1. 问题初现：整数类型分桶键为什么会倾斜
做数据仓库的同学应该都遇到过这种场面：一张几百G的大表，按某个整数类型字段分了桶，跑一个INSERT ... SELECT，Map阶段很快，Reduce阶段却卡了半小时。点开AppMaster一看，几个Reduce任务的数据量是隔壁任务的十几倍，整个Job被那几个“大哥”拖到超时。这就是典型的数据倾斜，而倾斜的源头往往不是SQL写错了，而是分桶键选得不合适，尤其当你选的是一个整数类型字段时，问题会被数学规律放大得很隐蔽。
分桶（Bucket）在Hive和Inceptor里是个很常用的优化手段，它可以把数据按某个键的哈希值切分到固定数量的文件/目录中，方便做map join、抽样、以及后续的桶裁剪（bucket pruning）。通常我们直觉上认为“整数取模肯定均匀”，但实际业务里整数键的分布往往不是随机的——用户ID可能是自增的，订单号可能有固定前缀，地区编码可能是连续的，这些规律一旦叠加哈希取模，就会让某些桶疯狂膨胀，某些桶只剩骨架。
这篇文章我会从分桶的底层逻辑讲起，把整数类型分桶键倾斜的原因一层层扒开，然后给出几套可以直接落地的优化方案，包括重新选键、调整桶数、盐值处理、特殊键隔离，以及配套的小文件合并和参数调优。不管你是用Hive还是Inceptor，只要语法基于HiveQL，这些思路基本都能复用。
先说结论：整数分桶键倾斜不是“玄学”，它是哈希函数 + 数据分布 + 桶数三者叠加的结果。搞清楚了这一点，你就能在写建表语句的那一分钟里避开几个大坑。
2. 追根溯源：分桶机制与哈希规律
2.1 Hive分桶的底层逻辑
Hive和Inceptor的分桶原理其实很简单：对分桶键取哈希值，再用桶数取模，得到桶编号，数据就落进对应桶。
bucket_id = hash(bucket_column) % bucket_number这个公式是理解一切问题的起点。比如桶数是16，键的哈希值模16后，余数0到15分别对应16个桶。看起来没问题，但这里有个隐藏前提：hash(bucket_column)的结果必须是均匀分布的，而且“均匀”还要能持续到取模之后。
Hive里针对不同数据类型，哈希算法不完全一样。整数类型（INT/BIGINT）的哈希很特殊——在Java的Object.hashCode()里，hash(整数)基本上就是整数本身。Hive的GenericUDFHash对整数类型做了类似处理，也就是说，对于一个INT字段，hash(100)的结果差不多就是100。这意味着分桶公式退化成了：
bucket_id = integer_value % bucket_number如果桶数是10，键值本身就是10、20、30、40这种规律，算出来的余数全是0，所有数据都挤进0号桶。哪怕键值不是严格等差数列，只要整数分布里有明显的周期或偏向，取模之后就一定会出现“偏桶”。
2.2 整数类型哈希的“陷阱”
整数键最常见的一种坏规律是“低位集中”。例如自增主键，虽然总体是连续的，但如果你按某个固定步长过滤（比如每天只同步某种类型的记录），落在某个桶里的数据就会扎堆。更常见的是枚举值字段，比如状态码status只有1、2、3三种值，桶数哪怕设成64，最终也只有三个桶有数据，剩下61个桶全空——这不仅是倾斜，还是巨大的存储浪费。
还有一种情况是负数。Java的hashCode()对负数整数会返回负值，取模结果也可能是负数，导致某些桶永远没有数据。虽然Hive的hash函数会做一定处理，但不同版本行为不一致，Inceptor和Hive之间也有细节差异。实测过，用BIGINT类型的负值做分桶键，某些组合下确实会出现负数桶号，查询时直接报错或者数据丢失，这种坑特别恶心。
另外，很多同学喜欢把字符串类型的业务键“不小心”转成了整数类型，比如把手机号、身份证号、订单号当作BIGINT来分桶。手机号前几位是号段，后四位是随机？其实整个手机号数值分布也不均匀，因为号段有限。订单号如果包含时间戳+流水号，取模后低位的流水号如果是连续递增，反而均匀；但如果你把“年月日+序号”拼接成整数，那高位日期部分几乎恒定，取模后等于只用序号那部分，如果序号长度固定，也可能产生偏斜。
一句话总结：整数本身分布均匀时，取模没问题；但“业务上的均匀”不等于“数学上的均匀”，尤其是那些低位有规律、高位恒定的数字，取模之后会把规律暴露无遗。
3. 定位问题：如何确认倾斜并找到根因
3.1 查看桶分布
别急着改表，先确认到底是不是分桶键的问题。最直接的方案是写一条聚合SQL，按桶号统计数据量。Hive提供了一个内置函数hash()，你可以用来模拟分桶结果。
SELECT hash(bucket_col) % num_buckets AS bucket_id, COUNT(*) AS cnt FROM your_table GROUP BY hash(bucket_col) % num_buckets ORDER BY bucket_id;这个查询能直接看到每个桶里有多少行。如果某个桶的cnt占了全表的60%以上，那基本就是倾斜了。不过注意，hash()函数在不同引擎里实现可能不同，Inceptor的hash函数和Hive的绝大多数情况下行为一致，但保险起见，更准确的做法是利用TABLESAMPLE采样或者直接看HDFS上文件大小。
另一种思路是通过dfs -du -h看分桶目录下各个文件的大小：
dfs -du -h /user/hive/warehouse/your_db.db/your_table;分桶表的每个桶通常对应一个物理文件（如果开启了hive.enforce.bucketing且没有排序，则每桶可能还会拆分）。哪个文件体积远大于其他文件，哪个桶就可能是热桶。
3.2 EXPLAIN与统计信息
如果数据量很大，跑全量GROUP BY成本太高，那就用EXPLAIN看执行计划，重点观察Reduce阶段的分配逻辑。当你对分桶键做GROUP BY时，Map端输出会按照分组键分区到Reduce，如果某个分组键的值特别大，单个Reduce就会处理超多数据。
EXPLAIN里通常看不到具体行数，这时候就得依赖统计信息：
ANALYZE TABLE your_table COMPUTE STATISTICS; ANALYZE TABLE your_table COMPUTE STATISTICS FOR COLUMNS bucket_col;接着用DESCRIBE FORMATTED your_table查看列统计里的ndv（不同值个数）和numNulls。如果ndv远小于桶数，例如表有1亿行，分桶字段的ndv只有50，那这1亿行按50个键哈希取模，最多也就落进50个桶，桶多了纯属摆设。如果numNulls巨大，空值会被哈希成一个固定点，也会造成单桶倾斜。
另外推荐一个组合拳：先跑SELECT percentile_approx(CAST(bucket_col AS DOUBLE), 0.5)看看中位数，再对比min/max。如果最大最小值跨度很大，但中位数集中在很窄的区间，说明数据分布偏斜，这样的键即使基数高，桶之间也可能不均衡。
4. 优化方案一：重新设计分桶键与桶数
4.1 高基数字段优先
分桶键的第一原则：选基数（cardinality）高且分布均匀的字段。什么是基数高？就是不同值数量足够多，至少大于桶数一个数量级。用户ID、交易流水号、设备唯一标识，这类字段通常可以。状态码、类型码、性别这类字段，哪怕基数有几百，也尽量不要选，除非你每个桶都小到可以忽略。
如果你确实只能用一个低基数字段，比如按地区ID分桶，那就要接受某些地区数据量超大。这时候可以换一种思路：用CONCAT构造复合分桶键。比如把地区ID和用户ID拼成一个字符串，再对整体做分桶。
CREATE TABLE order_bucketed ( order_id STRING, user_id STRING, region_id INT ) CLUSTERED BY (region_id, user_id) INTO 64 BUCKETS;注意，Hive的CLUSTERED BY支持多列，用多列组合哈希比单列要均匀得多。在Inceptor里同样支持。多列分桶的哈希是对各列哈希组合运算，这样即使region_id只有少数值，叠加user_id之后也能打散。
4.2 桶数选择与质数技巧
桶数不是越大越好，但也不是随便填。重新设计分桶键后，桶数要和最终数据量匹配。经验公式是：桶数 = max(1, 预估数据总大小 / 单文件目标大小)。如果期望单个分桶文件在256MB左右，总数据量约10GB，桶数设为40即可；如果你常用Map Join，桶数还要考虑和另外一张表的桶数成倍数关系。
这里有个容易被忽略的技巧：桶数尽量选择质数（或者至少不要选2的幂次）。前面分析了整数取模的特性，如果桶数是10，而整数键以10为周期，那必然倾斜；如果桶数是128，而键的后7位有规律，同样麻烦。质数可以打乱整数公约数带来的周期。实测过同样一张表，桶数从16改成17，倾斜比立刻从1:8降到1:2。这个原理和哈希表设计里“取模用质数”是同一个道理。
当然，质数桶数会带来一个副作用：不好做“桶对齐”。如果你有两张表要做Bucket Map Join，桶数必须成倍数关系（比如一张是4桶，另一张是8桶，或者都是8桶），质数桶数很难和别的表匹配。所以权衡下来，生产环境不少人还是用2的幂次，比如64、128、256。折中方案是选择一个既不是2的幂次、也不是明显公约数的数，比如64的兄弟7？不行，配合Map Join还是得慎重。更推荐的做法：主表用质数桶，小表不强制分桶，让优化器走普通Map Join或者Shuffle Join。
5. 优化方案二：盐值（Salting）与雪崩处理
5.1 加盐思路
如果分桶键没法换，比如必须按user_id分桶才能做bucket pruning，但某些热门用户的数据量特别大，这时候可以用“加盐”来打散热点。
加盐的思路很简单：在分桶键上追加一个随机数或分段编号，使得原本相同的键变成多个不同的键，从而分散到不同桶。下一步给SQL里也做对应处理。
假设原表按user_id分了32桶，现在要按加盐后的键重新分桶。我们可以新建一张表，把user_id和一个盐值拼接：
CREATE TABLE user_salted ( user_id STRING, salt INT, bucket_key STRING ) CLUSTERED BY (bucket_key) INTO 64 BUCKETS AS SELECT user_id, -- 给每个用户分配一个盐值，比如根据user_id哈希取模再映射到0~3 floor(rand() * 4) AS salt, concat_ws('_', cast(user_id AS STRING), cast(floor(rand() * 4) AS STRING)) AS bucket_key FROM user_source;这里的salt可以等于rand()*4取整，也可以根据user_id本身动态计算，保证同一user_id在多次写入时盐值稳定。如果不要求稳定，直接用rand()就行，但会导致同一个user_id跑到不同桶里，之后的查询没法做桶裁剪，所以一般建议盐值对键稳定。
5.2 如何避免影响下游查询
加盐最麻烦的是下游查询要改。比如之前是按user_id分桶做WHERE user_id = 123的bucket pruning，现在分桶键变成了bucket_key，查询时如果知道user_id=123，但不清楚它的盐值是几，就没法精准裁剪到某个桶，只能扫描全表。
解决方案有两个方向：
方向一：查询时在条件里也加盐值。如果我们定义盐值是稳定且可复算的，例如salt = 0到3，那么查询条件改成：
WHERE user_id = 123 AND bucket_key = '123_0'如果用户是在登录状态访问，我们可以从用户信息表里读出该user_id对应的salt并拼进查询条件。这需要业务侧配合，难度略高。
方向二：放弃分桶裁剪，但保留数据分布的均匀性。很多场景下分桶的目的本来就是做Map Join，而不是裁剪。两张表都按相同的加盐逻辑分桶，那么Map Join依然可以生效——因为相同的user_id和相同的salt会落到同一个桶。而且加盐后的桶内数据量更均匀，Join效率反而提升。下游只是不能靠单个user_id快速定位文件，但这类需求本来也可以通过索引或分区解决。
实际项目中我更推荐方向二。分桶最大的价值是让Join双方在Map端完成匹配，加盐不影响这个价值，只是牺牲了单值点查的裁剪。如果点查特别频繁，就别加盐，应当走分区表或单独的热点表。
5.3 盐值设计的细节
盐值的数量（即加盐的分数）取决于热点键的倾斜程度。假设某个user_id的数据占全表的20%，不加盐时它独占1/32的桶，但体量却是其他桶的6倍。加上4个盐值后，这个用户被分成4个桶，每个桶约占5%的数据，而其他用户仍然分布在大约28个桶里，每个桶约占3.2%，差距就缩小到了1.5倍以内。公式是：
期望最大桶比例 = (最大键数据占比 / 盐值数量) + (1 - 最大键数据占比) / (桶数 - 盐值数量)当盐值数量接近桶数时，均匀效果最好，但查询代价也会变大。一般盐值取4到8即可，再往上就属于过度设计，会显著增加文件数和小文件风险。
另一个细节：盐值要作为分桶键的一部分存储，而不是只存在单独一列。如果单独一列没有参与分桶，那么分桶键还是user_id，热点依然在同一个桶，白加盐了。
6. 优化方案三：特殊键隔离与动态处理
6.1 空值/默认值单独归桶
现实业务里很多整数分桶键存在大量的“空值”和“默认值”。例如用户未登录时，user_id可能是0或-1；订单表里未分配仓库时，warehouse_id为空。这些特殊键在哈希取模时会被映射到一个固定的桶。比如0 % 64 = 0，-1 % 64 = 63，NULL的哈希固定为一个常量，于是大量垃圾数据全堆在某个桶里。
对于这种情况，最优雅的做法是把特殊键单独分区，或者写入一个单独的“异常桶”，不让它污染正常点哈希桶。如果不想改动表类型，可以在建表时给特殊键加一个偏置：
CASE WHEN bucket_col IS NULL OR bucket_col <= 0 THEN hash('__NULL__') % bucket_num ELSE hash(bucket_col) % bucket_num END不过Hive的分桶键是直接对列值哈希，无法在CLUSTERED BY里写复杂表达式。因此建议把分桶键改成派生列：
CREATE TABLE t ( bucket_col INT, bucket_id INT ) CLUSTERED BY (bucket_id) INTO 64 BUCKETS; INSERT OVERWRITE TABLE t SELECT bucket_col, CASE WHEN bucket_col IS NULL OR bucket_col <= 0 THEN hash('__NULL__') % 64 ELSE bucket_col % 64 END AS bucket_id FROM src;这样空值会固定进0号桶，其余值正常散列。注意，bucket_id必须和分桶数强相关，而且建表语句里的CLUSTERED BY (bucket_id)要保证写入时按这个列计算桶号。Inceptor中也是同样的逻辑。
6.2 动态修复合规
特殊键的处理还可以做“动态修复”：在ETL脚本里，对热点键单独抽出来加工成小表，或者用UNION ALL把热点键和非热点键分开处理。例如：
INSERT OVERWRITE TABLE result SELECT ... FROM main_table WHERE user_id NOT IN (SELECT hot_user FROM hot_users) UNION ALL SELECT ... FROM hot_table h JOIN dim d ON h.user_id = d.user_id;这种方案适合热点用户只占少数、但查询经常命中这些用户的情况。通过把热点数据单独存放，既能保证主流程不倾斜，又能让热点查询走小而快的路径。
动态修复的另一个常用场景是“二次聚合”。如果你已经对分桶键做了聚合，但聚合结果仍不均衡，可以在聚合表达式里加盐，然后做两阶段聚合：第一阶段加上随机前缀做GROUP BY，第二阶段去掉前缀再汇总一次。虽然这已经不是分桶优化，但针对整数倾斜的聚合任务同样有效，尤其是COUNT DISTINCT这类重算子。
7. 配套优化：小文件、参数与常用函数
7.1 合并小文件
分桶键重新设计后，最怕的是小文件爆炸。尤其是加盐处理，盐值数量一多，每个桶又分成多个文件，小文件数量可能翻几倍。HDFS上每个文件都要占元数据内存，NameNode压力大了，整个集群性能都会下降。处理小文件有两条路：写入时合并和查询时合并。
写入时合并的核心参数是：
SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=true; SET hive.merge.size.per.task=256000000; SET hive.merge.smallfiles.avgsize=128000000;这些参数对Inceptor同样适用，因为Inceptor的SQL解析器兼容Hive。写入前，把hive.merge.size.per.task和目标文件大小对齐，Map端和Reduce端的小文件都会自动合并。
查询时合并主要靠调整InputFormat：
SET hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;CombineHiveInputFormat能把多个小文件合并成一个逻辑分片，减少Map数量。但注意，分桶表的桶裁剪依赖于输入格式对桶内文件的识别，用了CombineHiveInputFormat可能导致桶裁剪失效，所以分桶表更推荐在写入时控制文件数，而不是查询时强行合并。
7.2 常用参数与percentile_approx示例
和分桶相关的参数，生产环境我一般这样设置：
SET hive.enforce.bucketing=true; -- Hive 0.x时代需要，Hive 3.x与Inceptor已默认开启 SET hive.enforce.sorting=true; SET hive.mapjoin.bucket.cache=10000; SET hive.optimize.bucketmapjoin=true; SET hive.optimize.bucketmapjoin.sortedmerge=true;如果两个分桶表的桶数一致、桶内排序一致，且分桶键就是Join键，可以开启bucketmapjoin，让Join在Map端直接完成，大幅度减少Shuffle。
顺带提一下percentile_approx。在分析倾斜桶时，我们可以用它对分桶键的数值分布做快速评估，它本身就是个近似计算函数，消耗资源远小于精确percentile：
SELECT percentile_approx(CAST(user_id AS DOUBLE), 0.5) AS median, percentile_approx(CAST(user_id AS DOUBLE), 0.99) AS p99 FROM your_table;如果p99和median之间的差距非常大，说明存在极端大值的键，这些键往往是倾斜源。比如中位数是1000，p99跑到50万，那尾部那些超出常规的ID就要单独排查。
Inceptor内置了几种分桶相关的自研优化，比如自动评估桶内数据量并动态调整Reduce数。这里建议你查阅对应版本的手册，但通用的原则仍然是：分桶键基数要高、桶数匹配数据量、不要忽视空值。
8. 常见问题排查实录
8.1 桶数不匹配
修改了分桶键或桶数后，最经典的报错是“FAILED: SemanticException Bucket number 20 has no data”。这通常是因为表结构定义CLUSTERED BY ... INTO 20 BUCKETS，但写入数据时实际执行的Reducer数量不是20，导致某些桶没有文件。虽然Hive会自动按照桶数强制reducer数，但如果你手动设置过mapred.reduce.tasks，会覆盖这个逻辑，造成桶空。
解决办法：写入前删除SET mapred.reduce.tasks，或者把它设为分桶数，并让hive.enforce.bucketing=true。Inceptor同样遵循这条规则。
还有一种情况是表已经分桶，但查询时用了WHERE bucket_col % 20 = 3，这种条件不会自动触发桶裁剪，因为优化器只认bucket_col = 3这种等值条件。如果你发现加了分桶条件后查询反而变慢，先查一下执行计划是不是走了全表扫描。
8.2 bucket pruning失效
分桶裁剪（bucket pruning）生效的前提非常苛刻：查询条件必须是分桶键的等值条件，且两边类型完全一致。最常见的问题是整数类型和字符串类型比较。比如分桶键是user_id INT，查询条件写成WHERE user_id = '123'，Hive会做一个隐式类型转换，但优化器有时不认这种转换，直接放弃prune，扫描所有桶。解决方法是严格保持SQL里的类型和分桶键类型一致，不要写字符串数字。
另外，如果分桶键表达式是CAST(user_id AS STRING)，查询条件里直接user_id就没法裁剪。分桶键必须和查询字段一样，并且不能用函数包裹。这也是为什么很多优化方案都强调“分桶键用派生列”时，下游查询必须严格使用该派生列。
8.3 加盐后Join结果不对
加盐表做JOIN时，如果两张表盐值规则不一致，即使盐值列都被加入分桶键，也可能匹配不到。例如左表盐值范围是0~3，右表盐值只用了0~1，那么左表盐值2和3的数据在右表没有对应桶，Join时右表必然缺数据。这类问题不报错，但结果会悄悄变少。
解决方法是保证参与Join的两张表使用完全相同的盐值生成逻辑，并在ETL开始时先从源头统一盐值配置。可以在维度表里冗余一个salt列，每次都根据user_id算出稳定的盐值，比如abs(hash(user_id)) % 4，而不是用rand()。
8.4 全局排序与桶内排序的坑
分桶表可以配合SORTED BY实现桶内排序。但很多同学在重建表时只改了分桶键，没改排序键，导致桶内排序字段和分桶键不一致。这时如果要开启bucketmapjoin的sorted merge优化，条件就不满足，执行计划会悄悄退化成普通Join，性能出现“神秘”下降。排查时看一眼执行计划，确认Map Join的SORT_MERGE标志是否打开。
我个人的实操习惯是：每次调整分桶方案后，必须跑一遍EXPLAIN对比前后计划，同时抽样30分钟到1小时的实时数据做体积分布验证，不要只看全局总量。分布均衡度在一天内的不同时段可能完全不同，比如晚高峰用户活跃度变化会导致某些键的占比被放大。养成写“分桶健康检查”SQL的习惯，把它固化到调度平台里，每周自动跑一次，倾斜问题基本能提前发现。
另外，如果你在Inceptor上做同样的操作，多留个心眼：Inceptor的hash函数在个别版本里对BIGINT的处理与Hive有细微差异，跨平台重放数据时一定要做桶号一致性验证。这属于踩过坑才会知道的点，记录在这里供大家参考。
