Оценка размера контейнера Tez относительно длины входного разделения

Итак, когда Tez выбирает количество картографов для запуска, он смотрит на количество контейнеров, которые могут работать параллельно (доступные слоты), волновой фактор, местоположение данных в стойке, максимальный размер разделения FileInputFormat, максимальный размер группировки Tez, полосы, которые могут перейти к разделению, несжатому общему размеру данных извлекаемых столбцов и т. д. - он не смотрит на размер контейнера tez.

Таким образом, вычисление количества картографов приводит к входной длине отрезка в байтах на модуль сопоставления, которую можно оценить (перед запуском задания).

Но как оценить общий размер контейнера, необходимый (память) для обработки этого разделения ввода?

Я понимаю, что необходимая память будет зависеть от

  1. Необработанная длина разделения ввода (байты)
  2. Сжатие (в процентах?)
  3. Любой UDF, который будет применяться к записям (вероятно, незначительный)
  4. Векторизация, если используется (логическое значение)
  5. Присоединение к карте, если необходимо (логическое значение)
  6. Сортировка при необходимости (логическое значение)
  7. Буфер, используемый перед записью на диск (в процентах?)

Но как я могу оценить размер контейнера или, скорее, пространство кучи, необходимое внутри контейнера, на основе входных разделенных байтов?

Один из способов — просмотреть выделенные байты кучи задачи сопоставления после одного запуска.

Но есть ли какая-либо формула для оценки COMMITTED_HEAP_BYTES из INPUT_SPLIT_LENGTH_BYTES на основе вышеуказанных факторов или любых других факторов?


google-cloud-dataproc hadoop hive yarn apache-tez
person Run2    schedule 25.09.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не думаю, что длина разделения входных данных для каждого преобразователя напрямую влияет на размер контейнера Tez. Это просто означает, что сплит будет обрабатываться одним маппером, но это не означает, что весь сплит будет загружен в память сразу. Таким образом, длина разделения может быть намного больше, чем размер контейнера Tez, в котором работает картограф.

Как правило,

Установите размер контейнера Tez равным или немного кратным (в 1 или 2 раза) размеру контейнера YARN yarn.scheduler.minimum-allocation-mb, но НИКОГДА не больше, чем yarn.scheduler.maximum-allocation-mb. Вы хотите иметь запас для запуска нескольких контейнеров.

Дополнительные сведения см. в этом документе.

person Dagang    schedule 15.10.2020
comment
У нас есть узлы размером 104 ГБ. Yarn может выделять контейнеры от 1 ГБ до 80 ГБ. Так что размах огромный. Обычно размер группы tez для полос tez.grouping.max-size составляет 1 ГБ. Кроме того, если средний размер файла для таблиц составляет около 1 ГБ, стратегия разделения BI или ETL не будет работать в контейнерах размером 2 ГБ (с использованием приведенного выше правила). Я заметил, что разбиение на 1 ГБ приводит к тому, что на картографах выделяется от 4 до 5 ГБ байтов кучи. Это то, что мне нужно, расчет, основанный на факторах, которые я упомянул в своем вопросе, или на любом другом факторе. - person Run2; 15.10.2020