二、设计规范 - 指标
===========
- Step1:面向主题域管理
为了提高指标管理的效率,你需要按照业务线、主题域和业务过程三级目录方式管理指标。
- Step2:划分原子指标和派生指标
原子指标 + 原子指标 = 派生指标
- Step3:进行指标命名规范
需要遵循两个原则:易懂与统一
-
易懂,就是看到指标的名称,就可以基本判断这个指标归属于哪个业务过程;
-
统一,就是要确保派生指标和它继承的原子指标命名是一致的。
对于原子指标,标名称适合用“动作 + 度量”的命名方式(比如注册用户数、购买用户数)
对于派生指标,应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式。(比如30天内黑卡会员购买用户数)
- Step4:分级管理
指标确实是多,如果一视同仁去管理其实很难,所以可以按照下面的原则进行等级划分:
-
一级指标:数据中台直接产出,核心指标(提供给公司高层看的)、原子指标以及跨部门的派生指标。
-
二级指标:基于中台提供的原子指标,业务部门创建的派生指标。
三、命名规范 - 表命名
============
3.1 常规表
常规表是我们需要固化的表,是正式使用的表,是目前一段时间内需要去维护去完善的表。
规范:分层前缀[dwd|dws|ads|bi]_业务域_主题域_XXX_更新评率|全量/增量。
业务域、主题域我们都可以用词根的方式枚举清楚,不断完善,粒度也是同样的,主要的是时间粒度、日、月、年、周等,使用词根定义好简称。
例如: dwd_xxx_xxx_da
-
di :每日增量
-
da:每日全量
-
mi:每月增量
-
ma:每月全量
3.2 中间表
中间表一般出现在Job中,是Job中临时存储的中间数据的表,中间表的作用域只限于当前Job执行过程中,Job一旦执行完成,该中间表的使命就完成了,是可以删除的(按照自己公司的场景自由选择,以前公司会保留几天的中间表数据,用来排查问题)。
规范:mid_table_name_[0~9|dim]
table_name是我们任务中目标表的名字,通常来说一个任务只有一个目标表。这里加上表名,是为了防止自由发挥的时候表名冲突,而末尾大家可以选择自由发挥,起一些有意义的名字,或者简单粗暴,使用数字代替,各有优劣吧,谨慎选择。通常会遇到需要补全维度的表,这里我喜欢使用dim结尾。中间表在创建时,请加上 ,如果要保留历史的中间表,可以加上日期或者时间戳
3.3 临时表
临时表是临时测试的表,是临时使用一次的表,就是暂时保存下数据看看,后续一般不再使用的表,是可以随时删除的表。
规范:tmp_xxx
只要加上tmp开头即可,其他名字随意,注意tmp开头的表不要用来实际使用,只是测试验证而已。
3.4 维度表
维度表是基于底层数据,抽象出来的描述类的表。维度表可以自动从底层表抽象出来,也可以手工来维护。
规范:dim_xxx
维度表,统一以dim开头,后面加上,对该指标的描述,可以自由发挥。
四、开发规范
======
1 | 表和列的注释释是否有缺失,复杂计算逻辑是否有注释释 |
2 | 任务是否支持多次重跑而输出不变,不能有insert into语句 |
3 | 分区表是否使用分区键过滤并且有有效裁剪 |
4 | 外连接的过逑条件是否使用正确,例如在左连接的where语句存在右表的过滤条件 |
5 | 关联小表,是否使用/*+ map join * / hint |
6 | 不允许引用别的计算任务临时表 |
7 | 原则上不允许存在一个任务更新多个目标表 |
8 | 是否存在笞、迪卡尔积 |
9 | 禁止在代码里面使用drop 111ble、creat它111ble、renaiue 111ble、chan零column等ddl语句 |
10 | 使用动态分区时,有没有检查分区键值为NULL的情况 |
11 | DQC质量监控规则是否配置,严禁棵奔 |
12 | 代码中有没有进行适当的规避数据倾斜语句 |
13 | Where条件中is null语句有没有进行空字符串处理 |
五、流程规范
======
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新