Part 1 一些基础观点

关于维度

多维数据分析过程中，大家会假定数据为一个多维立方体，然后其针对其维度会有切片、切块、上卷、下钻等操作

那么从这一观点出发，我们对于维度的定义应该也可以反推：维度需要支持切片、切块、上卷、下钻操作，才可以被称之为维度。

为什么要多说上面这一句看似废话的观点呢？给大家举一些例子：

1、数据应用——海外业务报表查询时，我们会有一些筛选项，例如：游戏、渠道等，这些是可以对应上数据表的具体字段进行操作的。

2、但还有一些例外，例如：退款勾选、平台选择。不勾选退款时，订单金额的指标是“订单总流水”，而勾选后则成了“订单总流水-订单总退款”。而平台选项更会直接更换查询的目标数据库表。

这两者显然不是对于数据的维度操作，而以往我们都会含糊地将其统一归类为“维度”。

（碎碎念：当然我们可以在一个更宏观的角度说，它们的确就是某种概念上的“维度”，与处理方式无关。这里暂时不做这种讨论。）

关于指标

指标，是业务和数据结合的度量值，普遍会将其划分为三类：原子指标、复合指标和派生指标。

怎么理解呢？接着上面提到的订单金额指标进行举例：

1、当查询不选择退款的订单金额时，计算的是“订单总流水”，我们查询的逻辑简单来说是 "SELECT SUM(MONEY) FROM ORDERS;"，即仅需查询一个表、一个维度上的数据，无关筛选条件，此时这个查询逻辑是一个不可再分的基础逻辑，即原子指标类型

2、当查询选择退款的订单金额时，计算的是“订单总流水-订单总退款”，我们需要查的除了如上的总流水外，还需要查退款订单总额，例如"SELECT SUM(MONEY) FROM REFUND_ORDERS;"，然后将总流水与总退款进行计算。此类逻辑是将多个指标查询得到结果后再加工而来，即复合指标。

3、派生指标则是在以上两者基础之上，再添加了一些业务属性而来的特制指标。例如LTV指标，限定上时间属性3日、7日之后，又会出现3日LTV、7日LTV这样的指标。

Part 2 边界讨论

前面阐述了一些业务逻辑带来的指标维度划分问题，那么不可避免的，我们立即便会遇到一个冲突：这些形如”退款“、”平台“的影响指标逻辑的业务筛选项，是应该应用开发人员自行转换，还是该纳入指标设计体系？

这个问题如果没有其他因素加入考虑的话，是无解的，因为从实现上来说无论哪方来做都是没有问题的。因此，我认为两者中间有一段共同的缓冲区，这块区域内的内容是双方都可以承担的，因此可以对于其中的内容进行逐一甄别。

这里举三个例子：

1、“币种”选项导致指标切换

对于充值金额，报表上类似“退款”选项，也有“币种”选项，对于不同币种，指标对应的字段不同。

对于这类查询，无关查询业务方是谁、使用系统是谁，其逻辑是标准的，因此可以纳入指标设计体系。

2、应用侧给定的指标和维度不匹配

例如，查询订单的充值金额指标时，调用方指定了一个不支持的维度-标签值来分组，这样的查询是非法的。

但是对于指标体系设计人员来说，此次查询虽然非法，但我并不知道应用侧想要的产品逻辑是什么，例如：是忽视掉不支持的维度进行查询？是忽视掉不支持该维度的指标进行查询？还是抛出警告让用户取消勾选？

因此，我们设想是提供指标与维度关联关系计算的API或SDK服务，应用侧可以在计算得到支持关系结果后，处理成合法的请求再进行查询。是一个折中的方式。

3、同一报表场景下，指标、筛选项任意组合

对于某些特殊应用场景，业务方要求的报表中，某些筛选项只用于其中部分指标，例如下图中，要求时间筛选项只作用于充值金额指标，而不影响充值人数指标。

对于这类查询自由组合的情况，只能是应用侧自行处理了。

Part 3 指标体系设计尝试

分层

至此我们对指标体系结构有了大概的轮廓，我们可以将此划分为三层：

1、原子指标：一个指标对应一个SQL查询逻辑

2、复合指标：指标计算逻辑为原子指标+四则运算

3、派生指标：由派生指标名+传入的业务条件进行计算，得出原子或复合指标后，再进行原子或复合指标的查询

举例：

1、原子指标：订单流水_人民币、订单流水_美金、退款_人民币、退款_美金

2、复合指标：减退款流水_人民币（订单流水_人民币-退款_人民币）、减退款流水_美金（订单流水_美金-退款_美金）

3、派生指标：订单流水+（条件：退款、币种）

三层关系如图：

实际上对外暴露的指标，只需要一个“订单金额”的指标即可，可以通过传入的条件进行自动计算出实际指标逻辑。

分类

然后，虽然指标分为三层，对于使用者来说，依旧只有指标、条件（维度+业务条件）和分组三个参数，他们其实不关心指标内部如何分层，因此，为了快速定位所需指标，需要对指标进行多级分类

Part 4 更多思考

权限

对于数据的管控，存在一个连接关系问题：用户身份存在于应用测，而数据存在于指标重新侧。如何建立用户与数据的关系，就是个需要思考的问题，或许如果有一个三方的权限中心可以协调。

命名

目前有两种命名规则，其一为含规则语法的命名，在名称中以特殊含义字符来表示取数逻辑，例如s-money-o-d，可以表示sum(money)、from order表、按day分组

另一种则为普通命名，例如订单流水total_money

其实结合实际业务来说，前者可以操作的空间更大。举一个实际业务例子，同样是按天查订单流水，其实有两种查法，一是按注册时间register_day，另一种是按pay_day支付时间分组。

如果我们在一个报表中，同时查注册人数、订单流水，其中注册人数只能按注册时间分组，订单流水需要按支付时间来查看，那么按照常规逻辑，我们只能拆分为两个请求，处理完后再合并。但如果我们对于带语法规则的指标名，则可以约定一个附加参数用于条件切换，例如变更一个参数d为pd，改为s-money-o-pd表示按pay_day分组，则可以在一个请求中进行指标处理。当然实际的sql查询数量并不会减少，因此这种方式是否有收益还需要思考。

工作流

在实际指标使用过程中，存在指标需求收集、指标实现、数据校对、调用追踪等过程，如何使指标管理体系运行起来合理高效、便于协作，是个很重要的问题。

从目前实践的经验来看，需求收集和数据校对的耗时非常长。

此外，对于使用方来说，完整的数据流、数据查询和处理逻辑的透明性非常重要，直接关系到指标中心的可靠性。

免责申明：

本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！

《数据治理行业实践白皮书》下载地址：https://fs80.cn/4w2atu

《数栈V6.0产品白皮书》下载地址：https://fs80.cn/cw0iw1

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=bbs

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」，交流最新开源技术信息，群号码：30537511，项目地址：https://github.com/DTStack