导读：指标是对客观世界业务过程以及结果的度量，是企业数仓的核心产物，通常需要配合维度及聚合方式进行衡量。完善的指标体系不仅可以辅助业务进行精细化运营，而且可以指导战略层进行经营分析以及业务决策。

　　01 指标管理背景　　

　　常见的指标交付流程如下：

　　DS 或运营提出指标需求

　　数据 BP 或数据产品梳理确认指标口径

　　数仓工程师进行 ETL 开发

　　最终交付的指标会被应用到下游的各个数据产品中，比如管理驾驶舱、BI 报表以及分析工具。

　　1. 指标的基本要求　　

　　数仓交付的指标必须满足准确性、及时性以及一致性的要求。同时，在指标交付的过程中，需要兼顾指标管理的效率。在滴滴数据体系 1.0 阶段，整体的策略如下：

　　（1）准确性

　　开发环节：通过测试中心进行指标数据的测试验收；通过配置数据质量规则监控指标新增分区的产出情况。

　　消费环节：通过配置指标监控监测数据异动。

　　（2）及时性

　　开发环节：在指标的生产任务上关联对应的SLA基线，通过基线的智能预警，配合平台的稳定性保障措施，保证指标的及时产出。

　　消费环节：根据指标等级进行分级保障，不同等级的指标挂靠不同级别的基线，通过基线倒推保障下游数据的及时产出。

　　（3）一致性

　　开发环节和消费环节：通过人工校验和反馈的方式确保指标的一致性。

　　（4）管理效率

　　开发环节：基于统一的一站式开发平台进行指标的开发。

　　消费环节：在下游各个数据产品中定义指标口径和取数逻辑。

　　由此可见，在滴滴数据体系 1.0 阶段，指标的口径散落在各个数据产品中，不但对一致性提出了挑战，也造成了各个数据产品的重复开发。

　　2. 解决方案发展

　　滴滴数据体系 2.0 阶段，核心目标之一是建立规范的、标准化的指标体系。

　　（1）指标字典　

　　为了提升指标管理的效率，最初采用的是传统指标字典的解决方案，即提供统一的指标平台，用于指标录入、解释指标口径。

　　该方案存在以下问题：不规范的命名会造成指标口径的二义性，譬如同义不同名、同名不同义等；指标管理的权责没有明确的定义，指标录入的流程没有严格的管控，久而久之就会造成指标口径的混乱以及指标体系的臃肿等问题，导致产品走向被弃用的结局。

　　（2）指标管理工具　

　　为了解决上述问题，基于数仓的维度建模方法论构建指标管理工具。通过系统自动生成规范的中英文名称，解决指标的重复建设问题，从而消除指标的二义性。同时明确了指标管理的权责，以及指标录入的流程管控。

　　具体做法如下：

　　根据滴滴的业务属性，划分网约车、两轮车等独立的业务板块。

　　在业务板块下划分数据域以及时间周期。时间周期主要是用于描述数据统计的时间范围，数据域通常是业务过程或者维度进行抽象的集合。

　　在数据域下划分业务过程。业务过程通常是企业业务活动的事件。

　　在业务过程下划分原子指标以及修饰词。原子指标通常是某个业务过程的度量，是业务定义中不可再分的指标。修饰词通常是除维度以外的限定条件。原子指标和修饰词以及时间周期构成了派生指标。

　　以网约车板块下的“最近 1 天完单 GMV”为例，GMV 是原子指标，完单是修饰词，最近 1 天是统计范围。系统根据原子指标、修饰词以及时间周期的中英文名称自动生成派生指标“最近 1 天完单 GMV”的中英文名称。

