指标平台能力简介及指标复杂计算的实现方案介绍

最新推荐文章于 2026-06-23 21:03:17 发布

原创最新推荐文章于 2026-06-23 21:03:17 发布 · 1k 阅读 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

wavefly_liu

关注

标签

#大数据 #etl工程师 #数据仓库 #powerbi

分类 it交互设计（ux）

1 序言

因为做数据分析产品，在支持用户的取数需求过程中，随着用户数据化意识的增强，用户取数需求中『指标复杂计算』的case越来越多。但这10年来研究过不少指标平台。发现很多指标平台和数据分析产品的对指标复杂计算的支持不是很好。

下面把2021年做调研的文章发出来，介绍：

指标复杂计算的case是什么样子的
业界的顶尖产品是如何支持的。

1.1 早期的指标平台重视指标的管理和搜索

早期是比较出名的是基于OneData理念（大概是2015年提出来的）构建的指标研发与管理的指标平台，重心是放在：

满足指标确信需求：指标语义建模的能力建设。
指标的消费效率（相关子指标：找到指标的耗时、指标确信的耗时）：目录管理等建设。
指标稳定性保障：指标变更管控等能力建设。

当时存在的问题是：指标中心定义的指标和数据分析平台能消费的领域对象不一致，导致数据研发同学定义的指标不能在数据分析产品上很好的消费。不过这些指标通过OnsService提供数据服务，可以为在线业务调用提供数据：也是有局部的用武之地，且此时也带来另一问题：指标数据服务的能力比较简单，主要指标code + 有限的条件组合（维度 + 筛选条件）来取数，也不能支持数分场景下灵活、复杂的指标计算需求，且取数性能的优化，也是需要考虑指标定义的资产同学来优化。

未关注消费视角关键诉求（指标计算的覆盖率、指标计算的性能）、且未能和BI工具打通，也最终导致OneData理念构建的指标产品和配置的指标，并没有在阿里成功落地、也没有在蚂蚁被接纳。

1.2 重视下游消费链路打通的指标平台，但是未指出指标消费的关键

大约在2021年，Headless BI这个概念提出来了：重点关注和下游各种消费链路的打通，『指标只需定义一次，即可在仪表盘、自动化工具乃至任何下游系统里统一消费』。数据团队专注语义建模，业务/分析师直接通过配置或 API 消费，下游的数据分析工具支持HeadlessBI的API消费协议。

此后，发现市场上一些HeadlessBI 指标平台开始考虑『指标计算的性能』，通过自适应物化的方式，解决海量数据查询的性能痛点。但关注『指标复杂计算的覆盖率』的HeadlessBI产品依然较少，原因可能如下：

未意识到。
有些是意识到了但是定义不出来有哪些种类。
有些可能上面2类问题以及解决了但是技术选型上的限制，最终难以实现。
还有可能自己的需求方还未有类似需求，暂不需要。

下面是『指标的复杂计算』的案例介绍（这里不会介绍所有的分类），以及Tableau LOD+表计算和 PowerBI DAX是如何支持的。

2 业务场景可能的复杂计算case

前提：依赖的物理表是 dwd的明细表。

例如：订单表，字段：订单id、用户id、订单金额、交易日期、交易城市。（不考虑订单状态）

2.1 最简单的指标计算

交易额 = sum(订单金额)

所有的指标平台、数分产品都支持的

2.2 基于已有指标的N次聚合

均值/中位数/最大值等等，提问case：

各城市交易额的最大值；
各城市交易额的平均值；
各城市交易额的中位数
月初至今的交易额的均值

基于已有指标的衍生，部分产品可能已经无法支持了

2.3 基于指标的数学计算

注意这些case的中的『维度、筛选条件』是动态，可以随着页面可视化参数的调整，动态变化，生成新的衍生指标。大家就会发现，大部分基于SQL的原子指标很难衍生这些复杂指标：

指标常见的四则运算 + 对指标进行下钻, 提问case：
- 最近7天交易额汇总的月同比值及月同比率；
- 最近10天交易额汇总与1月同期的差值和差值率
- 最近3周交易额的上月同比值及同比率；
- 最近3周交易额的环比值及环比率；
- 本月北京市交易额与上海市交易额相差多少；
- 本月北京市交易额在整体占比是多少
- 本月北京市交易额与全国城市交易额均值/最大值/最小值的差值是多少
- 本月每个城市交易额与全国城市交易额均值/最大值/最小值的差值是多少
- 昨天每个城市的交易额最多的用户的交易额均值是多少
集合运算：
- 复购相关：5月份购买、且本周购买的用户有哪些
- 新增相关：5月份未购买、但本周购买的用户有哪些
- 流失相关：5月份购买、但本周未购买的用户有哪些
- 等等
基于度量的条件判断（if-elseif、case-when）,提问case：
- 交易额大于1000的城市有哪些、城市有多少个
- 查询近30日日均交易金额大于1000的城市有哪些、城市有多少个
- 查询近5周周均交易金额大于10000的城市有哪些、城市有多少个
- 查询近7个月月均交易金额大于20000并且日均交易额大于1000的城市有哪些、城市有多少个
- 昨天各城市交易额大于全国城市交易额均值的城市有哪些、城市有多少个
- 上周各城市交易额大于全国城市交易额均值的城市有哪些、城市有多少个
- 本季度交易额大于1000的城市有哪些、城市有多少个
- 昨天各城市人均交易额大于1000的城市有哪些、城市有多少个
- 昨天各城市人均交易额大于全国人均交易额的城市有哪些、城市有多少个
- 本月各城市交易额与全国城市交易额均值差值的绝对值在1000到2000的城市有哪些、城市有多少个
- 等等
度量排序（rank、top），例如：
- 近15天交易额的Top10的城市有哪些、城市有多少个
- 昨天各城市交易额Top10的用户id是什么

基于已有指标的衍生，部分产品可能已经无法支持了

做个总结：指标的计算表达式中的各个参数过于灵活，会基于上一轮结果集合中选取部分数据参与下一轮的计算，在这个过程中各个条件变化，需要修改每轮集合对应的SQL，对调用方来说，难度太大。

注意：这个表格不全，还未考虑集合运算相关的操作符。

3 当前指标复杂计算的有哪些实现方案

Tableau LOD表达式+表计算表达式的方案：在SQL的基础上做增强，通过灵活函数+强大的可视化能力，支持用户指标各种计算口径。参考： https://zhuanlan.zhihu.com/p/51329368 https://zhuanlan.zhihu.com/p/60748698
PowerBI DAX的方案：通过灵活、丰富的函数，支持用户指标各种计算口径。参考：https://www.powerbigeek.com/tableau-top-15-lod-expression/ https://www.zhihu.com/tardis/bd/art/42980917

大家重点看『参考』上的case的实现方案，会发现这些BI产品的指标计算能力的实现，都是需要自定义的DSL来支持的，也就意味着纯粹靠SQL来实现 HeadlessBI中的指标定义，基本上是无法支持指标的复杂计算的。

当然自定义DSL也会带来定义的门槛问题，在大模型生成代码的方案出现之前， Tableau 的方案因为有可视化的加持，常见的复杂case的实现门槛较低； PowerBI DAX 强依赖用户的对语言的熟悉程度，门槛较高，后来DAX pro出现了，提供了大量的DAX表达式模板，降低了很多门槛。