ООМ в тез / улей

[После нескольких ответов и комментариев я задал новый вопрос, основанный на полученных здесь знаниях: Недостаточно памяти в Hive / tez с LATERAL VIEW json_tuple]

Один из моих запросов постоянно выдает ошибку:

ERROR : Status: Failed
ERROR : Vertex failed, vertexName=Map 1, vertexId=vertex_1516602562532_3606java.lang.OutOfMemoryError: Java heap space03, diagnostics=[Task failed, taskId=task_1516602562532_3606java.lang.OutOfMemoryError: Java heap space03_000001, diagnostics=[TaskAttempt 0 failed, info=[Container container_e113_1516602562532_3606_01_000008 finished with diagnostics set to [Container failed, exitCode=255. Exception from container-launch.
Container id: container_e113_1516602562532_3606_01_000008
Exit code: 255
Stack trace: ExitCodeException exitCode=255: 
    at org.apache.hadoop.util.Shell.runCommand(Shell.java:933)
    at org.apache.hadoop.util.Shell.run(Shell.java:844)
    at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:1123)
    at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:237)
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:317)
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:83)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Container exited with a non-zero exit code 255
]], TaskAttempt 1 failed, info=[Error: Failure while running task:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
    at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.initializeAndRunProcessor(TezProcessor.java:173)

Ключевое слово здесь, кажется, java.lang.OutOfMemoryError: Java heap space.

Я огляделся, но ничего из того, что я думал, что понял из Tez, мне не помогает:

  • Yarn-site / yarn.nodemanager.resource.memory-mb увеличен до максимума => Я использую всю доступную память
  • yarn-site / yarn.scheduler.maximum-allocation-mb: то же, что и yarn.nodemanager.resource.memory-mb
  • пряжа-сайт / пряжа.scheduler.minimum-allocation-mb = 1024
  • hive-site / hive.tez.container.size = 4096 (кратное yarn.scheduler.minimum-allocation-mb)

В моем запросе 4 маппера, 3 работают очень быстро, 4-й каждый раз умирает. Вот графическое представление запроса Tez:

графическое представление tez

Из этого изображения:

  • таблица контактов имеет 150 млн строк, 283 ГБ данных, сжатых ORC (есть одно большое поле json с боковым просмотром)
  • таблица m имеет 1 млн строк, 20 МБ сжатых данных ORC
  • таблица c имеет 2k строк, ‹1MB сжатый ORC
  • таблица e имеет 800 тыс. строк, 7 ГБ сжатого ORC
  • e соединяется ЛЕВОЙ СОЕДИНЕНИЕМ со всеми остальными таблицами

e и contact разделены, и в предложении WHERE выбирается только один раздел.

Таким образом, я попытался увеличить количество карт:

  • tez.grouping.max-size: по умолчанию 650 МБ, даже если я уменьшу его до - tez.grouping.min-size (16 МБ), это не имеет значения
  • tez.grouping.split-count даже увеличенный до 1000 не имеет значения
  • tez.grouping.split-wave 1.7 по умолчанию, даже увеличенный до 5 без разницы

Если это актуально, вот еще несколько настроек памяти:

  • mapred-site / mapreduce.map.memory.mb = 1024 (минимальный размер контейнера)
  • mapred-site / mapreduce.reduce.memory.mb = 2048 (2 * минимальный размер контейнера)
  • mapred-site / mapreduce.map.java.opts = 819 (0,8 * минимальный размер контейнера)
  • mapred-site / mapreduce.reduce.java.opts = 1638 (0,8 * mapreduce.reduce.memory.mb)
  • mapred-site / yarn.app.mapreduce.am.resource.mb = 2048 (2 * минимальный размер контейнера)
  • mapred-site / yarn.app.mapreduce.am.command-opts = 1638 (0,8 * yarn.app.mapreduce.am.resource.mb)
  • mapred-site / mapreduce.task.io.sort.mb = 409 (0,4 * минимальный размер контейнера)

Насколько я понимаю, tez может разделить работу на множество нагрузок, что займет много времени, но в конечном итоге завершится. Я ошибаюсь, или есть способ, который я не нашел?

контекст: hdp2.6, 8 узлов данных с оперативной памятью 32 ГБ, запрос с использованием короткого бокового обзора на основе json, запущенного через beeline.


person Guillaume    schedule 23.01.2018    source источник
comment
Что, если вы конвертируете таблицу в формат ORC со сжатием Snappy?   -  person OneCricketeer    schedule 23.01.2018
comment
@ cricket_007 так уже хранятся мои таблицы.   -  person Guillaume    schedule 25.01.2018
comment
Хорошо ... Ничто не мешает вам преобразовать в другой формат с помощью Hive   -  person OneCricketeer    schedule 25.01.2018


Ответы (2)


Проблема явно связана с НЕКОТОРЫМИ данными. Я бы рекомендовал вам добавить DISTRIBUTE BY COL для выбора запроса из источника, чтобы редуктор равномерно распределял данные. В приведенном ниже примере COL3 - это более равномерно распределенные данные, такие как столбец идентификатора. Пример

ORIGINAL QUERY : insert overwrite table X AS SELECT COL1,COL2,COL3 from Y
NEW QUERY      : insert overwrite table X AS SELECT COL1,COL2,COL3 from Y distribute by COL3
person BalaramRaju    schedule 23.01.2018
comment
Я попробую ответить на этот быстрый, но быстрый вопрос: не могли бы вы объяснить «ясно»? Вам кажется очевидным, что данные искажены, но как вы догадываетесь? - person Guillaume; 25.01.2018
comment
Просто догадывайтесь: вы утверждаете: у моего запроса 4 преобразователя, 3 выполняются очень быстро, 4-й умирает каждый раз .. Это уже утверждение для искаженных (неравномерно распределенных) данных. - person huch; 25.01.2018
comment
@ThomasKettenbach, спасибо - я добавил к вопросу графическое представление своего запроса. Как видите, ошибка карты связана с комбинацией других карт (из-за отсутствия лучшей формулировки). Не уверены, можно ли таким образом увидеть асимметрию? Моя первая попытка с distribute by вызвала ту же проблему. - person Guillaume; 25.01.2018
comment
Я не вижу изменений после добавления distribute by. - person Guillaume; 25.01.2018
comment
Привет @Guillaume! Из диаграммы я понимаю, что запрос переводится как MAPJOIN. Вы можете попытаться установить set hive.auto.convert.join.noconditionaltask = false;, если вы можете попробовать это, мы можем определить, что проблема в том, что вы пытаетесь MAPJOIN очень большой набор данных. - person BalaramRaju; 25.01.2018
comment
@BalaramRaju, спасибо, я только что попробовал, но, к сожалению, без разницы. Я добавил дополнительную информацию о размерах таблиц в вопрос, если это необходимо, и экспериментирую с другими настройками соединения. - person Guillaume; 26.01.2018
comment
@BalaramRaju После ваших комментариев я гораздо лучше понимаю мою проблему. Это еще не решено, но я задал другой более точный вопрос: stackoverflow.com/questions/48462896/ - person Guillaume; 26.01.2018

У меня была такая же проблема, и увеличение всех параметров памяти не помогло.

Затем я переключился на MR и получил ошибку ниже.

Failed with exception Number of dynamic partitions created is 2795, which is more than 1000.

После установки большего значения я вернулся к tez, и проблема была решена.

person user3123372    schedule 26.08.2019