哈希分区数据倾斜的根本原因是分区键基数低或哈希碰撞严重；应优先选用高熵组合键（如concat(user_id,'_',date(created_at))），避免单一低基数字段，并结合引擎特性选择抗碰撞哈希算法或加盐处理。
为什么hash_partition后某些分区数据量爆炸？
根本原因就两个：分区键基数太低，或者哈希算法在该键值分布上“撞车”严重。比如用user_status（只有'active'、'inactive'、'pending'三种值）做哈希分区，不管分 128 个区还是 1024 个区，所有'active'记录全进同一个桶——哈希函数再均匀也救不了输入本身没变化。
实操建议：
- 先查键值分布：
SELECT user_status, COUNT(*) FROM t GROUP BY user_status ORDER BY COUNT(*) DESC，看是否前几项占比超 70% - 别只看唯一值数量（
COUNT(DISTINCT key)），更要盯住MAX(COUNT(*)) / AVG(COUNT(*))这个比值，>5 就算明显倾斜 - 对字符串键，注意大小写、空格、NULL 是否被统一处理；
NULL在多数哈希实现里会映射到固定槽位，极易成热点
怎么选更抗倾斜的分区键？
不是“选一个字段”，而是“构造一个高熵组合”。单一业务字段（如province、category_id）基本不扛压，得主动加扰动。
实操建议：
- 优先拼接：
CONCAT(user_id, '_', DATE(created_at))比单独用user_id更稳——前提是user_id本身不集中（比如新系统刚上线，ID 全是 1~1000） - 慎用时间字段：
TO_DAYS(created_at)在按天写入场景下必然倾斜；改用UNIX_TIMESTAMP(created_at) % 1000能打散，但要注意时区和精度损失 - 有主键且单调递增？直接
id & 0x7FFFFFFF（取低 31 位）比MOD(id, N)散列度高得多，避免连续 ID 落同一区
哈希算法本身能调吗？
能，但不是所有系统都开放。MySQL 的PARTITION BY HASH固定用内部整数哈希，不可换；Flink SQL 的HASH分区走的是Objects.hashCode()，对字符串依赖String.hashCode()实现；而 Spark 的partitionBy(new HashPartitioner(n))底层用的是MurmurHash3，天生比 Java 原生哈希抗碰撞。
实操建议：
- Spark 里如果发现
String键倾斜，可手动预处理：s.map(s => (s + System.nanoTime()).hashCode())，但注意System.nanoTime()在 map 算子内调用才有意义 - Flink 中避免直接
keyBy(x -> x.status)，改用keyBy(x -> Objects.hash(x.status, x.user_id % 16))引入二级扰动 - 确认你用的引擎是否支持自定义哈希函数——比如 Kafka Streams 的
StreamPartitioner可重写，但 Hive 的DISTRIBUTE BY不行
临时救急：加盐（salting）真的管用吗？
管用，但只治标。本质是把热点键拆成多个逻辑子键，让它们分散到不同分区，查询时再合并。代价是读路径变长、无法精准点查、聚合需两阶段。
实操建议：
- 盐值别硬编码：
CONCAT(key, '_', FLOOR(RAND() * 16))会导致每次计算结果不同，无法复用；应基于键确定性生成，如CONCAT(key, '_', ABS(HASH(key)) % 16) - 盐范围要匹配分区数：16 盐值配 128 分区（128 ÷ 16 = 8），确保每个盐组能均匀摊开
- 下游必须识别盐结构——比如
WHERE key = 'A' AND salt IN (0,1,2,3)，漏掉盐值就丢数据
真正难的不是加盐或换键，而是确认“倾斜”到底是数据问题、建模问题，还是查询模式暴露了隐藏的热点。比如某分区慢，未必是数据多，可能是该分区所在节点磁盘 IO 已满，而监控只报了“shuffle 数据量大”。这时候看bytes spilled to disk和GC time比看分区行数更有用。
