Hive + Tez :: Запрос соединения надолго застрял на последних 2 мапперах

У меня есть таблица представлений, объединенная с временной таблицей с намеренно включенными ниже параметрами.

hive.auto.convert.join=true;    
hive.execution.engine=tez;

Фрагмент кода,

CREATE TABLE STG_CONVERSION AS    
SELECT CONV.CONVERSION_ID,
       CONV.USER_ID,
       TP.TIME,
       CONV.TIME AS ACTIVITY_TIME,
       TP.MULTI_DIM_ID,
       CONV.CONV_TYPE_ID,
       TP.SV1
FROM VIEWS TP
JOIN  SCU_TMP CONV ON TP.USER_ID = CONV.USER_ID
WHERE TP.TIME <= CONV.TIME;

В обычном сценарии в обеих таблицах может быть любое количество записей.
Однако в таблице SCU_TMP ожидается только 10–50 записей с одним и тем же идентификатором пользователя.

Но в некоторых случаях несколько идентификаторов пользователей содержат около 10 000 – 20 000 записей во временной таблице SCU, что создает эффект перекрестного произведения.
В таких случаях он будет работать вечно, и для завершения потребуется всего один преобразователь.

Есть ли способ оптимизировать это и запустить это изящно?


hadoop hive hql tez
person Optimus Prime    schedule 12.03.2018    source источник
comment
Попробуйте увеличить параллелизм мапперов. См. этот ответ: stackoverflow.com/a/48487306/2700344   -  person leftjoin    schedule 19.03.2018
comment
tez.grouping.(min/max)-size — это параметр для управления размером разделения входных данных картографов в tez? Если да, если я уменьшу это окно, будет ли обработка разделена на множество картографов?   -  person Optimus Prime    schedule 23.03.2018
comment
Да, это. Уменьшите максимальный и уменьшите минимальный размер. Также проверьте это `set hive.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat;`. Проверьте размеры файлов. Если вам нужен сопоставитель для каждого файла и если есть небольшие файлы, уменьшите минимальный размер, чтобы он соответствовал вашему небольшому размеру файла.   -  person leftjoin    schedule 23.03.2018

Ответы (1)


arrow_upward
2
arrow_downward

Я смог найти решение по следующему запросу.

set hive.exec.reducers.bytes.per.reducer=10000
CREATE TABLE STG_CONVERSION AS    
SELECT CONV.CONVERSION_ID,    
       CONV.USER_ID,    
       TP.TIME,    
       CONV.TIME AS ACTIVITY_TIME,    
       TP.MULTI_DIM_ID,    
       CONV.CONV_TYPE_ID,    
       TP.SV1    
FROM (SELECT TIME,MULTI_DIM_ID,SV1 FROM VIEWS SORT BY TIME) TP    
JOIN  SCU_TMP CONV ON TP.USER_ID = CONV.USER_ID    
WHERE TP.TIME <= CONV.TIME;

Проблема возникает из-за того, что когда в таблице доминирует один идентификатор пользователя, присоединение этого пользователя обрабатывается через один преобразователь, который застревает.

Две модификации:
1) Имя таблицы заменено подзапросом, что добавило процесс сортировки перед объединением.
2) Уменьшен параметр hive.exec.reducers.bytes.per.reducer до 10 КБ.

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

Благодаря этим двум усовершенствованиям пробежка с 10-12 часов сократилась до 45 минут.

person Optimus Prime    schedule 11.05.2018