蜂巢，Hadoop的，後面hive.exec.reducers.max

Question

在此的其他問題here

使用hive.exec.reducers.max指令的情況下的力學已忠實地把我難倒了。

從我的角度來看，我認爲配置單元可以處理某種邏輯，例如，在所需的查詢中有N個塊，因此我需要N個映射。從NI將需要一些合理範圍的減速器R，它可以是從R = N/2到R = 1的任何地方。對於我正在研究的蜂巢報告，有1200多幅地圖，沒有任何影響蜂巢制定了約400除了我正在研究一個總共只有70個減速器的集羣外，其他的減速器都很好。即使有合理的工作調度程序，這也會導致積壓，從而導致其他工作掛掉。因此，我嘗試了很多不同的實驗，直到找到hive.exec.reducers.max並將其設置爲類似於60.

結果是，花了248分鐘的配置單元工作，在155分鐘內完成，沒有任何更改結果。有什麼困擾我的是，爲什麼不把Hive的默認值設置爲N從未超過集羣減速器的容量，並且看到我可以用減少的減速器集滾動幾個TB數據，然後蜂巢認爲是正確的，總是嘗試更好並調整這個計數？

Answer 1

你可能想看看（其中談到優化插槽數）：http://wiki.apache.org/hadoop/LimitingTaskSlotUsage

這是我的看法：

1）蜂巢在理想情況下嘗試優化減速機的數量根據根據地圖任務後生成的預期數據量。它會期望底層羣集被配置爲支持相同。

2）關於是否可能不調整這個數還是不是一個好主意：

• 首先讓我們試着來分析一下可能是執行時間下來248分鐘，155的原因分鐘：

案例1：Hive使用400個減速器 問題：只有70個減速器可以在給定的時間點運行。

• 假設沒有JVM重用。一次又一次創建JVM會增加大量開銷。

• 不知道這個：期望400減速器會導致像碎片一樣的問題。如在，假設我知道只有70個減速器可以運行，那麼我的中間文件存儲策略將取決於此。但是，有400名減員者，整個戰略都是折騰。

案例2：蜂房是使用70級減速器 - 這兩個問題得到通過設置這個數字解決。

我想最好設置最大可用減速器的數量。但是，我不是這方面的專家。請讓專家評論一下。

Answer 2

根據我的配置經驗，將mapred.job.reuse.jvm.num.tasks設置爲一個健康的數字（在我的情況下爲8）有助於處理大量這些即席查詢。大約需要20到30秒才能產生一個JVM，所以重用可以幫助很短時間的mappers和reducer（< 30秒）。