数仓维度建模系列-数仓规范篇

本系列将持续更新数仓建模相关知识，将学习到的理论知识和工作实践结合起来，总结沉淀下来，积跬步成千里。

上一篇介绍了维度建模体系的搭建，这次来分享下搭建数据仓库涉及的各种规范。

 

分享我工作中遇到的一个小案例：

小A：我发现XXX这个历史累计指标既可以从服务端出，又可以从日志出，这2份数据源貌似有差异

小B：是的，服务端记录的是当前还存在的，日志会把删除的也记下来

小A：嗯，2份数据源会导致数据不一致的情况，我觉得我们应该从指标命名上区分开来

小B：嗯，我这边是这么记得：服务端的直接从后端表获取，我直接放在维表中，且不加_std

小A：啊？我不是这么写的呢，我是想在前面加个后缀呢

小B：。。。

小A：。。。

 

案例虽小，但折射出来的问题是：每个人都有自己的一套准则，一个数仓几套准则的话，业务怎么用？新人怎么了解？指标一致性怎么保证？所以需要建设数仓标准化规范，保持队形。

另外一方面，所谓"前人留坑、后人填坑"，接盘侠一般会很痛苦，好的规范一定程度上可以降低接盘侠的痛苦。比如版本迭代规范，可以很好的追溯新指标上线情况、bug修复情况、数据回刷情况等。

数据规范是数仓体系建设的"语言"，是数据使用的说明书和翻译官，同时也是数据质量的保驾护航者。采用标准化、系统化规范让用户"看得懂"、"找得到"、"放心用"，保证指标的一致性、保证数据高质量生产。

一、模型层次调用规范

设计模型层次和制定调用规范的目的是：避免烟囱式建设，数据更多的共享，减小重复计算、保持数据一致性等。主要有以下几点：

• ods层一般只被dwd层调用，不建议跨层调用ods层
• ads层优先调用dwd和dws层数据，不建议直接抽ods层数据，优先调用dws层
• 应充分了解业务需求，尽量沉淀常用指标到dwd层、dws层、dim层
• dws层可先建轻度汇总层，避免指标直接从dwd明细层出
• dws层要尽量沉淀出常用指标，避免ads层过度调用dwd层数据
• dws层不宜过深，比如超过10层

二、命名规范

字段命名一般有以下通用规范：

• 命名一律采用小写
• 由字母、下划线、数字组成，不能以下划线和数字开头
• 尽量用英文简写，其次是英文
• 部分可以汉语拼音首字母标准缩写，如中国制造zgzz
• 命名不宜过长

1、数据域命名规范

确定好数据域后，需要对其命名，比如上一篇涉及到的

此外一些常用的命名，如：

• 用户域：par
• 日志域：log
• 关系域：sns
• 广告域：adv
• 位置域：loc
• ........

2、表命名规范

可以对表进行如下的约定：

1）临时表：tmp_名字全称_对应输出正式表名_自由发挥_yyyyMMdd

2）正式表：可以采用模型层次、数据域、表描述和分表规则结合的方式

[层次][一级主题域][二级主题域][产品或业务板块][内容描述][分表策略]

说明：

1. ods层表：尽量保持与源系统相同的命名，不涉及主题域，在此基础上增加层次或分表策略
2. 内容描述
   • dim表内容描述一般是维度标识词
   • dwd事实表，内容描述跟业务过程有关
   • dws/ads可以增加统一关键词标识有聚合功能，比如aggr、tag等
3. 层次：就是数仓的模型层次ods/dwd/dim/dws/ads
4. 主题域：即指上面提到的数据域，根据业务情况确定是否有二级主题和产品或业务板块
5. 分表策略：即为数据的生命周期，主要有下面几种：

分表策略	简称	说明
小时全量	dh	每小时分区中保留的是历史至今的全量数据
小时增量	hi	每小时分区中保留的是当前小时的增量数据
日全量	dd	每天分区中保留的是历史至今的全量数据
日增量	di	每天分区中保留的是当日的增量数据，可以是汇总数据也可以是明细数据
周全量	wd	每周的分区中保留的是历史至今的全量数据
周增