传统上,企业中数据仓库作为全企业数据汇聚的场所,不能直接保留原系统名称,需要进行规范命名,其命名规范也是数据标准的一部门。本文介绍的规范可供大家参考!
词根属于数仓建设中的规范,属于元数据管理的范畴,现在把这个划到数据治理的⼀部分。完整的数仓建设是包含数据治理的,只是现在谈到数仓偏向于数据建模,而谈到数据治理,更多的是关于数据规范、数据管理。表命名,其实在很大程度上是对元数据描述的⼀种体现,表命名规范越完善,我们能从表名获取到的信息就越多。比如:⼀部分业务是关于货架的,英⽂名是:rack,rack 就是⼀个词根,那我们就在所有的表、字段等⽤到的地⽅都叫 rack,不要叫成别的什么。这就是词根的作⽤,来统⼀命名,表达同⼀个含义。指标体系中有很多“率”的指标,都可以拆解成 XXX+率,率可以叫 rate,那我们所有的指标都叫做 XXX+rate。举例:以流程图的⽅式来展⽰,更加直观和易懂,本图侧重 dwm 层表的命名规范,其余命名是类似的道理:
第⼀个判断条件是该表的用途,是中间表、原始日志还是业务展示用的表如果该表被判断为中间表,就会⾛⼊下⼀个判断条件:表是否有 group 操作通过是否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层如果不是 dwd 层,则需要判断该表是否是多个行为的汇总表 (即宽表) 最后再分别填上事业群、部门、业务线、自定义名称和更新频率等信息即可。- ⾃定义:⼀般会尽可能多描述该表的信息,⽐如活跃表、留存表等
- 常规表是我们需要固化的表,是正式使用的表,是⽬前⼀段时间内需要去维护去完善的表。
- **规范:分层前缀[dwd|dws|ads]部门业务域_主题域XXX更新周期|数据范围**
- 业务域、主题域我们都可以⽤词根的⽅式枚举清楚,不断完善。
- 中间表⼀般出现在 Job 中,是 Job 中临时存储的中间数据的表,中间表的作⽤域只限于当前 Job 执⾏过程中,Job ⼀旦执⾏完成,该中间表的使命就完成了,是可以删除的 (按照⾃⼰公司的场景自由选择,以前公司会保留⼏天 的中间表数据,⽤来排查问题) 。
- **规范:mid_table_name_ [0~9|dim] **
- table_name 是我们任务中⽬标表的名字,通常来说⼀个任务只有⼀个⽬标表。这⾥加上表名,是为了防⽌⾃由发挥的时候表名冲突,⽽末尾⼤家可以选择⾃由发挥,起⼀些有意义的名字,或者简单粗暴,使⽤数字代替,各有优劣吧,谨慎选择。通常会遇到需要补全维度的表,这里使⽤ dim 结尾。如果要保留历史的中间表,可以加上⽇期或者时间戳。
- 临时表是临时测试的表,是临时使用一次的表,就是暂时保存下数据看看,后续一般不再使用的表,是可以随时删除的表。
- 只要加上 tmp 开头即可,其他名字随意,注意 tmp 开头的表不要⽤来实际使⽤, 只是测试验证而已。
- 维度表是基于底层数据,抽象出来的描述类的表。维度表可以⾃动从底层表抽象出来,也可以⼿⼯来维护。
- 维度表,统⼀以 dim 开头,后⾯加上,对该指标的描述。
⼿⼯表是⼿⼯维护的表,⼿⼯初始化⼀次之后,⼀般不会⾃动改变,后⾯变更,也是⼿⼯来维护。⼀般来说,⼿⼯的数据粒度是偏细的,所以暂时统⼀放在 dwd 层,后⾯如果有⽬标值或者其他类型⼿⼯数据,再根据实际情况分层。**规范:dwd_业务域_manual_xxx **⼿⼯表,增加特殊的主题域,manual,表⽰⼿⼯维护表。- 单词之间下划线分割 (反例:appName 或 AppName)
- 可读性优于长度 (词根,避免出现同⼀个指标,命名⼀致性)
- 禁止使用 sql 关键字,如字段名与关键字冲突时 +col
- 天分区使⽤字段 dt,格式统⼀ (yyyymmdd 或 yyyy-mm-dd)
结合指标的特性以及词根管理规范,将指标进⾏结构化处理。
- 业务修饰词,用于描述业务场景的词汇,例如 trade-交易。
- 基础指标,单⼀的业务修饰词+基础指标词根构建基础指标,例如:交易⾦额 -trade_amt。
- 派⽣指标,多修饰词+基础指标词根构建派⽣指标。派⽣指标继承基础指标的特性,例如:安装门店数量-install_poi_cnt。
- 普通指标命名规范,与字段命名规范⼀致,由词汇转换即可以。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70027827/viewspace-2964555/
,如需转载,请注明出处,否则将追究法律责任。