hiveSQL优化

最新推荐文章于 2025-06-19 21:09:36 发布

悠嘻小猴仔

最新推荐文章于 2025-06-19 21:09:36 发布

阅读量338

点赞数

CC 4.0 BY-SA版权

文章标签： hive

本文链接：https://blog.csdn.net/weixin_41708343/article/details/102859635

本文分享了HiveSQL性能优化的关键策略，包括使用groupby替代distinct减少内存消耗，合理利用where条件过滤分区数据，避免全表扫描的in和notin操作，以及优化表关联和子查询等方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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，不如分区、分桶来得合算。