数据仓库建模全解

傅一平评语：

本文分两部分，第一部分通俗易懂的讲清楚了建模的理论，回答了很多关键问题，包括：

1、什么是模型？

2、什么是数据模型? 3、通用的数据建模流程

4、主要的数据建模方法

第二部分讲了建模的实践，干货很多，很有借鉴意义，包括：

1、理论联系实践的数仓建模方法探索

2、作者采用的数据建模方法和流程

推荐大家读一读。

      第一部分

      1 前言

      大家好，本篇文章是数仓详细介绍系列的第四篇。

      第一篇是简单介绍，后三篇属于数仓设计部分：

      数仓概述，这一篇我给大家简单介绍了数据仓库的基本概念和大致构建过程，没有过多深入主要是给大家有个基本的了解。

      数仓架构，这部分确定了数据仓库的结构和边界，我们从四个不同视角给大家带来了相对全面的宏观认识，当然还差一个部署架构。

      数仓规范，则是对数据管理的全流程进行约束，以保证数据管理工作的有序、高效、高质量的开展。上篇是心法，我们简单阐述了规范的重大意义以及设计和落地方法论。下篇是招式，我们从四个不同方向给大家呈现了一幅完整规范范本，给大家参考。

      数据模型，可以说是数据仓库的基石，承载着数据存储的重要职能。上篇我们主要介绍数据建模理论，我们先不对数仓建模做太多介绍，而是从更大的视角去阐述。下篇我们主要介绍真实数仓建设场景下的数据建模实践。

由于数仓建模的重要性，数据仓库的文章都会用绝大多数篇幅来讲解，当然主要还是维度建模，我一开始也认为自己会在这一章讲讲三范式，讲讲维度建模然后就完了，由于大家都已经讲的很好了，甚至我都打算直接转载了。

后来由于一些其它原因，我在七月份做了一次公开课《数据仓库的前世今生》，八月份又翻阅了一些 DAMA2.0 的内容。突然意识到数据建模并不等于数仓建模，事实上数仓建模仅仅是数据建模的其中一个分支，在范式建模和维度建模之外也还有几个别的建模方法，只是数仓建模很少用到罢了。

既然这篇是数据建模的理论篇，那么我们何不跳出数仓建模，从更大的视角展开来阐述呢？

      2 什么是模型？

      说到模型，还有另外一个比较容易搞混的概念：什么是模式?

      从字面的意思理解，“模”一种标准，或者一种套路，“式”方式，方法，形式 。两个字连接在一起就可以解释为，一种可以重复使用，具有参考性的方法、知识体系。

      在互动百科中定义为：

      模式是指从生产经验和生活经验中经过抽象和升华提炼出来的核心知识体系。模式（Pattern）其实就是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度，那就是模式。模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。

      实际中有些人会把模式误认为模型，大家可以参考以上定义去做识别。

      好了， 我们接下来回归正题，既然我们聊建模，那么什么是模型？

      现实中我们经常听到各种各样的模型，比如数学模型、算法模型、数据模型、概念模型、内存模型、领域模型、编程模型、行业研究模型。。。哈哈，是不是很乱！反正我是有点晕了，不过能跟模型联系上的总能给人一种高大上的感觉。

      模型（model）是对现实客观事物的一种表示和抽象，它可以是文字、图表、公式，也可以是计算机程序或其他实体模型。可以说，模型是把对象实体通过适当的过滤，用适当的表现规则描绘出的简洁的模仿品，通过这个模仿品，人们可以了解到所研究实体的本质，而且在形式上便于人们对实体进行分析和处理。

      模型不只可以描述实物，还可以描述虚拟物件。描述实物就很好理解了，比如建筑模型、汽车模型、飞机模型。

      上边的解释，是不是不太好理解，好吧，看我下边的解释：

      按照wiki的定义，模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式

      这里要划的重点是：抽象！模型是可以简化人们的认知成本，有助于人们拨开庞杂细节和迷雾，理解客观事物的。比如古代打仗商讨战术使用的军事沙盘，所有形势地理浓缩呈现到台面上，给大家一种直观全面的认识。

      3 什么是数据模型?

