共计 6885 个字符，预计需要花费 18 分钟才能阅读完成。
数字经济的疾速倒退，给企业的经营带来了新的时机和挑战，如何无效发展数据治理，突破数据孤岛，充分发挥数据的业务价值，爱护数据安全，已成为业界的热门话题。本文基于美团配送数据治理的历程，分享了数据定义、模型设计、数据生产三环节对立的配送数据“底座”的建设与实际。
1 前言
随着数字经济的疾速倒退，数据曾经成为新的生产因素。如何无效地发展数据治理工作，晋升数据品质，突破数据孤岛，充分发挥数据的业务价值，已成为业界的热门话题。本文基于美团配送数据治理的历程，重点和大家分享一下配送数据“底座”的建设与实际，如何通过体系化建模建设起数据定义到数据生产的桥梁，达成数据定义、模型设计、数据生产三个环节的对立，打消因数据规范缺失和执行不到位引发的数据信赖问题，在高质量地实现数据到信息的转化的同时，为后续的数据便捷生产提供数据和元数据保障。心愿能给从事数据治理方向的同学在实现数据到资产的转化过程提供一些参考和借鉴。
2 什么是体系化建模
体系化建模是以维度建模为实践根底，以事先治理的理念驱动，让元数据贯通其中的建模流程，上承指标、维度的定义，下接理论的数据生产。首先，通过高层模型设计，将业务指标结构化拆解为原子指标 / 计算指标 + 限定条件的组合形式，并将其归属到特定的业务过程和主题下，实现业务指标的打算化定义；其次，基于高层模型设计自动生产具体的物理模型设计；第三，基于产生的物理模型设计，半自动或主动地生成数据加工逻辑，以确保最终的业务定义和物理实现的对立。具体如下图所示：
从对体系化建模的定义来看，它强调了两个对立，即数据需要与模型设计的对立和模型设计与物理实现的对立。
数据需要与模型设计的对立 ，模型设计是仓库畛域划分和具体需要相结合的产物。仓库畛域划分是对数据进行基于业务自身但超过和脱离业务需要限度的形象，对数据实现主题、业务过程的形象，作为业务指标、维度需要归属和实现数据建设高内聚、低耦合的重要依据；具体的需要模型设计，是在仓库畛域划分根底上的内容填充，将需要以指标、维度的模式归属到对应的主题与业务过程，以此驱动和束缚具体具体模型设计，勾画出贵重的信息架构资产。
模型设计与物理实现的对立 ，基于模型设计环节积淀的信息架构元数据，以此来驱动和束缚理论的物理模型，束缚对应物理模型的 DDL，在数据加工时，避免因不足无效束缚带来的“烟囱式”开发，是模型上线前，主动实现业务定义与物理实现一致性验证，确保 DML 实现的正确性。
3 为什么要进行体系化建模
此前一段期间，配送数据建设存在着需要治理（指标、维度）、模型设计、模型开发互相割裂不对立的景象，数据架构标准无奈进行本质、无效的治理，元数据（指标、维度、模型设计）与理论物理模型割裂、不匹配，造成各种数据资产信息缺失。而且因为不足零碎抓手，无奈齐全标准研发的模型设计品质，导致局部需要间接进行了数据开发，引起好转模型建设品质的问题。这种不足标准和束缚带来的“烟囱式”开发，在节约技术资源的同时造成数据反复且不可信。配送体系化建模切入点是：以标准“根底数据建设”，打消因“烟囱式”开发给业务带来的困扰和技术上的节约。
3.1 体系化建模能够对数据架构进行本质无效的治理，从源头打消“烟囱式”开发
体系化建模不仅能够在工具上实现一体化设计和开发，而且能在机制上造成模型设计与开发施行的无效协同。以需要驱动模型设计，以模型设计驱动和束缚开发施行，避免因模型设计与开发施行割裂、开发施行短少束缚带来的无序、“烟囱式”开发。
3.2 体系化建模积淀的标准元数据，能够无效打消业务在检索和了解数据时的困扰
体系化建模岂但将原先割裂的数据标准定义、模型设计以及最终的物理模型实现连贯在一起，而且以元数据的模式将数据资产的刻画积淀了下来，每个指标不仅有标准的业务定义和清晰的加工口径，而且还能够映射到对应的物理表上，无效地打消了业务在检索和了解数据时的困扰。
4 如何进行体系化建模
实现体系化建模要从源头开始，将数据标准定义、数据模型设计和 ETL 开发链接在一起，以实现“设计即开发，所建即所得”。整体策略是从源头开始，先在需要层面解决指标定义的问题，而后顺次束缚和驱动模型设计进而束缚数据加工，将产生于线上业务流程各环节的数据进行畛域化形象，并实现业务规定的数字化，实现“物理世界”的数字孪生，造成“数字世界”。在工具层面实现基于需要的一体化设计和开发，在机制上造成模型设计与数据开发的无效协同。
体系化建模不仅在工具上基于需要实现一体化设计和开发，而且在机制上造成模型设计与数据加工的无效协同。首先，基于数仓布局，将业务提的指标、维度映射到对应的主题、业务过程，而后基于数据定义规范，对业务指标进行结构化拆解，实现指标的技术定义，实现高层模型设计；其次，基于高层模型设计环节积淀的元数据，驱动和束缚最终的物理模型设计，为后续的数据加工确定最终的 DDL，实现物理模型设计，以此来束缚后续的数据开发。
4.1 高层模型设计
一线的数据需要都是以指标和维度的模式提给数据工程师的，数据工程师首先要依据拿到的指标需要确定要剖析的业务过程，实现业务过程的划分和定义，同时将指标归属到对应的业务过程下；其次，依据指标的业务口径，将业务指标拆分成原子指标 + 限定条件 + 工夫周期或计算指标 + 限定条件 + 工夫周期模式，实现指标的技术定义；第三，综合各方剖析视角，实现该业务过程统一维度的设计，多个业务过程一致性维度的设计形成该主题下的总线矩阵。
上述高层模型设计，波及两个环节。第一，通过业务形象实现畛域模型划分，咱们基于业务的理论流程来划分业务过程，并依照剖析畛域实现业务过程的归属。在特定的业务下，剖析畛域和对应的业务流程不会随着剖析需要的变动而变动，畛域划分也不会随着剖析需要的变动而变动，能够基于此划分，构建稳固的资产目录。第二，通过实现业务指标的技术定义并将其归属到特定的业务过程下，以及确定特定业务过程的剖析维度实现逻辑建模。逻辑建模进一步勾画出了在特定的剖析畛域和业务过程下，具体的剖析度量和剖析维度，实现最终的高层模型设计，高层模型的设计决定了在特定的剖析域和剖析业务过程下的具体物理产出。
更具体的讲，确定业务过程下的剖析度量须要实现业务指标的技术定义，并将其归属到特定的业务过程下。在这一步中，咱们从技术角度对业务指标产出了结构化的技术定义，造成了一套结构化指标体系。一方面结构化定义容易对立并造成规范，防止全文字描述带来了解上的歧义，另一方面结构化的定义有助于零碎来保障其一致性，解决靠人工来保障一致性难以施行的难题。咱们的结构化指标计划将指标分为：原子指标、计算指标和衍生指标，并针对这三类指标做了如下明确的定义：
- 原子指标 ：指在某一业务过程下不可再拆分的指标，具备明确业务含意的名词。在物理实现上，它是特定业务过程下业务实体字段加特定聚合算子的组合。
- 计算指标 ：由原子指标与限定条件组合并通过加减乘除四则运算失去的指标。计算指标有明确的计算公式作为计算指标的定义，能够与多个限定条件进行组合。对于计算指标的归属，咱们遵循 2 个准则①因为原子指标都能归属到相应的业务过程，业务过程一般来说都有工夫前后程序，将计算指标归属到程序靠后的业务过程中；②如果波及到多个业务过程，同时这些业务过程没有工夫的先后顺序，这种状况下须要判断指标形容内容与主题业务过程的相关性，而后再归属到对应的业务过程。在物理实现上，计算指标能够由其定义的计算公式间接主动的生成其实现逻辑。
- 衍生指标 ：由“工夫周期 + 多个限定条件 + 原子指标 / 计算指标”组成的指标。因为衍生指标是由原子指标 / 计算指标衍生进去的，所以衍生指标须要归属到原子指标 / 计算指标所属的业务过程。
- 限定条件 ：限定条件是指标业务口径的一个逻辑封装，工夫周期也能够算作一类非凡的限定条件，是衍生指标必须蕴含的。在物理实现上咱们将其加工成衍生事实的一个逻辑标签。
在这样的定义后，衍生指标便清晰地分为原子衍生指标和计算衍生指标两类，都能够比拟容易地通过结构化的形式半自动生成定义和实现。衍生指标笼罩了用户生成报表等数据产品的所有指标，而原子指标和计算指标作为指标体系的核心内容不间接提供给用户应用。在指标的实现形式上也容易明确，原子指标和计算指标的逻辑尽量下沉在根底事实层中，而衍生指标在中间层和应用层依据需要实现。
4.2 具体模型设计
具体模型设计是将高层模型设计转化为理论物理生产的桥梁，具体模型设计必须联合数据的生产流程，给出与其分层模型相匹配的理论物理模型。依据数仓不同分层间的职责边界，具体模型设计又呈现出不同特点。
具体说来，须要数据工程师联合业务需要，对应的逻辑建模产出的 DDL 实现最终物理模型的加工生产，这是咱们具体模型设计的外围，对于中间层汇总模型，是为进步查问性能，基于明细模型进行预计算的过程，不波及工作业务口径的加工，只有元数据定义清晰，齐全能够通过工具实现“TEXT2SQL”进而实现配置化生产。咱们的工程师只须要关注基建层的开发，两头和应用层建设交给工具实现，节俭了大量的工夫和精力。在开展具体模型设计之前，咱们先介绍一下数仓分层，而后通过数据分层来介绍与之匹配的具体模型设计。
4.2.1 数仓分层简介
依照整个数据生产的流转链路看，数据会经验产生、接入、加工到最初的生产，数仓的建设次要集中在数据的接入和加工环节。数据的接入蕴含数据的获取和荡涤两个过程，通过该过程实现了数据从业务零碎到仓库的流转，为后续基于剖析场景的数据建模提供了原始数据，咱们将该过程产生的数据定义为筹备区数据，该过程根本通过工具实现了自动化，不须要太多的人为参加和设计。
另一过程，为了反对用户、报表制作者以及其余 BI 利用的查问，咱们须要为用户提供开放区数据，目前采取维度建模和仓库分层实践，通过星型明细模型 + 多维汇总模型的形式别离满足用户固定的在线剖析，以及无奈预期的、随便查问的即席剖析诉求。该区域是数据工程师整体工作的外围，能够利用在线建模积淀的元数据，辅助咱们实现数据生产的提效和提质。在数据筹备区，咱们将数据模型分为根底明细层（B3）、两头汇总层（B2、B1）来撑持不同场景的数据需要。
4.2.2 元数据驱动的具体模型设计
设计理念
元数据驱动的具体模型设计，是基于高层模型设计产出的逻辑模型，进而来驱动和束缚后续要加工的物理模型 DDL，大抵分成三步：第一，确定物理模型名称；第二，基于模型归属主动生成根底事实，基于需要确定衍生事实，实现事实确定；第三，基于总线矩阵，确定模型一致性维度。
每一步具体操作的内容因模型所属的仓库分层不同而有所区别。对于两头汇总层而言，只是在根底模型根底上的多维上卷，根底模型确定当前，人工通过简略的指标拖拽，就能够自动生产 DDL 而且能够自动生产 DML，绝对较简略，在此不做详述。接下来，咱们重点形容一下根底事实层的具体模型设计，具体如下图所示：
第一步，依据模型的出处确定模型名称，通过此处，不仅标准了模型命名，而且在数据生产前主动实现了资产挂载，不便了后续数据的治理和经营；第二步，依据第一步的模型挂载，束缚并确定该模型要生产的事实，即该模型所蕴含的根底事实字段由对应业务过程下的快照表决定，自动生产根底事实字段，该模型所蕴含的衍生事实由由对应业务过程下的衍生指标所需的限定条件决定，确保了需要、模型设计、物理实现三者的对立。
通过该过程，咱们束缚了理论生产环节物理模型的随便加工，从源头打消了“烟囱式”开发带来的冗余。通过元数据束缚了对应主题应该生产哪些事实，从源头避免了边界不清带来的交叉耦合问题，保障了最终物理模型的高内聚、低耦合。
第三步，基于总线矩阵确定物理模型的一致性维度，不是基于需要来增加维度，前期如果因需要变动而频繁调整根底模型，这样会导致根底模型复用性差，而是在模型生产之初，一次性实现维度的设计和生产，以晋升模型的稳定性和复用性。
产品实现
在论述了具体模型设计的理念和束缚后，咱们再具体看一下在具体产品层面是如何实现的。具体模型设计就是基于上一阶段的高层模型设计和物理建模的根本准则，采纳系统化的形式疏导数据工程师依照规范的流程实现对应的物理模型设计，以最终产出的 DDL 作为该环节的交付物，领导数据工程师在生产环节，实现最终的 DML 编写。
这个环节除了辅助数据工程师实现规范化的模型设计外，还通过物理模型齐备了上下文形容，包含实现了物理表与资产目录的映射关系、物理字段与指标维度的映射关系，为后续资产生产环节提供了齐备的根底元数据。依照物理模型设计最终的交付物来看，它的设计流程次要包含两局部：第一，依照标准和规范，确定物理模型的名称；第二，依照标准和规范，确定物理模型的数据字典。
- 通过确定所建物理模型对应的数仓层级、主题域和业务过程，主动生成该物理表的名称。
- 基于高层模型设计环节确定的剖析度量和维度，主动生成物理表对应的数据字典，确保模型设计与最终物理落地的一致性，从源头杜绝不标准的开发。
4.3 上线前卡点
高层模型设计和具体模型设计束缚和标准了数据工程师如何确定一个模型的 DDL，对于如何束缚和保障理论的加工逻辑（模型的 DML）和业务定义保持一致，并没有与之匹配的束缚卡点。上线前卡点就是利用高层模型和具体模型设计这两个环节产生的元数据，通过自动化的形式来实现 DML 与业务定义的一致性验证，打消人工验证带来的老本问题。具体卡点验证包含四类：
- 雷同指标不同出处的数据一致性验证，将来自不同出处的雷同指标上卷到雷同维度，它们具备雷同的数值；
- 业务定义与具体实现的一致性验证，此类验证次要针对码值类字段，具体数值必须与其对应的业务定义统一；
- 研发合规的束缚类验证，例如，主键必须惟一、全表扫描、代码流程分支笼罩（T+ 1 重导、批量重导、全量重导）；
- 变更时的级联影响，包含上游的生产工作影响和生产工作影响。
5 总结
体系化建模是配送数据团队围绕着数据资产化建设“提质降本和数据利用提效”这一指标孵化的产物，本着将规范流程工具化的思路，咱们通过工具来束缚和标准数据工程师的生产，力求将模型的规范化治理做到事先，防止重蹈业务疾速倒退阶段“先建设后治理”的覆辙。在模型提质方面，咱们实现了高层模型设计、物理模型设计的对立以及业务定义与物理实现的对立，而且在提效方面，在线建模通过零碎的形式为咱们积淀了贵重的元数据，是咱们后续基于元数据进行利用提效的要害。
① 体系化建模，搭建起了数据定义到生产的桥梁，实现数据到信息的转化，提供了齐备的流程保障，并在配送外部实现了波及 10 多个主题、180 多个原子指标、300 多个计算指标和 90 多个衍生指标的对立。
在美团外部，波及配送交易、履约等外围主题的规范性建设方面治理评分均获得了优良的问题，特地是在指标完整性建设得分和物理模型维度完整性得分方面，均获得 90 分以上优良问题。
② 得益于体系化建模实现的元数据和数据的对立，咱们实现了数据建设从“保姆”模式到“服务 + 自助”模式的转变。
在数据检索方面，得益于体系化建模积淀的高质量元数据，咱们构建了数据地图，解决了数据“可搜寻 / 可获取”问题，并在检索内容方面实现了所建即所得。
在数据生产方面，得益于体系化建模积淀的高质量元数据，咱们实现了“服务 + 自助”的数据服务模式，不仅打消了传统报表开发齐全依赖产研带来的开发流程长、需要响应慢、笼罩用户少等问题，而且解决了无奈“零 SQL”即席剖析的难题，满足了业务人员通过“拖、拉、拽”即可疾速产生剖析报告的诉求。
目前，该模式广泛应用于所有业务大区”零 SQL“数据经营人员早报、周报、季度述职等业务场景，得益于上述模式，不仅失去了一线人员宽泛好评，而且也将咱们的数据 RD 从“取数”、“跑数”的沉重工作中解脱进去。
作者简介
王鹏、新兴、晓飞，均来自配送事业部数据团队。
团队简介
配送数据组负责基于美团配送业务千万级订单、百万级商家和骑手产生的海量数据的实时和离线数据计算体系和产品体系的建设，为业务实现平安、效率和体验的外围指标，为新一代智能即时配送零碎——「美团超脑」建设数字化、智能化的零碎能力，提供数据撑持，为业务的经营治理、策略决策和算法策略提供欠缺的数据体系和基于数据迷信的决策能力。作为美团万物到家的根底，美团配送领有最丰盛的实时计算和离线计算场景，利用业界最先进的数据计算技术架构，建设保障数据及时性、一致性、准确性、完整性，保障数据计算和服务的稳定性的技术能力。欢送你的退出，跟美团配送数据团队一起打造业界当先的数据撑持平台。
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。