Свинья CROSS против реплицированного JOIN

Мне нужно сделать неравноправное соединение в Pig. Первое, что я хочу попробовать, это CROSS + фильтр:

    together = CROSS A, B;
    filtered = FILTER together BY (JOIN PREDICATE);

Однако одно из отношений определенно достаточно мало, чтобы поместиться в памяти. Это заставляет меня задаться вопросом, как CROSS на самом деле реализован в Pig. Может ли он сделать «реплицированный» КРЕСТ?

Если нет, я мог бы сделать что-то вроде этого:

    small = FOREACH small GENERATE *, 1 AS key:int;
    large = FOREACH large GENERATE *, 1 AS key:int;
    together = JOIN large BY key, small BY key USING 'replicated';
    filtered = FILTER together BY (JOIN PREDICATE);

Увидит ли второй подход какой-либо прирост производительности?


hadoop apache-pig
person user3909850    schedule 12.08.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Таким образом, для большого отношения с записями 2M и малого отношения с записями 500K реплицированное соединение было НАМНОГО быстрее.

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

В тех случаях, когда это невозможно, кажется, что реплицированное соединение с фальшивым ключом — это путь.

person user3909850    schedule 13.08.2014
comment
Реплицированное соединение определенно будет намного быстрее, потому что оно выполняется на карте, а перекрестное соединение вызывает сокращение. Я не уверен, как вы могли бы выполнить соединение с UDF, потому что вы не могли гарантировать, что все ваши ключи соединения будут в одной и той же задаче сопоставления для обоих отношений. - person bridiver; 21.08.2014

arrow_upward
1
arrow_downward

Неплохо подмечено! Действительно хороший вопрос.

Под капотом CROSS переводится в GFCross и COGROUP, как объяснено здесь. Обратите внимание, что философия Pig гласит: «Свинья — это домашнее животное», и поэтому мало что делает для оптимизации производительности. Вместо этого пользователь должен изменить поведение, чтобы получить максимальную производительность для своих данных.

Я думаю (не уверен на 100%), ваше альтернативное решение, реализующее ваш собственный CROSS с использованием JOIN в фиктивном столбце, должно повысить производительность.

В любом случае, вы можете провести пару тестовых прогонов, чтобы сравнить производительность и получить свои результаты самостоятельно!

person Gaurav Phapale    schedule 12.08.2014
comment
Спасибо! Я попробую завтра. приятно знать, что это не очевидно - person user3909850; 13.08.2014