离线数仓-03-数仓系统搭建(ODS,DIM,DWD,DWS,ADS)_dataworks dwb dwd dws ads ods dim

数仓分层

为什么要分层

数据分层是使用一种有效的数据组织和管理方法来让我们的数据体系更有序。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

• 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
• 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
• 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

我们将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP）：

• ODS层存放的是接入的原始数据经；
• DW层是存放我们要重点设计的数据仓库中间层数据；
• APP是面向业务定制的应用数据。

数据运营层：ODS（Operational Data Store）

“面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。

一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，保持数据原貌不做任何修改，保留历史数据，储存起到备份数据作用，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

数据一般采用lzo、Snappy、parquet等压缩格式；创建分区表，防止后续的全表扫描，减少集群资源访问数仓的压力，一般按天存储在数仓中。

数据仓库层：DW（Data Warehouse）

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题进行分流建立各种数据模型。DW层又细分为 **DWD（Data Warehouse Detail）**层、**DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层 **等。

维表层：DIM（Dimension）

维度层，保存维度数据，主要是对业务事实的描述信息，不适一个具体业务事实，例如何人，何时，何地等。

维表层主要包含两部分数据：

• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别；
• **低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。**数据量可能是个位数或者几千几万。

数据明细层：DWD（Data Warehouse Detail）

DWD层：对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）、脱敏等。DWD层是以业务过程为驱动，按业务事实进行划分，保存业务事实明细，一行信息代表一次业务行为，例如一次下单。

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

数据中间层：DWM（Data WareHouse Middle）

该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

• 数据生成方式：由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
• 日志存储方式：内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dwb,表名：初步考虑格式为：dwb日期业务表名,待定。
• 旧数据更新方式：直接覆盖

数据服务层：DWS（Data WareHouse Servce）

又称数据集市或宽表。按照主题划分，对应着维度表，如方访客、地区、商品、用户、优惠卷等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。按天进行轻度汇总，一行信息代表一个主题对象一天的汇总行为，例如一个用户一天下单次数。

DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。

一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

• 数据生成方式：由轻度汇总层和明细层数据计算生成。
• 日志存储方式：使用impala内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dm,表名：初步考虑格式为：dm日期业务表名,待定。
• 旧数据更新方式：直接覆盖

主题数据层：DWT(Data WareHouse Topic)

也是构建一个宽表，只不过DWS层的粒度是对当日用户汇总信息，而DWT层是对截止到当日、或者近7日、近30日等的汇总信息。

数据应用层：APP（Application）

应用层是根据业务需要，由前面几层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用，也就是主要提供给数据产品和数据分析使用的数据，对各大主题指标分别进行分析。一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

这里面也主要分两种类型：

1. 每日定时任务型：比如我们典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。 这种任务经常使用 Hive、Spark 或者生撸 MR 程序来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
2. 实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用 Spark Streaming、Storm 或者 Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。

• 数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。
• 日志存储方式：使用impala内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：暂定apl，另外根据业务不同，不限定一定要一个库。(其实就叫app_)就好了
• 旧数据更新方式：直接覆盖。

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

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

数据集市与数据仓库概念

数据集市(Data Market)，现在市面上的公司和书籍都对数据集市有不同的概念。

数据集市则是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级的，一般只能为某个局部范围内的管理人员服务。

数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段。

数据仓库是企业级的，能为整个企业各个部门的运作提供决策支持；而数据集市则是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。

数据集市按数据的来源分为以下两种：

• 从属数据集市：其数据直接来自于中央数据仓库。该结构能保持数据的一致性。一般为那些访问数据仓库十分频繁的关键业务部门建立从属的数据集市，能提高查询反应速度。
• 独立数据集市：独立数据集市的数据子集来源于各生产系统，许多企业在计划实施数据仓库时，往往处于投资方面的考虑，首先建成独立数据集市，用来解决个别部门较迫切的决策问题。

数据集市容易产生数据孤岛问题。

数仓命名规范

（1）表命名

• ODS层命名为ods_表名
• DIM层命名为dim_表名
• DWD层命名为dwd_表名
• DWS层命名为dws_表名
• DWT层命名为dwt_表名
• ADS层命名为ads_表名
• 临时表命名为tmp_表名

（2）脚本命名

• 数据源_to_目标_db/log.sh

• 用户行为脚本以log为后缀；业务数据脚本以db为后缀。

（3）表字段类型

• 数量类型为bigint

• 金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位

• 字符串(名字，描述信息等)类型为string

• 主键外键类型为string

• 时间戳类型为bigint

数仓理论

范式理论

（1）范式概念

数据建模必须遵循一定的规则，在关系建模中，这种规则就是范式。

目的：采用范式，可以降低数据的冗余性。

为什么要降低数据冗余性？

• 十几年前，磁盘很贵，为了减少磁盘存储。
• 以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
• 一次修改，需要修改多个表，很难保证数据一致性

缺点：范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

分类：目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

（2）函数依赖

（3）三范式区分

关系建模与维度建模

关系建模和维度建模是两种数据仓库的建模技术。关系建模由Bill Inmon所倡导，维度建模由Ralph Kimball所倡导。

（1）关系建模

关系建模将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。关系模型如图所示，从图中可以看出，较为松散、零碎，物理表数量多。

关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

（2）维度建模

维度模型如图所示，从图中可以看出，模型相对清晰、简洁。

维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单，故查询简单，查询效率较高。

维度表和事实表（重点）

（1）维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。

维表的特征：

• 维表的范围很宽（具有多个属性、列比较多）

• 跟事实表相比，行数相对较小：通常< 10万条

• 内容相对固定：编码表

时间维度表：

（2）事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，2020年5月21日，宋宋老师在京东花了250块钱买了一瓶海狗人参丸。维度表：时间、用户、商品、商家。事实表：250块钱、一瓶。

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。

事实表的特征：

• 非常的大

• 内容相对的窄：列数较少（主要是外键id和度量值）

• 经常发生变化，每天会新增加很多。

1）事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

3）累积型快照事实表

**累计快照事实表用于跟踪业务事实的变化。**例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

维度模型分类

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

数据仓库建模（绝对重点）

ODS层

（1）HDFS用户行为数据

（2）HDFS业务数据

（3）针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

• 保持数据原貌不做任何修改，起到备份数据的作用。
• 数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
• 创建分区表，防止后续的全表扫描

DIM层和DWD层

DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实

（1）选择业务过程

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

（2）声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

• 订单事实表中一行数据表示的是一个订单中的一个商品项。
• 支付事实表中一行数据表示的是一个支付记录。

（3）确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

（4）确定事实

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。

DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

DWS层与DWT层

DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

• 问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
• 处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

那怎么设计能避免重复计算呢？

针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

总结：

• 需要建哪些宽表：以维度为基准。
• 宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
• DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

ADS层

对电商系统各大主题指标分别进行分析。

数仓环境搭建

Hive环境搭建

Hive安装

详看组件安装：