一文读懂系列：数据仓库为什么分层，分几层？数仓建模方法有哪些|元数据|关系型|客户端节点|数据仓库|数据源

一、数仓为什么要分层

简单来说，数仓分层就像盖楼房，不分层就是盖平房，虽然简单快捷，但无法建成复杂、稳固的高楼大厦

数据仓库之父 Bill Inmon对数据仓库做了定义——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从定义上来看，数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策，而这些关键词的实现就体现在分层架构内。

数仓分层，核心原因与核心价值

1、清晰数据结构，降低复杂度：

问题：一个庞大的数据系统，如果所有数据都堆在一起，ETL（抽取、转换、加载）逻辑、业务计算逻辑会相互缠绕，变得极其复杂和难以理解。
解决：每一层都有对应的作用域，在使用数据的时候能更方便地定位和理解。比如，DWD层负责数据清洗和标准化，DWS层负责轻度汇总。这样，当业务需求变更时，开发人员可以快速定位到需要修改的逻辑所在的层级，而不必在混乱的脚本中大海捞针。

2、数据血缘与质量保障：

问题：如果最终报表数据出错，如何快速追溯问题源头？
解决：分层结构天然形成了数据血缘关系。当应用层的数据有问题时，可以逐层向下排查：

- 应用层 -> 是来自DWS层的汇总数据有问题？

- DWS层 -> 是来自DWD层的明细数据有问题？

- DWD层 -> 是ODS层原始数据本身有脏数据？

这种追溯能力极大地提高了数据问题排查的效率和数据质量的可靠性。

3、减少重复开发，提高复用性：

问题：不同的业务线或报表可能需要相同的中间计算逻辑（如用户画像、业务宽表）。如果不分层，每个开发人员都会重复实现一遍，浪费资源且可能产生口径不一致的结果。
解决：将公共的加工逻辑沉淀到中间层（如DWD、DWS层）。下游所有的数据应用（报表、BI分析、数据科学）都直接复用这些加工好的高质量数据，避免了“烟囱式”开发，保证了数据口径的一致性。

4、隔离原始数据与数据应用，增强稳定性

问题：业务系统的表结构变更、甚至数据库宕机，会直接影响到数据报表和数据分析的稳定性。
解决：ODS层将原始数据与应用层隔离开。即使业务系统发生变化，也只需要在ODS层和DWD层进行调整，而不会影响到上层的汇总数据和直接面向业务的数据应用，增强了数据体系的鲁棒性。

5、空间与计算成本的权衡

问题：如果所有查询都直接基于最细粒度的原始数据，虽然灵活，但每次查询都需要进行大量的关联和聚合运算，效率极低，计算成本高。
解决：通过分层，将常用的、固定的计算逻辑在DWS层或ADS层提前计算好（空间换时间）。这样，大部分简单的查询可以直接使用汇总层的数据，响应速度极快，也降低了对底层计算资源的压力。

最核心的目的可以概括为：通过分层，将复杂的数据处理流程分解成多个步骤，从而实现对数据的管理、控制和高效使用

二、数仓分几层最好

答案是：没有绝对“最好”的层数，最适合的层数取决于你的业务规模、数据复杂度、团队能力和技术栈。

核心原则是：分层是为了解决问题，而不是为了分层而分层。在保证清晰、高效、可维护的前提下，层数越少越好。

01、主流分层模型及其适用场景

通常我们将分层模型分为以下几类，从简单到复杂：

1、基础三层模型（最经典、最常用）

这是绝大多数中小型公司和业务场景的最佳起点和黄金标准

结构：ODS -> DWD -> ADS
特点：
ODS：贴源数据，备份和隔离。
DWD：核心层，完成所有数据清洗、关联、维度退化，形成主题一致、高质量的明细数据。
ADS：直接面向应用，基于DWD进行各种业务计算，产出报表、API等。
优点：结构极度清晰，职责明确，维护成本低，能解决80%的问题。
适用场景：
初创公司或新业务从0到1搭建数仓。
数据量、业务复杂度、团队规模处于中等或以下水平。
强烈建议从这里开始，不要过度设计。

2、标准四层模型（阿里巴巴经典模型）

这是目前国内互联网行业最主流的实践，是对三层模型的精细化补充。

