1. 一道Hive面试题背后的数据倾斜排查思路面试题这种东西做过的人都知道真正拉开差距的从来不是“你会不会写SQL”而是“线上跑崩了你怎么查”。我面过不少人也被人面过Hive这块最容易被追问的就是数据倾斜。题目本身可能就一句话“有个任务跑了六个小时没出结果你怎么处理”但这一句话背后考的是你对执行计划、分区分桶、Join策略、参数调优这一整套东西的理解。这篇就借着一道典型的Hive面试题把数据倾斜从现象到根因到解决方案完整拆一遍顺便把面试里那些容易被忽略的细节补上。先说清楚这道题大概长什么样。常见的版本是两张表做Join一张大表一张小表或者两张都是大表但某几个Key的数据量特别大任务卡在Reduce阶段不动日志里能看到某个Reducer处理的数据量远超其他Reducer。面试官想听的不是“加个参数就好了”而是你如何定位、如何判断倾斜类型、如何选择方案。下面我按实际排查的顺序来讲这套思路在真实工作里同样适用。1.1 为什么数据倾斜是Hive面试的必考题Hive本质上把SQL翻译成MapReduce任务Map阶段做过滤和投影Reduce阶段做聚合和Join。数据倾斜的本质是Key的分布不均匀导致某个或某几个Reducer要处理的数据量是其他Reducer的几十倍甚至上百倍。整个任务的完成时间取决于最慢的那个Reducer所以一个Reducer卡住整个任务就卡住。面试官爱考这个是因为它同时考察几个能力你懂不懂MapReduce的执行模型、会不会看执行计划、知不知道常见的调优参数、有没有实际处理过线上问题。光背参数没用因为面试官会追问“为什么这个参数能解决”“什么情况下这个参数反而没用”。我见过不少人能说出set hive.groupby.skewindatatrue但问他这个参数具体做了什么就答不上来了。这道题在面试里的变体很多比如“大表Join小表为什么会倾斜”“Group By为什么会倾斜”“Count Distinct为什么会倾斜”每一种的根因和方案都不一样。接下来我按类型拆开讲每种都给出定位方法和处理方案。2. 定位倾斜先搞清楚是哪种倾斜遇到任务卡住第一步不是急着加参数而是先定位。我一般的排查顺序是看日志、看执行计划、看Key分布。这三步能覆盖大部分场景。2.1 从日志和Counter里找线索任务跑得慢先看YARN的日志或者Hive的日志。重点看几个地方Map完成了多少、Reduce完成了多少、有没有Reduce卡在某个百分比不动。如果Map早就100%了Reduce卡在99%或者某个Reducer一直不结束基本可以确定是倾斜。再看Counter。Hive任务结束后会打印一堆Counter重点看HDFS Bytes Read和Reduce input records。如果某个Reducer的输入记录数远大于其他Reducer那就是倾斜。不过任务卡住的时候可能拿不到最终Counter这时候可以看中间日志或者用EXPLAIN看执行计划。-- 查看执行计划重点看Stage的依赖关系和Operator EXPLAIN SELECT a.id, a.name, b.order_amount FROM user_info a JOIN order_detail b ON a.id b.user_id;执行计划里如果看到Reduce Output Operator的Key分布信息能大致判断倾斜发生在哪个Stage。不过EXPLAIN只能看逻辑计划要看更细的得用EXPLAIN EXTENDED。2.2 用SQL直接验证Key分布最直接的办法是跑一条SQL看Key的分布。比如怀疑user_id倾斜就跑SELECT user_id, COUNT(*) AS cnt FROM order_detail GROUP BY user_id ORDER BY cnt DESC LIMIT 20;如果第一名和第二十名差了几个数量级那就是典型的Key分布不均。我遇到过最夸张的一次某个user_id占了全表40%的数据这种不管怎么调参数都救不了必须从业务层面处理。还有一种情况是Join的Key本身分布均匀但某个Key对应的数据量特别大。比如user_id分布均匀但某个用户的订单记录有几百万条Join的时候这个Key就会倾斜。这种要看Join后的数据量不能只看单表。2.3 判断倾斜发生在Map端还是Reduce端Map端倾斜比较少见一般是小文件太多或者输入格式有问题。Reduce端倾斜才是大头主要发生在Join和Group By。判断方法很简单如果Map阶段就卡住看是不是小文件太多如果Map很快Reduce很慢那就是Reduce端倾斜。Reduce端倾斜又分几种Join倾斜、Group By倾斜、Count Distinct倾斜。每种的处理方式不同下面分别讲。3. 大表Join小表的倾斜处理这是最常见的一种。小表可能就几MB大表几百GBJoin的时候如果小表的Key分布不均或者大表的Key分布不均都会导致倾斜。3.1 Map Join把小表广播出去最直接的方案是用Map Join。原理是把小表加载到每个Map任务的内存里在Map阶段就完成Join不需要Reduce阶段。这样从根本上避免了Reduce端倾斜。-- 方式一通过Hint指定 SELECT /* MAPJOIN(b) */ a.id, a.name, b.order_amount FROM user_info a JOIN order_detail b ON a.id b.user_id; -- 方式二通过参数控制小表阈值默认25MB SET hive.auto.convert.join true; SET hive.mapjoin.smalltable.filesize 25000000;Map Join的适用条件是小表足够小能放进内存。默认阈值是25MB如果小表超过这个大小可以适当调大但要注意内存压力。我一般建议不超过200MB再大就有OOM风险。注意Map Join不是万能的。如果小表本身就不小或者Join的Key在两张表里都分布不均Map Join解决不了问题。另外Map Join会把小表复制到每个Map任务如果Map任务很多网络传输和内存开销也不小。3.2 大表Join大表分而治之两张都是大表没法用Map Join这时候要看倾斜的Key是不是少数。如果是少数几个Key导致的倾斜可以用“加盐”的方式把热点Key打散。具体做法是给热点Key加上随机前缀让小表也做同样的处理这样Join的时候热点Key就被分散到多个Reducer。处理完再去掉前缀。-- 第一步给大表的热点Key加随机前缀 SELECT CONCAT(CAST(FLOOR(RAND() * 10) AS STRING), _, user_id) AS join_key, user_id, order_amount FROM order_detail WHERE user_id IN (hot_user_1, hot_user_2); -- 第二步给小表的相同Key也加前缀每个Key复制10份 SELECT CONCAT(CAST(n AS STRING), _, user_id) AS join_key, user_id, user_name FROM user_info LATERAL VIEW EXPLODE(ARRAY(0,1,2,3,4,5,6,7,8,9)) t AS n WHERE user_id IN (hot_user_1, hot_user_2); -- 第三步Join后去掉前缀 SELECT SPLIT(join_key, _)[1] AS user_id, user_name, order_amount FROM ( -- Join逻辑 ) t;这个方案的核心思路是“把热点Key打散到多个Reducer”。加盐的倍数要根据热点Key的数据量来定一般取热点Key数据量除以平均数据量。比如热点Key有1000万条平均每个Key有10万条那倍数取100左右比较合适。实操心得加盐方案写起来麻烦而且只对少数热点Key有效。如果热点Key很多或者Key分布是长尾分布加盐的效果有限。我一般先用SQL统计一下Top 100的Key占比如果Top 10的Key占了50%以上加盐效果很好如果Top 1000的Key才占50%那加盐就没意义了。3.3 空值Key导致的倾斜还有一种特殊情况是Join的Key里有大量空值。比如user_id为NULL的记录Join的时候所有NULL会被分到同一个Reducer导致倾斜。处理方式很简单把空值过滤掉或者给空值加上随机前缀。-- 方式一过滤空值如果业务允许 SELECT a.id, a.name, b.order_amount FROM user_info a JOIN order_detail b ON a.id b.user_id WHERE b.user_id IS NOT NULL; -- 方式二给空值加随机前缀 SELECT a.id, a.name, b.order_amount FROM user_info a JOIN ( SELECT CASE WHEN user_id IS NULL THEN CONCAT(null_, CAST(FLOOR(RAND() * 100) AS STRING)) ELSE user_id END AS user_id, order_amount FROM order_detail ) b ON a.id b.user_id;空值倾斜很容易被忽略因为很多人觉得NULL不参与Join。实际上Hive的Join会把NULL当成一个正常的Key来处理所有NULL分到同一个Reducer。我踩过这个坑一个任务卡了四个小时最后发现是几百万条NULL记录导致的。4. Group By和Count Distinct的倾斜处理Group By倾斜和Join倾斜的根因一样都是Key分布不均。但处理方式略有不同。4.1 Group By倾斜的两阶段聚合Hive提供了一个参数hive.groupby.skewindata开启后会做两阶段聚合。第一阶段在Map端做局部聚合给每个Key加上随机前缀这样同一个Key的数据会被分到多个Reducer做预聚合第二阶段再去掉前缀做最终聚合。SET hive.groupby.skewindata true; SELECT user_id, COUNT(*) AS order_cnt FROM order_detail GROUP BY user_id;这个参数的本质是“用两次MapReduce换一次倾斜”。第一次MR做局部聚合第二次MR做全局聚合。代价是多了一次Shuffle但解决了倾斜问题。注意这个参数不是万能的。如果倾斜的Key是少数几个效果很好如果所有Key都倾斜比如每个Key的数据量都很大那两阶段聚合也救不了。另外这个参数只对Group By有效对Join无效。4.2 Count Distinct的倾斜处理Count Distinct是Group By的一种特殊情况但更容易倾斜。因为Count Distinct需要把所有数据放到一个Reducer去重数据量大的时候很容易卡住。处理方式是把Count Distinct拆成两步先去重再Count。-- 原始写法容易倾斜 SELECT COUNT(DISTINCT user_id) AS uv FROM order_detail; -- 优化写法先去重再Count SELECT COUNT(*) AS uv FROM ( SELECT user_id FROM order_detail GROUP BY user_id ) t;如果去重后的数据量还是很大可以进一步用hive.groupby.skewindata或者加盐。还有一种方式是近似计算用approx_distinct或者HyperLogLog但精度会有损失看业务能不能接受。-- 近似计算精度约1% SELECT APPROX_DISTINCT(user_id) AS uv FROM order_detail;实操心得Count Distinct的优化优先级是先去重再Count 两阶段聚合 近似计算。近似计算虽然快但面试的时候如果面试官问“怎么保证精度”你得能说出HyperLogLog的原理和误差范围。我一般建议在数据量特别大且业务能接受误差的场景下才用近似计算。5. 参数调优与执行计划解读前面讲的都是方案层面的处理这一节讲参数层面的调优。参数调优是“锦上添花”不是“雪中送炭”。如果倾斜的根因没解决光调参数没用。5.1 常用参数速查表参数默认值作用适用场景hive.auto.convert.jointrue自动转Map Join大表Join小表hive.mapjoin.smalltable.filesize25MB小表阈值调整Map Join适用范围hive.groupby.skewindatafalse两阶段聚合Group By倾斜hive.optimize.skewjoinfalse倾斜Join优化Join倾斜hive.skewjoin.key100000倾斜Key阈值配合skewjoin使用hive.exec.reducers.bytes.per.reducer256MB每个Reducer处理的数据量调整Reducer数量hive.exec.reducers.max1009Reducer数量上限控制并发hive.optimize.skewjoin这个参数值得单独说一下。开启后Hive会把超过阈值的Key单独拿出来处理其他Key正常Join。这个方案对少数热点Key有效但会多一次MR。SET hive.optimize.skewjoin true; SET hive.skewjoin.key 100000;5.2 怎么读执行计划执行计划是排查倾斜的核心工具。EXPLAIN输出的是逻辑计划EXPLAIN EXTENDED输出的是更详细的计划EXPLAIN DEPENDENCY输出的是依赖关系。-- 查看详细执行计划 EXPLAIN EXTENDED SELECT a.id, COUNT(*) AS cnt FROM user_info a JOIN order_detail b ON a.id b.user_id GROUP BY a.id;执行计划里重点看几个东西Stage的划分、每个Stage的Operator、Reduce Output Operator的Key。如果看到某个Stage的Reduce Output Operator后面跟着Group By Operator或者Join Operator那就是倾斜可能发生的地方。注意执行计划是逻辑计划不是物理计划。实际执行的时候Hive会根据参数做优化所以执行计划和实际执行可能不一样。要结合日志和Counter一起看。6. 面试里的高频追问与应对面试官问完基础问题后通常会追问几个深入的问题。这一节整理几个高频追问和应对思路。6.1 “加盐方案有什么缺点”加盐方案的缺点很明显一是实现复杂需要改SQL二是只对少数热点Key有效三是加盐倍数不好确定太小没效果太大增加Shuffle开销四是加盐后数据分布可能还是不均因为随机函数不一定均匀。我一般会补充一句“加盐是最后的手段优先考虑Map Join或者业务层面处理。如果必须加盐建议先用SQL统计Key分布确定加盐倍数。”6.2 “Map Join一定比Reduce Join快吗”不一定。Map Join的优势是避免了Shuffle但如果小表不够小或者Map任务很多Map Join的内存开销和网络传输开销可能比Reduce Join还大。另外Map Join不支持Full Outer Join也不支持非等值Join。我遇到过一个小表200MBMap任务有5000个Map Join直接把集群内存打满了。后来改成Reduce Join加两阶段聚合反而更快。6.3 “怎么判断倾斜是数据问题还是SQL问题”数据问题和SQL问题的判断方法先看Key分布如果Key分布本身就不均那是数据问题如果Key分布均匀但任务还是慢那可能是SQL写法有问题比如笛卡尔积、错误的Join条件、重复扫描等。还有一种情况是数据问题SQL问题比如Key分布不均同时SQL里又用了Count Distinct两个问题叠加。这种要分开处理先解决SQL问题再解决数据问题。7. 真实场景下的排查记录这一节分享一个我实际处理过的案例。某天一个核心报表任务跑了八个小时没出结果平时只要一个小时。任务是一个大表Join大表然后Group By。第一步看日志Reduce卡在99%某个Reducer处理了80%的数据。第二步看Key分布发现shop_id这个Key的分布极度不均Top 1的shop_id占了全表60%的数据。第三步看SQL发现Join之后又做了Count Distinct。处理方案分三步第一步把Count Distinct改成先去重再Count第二步对热点shop_id加盐加盐倍数取50第三步调整Reducer数量从默认的300调到800。改完之后任务跑了40分钟比平时还快。这个案例的关键点是倾斜往往是多个问题叠加的不要指望一个参数解决所有问题。先定位根因再逐个解决。实操心得排查倾斜的时候我一般会先跑一条SQL看Key分布这一步能省很多时间。如果Key分布均匀那问题不在数据在SQL或者参数如果Key分布不均那就针对热点Key处理。另外改完SQL后一定要先跑一个小样本验证别直接上全量不然可能白等几个小时。8. 写在最后的一些经验Hive数据倾斜这块面试里考的是思路工作里考的是效率。我面人的时候如果候选人能说出“先定位再处理”这个思路基本就及格了如果能说出具体的定位方法和不同场景的处理方案那就是优秀。有几个坑我踩过这里提一下。一是不要一上来就加参数参数解决不了根因二是不要忽略空值Key空值Key导致的倾斜很常见三是不要迷信Map Join小表不够小的时候Map Join反而更慢四是加盐方案要慎用能用其他方案就用其他方案。最后说一个容易被忽略的点数据倾斜有时候不是技术问题是业务问题。比如某个店铺的订单量突然暴涨导致Key分布不均。这种时候技术方案只能缓解根本解决要靠业务层面处理比如把大店铺单独拆出来处理。面试的时候如果能提到这一点面试官会觉得你有全局视角。另外Hive的版本不同参数和行为可能有差异。我上面讲的基于Hive 2.x和3.x更早的版本可能不支持某些参数。实际使用的时候要先确认版本别照搬。
