背景

数据是现实生活的客观描述，数据仓库的构建已经逐渐成为现代企业业务发展的重要驱动力。作为一个面向主题、集成的、相对稳定的、反应历史变化的集合。如何在复杂的业务场景下，选择合适的数据建模理论完成上述四个特质的反应，并对企业业务发展进行驱动，成为摆在每一个数据从业人员面前的问题。本文梳理了业界已有的数据建模理论知识，并对其的适用场景和优劣势进行简单分析，期望可以对读者有所参考。

数据建模思路

在企业的发展过程中，各个系统、流程都会产出数据，各位系统的组成成分，各位流程的参与人员都会需要消费数据。由于原始数据的产出思路是以满足系统流程的正常运转而产生，而数据消费思路依据消费视角、消费目的的不同往往需要将原始数据进行加工后才能满足需求。消费视角的多样化和基础数据的原始性，将会产生不匹配的情况，数据建模则是最小化数据生产与数据消费的gap，通过规范化的数据建模思路生产出满足多样性消费场景的数据资产。

数据建模思路简要的可以分为两类的数据建模思路：

自下而上的建模思路：由原始数据出发，将原始系统的数据按照业务系统的的关系、业务系统的流程进行数据资产的构建，数据资产以反应业务系统的运转情况为目标；

自上而下的建模思路：由消费场景出发，依据消费场景的的目标，对消费主体整合抽象，进行数据资产的构建，数据资产以满足消费场景、消费主体的诉求为目标；

自下而上的建模思路应用场景

明确的业务流程和产品功能，由工程技术方案出发驱动产生的技术指标。如某特定页面的UV、PV，某业务过程的单向漏斗分析等依托于产品功能的设计逻辑。

自上而下的建模思路应用场景

明确的商业方案分析场景，如分渠道进行数据模块的分析，涉及到多产品、多系统的串联分析等，实现的是商业方案的分析转化。

数据计算技术方案的演进

在数据仓库的发展过程中，数据建模的思路也是在逐步演进进化过程中。 在这个演进过程中，一方面是需求提出了更高的要求，另外一个方面则是数据引擎的不断进步，提供了更高的算力支持。

经典数仓方案

在oracle、sql server等数据库世代，即产生了数据仓库的方案，在此方案下由于数据加工主要为传统的关系型数据库来实现，数据加工和数据存储均受到单一数据库的性能限制，因此在该方案中，往往会出现为了提升性能产生的分库分表乃至分机房的方案，但是相应的也会产生数据一致性同步以及数据备份的困难。

在此阶段的代表性的软件为 kettle、Teradata

离线数仓方案

离线数仓方案特指出来在hadoop数据组件产生后的数据仓库的方案，在此阶段事实表的数据量级已经接近亿，传统的ETL的工具已经没有办法满足性能要求，而HDFS、Hive等工具则可以很好的支持大数据量的存储和计算的问题，但是无法满足数据查询的性能要求问题，这样就会产生使用mysql作为查询引擎的方案

离线的数仓方案则为

数据源  ->  离线数据仓库 -> mysql/olap引擎 -> 数据应用

Lambda架构

随着网络技术的方案的更新和报表实时性要求的产生，使得部分的指标实现实时产出成为可能性，因此开始出现使用流处理技术完成较高实时性指标计算的架构，即称之为lamada架构

lamda架构 即在原始的离线数仓的基础上，新增实时计算的链路，对数据源进行流式的改造，实时来订阅消息队列，完成指标增量部分的计算，并且在数据服务侧进行离线指标和实时指标的合并。

在此过程中，流计算指标仍然为一个近似指标，在每次的批处理计算完成后，将会产生对流处理计算结果的覆盖。Lamada架构实现了实时计算和离线计算的初步融合。但是存在如下的问题

相同的逻辑将会产生一个实时计算结果和一个离线计算结果，两次计算则会产生两份资源消耗；

实时链路和离线计算链路容易让人误解，昨日的数据指标和今日的数据指标不一致。

下游处理结果复杂，需要整合实时和离线的处理结果。

Kappa架构

随着业务的发展，实时指标逐步成为业务需要参考的更重要的指标，实时处理从次要部分变成了主要部分，架构也需要进行相应的调整，出现了以实时时间处理为核心的Kappa架构。该架构的出现得力于Flink的出现，Flink技术使得Excatly-Once 和状态计算成为可能，使得实时计算不再是近似计算而是做到了准确计算。

