数据中台实战(05)-如何统一管理纷繁杂乱的数据指标？

红太狼 2024-02-25 04:36 5阅读 0赞

各种类型的元数据有什么用？跟数据中台啥关系？

元数据在指标管理、模型设计、数据质量和成本治理四个领域都发挥作用，这些领域构成数据中台OneData 数据体系。今天逐一了解元数据在上述领域的应用

### 1 指标管理 ###

指标，一种特定类型的元数据，运营会围绕它工作，业务和数据的交汇点。指标数据能否用，会影响他们的日常工作。

电商业务中，新用户销售额是考核市场活动拉新效果的重要指标。马漂亮是市场部门的数据分析师，某天，她要给CEO提供一份数据报告，报告有一项指标“新用户销售额”。孙美丽是会员中心的运营，她每天都会给CEO提供每日的新用户销售额数据。

结果有天，CEO看这两份报告后发现，同日的新用户销售额数值相差很大，他判断数据出问题，责令两部门负责人排查。**排查后发现，市场部门对新用户口径的定义和会员中心不一样：**

*  市场部门认定新用户是首次下单并完成支付的用户
 *  会员中心认定新用户是当日新注册用户

即市场部门认定的新用户中，可能有之前注册但没下过单的客户；而会员中心只包括当日注册并完成下单支付的用户。日常工作中还有很多类似问题。

上述问题根源是指标口径不一致，而你要构建全局一致的指标口径，输出企业的指标字典。

### 2 指标混乱现状 ###

18年末开始，网易电商数据中台团队对电商业务的核心指标全面盘点梳理，解决指标口径不一致问题。原800个指标，最终梳理完成427个指标，总结出常见的指标问题：

![3bbd4e56dfa34c50acac6c9a4cdf7910.png][]

同名不同径，同径不同名。  
口径不清晰，口径有错误。  
命名难理解，计算不易懂。  
来源不清晰，同部不同径。

#### 2.1 相同指标名称，口径定义不同 ####

不同部门对相同的“新用户销售额”，因为口径定义差别，导致指标数值的不一致。这是指标管理最易出现的case。

口径不一致，数据就无法横向对比，失去数据辅助商业决策的意义。

![27e3fc99e1a744d59e6121f076786bc8.png][]

#### 2.2 相同口径，指标名称不一样 ####

如发放优惠券，现有两个数据产品：

*  经营大脑，主要展示企业日常经营活动健康度的核心指标，有个指标“优惠券抵扣金额”
 *  市场360，主要展示市场活动效果衡量的指标，也有个指标“优惠券消耗金额”

二者口径定义无差，但指标名称不同，让指标使用人疑惑，是否同一指标，计算逻辑是否一致？数据是否可横向对比？

#### 2.3 不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致 ####

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

按一致性原则，虽是俩指标，但对购买用户数这个相同的事实部分，业务口径、计算逻辑应一致，但现实可能：

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

对购买用户数，这两个指标的口径不一致：

*  一个包含关单
 *  一个不包含关单

#### 2.4 指标口径描述不清晰 ####

有些报表上的指标口径描述较笼统。如“关单金额”，口径描述“关闭订单的金额”。不同人理解可能不一，有人认为是支付成功后关闭订单；也可能支付完成前，取消订单。描述不清，让人对数据理解有歧义。

#### 2.5 指标口径描述错误 ####

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

#### 2.6 指标命名难于理解 ####

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

#### 2.7 指标数据来源和计算逻辑不清晰 ####

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

### 3 如何规范化定义指标 ###

如何高效、规范化管理指标。

![196ea48c966d4a9a84fe6303ed0b49fa.png][]

#### 3.1 面向主题域管理 ####

为提高指标管理效率，需按业务线、主题域和业务过程三级目录管理指标（业务线 - 顶级目录）。

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

#### 3.2 拆分原子指标和派生指标 ####

为解决“黑卡购买用户数”和“非会员购买用户数”，这俩指标对购买用户数口径定义不一致问题，需引入管理方式：

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

![03c0fafd79634ba0b3bc293819c2f990.png][]

即可理解为：

*  购买用户数是原子指标，原子指标的口径定义“计算周期内去重的，下单&&支付成功的用户数量，包括关单”
 *  黑卡会员、非会员都可认定为业务限定词
 *  统计粒度是商品粒度
 *  统计周期30天

