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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上就是本次分享的内容，谢谢大家。

Q1：是否支持同一请求里查询不同模型？不同引擎查询速度不同，多个结果要出来一起再给出，中间是否有超时处理?

A1：支持在一次请求里查询不同的模型，按照公共维度关联。针对不同模型查询速度存在差异的情况，推荐用 join 性能较好的 StarRocks，当前方案不做中间存储，在 MPP 层并行处理。

针对查询速度做过一系列的性能优化，譬如在统一查询层实现了查询缓存，在数据虚拟化层实现了聚合下推、字段裁剪等，未来考虑实现查询预热、自动物化等性能优化手段，譬如针对 Hive 模型进行预计算和加速。

指标管理的成本较高，指标录入和开发的效率提升是未来的核心方向之一，主要是通过提供指标的批量录入和变更，以及自动化构建模型等能力。

Q2：针对指标调用，上游的数据产品准入策略是什么？

A2：指标主要服务于数据产品，没有应用到线上。数据产品包括BI报表、驾驶舱、各种分析工具等，离线指标整体的 QPS 不高。在查询性能方面，未来重点是指标的自动生产、自动物化，提升整体查询效率。