1 什么是数据建模

1.1  基本概念

数据建模其实包含了两个词，一个是「数据模型」，一个是「建」，要理解什么是数据建模，先要理解「数据模型」，然后再了解如何「建」。

数据模型是数据特征的抽象，也是对数据背后业务的抽象表达，属于微观架构，可以用一个公式表示其结构：

数据模型 = 数据组件 + 组件间关系 + 规约

数据组件指各类业务对象或实体，对应到数据模型的图形化表达上，一般是「点」，常见的数据组件有业务对象（如：用户、商家）、表（如：Hive物理表）、指标等；组件间的关系就是多个数据组件之间的各种关系，对应到数据模型的图形化表达上，一般是「边」，常见的组件间的关系有关联关系（如用户与商品之间，商品与商家之间）、泛化关系（如：用户与用户，商家与小程序商家）；规约指各类组件及关系的约束条件，如数据组件的命名约束、关联关系的方向约束、主外键约束等等。

数据组件、组件间关系及规约的不同，形成了不同的数据模型，不同的数据模型，也对应着不同的构建流程，后续针对具体数据模型的时候再展开介绍。

1.2 模型分层

从层级上看，自上而下依次分为：概念模型、逻辑模型、物理模型：

概念模型：是一种面向用户、面向客观世界的模型，用抽象的概念名词来抽象表达业务，按数据模型的结构，概念模型对应的数据组件一般是各类数据实体，如：业务对象（用户、商家、商品...），业务活动（交易、投保、配送...）。一般是具备业务领域知识的架构师构建。

逻辑模型：逻辑模型既面向用户，又面向物理系统，它是在概念模型的基础上，扩展概念的属性实现的，如用户这个概念模型数据组件，扩展性别、年龄、住址等等属性，形成一个表格，逻辑模型的载体可以是一个文档，也可以是一张虚拟表。一般由有一定业务认知的一线研发者构建。

物理模型：物理模型是逻辑模型针对物理系统的适配，主要是根据逻辑模型，基于物理系统的特性进行针对性的适配，如：分库分表、索引、冗余等等，载体一般是物理表（如一张 Hive 表）。一般由专业的数据研发构建。

这三层模型，从用户理解成本上看，依次增加，概念模型对用户最友好，越能跨越组织、角色在大范围进行共识和传播，相反，经过一系列精妙设计后的物理模型，基本只有小范围的技术专家才能理解和使用。

1.3 模型分类

从类型上看，数据模型主要分为两类：静态结构类和动态行为类

静态结构类：主要用于抽象业务的静态结构，一般是业务对象及对象间的关系，如类图：

针对静态结构，按照结构形状，通常分为两类：

星型模型：一般是一个中心实体，围绕中心关联一层多个实体，示意图：

雪花模型：一个中心实体，围绕中心关联多层多个实体，示意图：

动态行为类：主要用于对业务实体动作的抽象描述，如流程图：

不同类别的模型，会在构建和使用上有不同的特性，后续再展开介绍。

1.4 模型表达方式

为了便于理解，数据模型通常面向用户的表达方式是图形化表达，当然物理模型会以各种各种格式表达在物理系统中。针对图形化表达，一般不同的建模方式会有自己的表达语言，更常用的是 UML语言，这里不再赘述。

2. 常见的数据模型

2.1 E-R 模型

E-R 模型诞生于 20 世纪 70 年代，设计支持是针对关系型数据库的建模，比较适合构建三范式的模型，在数仓领域，Inmon 比较推崇此建模方式。从模型结构上看：

从构建流程上看：

2.2 维度模型

维度模型诞生于 20 世纪 90 年代，由 Kimball 引入到数仓领域并形成数仓维度建模的理论体系，比较适合分析领域，从模型结构上看：

从构建流程上看：

2.3 Data-Vault 模型

Data-Vault 模型诞生于 20 世纪 90 年代，由 Dan Linstedt 提出，在xx内部出现的 olp 模型与 Data-Vault 模型类似。Data-Vault 模型个人认为是 E-R 范式模型与维度模型的组合，在概念模型层面，他与 E-R 概念模型基本一致，在逻辑模型上，Data-Vault 抽象一个星型结构的卫星表来构建，便于扩展与物理模型的优化（如快慢数据、冷热数据的分离，作者原文中是想通过卫星表以增加新行的方式解决缓慢变化维表问题，但目前大数据的存储基本都有分区的能力，其实在物理模型层优化的作用不大），从模型结构上看：

从构建流程上看：

2.4 指标模型