这样：

*  30天内商品维度的黑卡会员购买用户数
 *  30天内商品维度的非会员购买用户数

就作为两个派生指标存在，但他们继承自同一原子指标。

#### 3.3 指标命名规范 ####

遵循基本原则：

*  易懂，看到指标名称就可基本判断指标归属哪个业务过程
 *  统一，确保派生指标和它继承的原子指标命名一致

指标应有指标名称、指标标识（或英文名）。

*  原子指标，指标名称适合用“动作+度量”命名（如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写较好
 *  派生指标，应严格遵循“时间周期+统计粒度+修饰词+原子指标”命名，标识命名要用“修饰词\_原子指标\_时间周期”的方式

![dc47716dbfd54bbcaf04f9e02de5c5f7.png][]

#### 3.4 关联的应用和可分析维度 ####

使用指标人（运营、分析师）了解指标的口径定义后，下步就是看指标数值。所以，全局指标字典中，还应有指标被哪些应用使用，方便去对应数据产品或报表查看指标数值。

还应有指标的可分析维度，方便分析师从不同维度分析指标变化趋势。

#### 3.5 分等级管理 ####

这么多指标，数据中台管的过来？管不过来，不仅是数据中台会产出一些公共核心指标，业务部门也会创建一些专属业务部门内指标。这么多指标咋管？可按照如下原则等级管理：

*  一级指标：数据中台直接产出，核心指标（提供给公司高层看）、原子指标及跨部门的派生指标
    
    要确保指标按时、保证质量产出，指标创建由中台负责
 *  二级指标：基于中台提供的原子指标，业务部门创建的派生指标
    
    允许业务方自己创建，中台不承诺指标产出时间和质量。

> 结合自己所在业务，找一些指标，按上面方法实践！

### 4 指标系统 ###

很多公司爱Excel管理指标，觉得上手容易，编辑方便，但不适合指标管理：

*  难共享
 *  缺少权限控制
 *  无法动态更新
 *  指标无法跟数仓的模型动态关联

需要一个面向指标的管理系统：

![f4665797df014513889d5546abd8279c.png][]

指标系统是基于元数据中心构建的一个指标管理工具，它从元数据中心自动同步数仓的主题域和业务过程，按规范化定义创建指标。

新创建的指标同时会以特定类型的标签，下沉到元数据中心对应的表和字段，这样在数据地图上就能搜索到表关联的指标。

![b51b0702bf324cbcb03489dfc519af8d.png][]

支持按指标名称、标识、业务口径检索：

![2e6b90585cd7440ca882ee330f6ed05d.png][]

既然指标系统能实现指标规范化定义，解决“如何系统化、规范化定义指标”，如何基于指标系统构建全局的指标字典，因为这是指标治理的最终结果。

### 5 基于指标系统，构建全局的指标字典 ###

指标治理最终结果，是形成一个全局业务口径一致的指标字典。让使用指标人可通过指标字典，快速了解指标业务含义和计算过程，不对指标口径产生歧义。

数据中台团队须有一个专门负责指标管理的人/小组（一般不超3人），最好是数据产品经理负责，若公司没这职位，也可让分析师承担（前提分析师须属中台团队）。

构建全局的指标字典分如下场景：

#### 5.1 面对新的指标需求，如何基于指标系统完成指标开发 ####

![18937c63839c4a64b48638d7e2fc175d.png][]

新建指标的流程，流程中参与的各角色。

*  指标需求评审，需求方、数据开发、应用开发都参加。评审先要确认这是不是一个新指标，并明确原子指标/派生指标。评审就是要达成一致
 *  评审结果：
    
     *  不需要开发，是已存在的指标，直接可通过设计逻辑模型，发布接口，获取数据
        
        交付时间短
     *  需要开发
        
        需排期，交付时间长
 *  指标有等级之分，这流程适用于一级指标，二级指标可无需评审，当然开发也由业务方开发和发布上线

#### 5.2 面对已存在、混乱的指标现状，如何全局梳理 ####

很多公司已有一定大数据业务，但还不能算中台，这部分公司如何进行一次全局的指标梳理？

步骤：

