摘要：今天分享的主要内容是数据指标的管理工作，以及快手是如何进行指标规范化的，还有快手的OneService平台化实战。内容干货满满，欢迎各位同学关注、留言交流。主要内容包括：

1、指标混乱现状

2、如何规范化定义指标

3、快手指标管理/服务问题及方案设计

4、指标规范化建设

5、OneService平台化建设

6、落地成果及未来规划

一、指标混乱现状

指标是一种特定类型的元数据，公司的运营会围绕它们进行工作，可以说，指标是业务和数据的交汇点。指标数据能不能用，会影响他们日常的工作。

从2018年年末开始，某电商数据中台团队对电商业务的核心指标进行了全面的盘点和梳理，为的是解决指标口径不一致的问题。原先800多个指标，最终梳理完成427个指标。在梳理的过程中，总结了7个常见的指标问题，希望各位同学对照着看一下，自己是否也存在类似的情况：

1.1、相同指标名称，口径定义不同

以电商业务为例，不同的部门相同的“新用户销售额”存在不同的解释和计算逻辑。因为口径定义的差别，导致指标数值的不一致。而这种情况是指标管理中最容易出现的情况。口径不一致，数据也没办法横向对比，失去了数据辅助商业决策的意义。

1.2、相同口径，指标名称不一样

这种情况与上面相反，比如发放优惠券是电商常见的促销手段，现在有两个数据产品：

• 一个是经营大脑，主要展示的是企业日常经营活动健康度的核心指标，有一个指标叫做“优惠券抵扣额”

• 一个是市场360，主要展示的是市场活动效果衡量的指标，有一个指标叫做“优惠券耗金额”

其实，两者的口径定义并没有区别，计算逻辑也是一样的，但是，指标名称不同，这会让使用指标的人产生疑惑：这是不是同一个指标？计算逻辑是否一致？数据是否可横向对比？

1.3、不同限定词，描述相同事实过程的两个指标，相同事实部门口径不一致

这个问题该如何理解呢？来看一个例子：

黑卡会员购买用户和非会员购买用户数，它们描述的都是用户下单购买商品的相同业务过程，记录的都是购买商品的事实，只是一个限定词是黑卡会员，一个限定词是非会员。

按照一致性原则，虽然是两个指标，但是对于购买用户数这个相同的事实部分，业务口径、计算逻辑应该是一致的，但是现实情况却可能不是这样：

• “黑卡会员购买用户数”的口径定义是计算周期内去重的（重复购买的用户只算一个），下单并且支付成功的用户数量；

• “ 非会员的购买用户数”的口径定义是计算周期内去重的，下单并且支付成功，排除关单（“关单”是指在用户在下单购买成功后，取消订单）的用户数量。

对于购买用户数，这两个指标的口径是不一致的，一个包含关单，一个不包含关单。

1.4、指标口径描述不清晰

在梳理过程中，我们还发现，有些报表上的指标口径描述的比较笼统。比如“关单金额”，口径描述“关闭订单的金额”。不同人的理解可能不一样，有的人会认为是支付成功后关闭订单；也有可能是支付完成前，取消订单。描述不清晰，就会让人们对数据的理解产生歧义。

1.5、指标库口径描述错误

在流量分析数据产品中，有“7 日 uv”这个指标，口径的定义是 7 日内日均 uv。根据口径描述的计算逻辑，应该是最近 7 日，每日 uv 相加除以 7 取平均值。显然，这个定义在业务场景中是有问题的，正确的 7 日 uv 的口径定义应该是 7 日内有登录过，去重的用户数。

1.6、指标命名难于理解

我们在梳理促销业务过程的指标时，有一个数据产品的指标名称是“ROI”，口径定义优惠券销售额 / 优惠券成本。ROI 其实是投资回报率的简称，在电商业务场景中，除了优惠劵，商品降价促销都可以计算 ROI，所以比较好的命名应该是（商品|类目|通用）优惠劵ROI。所以，指标命名不规范的话，从指标名称中很难看出指标描述的业务过程。

1.7、指标数据来源和逻辑不清晰

如果指标数据来源不清楚，一旦这个指标数据异常，就很难去做溯源。另外，有些指标的计算逻辑比较复杂，仅仅凭借业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者 SQL 描述。

二、如何规范化定义指标

如果是咱遇到了这些问题，该如何规范化定义指标呢？下面给大家分享些经验，希望大家能从中学习到如何高效、规范化的管理指标。

2.1、首先，面向主题域管理

为了提高指标管理的效率，需要按照业务线、主题域和业务过程三级目录方式管理指标（业务线是顶级目录）

例如，在网易，电商、游戏、音乐、传媒、教育都是不同的业务线。在业务线之下，是主题域，指标中的主题域与数仓中的概念是一致的，划分标准最好的是跟数仓保持一致。在主题域下面还有细分的业务过程，比如对于交易域，细分的业务过程有加入购物车、下单、支付。

2.2、其次，拆分原子指标和派生指标

