【数据仓库】数据仓库层次化设计

一、基本概念

**1. RDS（RAW DATA STORES，原始数据存储）**

RDS作为原始数据存储层，用于存储来自各种源头的未经处理的数据。这些数据可能来自企业内部的业务系统、外部数据源或各种传感器等。RDS确保原始数据的完整性和可访问性，为后续的数据处理和分析提供原始素材。

**2. ODS（Operational Data Store，操作数据存储）**

ODS（操作性数据），是数据仓库架构中的重要组成部分。它位于数据源系统和数据仓库的数据集市之间,主要用于存储从各个业务系统抽取的原始数据。作为数据库到数据仓库的一种过渡，ODS的数据结构一般与数据来源保持一致，便于减少ETL的工作复杂性，而且ODS的数据周期一般比较短。ODS的数据最终流入DW。

ODS位于RDS之后，用于存储从RDS中提取出来的、经过初步整合的数据。ODS通常用于存储来自多个操作型系统的数据，如ERP、CRM等。它的主要作用是为数据仓库提供结构化、整合后的数据，作为后续数据处理和分析的基础。

ODS存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作性的、集成的全体信息的需求。ODS作为数据库到数据仓库的一种过渡形式，能提供高性能的响应时间。ODS中的数据是"实时值"，而数据仓库的数据却是"历史值"。

2.1 ODS的特点

ODS层的主要特点包括:

1. 面向主题: 数据按照业务主题进行组织
2. 粒度细: 保留原始数据的细节级别
3. 实时性强: 数据更新频率较高,通常为准实时或近实时
4. 数据冗余: 保留历史数据,支持数据回溯

2.2 ODS系统的作用

一般在带有ODS的系统体系结构中，ODS都具备如下几个作用：

1） 在业务系统和数据仓库之间形成一个隔离层。 
2） 转移一部分业务系统细节查询的功能。在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
3） 完成数据仓库中不能完成的一些功能。 一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据和运营指标，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。

**3. TDS（TRANSFORMED DATA STORES，转换后的数据存储）**

TDS在ODS之后，负责对数据进行清洗、转换和整合，以满足特定的业务需求或分析需求。在TDS中，数据经过一系列的处理操作，如去除重复数据、填充缺失值、转换数据类型等，以生成更加准确、一致和有用的数据集。

**4 .数据仓库（DW）

4.1 概述

数据仓库(Data Warehouse)，是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。DW保持着所有的从ODS到来的数据，并长期保存，而且这些数据不会被修改。（DW中的数据实际存储在分布式文件系统中（如HDFS）。如果想要删除数据，一般会在分布式文件系统中进行操作。而由于效率问题，数据仓库一般只读取数据，不直接对数据进行修改。）

（1） 面向主题(Subject Oriented)操作型数据库的数据组织 面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。
（2） 集成的(Integrated)数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
（3） 相对稳定的(Non-Volatile) 数据仓库的数据主要供 企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
（4） 反映历史变化(Time Variant) 数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到各个阶段的信息，通过这些信息，可以对企业的 发展历程和未来趋势做出定量分析和预测。

4.2 数据仓库的特征

特征有：
（1）效率足够高，要对进入的数据快速处理
（2）数据质量高，数据仓库是提供很多决策需要的数据支撑，DW的数据应该是唯一的具有权威性的数据，企业的所有系统只能从DW取数据，所以需要定期对DW里面的数据进行质量审，保证DW里边数据的唯一、权威、准确性。
（3）扩展性，企业业务扩展和降低企业建设数据仓库的成本考虑
（4）面向主题，数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域，数据仓库排除对决策无用的数据，提供特定主题的简明视图
（5）数据仓库主要提供查询服务，并且需要查询能够及时响应
（6）DW的数据也是只允许增加不允许删除和修改，数据仓库主要是提供查询服务，删除和修改在 分布式系统

