数据仓库物理分层_【数据中台】关于数据仓库分层的争论

背景

这两年随着阿里数据中台概念的提出，关于什么是数据中台，数据中台架构的文章层出不穷，有些新的概念更是让人丈二和尚，摸不着头脑。

今天就与领导关于针对阿里提出的One DataOne ID的理论体系以及数据仓库的分层方式如何在实际项目进行落地进行了一番争论。

通过争论，实际上证明了一些东西，就是知识需要进行不断的总结和提炼，并且能够给别人讲明白的知识才真正的称之为知识，否则有时候我以为我已经懂了，但这个时候只是自己在那里窃喜而已，窃喜自己知道了别人不知道的东西，心中一直嘿嘿。但实际缺确是自己并没有真正理解，而且别人也不一定就不知道。

问题

今天争论的焦点有这么几点：

• 数据仓库应该如何分层？各个层级叫什么？
• 宽表应该属于数据仓库的哪一层？

针对第一个问题，当在百度上搜索数据仓库分层架构时，各种名称、概念层出不穷，容易把我们这些刚入门的小白搞的晕头转向，所以非常有必要进行一次“正本溯源”。

数仓分层

在回答上面两个问题之前，有必要了解一下Kimball（维度建模）和Inmon（范式建模）两种主流的数据仓库建模方法，分别是由Ralph Kimball和Bill Inmon两位大神提出的，两位大师对应的著作分别是（这两本书都买完了，但是一本都还没啃完~）：

Inmon建模的方式是自下而上的（也有说是自上而下的，角度不同而已；自下而上是从应用层级划分的角度来说的；自上而下是从数据上下游关系来说的），即先考虑我有哪些数据，再考虑当下业务场景中的所有可能，基于范式建模的理念去构建一个大而全的数据基座。

这个大而全的数据基座被称之为企业数仓，顾名思义，即涵盖了整个企业范围内的全域数据。在数仓中会按照业务主题进行划分，每个主题采用的是关系建模的方法，遵循第三范式（3NF，即单张数据表中不存在数据冗余，3NF能够保证每个数据实体的独立性，避免造成数据冗余及不一致；但是问题也比较明显，即在进行数据查询分析时，面临大量的表关联查询，如果数据量比较大，则会严重影响查询性能。）。

Inmon架构如下图所示（图片来源：数据仓库Inmon和Kimball架构）

Kimball建模的方式是自上而下的，即优先考虑有哪些业务场景，这些场景需要构建哪些数据指标，而这些数据指标依赖的数据维度和事实数据有哪些。也就是针对某一个数据域或者业务进行维度建模，得到最细粒度的事实表和维度表，形成适用于某一个数据域、业务的数据集市之后，再集成各个数据集市为数据仓库。

Kimball建模采用的是维度建模，也就是我们熟悉的星型模型、雪花模型等。

Kimball架构如下图所示：（图片来源：数据仓库Inmon和Kimball架构）

针对Inmon和Kimball孰优孰劣在历史上发生过多次争论，我们不是学术派就不争论了。而是应该站在更好满足应用的视角，取各自的优势，去除各自的糟粕。Inmon方法能够涵盖企业的全域数据，与数据中台倡导的打通企业信息孤岛的理念是一致的；而Kimball从应用视角进行组织数据，更加符合数据分析人员和业务人员的对数据的理解。所以，通常情况下，业界通常采用的是混合的架构模式。

在这里推荐一下阿里的数据仓库体系，整体架构如下图所示：

如下是阿里针对各个分层给出的定义。

• 数据引入层ODS（Operation Data Store）：存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入的职责，同时记录基础数据的历史变化。
• 公共数据层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。
  • 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
  • 公共汇总层（DWS，Data Warehouse Summary）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
  • 明细数据层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。
• 数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

这里我们重点关注CDM层，相比于另外两个层次，CDM层又细分为了明细数据层、汇总数据层和公共维度层三个部分。其中明细数据层提供的是企业最细粒度的事实数据，能够体现出企业的即时视图以及历史视图，需要参考Inmon建模方法将数据按照业务主题进行拆分，并进行3NF建模，重点体现的是各个事实的现状以及事实之间的关系。汇总数据层是基于明细数据层加工形成的更大粒度的数据，是基于Kimball建模方法进行的维度建模，以公共维度层为基础形成星型模型，是对业务指标进行的最细粒度的加工和计算，实际上也是一个大而全的指标集，为上层提供具体指标计算的原材料。

关于宽表

今天争论的一个话题是，宽表应该属于数仓的哪个层级。先明确一下什么是“宽表”。

宽表，实际上是指字段比较多的数据表。这个是相比3NF来说的，3NF强调的是不允许有数据冗余，但是在实际应用中，为了便于进行查询分析，所以在进行表设计时，会将一些常用的属性也追加到事实表中，这就导致了数据冗余，也就是违背了3NF。但是这种模式则能够更好的进行数据的上卷、下钻，所以在实际项目中被广泛应用。

那么在讨论宽表应该放在数仓哪一层这个问题时，这里实际上相当于混淆了一个问题，就是宽表实际上是一种建表方式，而数据仓库分层则是数仓架构设计的模式。

那么回过头来看宽表应该放在哪个数据仓库层级呢？这取决于宽表中的数据粒度以及数据含义，也就是在数仓的各个层级中都可能存在宽表。

总结

数仓的核心在与让数据会说话，数仓的分层，越靠近上层，数据越具体，也就是能够满足的数据查询分析的需求范围越小，但是数据的价值确实越来越大。数据仓库的分层实际上就是一个数据-信息-价值的过程，通过合理的数据层次划分，能够保证数据到信息、信息到价值这个过程更加便捷。因为，数据开发的过程与软件开发的过程不同，数据开发通常做不到明确的需求，它是一个不断迭代不断清晰的过程。

写在后面

写文章是对个人知识体系的重新审视和梳理，而与人分享知识，并就知识点进行争论磨擦，则能够找到知识盲点，加深理解。

知识是一种资产，但是与其他资产不同的是，越分享它会变得越多。