Hadoop組合器排序階段

Question

使用指定的組合器運行MapReduce作業時，組合器是否在排序階段運行？ 我知道組合器在每個溢出的mapper輸出上運行，但似乎在合並排序的中間步驟中運行也是有益的。 我在這里假設在排序的某些階段，某些等效鍵的映射器輸出在某些時候保存在內存中。

如果目前沒有這種情況，是否有特殊原因，或者只是尚未實施的內容？

提前致謝！

Answer 1

組合器可以節省網絡帶寬。

mapoutput直接排序：

sorter.sort(MapOutputBuffer.this, kvstart, endPosition, reporter);

這在實際映射完成后立即發生。 在通過緩沖區的迭代期間，它檢查是否已經設置了組合器，如果是，則組合記錄。 如果沒有，它會直接溢出到磁盤上。

如果你想親自看看它，那么重要的部分就在MapTask 。

    sorter.sort(MapOutputBuffer.this, kvstart, endPosition, reporter);
    // some fields
    for (int i = 0; i < partitions; ++i) {
        // check if configured
        if (combinerRunner == null) {
          // spill directly
        } else {
            combinerRunner.combine(kvIter, combineCollector);
        }
    }

這是保存磁盤空間和網絡帶寬的正確階段，因為很可能必須傳輸輸出。 在合並/混洗/排序階段，它沒有用處，因為與地圖結束時的組合器運行相比，你必須處理更多的數據量。

請注意，Web界面中顯示的排序階段具有誤導性。 這只是純粹的融合。

Answer 2

在處理的地圖方面，有兩個運行Combiner的機會。 （一個非常好的在線參考來自Tom White的“Hadoop：The Definitive Guide” - https://www.inkling.com/read/hadoop-definitive-guide-tom-white-3rd/chapter-6/shuffle-and-排序 ）

在完成每個分區的密鑰的內存中排序之后，以及在將這些已排序的數據寫入磁盤之前，第一個機會來自映射端。 此時運行Combiner的動機是減少最終寫入本地存儲的數據量。 通過在此處運行Combiner，我們還可以減少在下一步中需要合並和排序的數據量。 所以對於發布的原始問題，是的，Combiner已經在這個早期步驟中應用了。

第二次機會在合並和排序溢出文件后立即出現。 在這種情況下，運行Combiner的動機是減少最終通過網絡發送到Reducer的數據量。 此階段受益於Combiner的早期應用，這可能已經減少了此步驟要處理的數據量。

Answer 3

組合器只會運行你如何理解它。

我懷疑組合器僅以這種方式工作的原因是它減少了發送到reducer的數據量。 在許多情況下，這是一個巨大的收獲。 同時，在reducer中，數據已經存在，並且無論是在排序/合並中還是在reduce邏輯中將它們組合在一起，實際上並不重要（它可以在現在或以后完成）。

所以，我想我的觀點是：你可能會像你在合並中所說的那樣通過組合獲得收益，但它不會像地圖側組合器那樣多。

Answer 4

我沒有查看代碼，但是參考了Hadoop：Tom White第3版的權威指南，它確實提到如果指定了組合器，它將在reducer的合並階段運行。 以下摘自文字：

“如果映射輸出足夠小（映射緩沖區的大小由mapred.job.shuffle.input.buffer.percent控制，它指定用於此目的的堆的比例），則將映射輸出復制到reduce任務JVM的內存中。否則，它們被復制到磁盤。當內存緩沖區達到閾值大小（由mapred.job.shuffle.merge.percent控制），或達到閾值數量的地圖輸出（mapred.inmem.merge.threshold）時，它被合並並溢出到磁盤。 如果指定了合並器，它將在合並期間運行，以減少寫入磁盤的數據量 。“