在Lambda架构下，实时计算逻辑和离线计算逻辑为两套逻辑，且实时计算的结果为离线计算结果的近似值，在Kappa架构中，不再包含有实时计算的部分，需求的需求和历史数据的处理都可以通过上游的重放来完成。

在此架构下，主要问题就是  如何进行历史数据的保存和回放。这是通过选择一个具有重放功能，并且具有保存历史数据并且支持多消费者的消息队列的方式来完成的。

如 kafa：可以保留全部的历史数据；

Pulasr、Parvega 可以专门解决实时输出存储的问题。

当某个 or 某些指标需要重新处理时，则按照一个新逻辑启动一个作业，重新进行数据的加工处理，并且将结果输出到下游一个新的下游表中，当新作业赶上进度后，应用切换数据源，使用新产生的结果表，并且停止老的作业任务，删除老的作业结果表。

在此架构下，会出现流式计算的结果低于批处理的计算结果

数据湖

数据湖不仅可以存储传统类型的数据，还可以存储其他任意类型的数据(文本、图像、音频、视频)，并且是可以对任意的数据类型进行分析和处理。因此不提前定义数据的schema，而是通过将原始数据进行缓存上，在需要消费的时候进行原始数据的解析使用。

数据建模理论的演进

数据仓库的建模理论或者是分层理论是为了更好的进行数据生产、管理、消费的手段。衡量数据建模理论的好坏，可以从以下的几个角度出发

访问性能：快速查询所需的数据，减少IO

数据成本：减少不必要的数据冗余，实现结果数据的复用，降低存储成本和计算成本

使用效率：改善用户的应用体验，提高数据的效率

数据质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

在层次建模的大背景下，在不同的层次可以采用不同的数据建模理论进行数据资产的构建。数据资产的构建，在业内主要的建模理论主要分为以下的几种

数据集市建模：每个应用程序都会产生存储大量的数据，这些数据并不能被其他的应用程序所使用，为了解决信息孤岛的问题，使用数据集市将应用程序产生的数据存储到集中的离线仓库中，而数据集市会受到数据计算资源的限制而不能无限大，因此在发展的后期阶段，还会出现数据集市的分层。

分层建模理论：将数据仓库划分标准的建模层次，根据层次不同选择不同的建模手段，最终整合成统一的数据仓库服务。不同的层次承担不同的职责，并最终形成统一的分层的数仓理论。

维度建模+粒度建模：维度建模是指将业务过程拆分为事实和维度两种，进行建模，该种建模思路便于进行数据的研发

ER实体建模：是将业务过程拆解为实体、属性和关系等相关内容，进行数据建模；

范式建模理论：是由Inmon所提倡的建模理论，主要以关系型数据库的建设理论，将数据关系按照范式进行严格拆分，进行数据仓库的建设。

反范式建模理论：不遵循范式的要求，完全按照消费场景，进行数据资产的构建。

分层建模理论

数据仓库，当前往往会以分层建模作为主流的数据建模理论。在分层建模的理论指导下，数据资产的不同层次具备不同的使用目标：

数据采集层即ODS层：该层次主要目的是采集业务系统的原始数据，通过数据库同步 or 日志采集等相关手段，采集数据ods资产，以客观镜像业务系统的资产作为主要目的；不会进行字段名和字段类型的统一

数据明细层即dwd层：该层次主要目的是进行数据资产的简单清晰，删除掉部分的系统脏数据，最大程度保留原始数据的信息。规范字段的命名，进行数据的一致性规范。

数据汇总层即dws层：该层次主要目的是进行数据资产的汇总加工，生成适合多消费方的，数据资产的统一消费；采用维度模型作为理论基础，采用维度退化的方案，减少维度表和事实表的关联，增强表的易用性。使用宽表的手段构建公共指标的数据层，提升指标的复用性，减少重复加工。

dim维度层：使用抽象的数据事实，建立的统一事实的维度表。维度表通常来说会包含有多个属性、是扁平的规范表，往往会使用反范式的设计逻辑，减少关联更加易用。

tdm标签数据层：从属于一个实体对象的数据建设到统一层次

