Кто-нибудь находит Cascading для Hadoop Map Уменьшить полезность?

Ответ 1

Я использую Cascading уже пару лет. Я считаю, что это очень полезно. В конечном счете, это касается повышения производительности. Я могу быть намного более эффективным в создании и обслуживании заданий M/R по сравнению с простым Java-кодом. Вот несколько причин, по которым:

• Много кода шаблона, используемого для запуска задания, уже написано для вас.
• компонуемости. Обычно код легче читать и проще повторять, когда он написан как компоненты (операции), которые сшиты вместе для выполнения более сложной обработки.
• Я считаю, что тестирование модулей проще. В каскадном пакете есть примеры, демонстрирующие, как писать простые модульные тесты для непосредственного тестирования вывода потоков.
• Парадигма Tap (источник и приемник) упрощает изменение ввода и вывода задания, поэтому вы можете, например, начать с вывода на STDOUT для разработки и отладки, а затем переключиться на файлы HDFS для пакетных заданий и затем переключитесь на кран HBase для обновлений псевдореальности.
• Еще одно большое преимущество написания каскадных заданий заключается в том, что вы действительно пишете больше factory, который создает задания. Это может быть огромным преимуществом, когда вам нужно что-то построить динамически (т.е. Результаты одного задания контролируют, какие последующие задания вы создаете и запускаете). Или, в другом случае, мне нужно было создать задание для каждой комбинации из 6 двоичных переменных. Это 64 рабочих места, которые все очень похожи. Это было бы хлопот с помощью только снижающих класс карты.

В то время как существует много готовых компонентов, которые вы можете скомпоновать вместе, если какой-то конкретный раздел вашей логики обработки кажется простым, просто написать прямо на Java, вы всегда можете создать каскадную функцию для переноса этого, Это позволяет использовать преимущества Cascading, но очень настраиваемые операции могут быть записаны как прямые java-функции (реализация Cascading-интерфейса).

Ответ 2

Имея в виду, я являюсь автором Cascading...

Мое предложение - использовать Pig или Hive, если они имеют смысл для вашей проблемы, особенно Pig.

Но если вы работаете с данными, а не просто ковыряете свои данные для получения информации, вы обнаружите, что подход Cascading имеет гораздо больший смысл для большинства проблем, чем raw MapReduce.

Ваше первое препятствие с помощью raw MapReduce будет думать в MapReduce. Тривиальные проблемы просты в MapReduce, но гораздо проще разрабатывать сложные приложения, если вы можете работать с моделью, которая более легко сопоставляется с вашей проблемной областью (отфильтруйте ее, проанализируйте, сортируйте, присоединитесь к остальным и т.д.).

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

Кроме того, вы найдете рефакторинг и создание повторно используемого кода намного сложнее, если вам нужно постоянно перемещать функции между картографами и редукторами. или от карт к предыдущему редуктору, чтобы получить оптимизацию. Это приводит к проблеме хрупкости.

Каскадирование верит в неудачу как можно быстрее. Планировщик пытается разрешить и удовлетворить зависимости между всеми этими именами полей до того, как кластер Hadoop даже занят работой. Это означает, что 90% + всех проблем будут найдены до того, как часы ожидания вашей работы найдут его во время выполнения.

Вы можете облегчить это в необработанном коде MapReduce, создав объекты домена, такие как Person или Document, но многим приложениям не нужны все поля вниз. Подумайте, нужен ли вам средний возраст всех мужчин. Вы не хотите платить штраф IO за прохождение целого Лица вокруг сети, когда все, что вам нужно, это двоичный пол и числовой возраст.

С неудачей быстрой семантики и ленивой привязкой приемников и источников становится очень легко создавать фреймворки на Cascading, которые сами создают каскадные потоки (которые становятся многими заданиями Hadoop MapReduce). В проекте, в котором я сейчас участвую, заканчивается 100 заданий MapReduce за каждый запуск, многие из которых созданы на лету, на основе обратной связи с обрабатываемыми данными. Найдите Cascalog, чтобы увидеть пример структуры Clojure для простого создания сложных процессов. Или Bixo для инструментария веб-разработки и фреймворка, который намного проще настроить, чем Nutch.

Наконец, Hadoop никогда не используется в одиночку, это означает, что ваши данные всегда извлекаются из какого-то внешнего источника и затем переходят к другому после обработки. Грязная тайна о Hadoop заключается в том, что это очень эффективная структура ETL (поэтому глупо слышать, как продавцы ETL говорят об использовании своих инструментов для ввода/вытягивания данных на/из Hadoop). Каскадирование облегчает эту боль, позволяя вам писать ваши операции, приложения и модульные тесты независимо от конечных точек интеграции. Каскадирование используется в производстве для загрузки таких систем, как Membase, Memcached, Aster Data, Elastic Search, HBase, Hypertable, Cassandra и т.д. (К сожалению, не все адаптеры были выпущены их авторами.)

