最强最全面的数仓建设规范指南（二）

上节：https://xie.infoq.cn/article/3bd7bc4ac355aa1fc9e945b4f

本文将全面讲解数仓建设规范，从数据模型规范，到数仓公共规范，数仓各层规范，最后到数仓命名规范，包括表命名，指标字段命名规范等！

上节：最强最全面的数仓建设规范指南（一）

三、数仓各层开发规范

1. ODS 层设计规范

同步规范：

1. 一个系统源表只允许同步一次；

2. 全量初始化同步和增量同步处理逻辑要清晰；

3. 以统计日期和时间进行分区存储；

4. 目标表字段在源表不存在时要自动填充处理。

表分类与生命周期：

1. ods 流水全量表：

• 不可再生的永久保存；

• 日志可按留存要求；

• 按需设置保留特殊日期数据；

• 按需设置保留特殊月份数据；

2. ods 镜像型全量表：

• 推荐按天存储；

• 对历史变化进行保留；

• 最新数据存储在最大分区；

• 历史数据按需保留；

3. ods 增量数据：

• 推荐按天存储；

• 有对应全量表的，建议只保留 14 天数据；

• 无对应全量表的，永久保留；

4. ods 的 etl 过程中的临时表：

• 推荐按需保留；

• 最多保留 7 天；

• 建议用完即删，下次使用再生成；

5. BDSync 非去重数据：

• 通过中间层保留，默认用完即删，不建议保留。

数据质量：

1. 全量表必须配置唯一性字段标识；

2. 对分区空数据进行监控；

3. 对枚举类型字段，进行枚举值变化和分布监控；

4. ods 表数据量级和记录数做环比监控；

5. ods 全表都必须要有注释；

2. 公共维度层设计规范

1) 设计准则

1. 一致性

共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）

2. 维度的组合与拆分

• 组合原则：

将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌。

无相关性：如一些使用频率较小的杂项维度，可以构建一个集合杂项维度的特殊属性。

行为维度：经过计算的度量，但下游当维度处理，例：点击量 0-1000,100-1000 等，可以做聚合分类。

• 拆分与冗余：

针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表。

数据记录较大的维度，可以适当冗余一些子集。

2) 存储及生命周期管理

建议按天分区。

1. 3 个月内最大访问跨度<=4 天时，建议保留最近 7 天分区；

2. 3 个月内最大访问跨度<=12 天时，建议保留最近 15 天分区；

3. 3 个月内最大访问跨度<=30 天时，建议保留最近 33 天分区；

4. 3 个月内最大访问跨度<=90 天时，建议保留最近 120 天分区；

5. 3 个月内最大访问跨度<=180 天时，建议保留最近 240 天分区；

6. 3 个月内最大访问跨度<=300 天时，建议保留最近 400 天分区；

3. DWD 明细层设计规范

1) 存储及生命周期管理

建议按天分区。

1. 3 个月内最大访问跨度<=4 天时，建议保留最近 7 天分区；

2. 3 个月内最大访问跨度<=12 天时，建议保留最近 15 天分区；

3. 3 个月内最大访问跨度<=30 天时，建议保留最近 33 天分区；

4. 3 个月内最大访问跨度<=90 天时，建议保留最近 120 天分区；

5. 3 个月内最大访问跨度<=180 天时，建议保留最近 240 天分区；

6. 3 个月内最大访问跨度<=300 天时，建议保留最近 400 天分区；

2) 事务型事实表设计准则

• 基于数据应用需求的分析设计事务型事实表，结合下游较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程构建事务型实时表；

• 一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；

• 冗余子集原则，有利于降低后续 IO 开销；

• 明细层事实表维度退化，减少后续使用 join 成本。

3) 周期快照事实表

• 周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。

• 粒度是周期性的，不是个体的事务。

• 通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许的。

4) 累积快照事实表

• 多个业务过程联合分析而构建的事实表，如采购单的流转环节。

• 用于分析事件时间和时间之间的间隔周期。

• 少量的且当前事务型不支持的，如关闭、发货等相关的统计。

4. DWS 公共汇总层设计规范

