SQL查询执行过程中，数据倾斜是指数据在集群节点间分布不均匀，少量节点需要处理远超其他节点的数据量，最终导致整个查询任务的执行时间被这些热点节点拖慢，是大规模数据处理场景下的常见性能瓶颈。
数据倾斜的成因与典型表现
数据倾斜通常由以下原因导致：
- 业务数据本身存在天然热点，比如某款爆款商品的订单量远高于其他商品
- 分区键选择不合理，导致大量数据集中到同一个分区
- 关联查询时使用的关联键存在大量重复值，比如空值、默认值集中出现
典型表现包括：查询进度卡在99%长时间不动、部分执行节点的CPU和内存使用率远高于其他节点、单个任务执行时间远超同类型其他任务。
通过分区优化数据倾斜
合理的分区策略可以将热点数据拆分到不同分区，避免单个分区数据量过大。常见的分区优化方式有以下几种：
选择合适的分区键
优先选择数据分布均匀的字段作为分区键，避免使用存在大量重复值的字段。比如订单表可以按用户ID哈希分区，而不是按商品类目分区，因为热门类目的数据量会远高于冷门类目。
以下是创建哈希分区的SQL示例：
-- 创建订单表，按用户ID进行哈希分区，分为8个分区
CREATE TABLE order_table (
order_id INT,
user_id INT,
product_id INT,
order_amount DECIMAL(10,2),
order_time TIMESTAMP
)
PARTITION BY HASH (user_id) PARTITIONS 8;
热点分区拆分
如果已经存在分区表，且发现某个分区数据量异常大，可以将该分区进一步拆分。比如原来的按日期分区中，某一天的订单量特别大，可以将这一天的数据按小时再拆分出子分区。
-- 给已有的日期分区表添加子分区，拆分2024-05-01的数据为小时级子分区
ALTER TABLE daily_order_table
PARTITION BY RANGE (order_time) (
PARTITION p20240501 VALUES LESS THAN ('2024-05-02')
SUBPARTITION BY HASH (user_id) SUBPARTITIONS 6
);
通过重新分布数据优化数据倾斜
当分区优化无法完全解决倾斜问题时，可以通过重新分布数据的方式均衡各节点负载。
调整数据分布策略
对于关联查询场景，如果关联键存在倾斜，可以在关联前对倾斜的键进行单独处理，比如给空值添加随机前缀，打散后再进行关联。
-- 处理关联键为空的倾斜问题，给空值添加随机前缀打散
SELECT a.user_id, a.order_amount, b.user_name
FROM (
SELECT
order_id,
user_id,
order_amount,
CASE
WHEN user_id IS NULL THEN CONCAT('random_', FLOOR(RAND()*10))
ELSE CAST(user_id AS STRING)
END AS new_user_id
FROM order_table
) a
LEFT JOIN (
SELECT
user_id,
user_name,
CASE
WHEN user_id IS NULL THEN CONCAT('random_', FLOOR(RAND()*10))
ELSE CAST(user_id AS STRING)
END AS new_user_id
FROM user_table
) b
ON a.new_user_id = b.new_user_id;
手动重分布数据
部分SQL引擎支持手动指定数据的分布方式，比如Spark SQL中可以使用DISTRIBUTE BY语句指定数据按某个字段分布，将倾斜的数据打散到不同节点。
-- 按user_id的哈希值重新分布数据，避免倾斜 SELECT user_id, SUM(order_amount) AS total_amount FROM order_table DISTRIBUTE BY CAST(user_id AS STRING) GROUP BY user_id;
优化效果验证
实施分区和重新分布优化后，可以通过以下方式验证效果：
- 查看查询执行计划，确认各阶段的任务数据量分布是否均衡
- 监控集群节点的负载情况，确认热点节点的资源使用率是否下降
- 对比优化前后的查询执行时间，确认性能是否得到提升
如果优化后仍然存在倾斜，需要进一步排查是否存在未处理的热点数据，或者调整分区数量和分布策略，直到数据分布达到均衡状态。