Если вы захотите, пришлите мне список проблем, с которыми вы сталкиваетесь с интерфейсом. Я постоянно ищу лучший способ улучшить API и документацию, а сообщество пользователей всегда помогает.

Ответ 3

Я использовал Cascading с Bixo, чтобы написать полный протокол классификации нежелательной почты для большой социальной сети.

Каскадный трубопровод привел к 27 работам MR, которые было бы очень трудно поддерживать в простой MR. Ранее я писал задания MR, но использование чего-то вроде Cascading похоже на переход с ассемблера на Java (insert_fav_language_here).

Одним из больших преимуществ по сравнению с Hive или Pig IMHO является то, что Cascading - это единый банку, которую вы связываете с вашей работой. Pig и Hive имеют больше зависимостей (например, MySQL) или не так просто вставлять.

Отказ от ответственности: Пока я знаю Криса Венселя лично, я действительно думаю, что Cascading - это удар **. Учитывая его сложность, чрезвычайно впечатляет, что я не нашел ни одной ошибки, использующей ее.

Ответ 4

Я преподаю курс Hadoop Boot Camp для Scale Unlimited, а также широко использую Cascading в Bixo и для создания приложений для веб-поиска в Bixo Labs, поэтому я думаю, что я получил хорошую оценку для обоих подходов.

Самое большое единственное преимущество, которое я вижу в Cascading, заключается в том, что он позволяет вам думать о вашем рабочем процессе обработки данных с точки зрения операций над полями и (в основном) не беспокоиться о том, как перенести это представление мира на ключ/которая по своей сути является частью любой реализации сокращения карты.

Самая большая проблема с Cascading заключается в том, что это другой способ мышления о рабочих процессах обработки данных, и есть соответствующий концептуальный "горб", который вам нужно преодолеть, прежде чем все начнет иметь смысл. Кроме того, сообщения об ошибках могут напоминать один из результатов из lex/yacc ( "конфликт в сдвиге/снижении" ):)

- Кен

Ответ 5

Я думаю, что место, которое Cascading преимущества начинают показывать, - это случаи, когда у вас есть куча простых функций, которые должны храниться отдельно в исходном коде, но которые могут быть собраны в состав вашего картографа или редуктора. Объединяя их, ваш основной код с уменьшением кода сильно читается, и их разделение делает программу очень медленной. Каскадный оптимизатор может объединить их, даже если вы пишете их отдельно. Свинья и, в некоторой степени, Hive тоже могут это сделать, но для больших программ я считаю, что у Cascading есть преимущество в обслуживании.

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

Ответ 6

Cascading позволяет вам использовать простые имена полей и кортежи вместо примитивных типов, предлагаемых Hadoop, которые "... имеют тенденцию быть на неправильном уровне детализации для создания сложного, очень сложного кода, который может использоваться совместно разработчики" (Tom White, Hadoop Окончательное руководство). Каскадирование было разработано для решения этих проблем. Имейте в виду, что некоторые приложения, такие как Cascading, Hive, Pig и т.д., Разрабатывались параллельно и иногда делали то же самое. Если вам не нравится Cascading или вы считаете его запутанным, может быть, вам лучше использовать что-то еще?

Я уверен, что у вас уже есть это, но вот руководство пользователя: http://www.cascading.org/1.1/userguide/pdf/userguide.pdf. Он обеспечивает достойную прогулку потока данных в типичном каскадном приложении.

Ответ 7

Я работал над каскадом в течение нескольких лет и ниже полезные вещи в каскадировании.

1. code testability
2. easy integration with other tools
3. easily extensibile
4. you will focus only on business logic not on keys and values
5. proven in production and used by even twitter.

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

Ответ 8

Каскадирование - это оболочка вокруг Hadoop, которая обеспечивает отводы и стоки в Hadoop и обратно.

Написание Mappers и Reducers для всех ваших задач будет утомительным. Попробуйте написать одно каскадное задание, и тогда вы все настроены на то, чтобы не писать никаких картографов и редукторов.

Вы также хотите посмотреть каскадные краны и схемы (это то, как вы вводите данные в свое каскадное задание обработки).

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

Каскадирование - это больше, чем просто обертка вокруг hadoop, я пытаюсь сохранить ответ простым. Например, я портировал огромную базу данных mysql, содержащую терабайты данных, в файлы журналов, используя каскадный переход jdbc