　　其次，指标管理的方法论由数据侧强管控。其中，相对不变的数据域、以及通用的时间周期，由业务板块管理员统一管控。和数据域强相关的业务过程、原子指标以及修饰词，由数据域管理员统一管控。由于派生指标的中英文名称是系统根据原子指标、修饰词以及时间周期自动生成。所以，一旦原子指标或者修饰词的口径发生变更，下游派生指标就会自动级联变更。此外，根据不同等级对指标的新增和变更流程进行强管控，譬如 T1 核心指标的变更，需要数据管理员、业务板块管理员分别进行审批。

　　02 滴滴数据产品概况

　　1. 数据产品多样，各自消费指标　　

　　滴滴数据产品包括面向高管的驾驶舱、面向业务的 BI 看板、面向 DS 的分析工具等，这些数据产品消费指标的模式分为两种：传统数仓模式和敏捷 BI 模式。

　　传统数仓模式下，数据 DS 提出指标需求，数据BP确认指标口径，并将指标录入指标管理工具。数仓工程师在数据开发平台上进行指标加工，产出各个业务方向的 APP 表。下游的各个数据产品基于 APP 表构建数据集，并在数据集上定义指标的取数逻辑。

　　该模式存在以下问题：

　　指标管理工具和指标生产、消费链路是脱离的，指标管理工具等同于一个规范化的线上 wiki，指标管理的业务价值难以评估。

　　下游各个数据产品各自维护指标的计算口径, 指标口径的一致性无法得到保障。

　　下游用户只能基于数仓提供的APP表中包含的维度进行数据分析，无法进行灵活的下钻分析。

　　2. 敏捷 BI 难以管控指标口径　　

　　传统数仓模式下，所有数据需求都要经过数仓的排期开发，在业务需求快速变化的场景下，数仓的开发效率以及需求响应速度就成为业务发展的瓶颈。由此诞生敏捷 BI 模式。

　　敏捷 BI 模式倡导“人人都是分析师”，即支持业务人员在 BI 工具中定义和加工指标，通过短平快的方式解决需求快速变化时的分析效率问题。在这种模式下，数仓提供的是大宽表，业务人员基于大宽表进行指标的加工以及灵活的分析。

　　该模式存在以下问题：

　　指标的计算口径由业务人员维护，并且散落在各个数据产品以及数据集中，导致指标口径的一次性问题变得更加严峻。

　　指标加工对于业务人员来说，存在一定的门槛。

　　3. 问题总结　　

　　综上所述，整个指标交付流程存在以下问题：

　　指标生产成本高。数仓面向应用层去构建 APP 表，可复用性差，譬如需要在 APP 表中冗余存储维度属性，针对衍生维度或者计算指标需要做二次计算。此外，开发和运维成本高，譬如针对于不同时间粒度下的同一个指标，数仓需要开发多张 APP 表，指标的生产成本高进而影响数仓的交付效率。

　　指标消费效率低。在传统数仓模式下，基于 APP 表的交付方式很难支撑业务进行灵活的自助分析。在敏捷 BI 模式下，如果业务需要分析某个指标，首先需要在指标管理工具中找到该指标，然后基于指标对应的物理表和计算口径手写 SQL 进行取数验数，不但流程长，而且使用门槛高。

　　指标口径存在一致性问题。由于指标的取数逻辑沉淀在各个数据产品以及数据集中，所以会造成不同数据产品间指标数据的不一致，乃至同一数据产品上不同BI看板间指标数据的不一致。

　　规范执行落地难。由于指标管理游离在指标生产和消费链路之外，导致指标管理的规范执行程度难以评估。其次，指标管理的成本较高，而下游消费指标场景比较单一，导致指标管理的收益不足，进而影响数据BP的录入意愿，从而加重了指标管理执行的难度。

　　03 指标标准化建设

　　1. 整体方案　

　　指标标准化建设的整体目标是打通指标管理、生产、消费的全链路，解决指标口径的一致性问题，提升指标生产消费的效率。整体建设思路和业界的 headless BI 模式类似，核心是将指标从数据生产、消费链路中抽离出来，作为独立的一层，不同的数据产品通过对接同一个指标平台，实现屏蔽指标技术口径，确保指标口径一致性的目的。

