Короткий ответ - нам нужен MapReduce, когда нам нужен очень глубокий уровень и мелкозернистый контроль на пути, который мы хотим обработать нашими данными. Иногда не очень удобно выражать то, что нам нужно именно в терминах запросов Pig и Hive.
Это не должно быть абсолютно невозможно сделать, что вы можете использовать MapReduce, через Pig или Hive. Благодаря гибкости, предоставляемой Pig and Hive, вы можете как-то справиться с достижением своей цели, но это может быть не так гладко. Вы можете писать UDF или что-то делать и добиваться этого.
Существует нет четкого различия как такового среди использования этих инструментов. Это полностью зависит от вашего конкретного случая использования. На основе ваших данных и вида обработки вам необходимо решить, какой инструмент лучше подходит для ваших требований.
Edit:
Некоторое время назад у меня был случай использования, где я должен был собирать сейсмические данные и запустить аналитику на него. Формат файлов, содержащих эти данные, был несколько странным. Некоторая часть данных была закодирована в EBCDIC, а остальные данные были в двоичном формате. Это был в основном плоский двоичный файл без разделителей типа \ n или что-то в этом роде. Мне было трудно найти способ обработать эти файлы с помощью Pig или Hive. В результате мне пришлось договориться с MR. Первоначально это заняло много времени, но постепенно оно стало более плавным, поскольку MR действительно быстр, как только у вас будет готовый базовый шаблон.
Так, как я сказал ранее, в основном это зависит от вашего варианта использования. Например, повторение каждой записи вашего набора данных очень просто в Pig (только для foreach), но что, если вам нужно foreach n ?? Поэтому, когда вам нужен «тот» уровень контроля над тем, как вам нужно обрабатывать ваши данные, MR более подходит.
Другая ситуация может быть, когда данные являются иерархическими, а не строковыми, или если ваши данные неструктурированы.
Проблема Metapatterns, связанная с привязкой к работе и слиянием задач, проще решить с использованием MR напрямую, а не с использованием Pig/Hive.
И иногда очень удобно выполнять конкретную задачу с использованием какого-либо инструмента xyz по сравнению с использованием Pig/hive. ИМХО, МР оказывается в таких ситуациях лучше. Например, если вам нужно сделать некоторые статистические анализы в вашем BigData, R, используемое с потоком Hadoop, вероятно, является лучшим вариантом.
НТН
Далее , если вам нужно написать много UDAF в Pig/Hive, чтобы решить вашу проблему, лучше всего создать одну карту, уменьшающую работу, которая делает все это.По моему опыту, как только вы приложите усилия, чтобы закодировать работу по сокращению карты, вы в основном вносите в нее простые дополнительные изменения в будущем, в основном внутри метода map/reduce по мере развития бизнес-правил. Когда у вас появятся новые члены команды, вы также захотите, чтобы они поняли нюансы карты, прежде чем они начнут делать серьезные вещи с помощью свиньи/улья, и ваша база кода MR служит для них хорошей ссылкой. –
Полностью согласен с комментарием. Java MR - очень хороший выбор для первой волны работы ETL, так как существует много логики ветвления и поворота. Кроме того, java-код легче тестировать, и иногда это единственный выбор, если вы хотите максимальной производительности. Но многие пользователи Hadoop в основном являются бывшими разработчиками SQL, и они очень неохотно пишут какой-то код, часто тратя слишком много усилий на решение проблемы с SQL или скриптом. С другой стороны, разработчики приложений ex Java не могут написать эффективный код обработки данных, поскольку они не знают, что такое сортировка слияния. – alexeipab