MapReduce 里有一个问题，很多初学者做实训或者面试准备的时候都会碰到：明明已经写好了 Mapper 和 Reducer，程序也能跑通，但输出结果总是跟预期对不上。要么某个 key 的数据跑到了"错误"的 reduce 任务里，要么所有数据都堆到了同一个输出文件，要么做全局排序时区与区之间的边界完全乱了。这时候绝大多数人会去反复检查 Mapper、Reducer 的逻辑，却很少有人意识到，真正在背后决定"数据去哪"的，是那个最容易被忽略的组件——Partitioner（分区器）。
Partitioner 在 MapReduce 作业里扮演的角色，就像快递分拣中心的分流闸口。Map 端吐出来的每一对键值，在落盘并交给下游 Reduce 之前，都要经过它的判断，被分配到不同的分区里。分区的编号，直接决定了这条数据最终会进入哪一个 ReduceTask、写进哪一份输出文件。换句话说，分区器错了，后面所有的排序、分组、归并、输出，全部跟着错。这篇文章我想从最底层的原理说起，结合我在实训和项目中踩过的坑，把 Partitioner 的工作机制、默认行为、自定义写法、以及它和排序、分组、数据倾斜之间的关系一次性讲清楚。
1. Map 端输出后的第一次重要分流：Partitioner 在作业流程中的位置
1.1 从一次 WordCount 看懂数据流向
先回顾一下 MapReduce 的整体数据流，这样才能理解 Partitioner 到底在哪一环起作用。拿最经典的 WordCount 举例：输入是一堆文本文件，Mapper 逐行处理，每碰到一个单词就输出一个<word, 1>的键值对。这些键值对并不会直接送到 Reducer 手里，而是先被写进 MapTask 内部一个环形内存缓冲区（默认 100MB）。当缓冲区占用达到阈值（默认 80%）时，MapTask 会启动一个后台线程，把缓冲区里的数据溢写（spill）到本地磁盘。
溢写之前，有一个极其关键的步骤：分区（partition）。系统会先调用 Partitioner 的getPartition()方法，计算出这条键值对属于哪个分区号，然后按分区号把数据归拢到一起。同时在每个分区内部，还会进行排序（sort）。所以最终的溢写文件，是一个"先按分区号升序、分区内部再按 key 排序"的结构。多个溢写文件之后会被合并（merge）成一个更大的溢写文件，合并时依然保持同样的分区和排序规则。
然后，各个 MapTask 输出的文件，才轮到 ReduceTask 来拉取。ReduceTask 只会拉取属于自己的那部分分区数据——它启动时会带上自己的分区编号，然后把所有 MapTask 输出中对应这个编号的数据拉过来，再做一次归并排序，最后交给 Reducer 的reduce()方法逐组处理。
所以可以看到，Partitioner 的工作发生在 Map 端溢写之前，它决定的是"每条记录进哪个分区"，而分区号又直接对应"哪个 ReduceTask 处理这份数据"。理解了这一环，再去看各种诡异的结果异常，很多都能解释通了。
1.2 分区编号和 ReduceTask 的绑定关系
有一个特别重要的关联需要记牢：分区数量 = ReduceTask 数量，每个分区号对应一个 ReduceTask。这个数量不是自动推导的，而是由job.setNumReduceTasks(n)显式指定的。假如你设置了 3 个 ReduceTask，那么分区号就是 0、1、2 三个。Partitioner 计算出来的分区号一旦越界，比如算出来是 3 或者负数，作业就会直接报错——这是初学者最容易踩的一个坑，后面我会专门讲。
如果你的作业里根本没有调用setNumReduceTasks()，那么默认的 ReduceTask 数量是 1。这时不管 Partitioner 怎么算，最终所有数据都会进入编号为 0 的那个分区，也就会写进同一个输出文件（part-r-00000）。很多人第一次做自定义分区器练习的时候，发现明明写了分区逻辑但输出还是一个文件，十有八九就是没有设置 ReduceTask 数量。这个细节，在后面的实训关卡里可以说是"一票否决"级别的存在。
还有一点值得强调的是，Map 端的分区结果标识的是"逻辑上属于哪个 ReduceTask"，而不是"数据已经发过去了"。真正传输发生在 Map 阶段结束之后，由 Hadoop 框架的 shuffle 机制完成。所以分区器不直接参与网络传输，但它决定了 shuffle 阶段每个 ReduceTask 需要拉取的数据范围，从根源上影响整个作业的负载均衡。
2. 拆解默认行为：HashPartitioner 的哈希取模机制
2.1 默认实现的源码与原理
Hadoop 的默认分区器叫HashPartitioner，代码只有短短几行：
public class HashPartitioner<K, V> extends Partitioner<K, V> { public int getPartition(K key, V value, int numPartitions) { return (key.hashCode() & Integer.MAX_VALUE) % numPartitions; } }核心逻辑一句话：取 key 的hashCode()，先和Integer.MAX_VALUE做位与运算，再对分区数取模。其中& Integer.MAX_VALUE的操作是为了把hashCode()可能出现的负数转换为正数（Integer.MAX_VALUE的二进制是所有位除了符号位都是 1，与运算后符号位被清零）。如果不做这一步，负数的 hashCode 取模后会得到负的分区号，直接导致程序异常。
这种设计的好处是：只要 key 的 hashCode 足够均匀，数据就能比较平均地散落到各个分区里。比如一个文本里有大量不同的单词，单词的哈希值分布相对分散，取模后基本能做到均匀负载。
2.2 哈希取模在哪些场景下会失效
HashPartitioner 看起来简单可靠，但它有一个明显的盲区：它只关心"key 的哈希值"，完全不关心 key 的语义。一旦 key 本身分布不均匀，或者不同 key 的哈希值取模后高度重合，数据倾斜就来了。
举一个我实际遇到过的场景：用 MapReduce 做日志分析，key 是用户 ID。用户 ID 本身是一个从 0 开始递增的长整型，理论上哈希分布没问题。但业务里存在极少数的"超级用户"，他们的请求量占了全体的 60% 以上。由于同一个 key 必须进同一个分区（否则词频、求和这类聚合计算就错了），这 60% 的数据全部涌向同一个 ReduceTask，其他 ReduceTask 却早早空闲。整个作业的完成时间被这一个分区拖死。
还有一种场景是 key 的语义天然带有聚集性。比如按省市分区统计人口，key 是省名。如果直接用 HashPartitioner，"北京""广东"这些高频 key 和"西藏""青海"这类低频 key 的哈希值取模结果完全不可控，很可能出现一个分区承担了全国一半人口、另一个分区只有几千条数据的情况。这种时候，就需要我们绕开默认的哈希取模，根据业务含义自己定义分区策略。
所以，判断默认分区器是否适用，有一个简单的标准：key 的取值是否天然均匀且不需要保持同语义聚合？如果答案是否定的，就要考虑自定义 Partitioner。这个判断标准，在项目初期做好，能省掉后面大量的性能调优时间。
3. 自定义 Partitioner 的完整开发流程：从需求到代码再到验证
3.1 场景建模：分区策略怎么定
自定义 Partitioner 的编写技术门槛不高，真正的难点在于：你如何根据业务需求，设计出一个合理、均匀、可扩展的分区策略。
举个例子，我现在要做一份全国各省的销量统计报表，要求结果按"华东、华南、华北、华中、西南、西北、东北"七个区域各输出一份文件。这个需求如果用默认 HashPartitioner，输出的七份文件里各省归属完全随机，业务上没法用。于是我需要写一个RegionPartitioner，根据省份名字符串判断所属区域，并返回对应的分区号。
分区策略的设计有两条原则值得记住：
- 必须保证同一个 key 的所有记录进同一个分区。这是聚合类计算的红线，破坏了这个原则，结果必错。
- 尽量让各分区数据量接近。如果七个区域里华东的数据占了 70%，那分区结果依然倾斜。这时可能需要进一步拆分，比如把华东再按省份细分分区。
第二条原则往往被初学者忽略。很多人觉得只要"按类别分区"就完事了，却忘了分区的根本目的是让 Reduce 阶段并行处理，负载不均的并行，还不如串行。
3.2 开发细节：getPartition 方法、构造参数与 Driver 配置
自定义 Partitioner 的标准写法是继承Partitioner<KEY, VALUE>抽象类，实现getPartition()方法。以按省份分区为例：
import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Partitioner; public class RegionPartitioner extends Partitioner<Text, Text> { @Override public int getPartition(Text key, Text value, int numPartitions) { String province = key.toString(); String region = getRegion(province); // 给每个区域一个分区号 switch (region) { case "华东": return 0; case "华南": return 1; case "华北": return 2; case "华中": return 3; case "西南": return 4; case "西北": return 5; case "东北": return 6; default: return 6; // 未知区域统一归到最后一个分区 } } private String getRegion(String province) { // 这里映射各省份到区域，省略具体代码 if ("上海".equals(province) || "江苏".equals(province)) return "华东"; // ... return "未知"; } }然后在 Driver 里这样配置：
Job job = Job.getInstance(conf, "province sales report"); job.setJarByClass(ProvinceReportDriver.class); job.setMapperClass(ProvinceMapper.class); job.setReducerClass(ProvinceReducer.class); job.setMapOutputKeyClass(Text.class); job.setMapOutputValueClass(Text.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(Text.class); job.setPartitionerClass(RegionPartitioner.class); job.setNumReduceTasks(7); // 必须和分区号最大值对应 FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1]));注意几个细节：
getPartition()方法里的numPartitions参数，就是setNumReduceTasks()设置的数量。你的分区号必须严格落在[0, numPartitions)区间内。- 如果某条记录的 key 不在预定义集合内，一定要有默认返回，不要让它抛出异常或者返回负数。
- 分区的判断逻辑只在 Map 端执行，每个键值对都会调用一次。所以这里的代码要尽量轻量，避免在
getPartition()里做重量级 IO 或者复杂的计算。
3.3 测试时可以复用的验证思路
写完自定义分区器后，怎么确认它真的按预期工作？我有一个比较高效的验证方法：先在本地用少量数据跑通，然后直接检查输出文件列表和内容分布。
具体做法是，准备一份只有几十行的测试数据，里面覆盖每个分区的代表性 key 和边界 key。跑完作业后，看输出目录下应该生成 N 个part-r-xxxxx文件（N 等于你的 ReduceTask 数），然后逐个检查每个文件里的 key 是否符合预期分区规则。
如果要更精确地验证分区逻辑，可以在 Reducer 的 setup 或者 reduce 方法里临时打印一下上下文信息，或者干脆在写 Reducer 时把 ReduceTask 的分区编号也输出到 value 里：
public static class VerifyReducer extends Reducer<Text, Text, Text, Text> { protected void reduce(Text key, Iterable<Text> values, Context context) { // 临时验证用：把分区号拼到结果里 int partition = context.getTaskAttemptID().getTaskID().getId(); context.write(key, new Text("partition=" + partition)); } }不过这种代码验证完要记得删掉，别留到线上。还有一个思路是单独写一个单元测试，直接实例化自定义 Partitioner，传不同的 key 和 numPartitions，断言返回值是否符合预期。这个方式是最快的，基本不用启动作业。实际开发中，我建议先做单元测试验证分区规则，再跑完整作业做集成验证，效率最高。
4. 与排序和分组的配合：全排序、二次排序场景下分区器的正确打开方式
4.1 分区只决定流向，不负责全局有序
我在热搜词里看到大量"MapReduce 排序"相关的实训内容，比如自定义排序、分组排序、倒排索引等。这些实训里，Partitioner 的作用经常和"排序"混在一起，搞得很多人分不清楚。
需要先明确一个核心事实：分区器本身不排序，它只负责把数据归类到不同分区。每个分区的内部排序是由 Map 端和 Reduce 端的排序机制完成的。默认情况下，Map 端溢写时会对分区内的 key 做一次排序（按 key 的自然顺序或自定义比较器），Reduce 端拉取数据后还会做一次归并排序，最终保证每个分区内是有序的。
但分区与分区之间，是不保证有序的。比如三个分区分别输出 1、3、5 和 2、4、6 的组合，每个分区内部升序，整体输出却是乱的。如果想要全局有序，就必须让分区号本身也按 key 的顺序递增——保证分区 0 的所有 key 都小于分区 1 的所有 key，分区 1 的所有 key 都小于分区 2 的所有 key。这就是所谓的"全排序（Total Sort）"。
实现全排序的思路有两个。最简单粗暴的是把 ReduceTask 设为 1，所有数据进一个分区，整体自然有序，但完全没有并行度，数据量大时效率惨不忍睹。正规的做法是自定义一个采样分区器：先对输入数据采样，估算出 key 的分布区间，然后按区间边界切分分区，使得每个分区内的 key 范围连续且数据量接近。这其实就是 Hadoop 的TotalOrderPartitioner所做的事情。
4.2 二次排序中 Partitioner、SortComparator、GroupingComparator 的分工
很多实训关卡里会出现"分组排序"或者"二次排序"的需求，比如按订单 ID 分组，组内按金额倒序。这需要三个组件协作才能完成：
- Partitioner：决定哪些记录进同一个 ReduceTask。二次排序的场景里，通常按"组 ID"分区，保证同一个组的数据不会散落到多个 reduce。
- SortComparator（排序比较器）：决定分区内记录如何排序。为了实现"组内按金额倒序"，需要把排序键设计为
(组ID, 金额)的组合键，排序比较器先比组 ID，再比金额。 - GroupingComparator（分组比较器）：决定
reduce()方法调用时，哪些记录被视为"同一组"从而被合并到一个 Iterable 里。它的比较逻辑是只看组 ID，组 ID 相同就认为是一组。
三者缺一不可。如果只设置了排序比较器而没设置分组比较器，那么每个独立组合键都会被当成一组，reduce()会被调用无数次；如果只设置了分组比较器而没设置排序比较器，那么组内的数据是无序的，"按金额排序"就无从谈起；如果分区器按组合键（而不是组 ID）来分区，那么同一个组的数据会分散到不同的 ReduceTask 里，整个二次排序彻底失效。
我在做这类实训的时候踩过一个很典型的坑：自定义分区器里我取的是完整组合键去计算哈希，而不是只取组 ID。数据量小的时候看起来没问题，因为正好都进了同一个分区，但数据一多，组合键的哈希值分散，同一个订单 ID 的数据就被劈成了好几份，聚合结果完全错了。后来我总结了一条经验：分区器里使用的 key 维度，必须与分组器使用的 key 维度保持一致，而且这个维度应该是业务上的"组标识"，而不是"组内排序键"。
4.3 实训作业中"自定义分区+排序+分组"的联动示例
拿头歌平台常见的"分组排序"关卡为例，任务是按部门分组，组内按薪资降序排列。可以这样设计：
- Mapper 输出 key 为一个自定义 WritableComparable，内部同时保存部门和薪资两个字段。这样 key 本身就同时承载了分组和排序双重信息。
- 自定义分区器
getPartition()中，只用department字段取哈希或映射分区号。目的就是保证同一部门的所有数据进入同一个 ReduceTask。 - 自定义排序比较器
compare()中，先比较部门，部门相同再比较薪资，薪资按降序。 - 自定义分组比较器中，只比较部门，部门相同即为同一组。
这样一个作业跑下来，最终 reducer 接收到的是"按部门分好组，组内薪资从高到低"的数据流。写进输出文件时，每一组数据正好对应一份连续的记录。
理解透了这个协作机制，再看那些排序类的实训，就不会再觉得"每个排序题都是一个新知识点"了。本质上它们考察的都是同一套能力：合理设计键的结构、正确配置分区器、排序比较器和分组比较器。
5. 数据倾斜排查与应对：分区不均导致的性能雪崩
5.1 倾斜的表现与定位方法
数据倾斜在 MapReduce 作业里是最让人头疼的问题之一。它的典型表现是：整个作业跑很长时间，80% 的 ReduceTask 早就跑完了，但有一个或几个 ReduceTask 卡在 99% 进度上迟迟不结束。如果你打开 ResourceManager 的 Web 界面看任务执行情况，会发现某个 ReduceTask 的 Shuffle 数据量比其他任务多出几个数量级。
定位倾斜的根源，通常从两个角度入手：
- 看 key 本身是否分布极不均匀。比如用户行为日志里的 user_id，少数大客户占了大多数记录。
- 看分区策略是否科学。比如用省份作为 key 做分区统计，人口大省的数据量天然就是小省的几十倍。
排查过程我常用的手段是：在 Mapper 里临时对 key 做一次"计数抽样"，把 key 的出现次数分布打印到日志里；或者直接跑一个简单的 MapReduce 作业做 wordcount，列出 key 计数排名前 50 的数据。看到前几个 key 占了 70% 以上的数据量，基本就实锤了。
5.2 缓解分区倾斜的几个可行方案
一旦确认了倾斜，应对方案要看具体业务场景来定：
方案一：加盐（salted key）。适用于聚合类场景，比如统计热点词的频次。做法是在 Mapper 输出的 key 上拼接一个随机数或分段编号（比如user_id + "_" + (random % 10)），让同一个逻辑 key 的数据被分散到 10 个分区。Reducer 做第一轮局部聚合，得到 10 份部分结果，再用第二轮作业按原始 key 做汇总。这个方案把倾斜的 key 打散，效果立竿见影，代价是多一轮作业。
方案二：自定义更均匀的分区策略。如果倾斜不是由少数热点 key 造成，而是分区策略本身不均衡，直接调整分区算法就行。比如按用户 ID 哈希分区时，可以把取模的基数从"分区数"改为一个更大的质数，再把取模结果映射回实际分区号，让连续的用户 ID 分布得更均匀。
方案三：两级聚合或者 Combine 先行。在 Mapper 端先调用 Combiner，做一个本地预聚合，大量重复 key 的 value 可以先合并成一条，这样网络传输和 Reduce 端的数据量都会大幅下降。这个方法不直接解决分区均匀问题，但能显著降低倾斜分区的绝对数据量。WordCount 场景里效果尤其明显。
方案四：调整 ReduceTask 数量。有时候倾斜不是数据本身的问题，而是分区数量设置不合理。比如分区数为 3，但某个 key 归类到分区 1，那这 1/3 的数据量全都压给了一个任务。适当增加 ReduceTask 数量，能把单分区的负担降下来。当然这只是治标，如果数据倾斜程度很高，还是得回到方案一和方案二。
还需要提一个很容易被忽略的点：数据倾斜不只是会影响性能，还会导致 OOM（内存溢出）。当一个分区拉取到远超预期的数据量时，Reducer 端归并排序所需的内存可能直接打爆容器，表现为任务反复失败或者被 NodeManager 杀死。这种问题光调内存参数是撑不住的，根本上还是得先把数据分流做合理。
6. 自定义 Partitioner 的高发坑位：这些问题我都在实训和项目中真实遇到过
6.1 分区号越界与 ReduceTask 数量不匹配
这是最高发的问题，没有之一。我帮别人排查作业问题的时候，十个自定义分区器的报错里，至少有六个是"分区号越界"。
常见的两种错误写法：
第一种，返回的分区号超过了numPartitions - 1。比如设了 4 个 ReduceTask，但分区逻辑里 switch 分支返回了 5。作业运行时 Map 端会抛出IllegalArgumentException: Partition number out of range之类的异常。
第二种，忽略了numPartitions参数，直接用常量写死分区号。比如始终返回 0、1、2，但 Driver 里只设了 2 个 ReduceTask。通常这种代码，调试时侥幸能跑通一次（因为默认 ReduceTask 数可能正好匹配），换个环境配置就翻车。
我的经验是，自定义分区器的最后一定要加一个"兜底 return"，并且最好在开发阶段做单元测试，把 0 到numPartitions-1的所有返回值验证一遍。另外，分区号尽量在getPartition()里动态判断，不要硬编码，方便后面调整 ReduceTask 数量。
6.2 构造参数和成员变量没有序列化到 Reduce 端
有一点特别容易踩，但很多人完全没有概念：自定义分区器是在 Map 端执行的，但 MapTask 的初始化方式有特殊性。
MapTask 运行自定义 Partitioner 时，会通过反射创建一个实例。如果分区器里有构造参数需要依赖外部传入的数据（比如读配置文件、读数据库），这些操作可以直接在分区器内部做吗？可以，但你要注意序列化问题——MapTask 会把分区器实例序列化后发给每个 MapTask，如果成员变量没有实现序列化，或者依赖的资源在节点间不共享，就会出问题。
这里推荐一个更安全的方式：不要在 Partitioner 里做重量级资源初始化，而是把需要的映射关系做成静态块加载，或者通过 Configuration 传递参数，在 setup 阶段读取。分区器本身应该保持无状态、轻量、确定性强，这样既不容易出 bug，性能也最优。
6.3 自定义分区器与 Combiner、Reducer 的接口不匹配
MapReduce 作业中，Mapper 的输出类型决定了 Partitioner 的输入类型。一个典型错误是：Mapper 输出的 key 是自定义的 Bean 对象，但 Partitioner 里泛型写成了Text，或者强转类型导致ClassCastException。
另一个容易忽略的是 Combiner。Combiner 的输入输出类型必须与 Mapper 输出类型一致（因为 Combiner 被复用的是 Reducer 的 reduce 方法，但输入输出类型要保持同 Mapper），如果你的类型体系没理清楚，分区器在 Map 端溢写阶段就可能因为类型不匹配直接挂掉。
我的建议是：写作业前先画一张表，把 Mapper 输出类型、Partitioner 输入类型、Combiner 输入输出类型、Reducer 输入类型、最终输出类型列出来，逐个核对一致。这个步骤虽然简单，但在实际项目中真的能避免大量返工。
6.4 忽视了 key 的可变性与哈希稳定性
还有一个细节值得单独拎出来说：MapReduce 框架为了提高内存利用率，会复用 key/value 对象。你在分区器里拿到的 key，可能在下一次循环中被框架改写了。如果你的分区逻辑里把 key 转成字符串后存进了一个成员变量，或者基于 key 的哈希值做了某种依赖后续状态的判断，就有可能出现"同一个 key 跑出不同分区号"的诡异问题。
解决办法是分区器内部不保存任何依赖 key 内容的状态，每次getPartition()都直接用当前传入的 key 计算。如果确实需要做缓存或者映射，请确保对象拷贝后使用，不要直接引用框架传进来的 key 对象。
7. 实战经验总结：什么样的分区策略才是好策略
最后结合我自己的实战体会，给想要深入掌握 Partitioner 的读者几个方向性建议。
第一，自定义分区器不是炫技工具。很多人写自定义 Partitioner，纯粹是因为实训题目要求这么做，结果只是为了"自定义"而自定义，分区策略设计得比业务需求还复杂，完全没必要。真正需要自定义分区的场景，无非就是三种：全局有序、按业务类别输出、缓解数据倾斜。如果你不属于这几类，先用好默认的 HashPartitioner 就够了。
第二，分区策略一定要前置设计。我在做网约车、招聘之类的综合清洗项目时，最深的体会就是：数据倾斜和分区不均的问题，越早发现越好改。如果等作业跑到一半才发现某个分区数据量异常，再去修改分区策略，意味着整条链路的 Mapper 和 Reducer 都要跟着调整，成本和风险都很大。
第三，从"会用"到"会调优"之间，关键是建立"分区即负载均衡"的意识。很多人在单机小数据量环境下测试，所有作业秒级跑完，根本感受不到分区的重要性。可一旦上了集群，数据量到了亿级，一个分区策略的错误就能让整个作业多跑几个小时。所以每写一个分区器，我都会问自己一句：如果这个 key 的分布极不均匀，我的分区策略还能抗住吗？
拿我自己来说，现在写 MapReduce 作业时，已经把"检查分区策略"放到了和"检查 Mapper/Reducer 逻辑"同等重要的位置。作业跑完之后，第一步不是看结果对不对，而是先看各个输出文件的大小是否接近。如果某个输出文件大小异常突出，那就说明分区策略还对数据流做了不公平的裁决——这时候分区器的问题优先级最高，因为它是所有后续计算的源头。
