hiveSQL优化

hiveSQL优化

1. 数据去重使用group by代替distinct，禁止使用count(distinct);
   原因：group by 中会先使用sort方法进行排序，空间复杂度小，缺点是要进行一次排序，执行时间会较长
   distinct 中需要将排序的列全部存储到一个内存中可以理解为一个hash结构，最后再hash中计算多少个key，
   将不同的值存起来，内存消耗较大

2. 分区表使用时where条件必须加上分区过滤,
   如：df为每日全量表，day取最新分区；
   di每日增量表，限定日期，如 day between 20190415 and 20190416；
   原因：查询数据少较少资源。

3. 多表关联，先子查询过滤后关联；
   原因：查询数据少较少资源

4. 慎用in和not in，连续性值过滤用between and代替，如：age in (1,2,3,4) 修改为：age between 1 and 4；
   原因：in和not in 会导致全表扫描，between 不会。

5. 子查询禁止使用*号，只把需要的字段列出来，如select name,age；
   原因： 减少扫描时间。

6. 表关联时一定要加上on条件，避免笛卡尔乘积；

7. 表关联时关联条件一定要在子查询里过滤掉null值，避免数据倾斜；

8. 不要对一个表进行重复处理，多使用临时表，尽量做到一次处理多次使用；

9. 慎用order by，大数据排序会很慢；
   原因：对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

10. 创建表指定表存储格式为：Parquet（impala查询推荐格式）。
    根据不同公司定义
    11.多表关联：大表 为驱动表，小表要放在左边。如果差距很大的话 加上‘/+mapjoin(b)/ ’
    原因：mapjoin优化是在Map阶段进行join，而不是通常那样在Reduce阶段按照join列进行分发后在每个Reduce节点上进行join，不需要分发也就没有倾斜的问题，相反，Hive会将小表全量复制到每个Map任务节点，然后每个Map任务节点执行lookup小表即可。
    12.hive中的有索引，但是一般不用建立，hive的主要目的不是查询 是计算。而且索引占空间而且要不断update，不如分区、分桶来得合算。

13.hive中的视图View是逻辑视图，暂不支持物化视图，（目前公司是1.0.0版本），View是只读的，不支持LOAD/INSERT，