Hadoop Custom Writeable против второго прохода

Question

Я работаю над анализом большого набора данных, в котором используется запись с первичным и вторичным ключами:

• Первичный ключ
• Вторичный ключ
• Дополнительные поля

Первичное-вторичное отображение - «один ко многим» (первичное - «один»). Я хотел бы использовать количество уникальных вторичных серверов на первичное в моем выводе. Максимум будет не более нескольких тысяч вторичных серверов.

Я могу придумать два способа сделать это:

• Определить настраиваемый тип записи для вывода из Map, который содержит набор (хеш-таблица, список, что угодно) уникальных вторичных объектов. Выполните все в одном цикле преобразования / уменьшения, где редуктор объединяет множество вторичных ключей.
• Выполните первичный / вторичный подсчет в своей собственной операции и используйте вывод во вторичном задании.

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

Может кто-нибудь посоветовать, какой лучший подход был бы здесь?

Я также рассматриваю возможность использования Hive - может быть, имеет смысл сгенерировать таблицу, которая содержит все эти данные и выполнить группировку с запросами Hive?

Answer 1

Я бы попробовал просто испустить пары «первичный» - «вторичный» ключ-значение из преобразователя, а затем подсчитать уникальные вторичные ключи в редукторе.Если существует не более нескольких тысяч вторичных значений, проблем не должно быть.В то же время, если у вас есть внешний набор данных - вы можете ожидать его нерегулярности данных, поэтому было бы затруднительно ограничить число уникальных вторичных объектов, которые будут обрабатываться в редукторе, - например, остановить обработку при достижении значений 100K и сообщить об ошибке.
Если вы ожидаете хорошей локализации первичных значений в одном разделе - объединитель сделает хорошую работу по сокращению промежуточных данных.
По поводу улья - если данные в подходящем формате, определенно имеет смысл попробовать.У меня были случаи, когда мы планировали серьезную МР-оптимизацию, а потом обнаружили, что Hive выполняет достаточно хорошую работу.