Новый релиз Apache Hadoop 3.3.1: ТОП-15 обновлений

Автор Категория ,
Новый релиз Apache Hadoop 3.3.1: ТОП-15 обновлений

Постоянно обновляя наши курсы по Apache Hadoop для администраторов кластеров и инженеров данных, сегодня рассмотрим главные новинки июньского релиза 2021. Читайте далее, как поддержка Erasure Coding сэкономит место в HDFS, зачем обновляться до 8-ой версии Java, чем хорош YARN Timeline Service v.2, как повысить надежность кластера Hadoop еще больше и почему устарела переменная HADOOP_HEAPSIZE.

Что нового в Apache Hadoop 3.3.1: 7 главных изменений

Apache Hadoop 3.3.1 включает ряд значительных улучшений по сравнению с предыдущей версией 2. Примечательно, что этот релиз назван общедоступен (GA, Generally Available), т.е. считается стабильным и готовым для применения в production. Все JAR-файлы Hadoop теперь скомпилированы для 8-ой версии Java, поэтому пользователям прошлых версий обязательно нужно обновить их. Помимо этого, самими значимыми новинками свежего релиза Apache Hadoop 3.3.1 являются следующие [1]:

  • улучшение файловых систем – включение технологии Erasure Coding и федерализация на основе маршрутизатора HDFS, добавлена внутренняя балансировка на узле данных, а также поддержка S3Guard и коннекторов для интеграции с Microsoft Azure Data Lake и системой хранения объектов Aliyun Object Storage System;
  • повышение эффективности YARN – 2-я версия YARN Timeline Service, поддержка Opportunistic-контейнеров и распределенного планирования, а также обобщение модели ресурсов;
  • архитектурные изменения кластера – возможность запускать несколько резервных NameNode для обеспечения высокой доступности и изменение портов по умолчанию для некоторых сервисов;
  • обновление MapReduce – поддержка собственной реализации сборщика выходных данных этапа Map, а также изменения управления кучей для системных служб и задач.

Также внесены изменение в некоторые shell-скрипты, чтобы исправить многие давние ошибки и включить новые функции. При том, что особое внимание было уделено совместимости, некоторые изменения могут нарушить существующие установки. Несовместимые изменения задокументированы в источнике [2]. Наконец, чтобы избежать конфликтов путей к классам Hadoop-приложений в разных версиях, клиентские зависимости сведены в единый JAR-архив. Добавлены новые артефакты hadoop-client-api и hadoop-client-runtime, которые объединяют зависимости Hadoop. Далее рассмотрим подробнее некоторые из этих нововведений.

Улучшения Hadoop HDFS и коннекторы к другим хранилищам

Теперь распределенная файловая система Apache Hadoop поддерживает технологию кодирования со стиранием (Erasure Coding, EC), которая экономит место на жестком диске по сравнению с репликацией. Например, стандартная схема 3-кратной репликации в HDFS имеет 200% накладных расходов на пространство хранения и пропускную способность сети. Erasure Coding снижает накладные расходы на хранение данных до 50% независимо от коэффициента репликации. Это достигается благодаря чередованию, которое разделяет логически последовательные данные (файл) на более мелкие блоки (бит, байт или блок), сохраняя их на разных дисках. Для каждой полосы исходных ячеек данных вычисляется и сохраняется определенное количество ячеек четности, что называется кодированием. Ошибка в любой чередующейся ячейке устраняется путем декодирования на основе сохранившихся данных и ячеек четности. Например, файл с 3-кратной репликацией с 6 блоками HDFS будет занимать 6 * 3 = 18 блоков дискового пространства. А с поддержкой EC в 3 ячейки четности он будет использовать в 2 раза меньше: 9 блоков дискового пространства [3]. Подробнее о технологии Erasure Coding в Hadoop HDFS читайте в нашей новой статье.

Поскольку один DataNode управляет несколькими дисками, обычно они заполняются равномерно. Но добавление или замена дисков может привести к значительному перекосу на DataNode. Эта ситуация не обрабатывается существующим балансировщиком HDFS, который занимается внутренним, а не внутренним перекосом DN. Поэтому для балансировки внутри узла данных добавлена новая функция, которая вызывается через интерфейс командной строки hdfs diskbalancer.

Еще в Hadoop 3.3.1 включена федерализация на основе маршрутизатора HDFS, которая добавляет уровень маршрутизации RPC для объединенного представления нескольких пространств имен распределенной файловой системы. Это похоже на существующие функции ViewFs и федерации HDFS, но таблица монтирования управляется уровнем маршрутизации на стороне сервера, а не на клиенте. Это упрощает доступ к объединенному кластеру для существующих клиентов HDFS.

