数据分层是数据仓库设计的重要环节，良好的分层设计使整个数据体系更容易理解和使用。 目前，大多数可在互联网上搜索到的文章都只是提到数据层的设计，或者缺乏清晰详细的说明，或者缺乏可落地的实现方案，或者缺乏具体的示例。
1 .为什么要设计数据分层？ 这是数据仓库学生在设计数据分层时首先要挑战的问题，类似的问题是“为什么要建立数据仓库？ ”等等，可能有很多。“为什么要进行元数据管理？ ”、“为什么要进行数据质量管理？ 中选择所需的族。 当然，这里只谈谈为什么要进行设计数据的分层。
作为数据的策划人，我们一定希望自己的数据有序流动，数据的整个生命周期都能被设计者和使用者清晰地感知。 直观上，层次清晰，依存关系直观，如下图所示。
但是，在很多情况下，我们完成的数据体系很复杂，层次混乱。 如下图所示，在不知不觉中，表依赖结构可能会混乱，形成循环依赖的数据体系。
因此，为了使数据体系更加系统，需要有效的数据组织和管理方法。 这就是数据分层。 数据分层并不能解决所有的数据问题，但数据分层提供了以下好处：
明确数据结构：每个数据层都有作用域和作用，使用表时更容易定位和理解
减少重复开发：通过规范数据分层和开发公共中间层数据，可以减少大量的重复计算
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
简化复杂问题：将一个复杂的任务分解为多个步骤来完成，每层解决特定的问题
2 .典型的数据分层设计为了满足上述数据分层的优点，将数据模型分为ODS、DW、APP三个层次。 如下图所示。 简单来说，**ODS层存储访问源数据，DW层存储重点设计的数据仓库中间层数据，可以理解为APP是为业务定制的APP数据。 *详细说明这三层的设计。
一、数据运营层：操作数据库(ODS )“面向主题”数据运营层，也称为ODS层，是最接近数据源中数据的层。 数据源中的数据被提取、清洗、传输，也称为传说中的ETL后被载入到基本层。 本层数据总体上多按照源业务系统的分类方式进行分类。
通常，为了考虑后续，需要追溯数据，因此不推荐对该层进行过多的数据清洗操作，直接访问原始数据即可，数据的噪声去除、噪声去除、异常值处理等处理可以在之后的DWD层中进行
二、数据仓库层： dw(datawarehouse )数据仓库层是我们做数据仓库时核心设计的层，这里从ODS层获得的数据按照主题建立各种数据模型。 DW层细分为数据仓库详细信息(dwd )层、DWM (数据仓库中间)层和dws (数据仓库服务)层。
1 .数据细节层：数据仓库细节(dwd )该层一般保持与ODS层相同的数据粒度，且提供一定的数据质量保证。 另外，为了提高数据细节层的易用性，该层采用了一些降维方法，将维度降维到事实表中，减少事实表与维度表的关联。
此外，该层还进行了部分数据聚合，将同一主题的数据合并到一个表中，从而提高数据的可用性。 稍后我会举例说明。
2 .数据中间层：数据仓库中间件(dwm )该层基于DWD层的数据，对数据进行轻度聚合操作，生成一系列中间表，提高公共指标的复用性，减少重复加工。
直观上，对共同的核心维度进行聚合操作，计算相应的统计指标。
3 .数据服务层：数据仓库服务(dws )也称为数据集市或宽表。 基于流量、订单、用户等业务划分，生成用于提供后续业务查询、OLAP分析、数据发布等的多字段平台。
一般来说，此层次结构中的数据表相对较少，一个表涵盖许多业务内容，字段较多，因此此层次结构中的表有时也称为宽表。
在实际计算中，直接从DWD和ODS计算宽表的统计指标的话，由于存在计算量过多、维数过少的问题，所以一般在DWM层中首先计算出多个小的中间表，并将其合并到一张DWS的宽表中。 由于宽边界和窄边界难以定义，可以取消DWM层，只留下DWS层，将所有数据放置在DWS上。
三、数据应用层： app(application )在这里主要是数据产品和提供数据分析的数据，一般存储在ES、PostgreSql、Redis等系统用于在线系统，Hive或比如我们常说的报告数据，一般都放在这里。
四.维表层(Dimension )最后补充一个维表层，维表层主要包括两部分数据。
基数维度高的数据：一般是用户数据表、商品数据表这样的数据表。 数据量可能在千万或亿级。
低基数维数据：一般是与枚举值对应的中文语义和日期维表等配置表。 数据量可能是一位数或几千几万。
到此为止，我们
讲完了数据分层设计中每一层的含义，这里做一个总结便于理解，如下图。 3.实战数据分层(举个栗子)趁热打铁，举个栗子说明一下，如下图，可以认为是一个电商网站的数据体系设计。我们暂且只关注用户访问日志这一部分数据。
在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。
为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。
在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表
然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。
最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。
备注：例子只是为了简单地说明每一层的作用，并不是最合理的解决方案，大家辩证地看待即可。
4.技术实践既然谈到了数据分层，那不同的层次中会用到什么计算引擎和存储系统呢，本节来简单分享一下。
数据层的存储一般如下：
Data Source：数据源一般是业务库和埋点，当然也会有第三方购买数据等多种数据来源方式。业务库的存储一般是Mysql 和 PostgreSql。
ODS 层：ODS 的数据量一般非常大，所以大多数公司会选择存在HDFS上，即Hive或者Hbase，Hive居多。
DW 层：一般和 ODS 的存储一致，但是为了满足更多的需求，也会有存放在 PG 和 ES 中的情况。
APP 层：应用层的数据，一般都要求比较快的响应速度，因此一般是放在 Mysql、PG、Redis中。
计算引擎的话，可以简单参考图中所列就行。目前大数据相关的技术更新迭代比较快，本节所列仅为简单参考。
5.总结我个人从这几个角度来理解数据分层的划分：
从对应用的支持来讲，我们希望越靠上层次，越对应用友好。比如APP层，基本是完全为应用来设计的，很易懂，DWS层的话，相对来讲就会有一点点理解成本，然后DWM和DWD层就比较难理解了，因为它的维度可能会比较多，而且一个需求可能要多张表经过很复杂的计算才能完成。
从能力范围来讲，我们希望80%需求由20%的表来支持。直接点讲，就是大部分（80%以上）的需求，都用DWS的表来支持就行，DWS支持不了的，就用DWM和DWD的表来支持，这些都支持不了的极少一部分数据需要从原始日志中捞取。结合第一点来讲的话就是：80%的需求，我们都希望以对应用很友好的方式来支持，而不是直接暴露给应用方原始日志。
从数据聚合程度来讲，我们希望，越上层数据的聚合程度越高，看上面的例子即可，ODS和DWD的数据基本是原始日志的粒度，不做任何聚合操作，DWM做了轻度的聚合操作只保留了通用的维度，DWS做了更高的聚合操作，可能只保留一到两个能表征当前描述主体的维度。从这个角度来看，我们又可以理解为我们是按照数据的聚合程度来划分数据层次的。
数据分层的设计，在某种程度上也需要通过数据命名来体现，本文的核心在于讲解数据分层的思想和方法，后面会有单独的文章来分享该如何根据数据分层来设计数据表的命名规范。