1.  成立以数据产品或分析师为核心的1～3人的工作小组，专门负责指标的全局梳理
2.  制定指标梳理计划，明确指标梳理目标，覆盖多少个业务线，与业务方共同制定时间计划
3.  对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，这里顺便可以把没用的报表和数据产品应该下线
4.  对于每一个报表和数据产品中涉及的指标，按照以下格式进行收集

![204bc23204a24009a39a404e2a33b8cb.png][]

1.  对于收集的指标，明确业务口径，对于口径相同的，应该去除重复，关联的应用应该合并，此时以我的经验，可以过滤掉相当一部分；
2.  根据指标业务口径，明确指标所属的主题域、业务过程；
3.  区分指标类型，对于派生指标，要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标；
4.  按照指标系统对指标的规范化定义，把整理好的指标录入指标系统。

通过全局的梳理和新建指标流程的管控，你就可以构建一个全局一致的指标字典了。

### 6 总结 ###

如何构建全局一致的指标字典，通过系统+规范的方法，解决数据中台指标一致性管理的难题。

*  数据中台直接产出的核心指标必须实施强管理，由数据中台团队的专人或者小组负责，最好是数据产品经理的角色。
 *  指标的管理必须结合系统+规范的治理方法，明确每个角色的职责，通过系统化的方法实现。
 *  不同的两个指标描述的相同业务过程中的相同事实部分口径不一致，是指标梳理过程中最常见的问题，需要通过拆分原子指标和派生指标的方式解决。

![7041573df6d04e399964b8a1eb36c3e7.png][]

### 7 FAQ ###

企业指标字典中原子指标还是派生指标多？

基金公司基金规模算原子指标？因为他每天都在变，不加限定的日期根本不行？

应该是原子指标。为什么要区分原子指标和派生指标呢？ 全当原子指标，不就能确保每个指标的业务口径都在指标系统里面强管理。但这样指标的管理工作量太大了，而且整个数据分析的瓶颈会压在指标的管理上。所以就想出来一个方法，能不能把原子指标中，不涉及口径的指标，可拆，就是派生指标。

派生指标和原子指标有明确的区分，派生指标是时间周期+统计粒度+修饰词+原子指标。 时间周期和统计粒度并不涉及指标的口径。

关键在修饰词，哪些修饰词带口径，哪些不，难度就在这。如新用户销售额是原子还是派生，很多误作派生，其实新本身这个词是带口径的，新的定义大家可能不一致，而且也没新对应的维度，所以会把新用户销售额作原子指标。

啥修饰词不带口径？ 常见的就是一个维度属性值组成的修饰词，如黑卡会员销售额、母婴销售额，本身对应的维表的，所以大家对维度理解一致。

针对你这Case，基金规模属原子指标。加上日期，如最近一天基金规模，属派生指标。派生指标一定根据某原子指标来派生，所以先有原子指标基金规模的口径定义。

“指标管理须跟元数据中心关联，从元数据中心自动同步数仓的主题域和业务过程，同时以特定的类型标签下沉到元数据中心对应的表和字段，可应用到数据地图上关联了表和指标“ 这段话看起来应该是跟数仓动态关联的，但看后面指标录入时又是手动录入，不明白是手动维护？还是自动同步？如是跟数仓动态关联，怎么关联？

指标业务口径的录入，是指标管理人员在指标系统内完成，然后指标和数据模型，即表的关联在模型设计中心完成。

指标与表关联后，指标会作为标签，落到元数据中心，然后在数据地图查一张表时，就可以看到这表哪些字段对应哪些指标。

指标定义里面需要区分口径的，并且没有其他任何和口径相关的修饰词，那么就可以作为原子口径，有原子口径，并且有任何和口径无关的的修饰词的指标就是派生指标

但具体实施过程中，有没有口径，跟口径相不相关，这部分其实比较难判断。较容易判断的标准，就是如果修饰词有对应的维表，那就可以作为派生指标，如果修饰词没有对应的维表，那就作为原子指标管理。

新会员消费额，新没有对应的维表，就不能作为派生指标。黑卡会员消费金额，有黑卡对应的会员类型维度，所以黑卡会员消费金额是派生指标。这样就比较容易落地了。

指标是单独存在某一个或多个表里吗？如果存的话是放在数仓的那一层？

指标不是单独存在一个表，每个表中都可以有指标。指标一般出现在汇总层、集市层和应用层。