　　指标定义标准化建设的整体架构分为三个部分：

　　指标定义标准化：基于指标管理工具，进行指标的标准化定义以及流程管控。

　　指标实现逻辑化：通过逻辑模型隔离指标生产和消费，提升物理模型可复用性，保障指标交付质量。

　　指标消费统一化：基于指标维度的统一查询 DSL，降低下游消费门槛，通过接入统一查询服务，保障指标口径一致性，通过数据虚拟化技术增强 OLAP 的分析能力，提升取数灵活性。

　　2. 解决方案：指标定义标准化　　

　　为了提升指标的语义化表达能力，在基础派生指标之上，引入了计算指标以及复合指标。计算指标和复合指标不需要落表开发。

　　基础指标：对应于物理表上的某个字段。

　　计算指标：基于其他指标四则计算得到。

　　复合指标：基于其他指标复合维度得到。

　　此外，支持四种维度类型：

　　维表维度：对应于一张维表，维表包含唯一的主键以及其他的维度属性，譬如城市维度。

　　枚举维度：用来描述可枚举的 k-v 键值对，譬如业务线维度，key 是业务线 ID，value 是业务线名称。

　　退化维度：某些场景下，一些维度在不同的物理表上有不同的计算逻辑，但代表的是同一个维度。退化维度主要用于解决这种场景。

　　衍生维度：和退化维度类似，区别在于衍生维度的计算逻辑比较通用，可以进行集中化管理。

　　基于四种维度类型可以构建逻辑维度，用于描述维度间的关联关系，通过逻辑维度可以构建数仓的雪花模型。

　　除了对指标维度的定义规范进行标准化之外，还需要对指标维度的录入流程进行标准化。

　　将 DS 提指标需求、数据 BP 录入指标、数据开发交付指标的流程进行线上化。

　　对指标的变更流程进行强管控，当指标口径发生变更时，所有下游指标会自动级联变更，并通知到所有的下游应用。

　　为了规范指标在下游的安全使用，构建了完善的指标权限体系，包括指标权限以及行级权限。指标权限对应于指标的列权限，拥有指标权限才能使用指标。行级权限主要控制指标的数据可见范围，比如某个大区运营只能看到该大区下的指标数据。

　　为了防止平台上录入无用指标导致指标泛滥，需要进行常态化的指标维度治理。

　　在看清方面，构建了从基础指标、时间周期、修饰词到基础指标，基础指标和维度到计算指标和复合指标的全链路血源。

　　在治理措施方面，针对长期未使用的指标维度，会自动进入废弃状态，针对公共的指标维度，支持跨业务板块引用和管理。

　　综上所述，基于指标维度的标准化定义规范以及流程管控，确保指标定义标准化。通过配合常态化的指标维度治理，达到长期的指标定义标准化。

　　3. 解决方案：指标实现逻辑化——逻辑建模　　

　　指标的技术口径是由物理表字段、聚合方式和维度共同决定。在指标实现逻辑化部分，通过抽象出逻辑模型，构建指标维度和物理表字段的映射关系，同时定义指标的聚合方式，从而实现指标的技术口径定义。

　　逻辑模型改变了数仓交付数据、下游消费数据的方式。数仓从原先的交付表变为交付指标，下游从消费表变为消费指标，从而对用户屏蔽指标的技术口径实现。

　　逻辑模型解耦了指标生产和消费。

　　逻辑模型可以适配不同的计算引擎，对用户屏蔽了不同引擎的计算差异。

　　逻辑模型可以适配不同的表粒度，对用户屏蔽 cube 表、groupingsets 表以及普通表在数据存储上的差异。

　　逻辑模型可以适配不同的数仓架构，不仅支持 APP 表的接入，也支持直接接入 DWM 和 DWD 表。