结构：ODS -> DWD -> DWS -> ADS
变化：在DWD和ADS之间增加了 DWS 层。
DWS层的核心作用：
公共汇总：将DWD的明细数据，按常见的分析维度（如用户、商品、地区、时间）进行轻度汇总，形成“宽表”。
复用与提速：80%的通用查询可以直接使用DWS层的宽表，避免了重复关联，极大提升了查询效率。
优点：在清晰性基础上，通过空间换时间，显著提升了查询性能和数据复用度。
适用场景：
业务复杂度增加，有大量跨主题的关联分析需求。
数据量较大，直接查询明细性能成为瓶颈。
团队规模扩大，需要更精细的职责分工（专人维护DWS公共层）。

3、复杂多层模型（五层及以上）

通常在超大型、业务极其复杂的公司中见到，是四层模型的进一步扩展。

常见扩展
DIM（维度层）：独立管理维度表，这是四层模型中通常包含的部分，有时会单独强调。
DWM（Data Warehouse Middle，中间层）：在DWD和DWS之间增加，进行更细粒度的业务过程组合，为不同的DWS主题服务。
ST（Staging，缓冲层）：在ODS之前，用于临时存放、校验、拆分增量/全量数据。
优点：职责划分极致精细，适合超大规模协作。
缺点：管理成本极高，数据链路变长，时效性可能受影响。
适用场景
像阿里巴巴、腾讯、字节跳动等超大型企业，有数千名数据开发人员。
业务板块繁多且差异巨大（如电商、金融、云服务、文娱）。
对于绝大多数公司来说，这是“过度设计”的典范，应避免盲目模仿。

02、如何为你的项目选择“最佳”层数？

可以通过回答以下几个问题来做决策：

1、当前业务有多复杂？

简单：只有几个核心业务表，报表需求固定 -->考虑最简三层 (ODS, DWD, ADS)
中等：多个业务系统，有跨系统的分析需求 -->从三层开始，逐步演进到四层
非常复杂：多条独立产品线，数据量巨大，有实时和离线混合需求 ->采用四层，并规划未来可能的细化

2、团队规模和能力如何？

1-3人小团队：优先选择三层模型，集中精力保证DWD层质量，避免在分层管理上耗费过多精力。
5-20人成熟团队：采用四层模型，可以安排专人负责DWS公共层的建设和维护。
大型团队：在四层基础上，通过主题域划分数据域划分来管理复杂度，而不是盲目增加层级。

3、对数据时效性和查询性能的要求有多高？

对查询性能要求极高（如面向C端的数据产品），DWS层至关重要，需要用四层模型。
主要是T+1的内部报表，三层模型通常足够。

4、技术栈是什么？

使用Hive/Spark等批处理引擎，链路长，分层明显。
使用ClickHouse, Doris等MPP引擎，因其本身性能极强，有时可以简化DWS层，甚至采用“大宽表”模式，但ODS和DWD的思想依然需要。

03、核心建议与结论

1、从简单开始（KISS原则）：

强烈建议从“基础三层模型”（ODS -> DWD -> ADS）开始你的数仓建设。这是最稳健、犯错成本最低的起点。很多问题在早期并不存在，过早设计复杂分层是浪费。2、演进优于预设计：

数仓是“生长”出来的，不是“设计”出来的。当现有三层遇到明显痛点时（如“ADS层有大量重复关联逻辑”、“核心查询越来越慢”），再考虑引入DWS层，演进到四层模型。这通常是第一个关键的演进点。

3、核心永远是DWD层：

无论分几层，DWD（明细数据层）都是数仓的基石和心脏。必须投入最大精力保证它的数据质量、一致性、稳定性和可回溯性。DWD层如果混乱，上层建筑再漂亮也会崩塌。

4、分层思想重于固定层数：

理解“原始数据、集成清洗、公共汇总、个性应用” 这一核心分层思想，比记住“必须分四层”更重要。你可以根据这个思想，为你的业务定制最合适的层数。

最终答案：对于大多数场景，3到4层是最佳实践范围。从3层开始，根据需要演进到4层，是最明智的路径。永远记住：分层是手段，不是目的，目的是高效、可靠、清晰地服务业务。

三、数仓设计