• 百度百科的定义：

• wiki MBA智库的定义：

• 通俗版的解释：

      数据模型是现实世界或业务逻辑在数据层面的投影，是将数据元素以标准化的模式组织起来，用来模拟现实世界的信息框架和蓝图。

      目的和作用：

      方便人与人之间信息的传递和沟通。

      方便人们通过数据模型去理解现实世界。

      计算机通过算法模型、规则模型，可以预测客观虚拟事物的发展或轨迹。

      现实世界的虚拟事物，抽象到信息世界逻辑模型，再转换成计算机世界的数据模型，而计算机能够存储和识别的是物理模型。

      综上所述，数据模型有如下几个用途：

•  以一种结构化、方便理解特定事实的组织方式呈现给人，比如BI模型、分析模型。
• 帮助更好的理解业务，比如业务模型、概念模型、领域模型、逻辑模型。
• 根据对样本数据或人的经验猜想，构建模型，去预测其它同类事物或场景，比如算法模型。
• 将现实世界的信息转化成数据模型，呈现给计算机，可以用于存储或计算，比如物理数据存储模型

     根据数据模型用途的不同，建模方法也大相径庭。所以我们在做数据建模前，一定要先想清楚所建模型的具体用途和场景。

      我们所说的数仓建模，实际上就是构建一种数据存储模型，用于结构化存储我们日常业务行为或信息化系统存储下来有价值的数据。

      数仓建模的目的，是使用数据建模方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

• 性能，良好的数据模型能帮助我们快速查询所需要的数据，减少数据的 110 吞吐。
• 成本，良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
• 效率，良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
• 质量，良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

      高质量数据建模的重大意义：

• 更低的存储成本
• 更高的查询效率
• 清晰明了的数据结构方便理解和使用
• 简化的ETL处理逻辑
• 更好的数据质量保障（一致性、准确性、完整性、时效性）
• 更灵活的应对变化
• 更好的满足客户需求

      4 通用的数据建模流程

      调研阶段 --》》概念模型 --》》 逻辑模型 --》》物理模型 --》》生产应用迭代

      调研阶段，我们需要做好业务调研、需求调研、数据探查。

      业务调研帮助我们了解业务，结合业务去理解需求我们一开始就应该带着需求去做模型设计。

      最后我们还要结合业务和需求去做数据探查以确保原始数据的现状能够满足现有的和未来的业务需求。

      应用场景主要分为数仓建模、BI建模、算法建模等等，应用场景不同建模的方法也会差异很大。

      只有对业务、需求、数据、应用场景有足够的了解，才有可能设计出高质量的数据模型。

       概念模型阶段，我们必须做好以下几方面工作：

