大数据中两个超级大的表join，发生了数据倾斜怎么处理？

这是一个大数据处理中非常经典和关键的问题。当两个超级大的表进行 JOIN 操作时发生数据倾斜，意味着某个或某几个 key 对应的数据量异常庞大，导致处理这些 key 的 Task 需要花费远超其他 Task 的时间，从而拖慢了整个作业，甚至导致内存溢出（OOM）而任务失败。

数据倾斜的本质是：数据分布不均。

下面我将从现象诊断、常见原因、解决方案三个方面来详细阐述如何处理。

---

一、首先，如何诊断数据倾斜？

在 Spark 或 Flink 等大数据引擎的任务中，可以通过以下迹象判断：

1. 任务监控界面（如 Spark UI）：
   • 绝大多数 Task 很快完成，但个别（比如一两个）Task 运行时间极长。
   • 这些慢 Task 的输入数据量（Input Size / Records） 远远大于其他 Task。
   • 可能出现 Shuffle Write/Read 量 在某个节点上异常高。
2. 日志信息：
   • 任务卡在最后的 99% 或 100% 不动。
   • 出现 Java heap space 或 GC overhead 等 OOM 错误。

一旦确认是数据倾斜，下一步就是分析原因并选择对策。

---

二、数据倾斜的常见场景

1. Join 键分布不均：
   • 事实表 join 维度表：Join 键可能是某个维度 ID（如city_id），但大部分数据集中在少数几个大城市（如“北京”、“上海”），而小城市的数据量很少。
   • 存在空值或无效值：如 null, 0, -1, ‘N/A’ 等。如果这些值很多，它们会被分到同一个 Reduce 任务中。
2. 大表 join 大表：两个表都很大，并且都存在热点 key。

---

三、解决方案（从易到难，从通用到特定）

方案一：过滤倾斜的 Key（最简单直接）

如果倾斜的 key 本身是脏数据或业务上无关紧要（比如 null 值），最有效的方法就是直接过滤掉。

示例：

-- 假设 table_a 和 table_b 通过 user_id JOIN，但 user_id 为 0 或 null 的数据量巨大且无业务意义
SELECT *
FROM table_a
JOIN table_b
ON table_a.user_id = table_b.user_id
WHERE table_a.