Vol.01 实际案例-数据倾斜
内容提要
本文分享了一位数仓工程师处理数据歪斜问题的经验，通过调整内存参数和查看Spark UI成功定位问题。作者提出了避免数据歪斜的方法，并总结了数仓工程师的能力和责任心。
延伸解读
数据倾斜的隐蔽诱因：执行计划变更
文章指出，一个长期稳定运行的SQL突然出现Executor OOM，根本原因并非SQL本身修改，而是小表数据量增长超过了系统配置的广播阈值，导致执行计划从BroadcastHashJoin变为ShuffledHashJoin。这种变化会引发数据重分布，若关联键存在大量相同值（如-1），就会造成严重的数据倾斜。这提醒我们，监控小表数据量变化和定期检查执行计划同样重要。
ON条件中的过滤为何失效
作者原本在LEFT JOIN的ON条件中写入nvl(a.id, '-1') != '-1'，期望-1不参与关联，但实际执行时这些记录仍参与了hash partitioning，导致倾斜。通过对比物理执行计划发现，ON中的过滤条件并不能阻止左表数据参与shuffle。因此，对于需要排除的倾斜键，更可靠的方式是使用UNION ALL将倾斜键单独处理，避免其进入关联操作。
实战中数据倾斜的排查与解决思路
面对Executor OOM，作者先尝试调大内存参数，同时通过Spark UI的Stages和SQL页面定位到具体出错的Stage和SQL。这种双线并行的方法既争取了快速恢复的可能，又为根治问题提供了依据。最终通过将SQL改写为id != '-1' UNION ALL id = '-1'的方式解决了倾斜。文章强调，调参只是临时手段，根治需要优化SQL逻辑。
数仓工程师的核心能力与责任
作者认为，数据倾斜的解决方案在面试中常被提及，但实战中更考验工程师快速定位复杂SQL中具体问题的能力、找到长期有效解决办法的思维，以及强烈的责任心和夜间保障意识。这些软实力与硬技能同样重要，需要在实际工作中不断打磨和坚持。
Q&A
数据歪斜是什么原因导致的？
数据歪斜的原因是小表数据量增加，超过了播送阈值，导致执行计划变化。
如何处理数据歪斜问题？
可以通过优化SQL，使用id != '-1'和id = '-1'的union all方式来处理数据歪斜问题。
数仓工程师在处理数据歪斜时需要具备哪些能力？
数仓工程师需要具备快速定位问题的能力和强烈的责任心。
在处理Executor OOM时，应该采取什么措施？
可以通过增加Executor内存参数来解决内存不足的问题。
如何通过Spark UI定位数据歪斜问题？
可以通过查看Spark UI中的Stages和SQL，检查失败的Stage和SQL来定位问题。
为什么未修改的SQL会突然产生数据歪斜？
因为小表的数据量近期渐渐变大，超过了系统装备的播送阈值，导致执行计划从BroadcastHashJoin变为ShuffledHashJoin。