数据仓库是一个过程而不是一个项目；
数据仓库系统是一个信息提供平台，从业务处理系统获得数据，主要以星型模型和雪花模型进行数据组织，并为用户提供各种手段从数据中获取信息和知识。

从功能结构划分，数据仓库系统至少应该包含数据获取(Data Acquisition)、数据存储(Data Storage)、数据访问(Data Access)三个关键部分。

**5. 数据集市（DM）

数据集市(Data Mart) ,为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。

面向应用。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。

需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。数据集市，以某个业务应用为出发点而建设的局部DW,DW只关心自己需要的数据，不会全盘考虑企业整体的数据架构和应用。

特征有：
（1）DM结构清晰，针对性强，扩展性好，因为DM仅仅是单对一个领域而建立，容易维护修改
（2）DM建设任务繁重，公司有众多业务，每个业务单独建立表
（3）DM的建立更多的消耗存储空间，单独一个DM可能数据量不大，但是企业所有领域都建立DM这个数据量就会增加多倍

6.如何能搭建一个体系，既能支持战略决策使用的数据仓库数据，又能兼容业务快速的变化和运营产品人员日常需求的ODS数据？

数据仓库和ODS并存方案，经过调研，发现大体上有三种解法：

（1）业务数据 － ODS － 数据仓库

（2）DB － ODS

优点：结构简单。一般的初创数据分析团队都是类似的结构，比如我们部门就应该归结到这一范畴
缺点：这样所有数据都归结到ODS，长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差。

（3）数据仓库和ODS并行

引用自：ODS、DW、DM - 知乎 (zhihu.com) 

数仓分层（ODS、DWD、DWS、DWT、ADS）和数仓建模_ods,dwd,dws,ads-CSDN博客

二、.数据仓库分层

1 数据分层思想

​数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，数据运营层、数据仓库层和数据服务层。基于这个基础分层之上添加新的层次，来满足不同的业务需求。 ​

2 数据分层的好处

（1）清晰数据结构： 每个数据分层都具有明确定义的作用范围和职责，使得在使用表时更容易定位和理解。

（2）减少重复开发： 通过规范数据分层，可以开发一些通用的中间层数据，从而极大地减少重复计算的工作。

（3）统一数据口径： 数据分层提供了统一的数据出口，使得对外输出的数据口径更为一致。

（4）复杂问题简单化： 通过将复杂任务分解为多个层次来完成，每一层解决特定的问题，从而简化了整体任务的复杂性。

3 业界常见数仓分层架构

 4 案例根据架构设计数据体系

举个例子说明一下，如下图，可以认为是一个电商网站的数据体系设计。我们暂且只关注用户访问日志这一部分数据。

在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。

为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。

在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表

然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。

最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。

5 不同的层次中用到的计算引擎和存储系统

6 如何构建一个高效的数据仓库分层体系

首先， 企业需要明确业务需求和数据特点，确定分层的粒度和层次结构。
其次， 选择合适的存储技术和工具，确保各层次数据的高效存储和访问。
最后， 建立完善的数据管理流程和规范，确保数据的准确性和安全性。

数据分层的划分时，我从以下几个角度进行思考：

对应用的支持： 从这个角度来看，我们期望越靠上层次，越能够友好地支持应用。例如，APP层基本上是为应用专门设计的，易于理解。相较之下，DWS层可能会有一些理解成本，而DWM和DWD层则更加复杂，因为它们可能涉及多个维度，并需要进行复杂的计算才能满足需求。

能力范围： 我们希望80%的需求可以由20%的表来支持。换言之，大部分（80%以上）的需求都可以使用DWS层的表来支持，DWS无法支持的需求可以借助DWM和DWD层的表，而仅有极少部分的数据需求可能需要从原始日志中提取。结合第一点，我们希望以对应用非常友好的方式来支持80%的需求，而不是直接将原始日志暴露给应用方。

