hiveSQL优化
-
数据去重使用group by代替distinct,禁止使用count(distinct);
原因:group by 中会先使用sort方法进行排序,空间复杂度小,缺点是要进行一次排序,执行时间会较长
distinct 中需要将排序的列全部存储到一个内存中可以理解为一个hash结构,最后再hash中计算多少个key,
将不同的值存起来,内存消耗较大 -
分区表使用时where条件必须加上分区过滤,
如:df为每日全量表,day取最新分区;
di每日增量表,限定日期,如 day between 20190415 and 20190416;
原因:查询数据少较少资源。 -
多表关联,先子查询过滤后关联;
原因:查询数据少较少资源 -
慎用in和not in,连续性值过滤用between and代替,如:age in (1,2,3,4) 修改为:age between 1 and 4;
原因:in和not in 会导致全表扫描,between 不会。 -
子查询禁止使用*号,只把需要的字段列出来,如select name,age;
原因: 减少扫描时间。 -
表关联时一定要加上on条件,避免笛卡尔乘积;
-
表关联时关联条件一定要在子查询里过滤掉null值,避免数据倾斜;
-
不要对一个表进行重复处理,多使用临时表,尽量做到一次处理多次使用;
-
慎用order by,大数据排序会很慢;
原因:对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 -
创建表指定表存储格式为: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,