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

Question

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

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–20 тыс. Записей в таблице временных характеристик SCU, что создает эффект кросс-продукта.
В таких случаях он будет работать вечно только с 1 картографом для завершения.

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

Answer 1

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

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 минут.