比如购买用户数，统计粒度是商品，那么统计粒度是不是可以多个，比如增加地区维度，那么地区如果全面按省市县三级，全国有几万个县，那派生指标是不是就是几万个呢？

不是具体的县市，统计粒度是指的县粒度的统计，市级别的粒度统计。

原子指标是根据业务流程的一些描述，而派生指标是数据需求者根据自己的需要对各种业务和业务流程的一些描述性数据，所以数仓刚建立应该是原子性指标多，随着需求的增多，派生指标就会增多

一个快速发展的业务，派生指标一定是多于原子指标的。如果原子指标比派生指标多，第一说明指标拆分存在问题，第二可能是业务没在发展，数据应用场景比较简单。

原子指标？这大概源自不可分割性吧，我们在数据系统设计时会去强调的原子性。其实老师在提出源自指标多还是派生指标多的时候可以去反向思考一下另外一个问题，我们在数据系统设计时是复合索引多还是单值索引多？  
哪个多少并不重要重要的是如何合理去定义与规范？定位的规范性和合理性这才是痛点。  
哪个多少并不重要，关键是合理和规范。

我之所以提这个问题，其实这个东西可以作为一个粗略的看看，你当前的指标管理是否规范。因为我看到很多指标管理过程中，基本都是原子指标，导致指标管理成为瓶颈。所以我提这个问题，是想让大家，拿这个可以看看自己当前指标管理中，原子指标的比例，如果很高，说明指标管理是有问题的。

网易系统有3种类型指标：原子指标，派生指标，复合指标。复合指标咋理解？如一个指标XXX率，是两个派生指标相除，这个指标是复合指标？

2或多个指标，通过一定规则，计算出来的，即为复合指标。

订单金额是原子指标吗？订单金额.付款日期统计；订单金额以确认收货日期统计；是不是就是两个派生指标？如看一个业务员的销售订单金额，是不是就要只统计派生指标的数据？因为原子指标实际上并不是一个真的有数据的指标，只是一个管理维度，可以这么理解？

订单金额是原子指标，而订单金额的付款日期统计和确认收货日期统计是派生指标。如想查看一个业务员的销售订单金额，要统计派生指标的数据。原子指标是管理维度，用于描述业务流程中的某个环节或数据，而派生指标则是基于原子指标计算得出的指标，用于更好地分析业务数据。

原子指标是不是一般无法产出具体的指标数据，而仅仅是一个定义。

如果先有指标，再关联元数据，如何赋能技术口径？是否可以直接通过事实表生成指标，可是这种方式又如何保证指标的唯一性？

指标和元数据相互关联。如先有指标，可通过关联元数据来赋能技术口径。更好了解数据的来源、定义和质量，从而更好地理解指标的含义和价值。

事实表是常见数据建模，可通过事实表生成指标。但为保证指标的唯一性，需要在数据建模和数据采集的过程中进行严格的控制和管理。例如，可以使用唯一标识符来标识每个指标，以确保其唯一性。同时，在数据采集和处理过程中，需要进行严格的数据质量控制，以确保指标的准确性和可靠性。

指标系统的核心是指标管理的方法论，方法论最重要的在于落地，也就是说，指标系统向上，要能够跟BI 打通，数据报表能够直接引用指标系统的指标口径，向下，指标系统要能够和模型建立关联关系，所以指标系统并不仅仅只是一个孤立的登记系统，指标系统承载的业务数据需求，也是业务看数据的主要对象。

业务场景：收件量，对应两种口径:结算口径和操作口径，结算口径和操作口径来源同一个dwd表，那么这个收件量作为原子指标，结算口径和操作口径作为派生指标吗？还是说结算口径和操作口径都做为原子指标呢？

派生指标是基于原子指标，通过构建派生词+时间周期，构建出来。 派生词一定以维表的属性值作为派生词，如结算口径收件量和操作口径收件量，要先确定，是否有结算口径和操作口径对应的维表。一般没有结算口径和操作口径的维表，所以会将结算口径收件量和操作口径收件量作为两个原子指标来处理。类同，前台毛利率、后台毛利率，虽都有毛利率字眼，但都是原子指标。

咱们这边是按照数仓模型建立的，应用层的指标是否也是在指标池的管理范围，应用层的指标可以基于汇总层建立吗？

