3

在这个其他问题的上下文中

使用 hive.exec.reducers.max 指令真的让我感到困惑。

从我的角度来看，我认为 hive 处理某种逻辑，例如，我在所需的查询中有 N 个块，所以我需要 N 个映射。从 NI 将需要一些合理的 reducer R 范围，它可以是从 R = N / 2 到 R = 1 的任何位置。对于我正在处理的 hive 报告，有 1200 多张地图，并且没有任何影响 hive 制定了大约 400 的计划减速器很好，除了我正在处理一个总共只有 70 个减速器的集群。即使使用公平的作业调度程序，这也会导致积压，从而挂起其他作业。所以我尝试了很多不同的实验，直到找到 hive.exec.reducers.max 并将其设置为 60 左右。

结果是，一个耗时 248 分钟的 Hive 作业在 155 分钟内完成，结果没有任何变化。困扰我的是，为什么不将 hive 默认设置为 N 永远不会大于集群减速器的容量，并且看到我可以使用减少的减速器集翻转数 TB 的数据，然后 hive 认为是正确的，总是尝试更好吗并调整这个计数？

4

2 回答 2

2

您可能想看看（其中谈到优化插槽数量）：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 个减速器，整个策略都需要折腾。

案例 2：Hive 使用了 70 个 reducer——这两个问题都可以通过设置这个数字来解决。

我想最好设置最大可用减速器的数量。但是，我不是这方面的专家。让专家对此发表评论。

于 2011-02-18T09:40:23.850 回答
2

根据我的经验，将 mapred.job.reuse.jvm.num.tasks 设置为一个健康的数字（在我的例子中是 8）有助于解决很多这些临时查询。生成一个 JVM 大约需要 20 到 30 秒，因此重用对于短寿命（< 30 秒）的映射器和缩减器有很大帮助。

于 2011-02-24T14:41:18.117 回答