不会体系化建模，那数据治理不就是乱来吗？
发布时间：2022-03-15 07:33:53 所属栏目：大数据 来源：互联网
导读：本文基于美团配送数据治理的历程，重点和大家分享一下配送数据底座的建设与实践。如何通过体系化建模建立起数据定义到数据生产的桥梁，达成数据定义、模型设计、数据生产三个环节的统一，消除因数据标准缺失和执行不到位引发的数据信任问题，在高质量地实
|
本文基于美团配送数据治理的历程，重点和大家分享一下配送数据“底座”的建设与实践。如何通过体系化建模建立起数据定义到数据生产的桥梁，达成数据定义、模型设计、数据生产三个环节的统一，消除因数据标准缺失和执行不到位引发的数据信任问题，在高质量地实现数据到信息的转化的同时，为后续的数据便捷消费提供数据和元数据保障。希望能给从事数据治理方向的同学在实现数据到资产的转化过程提供一些参考和借鉴。 什么是体系化建模 体系化建模是以维度建模为理论基础，以事前治理的理念驱动，让元数据贯穿其中的建模流程，上承指标、维度的定义，下接实际的数据生产。首先，通过高层模型设计，将业务指标结构化拆解为原子指标/计算指标+限定条件的组合方式，并将其归属到特定的业务过程和主题下，完成业务指标的计划化定义;其次，基于高层模型设计自动生产详细的物理模型设计;第三，基于产生的物理模型设计，半自动或自动地生成数据加工逻辑，以确保最终的业务定义和物理实现的统一。具体如下图1所示： 数据需求与模型设计的统一，模型设计是仓库领域划分和具体需求相结合的产物。仓库领域划分是对数据进行基于业务本身但超越和脱离业务需求限制的抽象，对数据完成主题、业务过程的抽象，作为业务指标、维度需求归属和实现数据建设高内聚、低耦合的重要依据;具体的需求模型设计，是在仓库领域划分基础上的内容填充，将需求以指标、维度的形式归属到对应的主题与业务过程，以此驱动和约束具体详细模型设计，勾勒出宝贵的信息架构资产。 模型设计与物理实现的统一，基于模型设计环节沉淀的信息架构元数据，以此来驱动和约束实际的物理模型，约束对应物理模型的DDL，在数据加工时，防止因缺乏有效约束带来的“烟囱式”开发，是模型上线前，自动完成业务定义与物理实现一致性验证，确保DML实现的正确性。 为什么要进行体系化建模 此前一段时期，配送数据建设存在着需求管理(指标、维度)、模型设计、模型开发相互割裂不统一的现象，数据架构规范无法进行实质、有效的管理，元数据(指标、维度、模型设计)与实际物理模型割裂、不匹配，造成各种数据资产信息缺失。而且由于缺乏系统抓手，无法完全规范研发的模型设计质量，导致部分需求直接进行了数据开发，引起恶化模型建设质量的问题。这种缺乏规范和约束带来的“烟囱式”开发，在浪费技术资源的同时造成数据重复且不可信。配送体系化建模切入点是：以规范“基础数据建设”，消除因“烟囱式”开发给业务带来的困扰和技术上的浪费。 1、对数据架构实质有效的管理，从源头消除“烟囱式”开发 体系化建模不仅可以在工具上实现一体化设计和开发，而且能在机制上形成模型设计与开发实施的有效协同。以需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与开发实施割裂、开发实施缺少约束带来的无序、“烟囱式”开发。 2、沉淀的规范元数据，可以有效消除业务在检索和理解数据时的困扰 体系化建模不但将原先割裂的数据规范定义、模型设计以及最终的物理模型实现连接在一起，而且以元数据的形式将数据资产的刻画沉淀了下来，每个指标不仅有规范的业务定义和清晰的加工口径，而且还可以映射到对应的物理表上，有效地消除了业务在检索和理解数据时的困扰。 如何进行体系化建模 实现体系化建模要从源头开始，将数据规范定义、数据模型设计和ETL开发链接在一起，以实现“设计即开发，所建即所得”。整体策略是从源头开始，先在需求层面解决指标定义的问题，然后依次约束和驱动模型设计进而约束数据加工，将产生于线上业务流程各环节的数据进行领域化抽象，并实现业务规则的数字化，完成“物理世界”的数字孪生，形成“数字世界”。在工具层面实现基于需求的一体化设计和开发，在机制上形成模型设计与数据开发的有效协同。 1、高层模型设计 一线的数据需求都是以指标和维度的形式提给数据工程师的，数据工程师首先要根据拿到的指标需求确定要分析的业务过程，完成业务过程的划分和定义，同时将指标归属到对应的业务过程下;其次，根据指标的业务口径，将业务指标拆分成原子指标+限定条件+时间周期或计算指标+限定条件+时间周期形式，完成指标的技术定义;第三，综合各方分析视角，完成该业务过程一致维度的设计，多个业务过程一致性维度的设计构成该主题下的总线矩阵。 上述高层模型设计，涉及两个环节。 第一，通过业务抽象完成领域模型划分，我们基于业务的实际流程来划分业务过程，并按照分析领域完成业务过程的归属。在特定的业务下，分析领域和对应的业务流程不会随着分析需求的变化而变化，领域划分也不会随着分析需求的变化而变化，可以基于此划分，构建稳定的资产目录。 第二，通过完成业务指标的技术定义并将其归属到特定的业务过程下，以及确定特定业务过程的分析维度完成逻辑建模。逻辑建模进一步勾勒出了在特定的分析领域和业务过程下，具体的分析度量和分析维度，完成最终的高层模型设计，高层模型的设计决定了在特定的分析域和分析业务过程下的具体物理产出。 2、详细模型设计 详细模型设计是将高层模型设计转化为实际物理生产的桥梁，详细模型设计必须结合数据的生产流程，给出与其分层模型相匹配的实际物理模型。根据数仓不同分层间的职责边界，详细模型设计又呈现出不同特点。 具体说来，需要数据工程师结合业务需求，对应的逻辑建模产出的DDL完成最终物理模型的加工生产，这是我们详细模型设计的核心。对于中间层汇总模型，是为提高查询性能，基于明细模型进行预计算的过程，不涉及任务业务口径的加工，只要元数据定义清晰，完全可以通过工具实现“TEXT2SQL”进而实现配置化生产。我们的工程师只需要关注基建层的开发，中间和应用层建设交给工具完成，节省了大量的时间和精力。在展开详细模型设计之前，我们先介绍一下数仓分层，然后通过数据分层来介绍与之匹配的详细模型设计。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号