滴滴目的规范化通常

经常出现的目的交付流程如下：

最终交付的目的会被运行到下游的各个数据产品中，比如控制驾驶舱、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 不高。在查问性能方面，未来重点是目的的智能消费、智能物化，优化全体查问效率。