数据仓库实践：数仓分层

分层的目的

• 清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解;
• 复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题;
• 统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径;
• 减少重复开发：规范数据分层，开发通用的中间层，可以极大地减少重复计算的工作;

数据仓库的分层依现状而定，并没有一个最佳实践，但即使数据的情况千千万万，也会至少有相互接近的实践方式，以减少实践成本。

一般情况下，数据开发的过程分为ODS层、DW层、ADS层就足够使用了，因为简单的数据如果不分析现状强行按照范式开发也会导致额外的成本，比如数据冗余虽然在一定层度上提到了开发过程中的读取效率，减少了关联（join）表的数量、频率和代码开发量，但会提高存储成本，也会提高保持数据一致性的成本。

同时为了适应更大规模的数据开发需求，我们可以灵活地对ADS层、DW层和DW层中的DIM区进行细分，类似spring服务开发中为了适应更大的服务规模将Service层进行细分，或者springboot微服务中MVC三层架构向DDD领域驱动设计四层架构的演进，从数据本身的结构上主动兼容业务规模扩大带来的结构变化。

ADS层细分

APP层：Application 应用层

APP层一般用于数据报表、Redis内存数据库热点数据、机器学习等数据消费需求，因为这些需求需要完整清洗后的数据，并且为了适应报表【同一维度展开多个粒度】的下钻需求 和 机器学习【独热编码（one-hot）】的编码需求等类似需求，APP层大多会是【宽表】；

同时为了降低管理复杂度，一个APP层的表通常直接对应一个机器学习项目，或者直接对应一个报表产产品；

DM层：Data Mart 数据集市层

DM层与APP层类似，但区别于APP层，APP层一般由数据仓库提供所有的计算消耗，提供【现成的、不再需要继续处理的】数据内容，DM层一般面对【有自行二次加工、继续处理数据能力的】服务对象，比如restful api,或者业务系统。

DW层细分

DWS层：Data Warehouse Service 数仓服务层

DWS层一般在雪花模式上更进一步，使用必然出现的星座模式，同时也意味着DWS层中的数据结构高度的适应于分析类型的需求，此时星座模式如果管理得当，即使规模不大也能显现出诸如元数据、数据血缘、术语、词根等概念的实在雏形，因为许多手工报表、业务流程汇报过程、决策过程所用到的数据是高度一致的，只是各个部门、各个业务系统的说法、术语不同，这进一步提出对元数据的管理开发需求，从而促进元数据管理、术语管理等流程的建设。

DWM层：Data Warehouse Middle 数仓中间层

DWM层除了按照业务数据本身的灵活处理需求使用雪花模式建模外，还会使用诸如流水表、拉链表、全量表、增量表等表结构实现并满足如历史数据变化履历，时间序列，更新频次等分析需求。在中间层，开发人员将着重于计算性能的要求，尤其是查询性能，许多传统数仓向大数据数仓迭代转型的需求一般都是从DWM层出现的。比如数据存储平台处理向前半年、一年数据量的性能需求。

DWD层：Data Warehouse Details 数仓明细层

DWD层 一般按照星型模式处理并轻度汇总来自ODS层的原始数据，比如：剔除空值，剔除无关数据，统一日期字符格式，统一字段命名格式等，除非遇见性能等问题，基本结构仍然高度与原系统保持一致。

DIM层细分

公共维度

不因业务变化而改变的维度数据

• 时间
• 地区
• …

业务维度

业务部门负责人，业务流程定义的维度，一般包括大量的主数据

• 部门
• 物料（料号）
• 产品
• 厂区
• …

数据应用维度

适应数据开发过程汇总的维度，一般是业务维度的变体

• 全路径BOM变体
• …

宽表VS星型模式

如前所述，在实际情况中需要根据现状灵活使用多种开发，同时这符合如《数据仓库工具箱——维度建模权威指南（第3版）》所述目标：简化及速度；

2.3.6 非规范扁平维度

一般来说，维度设计者需要抵制多年来操作型数据库设计所带来的对规范化设计的要求，并将非规范化的多对一固定深度层次引入扁平维度行的不同属性。非规范化维度能够实现维度建模的双重目标：简化及速度。

这种【非规范化维度】一般体现在我们熟知的【宽表】上，因为宽表一般会额外包含维度的不同层次，比如日期维度中的日、月、年，它们的优势是查询时不需要过多关联原有维度表，从而局部地提高查询效率，这样的优势适用于接近报表、API接口等数据消费端，也包括数据开发人员通过数据操作工具查看验证等开发操作。因为消费端几乎总是查询的频率大于插入、更新、删除等操作的频率。

数据开发中接近规范化设计的设计方法是星型模式，所以星型模式设计方法的优势与操作行数据库的优势相似，相对于非规范化设计，在插入、更新等操作时不必关联与主要内容不相关的内容，从而降低操作的复杂性和性能消耗。同规范化设计的目标一样，这样的优势主要适用于程序的操作过程，在数据开发的场景下，即是各种自动化的汇总计算任务，比如spark，kettle等计算引擎和工具的汇总定时任务。

故本文的建议是，在实践中接近数据消费一端，即ADS层和部分DW层如DWS层，更多使用【宽表】等非规范化设计，以适应多样化的消费场景。

接近数据来源的，即DWD层和部分DWM层，更多使用规范化的设计，并在此基础上再根据操作方式等其他因素灵活处理。

最新内容可扫码前往公众号继续查看