• 注重全局理解和对整体架构的思考，确定系统的核心以及划清系统范围和边界。类似于领域模型，这一阶段我们对于建模的范围、工作量、重点等会有一个整体直观的认识，同时确保跟客户达成共识。
• 需要确定好领域内的基础和关键的业务实体，同时也要给出实体间关系的描述。
• 我们要统一各种业务术语和命名规范。
• 我们应该明确后续使用的数据存储类型（通常会是某类数据库，这个我们下文会介绍），因为不同的数据存储对应的逻辑模型设计可能会有很大差异。

      上图来源自 DAMA2.0 。左边的是关系型概念数据模型，右边的是维度型概念数据模型。

      逻辑模型阶段，需要根据概念模型确定好的边界做进一步的细化。

      逻辑模型文档比较详细，所有实体属性均需添加，实体间关系要清晰描述，需要使用术语，遵循命名规范，采用 Case 工具创建项目文件，对各个实体以及关键属性必须要有清晰的描述。

      逻辑模型不受底层实际存储数据库的约束，但我们需要定义好实体属性以及实体间的关系（这里主要是主外键关系、一对一或一对多或者多对多关系）、实体和属性的备注说明、属性的数据类型以及约束（空值、非空、主外键键约束）。

      我们应该遵循先规范化再逆规范化的设计顺序，规范化的设计能够消除冗余方便理解，逆规范化的设计主要是为了方便使用，但我们切不可把偷懒和不专业当成逆规范化。

      上图来源自 DAMA2.0 仅供大家参考理解。在逻辑模型设计上关系模型设计思路和维度模型差异还是很明显的。关系模型设计重在捕获业务流程的规则。维度模型设计重在捕获业务问题以确定业务流程的运行状况和性能，是维度型概念数据模型的完全属性透视图。

      物理模型阶段，我们主要是针对不同的数据存储类型，根据逻辑模型，使用模型设计工具自动生成的。

      常用模型设计工具是：PowerDesigner 。

      对于主外键约束，在 OLTP 系统我们有可能会生成，但在 OLAP 环境下通常不会用。

      建模工具可以根据物理模型直接生成模型设计交付文档、数据库建表语句等。

      需要考虑查询性能要求和未来一段时间内的存储空间占用情况。

      需要确定使用哪些约束、索引、以及表字段备注的准确完整性等，当然我们之前很多时候基于商业竞争考虑这里是不写备注的。

      生产应用及迭代，物理模型部署以后，会逐步投入生产使用。随着业务的深入或者变动，模型也需要跟着优化完善。优质的模型可以更好的适应未来需求的变化，但是一劳永逸的模型几乎是不存在的。

      5 数据存储技术发展的三个阶段

      在上文我们提到，在概念模型设计阶段我们就应该确定好使用何种存储类型的数据库。

      经过五十多年的发展，数据存储主要经历三个大的阶段。

• 第一阶段：数据库技术诞生以及三大模型之争

      时间迈入了 1960 年代，野心勃勃的美国人提出了登月计划，这在当时可以件大事情。可是要飞到月球去，得有个交通工具，美国人起了个希腊神话中太阳神来命名了这个飞船。要制作这个飞船，可以动用了美国庞大的社会资源，可是这个超复杂的东东有着数不清的零件，如何管理它们成了大难题？于是计算机业内的百年老店— IBM 出场了，研发了一款叫做 ICS 的软件，专门用来管理这些零件信息。后来以此为基础诞生了大名鼎鼎的 IMS（Information Management System）数据库。这可是现代数据库的祖先。直到今天，这一老当益壮的数据库还在某些银行重要的核心岗位发挥着余热。

      IMS 数据库是基于层次结构构建的，很容易实现从上往下找，但对于左右横向查询就不太好用。另一个老牌公司 GE 看到了，开发出了新的基于网状的数据库 IDS。这个貌似蜘蛛网结构的数据库很快取得的不错的市场成绩。作为行业的老大，IBM 自然不会坐以待毙，在一个超级英雄 EF.Codd（下图中，曾获得图灵奖）的带领下，提出了关系模型。一时间，层次、网状、关系三大关系模型杀的浑天黑地。直到一个重要的语言-SQL的出现，改变了整个战局。这是一个如此简单易懂的语言，可以很容易描述数据访问需求，战局的天平倾斜关系模型。后来，聪明人扎堆的加州大学伯克利分校开发了 INGRES（就是现在的 PostgreSQL ）数据库，证明关系模型是靠谱的，才为这场战争画上了句号。

      注：以上两段文字摘抄自 CSDN 文章：

      https://blog.csdn.net/hzbooks/article/details/108480871

• 第二阶段：SQL 语言促使关系型数据库一家独大。

      由于 SQL 超低学习成本，以及关系型数据库对 SQL 的天然支持，使得关系型数据库迅速普及并几乎完全占领市场，像我们耳熟能详的数据库，基本上都是关系型数据库。