为了解决前面提到的“黑卡购买用户数”和“非会员购买用户数”，这两个指标对购买用户数口径的不一致问题，需要引入原子指标和派生指标的管理方式。那么问题来了：什么是原子指标，什么又是派生指标呢？

统计周期、统计粒度、业务限定，原子指标，组成派生指标。所以原子指标可以定义为不能够按照上述规则进一步拆分的指标。

可以这样理解：

购买用户数是原子指标，原子指标的口径定义是“计算周期内去重的，下单并且支付成功的用户数，包括关单”；

黑卡会员和非会员都可以认定为业务限定词；

统计粒度是商品的粒度；

统计周期是30天。

这样30天内，商品维度的黑卡会员购买数和30天内商品维度的非会员购买用户数就作为两个派生指标存在，但是他们继承自同一个原子指标。

2.3、指标命名规范

指标命名规范要遵循两个基本原则：

• 易懂，就是看到指标的名称，就可以基本判断这个指标归属于那个业务过程；

• 统一，就是要确保派生指标和它继承的原子指标命名是一致的；

除此之外，指标应该有指标和指标标识（或者叫英文名）

对于原子指标，指标名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好。

对于派生指标，指标名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式，标识命名要用“修饰词_原子指标_时间周期”的方式。

2.4、关联的应用和可分析维度

对于使用指标的人（运营、分析师）了解了这个指标的口径定义后，下一步就是要看指标的数值。所以，在全局的指标字典中，还应该有指标被哪些应用使用，这样方便去对应的数据产品或者报表上查看指标的数值。除此之外，还应该有指标的可分析维度，方便分析师从不同的维度分析指标的变化趋势。

2.5、分等级管理

那这么多指标，数据中台管的过来么？是的，确实管不过来，因为不仅仅是数据中台会产出一些公共核心指标，业务部门也会创建一些专属业务部门内的指标。那面对这么多指标，如何管理呢？按照经验，可以按照以下原则区分等级来管理指标。

• 一级指标：数据中台直接产出，核心指标（提供给公司干层看），原子指标以及跨部门的派生指标

• 二级指标：基于中台提供的原子指标，业务部门创建的派生指标

不同等级的指标意味着管理方式不同：

• 一级指标，要确保指标按时、保证质量产出，指标创建由中台负责

• 二级指标，允许业务自己创建，中台不承诺指标的产出时间和质量

三、快手指标管理

3.1、指标服务面临的问题：

• 指标管理不统一

• • 多处管理，成本较高

  • 重复管理，指标泛滥

• 指标口径不统一

• • 同名不同义

  • 同义不同命

• 指标流程不统一

• • 系统之间相互独立

  • 无法统一流程控制

3.2、指标管理面临的问题：

• 数据字典，约等于Wiki，能管能看

• 无体系化流程保障机制，数据准确性无法保障

• 指标血缘关系缺失，没有和数据生产、消费体系建立血缘关系

• 定义管理与应用使用分离，无法一处不变，全局生效

问题总结为：没有发挥最大价值，指标管理动力不足！！

3.3、指标管理设计思路：

3.4、解决方案设计：

3.5、解决方案落地：

四、快手指标规范化建设

4.1、指标规范：

PS：快手指标规范也离不开上面介绍的那几种方案，万变不离其宗，大家好好体会、理解。

4.2、模型设计流程规范：

4.3、OneMetric-设计思路：

4.4、OneMetric-架构设计：

4.5、OneMetric-元数据管理模块：

4.6、OneMetric-指标⼀致性模块：

4.7、OneMetric-模型构建模块：

4.8、OneMetric-模型搜索模块：

总结：快手的指标规范化建设基本也是遵循了数仓的一致性维度和一致性指标的原则，并且参照数仓的维度建模和分层理论基础实现指标的规范化管理。指标管理的好坏也意味着数仓建设的完整度，作为数据人，我们应不断地充实自己、完善系统。

五、OneService平台化建设

5.1、设计思路：

5.2、架构设计：

5.3、查询DSL抽象：

5.4、执行计划：

5.5、执行流程：

5.6、OneSQL翻译过程：

六、落地成果和未来规划

6.1、落地成果：

6.2、未来规划：

七、写在最后

本文通过理论基础和快手实际落地项目和大家分享了指标相关的一些知识，现在回忆下：如何构建全局一致的指标？原子指标和派生指标的特点是什么呢？常见指标的问题和规范化手段又是什么呢？

最后，给大家提一个思考的点：在企业的指标体系中，大家觉得应该原子指标多，还是派生指标多？为什么呢？欢迎大家留言讨论~

最后的最后，感谢各位阅读，如果这篇文章让你收获一二，也欢迎各位分享给更多的朋友奥~

往期推荐

实时和离线，大数据计算引擎谁主沉浮

元数据：快手元数据平台建设及应用场景

数据湖：Apache Iceberg在腾讯的探索和实践

快手如何是从模型规范开始进行数据治理的

基于快手直播场景聊一聊数据质量体系

听说一键三联的朋友都暴富了

女朋友都贼拉漂亮