表的命名需要遵循基本原则:层次_表名_所属项目,如bdl_order_eb;
临时表的命名可考虑带上创建人姓名缩写信息:tmp_xxx_zhangsan、tmp_xxx_lisi、…
idl层宽表基本都是基于一张原表扩展出来的,因此表名以原表名+ext作为通用规范:如idl_pay_ext_class
表重构与原表不兼容无法立即替换的,以原表名+v+版本号作为通用规范:如bdl_event_assign_v2_crm
含有判新逻辑的表,建议使用idl_new_install开头来标识这类表
对应每日全量分区表,表名需要以idl_all开头来标识这类表
特征表的的表,表名需要以idl_fe开头来标识这类表
针对具有每日结算的表,表名需要包含daily这类关键词来标识
针对具有取最近逻辑的表,表名需要包含last关键字来标识
具有拉链属性的表,表名中需要包含zipper关键字来标识这类表
针对历史快照表,表名中需要包含history或者his来标识这类表
所有的SQL都需要排版对称,添加必要的注释。
所有join必须添加on条件,即使是某些特殊场景下的笛卡儿积。
原则上,不能使用变量拼接SQL的核心逻辑,这会增加SQL阅读难度。
一个脚本原则上只能写一个表(多阶段处理的中间表,需要命名为stage层的表)
不要使用count(*),需要使用count(1)
SQL中如果表有别名,字段上一定要把表别名带上
表的别名不能重复
少用空字符串,尽量用NULL
刷数据尽量使用动态分区的方式,避免一天天的重刷
字段尽量不要以数字开头,部分导出场景下不支持,例如palo就不支持字段名以数字开头
尽量在底层保证数据质量,乱码、特殊字符、长度超长、主键唯一等规范,避免上层再次处理
hive建表尽量不要用boolean(可以使用tinyint),因为boolean导出的时候会变成字符串true和false,在导出到其它类型的数据库(例如palo)时需要做特殊处理
条件关联时保证类型一致,如果a(int)=b(string)保不定哪天就突然慢了
同一个字段在各个表的类型和描述应该一致,字段名也应该保持一致
所有标准作业都需要通过Azkaban来调度管理
所有的天级别以上Hive表ETL完成后,都需要创建成功标识(HDFS路径:/user/dw_etl_task/项目/日期/表名)
作业名必须和脚本名保持一致(除数据导出外,脚本名还需要和hive表名保持一致)
原则上一个主题域或项目对应一个Azkaban的调度project,一个project按调度逻辑拆分多个作业流。作业流命名格式:项目名_逻辑名_flow。例如:class_xxx_flow。
为了保证调度逻辑的简洁性与直观性,所有作业都封装成脚本程序执行,一个作业(job)只允许执行一个命令(command),
所有的调度逻辑的新增或修改,必须手工测试并通过。
监控程序会每15分钟检测一次异常或者超时作业流,各作业流的维护者或者修改者需要在第一时间内解决。
如果在Azkaban中kill作业,必须把对应Hadoop中执行的Job也kill掉(hadoop job -kill xxxx)
部署任务调度时候错误选项(Failure Option)里必须选择Finish All Possible,以免因一个作业错误而导致整个作业流后续作业都无法执行;
建议日常ETL SQL实现中就同时支持历史数据刷新(如时间条件为一段范围,group by时间字段),只需要修改部分参数即可快速重刷数据。
如果业务SQL难以支持同时刷历史的话,则需要单独提供刷新历史脚本或者使用range_run.sh逐天刷新数据。
逐天刷新数据的场景,务必需要控制好并发刷新度以及对服务器的资源占用,并及时只会其他数据开发。
刷新数据务必有人值守,出现过载情况需要及时停止相关任务。
严禁刷数据超过零点,零点后未完成是刷数据任务必须手动终止并kill相关集群任务
设计表时要支持刷历史数据,且尽量支持批量重刷历史数据
归因数据谨慎重刷,因为归因数据一般N天前的数据都会固化不会改变,一旦重刷就会造成数据不一致
基本层级关系如下:odl->bdl->idl->adl,禁止低层数据表依赖同项目高层数据表;
bdl尽量避免跨项目依赖其他表,可考虑放在idl层操作;
原则上所有odl层表应该都有对应的bdl层表,但由于沪江很多都是结构化的业务数据,因此有些数据开发可以直接使用odl层数据表,但对于日志如CT服务器日志、utrack流量日志等均有bdl层做数据清洗,并且后续开发也禁止直接依赖odl层数据表;
日常任务调度不鼓励使用宽表,尽量减少表的依赖深度,以提高调度效率;
当项目内调度作业过多时,应根据业务分拆作业流,不同作业流之间相互依赖的表采用wait方式解决,切勿造成同一个作业在不同的作业流当中多次执行;
需要注意作业之间的循环依赖问题,同项目同一个作业流内azkaban会检查循环依赖,但是跨项目跨作业流的需要开发自己注意;
修改表结构增加字段的,需要在最后追加字段,不能在中间插入字段;
Hive表结构修改以后,需要刷新历史分区的元数据信息,执行/home/hadoop/bin/update_schema +tablename 命令刷新;
日志型数据一般都是不会变的,可以做成存量脚本。业务数据会经常变,所以尽可能在上层表关联业务数据,如果要在底表用,优先做成全量的,如果是增量,要考虑重刷数据不一致的问题