　　逻辑模型可以实现配置即开发。譬如针对同一指标不同时间粒度的情况，数仓只需要开发天粒度的指标，自然周、自然月指标可以基于最近一天指标上卷得到，譬如计算指标和复合指标可以通过实时计算得到，无需落表开发，譬如通过逻辑维度可以自动构建数仓的星形模型和雪花模型。

　　4. 解决方案：指标实现逻辑化——指标质量保障　

　　为了支持同一个指标在不同模型中同时存在，需要保证指标在不同模型间的数据一致性。

　　ETL 阶段：当指标的生产任务变更时，需要产出指标的测试报告后方可准入。同时在 DQC 上配置指标的数据质量规则，用来检测新增分区的产出质量。

　　逻辑模型阶段：在模型发布前，需要针对模型上的指标进行验数，并且需要和线上版本的数据进行比对，以确保模型的正确配置和变更。为了保证指标的一致性，针对模型上的所有指标进行不同模型间的一致性校验，只有数据一致才允许发布到线上。同时，平台会默认监听模型分区的变更，并自动进行系统一致性校验，一旦出现数据不一致的情况则会及时告知用户。

　　平台上的流程规范和监控手段，只是为了帮助用户快速并及时地发现问题，核心需要自上而下的目标牵引，以及对指标质量的高度重视。

　　5. 解决方案：指标实现逻辑化——指标质量保障　　

　　在指标标准化建设前，下游各个数据产品各自维护指标的取数逻辑，导致各个应用间的指标一致性无法得到保障。期望通过构建统一的指标消费体系，解决指标口径的一致性问题。

　　指标消费统一化的整体架构分为三层：

　　最上层是统一的查询入口，提供统一的查询服务，通过 DSL 描述指标维度的查询请求，DSL 包含指标、维度、过滤条件、时间范围四个要素。基于指标维度的查询方式对下游屏蔽了计算口径的实现，由统一的查询服务完成从指标定义到计算口径的转化，主要实现流程如下：

　　（1）构建指标 DAG

　　根据用户的查询请求构建指标查询树，每个节点代表一个指标，节点间的边代表指标间的依赖关系。

　　（2）模型筛选

　　针对每个指标，筛选出满足查询条件的模型列表。主要会进行维度、权限、时间的筛选。维度筛选用来过滤维度不匹配的模型，权限筛选用来过滤不包含鉴权维度的模型，时间筛选用来过滤数据范围不匹配的模型。

　　（3）模型择优

　　模型筛选后，指标和模型间是多对多的关系。针对每个指标，需要进一步确定最优的查询模型，即模型择优，主要采取性能为主，调控为辅的思路。主要包括以下几种策略：

　　周期排序：譬如自然月指标同时存在天模型和月模型中，优先选取月模型，通过减少计算数据量提高查询速度。

　　引擎排序：譬如指标同时存在 Hive 模型和 SR 模型中，优先选取 SR 模型，充分利用 OLAP 引擎的计算能力。

　　粒度排序：譬如指标同时存在 Cube 表模型和普通表模型中, 优先选取 Cube 表模型，通过指标的预计算提高查询速度。

　　效率排序：譬如优先选取能够满足更多指标查询请求的模型，针对同一个模型上的指标进行查询请求的合并，通过减少查询次数提高查询速度。

　　最后支持在模型上配置推荐度，辅助人工进行策略调控。

　　（4）模型查询树

　　模型择优后，确定了每个指标的查询模型。由于不同的指标可能对应同一个模型，需要对同一个模型的指标查询进行合并，将指标查询树转变成模型查询树，模型查询树的每个节点代表一个模型以及可查的指标列表，节点间的边代表模型间的关联关系。

　　（5）生成联邦查询

　　基于模型查询树生成联邦查询 SQL，发送至最下层的数据虚拟化层。

　　数据虚拟化层主要用于执行联邦查询及扩展自定义计算函数。其中，联邦查询 SQL 分为两个部分：

