Понимание слияния в Hadoop на стороне уменьшения

Question

У меня проблема с пониманием процесса слияния файлов на стороне уменьшения в Hadoop, как описано в «Hadoop: The Definitive Guide» (Том Уайт). Ссылаясь на это:

Когда все карты выходы были скопированы, уменьшает хода задачи в фазу сортировки (который правильно следует называть фазу слияния, как сортировка была проведена на стороне карты), который объединяет карты выходов, сохраняя порядок сортировки. Это делается в раундах. Например, для , если было 50 выходов карты, а коэффициент слияния составлял 10 (значение по умолчанию, контролируемое свойством io.sort.factor, как и в слиянии карты ), было бы пять раундов. Каждый раунд объединял бы 10 файлов в один, поэтому в конце было бы пять промежуточных файлов. Вместо того, чтобы иметь окончательный раунд, который объединяет эти пять файлов в один отсортированный файл , слияние сохраняет переход на диск, напрямую подавая функцию уменьшения в последнем фазе: фаза уменьшения. Это окончательное слияние может исходить из смеси сегментов в памяти и на диске.

Количество файлов, объединенных в каждом раунде, на самом деле более тонкое, чем . Цель состоит в том, чтобы объединить минимальное количество файлов , чтобы получить коэффициент слияния для финального раунда. Так что если было 40 файлов, слияние не объединило бы 10 файлов в каждом из четырех раундов , чтобы получить 4 файла. Вместо этого первый раунд объединил бы только 4 файлов, а последующие три раунда объединили бы все 10 файлов. 4 объединенных файла и 6 (еще не загруженных) файлов составляют в общей сложности 10 файлов для финального раунда. Процесс проиллюстрирован на фиг. 6-7. Обратите внимание, что это не изменяет количество раундов; это просто оптимизация , чтобы свести к минимуму количество данных, записанных на диск, , так как окончательный раунд всегда сливается непосредственно в сокращение.

Во втором примере (с 40 файлами) мы действительно получаем коэффициент слияния для финального раунда. В 5-м раунде 10 файлов не записываются на диск, они идут напрямую, чтобы уменьшить. Но в первом примере действительно 6 раундов, а не 5. В каждом из первых пяти раундов 10 файлов объединяются и записываются на диск, а затем в 6-м раунде у нас есть 5 файлов (не 10!), Которые напрямую идут на сокращение. Зачем? Если придерживаться «Цель состоит в том, чтобы объединить минимальное количество файлов, чтобы получить коэффициент слияния для финального раунда», то для этих 50 файлов мы должны объединить 5 файлов в первом раунде, затем 10 файлов в каждом из последующих 4 раундов и то мы получим коэффициент объединения 10 для финального 6-го тура.

Примите во внимание, что мы не можем объединить более 10 файлов в каждом раунде (указанный в данном примере io.sort.factor).

Что я понимаю неправильно в первом примере с 50 файлами, объединенными?

Answer 1

Это то, что я понял. Если вы внимательно прочитаете, важно помнить следующее:

Обратите внимание, что это не изменяет количество раундов; это просто оптимизация, чтобы свести к минимуму количество данных, которое записано на диск, так как окончательный раунд всегда сливается непосредственно в сокращение.

С или без оптимизации, количество раундов слияния остается один и тот же (5 в первом случае и 4 во втором случае).

• Первый случай: 50 файлов объединяются в окончательном 5, а затем они непосредственно подают в «уменьшить» фазы (Всего раундов 5 + 1 = 6)
• Второй случай: 34 файлы объединены в финале 4 и остальные 6 непосредственно считываются из памяти и подаются в фазу «уменьшения» (общий раунд равен 4 + 1 = 5)

В обоих случаях количество раундов слияния определяется конфигурацией mapreduce.task.io.sort.factor, который установлен в 10.

Таким образом, количество слияний ds не изменяется (выполняется оптимизация или нет). Но количество файлов, которые объединены в каждом раунде, может измениться (поскольку инфраструктура Hadoop может внести некоторые оптимизации для уменьшения количества слияний и, следовательно, количества разливов на диск).

Таким образом, в первом случае, без оптимизации, содержимого 50 файлов (объединено в последние 5 файлов) пролиты на диск и эти файлы считываются с диска, во время «сокращения» фазы.

Во втором случае с оптимизацией содержимое 34 файлов (объединенных в последние 4 файла) разливается на диск, и эти файлы считываются с диска, а оставшиеся 6 не объединенных файлов непосредственно считываются из -memory buffer, во время фазы «уменьшения».

Идея оптимизации заключается в минимизации слияния и разлива.