数仓设计的3个维度：

功能架构：结构层次清晰。
数据架构：数据质量有保障。
技术架构：易扩展、易用。

01、数仓架构

按照数据流入流出的过程，数据仓库架构可分为：源数据、数据仓库、数据应用。

数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。

源数据：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。

数据仓库：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。

数据应用：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

建设数据仓库犹如创造一条新的生命，分层架构只是这条生命的逻辑骨架而已。想要在骨架上长出血肉，就必须进行合适的数据建模，数据仓库的强壮还是孱弱，健美还是丑陋，就取决于建模的结果。

02、数仓建模方法

数据仓库的建模方法有很多种，每一种建模方法代表了哲学上的一个观点，代表了一种归纳、概括世界的一种方法。常见的有范式建模法、维度建模法、实体建模法等，每种方法从本质上将是从不同的角度看待业务中的问题。

1、范式建模法

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。

在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :

每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

根据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。

2、实体建模法

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件，说明，如下图所示：

上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

3、维度建模法

维度建模（Dimensional Modeling）主要应用于数据集市的构建，适用于以分析需求为主导的业务场景，以“业务流程”为核心，以“事实数据”为中心，通过组织维度（如时间、地区、产品等）和度量指标（如销售额、订单数、访问量等），形成面向主题的分析数据结构。

维度建模中比较重要的概念就是事实表（Fact table）和维度表（Dimension table）。通过它们之间的关联构建模型结构，前者用于存储可度量的业务事件（如交易、订单、点击），后者用于描述这些事件发生的背景信息（如发生时间、发生地点、客户身份等）。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。目前在互联网公司最常用的建模方法就是维度建模。

换句话说，维度建模就是为“看得懂、分析快”而设计的结构，它不追求字段最规范、结构最严谨，而是优先考虑业务使用时的便捷性，维度建模让数据像拼图一样组成业务故事：一张订单背后有哪些客户？这位客户来自哪里？在什么时间下的单？买的什么商品？……

这些信息原本可能散落在多个系统表中，维度建模把它们重新整合，让业务视角可以一目了然地串联起来，相比范式建模强调“数据不重复、结构不冗余”，维度建模在意的是“查询效率高、业务口径准、指标逻辑清晰”。

维度建模最常采用的模型结构是星型模型（Star Schema），即以中心事实表为核心，连接多个维度表，其他常见结构还包括雪花模型星座模型

标准的星型模型，维度只有一层，分析性能最优
雪花模型具有多层维度，比较接近三范式设计，较为灵活
星座模型基于多个事实表，事实表之间会共享一些维度表，是大型数据仓库中的常态，是业务增长的结果，与模型设计无关

总的来说，维度建模是以业务分析为导向的数据建模方式，它用数据语言表达业务过程，强调主题清晰、结构简洁、分析高效，主要适用于数据集市层，但很难提供一个完整地描述真实业务实体实体之间的复杂关系的抽象方法。

03、维度建模怎么建：

在实际业务中，给了我们一堆数据，我们怎么拿这些数据进行数仓建设呢，数仓工具箱作者根据自身60多年的实际业务经验，给我们总结了如下四步。

数仓工具箱中的维度建模四步走：

这四步是环环相扣，步步相连。下面详细拆解下每个步骤怎么做

1、选择业务过程

维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。

2、声明粒度

先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。

3、确认维度

维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

4、确认事实

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

其中粒度是非常重要的，粒度用于确定事实表的行表示什么，建议从关注原子级别的粒度数据开始设计，因为原子粒度能够承受无法预估的用户查询，而且原子数据可以以各种可能的方式进行上卷，而一旦选择了高粒度，则无法满足用户下钻细节的需求。

事实是整个维度建模的核心，其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展，生成一份能够支撑可预知查询需求的模型宽表，而且最后的查询也是落在事实表中进行。

四、派可数据零代码数仓建模

派可标准化数仓产品，零代码实现，不需要用户再进行手动分层，后台算法自动识别维度和指标、指标与指标的先后调度关系。用户可以在派可数据标准化数仓产品中直接零代码配置并完成数仓建模的整个过程并可以体会到完整的建模方法论及各个数仓元素。下图为派可数据标准化零代码数仓分层方式。