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

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

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

 

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

小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	每周的分区中保留的是历史至今的全量数据
周增量	wi	每周的分区中保留的是对应周的增量数据，可以是汇总数据也可以是明细数据
月增量	mi	每月的分区中保留的是对应月份的整个月的增量数据，可以是汇总数据也可以是明细数据
月全量	md	每月的分区中保留的是历史至今的全量数据
无时间分区	nd	死表或者不定期更新的全量表