【下篇】计算列 vs 计算度量：你真的懂吗？

【上篇】计算列 vs 计算度量：你真的懂吗？ 上篇内容学完，是不是感觉对于计算列和计算度量的选用时，还是容易搞混呀？

别担心！接下来，让我们继续走进不同场景的实际示例，就像玩解谜游戏一样，看看在什么情况下，计算列是最佳 “搭档”，而什么时候计算度量又能 “大显身手”。

多研究几个实际案例，就像多积累了几个通关秘籍，帮你透彻理解如何选用计算列和计算度量，保准让你豁然开朗！

 

 

（1）场景描述：计算两数值字段相乘，需要计算前判断若字段为空则显示0

• 揭晓答案：对原始字段值直接判断处理，选用计算列，使用 IFNULL 函数，当值为null时转成0，如果为””空时也可以转成0 ：

 

 

• 预览结果：

 

 

（2）场景描述：值判断是否为空,数据源中存储的数据有null，需要判断最终展示的结果数据 为 null时 显示为 0 

• 揭晓答案：判断展示结果数据，那就是对度量判断处理，得选用计算度量二次计算判断，通过函数IIF、IsEmpty函数进行判断，如下图表达式的含义：如果[销售额]度量为空，则返回0，否则返回1。

 

 

• 预览结果：

 

 

（3）场景描述：把订单模型订单表中的“区域”、“省份”、“城市”、“地址”这几个字段拼接成一个收货地址

• 揭晓答案：直接拼接表字段应该使用计算列，创建计算列，使用 CONCAT函数进行拼接，可以使用无数个字段或者常量。

 

 

• 预览结果：

 

 

（4）场景描述：需把指定成员拼接成一个字符串，例如如何把销售额前3的3个城市名称拼接成一个字符串显示

• 揭晓答案：与例子（3）不一样的是，这个需求是需要判断度量汇总后的值，再拼接实际汇总对应结果值，此时应该选用计算度量，如下图：

 

 

• 预览结果：

 

 

（5）场景描述：有一个“订单日期”字段，把它作为筛选器，当前值是2024年7月11，现在要取这个日期的前30天

• 揭晓答案：对表字段判断处理，应该选用计算列，通过DATEADD 函数实现：

 

 

• 预览结果：

 

 

（6）场景描述：返回日期之间的天数差，比如计算下单到发货用了多久

• 揭晓答案：对明细行字段判断处理，应该选用计算列，通过DATEDIFF函数实现：

 

 

• 预览结果：

 

 

（7）场景描述：查询购买商品次数大于1的客户数有多少

• 揭晓答案：需基于维度汇总后的度量进行二次计算分析，创建计算度量，使用 count、Filter 函数实现：

 

• 预览结果：

 

 

（8）场景描述：如何计算某些成员的销量，例如计算“产品名称”下的白米的销量。

揭晓答案：

【推荐】方案一：如果计算度量只有指定成员汇总，可以优先使用计算列，计算结果通过计算列处理好再复制转度量使用，计算列转度量走SQL引擎优化查询性能较好

【不推荐】方案二：接通过计算度量向导——计算类型选择“按指定成员集聚合度量”并勾选“白米”作为成员集。

 

• 新建计算列-复制转度量：

 

 

• 新建计算度量：

 

 

• 预览结果：

 

 

• 查看系统监控-SQL/MDX记录，可看到计算列转度量的查询耗时比直接计算度量处理快很多：

 

 

（9）场景描述：如何排除某些成员的指标，例如排除产品类别为点心的销售额?

• 揭晓答案：涉及成员的可以新建计算度量，通过AGGRGATE、EXCEPT函数处理：

 

注意：选维度成员下面的【产品类别】，上面维度那个包含了一个all成员，数据会翻倍；

 

 

• 预览结果：

 

 

（10）场景描述：按多个维度指定成员进行过滤汇总，例如计算2020年、东北区域、点心类别的销售额

• 揭晓答案：涉及维度指定成员汇总处理，选用计算度量，通过 AGGREGATE、NONEMPTYCROSSJOIN 函数实现；  

注意：如果要更多个维度，可以再嵌套一个NONEMPTYCROSSJOIN，用多了NONEMPTYCROSSJOIN 可能会存在性能问题。

 

 

• 预览结果：

 

 

（11）场景描述：指定维度进行汇总，例如需查询【区域】和【类别】的销售额合计值，但是又想显示区域的销售额与它进行对比

• 揭晓答案：涉及维度汇总处理，选用计算度量，通过 FIXED函数实现；  

 

• 预览结果：

 

 

优先选择计算列或计算度量的场景决策树：

1、是否需要聚合？

是 → 计算度量（如场景2、4、7、8、9、10、11）

否 → 计算列（如场景1、3、5、6）

 

2、是否需要动态上下文？

是 → 计算度量（如结果依赖维度和度量聚合后的数据）

否 → 计算列（如结果仅依赖原始数据）

 

3、是否涉及成员筛选？

是 → 计算度量（如场景8、9、10）

否 → 根据其他条件判断

 

典型错误规避：

1. 误用计算列处理聚合：
   计算列无法感知维度上下文，无法正确计算动态汇总值（如最大日期对应的金额汇总值）。


2. 误用计算度量处理明细数据：
   计算度量需依赖聚合逻辑，无法直接处理行级字段拼接（如地址拼接）。

 

在本篇文章中，我们继续结合具体案例演示了计算列和计算度量两者在计算逻辑方面的特性，相信我们遇到不同业务场景需求时，都会快速定位应选用计算列还是计算度量，确保业务展示结果正确性啦！

当你掌握了这些核心技能，就能像数据魔法师一样灵活驾驭数据模型。那么最后一个问题来了 —— 如何正确使用数据模型参数？别急，这正是我们下篇要解锁的终极秘籍！

 

下篇精彩继续：
▶ 秒懂！模型参数的应用与生存法则

记得关注更新，我们将手把手带你突破数据建模的 "最后一公里"，不见不散！

 

降龙十八赞

受益匪浅

点赞。看了之后对计算列和计算度量的理解更深入了。

感恩的心，刚好拿来用一下

这些场景还是很nice的，都比较常用。

牛啊

可以可以

清晰明了，学习了

好像还没看懂啊