• 第三阶段：新型数据库的百花齐放。

      后来随着互联网用户规模、数据量越来越大，并且要求 7X24 小时在线，传统的关系型数据库由于性能随着数据量的变大而极速下降、升级扩展困难、扩容成本与数据规模呈指数级增长，这都促使开发者们不得不去探索新的数据存储。

      NoSQL (Not Only SQL)，泛指非关系型的数据库，我们通常会根据不同的使用场景去选择不同的 NoSQL 数据库，但由于不支持 SQL 就极大的增加了数据从业者的使用难度，好在后来有人想到在此之上封装一层 SQL 解析程序，这才加速了 NoSQL 数据存储的快速普及，比如 Hive、SparkSQL 等等。而其它没有提供 SQL 查询或者 SQL 支持不到位的几乎很难扩大影响力和普及率，有些甚至也已经慢慢被淘汰了。

      虽然开放对 SQL 的支持使得 NoSQL 数据存储得到普及，但其依然存在一些问题使其无法取代传统关系型数据库，近些年伴随着分布式协议的成熟，人们找到了一种新的方式来解决这些痛点。

      NoSQL (Not Only SQL)，泛指非关系型的数据库，我们通常会根据不同的使用场景去选择不同的 NoSQL 数据库，但由于对 SQL 的支持能力弱，使用群体往往被限制在技术圈层内，通常能够提供相对完备 SQL 支持能力，或者再次之上再包一层SQL转化解析的才更容易被普及到更广大的数据从业者中去，比如Hive、SparkSQL等等。

      NewSQL ，是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

      NewSQL 系统的提出，正是为了满足整合 NoSQL 和 RDBMS 特性的需求。其中，NoSQL 提供了可扩展性和高可用性，传统 RDBMS 提供了关系模型、ACID 事务支持和 SQL。用户已不再考虑一招能解决所有问题（one-size-fits-all）的方案，逐渐转向针对 OLTP 等不同工作负载给出特定数据库。大多数 NewSQL 数据库做了全新的设计，或是主要聚焦于 OLTP，或是采用了 OLTP/OLAP 的混合架构的全新设计。

      什么样的数据库才能称之为 NewSQL，应该有以下几点必备的特性：

• SQL
• ACID Transaction, 支持跨行事务
• Auto-scale 可扩展性
• Auto-failover

      最后来一张图，有点搞笑，不过说真的，对于一个数据管理系统而言，得 SQL 者得天下，因为不支持 SQL 的话很难去普及推广。SQL 是最伟大的语言，数据从业者的最爱，不接受反驳，哈哈。。。

      6 数据建模方法有哪些？

      上边表格，是 DAMA 2.0 给出的建模方法和数据库交叉应用模式。

      数据建模阶段，我们需要根据不同应用场景选择合适的建模方法和数据存储。同时也需要根据数据存储类型的不同去调整建模方法，比如关系数据库里实现的范式模型就是星型模式，在多维数据库环境中实现的维度模型通常称为联机分析处理数据库。

      1.关系建模

      关系模型是 1970 年 IBM 研究院， EF.Codd 提出来的，随后在 1971 年又提出了范式理论。

      关系模型也被称作范式建模，因为其原理的核心是“规范化”理念，规范化是在保证数据存储完整性的同时，最小化冗余数据的结构化过程。

      范式是符合某一种级别的关系模式的集合，目前关系型数据库有六种范式：第一范式（1NF），第二范式(2NF)，第三范式（3NF），Boyce-Codd范式（BCNF），第四范式（4NF），第五范式（5NF）。

      规范化本质上是对数据存储结构进行拆分，范式等级越高拆的越细，同时规范化程度越高冗余度越低，但会给具体的查询带来负担，所以实际中我们通常到第三范式即可。

      除了规范化，我们在进行关系建模时也会用到 ER 模型，即实体关系模型（Entity-relationship model），美籍华裔计算机科学家陈品山提出，是概念数据模型的高层描述所使用的数据模型或模式图。

      ER 模型将现实世界抽象成不同的实体，每个实体附带不同的属性，实体与实体间的联系称为关系，关系又分为（1:1、1:n、m:3）三种。

      ER 模型和规范化理论共同构成了关系建模理论，OLTP 系统基本上都是使用的关系建模。

      样例一：ER 模型

      下边是网上摘抄的学生-课程-教师实体关系图，给大家参考一下。

      假设每个学生选修若干门课程，且每个学生每选一门课只有一个成绩，每个教师只担任一门课的教学,一门课由若干教师任教。“学生”有属性：学号、姓名、地址、年龄、性别。“教师”有属性：职工号、教师姓名、职称，“课程”有属性：课程号、课程名。

      样例二：规范化

      上文所说的规范化主要实现方案就是拆分，下边是临时写的一个集团公司合作伙伴的实体-关系-属性样例，写的很简单大家看懂问题就行。

      由于供应商和客户既有共同的属性又有特有属性，集团客户又分为内部客户和外部客户。为了降低冗余所以我们需要设计出父子两类实体，将共有属性抽象出来做为父实体。

      另外，公司与供应商间还会有采购合同，采购合同就应该从供应商实体中分离出来。

      2.维度建模

      联机分析处理的概念最早由关系数据库之父 E．F．Codd 于 1993 年提出。Codd 提出了多维数据库和多维分析的概念，把业务系统面向业务逻辑、面向事务增删改查而设计的存储结构，转换成面向分析、侧重查询的多维分析型存储结构。将所有对象都抽象为维度、度量、属性三类：

