Кодирование стирания Hadoop 3.0: влияние на производительность заданий MR?
Я пытаюсь понять, какое влияние может оказать кодирование стирания на карту для снижения производительности заданий.
Перед этим краткий обзор кодирования стирания Hadoop 3.0 с использованием метода Рида-Соломона. Если файл, разбитый на k блоков, закодирован в p блоков четности, то из k + p блоков по крайней мере любые k блоков должны быть доступны для воссоздания файла. В Hadoop 2.0 репликация по умолчанию была 3, поэтому для файла из 10 блоков требуется 30 блоков пространства в кластере. Hadoop 3.0 заявляет, что он обеспечивает сокращение пространства на 50%, поэтому для тех же 10 блоков, когда они хранятся в версии 3.0, потребуется только 15 блоков, т.е. дополнительные 5 блоков можно использовать в качестве блоков четности.
Теперь давайте посмотрим, как производительность Map Reduce будет в 2.0 против 3.0 -
На кластере из 30 узлов (от n0 до n29)
В hadoop 2.0 - если файл (file1) разбит на 10 блоков (частей), при 3-кратной репликации общее количество данных в кластере составит 30 блоков. (Скажем, оригинальные 10 блоков данных хранятся на узлах от n0 до n9. Это НИЧЕГО не имеет значения - это просто для иллюстрации того, как все работает в 3.0)
Теперь карта сокращает программу для этого файла, скажем, выбирает первые 10 узлов, т.е. от n0 до n9, для выполнения 10 заданий MR.
Затем еще один файл (file2) с 20 блоками, т.е. всего 60 блоков данных, включая репликацию, хранится на 30 узлах. (Скажем, исходные 20 блоков данных хранятся в узлах от n0 до n19).
Теперь карта сокращает программу для этого файла, в идеале может выбрать узлы от n10 до n29 для выполнения 20 заданий MR. Это связано с тем, что узлы с n0 по n9 уже обрабатывают программу MR файла file1.
Таким образом, все задания MR двух файлов выполняются на разных узлах и правильно используют кластер.
Теперь перейдем к Hadoop 3.0 - файл (file1) с 10 блоками приведет к 5 блокам четности (принимая улучшение данных с EC в 3.0 до 50%). Скажем, исходные 10 блоков данных хранятся в узлах с n0 по n9, а 5 блоков четности хранятся на узлах с n10 по n14.
Теперь карта сокращает программу для этого файла, поэтому определенно следует выбрать первые 10 узлов, т.е. от n0 до n9, для выполнения 10 заданий MR. Выполнение на узлах с блоками четности может занять больше времени.
Следующий файл (file2) с 20 блоками приведет к 10 блокам четности (опять же, улучшение данных между hadoop 2.0 до 3.0 составило 50%). Скажем, исходные 20 блоков данных хранятся в узлах с n0 по n19, а 10 блоков четности хранятся на узлах с n20 по n29.
Теперь карта сокращает программу для этого файла, поэтому определенно следует выбрать первые 20 узлов, т.е. от n0 до n19, для выполнения 10 заданий MR. Опять же, поскольку работа над блоком четности может занять больше времени.
Если MR-программа file1 и file2 интенсивно использует процессор и память, то они сильно конкурируют друг с другом, в то время как несколько узлов в кластере являются идеальными. Не сценарий полного использования кластера. Если, скажем, несколько заданий перемещены на другие свободные узлы, им придется иметь дело с блоками четности (как уже было сказано) или с извлечением данных из исходных блоков.
Теперь разверните его для большего количества файлов - file3, file4, file5 и т. Д. И MR-программ MRP3, MRP4, MRP5 и т. Д. Больше данных и больше заданий - так что использование и балансировка вычислений кластера, безусловно, является проблемой в 3.0 по сравнению с 2.0,
Поэтому возникает вопрос - не мешает ли EC (кодирование стирания) выбрать правильный узел для программ MR и, таким образом, повлиять / уменьшить вычислительную мощность (производительность) кластера.
(ПРИМЕЧАНИЕ: можно сказать, почему исходные блоки file2 размещаются на узлах с n0 по 19, вместо этого - на n10-29. Правильно. В этом случае 3.0 следует различать между исходными блоками и блоками четности, существующими на каждом узле прямо в то время записи каждого нового файла. Может быть, это так... не уверен, хотя. Но скажем следующий другой файл - приходит файл file3 с вновь 20 оригинальными блоками. Теперь каждый узел имеет равные права и скажет, что n0-n19 - выбор. Теперь MRP1 и MRP3 вызовет ту же проблему, что и выше.)
Этот вопрос является частью серии вопросов, которые у меня есть на EC - другие, как показано ниже -
Кодирование стирания Hadoop 3.0 - определение количества допустимых отказов узлов?