不会体系化建模那数据可视化不就是瞎搞吗？

ciluanlan

　　一、前言
　　本文基于美团配送数据治理的历程，重点和大家分享一下配送数据“底座”的建设与实践。如何通过体系化建模建立起数据定义到数据生产的桥梁，达成数据定义、模型设计、[url=http:///www.esensoft.com]数据可视化[/url]数据可视化数据生产三个环节的统一，消除因数据标准缺失和执行不到位引发的数据信任问题，在高质量地实现数据到信息的转化的同时，为后续的数据便捷消费提供数据和元数据保障。亿信华辰希望能给从事数据治理方向的同学在实现数据到资产的转化过程提供一些参考和借鉴。

　　二、什么是体系化建模
　　体系化建模是以维度建模为理论基础，以事前治理的理念驱动，让元数据贯穿其中的建模流程，上承指标、维度的定义，下接实际的数据生产。首先，通过高层模型设计，将业务指标结构化拆解为原子指标/计算指标+限定条件的组合方式，并将其归属到特定的业务过程和主题下，完成业务指标的计划化定义;其次，基于高层模型设计自动生产详细的物理模型设计;第三，基于产生的物理模型设计，半自动或自动地生成数据加工逻辑，以确保最终的业务定义和物理实现的统一。具体如下图1所示：
　　从对体系化建模的定义来看，它强调了两个统一，即数据需求与模型设计的统一和模型设计与物理实现的统一。
　　数据需求与模型设计的统一，模型设计是仓库领域划分和具体需求相结合的产物。仓库领域划分是对数据进行基于业务本身但超越和脱离业务需求限制的抽象，对数据完成主题、业务过程的抽象，作为业务指标、维度需求归属和实现数据建设高内聚、低耦合的重要依据;具体的需求模型设计，是在仓库领域划分基础上的内容填充，将需求以指标、维度的形式归属到对应的主题与业务过程，以此驱动和约束具体详细模型设计，勾勒出宝贵的信息架构资产。
　　模型设计与物理实现的统一，基于模型设计环节沉淀的信息架构元数据，以此来驱动和约束实际的物理模型，约束对应物理模型的DDL，在数据加工时，防止因缺乏有效约束带来的“烟囱式”开发，是模型上线前，自动完成业务定义与物理实现一致性验证，确保DML实现的正确性。
　　三、为什么要进行体系化建模
　　亿信华辰此前一段时期，配送数据建设存在着需求管理(指标、维度)、模型设计、模型开发相互割裂不统一的现象，数据架构规范无法进行实质、有效的管理，元数据(指标、维度、模型设计)与实际物理模型割裂、不匹配，造成各种数据资产信息缺失。而且由于缺乏系统抓手，无法完全规范研发的模型设计质量，导致部分需求直接进行了数据开发，引起恶化模型建设质量的问题。这种缺乏规范和约束带来的“烟囱式”开发，在浪费技术资源的同时造成数据重复且不可信。配送体系化建模切入点是：以规范“基础数据建设”，消除因“烟囱式”开发给业务带来的困扰和技术上的浪费。
　　1、对数据架构实质有效的管理，从源头消除“烟囱式”开发
　　体系化建模不仅可以在工具上实现一体化设计和开发，而且能在机制上形成模型设计与开发实施的有效协同。以需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与开发实施割裂、开发实施缺少约束带来的无序、“烟囱式”开发。
　　2、沉淀的规范元数据，可以有效消除业务在检索和理解数据时的困扰
　　体系化建模不但将原先割裂的数据规范定义、模型设计以及最终的物理模型实现连接在一起，而且以元数据的形式将数据资产的刻画沉淀了下来，每个指标不仅有规范的业务定义和清晰的加工口径，而且还可以映射到对应的物理表上，有效地消除了业务在检索和理解数据时的困扰。
　　四、如何进行体系化建模
　　实现体系化建模要从源头开始，将数据规范定义、数据模型设计和ETL开发链接在一起，以实现“设计即开发，所建即所得”。整体策略是从源头开始，先在需求层面解决指标定义的问题，然后依次约束和驱动模型设计进而约束数据加工，将产生于线上业务流程各环节的数据进行领域化抽象，并实现业务规则的数字化，完成“物理世界”的数字孪生，形成“数字世界”。在工具层面实现基于需求的一体化设计和开发，在机制上形成模型设计与数据开发的有效协同。
　　图2 体系化建模思路
　　体系化建模不仅在工具上基于需求实现一体化设计和开发，而且在机制上形成模型设计与数据加工的有效协同。首先，基于数仓规划，将业务提的指标、维度映射到对应的主题、业务过程，然后基于数据定义标准，对业务指标进行结构化拆解，实现指标的技术定义，完成高层模型设计;其次，基于高层模型设计环节沉淀的元数据，驱动和约束最终的物理模型设计，为后续的数据加工确定最终的DDL，完成物理模型设计，以此来约束后续的数据开发。