指标模型是逻辑层模型，以原子指标、业务限定（也有叫修饰词的）、统计周期、统计粒度对指标进行拆解，从模型结构上看：

从构建流程上看：

各类模型对比：

介绍完各类模型，具体在实践的时候区别是什么该如何选择呢，到底是自顶向下的还是自底向上的：

自顶向下：一般的构建流程先从点（业务对象）开始，然后定义各点之间的关系，是面向对象的建模。如 E-R 模型、Data-Vault 模型。此类模型要求构建者事前就有较高的领域认知，能够较好的对业务领域进行抽象，导致门槛与构建成本较高。一般来说，基于全局视角抽象的模型，更符合第三范式，表达更为简洁和准确，数据冗余也更少，但对应在查询的时候，join 会较多，因此查询性能较差。

自底向上：一般来说自底向上的构建方式从边（业务活动）开始，是面向过程的建模。如维度建模其流程从选择业务过程开始，可以不同业务分布式构建，再按需去定义点（维度）。此类方法门槛和构建成本都较低，但缺点是数据冗余多，在概念模型层面看会显得不够简洁，但在物理模型层面，几乎全是星型模型，join 较少，因此查询性能较好。

各模型对比如下：

三. 为什么要数据建模

3.1 从大数据平台发展阶段看

1. 起步阶段：随着Google那三篇论文的发布， 开启了大数据时代，Hadoop、Spark、Hive 等各类大数据计算引擎开始登场，该阶段主要是解决「能不能」的问题，主要集中在引擎的基础计算存储能力、稳定性、以及围绕引擎的各类工具组件的能力建设。

2. 快速发展阶段：随着引擎基础能力的相对完善，大数据各类应用场景激增，如何基于大数据系统快速实现业务数据化的矛盾开始凸显，这个阶段主要是「快不快」的问题，因此诞生了一站式数据研发平台（如：Dataworks），同时，由于业务场景越来越多，对于引擎的性能、稳定性也提出了更高的要求。

3. 成熟阶段：随着大数据生态的日趋成熟，数据应用场景的深度和广度被极大地拓展，几乎处处都有大数据的需求，人人都是数据研发者，数据量急速膨胀，大数据系统快速熵增，随着而来的各类问题也开始显现，如沟通协作成本上升，导致数据不好找、不敢用，降低了需求吞吐量，导致各种组织摩擦；大量非专业人员的分布式研发，数据口径不一，产出保障困难导致大量数据质量问题；还有各种重复研发导致的成本浪费；还有数据安全合规问题也开始凸显。

4. 突破阶段：随着大数据系统的云上商业化，云原生引擎开始展露头角，同时一大堆名词也应运而生：数据湖、流批一体、实时数仓、DataMesh、逻辑数仓等。

3.2 从客户价值看

当然，不管趋势如何，最终做判断的还是各自场景下的客户价值。我认为数据建模对各类客户的价值影响如下：

1. 针对数据研发者：数据模型是业务的抽象表达，抽象良好的模型可以高度复用，满足已知和未知的数据需求，提高数据研发效率。但数据建模是需要成本的，需要有理解抽象业务的成本，也有构建模型的成本，还有维护保鲜的成本，因此在短期会影响单次研发的耗时，这也是数据建模在数仓推广的最大难点。

2. 针对数据消费者：维护良好的数据模型（特别是概念模型）可以极大的降低数据理解成本，进而降低找数成本，数据模型的有序研发实现，也可以极大的避免数据的二义性。

3. 针对数据治理者：由于找数及二义性问题的改善，可以很大程度上避免数据的重复研发，可以避免重复研发导致的计算存储成本的浪费。

因为数据建模会增加数据研发者的成本，而建模带来的绝大部分收益又不属于数据研发者，因此，针对业务是否要实施数据建模并不能一刀切，主要取决于这几个因素：

1. 业务规模：数据量、协作人数等如果规模较小，则各类管理成本可控，不需要建模

2. 业务阶段：如果业务在快速发展期，不确定性高（模型维护成本高）、对短期效率诉求强（单次研发耗时），则不需要建模

3. 建模能力：只会写 SQL 并不能做好数据建模，需要有一定的业务理解及架构能力，如果团队成员目前不具备此能力，数据建模可能会负担大于收益，不建议实施。

4. 架构文化：长期主义、架构思维，数据建模的效果并不能在短期立竿见影，要实施数据建模，需要有一定的定力。

3.3 为数据技术的创新注入更多可能性

数据模型是现实世界和计算机物理世界的结构化沟通语言，计算机基于数据模型理解了业务之后，可以进行各类场景的自动化、智能化。如：

