Hadoop Мертв? Часть 1

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

«Инженер данных» .



Hadoop мертв? Часть 1

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

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

Я хотел бы рассмотреть некоторые аргументы относительно состояния Hadoop.



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

У Cloudera есть предложения, которые помогают Hadoop стать готовым решением.

Эти инструменты появились до того, как DevOps стал массовым явлением, и автоматическое развертывание было редкостью.

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

Cloudera в конечном итоге конкурирует со свободным программным обеспечением.

В довершение ко всему, многие разработчики экосистемы Hadoop в то или иное время работали в Cloudera, то есть в конечном итоге они каким-то образом субсидировали бесплатные предложения, с которыми конкурируют. Поскольку 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 являются проектами Apache. Престо — одно из таких исключений.

Другие, такие как ClickHouse, с грядущей поддержкой HDFS и Parquet, многими не будут восприниматься как проект Hadoop, хотя вскоре они поставят галочку на совместимость.

До 2012 года файлов ORC и Parquet не существовало.

Эти форматы способствовали реализации быстрой аналитики в Hadoop. До появления этих форматов рабочие нагрузки были в основном линейно-ориентированными.

Если вам нужно преобразовать терабайты данных и вы можете делать это параллельно, то Hadoop отлично справится с этой задачей.

MapReduce — это платформа, часто используемая для этой цели.

Столбчатые хранилища были предложены для анализа терабайтов данных за считанные секунды.

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

Специалистам по данным может потребоваться лишь небольшой объем данных, чтобы получить представление, но сначала им нужно будет просеять потенциально петабайты данных, чтобы выбрать правильные.

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

MapReduce имеет два функциональных оператора обработки данных, карту и сокращение, и обрабатывает данные как строки.

Spark следует за ним и имеет больше функциональных операторов, таких как фильтр и объединение, а также обрабатывает данные как структурированные в направленном ациклическом графе (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 000 операций в секунду.

AWS S3 сломал многое из файловых систем POSIX для достижения масштабируемости.

Быстрые изменения файлов, например, необходимые при преобразовании файлов CSV в файлы Parquet, невозможны в S3 и требуют чего-то вроде HDFS, если вы хотите распределить рабочую нагрузку.

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

Во-вторых, проект Hadoop Ozone направлен на создание S3 API-совместимой системы, которая сможет хранить триллионы объектов в кластере без необходимости использования собственного облачного сервиса.

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

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

Spark — идеальное решение для распределенного машинного обучения.

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

Я бы научил кого-нибудь сначала писать код SQL и PySpark, а затем научил бы распределять команды AWK по нескольким машинам.

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

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

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

На этом мы завершаем первую часть перевода.

Продолжение следует читай здесь .

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

Теги: #Большие данные #Hadoop #большие данные #Инжиниринг данных

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.