Перевод статьи подготовлен специально для студентов курса «Data Engineer».

---

После того, как и Cloudera, и MapR несколько недель назад объявили о том, что их бизнес переживает трудные времена, я увидел поток постов в социальных сетях с темой «Hadoop мертв». Эти посты не являются чем-то новым, но в секторе, где технические специалисты редко производят качественный материал для социальных сетей, эти возгласы становятся все громче и громче. Я бы хотел рассмотреть некоторые из аргументов, касающихся состояния Hadoop.

Конкуренция с бесплатным

У Cloudera есть предложения, которые помогают Hadoop в большей степени быть готовым решением. Эти инструменты появились до того, как devops стал массовым, а автоматизированное развертывание встречалось редко.

Их инструменты предоставляют выгодные предложения для более чем 2600 клиентов, но большая часть предлагаемого ими программного обеспечения имеет открытый исходный код и предоставляется бесплатно. Cloudera в конечном итоге конкурирует с бесплатным программным обеспечением. В довершение всего, многие разработчики экосистемы Hadoop в то или иное время работали в Cloudera, т.е. в итоге они так или иначе субсидировали бесплатные предложения, с которыми они конкурируют.

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

Другие фирмы, предлагающие готовые решения Spark и Presto, стараются дистанцироваться от бренда Hadoop. Их предложения могут включать сотни файлов .jar из различных проектов Hadoop, но, тем не менее, эти фирмы хотят сделать все возможное, чтобы избежать конкуренции с бесплатными предложениями, при этом снижая свои затраты на разработку за счет использования программного обеспечения с открытым исходным кодом. Продажи не так легки, когда ваш клиент может легально загрузить 80% вашего предложения, не платя за него.

Конкуренция с AWS

В 2012 году я работал над внедрением Hadoop с 25 другими подрядчиками. Некоторые из моих коллег пришли из Google, другие продолжали работать на Cloudera. Был задействован значительный бюджет, команда произвела много оплачиваемых часов, но очень малая часть экосистемы Hadoop была готова.

В течение нескольких лет появилась AWS EMR и начала поглощать свою долю рынка. EMR позволяет запускать кластеры Hadoop с большим разнообразием программного обеспечения, устанавливаемого всего за пару кликов. Он может работать в точечных экземплярах, которые сокращают затраты на оборудование на ~80%, и может хранить данные на S3, который был и остается дешевым и надежным на все 99,9999999999%.

Внезапно потребность в 25 подрядчиках на проекте исчезла. На некоторых проектах мог быть задействован только я, занятый полный рабочий день, и несколько других частично занятых, готовящих инфраструктуру в дополнение к нашим другим обязанностям. По-прежнему существует потребность в консультантах по проектам, использующим AWS EMR, но общий потенциал выставления счетов для такого рода работ намного меньше, чем несколько лет назад.
Какая доля потенциального бизнеса Cloudera была потеряна в пользу EMR? Cloudera проделала хорошую работу по организации настройки и управлению кластерами на голом железе, но сегодня большая часть мира данных находится в облаке. Стоит задуматься о том, насколько Hadoop привлекателен для бизнеса хотя бы потому, что в AWS есть управляемое предложение с точечными экземплярами.

Что такое Hadoop?

Если бы вы спросили меня определение Hadoop, я бы сказал, что это большая коллекция программного обеспечения с открытым исходным кодом, которое в определенной степени интегрируется друг с другом и имеет несколько общих библиотек. Я вижу Hadoop как разделенную базу данных, почти как дистрибутив операционной системы для данных.
Не все программные проекты под эгидой Hadoop являются проектами Apache. Presto является одним из таких исключений. Другие, такие как ClickHouse, с предстоящей поддержкой HDFS и Parquet, не будут восприниматься многими как проект Hadoop, хотя скоро они поставят галочку в графе совместимости.

До 2012 года не существовало ни файлов ORC, ни Parquet. Эти форматы способствовали реализации быстрой аналитики в Hadoop. До этих форматов рабочие нагрузки были в основном строчно-ориентированными. Если вам нужно преобразовать терабайты данных и вы можете сделать это параллельно, то Hadoop отлично справится с этой задачей. MapReduce был фреймворком, часто используемым для этой цели.

То для чего предлагались колоночные хранилища — это анализ терабайтов данных за считанные секунды. Что оказалось более ценным предложением для большего числа предприятий. Ученым, работающим с данными, может быть нужен лишь небольшой объем данных, чтобы получить представление, но сперва им нужно будет просмотреть потенциально петабайты данных, чтобы выбрать подходящие. Колоночная аналитика является для них ключевой в своей беглости обработки данных, необходимой для понимания того, что нужно отобрать.

MapReduce имеет два функциональных оператора обработки данных, map и reduce, и воспринимает данные в виде строк. Spark следует сразу за ним и имеет больше функциональных операторов, таких как filter и union, и воспринимает данные структурированными в направленный ациклический граф (Directed Acyclic Graph — DAG). Эти элементы позволили Spark запускать более сложные рабочие нагрузки, такие как машинное обучение и графическая аналитика. Spark по-прежнему может использовать YARN в качестве планировщика емкости, почти так же, как выполняются задачи в MapReduce. Но команда Spark также начала встраивать свой собственный планировщик и позже добавила поддержку Kubernetes.

