1. 数据倾斜的本质：什么是数据倾斜、典型特征与对分区裁剪的影响

各位同学好，我是老张。做大数据这么多年，要说最让人头疼的问题，数据倾斜排前三。今天咱们就来聊聊这个“万恶之源”——数据倾斜的本质。

1.1 什么是数据倾斜？

说白了，数据倾斜就是数据分布不均匀。你想想看，一个大数据任务，本来应该大家平均分担工作，结果某些节点累死累活，其他节点闲得发慌。

我习惯用一个比喻来解释：好比10个人搬砖，9个人每人搬1块，剩下1个人搬91块。这第10个人就是那个倾斜的节点，整个任务的完成时间就由他决定。

在Spark、Hive、Flink这些引擎里，数据倾斜通常发生在Shuffle阶段。比如做join、group by、distinct这些操作时，数据需要重新分区，如果某个key的数据量特别大，就会导致倾斜。

1.2 数据倾斜的典型特征

我在项目中遇到过无数次数据倾斜，总结下来有这几个典型特征，你可以对照着排查：

特征	表现	排查方法
任务进度卡在99%	大部分task已完成，少数task长时间运行	查看stage/step的task耗时分布
OOM异常	个别节点内存溢出，其他节点正常	检查executor日志，看哪个节点报错
数据量差异巨大	各分区记录数相差几十倍甚至上百倍	用df.groupBy("key").count()查看分布
网络IO不均衡	某个节点网络流量异常高	监控面板看各节点网络吞吐
GC频繁	倾斜节点频繁Full GC	查看GC日志，观察暂停时间

为什么会这样？常见的原因有：

• 热点Key：比如某个商品ID、某个用户ID的数据量特别大
• 空值或默认值：大量数据key为null或"unknown"
• 数据本身分布不均：比如日志中某个错误码出现频率极高
• 分区键选择不当：分区字段的基数太小，导致数据集中

1.3 数据倾斜对分区裁剪的影响

嗯，这里要重点讲。分区裁剪（Partition Pruning）是咱们做数据仓库优化时最常用的手段之一。它的原理很简单：只读取需要的分区，跳过无关分区，从而减少IO和计算量。

但数据倾斜来了，分区裁剪的效果就会大打折扣。我总结了几种典型场景：

场景一：倾斜分区导致裁剪失效

假设你的表按日期分区，每天一个分区。正常情况下，查询某天的数据，分区裁剪会精准定位到那个分区。但如果某天的数据量是其他天的100倍——比如双十一那天的数据——问题就来了。

你想想看，虽然分区裁剪帮你跳过了其他分区，但那个倾斜的分区本身数据量巨大，读取和计算依然很慢。说白了，分区裁剪只解决了“读哪些分区”的问题，没解决“分区内数据倾斜”的问题。

场景二：动态分区裁剪的副作用

有些引擎支持动态分区裁剪，比如Spark 3.0+的DPP（Dynamic Partition Pruning）。它会在运行时根据子查询结果动态过滤分区。但数据倾斜时，动态分区裁剪可能会产生大量小文件，反而拖慢性能。

我曾经遇到过一个案例：用DPP做星型模型查询，事实表按日期分区，维度表有倾斜。结果动态分区裁剪生成了上千个小分区文件，每个文件只有几十KB，读取效率极低。

场景三：分区键本身就是倾斜源

最尴尬的情况是——分区键就是那个倾斜的key。比如你按user_id分区，但某些大V用户的数据量是普通用户的万倍。这时候分区裁剪不仅帮不上忙，还会因为分区数量过多导致元数据膨胀。

1.4 知识体系总览

为了让你更直观地理解本章内容，我画了一张图。它展示了数据倾斜的本质、特征以及对分区裁剪的影响路径：

1.5 小结

这一章我们聊了数据倾斜的本质——说白了就是数据分布不均。典型特征包括任务卡在99%、OOM、数据量差异巨大等。最关键的是，数据倾斜会严重影响分区裁剪的效果：要么让裁剪失效，要么产生小文件，要么分区键本身就是倾斜源。

记住一句话：分区裁剪解决的是“读哪些分区”的问题，数据倾斜解决的是“分区内数据怎么分布”的问题。两者需要配合使用，才能达到最佳效果。