кто-нибудь находит каскадирование для Hadoop Map Reduce полезным?

имея в виду, что я автор каскадирования...

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

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

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

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

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

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

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

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

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

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

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

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

одно из больших преимуществ над ульем или Свиньей ИМХО что каскадировать одиночный опарник, который ты связываешься со своей работой. Pig и Hive имеют больше зависимостей (например, MySQL) или не так легко встроить.

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

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

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

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

-- Кен

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

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

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

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

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

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.

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

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

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

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

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

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