在另一个问题的上下文中 here
使用 hive.exec.reducers.max 指令真的让我感到困惑。
从我的角度来看，我认为 hive 在某种逻辑上工作，比如，我在所需的查询中有 N # 个 block ，所以我需要 N 个 map 。从 N 开始，我将需要一些合理范围的 reducer R，它可以是从 R = N/2 到 R = 1 的任何地方。对于我正在处理的 hive 报告，有 1200 多个 map 并且没有任何影响， hive 制定了大约 400 个的计划reducers 这很好，除了我在一个总共只有 70 个 reducers 的集群上工作。即使使用公平的作业调度程序，这也会导致积压，从而挂起其他作业。所以我尝试了很多不同的实验，直到找到 hive.exec.reducers.max 并将其设置为 60 之类的值。
结果是，一项耗时 248 分钟的 Hive 作业在 155 分钟内完成，结果没有任何变化。困扰我的是，为什么 hive 的默认值 N 永远不会大于集群 reducer 的容量，并且看到我可以使用一组减少的 reducer 滚动数 TB 的数据，然后 hive 认为是正确的，总是尝试更好吗并调整这个计数？
最佳答案
你可能想看一下(它讨论了优化槽的数量):http://wiki.apache.org/hadoop/LimitingTaskSlotUsage
我的观点是:
1) Hive 理想情况下会尝试根据 map 任务后生成的预期数据量来优化 reducer 的数量。它期望底层集群被配置为支持相同的。
2) 关于调整这个计数是否是个好主意:
- 首先让我们尝试分析执行时间从 248 分钟下降到 155 分钟的可能原因:
案例 1:Hive 使用 400 个 reducer 问题:在给定时间点只能运行 70 个 reducer 。
假设没有 JVM 重用。一次又一次地创建 JVM 会增加大量开销。
对此不确定:期望 400 个 reducer 会导致碎片化等问题。比如，假设我知道只有 70 个 reducer 可以运行，那么我的中间文件存储策略将取决于此。但是，如果有 400 个 reducer，整个策略就需要折腾了。
案例 2:Hive 使用 70 个 reducer - 这两个问题都通过设置这个数字得到解决。
我想最好设置最大可用 reducer 的数量。但是，我不是这方面的专家。请专家对此发表意见。
关于performance - Hive、hadoop 和 hive.exec.reducers.max 背后的机制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5025754/