Конвейер вводит 8 миллиардов строк из GCS и выполняет GroupByKey для предотвращения слияния, групповой шаг выполняется очень медленно

Я читаю 8 миллиардов строк из GCS, обрабатываю каждую строку, а затем вывожу. Мой шаг обработки может занять немного времени и избежать истечения срока аренды рабочих и получения ошибки ниже; Я делаю GroupByKey для 8 миллиардов и группирую по идентификатору, чтобы предотвратить слияние .

Рабочий элемент был безуспешно выполнен 4 раза. Каждый раз рабочий со временем терял связь со службой. Рабочий элемент был предпринят на:

Проблема в том, что шаг GroupByKey занимает целую вечность для завершения 8 миллиардов строк даже на 1000 узлах high-mem-2.

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

Любые идеи о том, как оптимизировать это, приветствуются. Спасибо.


apache-beam google-cloud-dataflow etl bigdata
person PUG    schedule 24.06.2017    source источник
comment
Почему вы пытаетесь предотвратить слияние? Что чтобы избежать истечения срока аренды рабочих мест? Что-то не так, когда вам нужно использовать 1000 узлов только для 8 миллиардов строк. Мы регулярно обрабатываем до 10 миллиардов строк всего за несколько часов всего с 50 ВМ (GCS -> Dataflow -> BigQuery).   -  person Graham Polley    schedule 25.06.2017
comment
Одна из причин, по которой я стараюсь избегать слияния, заключается в том, что команда облачной поддержки сказала. Похоже, что рабочие вашего конвейера тратят слишком много времени на вычисление этапов, и к тому времени, когда они сообщают о состоянии своего рабочего элемента, срок аренды уже истек.   -  person PUG    schedule 26.06.2017
comment
Согласно этому потоку, эта ошибка, которую я получаю, может быть связана с нехваткой памяти на виртуальных машинах stackoverflow.com/questions/43835866/   -  person PUG    schedule 26.06.2017
comment
Вы пытались запустить свой конвейер без GBK и с машинами highmem? Есть удача таким образом?   -  person Pablo    schedule 26.06.2017
comment
Я увеличил тип узла с high-mem-2 до high-mem-4, и эта проблема исчезла. В ближайшее время напишу подробный ответ.   -  person PUG    schedule 27.06.2017

Ответы (1)


arrow_upward
0
arrow_downward

Мне удалось решить эту проблему. С моей стороны было несколько неверных предположений о время потока данных. Я смотрел на свой пайплайн и на шаг с самым высоким временем прохождения стены; который был в днях, я думал, что это узкое место. Но в луче Apache шаг обычно объединяется с шагами ниже по потоку в конвейере и будет выполняться только с такой же скоростью, как шаг вниз по конвейеру. Таким образом, значительного времени стены недостаточно, чтобы сделать вывод, что этот шаг является узким местом в конвейере. Настоящее решение указанной выше проблемы пришло из этой темы. Я уменьшил количество узлов, на которых работает мой конвейер. И изменил тип узла с high-mem-2 на high-mem-4. Хотелось бы, чтобы был простой способ получить показатели использования памяти для конвейера потока данных. Мне пришлось подключиться к виртуальным машинам по ssh и выполнить JMAP.

person PUG    schedule 02.07.2017