数据消费层即adm层：该层次的主要目的是进行数据资产的应用加工，直接服务于消费场景使用。

分层建模的优势

数据分层具有其专门的定位，并且在下游消费方在使用对应的表的时候，可以快速的进行表的定位和理解；

数据血缘便于追踪。在分层建模的理论中，数据血缘可以快速定位出问题的表，并进行相应的结果修复;

三个月血缘可以减少资源的浪费和重复开发的工作。

优化加工处理逻辑，简化各个层次数据的权责；

复杂问题简单化，可以使得

ER实体建模

将事务抽象为 实体、属性、关系来描述，这种对数据的抽象建模被称之为实体关系建模。

ER建模是数据库设计的理论基础，所有的OLTP系统设计都会使用ER模型建模的方式。在分层数据建模理论中数仓的dwd层往往会采用ER关系模型来构建。

实体建模的优势

能够清晰的实现业务模型的划分，在业务建模阶段和领域建模阶段，实体建模法将会有广泛的应用。

实体：领域模型中特定的概念主体，指发生业务关系的对象。

关系：概念主体之间完成一次业务流程的过程，特指特定的业务过程。

属性：主要是针对实体和事件的特殊说明。

维度建模

维度建模是以分析决策作为出发点，进行数据模型构建的数据理论。维度建模重点解决的问题是用户如何更好的完成分析需求，并且还具有较好的复杂查询的响应性能。

维度建模的主要倡导者是Kimball，将数据仓库的表划分为事实表和维度表两种类型。维度建模一般是采用星型结构或者雪花结构进行数据建模

星型结构：以一个事实表为中心，周围环绕多个非正规化描述的维度表 。维度表之间是没有关联的，并且维度表是直接关联在事实表上的，只有维表特别大，存储空间存在问题的时候，才会考虑雪花模型。

雪花模式：将维度做进一星型中。

星型模型和雪花模型的主要区分在于对维度表的拆分，对于雪花模型，维度表的设计更加的规范，一般是更加符合3NF的，而对于星型模型而言，一般是使用降维的操作，利用冗余来避免模型过于的复杂，提高易用型和分析效率。

维度模型是非强范式的，可以更好的利用大数据框架的处理能力，避免了范式过多的关操作，并且可以实现高度的并行化。

维度建模是目前数据仓库dws层主流的建模手段。

维度建模的优点

方便使用，并且模型简单；

适合大数据下的处理操作；

维度模型非常的直观，并且可以反应业务问题中，不需要进行特殊的抽象，即可完成维度建模

可拓展：维度模型是可拓展的，由于维度数据存在数据冗余，当向维度表或者事实表中添加字段的时候，不会产生大的改动。

维度建模的缺点

数据冗余，维度补全以后会产生数据存储的浪费；

灵活性差，维度变化大导致数据量的更新量大。

需要进行大量的一致性定义，并且当业务发生变化以后，会需要重新维度数据的预处理。

范式建模理论

范式建模是由Inmon所提倡的建模理论，是采用关系型数据库进行的建模，大致上会采用三范式的手段，解决数据冗余、插入异常或者修改异常等问题。在数据仓库的板块中，主要用于解决数据冗余的问题；

三范式

第一范式：属性值不可再分，在数据资产的关系中，字段值为最小不可分单元。

第二范式：每张表都存在唯一主键，并且其他的列完全依赖主键。表只描述一个事实。

第三范式：表中的字段是直接依赖主键的，并且不依赖其他的字段。

范式建模的优点

解决存储，范式建模减少额外的存储冗余，降低存储成本；

结构清晰且便于理解。

范式建模的缺点

构建复杂，查询复杂

不适合进行灵活查询，

范式建模的应用场景：ODS建模，由于ODS资产是完全镜像线上业务系统，并且线上业务往往是已经遵循三范式的数据产物，三范式建模应用于ODS一方面有助于降低ODS的数据存储压力，另一方面也有助于减少对线上系统表的改造理解成本

反范式建模

对于反范式建模，主要应用的场景主要在指标的解读，快速的标签分析等场景。

反范式建模没有明确的主键、维度以及指标，所有的数据都是呈现高度的非结构化，如json的存储模式，或者如下面的数据存储方式

create table if not exists test_table (

index_code

index_value  )

数据建模实现手段