浅谈Hive程序相关规范
开发规范
- 注重代码的可读性,解耦性,健壮性!!!
- 存在多层嵌套,内层嵌套表的过滤条件不要写到外层(重点),例如:
--错误示范
select a.* from a
left join b
on a.id = b.id
where a.no =1
--正确书写(为加强可读性与代码解耦健壮性)
select * from(
select * from a where a.no=1
) a left join b
on a.id = b.id
- 插入覆盖语句禁止写select *(重点)
- 使用insert into 之前优先考虑是否可用insert overwrite代替
- 单条sql长度不宜超过一屏,例如:①就不符合规范,应当写成②的格式.
- sql子查询不应超过3层
- 避免SQL代码的复制、粘贴.如果有多处逻辑一致的代码,可以将执行结果存储到临时表中.
drop table if EXISTS test_mid;
create table if not EXISTS test_mid as
-
尽可能使用SQL自带的高级命令做操作.例如在多位统计分析中使用cube,grouping set和rollup等命令替代多个SQL子句的union all.
-
使用set命令,进行[]配置属性的更改,要有注释
-
关注null值的数据处理
-
少用或者不用 Hint,特别是Hive2.0后,增强HiveSql对于成本调优的支持,对业务环境变化时可能导致HIve无法选用最优的执行计划
-
功能节点要有相应注释
-
谨遵SOLID原则
- S -Single Responsibllity Principle -单一职责原则
一个代码块只能承担一个职责,并且只有有一个潜在原因才能去更改这个代码块 - O -Open/Closed Principle 开闭原则
代码实体对拓展开发,对修改关闭.允许拓展行为无需修改源代码 - L -Liskov Substitution Principle 里氏替换原则
程序中对象应该可被替换,而不会影响程序的正确性 - I -Interface Segregation Principle 模型隔离原则
使用多个特定细分的模型比单一总模型要好,不能强迫用户去依赖他们用不到的模型 - D -Dependency Inversion Principle
程序要依赖抽象模型,而不是具体实现.- 高层模型不应依赖低层模型,二者都应该依赖于抽象
- 抽象不应该依赖具体实现,具体实现应该依赖抽象
- S -Single Responsibllity Principle -单一职责原则
参考书籍:
- 《Hive性能调优实战》| 林志煌
- SOLID维基百科