Искровые контейнеры, убитые YARN во время группы

Question

У меня есть набор данных, извлеченный из Hbase, который представляет собой длинную форму широкого стола, т.е. имеет rowKey, columnQualifier и value столбцы. Чтобы получить форму pivot, мне нужно сгруппировать по rowKey, который является строкой UUID, в коллекцию и сделать объект из коллекции. Проблема в том, что только группа, которую я могу выполнить, подсчитывает количество элементов в группах; другие групповые неудачи из-за уничтожения контейнера из-за переполнения памяти за пределы контейнеров YARN. Я много экспериментировал с размерами памяти, включая накладные расходы, разбиение на разделы и без сортировки и т. Д. Я даже попал в большое количество разделов, т. Е. Около 10 000, но работа умирает одинаково. Я попробовал оба DataFrame groupBy и collect_list, а также набор данных grouByKey и mapGroups.

Код работает с небольшим набором данных, но не с большим. Набор данных составляет около 500 ГБ в файлах Parquet. Данные не перекошены как самая большая группа в группе, имеют только 50 элементов. Таким образом, всем мне известно, что разделы должны легко вписываться в память, поскольку агрегированные данные на один rowKey не очень большие. Ключи и значения данных в основном являются строками, и их не хватает.

Я пользуюсь Spark 2.0.2; все вышеизложенные вычисления были выполнены в Scala.

Answer 1

Возможно, вы столкнулись с ужасным groupByKey shuffle. Прочтите эту статью Databricks на странице avoiding groupByKey, в которой подробно описываются различия между этими двумя функциями.

Если вы не хотите, чтобы прочитать статью, новелла это: Хотя groupByKey и reduceByKey дают одинаковые результаты, groupByKey инстанцирует перетасовка ВСЕХ данных, в то время как reduceByKey пытается минимизировать перетасовать данных за счет уменьшения первой. Немного напоминает MapReduce Combiners, если вы знакомы с этой концепцией.