说明：该文章基于多篇博客整理而成，涉及的技术点已贴上链接。

一、数据倾斜的理解

1.数据倾斜是大数据中很常见的一个现象，一般针对数据倾斜我们都会对数据进行加盐或者repartition 等等，hive中的distribute by是控制在map端如何拆分数据给reduce端的。hive会根据distribute by后面列，根据reduce的个数进行数据分发，默认是采用hash算法。对于distribute by进行测试，一定要分配多reduce进行处理，否则无法看到distribute by的效果。
参考：https://blog.csdn.net/wanghai__/article/details/6448615?utm_medium=distribute.pc_relevant.none-task-blog-searchFromBaidu-3.not_use_machine_learn_pai&depth_1-utm_source=distribute.pc_relevant.none-task-blog-searchFromBaidu-3.not_use_machine_learn_pai

二、Hive 常见的数据倾斜及调优技巧

说明：Hive在执行MapReduce任务时经常会碰到数据倾斜的问题，表现为一个或者几个reduce节点运行很慢，延长了整个任务完成的时间，这是由于某些key的条数比其他key多很多，这些Key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。

小表与大表JOIN

小表与大表Join时容易发生数据倾斜，表现为小表的数据量比较少但key却比较集中，导致分发到某一个或几个reduce上的数据比其他reduce多很多，造成数据倾斜。

优化方法：使用Map Join将小表装入内存，在map端完成join操作，这样就避免了reduce操作。有两种方法可以执行Map Join：

(1) 通过hint指定小表做MapJoin

select /*+ MAPJOIN(time_dim) */ count(*) from store_sales join time_dim on ss_sold_time_sk = t_time_sk;

(2) 通过配置参数自动做MapJoin

核心参数：

参数名称	默认值	说明
hive.auto.convert.join	false	是否将common join（reduce端join）转换成map join
hive.mapjoin.smalltable.filesize	25000000	判断为小表的输入文件大小阈值，默认25M

因此，巧用MapJoin可以有效解决小表关联大表场景下的数据倾斜。

1.大表与大表JOIN

大表与大表Join时，当其中一张表的NULL值（或其他值）比较多时，容易导致这些相同值在reduce阶段集中在某一个或几个reduce上，发生数据倾斜问题。

优化方法：

(1) 将NULL值提取出来最后合并，这一部分只有map操作；非NULL值的数据分散到不同reduce上，不会出现某个reduce任务数据加工时间过长的情况，整体效率提升明显。这种方法由于有两次Table Scan会导致map增多。

SELECT a.user_Id,a.username,b.customer_id FROM user_info a LEFT JOIN customer_info bON a.user_id = b.user_id where a.user_id IS NOT NULLUNION ALLSELECT a.user_Id,a.username,NULL FROM user_info a WHERE a.user_id IS NULL

(2) 在Join时直接把NULL值打散成随机值来作为reduce的key值，不会出现某个reduce任务数据加工时间过长的情况，整体效率提升明显。这种方法解释计划只有一次map，效率一般优于第一种方法。

SELECT a.user_id,a.username,b.customer_idFROM user_info aLEFT JOIN customer_info bONCASE WHEN a.user_id IS NULL THEN CONCAT ('dp_hive', RAND())ELSE a.user_idEND = b.user_id;

2.GROUP BY 操作

Hive做group by查询，当遇到group by字段的某些值特别多的时候，会将相同值拉到同一个reduce任务进行聚合，也容易发生数据倾斜。

优化方法：

(1) 开启Map端聚合

参数设置：

参数名称	默认值	说明
hive.map.aggr	true（Hive 0.3+）	是否开启Map端聚合
hive.groupby.mapaggr.checkinterval	100000	在Map端进行聚合操作的条目数目

(2) 有数据倾斜时进行负载均衡

参数设置：

参数名称	默认值	说明
hive.groupby.skewindata	false	当GROUP BY有数据倾斜时是否进行负载均衡

当设定hive.groupby.skewindata为true时，生成的查询计划会有两个MapReduce任务。在第一个MapReduce 中，map的输出结果集合会随机分布到 reduce 中，每个 reduce 做部分聚合操作，这样处理之后，相同的 Group By Key 有可能分发到不同的 reduce 中，从而达到负载均衡的目的。在第二个 MapReduce 任务再根据第一步中处理的数据按照Group By Key分布到reduce中，（这一步中相同的key在同一个reduce中），最终生成聚合操作结果。

3.COUNT(DISTINCT) 操作

当在数据量比较大的情况下，由于COUNT DISTINCT操作是用一个reduce任务来完成，这一个reduce需要处理的数据量太大，就会导致整个job很难完成，这也可以归纳为一种数据倾斜。

优化方法：将COUNT DISTINCT使用先GROUP BY再COUNT的方式替换。例如：

select count(id) from (select id from bigtable group by id) a

因此，count distinct的优化本质上也是转成group by操作。

三、Hive的MapReduce原理

参考：https://blog.csdn.net/fanfan_gaolin/article/details/88576426

SQL优化：Hive---distribute by 防止数据倾斜相关推荐

SQL优化：使用distribute by 防止数据倾斜
场景数据倾斜是大数据中很常见的一个现象,一般针对数据倾斜我们都会对数据进行加盐或者repartition 等等 distribute by rand() distribute by :用来控制ma ...
Hive 性能优化（全面）解决数据倾斜等问题
Hive性能优化(全面) 1.介绍首先,我们来看看Hadoop的计算框架特性,在此特性下会衍生哪些问题? 数据量大不是问题,数据倾斜是个问题. jobs数比较多的作业运行效率相对比较低,比如即使有几 ...
Hive性能优化（全面）解决数据倾斜等问题
Hive性能优化(全面) 1.介绍首先,我们来看看Hadoop的计算框架特性,在此特性下会衍生哪些问题? 数据量大不是问题,数据倾斜是个问题. jobs数比较多的作业运行效率相对比较低,比如即使有几 ...
以小博大外小内大,Db数据库SQL优化之小数据驱动大数据
SQL优化中,有一条放之四海而皆准的既定方针,那就是:永远以小数据驱动大数据.其本质其实就是以小的数据样本作为驱动查询能够优化查询效率,在SQL中,涉及到不同表数据的连接.转移.或者合并,这些操作必须 ...
Hive优化笔记（1 - 非数据倾斜）
目录列裁剪和分区裁剪谓词下推本地模式(local mode) 并行执行严格模式 Map端聚合调整mapper数调整reducer数小文件合并优化设置jvm重用引擎选择输出结果压缩 ...
spark sql读取hive底层_[大数据]spark sql读写Hive数据不一致
在大数据公司中,任何一家公司都不会只使用一个框架吧?! skr,skr~~ 那我们今天就来聊一段 Hive 与 Spark的爱恨情仇就像在一些场景中,需要将外部的数据导入到Hive表中,然后再对这 ...
高性能MySQL（3th）（第六章 sql优化） —— 01 减少冗余数据
一查询冗余的条数如实际前台只需要TOP10,但是查询时使用 LIMIT 100. 解决方案:使用需要的大小限制.e.g. LIMIT 10,或者至多 LIMIT 20. 二查询冗余的的列避免使 ...
Hive之数据倾斜的原因和解决方法
数据倾斜在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显.主要是因为在Job完成后的所得到的Counters是整个Job的总和,优化是基于这些Counter ...
Hive中数据倾斜和小文件过多的解决方案
数据倾斜: 任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成.因为其处理的数据量和其他reduce差异过大. 原因:某个reduce的数据 ...

SQL优化：Hive---distribute by 防止数据倾斜