Я не могу говорить о накладных расходах каскадного задания по сравнению с рисованным необработанным заданием MapReduce, поскольку оно действительно зависит от сложности рабочей нагрузки, версии каскадирования, того, как вы написали каждое задание, погоды внутри Amazon или вашей сети, и т.д.
Тем не менее, каскадирование - это абстракция над MapReduce, и будут некоторые накладные расходы. Но, как абстракция, у него есть возможности делать вещи более эффективно (например, 1.2 будет лениво десериализовывать данные во время сортировки, что-то, что необработанный разработчик MR должен будет кодировать вручную для каждого промежуточного объекта посредством реализации Comparator).
Я подозреваю, что вы предполагаете, что Cascading делает какую-то оптимизацию конфигурации кластера сверх значений по умолчанию. Это не. Поэтому, если вы запустите Каскадный поток без установки каких-либо других свойств Hadoop, скорее всего, вы увидите только один редуктор в каждом задании, так как это значение по умолчанию в Hadoop (см. Mapred-default.xml).
Или ваша работа достаточно проста: он может использовать 'Combiners', который Cascading не поддерживает напрямую, но имеет более гибкую альтернативу с использованием частичной агрегации на стороне карты. Это похоже на комбинаторы, но торгует памятью для процессора, и они не ограничиваются коммутативно-ассоциативными операциями, такими как Combiners. Вот лучшее описание частичное агрегирование .
Я должен сказать, что если ваша рабочая нагрузка достаточно проста (и останется простой) (и Hadoop действительно оправдан здесь ), что вы можете написать пару заданий MR для ее удовлетворения, вам, вероятно, следует придерживаться этого (пока см. ниже).
Но работа, которую я делаю (и я являюсь автором Cascading), приводит к десяткам, если не сотням, в некоторых случаях, MR-заданий. Тот факт, что я на самом деле могу завершить свой проект и получить результаты в течение нескольких дней, перевешивает незначительные накладные расходы каскадирования в некоторых случаях. Например, Каскадирование имеет планировщик быстрого отказа, то есть он не будет запускать Каскадный поток в кластере, если в потоке не удовлетворены все зависимости данных / полей.
Маловероятно, что вы можете иметь эту функцию, если вы объединяете сырые задания MR вместе. более вероятно, что ваша рабочая нагрузка завершится с ошибкой через несколько часов из-за отсутствующей зависимости, которую можно определить только во время выполнения.
Или вы передаете необработанные типизированные «бизнес-объекты» (чтобы обеспечить безопасность типа компилятора), что означает, что вы либо передаете данные через кластер без необходимости, либо у вас есть десятки промежуточных объектов, которые вы должны вручную поддерживать при изменении бизнес-правила обработки данных в восходящем или нисходящем направлении.
Еще один пункт о количестве МР-заданий. Единственный способ снизить стоимость рабочей нагрузки в Hadoop - это уменьшить количество операций ввода-вывода между заданиями в рабочей нагрузке. Обычно это делается путем замены неэффективных алгоритмов на более качественные за счет добавления сложности, добавления большего количества заданий для более разумного выполнения задач. Так что, если вы думаете, что вам нужно всего лишь несколько работ по МР, и вы обнаружите неприятное узкое место в ваших данных при работе в масштабе (что, по крайней мере, всегда случается со мной). Возможно, вам придется применить другой подход к проблеме, что, вероятно, приведет к созданию еще пары рабочих мест. Я знаю, это кажется нелогичным, но это часто случается. В таких случаях вы будете рады, что работаете с абстракцией, в которой вы можете держать голову в проблемном домене, а не в домене MapReduce.
Если вы действительно обеспокоены производительностью, пожалуйста, не стесняйтесь по электронной почте в список рассылки Cascading с вашим кодом, и я или сообщество будем рады помочь определить любые проблемы с ним или в Cascading.