Благодаря поддержке коннекторов Hadoop теперь отлично интегрируется с Microsoft Azure Data Lake и системой хранения объектов Aliyun Object Storage System в качестве файловых систем, альтернативных HDFS. Также улучшена технология S3Guard для повышения согласованности и кэширования метаданных клиента файловой системы AWS S3A. Добавлена дополнительная функция клиента S3A: возможность использовать таблицу DynamoDB в качестве быстрого согласованного хранилища метаданных файлов и каталогов.

4 новинки YARN

В новом релизе Apache Hadoop предлагается 2-я версия YARN Timeline Service для улучшения масштабируемости и надежности, а также повышения удобства использования за счет введения потоков и агрегации. В отличии от предыдущей версии, этот выпуск поддерживает распределенную запись и масштабируемое внутреннее хранилище Apache HBase, отделяя сбор (запись) данных от обслуживания (чтения). Здесь используются распределенные сборщики для каждого приложения YARN и отдельные экземпляры для обслуживания запросов на чтение через REST API. Пока эта альфа-версия вместо Timeline Service v.1.x предоставляется для тестовой оценки и не рекомендуется в production [4].

Также добавлена поддержка Opportunistic-контейнеров и распределенного планирования. Теперь приложения могут запрашивать контейнеры с типом выполнения Opportunistic, которые могут быть отправлены для исполнения в менеджер узлов YARN (NodeManager), даже при отсутствии доступных ресурсов на момент планирования. В таком случае эти контейнеры будут поставлены в очередь в NM, ожидая доступных ресурсов для их запуска. Opportunistic-контейнеры имеют более низкий приоритет, чем гарантированные контейнеры по умолчанию, и поэтому при необходимости они вытесняются, чтобы освободить место для гарантированных контейнеров и повысить эффективность утилизации ресурсов Hadoop-кластера. Opportunistic-контейнеры по умолчанию выделяются центральным диспетчером ресурсов YARN (ResourceManager), но могут быть выделены распределенным планировщиком, который реализован как перехватчик протокола AMRMP. Подробнее о компонентах YARN мы писали здесь.

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

Наконец, для очереди Capacity-планировщика добавлена конфигурация на основе API. Расширение OrgQueue для Capacity-планировщика YARN обеспечивает программный способ изменения конфигураций. Теперь пользователи могут вызвать его REST API для изменения конфигураций очереди, а администратор кластера Hadoop может автоматизировать управление конфигурацией очереди в ACL-списках. Подробнее о том, как работает планировщик YARN, читайте в нашей отдельной статье.

Архитектурные изменения кластера Apache Hadoop

Изначальная реализация высокой доступности HDFS обеспечивало резервирование узла имен (NameNode). Через репликацию изменений в кворум из трех узлов журнала эта архитектура позволяла справиться с отказом любого узла в распределенной системе, о чем мы рассказывали в этой статье. Чтобы еще больше повысить устойчивость кластера Hadoop, добавлена новая функция, которая позволяет пользователям запускать несколько резервных NameNode. Например, настроив три NameNodes и пять JournalNodes, кластер может выдерживать отказ двух узлов, а не только одного.

Еще в Hadoop 3.3.1 изменены порты по умолчанию для некоторых сервисов, ранее находившиеся в диапазоне временных портов Linux (32768-61000). Из-за этого при запуске сервисы иногда не могли подключиться к порту, конфликтуя с другими приложениями. Например, номер порта 16000 HMaster HBase конфликтовал с таким же номером порта Hadoop kms, что затрудняло использование kms и HBase в одном кластере. В частности, не смотря на возможность шифрования файлов HBase, но пользователю мог требоваться KMS для шифрования других каталогов HDFS. Приходилось вручную переопределить порт по умолчанию для любого приложения в кластере. Поэтому в новом релизе Hadoop конфликтующие порты были перемещены из временного диапазона, что повлияло на NameNode, Secondary NameNode, DataNode и KMS.

Улучшение MapReduce

В Hadoop MapReduce версии 3.3.1 добавлена ​​поддержка собственной реализации сборщика выходных данных этапа Map. Для заданий с интенсивным перемешиванием это может повысить производительность на 30% и более. Переработан управления кучей системных служб и задач MapReduce. Добавлены новые методы для настройки размеров кучи демонов и возможность автоматической настройки в зависимости от размера памяти хоста. Переменная HADOOP_HEAPSIZE теперь считается устаревшей. Упрощена настройка этапа Map и уменьшены уменьшает размеры кучи задач. Теперь желаемый размер кучи не нужно указывать в 2-х местах: в конфигурации самой задачи и в качестве параметра Java.

Больше практических деталей про администрирование и эксплуатацию Apache Hadoop для хранения и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://hadoop.apache.org/docs/r3.3.1/index.html
  2. https://issues.apache.org/jira/browse/HADOOP-9902
  3. https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
  4. https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2.html