• 维度，可以理解为不同分析视角。
• 属性，用来定义和描述维度。
• 度量，是在一个或多个维度限定下的取值。

      存储格式分为两种：

• 关系 OLAP（ROLAP）：基于关系数据库的 OLAP 实现，细节数据以及为聚合后的的粗粒度数据，通常会存储到关系型数据库中。
• 多维 OLAP（MOLAP）：有时候会构件 Cube，优点是使用方便，缺点是需要占用大量的存储空间。

      上边两段是我在数据仓库系列开篇里边摘录两段内容。

      我发现一个有意思的事情，关系建模和维度建模理论应该是同一个人（关系数据库之父 E．F．Codd）提出的，维度建模方法比关系建模方法晚出来了 20 年，这 20 年刚好是信息化从开端到普及的阶段，OLTP 系统存储下来的数据开始有了分析应用的需求和场景，而 OLTP 数据库在进行海量数据的分析处理上又有很多不足，比如大量的资源消耗和性能问题。

      而维度模型和多维分析数据库就是在这样的背景下，由关系模型的奠基人提出来的，它将客观世界抽象成维度-属性-度量这三个概念，从而构成了维度模型。

      当维度模型在关系型数据库里实现就是我们大家常说的雪花模型或星座模型，反三范式或者逆规范化后就变成了星型模型

      当维度模型在多维分析数据库里实现会称为联机分析处理数据库。在 OLAP 多维数据库时，对这些数据的存储的索引，采用了维度数据涉及的格式和技术。性能聚集或预计算汇总表通常由多维数据库引擎建立并管理。由于采用预计算、索引策略和其他优化方法，多维数据库可实现高性能查询。

      当维度模型在 NoSQL 数据存储类型里实现，由于索引的缺失和对 Join 实现性能低下，维度模型会退化到星型模型甚至不建模了，就是直接粗暴的拉大宽表。

      当维度模型在 NewSQL 数据存储类型里实现，慢慢的开始回归到了最早关系型数据库的星型模型、雪花模型或星座模型中来了，比如最近比较火的 Doris。

      3.其它建模方法

      DAMA 2.0 给出的数据建模方法，还有其它四类：面向对象、基于事实、基于时间、非关系型。

      但由于这些建模方法都各有其局限性适用场景有限或者学习和理解难度较大，生产实践中用的不多，这里就不做介绍了，大家感兴趣的可以翻一下 DAMA 2.0 或者参考百度。

      第二部分

      上篇，我们主要讲解了数据建模的理论知识，同时跟大家介绍了数据建模的流程，以及常见的建模方法。

      本篇，我们会基于上篇的建模理论，结合真实数仓场景，给大家介绍下完整的数仓建模过程。

      1 数仓建模在数仓建设过程中的位置

      这张截图源自之前从 0 到 1 建设数据仓库的经验总结，采用的是瀑布模式的展现方式，但实际操作中经常会使用螺旋迭代模式，因为很难有人能够一步到位的考虑清楚所有细节。

      通过业务调研我们熟悉了相关业务过程，需求调研我们明确了本阶段数据建设的需求、内容和边界，数据调研也就是数据探查我们对需要的数据源做了整体摸排，不清楚的就赶紧搞清楚、不对的就赶紧搞对、缺失的就想办法找补回来或者想办法补救，真要缺的太多是不是就要中止项目了至少也得重新规划。我们只是数据的搬运工，并不能凭空编造数据…

      随后我们结合调研阶段的成果，做了五大架构设计、落实了技术选型、制定了数仓规范并分发给所有参与者。

      接下来我们就进入到了数仓建模阶段，数仓建模对于数仓建设的成败能起到决定性的作用。

      经常的我会把数据仓库类比成一个可以自运行的生态系统，当然我们拿人类自己来类比是最恰当了：人需要吃饭数仓也需要周期性的去源端获取数据，人有大脑和中枢神经去控制身体数仓有调度去掌控全局，人有骨架肌肉而数仓的骨架肌肉就是数据模型。

      数仓模型承载了数据存储的重要职能，我们需要从全局视角去设计，因为它本身就是一个整体，人有手有脚数仓模型也要分成多个不同的部分，人的手脚身体大脑必须协调一致才能正常活动，数据模型的不同部分也需要协调一致数仓这个生态系统才能正常 运转。人体如果筋脉不通就会生病，所以 Inmon 的数据建模思路讲究的是全局思考统一设计，Kimball 的数据建模思路提出的是总线架构，殊途同归其实都是提供给大家一套整体设计的方法论去打通数据模型甚至数仓运转的奇经八脉。

      2 理论联系实践的数仓建模方法探索

      上边两页出自之前的 PPT 供大家参考。

      国外的众多数据从业者经过几十年的理论研究和实践探索、多种方法论的碰撞，最终为我们留下了完整的方法论。而两大权威理论实际上包含的分别是两大不同的方法论：数仓建设方法和数仓建模方法。

      Inmon 的数仓建设方法论倡导一种自上而下的瀑布式的建设过程。其数据仓库模型设计的出发点是整合数据，将各个系统中的数据从全企业视角分主题进行整合，打通所有数据源，剔除冗余、错误和不兼容，采用规范化的模型设计方法统一存储企业所有数据，为数据分析决策服务，但这种规范化的模型设计方法不太适合分析决策这种场景，所以后来又在此基础之上新增数据集市用于支撑各部门的业务应用。

      规范化设计能够减少冗余避免数据不一致，全局兼容完整的设计能够保证数据的完整性。但是这种建模方法对建模人员的能力要求非常高，同时也需要对企业业务和数据有全面深入的了解，业务简单还好但对于复杂的业务场景难免拉长了建设周期、极大增 加了模型设计的难度，以至于在一开始以这种方法实施的数据仓库大都以失败告终。

      Kimball 的数仓建设方法，倡导自下而上建设，不用建设复杂的数据仓库，直接构建集市用于支撑业务需求，但当数据集市多了以后，多个数据集市间又造成了混乱和不兼容，而为了解决这种问题又提出了总线架构的概念。总线架构包含：一致性维度和一致性事实两个部分，我们集中设计和管理所有维度、统一定义各种指标，然后让所有数据集市都遵从这种一致性维度和一致性事实。

      由于是直接构建数据集市，不需要过多的数据整合，Kimball 的构建方法相对于 Inmon 就会容易很多。虽然总线架构解决了多个数据集市间的兼容性问题，但这种建模方法还存在以下两个问题：1、模型的稳定性完全取决于建模师对业务场景对分析需求的理解程度。2、完全基于业务需求的建模对于需求“用不到”的数据就会被丢弃从而造成数据的缺失，本质上讲这是违背数仓建设原则的，那么我们就需要永久的保留 ODS 层的数据确保未来需要的时候有办法可以找补回来。

      3 实践出真知适合自己的才是最好的

      实际上我们并不会局限于某一种建模方法，我们需要在熟知各种建模理论的基础上，结合实际业务场景去选择合适的方法。

      上图是我们常规的数仓建模流程，接下来我会逐个给大家讲解。我们主要采用统一调研、整体规划、分散设计、集中评审的建设思路，以及自顶向下和自下而上相结合的设计方法。

      说明：这里的上和下并非架构图的上下，而是数据流向的上下游。我们称之为上游数据源下游数据应用。

      我们通过三步调研，了解了业务流程、明确了中短期需求、对源端的数据质量和存储格式都有了清晰的了解。

      三步调研之后，我们会制定数仓分层架构，逻辑上主要分为三层：ODS、DW、DM。目前大家常用的四层五层甚至七层本质上还是对这三层的细化。比如 ODS 层前边还能有一个 STG 层，STG 英文翻译 staging，也有说是 stage ，就是一个临时数据存放区，数据源端每次抽取或上传过来的数据（通常是增量）先入 STG 做短暂临时的存放，ETL 进行简单的清洗、合并、转换后入 ODS 层存储。DW 层还会被细分成 DWD、DWS 等，当然还有可能会构建主题宽表，那宽表是否需要再分为明细宽表和汇总宽表呢，宽表应该归属于 DW 还是 DM 呢？当然了放哪儿都行这些都不重要逻辑上能讲通就行。

      分层架构出来后，我们会根据每一层的不同用途有针对性的建模。

      ODS 层，原始数据存储区，存储结构跟源端保持一致原则上不做清洗转换，命名上：数据来源+源端原始名称，数据保留时长取决于下游。如果 ODS-DW 过程中没有信息丢失，可以只保留 3-7 天，保留时间越短对运维人员要求越高。如果该过程有信息丢 失为防止万一 ODS 层需要永久保留，保留策略有很多，比如从时间上划分为冷热数据冷数据可以归档转移到更便宜的存储，比如对数据内容上进行归类对于一段时间后就失去价值的数据直接删除即可例如系统运行日志。

      DW 层，数据仓库的核心存储层，这一层数仓建模的核心，相对标准的思路是我们在明细层采用范式建模的思路自顶向下设计把 ODS 层的数据完整的整合进来，打破孤岛（ID 映射）、消除冗余，再往上层可以采用维度建模的思路，基于 DWD 层做轻度汇总、重度汇总，主要以满足业务需求为主，后期如有需求新增或变化可以基于 DWD 层的完整数据重新汇总。DW 层的数据是需要长期保留的。

      当然在大数据场景下，我们通常需要考虑存储和计算开销，会去评估这些成本投入是否产生了足够的价值，明细层往往也会采用维度建模而且完全面向需求去设计，就是说短期用不到的数据我们就先不引入 DW 层了，等需要的时候再根据原始数据算。

      这里需要说明一下，数据丢失远比计算错误更需要引起大家重视。由于某些原因很多大数据从业者没有认识到数据丢失的惨重后果。记得之前有一次为了降低成本老板甚至让删除一年之前的原始归档数据，结果没几天新的需求 DW 层无法满足需要重刷历史数据，幸好当时我们找借口拖着没删。

      DM 层，数据集市层在逻辑上会包含多个数据集市。DWS 层汇总的通常是公用的、经常被使用的数据，绝大多数常规业务也都可以基于 DWS 直接实现，满足不了的时候我们需要根据各部门或者项目的需求去重新组织构建对应的数据集市，这一层通常也是采用维度建模方法自下而上完全面向需求去设计，数据集市往往伴随着对应的部门或项目需求而建立或者终止。

      这里先做个简单的总结：

