数据大体系（一）——数据纵向分层

引

这几日，疫情又变得更加严重了，我往返的两座城市都纷纷带上了*，于是我成了王者两星人员。

今天受好友启发，可以写一个数据大体系的基础的连载。过去我以为我所知道的知识是一种 common sense， 所以大家应该都知道。然而我以为并非我以为的以为，大家并不一定都知道。所以开始写下了下面的内容。

在本节内容里，你可以学习到：

1. 传统数仓建设体系里，如何进行分层

分层概论

数据仓库的建设，和传统的系统建设有一些不同。我们过去讲究的系统建设，更多是面向事务的 OLTP 系统，讲究的是系统高响应，低延时等特点。而对于数仓型的应用，则更多强调的是 OLAP，面向分析型的体系搭建。

既然目的不同，那么其建设方法论也就一定不同。对于数据仓库/数据分析而言，如果每次我们的分析都是从海量的关系型数据库表里取出的话，那么会有以下几个弊端：

1. 性能损失：事务型的关系型数据库的目标是处理线上系统业务，如果分析都从里取，会对已有系统造成性能损耗

2. 时间冗长：由于数据分布在不同系统、不同业务体系，因此每次都需要从各个系统里抓取数据，对数据开发人员的时间以及运算机器的时间都是一种沉重的负担。

为了解决这个问题，我们往往会去：

1. 搭建一个其他的专门用于分析的数据库，解决性能损失问题

2. 将散落在各个应用系统的数据，在该专门用于分析的数据库里再存储一份
   

ODS 贴源层

上面提到，我们会将散落在各个应用系统的数据再额外保存一份，这额外保存的一份，我们一般就称之为 ODS 贴源层数据，这里的分层也就是贴源层。

贴源层最主要的目的，便是每日将业务系统的数据进行一份镜像备份，以提供更高层的数据库表进行使用。

DWD 明细层

贴源层之上，我们一般称之为 DWD 明细层。这一层的任务是什么？

我们都知道，一般的业务系统的数据库设计，都习惯于遵循三范式。这里我们来复习一下什么是三范式：

1. 范式一：确保每一列都保持原子性

2. 范式二：范式一的基础上，确保表中的每一列都与主键有关

3. 范式三：范式二的基础上，确保每一列都与主键直接相关，而不是间接相关

在三范式基础上，业务系统会构建自己的 ER 图体系，以满足我们的日常业务需求。

然而，数据仓库天生是为了分析服务的，所以我们更加系统，能有一张表，能将一个主体具备的属性都放在一起，这样每次在进行统计形成指标时，属性都有成为一个维度的潜力。如此一来，便能加速报表、分析的数据开发。从这个角度上看，DWD 我们又常常喊它为‘大宽表’。但我们并不能说‘大宽表’就是 DWD，因为更高层的数据库表设计也会有‘大宽表’的存在。DWD 的设计，往往是基于某个特殊的实体来进行设计，如会员 DWD、供应商 DWD 等等。而 DWD 中的每一条数据都是关于这个实体的一条明细数据。

DWS 轻聚合层

DWD 明细层列好后，DWS 轻聚合层，主要做的事情，是将 DWD 或者 ODS 层的数据，按照报表、分析等需求进行聚合。一般而言，我们在搭建 DWS 这一层时，可以看看 DWD 这一层主体都有哪些属性，按照对应属性进行聚合，就能够形成一些对应的聚合性的指标。什么是指标？这是个好问题，改天另起一篇来写写。

总而言之，DWS 层，主要处理的是一些小型的、轻的聚合性指标，以供其他的上层进行数据调用。

DM/ADS 层

DM/ADS 这一层开始，主要面向的便是应用想要看到的数据了。有些企业会将 DM 单独拎出来作为数据集市存在，这样的话其他应用想要调用任何的数据指标都能够直接从 DM 这一层里的某个主题域进行读取。而 ADS 则更加地贴近数据应用，如搜索推荐、精排、大屏展现等，往往都是从 ADS 层来出具数据。

Why？

为什么要搞那么多花里胡哨的？每次我都从 ods 层取数然后写 SQL 不就行了么？我还搞那么多层做啥？你还真别说，真有很多企业就是这样玩的。一个大 SQL 几千行，SQL 就是生产力，SQL 就是一切！

而我们分层的答案是什么？：复用。

我通过分层产生出中间层数据，可以供更多上层数据表业务进行复用，而不必每次都需要所有开发人员都需要了解完所有的数据地图才能够进行开发。如此一来，组织便可开始进行分工，从而提升我们的整体数据研发效率。

结

此篇非常简洁地对传统的数据仓库建设中，用到的分层概念做了一些科普/普及。而在现实的实际操作中，还会有更多规范性的内容存在，如：

1. 底层不能调用上层数据库表的内容

2. 每个层的命名内容规范等

下篇文章，我们就接着这个话题，去聊聊每个层的一些命名规范的事儿。

于辛丑年冬月初六