开发规范

• 注重代码的可读性,解耦性,健壮性!!!
  • 存在多层嵌套,内层嵌套表的过滤条件不要写到外层(重点),例如:

--错误示范
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
    程序要依赖抽象模型,而不是具体实现.
    • 高层模型不应依赖低层模型,二者都应该依赖于抽象
    • 抽象不应该依赖具体实现,具体实现应该依赖抽象

参考书籍:

• 《Hive性能调优实战》| 林志煌
• SOLID维基百科