• ODS 不用建模直接用源端数据存储结构。
• DWD 范式建模，保证 ODS 到 DW 信息不丢失，如果 DWD 也采用维度建模 ODS 数据一定要长期保留。
• DWS 维度建模面向需求设计，存储一些全域经常被使用到的数据。
• DM 完全面向需求建模，生命周期跟对应需求的生命周期一致。

      横向分层讲完了，那我们接下来聊聊纵向分域吧。

      分域的目的是为了给数据或表进行归类，从而方便数据管理。

      分域的概念也主要用在 DW 和 DM 层。

• DW 层主要面向业务过程划分数据域，数据域下边再划分多个主题，主题下边会有多个业务过程，理论上每个业务过程对应一张表，但当所有表设计好以后需要结合 ETL 过程和业务使用习惯考虑是否需要对多张表进行合并操作。
• DM 层划分数据域的方式就简单了，完全对应需求场景或者使用部门就好了。

      分层和分域的概念讲完后，我们接下来需要制定相应的模型设计和使用规范。具体到落地阶段了，那么很多事情我们就必须把它明确下来，上边我们提到的内容在具体细节上可能会有多种选择，比如 ODS 数据保留策略、DWD 采用何种建模方法、有无主题宽表以及宽表归属哪一层等等，这些都需要通过规范去明确从而避免多人协作过程中的混乱。更具体的内容可以参考文末推荐阅读里的相关历史文章。

      对于一致性维度、一致性事实的保障策略，也需要通过规范去明确和约束，确保同一个维度或度量在数仓的所有地方有相同的含义。我们也要通过规范教会大家如何才能建设出来统一高质量的数据模型。

      以上的统一调研、整体规划（分层架构、规范制定、主题域划分）后，我们进入了分散设计的阶段。

      分散设计

      到这里，由于数仓模型设计的复杂性，我们需要多人合作共同完成建模工作，这时候架构师或者建模师可以结合之前分层分域的成果，按层按域将模型设计任务进行拆解后分发给不同的人完成。我们通常可以这样拆分：ODS 层可以按源端类型拆分、DW 层可以按数据域分成多块、DM 层就按数据集市拆分。这样核心建模师只需要完成 DW 层即可，每人分别负责不同的数据域，ODS 层甚至可以分配给 ETL 工程师负责这样刚好顺便熟悉了源端存储结构以及对数据质量的探查，DM 层完全可以分配给 BI 工程师通常会开发成单表查询的模式。这样子做完分工后，在模型设计规范的统一指导和架构师或总建模师的协调下，相信最终是可以设计出一套统一完善且相互兼容的数仓模型的。

      统一评审

      虽然我们有完善的模型设计规范做指导，但考虑到各个部分建模者的不同情况，设计上难免会有疏漏，这就需要最终的统一评审环节。我们可以逐层分域的去评审，参与方主要有以下角色：架构师、总建模师、该模块主建模师、业务专家、数据运维、ETL 工程师。

      交付与迭代

      统一评审结束后，我们最终会形成一套完整的数据模型设计文档，通常是逻辑模型。

      我们根据逻辑模型生成物理模型，然后交付给 ETL 工程师负责后续的数据开发。我们通常需要 ETL 工程师除了具备基本的开发能力外，还要有一定的数据探查、数据建模能力，确保在数据开发阶段能够发现原有模型设计的不足并及时反馈，比如现有模型如果使得 ETL 开发变的异常复杂或者程序性能低下，这时候通常就需要考虑修改模型设计了。我们经常使用的维度退化和宽表“模型”就是最常见的为了提高程序执行效率而做的规范化方面的妥协。