　　引擎 SQL：描述同一模型上所有指标的查询 SQL，不同模型的引擎 SQL 会根据引擎类型发送到不同的数据引擎执行数据查询。

　　MPP SQL：描述不同模型间指标的计算关系，用于汇聚不同模型间的指标并进行二次计算，比如周、月、季、年的上卷，XTD，最近 N 天的上卷以及同环比均值等。

　　数据虚拟化层基于开源的 MPP 实现。通过扩展查询协议，支持联邦查询 SQL 的语义化描述；通过扩展自定义 connector，实现基于聚合下推的联邦查询能力，提升跨源查询的性能；通过扩展自定义计算函数，提升下游取数的灵活性。

　　6. 重塑消费体系　

　　通过指标消费统一化，实现指标的一处定义，全局消费，重塑下游数据产品消费指标的方式。目前已经覆盖滴滴内部绝大部分的数据产品，譬如驾驶舱，BI报表看板、复杂表格和探索分析，以及各种分析工具等，同时也支持各个业务的数据产品接入，未来也会接入实验分析领域的相关产品。

　　7. 收益总结　　

　　（1）标准化管理

　　通过指标维度的标准化定义规范及流程管控，保证了指标维度的标准化管理，为指标的质量保障奠定基础。

　　（2）指标质量保障

　　通过逻辑模型隔离指标生产和消费，基于平台化的监控手段以及自上而下的目标牵引保障指标口径的一致性，为基于指标维度消费奠定基础。

　　（3）指标高效消费

　　基于指标维度的统一查询服务，对下游屏蔽了指标的计算口径。通过逻辑大宽表加数据虚拟化的方案，提升下游取数的灵活性，从而促进指标的高效消费，增强指标维度治理的动力。

　　（4）指标治理

　　指标维度的动态治理，进一步促进指标维度的长期标准化，实现指标标准化价值的正循环，推进了指标标准化建设从「可做可不做——不得不做——愿意做」的过程演变。　　

　　指标标准化建设对于数据体系来说也是意义非凡。

　　（1）生产侧

　　通过逻辑大宽表和数据虚拟化的方案，使得部分指标维度无需落表开发，降低数仓的开发成本，提升数仓的需求交付效率。

　　通过提供系统化的指标质量保障方案，保障指标口径的一致性，降低数仓的运维成本。

　　通过构建完善的指标维度血缘，为数仓治理提供可靠的依据，降低数仓的治理成本。

　　（2）消费侧

　　构建灵活、低门槛、高效的指标应用。基于逻辑大宽表和数据虚拟化的方案，构建可复用的指标池，支撑下游用户进行灵活的自助分析，提升指标消费的效率。基于指标维度的统一查询服务，对所有用户屏蔽指标的计算口径实现，降低指标消费的成本。

　　04 后续规划

　　滴滴指标标准化建设的发展历程总结为三个阶段：探索、拓展和深入。当前处于拓展阶段，未来将走向深入阶段。主要包含以下三个方面：　　

　　（1）打造全生态体系的产品矩阵。

　　打通实验分析领域，保证实验指标和 BI 指标口径的一致性。

　　通过自助分析产品，提供更加灵活的取数方式，为 DS 及运营提效, 提升指标标准化建设的价值感知。

　　探索基于大模型的指标取数方式，进一步降低下游取数的门槛。

　　（2）持续为数据体系提效

　　从指标录入效率和模型构建灵活性等方面，进一步提升指标管理和开发的效率。

　　基于统一的指标监控告警能力，进一步保障指标的交付质量。

　　打通指标生产链路，实现指标生产自动化，进一步降低数仓的开发成本。

　　（3）实时指标标准化

　　指标标准化建设拓展至实时指标体系。实时场景不同于离线场景，对于 QPS 和查询性能有着更高的要求，需要进行更加完善的稳定性建设。