Pig Inner Join производит работу с 1 подвесным редуктором - PullRequest
Новая
       13

Pig Inner Join производит работу с 1 подвесным редуктором

2 голосов
/ 30 марта 2012

У меня есть Pig Script, над которым я работаю, с внутренним соединением из 2 разных источников данных.Это соединение является первой операцией, вызывающей MapReducing.С единственными операциями перед рукой, являющимися фильтрами и foreachs.Когда это соединение затем выполняется, все идет отлично и быстро, а когда дело доходит до фазы уменьшения, все редукторы, кроме 1, быстро заканчивают.Тем не менее, 1 просто сидит в части сокращения фазы, перетаскивая данные в очень очень медленном темпе.До такой степени, что это может занять до часа + просто ожидание этого 1 редуктора для завершения.Я попытался увеличить редукторы, а также переключиться на перекос, но, похоже, ничего не помогло.

Любые идеи, на которые стоит обратить внимание.

Я также сделал объяснение, чтобы увидеть, если яЯ мог видеть все что угодно, но это просто показывает простой поток работ без ничего удивительного.

1 Ответ

4 голосов
/ 30 марта 2012

Вероятно, происходит то, что один ключ имеет огромное количество экземпляров с обеих сторон, и он взрывается.

Например, если вы присоединитесь: 

x,4      x,'f'
x,5      x,'g'
x,6   X  x,'h'
y,7      x,'i'

... вы получите 12 пар x! Таким образом, вы можете себе представить, что если у вас есть 1000 одного ключа и 2000 одного и того же ключа в другом наборе данных, вы получите 2 миллиона пар только из этих 2000 строк. К сожалению, единственный редуктор должен взять на себя основную силу этого взрыва.

Добавление редукторов или использование косого соединения здесь не поможет, потому что в конце дня один редуктор должен справиться с этим одним большим взрывом пар.

Вот несколько вещей, которые нужно проверить:

  1. Похоже, что только одна клавиша соединения вызывает эту проблему, поскольку забивается только один редуктор. Общий виновник NULL. Может ли столбец в любом из них быть NULL? Если так, это получит огромный взрыв! Попробуйте отфильтровать NULL по внешнему ключу обоих отношений, прежде чем запускать соединение, и посмотрите, есть ли разница. Или вместо NULL ... возможно, у вас есть какое-то значение по умолчанию или одно значение, которое часто встречается.

  2. Попытайтесь выяснить, сколько на самом деле каждого ключа, и выяснить, как будет выглядеть взрыв. Что-то вроде (предупреждение: я на самом деле не тестирую этот код, надеюсь, он работает): 

    A1 = LOAD ... -- load dataset 1
B1 = GROUP A1 BY fkey1;
C1 = FOREACH B1 GENERATE group, COUNT_STAR(A1) as cnt1;

A2 = LOAD ... -- load dataset 2
B2 = GROUP A2 BY fkey2;
C2 = FOREACH B2 GENERATE group, COUNT_STAR(A2) as cnt2;

D = JOIN C1 by fkey1, C2 by fkey2;  -- do the join on the counts
E = FOREACH D GENERATE fkey1, (cnt1 * cnt2) as cnt;   -- multiply out the counts

F = ORDER E BY cnt DESC; -- order it by the highest first
STORE F INTO ...

  3. Точно так же это может не иметь никакого отношения к взрыву. У одного из ваших отношений может быть просто один ключ в кучу раз. Например, в примере с подсчетом слов у редуктора, заканчивающегося словом «the», будет намного больше счета, чем у того, который получает «зебру». Я не думаю, что здесь дело обстоит так, потому что только один из ваших редукторов подвергается забиванию, поэтому я думаю, что № 1, вероятно, имеет место.

Если у вас есть какое-то огромное количество для одного из ключей, вот почему. И вы также знаете, какой ключ вызывает проблему.

...