目录
一、数据运营层：ODS（Operational Data Store）
1. 数据明细层：DWD（Data Warehouse Detail）
2. 数据中间层：DWM（Data WareHouse Middle）
3. 数据服务层：DWS（Data WareHouse Servce）
数据分层在数据仓库设计中扮演着关键角色，合理的分层设计有助于使整个数据体系更易于理解和使用。然而，目前网络上关于数据分层设计的文章大多只是简单提及，或者缺乏明确而详细的说明，亦或者缺乏可实际实施的方案和具体的示例说明。
因此，本文旨在提供一种通用的数据仓库分层方法，具体包括以下内容：
1、介绍数据分层的作用。
2、提出一种通用的数据分层设计，并明确分层设计的原则。
3、通过具体的例子进行说明。
4、提出可实际实施的实践建议。
接下来，我们将详细讨论这些内容。
数据分层
为什么要数据分层？
这是设计数据分层时数据仓库同学首要面临的挑战之一。类似的问题可能还有很多，例如：“数据仓库的意义何在？”、“为何需要进行元数据管理？”、“为何要关注数据质量管理？”当然，在这里我们只讨论为何要设计数据分层。
作为数据规划者，我们自然希望数据能够在整个生命周期内有条不紊地流转，使得数据的设计者和使用者都能清晰地感知到。从直观的角度来看，就像下图的左侧展示的那样，层次清晰，依赖关系一目了然。
然而，实际情况中，我们所建立的数据体系却往往是依赖关系复杂、层级混乱的。如下图的右侧所示，不经意间我们可能构建出一套表依赖结构混乱，甚至出现了循环依赖的数据体系。
因此，我们需要一套行之有效的数据组织和管理方法来使我们的数据体系更有序，这就是数据分层的出发点。尽管数据分层并不能解决所有的数据问题，但它却能带来诸多好处：
清晰数据结构： 每个数据分层都具有明确定义的作用范围和职责，使得在使用表时更容易定位和理解。
减少重复开发： 通过规范数据分层，可以开发一些通用的中间层数据，从而极大地减少重复计算的工作。
统一数据口径： 数据分层提供了统一的数据出口，使得对外输出的数据口径更为一致。
复杂问题简单化： 通过将复杂任务分解为多个层次来完成，每一层解决特定的问题，从而简化了整体任务的复杂性。
通用的数据分层设计
为了实现前述提到的数据分层的优势，我们将数据模型划分为三个主要层次：数据运营层（ODS）、数据仓库层（DW）和数据应用层（APP），如下图所示。简单来说，我们可以理解为：
-
• ODS层：存储接入的原始数据，是数据的初始存储和处理阶段。
-
• DW层：存储着我们精心设计的数据仓库中间层数据，是数据加工和准备的关键层。
-
• APP层：面向业务定制的应用数据，提供给最终业务应用使用。
接下来，我们将详细介绍这三个层次的设计。
一、数据运营层：ODS（Operational Data Store）
面向主题的 数据运营层，也被称为ODS层，是与数据源中数据最为接近的一层。在数据源中的数据经过抽取、清洗、传输（即 ETL 过程）后，被加载到这一层。这一层的数据通常按照源头业务系统的分类方式进行整理。
一般来说，为了考虑可能需要追溯数据问题的需求，对于ODS层，不建议过多进行数据清洗工作，而是直接将原始数据接入。数据的去噪、去重、异常值处理等过程可以留待后续的DWD层来完成。
二、数据仓库层：DW（Data Warehouse）
数据仓库层是我们在构建数据仓库时的核心设计层面。在这个层次上，我们从ODS层获取的数据按照主题进行组织，建立各种数据模型。DW层进一步细分为DWD（Data Warehouse Detail）层、DWM（Data Warehouse Middle）层和DWS（Data Warehouse Service）层。
1. 数据明细层：DWD（Data Warehouse Detail）
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性，后文会举例说明。
2. 数据中间层：DWM（Data WareHouse Middle）
该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
3. 数据服务层：DWS（Data WareHouse Servce）
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，可能会面临计算量过大和维度过少的问题。因此，一种常见的做法是在DWM层先计算多个小的中间表，然后再将它们拼接成一张DWS的宽表。由于宽和窄的界限不容易明确定义，也存在另一种选择，即去掉DWM这一层，只保留DWS层，将所有的数据直接放在DWS中。
三、数据应用层：APP（Application）
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
四、维表层（Dimension）
最后补充一个维表层，维表层主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
至此，我们讲完了数据分层设计中每一层的含义，这里做一个总结便于理解，如下图。
场景模拟
趁热打铁，举个例子说明一下，如下图，可以认为是一个电商网站的数据体系设计。我们暂且只关注用户访问日志这一部分数据。
在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。
为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。
在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表
然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。
最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。
技术实践
既然谈到了数据分层，那不同的层次中会用到什么计算引擎和存储系统呢，本节来简单分享一下。
数据层的存储一般如下：
Data Source：数据源一般是业务库和埋点，当然也会有第三方购买数据等多种数据来源方式。业务库的存储一般是Mysql 和 PostgreSql。
ODS 层：ODS 的数据量一般非常大，所以大多数公司会选择存在HDFS上，即Hive或者Hbase，Hive居多。
DW 层：一般和 ODS 的存储一致，但是为了满足更多的需求，也会有存放在 PG 和 ES 中的情况。
APP 层：应用层的数据，一般都要求比较快的响应速度，因此一般是放在 Mysql、PG、Redis中。
计算引擎的话，可以简单参考图中所列就行。目前大数据相关的技术更新迭代比较快，本节所列仅为简单参考。
思考
与《漫谈数据仓库和范式》一文在最后思考数据仓库和范式之间的关系一样，本文将对数据分层的原则进行思考和总结。我们将探讨为什么需要进行数据分层，以及各个层次之间的界限是什么。
个人理解数据分层的划分时，我从以下几个角度进行思考：
对应用的支持： 从这个角度来看，我们期望越靠上层次，越能够友好地支持应用。例如，APP层基本上是为应用专门设计的，易于理解。相较之下，DWS层可能会有一些理解成本，而DWM和DWD层则更加复杂，因为它们可能涉及多个维度，并需要进行复杂的计算才能满足需求。
能力范围： 我们希望80%的需求可以由20%的表来支持。换言之，大部分（80%以上）的需求都可以使用DWS层的表来支持，DWS无法支持的需求可以借助DWM和DWD层的表，而仅有极少部分的数据需求可能需要从原始日志中提取。结合第一点，我们希望以对应用非常友好的方式来支持80%的需求，而不是直接将原始日志暴露给应用方。
数据聚合程度： 我们希望上层数据的聚合程度越高越好。以ODS和DWD的数据为例，它们基本上保留了原始日志的粒度，没有进行任何聚合操作。DWM进行了轻度的聚合，仅保留了通用的维度，而DWS则进行了更高级的聚合操作，可能只保留了一到两个能够完整描述当前主体的维度。从这个角度来看，我们可以理解为我们是根据数据的聚合程度来划分数据层次的。
6242
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
