数据仓库通用开发规范

一、数据模型架构原则

数仓分层原则¹²

可靠的数仓体系往往需要清晰的数据分层结构，既要保证数据层的稳定又要屏蔽对下游的影响。

分层是解决当前业务快速的数据支撑目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，也急速数据驱动和赋能。

数仓分层要结合公司业务进行，并且需要清晰明确各层职责，一般采用如下分层结构：

下面详细描述下每层建设规范：

1.数据源层：ODS（Operational Data Store）

ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就建议不做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。

2.数据仓库层：DW（Data Warehouse）

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里从 ODS 层中获得的数据按照主题建立各种数据模型。DW 层又细分为：

• DWD（Data Warehouse Detail）层

数据明细层，将数据进行清理、整合规范化，会将脏数据、状态不一致、命名不规范都会处理掉，来提供一定的数据质量保证。另外，也会做一部分数据聚合提高数据的可用性。

• DWM（Data WareHouse Middle）层

数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。由于宽和窄的界限不易界定，也可以去掉 DWM 这一层，只留 DWS 层，将所有的数据再放在 DWS 亦可。

• DWS（Data WareHouse Servce） 层

DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或业务宽表。

3.数据应用层：APP（Application）

数据应用层，主要提供给业务产品或数据分析使用的数据，一般会提供存放到ES、Redis、PostreSQL、MySQL等系统使用

二、数仓开发规范

层次调用规范

稳定业务按照标准数据流向进行数仓开发：ODS -> DWD -> DWS -> APP。

非稳定或探索类需求，可以按照一下两个数据流进行开发：

• ODS -> DWD -> APP
• ODS -> DWD -> DWM -> APP

模型分层引用原则：

• DWM、DWS和APP 禁止使用ODS的表，ODS表只能被DWD引用
• 不能出现反向依赖，例如DWM依赖DWS的表。

数据表处理规范

1. 增量表

新增数据，增量数据是上次导出之后的新数据。

• 记录每次增加的量，而不是总量
• 增量表，只报变化量，无变化不用报
• 每天一个分区

2. 全量表

每天的所有的最新状态的数据。

• 全量表，有无变化，都要报
• 每次上报的数据都是所有的数据（变化的 + 没有变化的）
• 只有一个分区

3. 快照表

按日分区，记录截止数据日期的全量数据。

• 快照表，有无变化，都要报
• 每次上报的数据都是所有的数据（变化的 + 没有变化的）
• 一天一个分区

4. 拉链表

记录截止数据日期的全量数据

• 记录一个事物从开始，一直到当前状态的所有变化的信息；
• 拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总 量；
• 当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
• 只有一个分区

表的生命周期管理³

这部分主要是要通过对对表类型的划分与历史数据的等级划分生成相应的生命周期管理矩阵。

表类型划分

1. 事件型流水表（增量表）：事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
2. 事件型镜像表（增量表）：事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。
3. 维度表：主要用于描述数据的属性，包括维度与维度属性数据，如用户表、商品表，例如日期、时间、产品、地区、客户、部门等
4. Merge 全量表：Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区 中。
5. ETL 临时表：ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
6. 普通全量表：很多小业务数据或者产品数据，一般是直接全量拉取，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。

历史数据等级划分

主要将历史数据划分P0、Pl、P2、P3 四个等级，其具体定义如下：

• P0 ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、KPI 数据。
• Pl ：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
• P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。
• P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性。
• P4 ： 业务方有特殊存储周期要求的数据
• P5 ：日内同步表（小时任务），并存在对应每日同步表
• P6 ：用来过渡兼容的表

数据分层	表类型	P0	P1	P2	P3	P4	P5	P6
ODS层数据	事件型流水表（增量表）	永久保存	3年	2年	180天	-	7天	30天
	事件型镜像表（增量表）	永久保存	3年	2年	180天	-	-	-
	维表（全量表）	33天+极限存储（或永久保存方式代替）	33天+极限存储（或永久保存方式代替）	33天+极限存储（或永久保存方式代替）	33天+极限存储（或3年代替）	-	-	-
DWD层/DWB	事件型流水表（增量表）	永久保存	3年	2年	180天	-	-	-
	事件型镜像表（增量表）	永久保存	3年	2年	180天	-	-	-
	维表（全量表）	33天+极限存储（注：因为目前阿里极限存储功能尚未上线，故采用永久保存方式代替）	33天+极限存储（注：因为目前阿里极限存储功能尚未上线，故采用永久保存方式代替）	33天+极限存储（注：因为目前阿里极限存储功能尚未上线，故采用永久保存方式代替）	33天+极限存储（注：因为目前阿里极限存储功能尚未上线，故采用3年代替）	-	-	-
	普通全量表	3年	365天	365天	180天	-	-	-
DWS层	各粒度数据	永久保存	3年	3年	3年	-	-	-
	临时存储	ETL临时表	7天	3天	3天	3天-	-	-
APP层	运营报表	永久保留	-	-	-	-	-	-
	对外数据	7年	-	-	-	-	-	-
	内部产品	3年	-	-	-	-	-	-

三、数仓命名规范

通用命名规范

1. 数仓层次:

• ODS层：ods
• DWD层：dwd
• DWM层：dwm
• DWS层：dws
• 维度表：dim

2. 周期/数据范围：

• 日快照：d
• 增量：i
• 全量：f
• 周：w
• 拉链表：l
• 非分区全量表：a

表命名规范

1）常规表

常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去 完善的表。

规范：分层前缀[dwd|dws|ads]_业务域_主题域_XXX_更新周期|数据范围

业务域、主题域我们都可以用词根的方式枚举清楚不断完善。

更新周期主要的是时间粒度、日、月、年、周等。

2) 中间表

中间表一般出现在 Job 中，是 Job 中临时存储的中间数据的表，中间表的作 用域只限于当前 Job 执行过程中，Job 一旦执行完成，该中间表的使命就完 成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天 的中间表数据，用来排查问题）。

规范：mid_table_name_[0~9|dim]

table_name 是我们任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。

通常会遇到需要补全维度的表，这里使用 dim 结尾。

如果要保留历史的中间表，可以加上日期或者时间戳。

3) 临时表

临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。

规范：tmp_xxx

只要加上 tmp 开头即可，其他名字随意，注意 tmp 开头的表不要用来实际使用，只是测试验证而已。

4) 维度表

维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。

规范：dim_xxx

维度表，统一以 dim 开头，后面加上，对该指标的描述。

5) 手工表

手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。

一般来说，手工的数据粒度是偏细的，所以暂时统一放在 dwd 层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。

规范：dwd_业务域_manual_xxx

手工表，增加特殊的主题域，manual，表示手工维护表。

引用