Что такое orc hadoop
Новое в Hadoop: познакомимся с различными форматами файлов в Hadoop
Всем привет! Публикуем перевод статьи, подготовленный для студентов новой группы курса «Data Engineer». Если интересно узнать, как построить эффективную и масштабируемую систему обработки данных с минимальными затратами, посмотрите запись мастер-класса Егора Матешука!
Несколько недель назад я написал о Hadoop статью, где осветил различные его
части и разобрался в том, какую роль он играет в области data engineering. В этой статье я
дам краткое описание различных файловых форматов в Hadoop. Это быстрая и легкая
тема. Если вы пытаетесь понять, как работает Hadoop и какое место он занимает в работе
Data Engineer, ознакомьтесь с моей статье о Hadoop здесь.
Форматы файлов в Hadoop делятся на две категории: row-oriented и column-
oriented.
Row-oriented:
Строки (row) данных одного типа хранятся вместе, образуя непрерывное
хранилище: SequenceFile, MapFile, Avro Datafile. Таким образом, если необходимо
получать доступ только к небольшому количеству данных из строки, все равно вся строка
будет считана в память. Задержка сериализации может до определенной степени
облегчить проблему, но полностью от накладных расходов чтения всей строки данных с
диска избавиться не удастся. Хранилище, ориентированное на строки (row-oriented)
походит в тех случаях, когда необходимо одновременно обрабатывать всю строку
данных.
Column-oriented:
Весь файл разрезается на несколько столбцов данных и все столбцы данных
хранятся вместе: Parquet, RCFile, ORCFile. Формат, ориентированный на столбцы (column-
oriented), позволяет пропускать ненужные столбцы при чтении данных, что подходит для
ситуации, когда необходим небольшой объем строк. Но такой формат чтения и записи
требует больше места в памяти, поскольку вся строка кэша должна находиться в памяти
(чтобы получить столбец из нескольких строк). В то же время он не подходит для
потоковой записи, потому что после сбоя записи текущий файл не сможет быть
восстановлен, а линейно-ориентированные данные могут быть повторно
синхронизированы с последней точки синхронизации в случае ошибки записи, поэтому,
например, Flume использует линейно-ориентированный (line-oriented) формат хранения.
Рисунок 1 (слева). Показана логическая таблица
Рисунок 2 (справа). Row-oriented расположение (Sequence-файл)
Рисунок 3. Column-oriented расположение
Если вы еще не до конца поняли, что такое ориентация на столбцы или на строки,
не переживайте. Вы можете перейти по этой ссылке, чтобы понять разницу между ними.
Вот несколько форматов файлов, которые широко используются в системе Hadoop:
Sequence-файл
Формат хранения меняется в зависимости от того, является ли хранилище сжатым,
использует ли оно сжатие записи или сжатие блока:
Рисунок 4. Внутренняя структура sequence-файла без сжатия и со сжатием записей.
Без сжатия:
Хранение в порядке, соответствующем длине записи, длине Key, степени Value,
значению Key и значению Value. Диапазон – это количество байтов. Сериализация
выполняется с использованием указанной.
Сжатие записи:
Сжимается только значение, а сжатый кодек хранится в заголовке.
Сжатие блока:
Происходит сжатие нескольких записей, чтобы можно было воспользоваться
преимуществами сходства между двумя записями и сэкономить место. Флаги
синхронизации добавляются в начало и в конец блока. Минимальное значение блока
задается атрибутом o.seqfile.compress.blocksizeset.
Рисунок 4. Внутренняя структура sequence-файла со сжатием блоков.
Map-файл
Map-файл – это разновидность sequence-файла. После добавления индекса к
sequence-файлу и его сортировки получается map-файл. Индекс хранится как отдельный
файл, в котором обычно лежат индексы каждой из 128 записей. Индексы могут быть
загружены в память для быстрого поиска, поскольку файлы, в которых хранятся данные,
расположены в порядке, определенном ключом.
Записи map-файла должны быть расположены по порядку. В противном случае мы
получаем IOException.
Производные типы map-файла:
Файлы, перечисленные ниже в системе Hadoop включают RCFile, ORCFile и Parquet.
Column-oriented версия Avro — это Trevni.
RC-файл
Hive’s Record Columnar File – этот тип файла сначала делит данные на группы строк,
а внутри группы строк, данные хранятся в столбцах. Его структура выглядит следующим
образом:
Рисунок 5. Расположение данных RC-файла в HDFS-блоке.
Сравним с чистыми row-oriented и column-oriented:
Рисунок 6. Хранение по строкам в HDFS-блоке.
Рисунок 7. Группировка по столбцам в HDFS-блок.
ORC-файл
ORCFile (Optimized Record Columnar File) – является более эффективным форматом
файла, чем RCFile. Он внутренне делит данные на полосы (stripe) размером 250М каждая.
Каждая полоса имеет индекс, данные и Footer. Индекс хранит минимальное и
максимальное значение каждого столбца, а также положение каждой строки в столбце.
Рисунок 8. Расположение данных в ORC-файле
В Hive для использования ORC-файла используются следующие команды:
Parquet
Универсальный column-oriented формат хранилища, основанный на Google Dremel.
Особенно хорош при обработке данных с высокой степенью вложенности.
Рисунок 9. Внутренняя структура Parquet-файла.
Вложенные структуры Parquet преобразует в хранилище плоских столбцов,
которое представлено Repeat-уровнем и Definition-уровнем (R и D) и использует
метаданные для восстановления записи при чтении данных, чтобы восстановить весь
файл. Дальше вы увидите пример R и D:
Вот и все. Теперь вы знаете о различиях форматов файлов в Hadoop. Если
обнаружите какие-либо ошибки или неточности, пожалуйста, не стесняйтесь обращаться
ко мне. Вы можете связаться со мной в LinkedIn.
Поговорим за Hadoop
Введение
Как человеку с не очень устойчивой психикой, мне достаточно одного взгляда на картинку, подобную этой, для начала панической атаки. Но я решил, что страдать буду только сам. Цель статьи — сделать так, чтобы Hadoop выглядел не таким страшным.
Что будет в этой статье:
Чего не будет в этой статье:
Что такое Hadoop и зачем он нужен
Hadoop не так уж сложен, ядро состоит из файловой системы HDFS и MapReduce фреймворка для обработки данных из этой файловой системы.
Если смотреть на вопрос «зачем нам нужен Hadoop?» с точки зрения использования в крупном энтерпрайзе, то ответов достаточно много, причем варьируются они от «сильно за» до «очень против». Я рекомендую просмотреть статью ThoughtWorks.
Если смотреть на этот же вопрос уже с технической точки зрения — для каких задач нам есть смысл использовать Hadoop — тут тоже не все так просто. В мануалах в первую очередь разбираются два основных примера: word count и анализ логов. Ну хорошо, а если у меня не word count и не анализ логов?
Хорошо бы еще и определить ответ как-нибудь просто. Например, SQL — нужно использовать, если у вас есть очень много структурированных данных и вам очень хочется с данными поговорить. Задать как можно больше вопросов заранее неизвестной природы и формата.
Длинный ответ —просмотреть какое-то количество существующих решений и собрать неявным образом в подкорке условия, для которых нужен Hadoop. Можно ковыряться в блогах, могу еще посоветовать прочитать книгу Mahmoud Parsian «Data Algorithms: Recipes for Scaling up with Hadoop and Spark».
Попробую ответить короче. Hadoop следует использовать, если:
Архитектура HDFS и типичный Hadoop кластер
HDFS подобна другим традиционным файловым системам: файлы хранятся в виде блоков, существует маппинг между блоками и именами файлов, поддерживается древовидная структура, поддерживается модель доступа к файлам основанная на правах и т. п.
Hadoop-кластер состоит из нод трех типов: NameNode, Secondary NameNode, Datanode.
Namenode — мозг системы. Как правило, одна нода на кластер (больше в случае Namenode Federation, но мы этот случай оставляем за бортом). Хранит в себе все метаданные системы — непосредственно маппинг между файлами и блоками. Если нода 1 то она же и является Single Point of Failure. Эта проблема решена во второй версии Hadoop с помощью Namenode Federation.
Secondary NameNode — 1 нода на кластер. Принято говорить, что «Secondary NameNode» — это одно из самых неудачных названий за всю историю программ. Действительно, Secondary NameNode не является репликой NameNode. Состояние файловой системы хранится непосредственно в файле fsimage и в лог файле edits, содержащим последние изменения файловой системы (похоже на лог транзакций в мире РСУБД). Работа Secondary NameNode заключается в периодическом мерже fsimage и edits — Secondary NameNode поддерживает размер edits в разумных пределах. Secondary NameNode необходима для быстрого ручного восстанавления NameNode в случае выхода NameNode из строя.
В реальном кластере NameNode и Secondary NameNode — отдельные сервера, требовательные к памяти и к жесткому диску. А заявленное “commodity hardware” — уже случай DataNode.
DataNode — Таких нод в кластере очень много. Они хранят непосредственно блоки файлов. Нода регулярно отправляет NameNode свой статус (показывает, что еще жива) и ежечасно — репорт, информацию обо всех хранимых на этой ноде блоках. Это необходимо для поддержания нужного уровня репликации.
Посмотрим, как происходит запись данных в HDFS:
Клиент продолжает записывать блоки, если сумеет записать успешно блок хотя бы на одну ноду, т. е. репликация будет работать по хорошо известному принципу «eventual», в дальнейшем NameNode обязуется компенсировать и таки достичь желаемого уровня репликации.
Завершая обзор HDFS и кластера, обратим внимание на еще одну замечательную особенность Hadoop’а — rack awareness. Кластер можно сконфигурировать так, чтобы NameNode имел представление, какие ноды на каких rack’ах находятся, тем самым обеспечив лучшую защиту от сбоев.
MapReduce
Единица работы job — набор map (параллельная обработка данных) и reduce (объединение выводов из map) задач. Map-задачи выполняют mapper’ы, reduce — reducer’ы. Job состоит минимум из одного mapper’а, reducer’ы опциональны. Здесь разобран вопрос разбиения задачи на map’ы и reduce’ы. Если слова «map» и «reduce» вам совсем непонятны, можно посмотреть классическую статью на эту тему.
Модель MapReduce
Посмотрим на архитектуру MapReduce 1. Для начала расширим представление о hadoop-кластере, добавив в кластер два новых элемента — JobTracker и TaskTracker. JobTracker непосредственно запросы от клиентов и управляет map/reduce тасками на TaskTracker’ах. JobTracker и NameNode разносится на разные машины, тогда как DataNode и TaskTracker находятся на одной машине.
Взаимодействие клиента и кластера выглядит следующим образом:
1. Клиент отправляет job на JobTracker. Job представляет из себя jar-файл.
2. JobTracker ищет TaskTracker’ы с учетом локальности данных, т.е. предпочитая те, которые уже хранят данные из HDFS. JobTracker назначает map и reduce задачи TaskTracker’ам
3. TaskTracker’ы отправляют отчет о выполнении работы JobTracker’у.
Неудачное выполнение задачи — ожидаемое поведение, провалившиеся таски автоматически перезапускаются на других машинах.
В Map/Reduce 2 (Apache YARN) больше не используется терминология «JobTracker/TaskTracker». JobTracker разделен на ResourceManager — управление ресурсами и Application Master — управление приложениями (одним из которых и является непосредственно MapReduce). MapReduce v2 использует новое API
Настройка окружения
На рынке существуют несколько разных дистрибутивов Hadoop: Cloudera, HortonWorks, MapR — в порядке популярности. Однако мы заострять внимание на выборе конкретного дистрибутива не будем. Подробный анализ дистрибутивов можно найти здесь.
Есть два способа безболезненно и с минимальными трудозатратами попробовать Hadoop:
1. Amazon Cluster — полноценный кластер, но этот вариант будет стоить денег.
2. Скачать виртуальную машину (мануал №1 или мануал №2). В этом случае минусом будет, что все сервера кластера крутятся на одной машине.
Перейдем к способам болезненным. Hadoop первой версии в Windows потребует установки Cygwin. Плюсом здесь будет отличная интеграция со средами разработки (IntellijIDEA и Eclipse). Подробнее в этом замечательном мануале.
Начиная со второй версии, Hadoop поддерживает и серверные редакции Windows. Однако я бы не советовал пытаться использовать Hadoop и Windows не только в production’e, но и вообще где-то за пределами компьютера разработчика, хотя для этого и существуют специальные дистрибутивы. Windows 7 и 8 в настоящий момент вендоры не поддерживают, однако люди, которые любят вызов, могут попробовать это сделать руками.
Отмечу еще, что для фанатов Spring существует фреймворк Spring for Apache Hadoop.
Мы пойдем путем простым и установим Hadoop на виртуальную машину. Для начала скачаем дистрибутив CDH-5.1 для виртуальной машины (VMWare или VirtualBox). Размер дистрибутива порядка 3,5 гб. Cкачали, распаковали, загрузили в VM и на этом все. У нас все есть. Самое время написать всеми любимый WordCount!
Конкретный пример
Нам понадобится сэмпл данных. Я предлагаю скачать любой словарь для bruteforce’а паролей. Мой файл будет называться john.txt.
Теперь открываем Eclipse, и у нас уже есть пресозданный проект training. Проект уже содержитя все необходимые библиотеки для разработки. Давайте выкинем весь заботливо положенный ребятами из Clouder код и скопипастим следующее:
Получим примерно такой результат:
Нажимаем Apply, а затем Run. Работа успешно выполнится:
А где же результаты? Для этого обновляем проект в Eclipse (кнопкой F5):
В папке output можно увидеть два файла: _SUCCESS, который говорит, что работа была выполнена успешно, и part-00000 непосредственно с результатами.
Этот код, разумеется, можно дебажить и т. п. Завершим же разговор обзором unit-тестов. Собственно, пока для написания unit-тестов в Hadoop есть только фреймворк MRUnit (https://mrunit.apache.org/), за Hadoop он опаздывает: сейчас поддерживаются версии вплоть до 2.3.0, хотя последняя стабильная версия Hadoop — 2.5.0
Блиц-обзор экосистемы: Hive, Pig, Oozie, Sqoop, Flume
В двух словах и обо всем.
Hive & Pig. В большинстве случаев писать Map/Reduce job’ы на чистой Java — слишком трудоемкое и неподъемное занятие, имеющее смысл, как правило, лишь чтобы вытащить всю возможную производительность. Hive и Pig — два инструмента на этот случай. Hive любят в Facebook, Pig любят Yahoo. У Hive — SQL-подобный синтаксис (сходства и отличия с SQL-92). В лагерь Big Data перешло много людей с опытом в бизнес-анализе, а также DBA — для них Hive часто инструмент выбора. Pig фокусируется на ETL.
Oozie — workflow-движок для jobs. Позволяет компоновать jobs на разных платформах: Java, Hive, Pig и т. д.
Наконец, фреймворки, обеспечивающие непосредственно ввод данных в систему. Совсем коротко. Sqoop — интеграция со структурированными данными (РСУБД), Flume — с неструктурированными.
Обзор литературы и видеокурсов
Литературы по Hadoop пока не так уж много. Что касается второй версии, мне попадалась только одна книга, которая концентрировалась бы именно на ней — Hadoop 2 Essentials: An End-to-End Approach. К сожалению, книгу никак не получить в электронном формате, и ознакомиться с ней не получилось.
Я не рассматриваю литературу по отдельным компонентам экосистемы — Hive, Pig, Sqoop — потому что она несколько устарела, а главное, такие книги вряд ли кто-то будет читать от корки до корки, скорее, они будут использоваться как reference guide. Да и то всегда можно обойдись документацией.
Hadoop: The Definitive Guide — книга в топе Амазона и имеет много позитивных отзывов. Материал устаревший: 2012 года и описывает Hadoop 1. В плюс идет много положительных ревью и достаточно широкое покрытие всей экосистемы.
Lublinskiy B. Professional Hadoop Solution — книга, из которой взято много материала для этой статьи. Несколько сложновата, однако очень много реальных практических примеров —внимания уделено конкретным нюансам построения решений. Куда приятнее, чем просто читать описание фич продукта.
Sammer E. Hadoop Operations — около половины книги отведено описанию конфигурации Hadoop. Учитывая, что книга 2012 г., устареет очень скоро. Предназначена она в первую очередь, конечно же, для devOps. Но я придерживаюсь мнения, что невозможно понять и прочувствовать систему, если ее только разрабатывать и не эксплуатировать. Мне книга показалось полезной за счет того, что разобраны стандартные проблемы бэкапа, мониторинга и бенчмаркинга кластера.
Parsian M. «Data Algorithms: Recipes for Scaling up with Hadoop and Spark» — основной упор идет на дизайн Map-Reduce-приложений. Сильный уклон в научную сторону. Полезно для всестороннего и глубокого понимания и применения MapReduce.
Owens J. Hadoop Real World Solutions Cookbook — как и многие другие книги издательства Packt со словом “Cookbook” в заголовке, представляет собой техническую документацию, которую нарезали на вопросы и ответы. Это тоже не так просто. Попробуйте сами. Стоит прочитать для широкого обзора, ну, и использовать как справочник.
Стоит обратить внимание и на два видеокурса от O’Reilly.
Learning Hadoop — 8 часов. Показался слишком поверхностным. Но для меня некую ценность представили доп. материалы, потому что хочется поиграть с Hadoop, но нужны какие-то живые данные. И вот он — замечательный источник данных.
Building Hadoop Clusters — 2,5 часа. Как понятно из заголовка, здесь упор на построение кластеров на Амазоне. Мне курс очень понравился — коротко и ясно.
Надеюсь, что мой скромный вклад поможет тем, кто только начинает освоение Hadoop.
Русские Блоги
Большие данные: формат хранения файлов Hive-ORC
1. Структура файла ORC
Хранение колонки
Из-за особенностей запроса OLAP, столбчатое хранилище может улучшить производительность запроса, но как это сделать? Это начинается с принципа столбцового хранения.Как видно из рисунка 1, относительно хранения строк, обычно используемого в реляционных базах данных, все элементы каждого столбца сохраняются последовательно при использовании столбцового хранения. Эта функция может привести к следующей оптимизации запроса:
Следует отметить, что ORC необходимо использовать дополнительные ресурсы ЦП для сжатия и распаковки при чтении и записи. Конечно, эта часть потребления ЦП очень мала.
Модель данных
В отличие от Parquet, ORC изначально не поддерживает вложенные форматы данных, но реализует поддержку вложенных форматов посредством специальной обработки сложных типов данных, таких как следующие таблицы кустов:
Файловая структура
Как и в Parquet, ORC-файлы также хранятся в двоичном режиме, поэтому они не могут быть непосредственно прочитаны, ORC-файлы также самоанализируются, они содержат много метаданных, эти метаданные сериализуются изоморфным ProtoBuffer. Файловая структура ORC показана на следующем рисунке, который включает следующие понятия:
В файле ORC хранятся три уровня статистической информации: уровень файла, уровень чередования и уровень группы строк, и все они могут использоваться для определения возможности пропуска определенных данных на основе поисковых ARGuments (условия предиката при нажатии). Статистическая информация включает в себя количество членов и наличие нулевого значения, а некоторая конкретная статистическая информация устанавливается для различных типов данных.
（1）file level
В конце файла ORC будет записана статистика на уровне файлов и статистика столбцов во всем файле. Эта информация в основном используется для оптимизации запросов, а также может выводить результаты для некоторых простых агрегатных запросов, таких как max, min и sum.
（2）stripe level
Файлы ORC будут хранить статистику уровня полосы для каждого поля. Считыватель ORC использует эту статистику, чтобы определить, какие записи полосы необходимо прочитать для запроса. Например, если полоса имеет поля max (a) = 10 и min (a) = 3, то когда условие where равно> 10 или = 1000)
whether to create row indexes
Три, операция Java ORC
Перейдите на официальный сайт https://orc.apache.org, чтобы загрузить исходный пакет orc, затем скомпилируйте и получите orc-core-1.3.0.jar, orc-mapreduce-1.3.0.jar, orc-tools-1.3.0.jar Добавьте его в проект
В большинстве случаев все еще рекомендуется преобразовывать текстовые файлы в формат ORC в Hive. Этот тип генерации файлов ORC локально с помощью JAVA относится к сценариям особых потребностей.
Мертв ли Hadoop? Часть 1
Перевод статьи подготовлен специально для студентов курса «Data Engineer».
После того, как и Cloudera, и MapR несколько недель назад объявили о том, что их бизнес переживает трудные времена, я увидел поток постов в социальных сетях с темой «Hadoop мертв». Эти посты не являются чем-то новым, но в секторе, где технические специалисты редко производят качественный материал для социальных сетей, эти возгласы становятся все громче и громче. Я бы хотел рассмотреть некоторые из аргументов, касающихся состояния Hadoop.
Конкуренция с бесплатным
У Cloudera есть предложения, которые помогают Hadoop в большей степени быть готовым решением. Эти инструменты появились до того, как devops стал массовым, а автоматизированное развертывание встречалось редко.
Их инструменты предоставляют выгодные предложения для более чем 2600 клиентов, но большая часть предлагаемого ими программного обеспечения имеет открытый исходный код и предоставляется бесплатно. Cloudera в конечном итоге конкурирует с бесплатным программным обеспечением. В довершение всего, многие разработчики экосистемы Hadoop в то или иное время работали в Cloudera, т.е. в итоге они так или иначе субсидировали бесплатные предложения, с которыми они конкурируют.
Поскольку они конкурируют с бесплатным, Cloudera никогда не будет обслуживать 100% базы пользователей Hadoop. Я бы не решился использовать их в качестве показателя здоровья Hadoop именно по этой причине.
Конкуренция с 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 приводит к тому, что отдел продаж узнает, насколько надежным является их внутреннее тестирование программного обеспечения.
На этом мы завершаем первую часть перевода. Продолжение можно прочитать тут. А сейчас ждем ваши комментарии и приглашаем всех на бесплатный вебинар по теме: «Принципы построения систем потоковой аналитики».