В какой-то момент сообщество Spark попыталось дистанцироваться от экосистемы Hadoop. Они не хотели, чтобы их видели надстройкой над легаси софтом или как своего рода «дополнение» для Hadoop. Учитывая уровень интеграции, который Spark имеет с остальной частью экосистемы Hadoop, и учитывая сотни библиотек из других проектов Hadoop, используемых Spark, я не согласен с мнением, что Spark — это обособленный продукт.

MapReduce, возможно, не является первым выбором для большинства рабочих нагрузок в наши дни, но он по-прежнему является базовой средой при использовании hadoop distcp — программного пакета, который может передавать данные между AWS S3 и HDFS быстрее, чем любое другое предложение, которое я тестировал.

Является ли каждый инструмент Hadoop успешным?

Нет, есть некоторые проекты, которые уже затмили новинки.

Например, многие рабочие нагрузки, которые раньше были автоматизированы с помощью Oozie, теперь автоматизируются с помощью Airflow. Роберт Кантер, основной разработчик Oozie, предоставил значительную часть кодовой базы, которая существует сегодня. К сожалению, Роберт больше не принимал такого активного участия в проекте с тех пор, как покинул Cloudera в 2018 году. Между тем, у Airflow более 800 участников, число которых почти удвоилось за последний год. Почти каждый клиент, с которым я работал с 2015 года, использовал Airflow как минимум в одном отделе в своих организациях.

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

В 2010 году было несколько проектов, которые позиционировались первым выбором для различных рабочих нагрузок, в которых было только несколько участников или в некоторых случаях несколько значительных развертываний. То, что эти проекты приходят и уходят, использовалось как свидетельство того, что вся экосистема Hadoop умирает, но я не делаю из этого таких выводов.

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

ОБНОВЛЕНИЕ: я первоначально заявил, что у Oozie было 17 участников, основываясь на том, что сообщается в GitHub. На самом деле у Oozie были как прямые коммиты, так и патчи, представленные 152 разработчиками, а не только 17, которые фигурируют в расчете GitHub. Роберт Кантер обратился ко мне после первоначальной публикации этого поста с доказательствами этих дополнительных 135 авторов, и я благодарю его за это разъяснение.

Поисковый трафик не работает

Одним из аргументов в пользу «гибели» Hadoop является то, что поисковый трафик Google по различным технологиям Hadoop не работает. Cloudera и ряд других консультантов проделали хорошую работу по сбору средств в прошлые годы и приложили значительные усилия для продвижения своих предложений. Это, в свою очередь, вызвало большой интерес, и в какой-то момент в техническом сообществе появилась волна людей, изучающих эти технологии. Это сообщество разнообразно, и в какой-то момент большинство людей, как и всегда, перешли к другим вещам.

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

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

Почему Hadoop особенный?

Во-первых, существуют кластеры HDFS с емкостью более 600 ПБ. Характер метаданных HDFS в оперативной памяти означает, что вы можете легко обрабатывать 60 тыс. операций в секунду.
AWS S3 сломал многое из того, что можно найти в файловых системах POSIX для достижения масштабируемости. Быстрые изменения файлов, такие как те, которые требуется при преобразовании файлов CSV в файлы Parquet, невозможны в S3 и требуют чего-то вроде HDFS, если вы хотите распределить рабочую нагрузку. Если программное обеспечение для преобразования было изменено, чтобы сделать вышеупомянутую рабочую нагрузку только для S3, компромиссы с локальностью данных, вероятно, будут существенными.

Во-вторых, проект Hadoop Ozone направлен на создание S3 API-совместимой системы, которая может хранить триллионы объектов в кластере без необходимости использования собственного облачного сервиса. Проект нацелен на то, чтобы иметь встроенную поддержку Spark и Hive, что дает ему хорошую интеграцию с остальной частью экосистемы Hadoop. После выпуска это программное обеспечение станет одним из первых таких предложений с открытым исходным кодом, которые могут хранить столько файлов в одном кластере.

В-третьих, даже если вы не работаете с петабайтами данных, API, доступные вам в экосистеме Hadoop, предоставляют согласованный интерфейс для обработки гигабайтов данных. Spark является окончательным решением для распределенного машинного обучения. Как только освоитесь с API, не имеет значения, измеряется ли ваша рабочая нагрузка в ГБ или ПБ, код, который вы создаете, не нужно переписывать, вам просто нужно больше машин для его запуска. Я бы сначала стал учить кого-нибудь писать код SQL и PySpark, а уже затем научил бы их распределять команды AWK на нескольких машинах.

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

На этом мы завершаем первую часть перевода. Продолжение опубликуем в ближайшие дни. А сейчас ждем ваши комментарии и приглашаем всех на бесплатный вебинар по теме: «Принципы построения систем потоковой аналитики».