Level of Detail - LOD计算
Level of Detail 详细级别表达式. 在开始之前, 我们看看官方文档里对LOD是怎么描述的?
详细级别表达式(也称为LOD表达式)允许您在数据源级别和可视化级别计算值. 但是LOD表达式可以让您控制要计算的粒度.他们可以在较高粒度级别(包括), 较低粒度级别(排除)或完全独立级别(固定)执行.
不知道今天作为Tableau新手的你, 现在看到这段对于Tableau LOD的简介,有没有一种每个字都认识, 但是连起来这是人说的话的感觉不. 那么今天这节课就试图给你讲清楚LOD到底是干嘛的.
图表中显示的数值都受到那些因素的影响?
首先我们需要观察一般Tableau计算的发生过程, 看看它的计算结果会受到什么影响. 我以最简单的销售额为例, 看看一个普通的计算SUM(Sales)是如何随着一步步操作, 数值而不断变化的.
理解这些变化发生的原因非常重要.
在这三幅截图当中, 我们并没有更改SUM(Sales)这个计算的定义, 但是我们可以看到显示的结果在不断改变.
第二个截图表明我们的计算受到所添加到的Dimension的影响. 当我们在Rows上添加Customer Name, 它显示的就是Sum(Sales) by Customer. 而不是所有Customer的总和. 它影响了Sum(Sales)计算的方式
而第三个截图就是Filter:过滤器. 过滤器决定了那些数据会显示, 哪些数据不会显示. 但是它不会改变计算的方式
数据的颗粒度: 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当中创建的图表的颗粒度不可能高于数据源. 换句话说你所做出来的图表不能超越你的数据
为什么你必须对数据颗粒度了如指掌?
在前边我已经向你展示了如果对数据颗粒度判断错了会造成多么致命的后果, 但是颗粒度的重要性还远远不止于此. 数据的颗粒度直接决定了我们什么能做,什么不能做.
比如客户说, 我想要分析卖出去的这些产品的颜色占比, 你可以直接回答, 对不起 这个我做不了. 为什么? 因为在数据当中并没有颜色的数据,这个根本分析不了. 如果你上来就说这个可以做, 那个也可以做, 最后发现不行, 这往往会给客户造成你并不是很了解它的数据的印象,大大的扣分.
在实际项目中如何确定数据的颗粒度?
这个课题是我们在Tableau中级课程当中需要重点讨论的课题, 由于它的深度和复杂性已经超过初学者的范畴放在初级课程并不合适. 但请务必记住在拿到所有数据时不要忘了这一步因为它对项目的成败和交付至关重要, 一旦理解错了, 很多东西都要推倒重来.