在 MapReduce 编程模型中，Reducer 的并行度设置会对作业性能产生何种影响？请阐述调整 Reducer 数量的几种常用策略，并讨论如何根据作业特征来确定最优的 Reducer 数量。
考察说明
考察对 MapReduce 作业调优中 Reducer 数量设置及其影响的理解。
回答思路
- 【回答框架 1】Reducer 数量决定 MapReduce 作业的并行度和最终输出文件数。数量过少会导致负载不均和资源利用不足，过多则增加调度开销和 shuffle 压力。通常建议每个 Reducer 处理约 1GB 数据，或遵循集群经验公式，如设置为基础值（如 10 到 100）乘以节点数或 map 槽位数。
- 【回答框架 2】选择最佳数量需考虑数据总量、集群资源（内存、CPU）、每个 Reducer 的预期执行时间及输出文件要求。理想情况下，应使 Reducer 运行时间接近 Map 阶段的执行时间，并确保每个 Reducer 的数据量在可接受范围（如 128MB 到 1GB）。可通过估算输入大小除以目标每 Reducer 数据量来初步确定数量。
- 【回答框架 3】调整策略包括：使用集群配置中的 mapreduce.job.reduces 参数设置默认值；在作业代码中通过 Job 对象的 setNumReduceTasks 方法动态设置；或采用数据采样估算数据分布，结合历史作业调整。对于数据倾斜严重的作业，可采用自定义分区器或增加 Reducer 数量来缓解。
- 【回答框架 4】实际优化应以基准测试为准，观察作业总耗时、资源利用率和 shuffle 阶段瓶颈。最终数量需在作业执行时间和资源消耗间取得平衡，避免因过多 small files 影响后续处理。
- 【关键点 1】Reducer 数量影响并行度和输出文件数，过多或过少均会降低性能。
- 【关键点 2】常见策略：基于数据量估算（如每 Reducer 1GB），或通过集群节点数与槽位数估算。
- 【关键点 3】通过参数 mapreduce.job.reduces 或 API setNumReduceTasks 设置。
- 【关键点 4】最终需结合资源限制、数据分布和基准测试调整，而非仅依赖固定公式。
- 【易错点 1】不能盲目使用公式，须基于实际数据和集群规格调整。
- 【易错点 2】设置的 Reducer 数量过多可能导致大量小文件，影响后续存储和查询。
- 【易错点 3】Reducer 数量与分区数相关，若分区数少于 Reducer 数，会浪费资源。