工作中遇到过数据倾斜问题吗？怎么定位怎么处理的？

错误示范（干燥无味版）

遇到过，数据倾斜就是部分 key 对应的数据量远大于其他 key 导致的。定位的话就是看任务监控找跑得慢的 task，处理的话就是打散倾斜 key、过滤无效 key、用 MapJoin 就行。

正确回答（叙事场景版）

当然遇到过，我去年在XXXX用户行为标签离线计算项目的时候就踩过这个坑。当时我们用 Spark SQL 跑 T+1 的天级用户标签任务，平时正常跑 40 分钟就能出结果，618 预售第一天突然跑了 2 小时还没结束，YARN 告警说有 ReduceTask 内存占用超过 90% 快 OOM 了，下游的画像系统等着这个数据推标签，当时特别急。

我先定位问题：第一步先点开 Spark UI 的 Stage 详情页，看每个 Task 的运行时长和数据量，发现 Map 阶段早就 100% 跑完了，Reduce 阶段卡在 99% 不动，98% 的 ReduceTask 都是 10 分钟以内就跑完了，唯独 2 个 Task 跑了 1 个多小时，读取的数据量是其他 Task 的 27 倍，基本确定是数据倾斜。第二步就是找具体的倾斜 Key，我先看当前运行的 SQL 逻辑，是把订单表和用户浏览表按seller_id（卖家 ID）关联后做分组聚合，我就对当天的订单表做了个采样查询：select seller_id,count(*) as cnt from ods_order where dt='2023-05-31' group by seller_id order by cnt desc limit 10，结果出来两个倾斜源：一个是平台自营的头部大店，当天预售订单量是第二名卖家的 32 倍，另一个是seller_id为 NULL 的记录有 200 多万条，查了下是前端埋点上报的时候，部分用户从首页跳转的场景没带卖家 ID，全存成 NULL 了。

然后针对性处理：首先 NULL 值对我们的标签统计没用，我直接在 SQL 里加了where seller_id is not null过滤掉，如果是需要保留 NULL 的场景，我会给 NULL 拼上 0~99 的随机前缀，打散成 100 个不同的 key 先做局部聚合，最后再去掉前缀做全局聚合就行。然后针对那个头部大卖家的倾斜 key，我用了两阶段聚合：第一阶段先给这个卖家的 ID 拼上 0~9 的随机后缀，变成seller_id_rand，先按这个带后缀的 key 做第一次聚合，把原来要打到 1 个 Task 的数分散到 10 个 Task 先算局部的 count、sum 这些指标，第二阶段再把后缀去掉，做第二次全局聚合就好了。另外我还把关联的用户浏览小表开了 MapJoin，直接在 Map 端完成关联，避免 Reduce 端关联再产生额外的倾斜。

改完重新提交任务，最后 38 分钟就跑完了，那两个倾斜的 Task 运行时长也降到了 8 分钟左右，顺利赶上了下游标签推送的时间点。后来我们还做了前置预案，在所有分组聚合的任务里加了自动倾斜检测逻辑：任务启动前先对关联字段做采样，如果发现某几个 key 的占比超过阈值，自动给大 key 加随机前缀做两阶段聚合，后面几次大促再也没出过类似的倾斜问题。

在面试的时候并不是说谁罗列的知识点概念多谁就能胜出, 很多时候我在给别人面试的时候首先关注的逻辑思维和处理问题的正确思 ! 如果我想要一个有经验的程序员,那么在面试中我就会关注你是否有类似的处理问题的经验和真正的开发能力! 所以理论基础为前提 ,如何表述才是你是否拿到OFFER的关键 !