Marco Liu1. 分区器在整个MapReduce数据流转中的位置与职责
我一直觉得，很多人学MapReduce的时候，把注意力都放在了Map函数和Reduce函数上，对中间那段数据流转过程往往是“知道有，但说不清楚”。尤其是Partitioner这个组件，在很多基础实战教程里甚至只是一句话带过：“默认使用HashPartitioner”。但真正在集群上跑过作业、排查过数据倾斜的人都会明白，Partitioner在MapReduce里扮演的角色，马上就要接近“指挥官”了——它决定了每一条map输出的KV记录到底去哪个Reducer，进而决定了整个作业最终的输出文件划分、Reducer负载均衡，甚至影响作业成败。
先说清楚Partitioner在整个数据流转中的位置。一个完整的MapReduce作业，数据大致是这样走的：输入分片（InputSplit）经过RecordReader逐条读出来，交给Map函数处理，Map函数的输出不是直接写到磁盘的，而是先写进一个内存环形缓冲区。在写入缓冲区之前，框架会调用一次Partitioner的getPartition方法，给每条记录算出一个分区编号，这个编号会连同key、value、key长度、value长度等信息一起写到缓冲区的索引区里。等到缓冲区占用比例达到阈值，就会触发一次Spill（溢写），溢写的时候，缓冲区里的数据会按照“分区号优先、key其次”的规则进行排序，然后按分区顺序写入临时文件。多个临时文件最后会合并成一个大文件，但合并后文件内部依然是按分区划分的。之后各个Reducer通过Shuffle拉取属于自己的那部分分区数据，再进行归并排序和Reduce处理。
所以你会发现，Partitioner的执行时机非常早——它并不是在Map端全部处理完之后才“分配”数据，而是在每一条map输出记录产生的那一刻就完成了决策。也就是说，Map端的所有数据在落盘、排序、合并的过程中，分区号已经写死在元数据里了。后面不管怎么排序、怎么合并，每个分区内部的记录都是固定的一批。这一点特别重要，因为很多人会误以为“Shuffle阶段有一个中间人负责把数据按规则分给Reducer”，实际上分区决定在Map端就做完了，Shuffle只是按分区号去搬运。
如果用生活里的场景类比，Partitioner就像快递分拣中心的自动分拣员。Map阶段是各个网点把包裹收上来，Partitioner给每个包裹贴上目的地标签，分拣流水线根据标签把包裹投递到对应的出港口，每个出港口对应一个Reducer。如果标签贴错了，后面运输、派送全都会乱套。所以你可以不写自定义Partitioner，但你必须理解它的决策逻辑和影响范围，否则出了问题根本无从排查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 默认HashPartitioner的源码逻辑与潜在问题
在Hadoop的MapReduce框架里，如果你不手动设置分区器，默认使用的就是HashPartitioner。它的源码非常短，核心逻辑加起来就三五行：
java复制public class HashPartitioner<K, V> extends Partitioner<K, V> {
public int getPartition(K key, V value, int numReduceTasks) {
return (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks;
}
}
这一行代码把所有逻辑都浓缩了：先取key的hashCode，然后与Integer.MAX_VALUE做一次按位与，目的是把hashCode的最高位符号位清零，确保结果是非负数，然后再对Reducer数量取模，得到一个0到numReduceTasks-1之间的分区编号。
这段代码看起来简单，但它背后有几个值得注意的点。
第一，当numReduceTasks等于1的时候，不管key的hashCode是多少，取模结果永远是0，所有数据都会进入同一个分区。换句话说，默认情况下整个作业只有一个Reducer，Partitioner形同虚设。很多人写入门级的MapReduce程序时不设置reduce数量，跑出来的结果总是只有一个part-r-00000文件，原因就在这里。
第二，这个分区方式是基于“key的哈希值尽量均匀分布”这个假设的。它不关心key是否在业务上有亲缘性，也不关心每条记录的value有多大。也正是因为这个特点，HashPartitioner在真实业务场景中会产生两类很典型的问题。一类是key本身的hashCode分布就不均匀，比如字符串类型的key，如果业务前缀高度集中，hash值很可能出现聚集效应，取模之后会有大量记录落到同一个分区；另一类是不同key的记录数量严重不均衡，比如某个热门key有1000万条记录，其他key都只有几十条，这时候哪怕哈希再均匀，那个包含热门key的分区也会承担巨大压力。
第三，自定义的Writable类型如果重写了compareTo、equals，却没有重写hashCode，或者hashCode实现过于简单，也会导致分区结果和预期完全不一样。Hadoop里常见的Text、LongWritable这些类型，hashCode实现相对靠谱，但如果你在Map阶段输出的是自己定义的Bean对象，又只重写了toString而没有正确重写hashCode，那么同样的业务键在不同的任务实例里可能算出不同的哈希，进而导致同一个逻辑key的数据被分到不同的Reducer。这个坑非常隐蔽，症状是结果时对时错，很难复现。
我记得有一次帮一个团队排查一个诡异的作业：数据量不大，但每次跑完结果都不一样，有时候多几个数字，有时候少几个数字。所有人都在怀疑是网络或者机器问题，最后我让他们把自定义Bean的hashCode打出来看，才发现那个Bean的hashCode方法直接返回了一个随机数。这种极端的错误虽然少见，但它很好地说明了Partitioner这层逻辑对数据归属的重要性——HashPartitioner把“数据归属”完全寄托在key.hashCode()上，hashCode一旦不靠谱，整个分区体系就是空中楼阁。
另外，HashPartitioner不考虑value的内容和大小，只根据key去算分区。这在大多数场景下是没问题的，因为Reducer之间处理的数据量通常应该按“key的个数”去大致均衡，而不是按value的字节数去均衡。但有些业务恰恰是value特别大，比如一个key对应一段很长的文本、一张图片的二进制内容，这时候即使key的个数很均匀，Reducer之间的磁盘IO和内存压力也会完全失衡。这个问题我在后面的数据倾斜章节会展开讲。
3. 自定义Partitioner的完整实战：从需求到Job配置
自定义Partitioner应该是MapReduce基础实战里必须掌握的一个技能。我用一个很常见的例子来讲：假设我们有运营商日志数据，每条记录包含一个手机号和一个通话时长，现在想按号段统计通话总时长，并且把136、137、138、139这几个主要号段拆成四个Reducer分别统计，其他号段统一归到一个Reducer里。
这个需求如果用默认的HashPartitioner，问题很明显：手机号作为key，hash之后分区完全是随机的，你无法保证136号段的数据一定落在同一个Reducer里，也没法控制最终输出文件的业务含义。这时候就需要继承Partitioner类，自己实现分区逻辑。
新API下，自定义Partitioner的代码框架如下：
java复制import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Partitioner;
public class MobilePartitioner extends Partitioner<Text, LongWritable> {
@Override
public int getPartition(Text key, LongWritable value, int numPartitions) {
String phone = key.toString();
// 这里做一层保护：如果手机号异常，放到最后一个分区
if (phone == null || phone.length() < 3) {
return numPartitions - 1;
}
String prefix = phone.substring(0, 3);
switch (prefix) {
case "136":
return 0;
case "137":
return 1;
case "138":
return 2;
case "139":
return 3;
default:
return 4;
}
}
}
对应的Job配置也很简单：
java复制job.setPartitionerClass(MobilePartitioner.class);
job.setNumReduceTasks(5);
这两行配置是配套使用的，少一个都不行。如果你只设置了PartitionerClass，却没设置NumReduceTasks为5，默认的Reduce数量仍然是1，那么所有数据还是只会进0号分区。更准确地说，这种场景下getPartition方法其实会被调用，框架也会拿着你算出来的0到4号分区号去写元数据，但因为Reducer数量是1，最终只有分区0的数据会被第一个Reducer拉取，其余分区数据根本没人消费，作业大概率会报错或者产生“莫名丢失数据”的现象。
还有一种常见的错误是反过来：设置了5个Reducer，但Partitioner方法里在某个分支返回了6或者返回了负数。返回负数会直接触发非法分区号异常；返回超范围的正数则可能在Shuffle阶段出现拉取不到数据或者数据错乱的诡异问题。所以在自定义Partitioner里，我习惯在任何分支的最后都加一个兜底返回，保证返回值一定在[0, numPartitions-1]区间内。
写完代码之后，你可以先不启动整个集群，写一个简单的单元测试单独调用getPartition方法，验证不同key前缀的返回分区号是否符合预期。这个习惯能帮你节省大量调试时间。比如：
java复制MobilePartitioner partitioner = new MobilePartitioner();
Text key136 = new Text("13612345678");
int p = partitioner.getPartition(key136, new LongWritable(10), 5);
System.out.println("136 -> partition " + p);
跑一遍当前main方法，就能确认返回结构。然后再丢进集群跑完整作业。作业跑完后，正常会生成5个输出文件：part-r-00000到part-r-00004。用hdfs dfs -cat分别查看这几个文件，你会发现每个文件里只包含对应号段的数据，而且order by的方式可以辅助验证数据范围。
这种“先单元验证，再集群验证”的流程，是我强烈推荐的。因为Partitioner的逻辑往往不复杂，但它一旦写错，问题会暴露在最终输出结果上，而最终输出结果又是很多其他因素叠加后的产物，排查起来成本很高。提前验证能把这个风险降到最低。
4. 数据倾斜排查：哪些是分区器的锅，哪些不是
在日常运维MapReduce作业时，遇到最多的性能问题就是数据倾斜。很多人一听到数据倾斜，第一反应就是“分区器有问题，我要重写Partitioner”。这个反应方向是对的，但很多时候结论是错的。分区器确实是数据倾斜的一个源头，但绝对不是唯一源头，而且有些倾斜类型不是靠改分区器就能解决的。
先给一个判断框架。先想清楚倾斜发生的位置：Map端是某些MapTask处理的数据量特别大，Reduce端是某些Reducer处理的数据量特别大。我们这里主要讨论Reduce端倾斜。
如果倾斜发生在Reduce端，下一步要看“到底是单个key的数据量巨大，还是很多不同key被哈希到了同一个分区”。这两种情况的表象很像——都是某个Reducer跑得慢、输出文件特别大。但根因和处理方式完全不同。
第一种情况：单个key的数据量巨大。比如一个电商订单表，一个头部商家的订单量占了全表的60%。此时即使其他商家都均匀分布，那个包含头部商家的分区必然承担海量数据。这种情况下，你改Partitioner是没用的，因为同一个key对应的数据必须进入同一个Reducer才能完成基于key的聚合。如果你强行用不同的分区号把同一个key拆开，聚合逻辑就崩溃了。正确的思路是引入“加盐/二次聚合”策略：Map端输出时给key加上随机后缀，让同一个逻辑key的数据先分散到不同Reducer做第一轮局部聚合，然后去掉后缀，再进行第二轮全局聚合。代价是作业变成了两轮MapReduce，但能显著缓解单Key倾斜。
第二种情况：key分布本身不均匀，比如很多不同的key经过哈希取模后，恰好大量集中在某几个分区。这种情况才是Partitioner能直接介入的。你可以通过自定义Partitioner，把hash算法改成更加业务导向的规则。比如按用户所属地域分区、按时间字段分区、按某个业务ID的区间分区，而不是直接用整个key对象去hash。
怎么判断到底是哪种情况？我建议在作业里开启Counters，或者在Reducer的输出路径上记录每个Reducer的输出记录数。最直接的办法是看YARN上每个ReduceTask的处理时间和Shuffle字节数。如果某个Reducer的Shuffle字节数明显偏大，且它对应的key集合里单个key占比也很高，那就是单Key倾斜；如果这个Reducer的key数量确实很多、单个key没那么突出，那就是分区不平衡。多跑几次，把每个Reducer的输出记录数打出来看，基本一目了然。
我以前排查过一个案例：一个统计用户访问次数的作业，按用户ID用默认HashPartitioner分区，6个Reducer，跑起来总是有1个Reducer很慢，另外5个很快就结束了。看Counter发现慢的那个Reducer输出记录数是其他Reducer的两倍多。当时我以为是单用户倾斜，结果细看数据，根本没有头部用户，而是用户ID的hash值分布在这个分区上出现了聚集。后来我把Partitioner改成先提取用户ID的某些业务特征位再取模，才把分区重新拉均衡。
另外，还要提醒一点：Partitioner的均衡是按“key的数量”来均衡的，不是按“value的字节数”来均衡的。如果你的某个key的value特别大，即使它的数量不多，也会拖垮一个分区。这种场景下，单纯重写Partitioner没有意义，需要从存储格式、压缩策略、甚至业务拆分层面去优化，或者接受“倾斜”的存在，给容易倾斜的分区分配更多的资源。这不是MapReduce框架能自动解决的。
5. 分区器与排序、合并、二次排序的协作机制
Partitioner并不单独工作，它是和Map端的排序、合并以及Reduce端的分组机制紧密耦合的。如果不理解这种协作关系，很容易写出“看起来正确、跑起来错误”的代码。
先看Map端溢写（Spill）阶段的排序规则。前面提到，缓冲区里的记录在Spill时会进行排序，排序的key是“分区号+原始key”。也就是说，排序器会先保证分区号小的记录排前面，分区号相同的记录再按key排序。这个设计的目的非常清晰：排序完成后，整个数据文件天然地按分区划分成了一段一段连续的区间，每个区间的内部又是有序的。这样ReduceTask在拉取某个分区数据时，只需要定位文件偏移量，就能迅速找到自己需要的那一段，同时每个分区内部已经有序，Reduce端做归并排序的成本也大大降低。
Combiner的执行位置也依赖Partitioner。如果你设置了Combiner，它并不是在每个key的Map输出产生时立刻执行的，而是在Spill阶段，某个分区内的数据已经按key排好序之后，对同一个分区内部的数据进行局部合并。换句话说，Combiner的数据范围永远不会跨越分区边界，它是“分区内聚合”。这就是为什么Combiner可以在不改变语义的前提下减少Shuffle数据量——它只是把同一个分区内、同一个key的多条记录预先合并了。如果你想把不同分区的数据合并，那就要改Partitioner，而不是Combiner。
再说说二次排序（SecondarySort）。这个技术在生产中的典型场景是：希望同一个分组键的数据进入同一个Reducer，并且在Reducer内部，同一个分组键下的数据又按照另一个字段有序排列。举个例子，假设我们有一批订单数据，想按用户ID分组，在每个用户内部按订单时间倒序排列后输出。
要完成这个需求，至少需要做三件事：
第一步，定义一个组合Key，它包含用户ID和订单时间两个字段。这个Key的compareTo方法要同时参与排序，保证先按用户ID排序，用户ID相同再按时间排序。
第二步，重写Partitioner。它的getPartition方法里，应该只用“用户ID”这个分组维度去计算分区，而不是用整个组合Key去计算。这样就能保证同一个用户ID的所有记录，不管时间字段是什么，都会进入同一个Reducer。这一步如果没做，默认HashPartitioner会对整个组合Key取hashCode，同一个用户ID的不同时间记录可能会被分到不同Reducer，二次排序直接失败。
第三步，自定义GroupingComparator。Reducer端的reduce方法按组读取数据，框架默认用Key本身作为分组依据，如果我们不重写分组比较器，那么每一对不同的Key都会触发一次reduce调用，二次排序同样无法实现。GroupingComparator的作用就是告诉框架：只要用户ID相等，就视为同一组数据。
这三个部分的分工非常清晰：Partitioner负责“路由到同一个Reducer”，Key的compareTo负责“分区内排序”，GroupingComparator负责“Reducer内分组”。很多人写二次排序，重写了Key却没有重写Partitioner和GroupingComparator，导致代码跑得起来，结果却是一堆散乱的记录。实际上，默认的HashPartitioner会对组合Key整体取模，但组合Key的hashCode如果还是只基于用户ID，那倒还好；问题在于很多自定义对象的hashCode方法是自动生成的全字段hash，一旦这样，同组数据就容易被拆散。所以在自定义Key时，一定要保持“分区分组字段一致”的原则：hashCode、equals、GroupingComparator这几个环节，用的都应该是同一个分组字段。
6. 实战中的几个隐蔽坑与经验补充
讲到这里，我觉得有必要把实战中容易踩的几个坑集中整理一下。这些坑单看每个都很简单，但组合在一起就是“看起来全部配置正确，但作业就是不对”。
第一个坑：分区数量与Reducer数量的契约被忽视。Partitioner的返回值必须在[0, numReduceTasks-1]范围内。这句话看起来简单，但实际操作中，很多人会在partitioner类里写死一个常量，比如返回0、1、2三个值，然后设置setNumReduceTasks(4)。这时第3个分区相对Reducer是存在的，但如果某个分支返回了3，没问题；可如果某个分支返回了4，运行时会直接报Illegal partition。更隐蔽的是，如果partitioner所有分支只返回0、1、2，你却设置了5个Reducer，那么分区3和4没有任何数据，作业依然正常，只是生成两个空文件，或者不生成文件。测试的时候不仔细看，根本发现不了。
第二个坑：没有Reduce任务的作业，Partitioner不生效。如果你通过job.setNumReduceTasks(0)把作业设置成纯Map任务，框架会走另一条输出路径，Partitioner根本不会被调用。所以不要把“按Partitioner分区输出”当成map-only作业的输出方案。如果你需要在map-only作业里控制文件数量，应该考虑的是MultipleOutputs，而不是Partitioner。
第三个坑：Combiner与Partitioner的执行顺序。我在前面已经说过，Combiner是分区内执行的。这意味着，如果你设置了Combiner，但Partitioner把同一个key的不同记录分到了不同分区，Combiner能合并的就非常有限，Shuffle数据量也不会明显下降。在做性能调优时，如果发现Combiner的减少量一直上不去，除了看key分布，也要回头确认Partitioner是否合理。
第四个坑：测试数据集过小导致问题被掩盖。Partitioner相关的bug，在小数据集上经常不暴露。因为数据量小，Reducer数量少，哪怕分区逻辑有问题，所有数据也可能被某一个Reducer全部接住，最终结果看起来没错。真正压到集群级数据量时，倾斜问题才会爆发。我建议在做任何涉及Partitioner的改动时，都构造一些带“极端分布”的测试数据，比如一个key占50%、其他key均匀分布的样例，让问题在开发阶段就显形。
第五个坑：全局排序依赖的是TotalOrderPartitioner，不是随意自定义分区。如果你想实现“所有Reducer输出的数据全局有序”，光靠自定义Partitioner返回0、1、2是不够的。你需要明确每个分区的key边界。Hadoop提供了TotalOrderPartitioner，配合InputSampler对输入数据进行采样，估算出合理的分区边界，然后把key按大小区间划分到不同的分区。这里涉及一个关键点：Partitioner返回的是分区号，但全局有序的语义要求你保证“分区0的所有key都小于分区1的所有key”。这个保证需要基于采样结果去建设边界，不能靠拍脑袋。我在实际项目中，只有遇到全局排需求时才会用TotalOrderPartitioner，大部分业务场景用自定义范围分区即可。
第六个坑：不同API版本之间，Partitioner的类路径和配置方式不同。旧版MapReduce API的Partitioner类在org.apache.hadoop.mapred包下，作业配置用的是conf.setPartitionerClass(...)；新版API在org.apache.hadoop.mapreduce包下，作业配置用的是job.setPartitionerClass(...)。虽然大多数新项目都用新版API，但很多历史遗留代码还在跑老版本，排查问题的时候要先确认自己看的是哪套API，否则网上搜到的示例代码根本对不上。
第七个坑，也是我想特别强调的经验：调试Partitioner的时候，优先写单元测试。我通常会在工程里给Partitioner单独建一个测试类，直接构造几条有代表性的数据，调用getPartition方法，断言分区编号。这种测试不依赖集群，秒级跑完，能防住90%的低级错误。启动集群后如果还是不对，再去看YARN日志和Counter。先本地验证，再上集群验证，这套流程能省下大量靠肉眼看输出文件猜原因的时间。
最后再分享一个小技巧。Partitioner的方法签名里其实是可以拿到value的，这意味着你可以根据value的属性来做分区决策。比如Map输出是<订单ID, 订单金额>，你想让大额订单单独一个Reducer做专项统计，小额订单走另一个Reducer，完全可以把value里的金额解析出来，在getPartition里判断后返回不同的分区号。这个技巧在某些业务场景下比单纯依赖key更灵活。不过要注意，这会引入一个隐含假设：“相同key的记录value一定相同或业务上可接受分流”。如果某个key的记录既有大额又有小额，同一个key被分到了不同Reducer，基于key的聚合逻辑就会被破坏。所以用value参与分区前，一定要确认业务语义是否允许。
说了这么多，其实就一句话：Partitioner是MapReduce里最值得花时间吃透的组件之一。它不是Map和Reduce之间无关紧要的“中间过程”，而是决定数据去向和作业整体负载的关键环节。把它的执行时机搞明白、把默认实现的行为边界摸清楚、把自定义逻辑的验证做到位，你的MapReduce作业才算真正有了“指挥官”。