应用层的指标，当时可基于汇总层建立。指标系统管理的主要是固化的沉淀的指标，如数据产品上的，固化的BI报表上的。 应用层的指标，应该也由指标系统管理。

指标在系统中的唯一性咋实现？新建一个指标需要人工评审，唯一性是在评审时人工确认吗，还是走系统方法进行检验？

如何帮助指标管理者快速发现这是重复指标，对提高指标系统管理效率很关键。提供一个文本相似性检测功能，基于word2vector实现，可将相似指标定义，业务口径的指标找出来，然后人判断是否重复。

数仓一般有ods、dwd、dws、ads层（有些可能更多层），元数据是所有层都要覆盖到吗？

分层通常是以标签形式，打在表上的，对应的是每个表对应的分层，所有的分层都必须要管理起来。

指标是在ads层吗，还是可能通过的dwd、dws或者ads层再计算出来的？如果是在ads层，那么可能会跟元数据有overlap？

指标dwd，dws，ads ，dm都有可能涉及到，一般原子指标在dwd，派生指标在dwd，ads和dm中。

指标划分时，先按业务线，再按主题、业务过程，那有些指标可能会跨业务线，这类咋处理？放一类跨业务线，还是类似打标签，同时打上多个业务线的标签？

如涉及跨业务线：

*  两个业务线都有这个指标
 *  单独搞一个公共的指标域

通常来说，两个业务线都有这个指标会更利于指标检索。

派生指标多，因为派生指标是由原子指标加统一周期、统一粒度、业务限定组成，所以衍生品肯定比原始产品要多。

指标管理中，一般派生指标>>原子指标，如你的指标系统，原子指标>派生指标，要思考是否有些原子指标没拆成派生指标。

原子指标与派生指标到底哪个多，看实际业务使用场景。多业务场景使用的指标，派生的应该多余原子。从原子指标和派生指标比例，也可反映指标管理好不好！

指标：付费用户中点击某按钮的用户，这时若不能从一张表出，而是涉及两个派生指标对应表的关联，如何处理？

派生指标直接基于两个表的数据计算出，并没落盘，那这指标怎么打在这个表？ 我们会在表上设计一个关联指标，不直接计算，但影响到这指标的计算结果。

指标系统等指标如何对外服务？  
指标系统，对外提供服务：

*  方便想快速了解指标体系的分析师、运营可以在指标系统中查阅指标
 *  更常见，在BI报表或数据产品，直接引用指标系统的口径定义，用户hover到某个指标上的时候，可直接展示指标系统的口径定义

派生指标如何生成？先生成然后固化成物理表？还是直接通过原始表实时计算？

派生指标，先在指标系统登记，然后在模型设计中心中，在模型设计过程中，与表关联，然后模型开发完成后上线，指标就加工出来了。派生指标一般存在与汇总层数据，一般是根据明细层度量数据，结合维度计算而来。

[3bbd4e56dfa34c50acac6c9a4cdf7910.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/4ccf417a5fb84d4d937eca0efa2d4f3d.png
[27e3fc99e1a744d59e6121f076786bc8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/14815e1e820d49dcad87e894cbc0561d.png
[196ea48c966d4a9a84fe6303ed0b49fa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/25dacbd310384b70922fa8a182ca379b.png
[03c0fafd79634ba0b3bc293819c2f990.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/2d1f21aa61a344bdabf3fb5816f99fe1.png
[dc47716dbfd54bbcaf04f9e02de5c5f7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/63e2e20e9be740789fb34f19f6cf4217.png
[f4665797df014513889d5546abd8279c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/6748b2681d09416bb7fd35ab7a3c7aea.png
[b51b0702bf324cbcb03489dfc519af8d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/038c73e5d233447fbe23beec0789f84d.png
[2e6b90585cd7440ca882ee330f6ed05d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/e0308df04e204a9f90aac64e6a98e1b5.png
[18937c63839c4a64b48638d7e2fc175d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/544e348428da4ad98cbc47dc634122c7.png
[204bc23204a24009a39a404e2a33b8cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/6da9765c6ac24888a173b0c91639dbb3.png
[7041573df6d04e399964b8a1eb36c3e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/e8071239a51d4246930d1f0d93314c1e.png