数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用访问明细数据带来的结果不一致问题。

1) 聚集的基本原则

• 一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。

• 避免单一表设计。不要在同一个表中存储不同层次的聚集数据。

• 聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度。

2) 聚集的基本步骤

第一步：确定聚集维度

在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。

第二步：确定一致性上钻

这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。当然，我们要做的只是了解用户需要什么，然后按照他们想要的进行聚集。

第三步：确定聚集事实

在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。

3) 公共汇总层设计原则

除了聚集基本的原则外，公共汇总层还必须遵循以下原则：

• 数据公用性。汇总的聚集会有第三者使用吗？基于某个维度的聚集是不是经常用于数据分析中？如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。

• 不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。如以业务

• 区分统计周期。在表的命名上要能说明数据的统计周期，如 _Id表示最近 1 天，_td 表示截至当天，_nd 表示最近 N 天。

四、数仓命名规范

1. 词根设计规范

词根属于数仓建设中的规范，属于元数据管理的范畴，现在把这个划到数据治理的一部分。完整的数仓建设是包含数据治理的，只是现在谈到数仓偏向于数据建模， 而谈到数据治理，更多的是关于数据规范、数据管理。

表命名，其实在很大程度上是对元数据描述的一种体现，表命名规范越完善，我 们能从表名获取到的信息就越多。比如：一部分业务是关于货架的，英文名是：rack， rack 就是一个词根，那我们就在所有的表、字段等用到的地方都叫 rack，不要叫成 别的什么。这就是词根的作用，用来统一命名，表达同一个含义。

指标体系中有很多“率”的指标，都可以拆解成 XXX+率，率可以叫 rate，那我 们所有的指标都叫做 XXX+rate。

词根：可以用来统一表名、字段名、主题域名等等。

举例： 以流程图的方式来展示，更加直观和易懂，本图侧重 dwm 层表的命名 规范，其余命名是类似的道理：

第一个判断条件是该表的用途，是中间表、原始日志还是业务展示用的表 如果该表被判断为中间表，就会走入下一个判断条件：表是否有 group 操作 通过是否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层 如果不是 dwd 层，则需要判断该表是否是多个行为的汇总表（即宽表） 最后再分别填上事业群、部门、业务线、自定义名称和更新频率等信息即可。

分层：表的使用范围

事业群和部门：生产该表或者该数据的团队

业务线：表明该数据是哪个产品或者业务线相关

主题域：分析问题的角度，对象实体

自定义：一般会尽可能多描述该表的信息，比如活跃表、留存表等

更新周期：比如说天级还是月级更新

数仓表的命名规范如下：

1. 数仓层次:

公用维度：dim

DM 层：dm

ODS 层：ods

DWD 层：dwd

DWS 层：dws

2. 周期/数据范围：

日快照：d

增量：i

全量：f

周：w

拉链表：l

非分区全量表：a

2. 表命名规范

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，表示手工维护表。

3. 指标命名规范

1) 公共规则

• 所有单词小写

• 单词之间下划线分割（反例：appName 或 AppName）

• 可读性优于长度 (词根，避免出现同一个指标，命名一致性)

• 禁止使用 sql 关键字，如字段名与关键字冲突时 +col

• 数量字段后缀 _cnt 等标识...

• 金额字段后缀 _price 标识

• 天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd）

• 小时分区使用字段 hh，范围（00-23）

• 分钟分区使用字段 mi，范围（00-59）

• 布尔类型标识：is_{业务}，不允许出现空值

2) 指标命名规范

结合指标的特性以及词根管理规范，将指标进行结构化处理。

1. 基础指标词根，即所有指标必须包含以下基础词根：

2. 业务修饰词，用于描述业务场景的词汇，例如 trade-交易。

3.日期修饰词，用于修饰业务发生的时间区间。

4.聚合修饰词，对结果进行聚集操作。

5.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。

6.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。

7.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。

参考

本文档规范依据来源参考：

1. 《大数据之路：阿里巴巴大数据实践》

2. 《数仓工具箱：维度建模权威指南》

3. 美团数据平台及数仓建设实践，超十万字总结