数据仓库分层建模和规范

仓库分层

1.1 STG 缓冲层

Staging

将业务数据同步过来，不做任何转换，与业务数据库同构。​

主要用于因为特殊原因，无法在 ODS 一步完成业务数据快照的场景。如每天按照 update_time 把 T 日更新的记录同步到 STG 层，但 STG 表中会有重复的记录，无法方便地直接使用，需要做一次去重后写入 ODS 层。

1.2 ODS 存储层（操作性数据）

Operational Data Store

将业务数据快照过来，不做任何转换，与业务数据库同构。

一般存在 HDFS 上，即 Hive 或者 Hbase，Hive 居多。

1.3 EXT 对外输出缓冲层

External

STG 和 ODS 主要用于从外部数据源获取数据的缓冲和存储。有些时候，还需要直接把数仓的数据同步到外部数据源，用 EXT 层的表做为缓冲和存储，与外部数据表同构。

2.1 DWD 数据明细层

Data Warehouse Detail

数仓建设的核心。

对数据做规范化处理（编码转换、清洗、统一格式、脱敏等），不做横向整合。

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

DWD 层要做的就是将数据 清理、整合、规范化，脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的 数据都会被处理。

DWD 层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。在 DWD 层会根据维度模型，设计事实表和维度表，也就是说 DWD 层是一个非常规范的、高质量的、可信的数据明细层。

2.2 DIM 维度表

Dimension

维度指的是观察事物的角度，提供某一业务过程事件涉及用什么过滤和分类的描述属性，「谁、什么时候、什么地点、为什么、如何」干了什么，维度表是维度建模的基础和灵魂。

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

3 DWT / DWM，主题宽表层 / 轻度汇总层

Data Warehouse Topic / Data Warehouse Middle

对 DWD 各信息进行关联整合，输出主题宽表（面向业务过程，不同业务过程的信息不冗余建设，采用外键形式）。

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

4 DWA / DWS / DM，汇总层 / 数据集市层

Data Warehouse Aggregation / Data Warehouse Service / Data Market

集中建设通用性维度和指标，降低业务需求开发成本。

按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询、OLAP 分析、数据分发等。

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

在实际计算中，如果直接从 DWD 或者 ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在 DWT/DWM 层先计算出多个小的中间表，然后再拼接成一张 DWA/DWS/DM 的宽表。

5 APP / ADS，应用层

Application / Application Data Service

面向业务需求进行定制开发。

主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、 Redis 等系统中供线上系统使用（因为一般都要求比较快的响应速度），也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

层间数据流向

稳定业务 / 标准数据流向

ODS → DWD → DWT → DWA → APP

• 如果出现 DWT 缺失的情况，说明主题域未覆盖全。应将 DWD 数据落到 DWT 中。对于使用频度非常低的表，也允许直接 DWD → DWA。
• 尽量避免在 DWA 宽表中使用 DWD 又使用（该 DWD 所属主题域的）DWT。
• DWT、DWA、APP 层禁止直接使用 ODS。ODS 的表只能被 DWD 引用。
• 禁止反向依赖。

非稳定业务 / 探索性需求

ODS → DWD → APP
或
ODS → DWD → DWT → APP

主题划分

主要考虑两类划分：面向业务、面向分析。

• 面向业务：按照业务进行聚焦，降低对业务理解的难度，并能解耦复杂的业务。将实体关系模型进行变种处理为「实体」与「业务过程」模型。
  • 实体：定义为业务过程的参与体；
  • 业务过程：定义是由多个实体作用的结果，实体与业务过程都带有自己特有的属性。
• 面向分析：按照分析聚焦，提升数据易用性，提高数据的共享与一致性。按照分析主体对象不同及分析特征，形成分析域主题在 DWA 进行应用，例如销售分析域、组织分析域。

表命名规则

通用规范

• 使用 stg、ods、ext、dim、dwd、dwt、dwa、app、tmp 等分层作为前缀
• 各部分用下划线分割
• 各部分使用小写英文单词
• 以字母为开头
• 长度尽量不要超过 64 个字符
• 表名的自定义部分不要用非标准的缩写

各层表名格式

• {stg|ods|ext}[_外部存储类型]_业务库名__业务表名[_分区]
  • 外部存储类型是 mysql 的可以省略
  • 注意库名和表名之间是双下划线 __
• dim[_主题[_子主题]]_维度名[_{detail|ext}][_分区]
• {dwd|dwt|dwa|app}[_主题[_子主题]]_自定义表名[_分区]
• tmp[_主题[_子主题]]_业务表名[_序号]
  • 序号：01~99
  • 细则待定
• 全量快照分区表，可以用视图来索引最新有效的分区
  • 原表名（不含分区）_v
  • 如原表为 stg_auth__users_da，对应的最新分区视图为 stg_auth__users_v

表名中的分区信息

格式：{h|d|w|m|q|y}{a|i}

• 时间范围
  • 小时：h
  • 日：d
  • 周：w
  • 月：m
  • 季度：q
  • 年：y
• 分区内数据范围
  • 全量：a
  • 增量：i

举例：

• 每小时一个全量快照分区：ha
• 每天一个增量数据分区：di

附：ETL 任务 vs 表分区

ETL 任务其实并不关心数仓表的分区情况，除非要用 drop partition 等操作分区的方式进行存量数据清理。

• 快照/全量 ETL 任务，关心的是快照附加日期时间字段的粒度/精度，如天、月、小时等。
• 增量 ETL 任务，关心的是增量数据时间范围的粒度，如一次最少同步一天的增量数据，还是一个月，等等。

通用的 ETL 脚本（即不是某个表专用的 ETL）的后缀，表达的是数据同步的粒度和范围，格式为：

• _时间粒度_数据范围
  • 时间粒度：hour、day、week、month、quarter、year
  • 数据范围：ss（快照/全量）、inc（增量）

为了强调跟表分区不是一个东西，这里使用单词/缩写。而表名为了节省字符数，使用单字母。

快照/全量 ETL 任务，如果表的一个分区只放一份快照，则可以使用 drop partition 进行清理，否则不可以。如：

• ods__table_da, etl_day_ss: 可以 drop partition
• ods__table_ma, etl_day_ss: 不可以 drop partition（一个分区里存放一个月内的所有快照）

增量 ETL 任务，如果数据的时间粒度和分区的粒度一致，且只同步单一粒度的数据，则可以使用 drop partition。

• ods__table_mi, etl_month_inc: 同步单一月份，可以 drop partition
• ods__table_mi, etl_day_inc: 同步一天数据，不可以 drop partition（分区里还有同月内其他天的数据）
• ods__table_di, etl_day_inc: 同步一天数据，可以 drop partition
• ods__table_di, etl_day_inc: 不同多天数据，理论上可以多次 drop partition，但目前暂不实现