数仓架构设计方法论

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数仓之父比尔·恩门（Bill Inmon）在1991年出版的《Building the Data Warehouse》一书中所提出的定义被广泛接受：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

早期的数仓多是基于关系型数据库（比如Oracel、SQLServer）搭建，数仓设计主要由从事系统开发的软件工程师完成。随着互联网大数据技术的发展，现在互联网公司的数仓主要基于hadoop技术生态构建，并逐渐分化出专门从事数仓架构和数据开发的数仓工程师。受关系型数据库的设计影响，大部分软件工程师转向做数仓设计时，会不自觉地遵循三范式要求。但是数仓设计与关系型数据库设计有很大区别，不能完全遵循三范式设计。

数仓的三层架构：ODS-DW-DM

ETL是英文Extract-Transform-Load的缩写，它描述了数仓数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的整个生产过程。早期数仓直接从数据源产出分析报表，ETL过程比较简单，可以通过简单的脚本实现。但是，随着数据量的爆发增长和数据应用的拓展（除数据分析外，数据挖掘，人工智能等应用都强依赖数仓），数仓的ETL过程变得越来越复杂，需要工程化手段对数仓做架构设计。现在数仓总体架构会分三层：ODS源数据层，DW中间层和DM集市层，如下图所示。

ODS层存储最原始的数据，不对数据做任何加工处理。DW层存储ETL过程的中间表，简化ETL实现的复杂度，提高中间数据的复用度。为了便于工程实现和维护，DW层会进一步细分为DWD明细层和DWM汇总层。DM层为最终输出的满足业务场景需求的数据表。DIM层存放维度数据，维度数据是一些基础数据不需要经过复杂的ETL过程，相对比较稳定，可以被DW和DM层共用。各层的详细职责划分如下。

采用分层架构后，ETL过程被分解为各层之间的子过程，全局过程通过依赖关系级联调度完成。为避免循环依赖和更好的维护性，每层数据的ETL过程只能使用本层和下层数据，不能依赖上层数据。例如，DWD层数据不能依赖DWM或DM层数据。

ODS层数据表通过数据采集而来。DW和DM层数据表通过ETL过程输出。那么对于这两层的数据表，该如何进行建模设计呢？主要有两种方式：① 数据仓库之父Inmon提出的集线器的自上而下（EDW-DM）的范式建模；② 数仓大师Ralph Kimball提出的总线式的自下而上（DM-DW）的维度建模。DW层数据表主要采用范式建模，而DM层数据表偏向维度建模。

DW层数据表：范式建模

范式建模源自关系型数据库的范式理论。它从“实体-关系”的角度对客观世界建模，和关系型DB的建模方式相同。范式建模的完整过程是从数据源到数据仓库再到数据集市。它从数据源出发，探索性地去获取尽量符合预期的数据，并将数据按预期划分为不同的表需求。

范式建模有利于维护数据的一致性、稳定性和可扩展性，减少数据冗余，降低ETL过程的实现复杂度。但是由于它从实体-关系角度建模，不利于分析理解数据。所以主要用于DW层中间表建模。DW层数据表基于ODS层数据产出，ODS层中来自业务数据库的数据表也是范式建模，相同的建模方法更有利于ODS层到DW层的ETL处理。

DM层数据表：维度建模

维度建模从“维度-指标”的角度对客观世界建模，它面向分析，反范式设计要求，为了提高查询性能可以增加数据冗余。维度建模的过程和范式建模相反，它以最终需求目标为导向，数据表的设计遵循易于理解和快速反应的准则。

维度建模主要使用的模型有：星形模型、雪花模型和星座模型（如下图所示）。三种模型的建模方式相同，都是围绕事实表和维度表建模。区别在于是否在维度表，事实表之间引入关系范式约束。星形模型完全不做范式约束，有极大的数据冗余，但也因此获得最好的查询分析性能。雪花模型对维度表作了一些范式约束，减少了维度数据冗余。星座模型允许多个事实表共享维度表。大型数仓一般采用星座模型。

和范式建模相比，维度建模的数据表更易于理解和OLAP查询分析。但是由于大量的数据冗余，维度建模不利于的数据一致性和稳定性。此外维度建模紧贴分析需求，需求的灵活变更会导致ETL过程也会复杂多变，不利于维护。因此他不适用于DW层数据表的建模。而DM层数据表对最终用户开放使用，需要面向具体的数据分析需求。维度建模能有效地满足DM层的设计要求。由于增加了DW中间层，复杂的数据处理逻辑会沉淀到DW层的ETL过程，大大简化DM层的ETL过程。

强可读性的命名规范

DB设计的数据表主要为程序所用，只有参与开发和运维的工程师等少数人类需要理解。但是数仓面向的用户有大量不同角色的人类。BI、运营、市场、销售、老板，几乎公司所有员工都需要使用数仓。因此，数仓设计必须遵循一套非常强的可读性命名规范。命名规范没有严格的标准，关键是统一，便于理解。以下是业内较为普遍的一种数仓表命名规范。

来源：互联网工匠