1. 低代码研发：基于数据模型，配合产品可视化能力，可以实现覆盖度较广的低代码研发能力，如自助分析场景、自动化指标研发场景等。

2. Data Copilot 的关键语料：在大模型时代，高度抽象的、准确的数据模型作为微调及 prompt 的语料，可以极大地提升细分子领域场景下的效果。

3. 自动化计算存储调优：数据模型可以提供丰富的底层引擎无法获取的业务特性，基于这些业务特征，可以智能匹配各类高级计存优化取舍策略，极大地降低数据研发门槛。

4. 流批一体：虽然现在在大部分语法元素上流批已经实现了统一，但因为计算模式不同，实际上任意的流批 SQL 还是无法实现无缝转化，因此，流批一体的起点或许可以先后置到数据模型这一层（而非ODS），基于统一的数据模型，配合低代码及自动物化，可以实现模型—消费层的流批一体。

当然基于专家经验抽象的数据模型并不是唯一路径，或许有一天，基于机器学习产出的人工神经网络，会优于架构师抽象的模型。

四. 建模方式

4.1 逻辑建模

逻辑建模的目标是优化数据二义性、数据理解效率、重复研发导致的成本，常见逻辑模型分为两类：

明细逻辑模型：是对业务语义详细、网站的结构化表达，一般是的模型组件是业务对象和业务过程的明细信息表

指标逻辑模型：是对业务抽象的、局部的表达，一般是汇总性的数据

4.1.1 明细逻辑模型

Kimball 维度建模的产品化实现，是一种自底向上的、分布式的建模方式，通过一致性维度来减少数据的二义性。维度建模因为其构建维护成本、查询性能等多方面的优势，在互联网公司被广泛采纳，这里讲一下关键点：

1. 在结构上，以星型模型为主，但也支持雪花模型的构建，即维度表可以继续关联维度表

2. 关联关系上，引入「角色」，用于事实表不同字段关联同维度表的唯一化标识，如：

3. 分区对齐方式

a.时间对齐：维度表的业务日期分区=事实表业务日期分区，如事实表是 20200101 分区时，自动关联的维度表也是 20200101。

b.最大分区对齐：map_pt(维度表的业务日期分区)=事实表业务日期分区，如事实表是 20200101 分区，当前维度表的最大分区是20200103， 则自动关联的维度表是 20200103。

c.业务日期对齐：运行时指定的业务日期对应的维度表分区=事实表业务日期分区，如事实表是 20200101 分区，当前维度表的最大分区是20200103， 运行时(如补数据)指定的业务日期是20200102，则自动关联的维度表是 20200102。

4. 支持通过桥接表来处理多值维度

5. 支持层级维度表

指标逻辑模型

指标逻辑模型是基于 OneData 的方法论，对指标进行结构化拆解，以构建口径一致、命名标准的企业级指标体系，其基本结构为：

可以看到，指标由一些基础元素组合而成，通过结构化的方式，来标准化定义指标。并且指标与维度模型有较强的关联，可以基于一致性维度将数仓中各类指标进行全局关联。

口径一致性问题

口径一致性问题是指标面临的核心问题，作为数仓核心的产出物，指标口径的一致性直接影响数据驱动决策的质量，现实中有因为不同报表同一指标的口径不同，两个业务方做出相反决策的案例，指标口径一致性严重影响业务对于数仓的信任程度，进而影响业务对数仓的投资。

如何解决口径一致性问题，通常的做法是基于上面指标模型，维护一个指标模型元素（原子指标、统计周期、业务限定、维度）的统一词库，基于此词库进行组装衍生，进而定义出一套标准的指标体系。

4.2 物理建模

物理建模是将逻辑模型翻译成物理引擎的过程，是一个技术实现过程，物理建模主要涉及的点包括：

1. 引擎适配：如数据类型适配，数据格式适配

2. 性能优化：如索引类的（Zorder、Hash Cluster、分区...），架构优化类的（渐进计算、BitMap、分库分表…）

3. 成本取舍：如计算换存储（压缩、极限存储…），存储换计算（维度属性冗余、物化视图…）

4. 易用性：拆分、合并、冗余等等

要做好物理建模，需要对物理引擎有较深入的理解，一些优化过程也比较繁琐，很多也涉及基于实际常见的各维度的权衡取舍，因此，它门槛相对较高，效率也相对较低。

常见的物理建模手段

维度表

事实表

指标(汇总表)

物理建模的优化思路

