作者|王鹏新兴小飞数字经济的快速发展给企业经营带来了新的机遇和挑战。如何有效进行数据治理，打破数据孤岛，充分发挥数据的商业价值，保护数据安全，成为业界关注的热点话题。本文基于美团配送数据治理的历史，从数据定义、模型设计、数据生产三个环节，分享统一配送数据“基地”的建设与实践。1前言本文基于美团配送数据治理的历史，着重与大家分享配送数据“基”的建设与实践，如何通过系统化的建模，搭建从数据定义到数据生产的桥梁，实现数据定义、模型设计、数据生产三个环节的统一，消除了因数据标准缺失、执行不到位而导致的数据信任问题，在实现高质量数据到信息的同时，为后续方便的数据消费提供数据和元数据保护转换。希望能为从事数据治理的同学在实现数据转化为资产的过程中提供一些借鉴和参考。2什么是系统建模？系统建模基于维度建模，由事前治理概念驱动，并允许元数据贯穿建模过程。它继承了指标和维度的定义，并连接到实际数据。生产。首先，通过高层模型设计，将业务指标在结构上拆解为原子指标/计算指标+限定条件的组合，并赋值给具体的业务流程和主题，完成业务指标的规划定义；其次，基于高层模型设计，自动生成详细的物理模型设计；第三，基于生成的物理模型设计，半自动或自动生成数据处理逻辑，保证最终业务定义和物理实现的统一。具体如下图1所示：图1系统建模概述从系统建模的定义来看，强调两个统一，即数据需求与模型设计的统一，以及模型设计与物理实现的统一。数据需求与模型设计的统一，模型设计是仓库域划分与具体需求相结合的产物。仓域划分是基于业务本身但超越和脱离业务需求约束的数据抽象，是数据主题和业务流程的抽象，作为业务指标、维度需求归属、高内聚的重要依据和数据构建的低耦合。;具体的需求模型设计是基于仓库字段划分的内容填充，将需求以指标和维度的形式赋值给相应的主题和业务流程，从而驱动和约束具体的详细模型设计和概述有价值的信息架构资产。模型设计与物理实现的统一，基于模型设计过程中沉淀的信息架构元数据，对实际物理模型进行驱动和约束，约束物理模型对应的DDL，防止在设计过程中因缺乏有效约束而导致的问题数据处理。“烟囱式”开发是在模型上线前自动完成业务定义和物理实现的一致性校验，保证DML实现的正确性。3为什么要进行系统建模？前期在配送数据建设中存在需求管理（指标、维度）、模型设计、模型开发分离、不一致的现象。无法有效地管理数据架构规范。（指标、维度、模型设计）与实际物理模型分离、不匹配，导致各种数据资产信息丢失。而且，由于缺乏系统的把握，无法对研发的模型设计质量进行全面标准化，导致部分需求直接开发数据，造成模型构建质量下降的问题。这种因缺乏规范和约束而带来的“烟囱式”发展，在造成数据重复和不可信的同时，浪费了技术资源。配电系统建模的出发点是规范“基础数据建设”，消除“烟囱”开发给业务带来的困扰和技术浪费。3.1系统化建模，有效管理数据结构，从源头杜绝“烟囱式”发展。系统建模不仅可以在工具上实现集成设计和开发，而且可以在机制上形成模型设计、开发和实现的有效协同。以需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与开发实施分离、开发实施缺乏约束而造成的无序和“烟囱式”发展。3.2系统化建模沉淀规范的元数据可以有效消除检索和理解数据时的业务困扰元数据的形式沉淀了对数据资产的描述。每个指标不仅有规范的业务定义和清晰的处理口径，还可以映射到对应的物理表，有效免除业务检索和理解数据的需要。困扰。4如何进行系统化建模实现系统化建模需要从源头入手，将数据规范定义、数据模型设计和ETL开发联系起来，实现“设计就是开发，建造就是你”得到”。总体策略是从源头入手，先解决需求层面的指标定义问题，然后依次约束和驱动模型设计来约束数据处理，将线上业务流程各个环节产生的数据抽象出来，并实现业务规则。数字化完成了“物理世界”的数字孪生，形成了“数字世界”。在工具层面实现基于需求的一体化设计开发，在机制层面形成模型设计与数据开发的有效协同。图2系统建模思路系统建模不仅在工具上实现了基于需求的集成设计和开发，而且在机制上形成了模型设计与数据处理之间的有效协作。首先基于数据仓库规划，将业务指标和维度映射到对应的主题和业务流程，然后基于数据定义标准，对业务指标进行结构化拆解，实现指标的技术定义，完成高-层次模型设计；其次，基于高层模型设计过程中沉淀的元数据，驱动约束最终的物理模型设计，确定后续数据处理的最终DDL，完成物理模型设计，约束后续数据开发。图3系统建模流程4.1高层模型设计一线数据需求以指标和维度的形式提供给数据工程师。数据工程师首先要根据得到的指标需求，确定要分析的业务流程，并完成业务流程。划分定义，同时将指标归于对应的业务流程；其次，根据指标的业务口径，将业务指标拆分为原子指标+限制条件+时间段或计算指标+限制条件+时间段完成指标第三，整合各方分析视角，完成设计业务流程的一致维度，以及业务流程的多个一致维度的设计构成了该主题下的总线矩阵。上述高层模型设计涉及两个环节。首先，通过业务抽象完成领域模型划分。我们根据实际业务流程划分业务流程，按照分析域完成业务流程的归属。在具体的业务下，分析领域和对应的业务流程不会随着分析需求的变化而变化，领域划分也不会随着分析需求的变化而变化。基于这个划分，可以构建一个稳定的资产目录。其次，通过完成业务指标的技术定义并归属到具体业务流程，确定具体业务流程的分析维度，完成逻辑建模。逻辑建模进一步勾勒出特定分析域和业务流程下的具体分析度量和分析维度，完成最终的高层模型设计。高层模型的设计决定了具体的分析域和分析业务流程。物理输出。图4高层模型设计更具体地说，确定业务流程下的分析度量需要完成业务指标的技术定义，并将其归于具体的业务流程。在这一步中，我们从技术角度对业务指标进行了结构化的技术定义，形成了一套结构化的指标体系。一方面，结构化定义易于统一形成标准，避免全文描述造成的理解歧义；另一方面，结构化定义有助于系统保证其一致性，解决了难以通过人为实现来保证一致性的问题。我们的结构化指标方案将指标分为：原子指标、计算指标和派生指标，并对这三类指标做了如下明确的定义：意义。在物理实现上，是业务实体字段加上特定业务流程下的特定聚合算子的组合。计算指标：结合原子指标和限制条件，经过加、减、乘、除四种算术运算得到的指标。计算指标有明确的计算公式作为计算指标的定义，可以结合多种限制条件。对于计算指标的归属，我们遵循两个原则：①由于原子指标可以分配给相应的业务流程，因此业务流程一般有时间顺序，计算指标分配给顺序较低的业务流程；②如果涉及多个业务流程，且这些业务流程没有先后顺序。在这种情况下，需要判断索引描述内容与主体业务流程的相关性，然后归属到相应的业务流程。在物理实现上，计算指标可以直接从它定义的计算公式中自动生成它的实现逻辑。派生指标：由“时间段+多个限定条件+原子指标/计算指标”组成的指标。由于派生指标是从原子指标/计算指标中派生出来的，因此需要将派生指标归属于原子指标/计算指标所属的业务流程。约束条件：约束条件是对指标业务口径的逻辑封装，时间段也可以算作一种特殊的约束条件，必须包含在派生指标中。在物理实现方面，我们将其处理成派生事实的逻辑标签。经过这样的定义，衍生指标明确分为原子衍生指标和计算衍生指标，两者都可以相对容易地定义和半自动地以结构化的方式实现。衍生指标涵盖了用户生成的报表等数据产品的所有指标，而原子指标和计算指标作为指标体系的核心内容，并不直接提供给用户。明确指标的执行情况也很容易。原子指标和计算指标的逻辑尽量下沉到基础事实层，派生指标根据需要在中间层和应用层实现。4.2详细模型设计详细模型设计是将高层模型设计转化为实际实物生产的桥梁。详细的模型设计必须结合数据的生产过程，给出与其分层模型相匹配的实际物理模型。根据数据仓库不同层次之间的职责边界，详细的模型设计呈现出不同的特点。具体来说，需要数据工程师将业务需求与相应逻辑建模产生的DDL结合起来，完成最终物理模型的加工和生产，这是我们详细模型设计的核心。对于中间层的汇总模型，是在详细模型的基础上进行的预计算过程，以提高查询性能。不涉及任务业务口径的处理。只要明确元数据，就可以通过工具实现“TEXT2SQL”，实现配置生产。我们的工程师只需要专注于基础设施层的开发，中间层和应用层的建设交给工具，节省了大量的时间和精力。在展开详细模型设计之前，我们首先介绍数据仓库分层，然后通过数据分层介绍与之匹配的详细模型设计。4.2.1数据仓库层次结构简介按照整个数据生产的流程环节，数据会经历生成、访问、处理、最终消费。数据仓库的建设主要集中在数据的访问和处理上。数据访问包括数据获取和清洗两个过程。通过这个过程，完成了数据从业务系统到仓库的传输，为后续基于分析场景的数据建模提供了原始数据。我们把这个过程产生的数据定义为区数据的准备，这个过程基本上是通过工具自动化的，不需要太多的人为参与和设计。在另一个过程中，为了支持来自用户、报表制作者和其他BI应用程序的查询，我们需要在开放区域为用户提供数据。目前，我们采用维度建模和仓库分层理论，采用星形明细模型+多维汇总模型分离，满足用户固定在线分析，以及随机查询的突发即席分析需求。这个区域是数据工程师整体工作的核心，我们可以利用在线建模中积累的元数据来辅助我们提高数据生产的效率和质量。在数据准备区，我们将数据模型分为基础明细层（B3）和中间汇总层（B2、B1），以支持不同场景的数据需求。图5DataHierarchicalModel4.2.2Metadata-drivendetailedmodeldesignconceptMetadata-drivendetailedmodeldesign是基于高层模型设计产生的逻辑模型，进而驱动约束后续物理模型DDL进行处理.大致分为三步：首先，确定实体模型的名称；二是根据模型归属自动生成基础事实，根据需求确定派生事实，完成事实认定。第三，基于总线矩阵确定模型一致性维度。每个步骤的具体操作内容根据模型所属的仓库层不同而不同。对于中间的summary层，只是在基础模型的基础上多维度rollup。基本模型确定后，可以通过手动拖放简单指标自动生成DDL和DML。比较简单，这里就不展开了。细节。接下来重点描述基础事实层的详细模型设计，如下图所示：图6详细模型设计的第一步是根据模型的来源确定模型名称。在此之后，不仅模型名称标准化，而且在数据生产前自动挂载Assets，方便后续数据的管理和操作；第二步，根据第一步挂载的模型，约束确定模型要生产的事实，即模型中包含的基本事实字段由相应业务流程下的快照表确定，并自动生成基本事实字段。模型中包含的派生事实由相应业务流程下的派生指标所要求的约束条件决定，保证了需求、模型设计和物理实现。通过这个过程，我们约束了实际生产过程中物理模型的任意处理，从源头上消除了“烟囱”开发带来的冗余。元数据约束对应主题应该产生哪些事实，从源头上防止边界不清晰导致的交叉耦合问题，保证最终物理模型的高内聚和低耦合。图7元数据驱动的模型设计从源头上杜绝了烟囱开发。第三步，基于总线矩阵确定物理模型的一致性维度，而不是根据需求增加维度。如果后期因为需求变化频繁调整基础模型，这会导致基础模型复用性差，但是在模型制作之初，一次完成尺寸设计和制作，提高稳定性和复用性该模型。图8使用总线矩阵约束模型，保证模型的可重用性和稳定性产品实现解释完详细模型设计的概念和约束，我们再来看看在具体的产品层面是如何实现的。详细模型设计是基于前一阶段高层模型设计和物理建模的基本原理，采用系统化的方法指导数据工程师按照标准流程完成相应的物理模型设计，并最终输出DDL作为这个链接对象的传递，指导数据工程师完成生产过程中最终的DML编写。该环节除了协助数据工程师完成标准化模型设计外，还通过物理模型完成上下文描述，包括物理表与资产目录的映射关系，物理字段与索引维度的映射关系，提供依据为后续的资产消费环节提供完整的基础元数据。根据实体模型设计的最终交付物，其设计过程主要包括两部分：首先，根据规范和标准确定实体模型的名称；第二，根据规范和标准确定物理模型的数据字典。通过确定构建的物理模型对应的数据仓库级别、主题域和业务流程，自动生成物理表的名称。图9.在详细模型设计中确定物理表的名称和资产所有权。基于高层模型设计过程中确定的分析指标和维度，自动生成物理表对应的数据字典，保证模型设计与最终物理实现的一致性，从源头上杜绝不一致。规范开发。图10详细模型设计，确定物理表的字段信息，完成指标、维度、字段的映射确保实际处理逻辑（模型的DML）与业务定义一致，不存在匹配约束。上线前的卡点是利用高层模型和详细模型设计两个环节产生的元数据，自动化完成DML和业务定义的一致性验证，消除人工验证带来的成本问题。具体的卡点校验包括四种：同一个指标不同来源的数据一致性校验，将不同来源的同一个指标汇总到同一个维度，它们有相同的值；业务定义与具体实现的一致性校验，此类校验主要针对代码值字段，具体值必须与其对应的业务定义一致；研发合规约束类型验证，例如主键必须唯一、全表扫描、代码流分支覆盖（T+1重定向、批量重定向、Fullreload）；变化的级联影响，包括对下游生产任务和消费任务的影响。5小结系统建模是配电数据团队在数据资产建设中围绕“提质降本、提高数据应用效率”的目标孵化的产物。基于工具化标准流程的思想，我们用工具来约束和规范数据工程师的生产，并尝试在事前规范模型的治理，避免重蹈“先建设后治理”的覆辙”处于业务高速发展阶段。在模型质量提升方面，我们实现了高层模型设计和物理模型设计的统一，以及业务定义和物理实现的统一。在效率提升方面，在线建模通过系统化的方式为我们积累了宝贵的元数据。我们后续基于元数据的应用效率提升的关键。①系统化建模搭建了数据定义到生产的桥梁，实现了数据到信息的转化，提供了完整的流程保障，实现了10多个主题、180多个原子指标、300多个计算指标的统一和90多个派生指标。图11数据定义、生产、加工全流程统一在美团内部，涉及配送交易、合同履约等核心议题的规范建设治理得分取得优异成绩，尤其是在指标完整性建设得分和物理模型方面维度完成度得分方面，均取得了90分以上的优异成绩。图12健康主题得分②得益于系统化建模实现的元数据与数据的统一，我们实现了数据建设从“保姆”模式向“服务+自助”模式的转变。在数据检索方面，得益于系统化建模沉淀的优质元数据，我们构建了数据地图，解决了数据“可搜/可得”的问题，实现了在检索内容上所建即所得.图13数据可取在数据消费方面，得益于系统化建模沉淀的优质元数据，我们实现了“服务+自助”的数据服务模式，不仅淘汰了传统报表开发完全依赖关于生产和研究。开发流程长，需求响应慢，覆盖用户少。也解决了“零SQL”即席分析的问题，满足了业务人员“拖拉拉拽”快速生成分析报告的需求。图14按需自由拼装指标获取数据目前，该模型广泛应用于晨报、周报、季报等业务场景中所有“零SQL”数据操作的业务领域。得益于上述模型，不仅得到了一线人员的广泛好评，也让我们的数据RD从“取号”、“跑号”的繁重工作中解脱出来。作者简介王鹏、新星、小飞均来自美团配送事业部数据团队。
