Level of Detail - LOD计算
图表的精度都受到那些因素的影响?
首先我们需要观察一般Tableau计算的发生过程, 看看它的计算结果会受到什么影响. 我以最简单的销售额为例, 看看一个普通的计算SUM(Sales)是如何随着一步步操作, 数值而不断变化的.
理解这些变化发生的原因非常重要.
第一步 添加SUM(Sales)
此刻在图表的区域里, 显示的是所有[Sales] 这一列的总和
第二步 添加Customer Name
Customer Name添加之后,我们的表格从一行分裂成多行.
此时在图标中, 我们所能得到的信息的精度也发生了变化, 之前我是不知道每个消费者的消费额的, 只知道总数, 但是现在每个消费者的销售额我们就知道了.
我们的报告精度提高的同时, 我们所显示的数据也变多了.
第三步 添加Filter: City
我们的图表再次发生变化. 与上图不同的是, 此时我们的图表只会显示一个城市 Boynton Beach的Customer销售额
截止到这里, 我们图表的精度停留在:
Boynton Beach每个消费者的销售额
我们拖拽的Customer Name决定了我们只能了解到顾客这一层. City Filter决定了我们只能知道Boynton Beach这一个城市
我们拖拽到图表中的Dimension再加上Filter就决定了我们从图表里能知道多少信息, 同样也决定了图表的精度
为什么要理解图表的精度?
图表的精度我几乎没有看到有人提及. 但是它对LOD的学习至关重要. 而它之所以重要就是因为如果我们想要显示计算的结果超越当前图表的精度那么靠普通计算是不行的. 这也决定了在什么时刻你需要使用LOD计算.
当你想要显示的计算结果和你当前图表的精度不匹配时, 你就需要使用LOD计算. 不管是更高精度, 还是更低的精度.
现在假设我们需要计算每个消费者在总销售中的占比.
除了保持当前的图表精度之外, 我们还需要超越当前的图表来计算所有消费者加起来的总消费额. 这个数字不能受到Customer Name和City Filter的影响. 这个时候我们就必须依赖LOD来实现了
数据的颗粒度: Granularity
颗粒度这个词都快被互联网黑话的梗给玩烂了, 但是有的时候我觉得这个词翻译的还挺好的. 一看到颗粒这俩字, 我就会想到颗粒无收, 就会想到把一袋米倒出来的时候, 一粒粒的米. 而到了数据这里, 数据的颗粒度你可以把数据源当做一个超级大的表格. 而这个超级大表格当中的每个小格子里那一个个数字就是数据的颗粒
写到这里你可能对前一句话没什么感觉, 但是这句话当中有一个非常重要的词你可能忽略掉了. 这个词就是数据源, 也就是数据的源头. 你拿到手的第一手数据奠定了你整个数据
数据的颗粒度=数据的精度
数据是现实的记录. 而数据的精度就代表数据能够多精确的反应现实.
假设我们拿到的数据只有一行, 整个公司一年的销售额是1180万. 那么你的报告就只能精确到'年'和'公司'这个级别.
假设我们的数据不再是一行, 而是六十行. 数据中有公司五个区域, 每个区域2024年12个月的销售额共计六十行. 那么我们的报告最精确也就只能精确到'月'和'区域'这个级别.
到这你应该对颗粒度有一个大概的了解了.
数据源的颗粒度代表了我们能够把数据收集到多么精细的程度. 精细的程度越高, 数据的体量就越大, 数据的结构就越复杂
现在我们以Tableau所提供的这个Sample - Superstore为例, 这里的每一行数据所代表的是什么?
每一行数据代表着: 一个订单下边的一种产品的销售数量, 销售额, 利润, 生产商, 产品编号, 订单的下单时间, 发货时间, 发货方式,顾客姓名 和顾客地址
更重要的是要理解一个顾客可以下多个订单, 一个订单下边可以包含多种产品, 而每行数据就是一个订单下的一个产品. 这就是这个数据源的精度的极限也就是这个数据的颗粒度
数据源的精度如何决定你面试和项目成败的?
当拿到数据之后, 探索和确定数据源的精度至关重要. 这直接决定了你所创建的报告的结果的对错.
比如我们接到的要求是计算每个订单的总额的平均值. 从逻辑顺序上来讲, 我们首先需要知道每个订单的总销售额, 然后再取它的平均值. 如果你没有探索过数据源的精度, 你会怎么做.
你有极大的可能把 [sales] 这个column当成每个订单的总销售额, 而不是订单下每个产品的销售额.
左边是一个非常简单的例子, 我们的数据当中只有两个订单, 订单号分别为123和456. 在订单123中, 顾客买了四种商品分别是A,B,C,D而订单456中, 只有两种商品分别是B, C
那么此时[Sales]这一列的数据所代表的含义是一个订单下边一个产品的销售额.
如果我们要计算订单的平均销售额我们应该怎么做? 首先把订单123的销售额加起来, 12.8 + 15.6 + 13.4 + 45.2 = 87. 再把订单456的销售额加起来 25.6 + 27.8 = 53.4
87和53.4取平均数等于70.2
如果没有理解数据源的精度你会犯下什么样的致命错误?
想象一下这个表格里不再是这六行而是成百上千行, 也不再是这三列,可能是20或者30列, 而你又恰好处于面试或者赶Deadline的压力当中. 你会不会上来就把Sales当成是一个订单的销售额而不是一个订单中的一个产品的销售额?
如果你犯了这样的错误,你会怎么算, 是不是直接计算Sales这一列的平均值, (12.8 + 15.6 + 13.4 + 45.2 + 25.6 + 27.8)/6 = 23.4
23.4和53.4相差了将近一倍.
作为一名Tableau Developer或者BI分析师来说, 这种错误是致命的.
区分图表的精度和数据的精度
在理解了数据源的颗粒度之后, 图表的颗粒度就非常好理解了. 我们在数据源当中往往希望保存非常详细的信息, 但是报告则恰恰相反，我们往往先关注整体再关注局部.
比如在报告中,我们想要看的是每个月份平均订单销售额的变化, 那么报告的精度就锁定在月份和订单总额这个级别. 报告并不会关注每个订单下边每个产品的销售额而是每个订单的总销售额.
因此我们在Tableau当中创建的图表的颗粒度不可能高于数据源. 换句话说你所做出来的图表不能超越你的数据
题外话: 为什么你必须对数据颗粒度了如指掌?
在前边我已经向你展示了如果对数据颗粒度判断错了会造成多么致命的后果, 但是颗粒度的重要性还远远不止于此. 数据的颗粒度直接决定了我们什么能做,什么不能做.
比如客户说, 我想要分析卖出去的这些产品的颜色占比, 你可以直接回答, 对不起 这个我做不了. 为什么? 因为在数据当中并没有颜色的数据,这个根本分析不了. 如果你上来就说这个可以做, 那个也可以做, 最后发现不行, 这往往会给客户造成你并不是很了解它的数据的印象,大大的扣分.
在实战中如何确定数据的颗粒度?
在本文的第一部分, 我指出数据的颗粒度是数据中的每一行所代表的含义. 但是除此之外, 我们还有一些更细致的问题需要去理解. 比如我们知道每一行数据都有一个post code. 但是一个订单下的所有商品都发往同一个post code吗? 有没有可能一个订单下边有不同的post code呢? 如果我们想要计算每个城市平均的订单金额, 那一个发往不同城市的订单我是拆开, 还是合并呢? 这些问题你想过吗?
再比如, 即使你拿到的数据格式和Tableau的sample superstore一样, 但是同一个订单下每个产品销售额都一样. 那这个[sales]代表的还是那个产品的销售额吗, 有没有可能每个产品的具体销售额我们不知道, 而[sales]这一列只是订单的总销售额呢? 如果你不打开一个个检查,你能意识到吗. 这无尽的问题都需要我们打开实际的数据一个个的去验证. 往往在验证的过程中,就会给你一个个惊喜.
在中级课程中, 我将专门有一课来通过实战来展示颗粒度的坑到底能有多深.