先看一下传统的逻辑模型->物理模型的建模结构：

一般来说，对于核心的场景，逻辑模型会通过一些文档进行设计保存（但通常也做不到很好的保鲜），大部分情况下，逻辑模型只在研发者脑中一带而过，也有一些场景，直接根据业务需求来映射对应的物理模型。这种方式存在几个问题，在生产端，需要比较专业的研发才能构建出较好的物理模型，而现实中超过 60% 的数据是非专业 ETL 同学产生的，容易在计算存储上带来一些浪费，而这种浪费在现有的治理能力下，是很难治理的；另一方面是缺乏逻辑模型的指引，物理模型的抽象程度往往不够，数据应用层嵌套层级多，容易造成过度的冗余与重复研发。在消费端，广大消费者需要被动理解物理层的语义，给使用造成一定的负担，另外，过度的冗余和重复的资产会导致一个关键词的搜索，出来很多相似的资产，造成选择困难。

因此，要优化物理建模，需要升级物理建模的结构：

这里的关键转变，是以逻辑模型为中心，串联生产与消费，对于生产者，聚焦在业务建模上，主要负责定义逻辑模型的业务语义，当然，在自动物化不完善阶段，也可以提供一定的物化建议；对于消费者，消费语义清晰，干净整洁的逻辑模型。物理建模过程中复杂繁琐的各种优化策略，有系统自动匹配最优策略进行优化。

基于新的结构，核心是赋予逻辑模型一个载体，这个载体可以是逻辑表。

引入逻辑表后，指标的研发消费能力可以上一个台阶，让我们先来看一下上文中提到过不断被造轮子的指标系统结构：引入逻辑表能力后，指标系统的结构可以升级为：

主要的变化有两点，一是针对词库中每一个指标的逻辑组件，可以唯一绑定物理口径，这样不仅统一了逻辑口径，还统一了物理口径。因为每一个逻辑组件都绑定了物理口径，基于模型组合的指标，就能同步自动化生成物理计算任务。而后，针对指标，可以以逻辑为载体，自动聚合出一张汇总逻辑表，供各类消费场景消费。具体实现的能力如下：

1. 【解决】标准化的、统一的指标口径：由于所有的指标都是由词库中的原子组件组装而来，而原子组件唯一绑定了物理口径，因此，只要保障原子组件的物理口径正确，就能极大程度的实现所有指标上下左右口径一致，即使口径是错的，全局也是错的一样。

2. 【解决】指标下钻分析：由于指标是结构化的拼接，很容易从指标路由到原子组件，又从原子组件路由到明细的维度模型中具体的表及口径，因此，针对任意的自动化指标，可以即时还原出明细维度模型，供各类二次分析。如我们看到总支付金额下跌，我们可以还原到明细模型，基于所有关联维度（买家、卖家...）的维度属性（城市、年龄、性别、人群标签...）进行筛选下钻分析。

3. 【解决】通用、便捷的指标消费：由于赋予了指标逻辑表这个载体，在指标消费能力上被极大地扩展了，逻辑表与物理表，在模型上一致（都是表格），只需要在技术上做一定的兼容，就能兼容绝大部分原来物理表的消费能力。

4. 【解决】高效的指标研发：基于上面的结构，在原子组件绑定了物理口径后，就能实现指标的定义即研发，且原子组件（特别是基于一致性维表定义的维度、业务限定）全局复用，具有网络效应，在建设到一定程度后就能满足大部分新增需求，指标研发的效率可以有数量级上的提升。特别是针对一些营销活动、A/B 实验等场景，业务想看一下一次活动或者实验对各类业务指标的影响，往往要反复不断的提看数需求，通过自动化研发，只需要在模型上将活动表、实验分流表与业务的事实表关联（一般是 user_id），定义一次业务限定，点一点鼠标就能立马生成成百上千个、所有与业务事实相关的指标，对效率是极大的提升。

五 总结

自顶向下看，在概念模型上，以数据消费者为第一客户， UML 为模型表达语言，以 Data-Vault 为概念模型的基础进行xx化扩展。

在明细逻辑模型上，以 Kimball 维度建模为理论基础，自下而上开展数据建模研发。在实现上，逻辑模型的组件与概念模型的组件进行关联，以实现概念-逻辑-物理模型间的自动保鲜、自动联想。

在指标逻辑模型上，基于 OneData 的指标建模，构建企业级的指标体系。

最后，以逻辑表为载体实例化逻辑模型，并通过逻辑表的自动物化，降低物理建模的门槛，提高研发效率。

用一张图总结：