Функция Hive Window ROW_NUMBER без предложения Partition BY для большого (50 ГБ) набора данных работает очень медленно. Есть ли лучший способ оптимизировать?

Question

У меня есть файл HDFS с 50 миллионами записей, а размер исходного файла составляет 50 ГБ.

Я пытаюсь загрузить это в таблицу кустов и создать уникальный идентификатор для всех строк, используя приведенное ниже, при загрузке. Я использую Hive 1.1.0-cdh5.16.1.

row_number () over (order by event_id, user_id, timestamp) в качестве id

Во время выполнения я вижу, что на шаге сокращения 40редукторы назначены. Среднее время для 39 редукторов составляет около 2 минут, тогда как последний редуктор занимает около 25 минут, что, несомненно, заставляет меня поверить, что большая часть данных обрабатывается в одном редукторе.

Я подозревал, что причиной этого является условие Order By. и попробовал следующее,

row_number () over () как id

Тем не менее, я вижу то же поведение.

Думая о парадигме уменьшения карты, она заставляет менячувствую, что если мы не укажем предложение Partition BY, данные должны быть обработаны в одном редукторе (нераспределенном), чтобы увидеть все строки и прикрепить правильный номер строки. Это может быть справедливо для любой оконной функции без предложения «По разделу» или «По» в перекошенном столбце.

Теперь мой вопрос: как нам обойти эту проблему и оптимизировать оконные функции, когда нам нужно избежать предложения «Разделение BY»?

Answer 1

Вы можете использовать UUID:

select java_method('java.util.UUID','randomUUID')

UUID, сгенерированный в вашей системе / рабочем процессе, также будет уникальным в некоторых других системах, поскольку UUID уникален во всем мире. UUID работает полностью распределенно и быстро.

Также в Hive 3.x есть функция SURROGATE_KEY , которую вы можете использовать в DDL

Answer 2

@ leftjoin's Предложение сработало как брелок (ОГРОМНОЕ СПАСИБО!) Для этого варианта использования. Это не было связано с уменьшением шага, и работа была выполнена менее чем за 3 минуты. Я проверил, и это действительно производит уникальный идентификатор. Будет проверять базовый код, так как очень интригующе, что он может генерировать уникальный идентификатор даже с 500 + мапперами.

Поскольку я использую Hive 1.1, я не смог попробовать SURROGATE_KEY

К сожалению, предложение @ Strick's не сработало, но спасибо, что поделились. Использование Cluster By не выдало уникальный идентификатор. Все строки были помечены 1, поскольку мой кластер по предложению имел Natural Key. Поведение «Сортировка по» было похоже на поведение «По порядку» в результатах и ​​производительности (32 минуты для завершения). Возможно, данные направляются через один редуктор, что означает, что в этом случае Sort By эквивалентен Order By. (Хотя я не уверен)

Все еще ищем решение для оконной функции, которое может не иметь предложения Partition By, но должно быть распределено

Answer 3

Вместо заказа попробуйте sort by или cluster by