数据聚合程度： 我们希望上层数据的聚合程度越高越好。以ODS和DWD的数据为例，它们基本上保留了原始日志的粒度，没有进行任何聚合操作。DWM进行了轻度的聚合，仅保留了通用的维度，而DWS则进行了更高级的聚合操作，可能只保留了一到两个能够完整描述当前主体的维度。从这个角度来看，我们可以理解为我们是根据数据的聚合程度来划分数据层次的。

参考自：数据仓库内容分享(六)：数据仓库层次化设计_数据明细层-CSDN博客

三、问题

4.1 DWS 与 DWD？

问答一： dws 和 dwd 的关系

问：dws 和dwd 是并行而不是先后顺序?

答：并行的，dw 层

问：那其实对于同一个数据，这两个过程是串行的?

答：dws 会做汇总，dwd 和 ods 的粒度相同，这两层之间也没有依赖的关系

问：对呀，那这样 dws 里面的汇总没有经过数据质量和完整度的处理，或者单独做了这种质量相关的处理，为什么不在 dwd 之上再做汇总呢?我的疑问其实就是，dws的轻度汇总数据结果，有没有做数据质量的处理?

答：ods 直接到 dws 就好，没必要过 dwd，我举个例子，你的浏览商品行为，我做一层轻度汇总，就直接放在 dws 了。但是你的资料表，要从好多表凑成一份，我们从四五份个人资料表中凑出来了一份完整的资料表放在了 dwd 中。然后在 app 层，我们要出一张画像表，包含用户资料和用户近一年的行为，我们就直接从dwd中拿资料， 然后再在 dws 的基础上做一层统计，就成一个app表了。当然，这不是绝对，dws 和 dwd 有没有依赖关系主要看有没有这种需求。

4.2 ODS与DWD区别？

问：还是不太明白 ods 和 dwd 层的区别，有了 ods 层后感觉 dwd 没有什么用了。

答：嗯，我是这样理解的，站在一个理想的角度来讲，如果 ods 层的数据就非常规整，基本能满足我们绝大部分的需求，这当然是好的，这时候 dwd 层其实也没太大必要。 但是现实中接触的情况是 ods 层的数据很难保证质量，毕竟数据的来源多种多样，推送方也会有自己的推送逻辑，在这种情况下，我们就需要通过额外的一层 dwd 来屏蔽一些底层的差异。

问：我大概明白了，是不是说 dwd 主要是对 ods 层做一些数据清洗和规范化的操作，dws 主要是对 ods 层数据做一些轻度的汇总?

答：对的，可以大致这样理解。

4.3 app层干什么的？

问答三：app 层是干什么的?

问：感觉数据集市层是不是没地方放了，各个业务的数据集市表是应该在 dwd 还是在 app?

答：这个问题不太好回答，我感觉主要就是明确一下数据集市层是干什么的，如果你的数据集市层放的就是一些可以供业务方使用的宽表表，放在 app 层就行。如果你说的数据集市层是一个比较泛一点的概念，那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。

问：那存到 Redis、ES 中的数据算是 app层吗?

答：算是的，我个人的理解，app 层主要存放一些相对成熟的表，能供业务侧使用的。这些表可以在 Hive 中，也可以是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中。

四、数据模型的评价标准

数据模型建设的怎么样，极度依赖规范设计，如果代码风格是“千人千面”，那么恐怕半年下来，业务系统就没法看了。没有什么比“数据系统”更看重“法制”了，规范体系不仅能保障数据建设的一致性，也能够应对业务交接的情况，更能够为自动化奠定基础。

1. 业务过程清晰：ODS就是原始信息，不修改；DWD面向基础业务过程；DIM描述维度信息；DWS针对最小场景做指标计算；ADS也要分层，面向跨域的建设，和面向应用的建设；
2. 指标可理解：按照一定业务事务过程进行业务划分，明细层粒度明确、历史数据可获取，汇总层维度和指标同名同义，能客观反映业务不同角度下的量化程度；
3. 核心模型相对稳定：如果业务过程运行的比较久，过程相对固定，就要尽快下沉到公共层，形成可复用的核心模型；
4. 高内聚低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。