Сегодня Apache Hadoop по праву считается главной платформой для хранения и обработки больших данных – и прежде всего, такое положение дел обусловлено удобством его использования. В самом деле: экосистема Hadoop позволяет хранить данные (и получать к ним доступ) при помощи довольно «стандартных» программ-менеджеров (вроде HDFS, HBase, Solr и т.д.), а вот технологию для их обработки каждый волен выбирать сам.
Всеобщее признание Hadoop в мире больших данных обеспечивает огромный выбор фреймворков для обработки информации – как раз тот случай, когда «глаза разбегаются». Так как же сделать правильный, обоснованный и, главное, эффективный выбор для каждого отдельного случая? Ловите нашу краткую инструкцию.
Виды фреймворков для обработки данных
Прежде всего обратимся к общей классификации фрейморков для Hadoop – специалисты подразделяют их на 6 видов:
- Универсальные (общего назначения) фреймворки для Hadoop позволяют использовать низкоуровневые API для обработки данных. Это, например, всем известные MapReduce и Spark, которые предполагают пакетную обработку, но все же используют различные по своей сути модели.
- Абстрактные фреймворки нужны для обработки данных на более высоком уровне абстракции. Основой для них служат либо прикладные интерфейсы (пример: Crunch), либо предметно-ориентированные пользовательские программы (пример: Pig). Чаще всего, абстрактный фреймворк надстраивается над универсальным.
- SQL-фреймворки, как и следует из названия, позволяют пользователю писать запросы к данным в Hadoop. Примерами могут служить Hive (в этом случае SQL-фреймворк является надстройкой над базовым универсальным) и Impala (здесь имеет место быть самостоятельная структура).
- Фреймворки для обработки графов в рамках Hadoop дают возможность работы с деревьями и прочими видами графов. И снова, такие фреймворки либо идут в качестве надстройки (Giraph) или существуют самостоятельно (GraphLab).
- Назначение фреймворков для машинного обучения очевидно из названия – и они, опять же, могут существовать как в виде самостоятельной единицы (Oryx), так и надстраиваться поверх фреймворка общего назначения (MLib для Spark).
- Наконец, обработка данных практически (время ожидания составляет от нескольких сотен миллисекунд до нескольких секунд) в реальном времени осуществляется при помощи фреймворков потоковой обработки. Примером надстраиваемого фреймворка в экосистеме Hadoop может служить Spark Streaming, а Storm можно назвать в числе представителей класса самостоятельных, узкоспециализированных единиц.
В общем-то, в этом списке прослеживается две закономерности. Во-первых, фреймворки делятся на виды исходя из их архитектуры: в общем случае, основные активные компоненты фреймворка могут иметь либо аппаратную природу (например, сервера как в Hive), либо программную (например, библиотеки как в MLib).
Во-вторых, фреймворки могут существовать либо самостоятельно, либо в виде надстройки над универсальной инфраструктурой.
От теории к практике: что выбрать?
Так что же из этого многообразия выбрать в каждом конкретном случае? Ответ зависит от двух факторов: собственно, конкретного случая, а также личного опыта (опыта компании).
Сначала стоит определиться, какой вид фреймворка будет вам наиболее полезен, а затем выбрать из существующих конкретных вариантов. На словах все вроде бы просто, а вот на деле можно и запутаться. Вот несколько рекомендаций, которые помогут направить мысли в нужное русло:
- Универсальный фреймворк пригодится всегда. Дело в том, что даже несколько узкоспециализированных инфраструктур в комплексе не дадут возможности решать более общие задачи, которые неизбежно возникают в работе любой компании, связанной с большими данными. Недаром про Spark, MapReduce и Tez сейчас так много говорят – без них, что называется, никуда. Какой из них выбрать, решать вам, но нужно помнить, что MapReduce существует дольше других, хотя и считается самым медленным среди себе подобных, а вот на Spark в самом фонде сейчас делается наибольшая ставка. Некоторые специалисты даже считают, что последний является преемником MapReduce, который через какое-то время полностью его заменит. Tez отличается от обоих тем, что в его рамках можно строить абстрактные фреймворки, тогда как и Spark, и MapReduce используют API.
- Кстати говоря, сегодня специалисты не считают обязательным использование программных интерфейсов универсальных фреймворков – напротив, рекомендуется по возможности пользоваться надстройками из абстрактных (Pig, Crunch, Cascading) и SQL-фреймворков (Hive, Impala) для обработки данных. Преимущества очевидны: во-первых, не нужно тратить время на работу с прикладными интерфейсами тех же Spark и MapReduce для решения тривиальных задачи обработки данных. Во-вторых, использование абстрактных (включая SQL) фреймворков возможно на базе любого универсального фреймворка, и сменить последний можно безо всяких потерь – переписывать ничего не придется.
- Но: есть два исключения, когда удобнее и эффективнее будет использовать универсальный фреймворк и его API. Первый случай предполагает наличие дополнительной информации (например, метаданных), которую просто невозможно будет учесть на высоком уровне абстракции, либо такая обработка будет неэффективной. Второй случай касается ситуации, когда задача анализа данных в силу обстоятельств настолько сложна и нетривиальна, что решение можно получить только на низком уровне абстракции, фактически, создавая отдельную программу.
- Наконец, фреймворки для машинного обучения, обработки графов и потоковой обработки данных обычно выбираются исходя из конкретной задачи, а также опыта и предпочтений специалистов, которые будут их решать.
Заключение
Экосистема Hadoop на текущий момент достигла той отметки в развитии, когда технология MapReduce уже не является единственным решением для обработки больших объемов данных. Изобилие вариантов может поставить в тупик, но четкая идея о том, чего вы хотите добиться, позволит вам принять верное решение. Надеемся, что наши рекомендации помогут вам в этом. Happy Hadooping!
По материалам: O’Reilly Radar