Hadoop Federation

Hadoop Federation — это архитектурное расширение экосистемы Apache Hadoop, которое позволяет объединять несколько независимых кластеров NameNode (узлов имен) в единую логическую систему управления метаданными, обеспечивая горизонтальное масштабирование, изоляцию нагрузки и устранение единой точки отказа (SPOF) в распределённой файловой системе HDFS (Hadoop Distributed File System). В отличие от классической архитектуры HDFS, где один NameNode управляет всеми метаданными файловой системы, Federation распределяет эту функцию между несколькими узлами, каждый из которых отвечает за свой набор блоков данных (Volume).

История и предпосылки создания

Классическая архитектура HDFS, разработанная в рамках проекта Apache Hadoop в 2006 году, предполагала наличие единственного NameNode, который хранил в оперативной памяти всё дерево каталогов, информацию о файлах и расположение блоков данных. По мере роста объёмов данных и числа клиентов этот подход столкнулся с рядом ограничений:

• Ограничение по памяти: NameNode должен был удерживать в памяти метаданные о всех файлах и блоках. Для кластеров с миллиардами файлов требовались сотни гигабайт оперативной памяти, что делало масштабирование дорогостоящим.
• Единая точка отказа (SPOF): При выходе из строя единственного NameNode вся файловая система становилась недоступной до восстановления резервной копии (Secondary NameNode или Standby NameNode).
• Ограничение пропускной способности: Все операции чтения и записи метаданных (например, создание файлов, получение информации о блоках) проходили через один NameNode, что создавало узкое место.
• Отсутствие изоляции: Разные приложения или пользователи, работающие в одном кластере, могли конкурировать за ресурсы NameNode, что приводило к взаимным блокировкам.

Для решения этих проблем в 2010 году в рамках версии Hadoop 2.0 была предложена архитектура Federation. Она была официально представлена в Hadoop 2.2.0 (2013 год) и стала стандартной опцией для крупных развёртываний HDFS.

Архитектура Hadoop Federation

Основные компоненты

В архитектуре Federation кластер HDFS делится на несколько независимых Namespace Volume (пространств имён), каждое из которых обслуживается отдельным NameNode. Каждый NameNode управляет:

• Namespace — деревом каталогов и метаданными файлов.
• Block Pool — набором блоков данных, принадлежащих файлам в этом пространстве имён.

Физические узлы хранения данных — DataNode (узлы данных) — являются общими для всех пространств имён. Каждый DataNode регистрируется у всех NameNode и хранит блоки данных, принадлежащие разным Block Pool. Для идентификации блоков используется уникальный идентификатор Block Pool ID (BPID), который добавляется к имени файла блока на диске.

Взаимодействие компонентов

1. Клиент (HDFS Client) получает от администратора или конфигурации список доступных NameNode. Для выполнения операции (например, чтения файла) клиент сначала обращается к соответствующему NameNode, который отвечает за метаданные этого файла.
2. NameNode обрабатывает запрос, возвращает расположение блоков данных (список DataNode, где хранятся реплики) и обновляет метаданные.
3. DataNode выполняют фактические операции чтения/записи данных. Они периодически отправляют отчёты (heartbeat) всем NameNode, сообщая о состоянии своих блоков.

Ключевые отличия от классической HDFS

Преимущества и недостатки

Преимущества

• Горизонтальное масштабирование: Увеличение объёма данных или числа файлов не требует замены оборудования, достаточно добавить новый NameNode.
• Изоляция и производительность: Разные приложения (например, потоковая обработка и пакетная аналитика) могут работать в своих пространствах имён, не влияя друг на друга.
• Управляемость: Администратор может назначать квоты, политики репликации и приоритеты для каждого пространства имён отдельно.
• Снижение риска SPOF: При отказе одного NameNode остальные пространства имён продолжают работу.

Недостатки

• Сложность администрирования: Необходимо настраивать и поддерживать несколько NameNode, а также управлять их конфигурациями.
• Отсутствие глобальной консистентности: Перемещение файлов между пространствами имён (например, с помощью distcp) требует ручного копирования, так как Federation не поддерживает глобальные транзакции.
• Повышенное потребление ресурсов: Каждый NameNode требует собственной оперативной памяти и процессорного времени. DataNode тратят больше ресурсов на отправку отчётов нескольким NameNode.
• Не решает проблему высокой доступности (HA): Для каждого NameNode всё равно требуется резервный экземпляр (Standby NameNode), что увеличивает сложность.

Применение

Hadoop Federation применяется в крупных корпоративных и исследовательских кластерах, где объём данных превышает десятки петабайт, а число файлов — миллиарды. Типичные сценарии:

• Разделение по отделам: Каждый отдел (финансы, маркетинг, разработка) получает своё пространство имён с собственными квотами и политиками.
• Разделение по типам данных: Например, одно пространство для оперативных данных, другое — для архивных, третье — для временных результатов.
• Мультитенантность: Облачные провайдеры и платформы данных (например, Amazon EMR, Google Cloud Dataproc) используют Federation для изоляции клиентов.

Альтернативы и развитие

С развитием экосистемы Hadoop появились альтернативные решения, частично или полностью заменяющие Federation:

• HDFS High Availability (HA): Решает проблему SPOF, но не масштабирует NameNode. Использует два узла — активный и резервный (Standby) — с синхронизацией через JournalNode.
• Apache Ozone: Объектное хранилище, разработанное для Hadoop, которое изначально поддерживает распределённое управление метаданными и масштабирование до миллиардов объектов.
• Apache HBase и Apache Cassandra: NoSQL-базы данных, которые могут хранить метаданные вне HDFS, снижая нагрузку на NameNode.

Начиная с Hadoop 3.x, Federation остаётся поддерживаемой, но для новых проектов рекомендуется использовать Ozone или комбинацию HDFS HA с оптимизацией метаданных (например, использование HDFS Router-based Federation).

Интересные факты

• Первая реализация Federation в Hadoop 2.0 была выполнена инженерами компаний Yahoo! и Hortonworks (ныне часть Cloudera).
• В крупнейших кластерах (например, у Facebook/Meta — организация признана экстремистской и запрещена в РФ) количество NameNode в Federation достигало нескольких десятков.
• Federation не поддерживает глобальное переименование файлов между пространствами имён — это одна из причин, по которой многие компании перешли на Ozone.

Источники

• Apache Hadoop Documentation: «HDFS Federation» (официальная документация, версия 2.x и 3.x).
• White, T. (2015). Hadoop: The Definitive Guide. 4th Edition. O'Reilly Media.
• Shvachko, K. et al. (2010). «The Hadoop Distributed File System». Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST).
• Apache Hadoop JIRA: HDFS-1052 (Federation design document).
• Cloudera Engineering Blog: «HDFS Federation: A Practical Guide» (2013).