HDFS Federation

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

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

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

1. Ограничение по объёму памяти. Размер метаданных рос пропорционально количеству файлов и блоков. Для крупных кластеров с миллиардами файлов память одного NameNode становилась узким местом.
2. Отсутствие изоляции. Разные приложения или пользователи работали в общем пространстве имён, что затрудняло управление квотами и безопасностью.

HDFS Federation была представлена в Apache Hadoop 2.0 (2009–2012 годы) как одно из ключевых нововведений, наряду с HDFS High Availability. Целью было снятие ограничения на масштабируемость метаданных без изменения интерфейса взаимодействия с клиентами.

Архитектура и принципы работы

Компоненты

В HDFS Federation выделяются следующие роли узлов:

• NameNode — сервер, управляющий метаданными в рамках одного пространства имён (namespace). Каждый NameNode независимо обрабатывает запросы клиентов на операции с файлами и каталогами.
• DataNode — сервер, хранящий блоки данных. Все DataNode являются общими для всех NameNode. Они регистрируются у каждого NameNode и отправляют отчёты о состоянии блоков (block reports) всем активным NameNode.
• Block Pool — совокупность блоков, принадлежащих одному пространству имён. Каждый NameNode управляет своим набором блоков, идентифицируемых уникальным идентификатором Block Pool ID.
• Namespace Volume — логическое объединение пространства имён и соответствующего пула блоков. Клиент обращается к тому или иному Namespace Volume через специальный путь или идентификатор.

Механизм работы

Каждый NameNode хранит метаданные в своей оперативной памяти и на диске (fsimage и edits). DataNode хранят блоки на дисках, но при этом каждый блок помечен идентификатором Block Pool ID, что позволяет различать блоки разных пространств имён. DataNode отправляет периодические отчёты всем NameNode, указывая, какие блоки из каких Block Pool у него хранятся.

Клиент (например, MapReduce-задача или Spark-приложение) при обращении к файловой системе указывает путь, начинающийся с префикса, соответствующего определённому NameNode. Например, hdfs://namenode1.example.com:8020/user/data и hdfs://namenode2.example.com:8020/user/logs могут указывать на разные пространства имён, хотя физически блоки могут храниться на одних и тех же DataNode.

Отличия от HDFS High Availability

HDFS Federation не следует путать с HDFS High Availability (HA). HA решает проблему отказоустойчивости одного NameNode за счёт активного и резервного узлов, синхронизирующих метаданные. Federation же решает проблему масштабирования, добавляя несколько активных NameNode, каждый из которых управляет своей частью метаданных. Federation и HA могут использоваться совместно: каждое пространство имён может иметь собственную пару активный/резервный NameNode.

Классификация и варианты реализации

Полная Federation

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

Federation с общим хранилищем

В некоторых реализациях (например, в дистрибутивах Cloudera или Hortonworks) допускается, что несколько NameNode могут использовать общее пространство имён (например, через монтирование одного раздела HDFS в другое). Однако это не является стандартной архитектурой Apache Hadoop и требует дополнительных инструментов (например, ViewFs — View File System).

ViewFs (View File System)

Для упрощения работы с несколькими пространствами имён в HDFS Federation используется клиентский уровень абстракции — ViewFs. Он позволяет создать единое виртуальное дерево каталогов, где разные части этого дерева отображаются на разные NameNode. Например, /user может быть смонтирован на NameNode1, а /logs — на NameNode2. Клиент видит единую файловую систему, но физически запросы направляются к разным NameNode. ViewFs не требует изменений на стороне серверов.

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

• Масштабируемость метаданных. Добавление новых NameNode позволяет увеличить общий объём метаданных, который может хранить кластер. Теоретически количество NameNode ограничено только ресурсами сети и управления.
• Изоляция рабочих нагрузок. Разные приложения или отделы могут работать в своих пространствах имён, не влияя на производительность друг друга. Например, потоковая обработка и пакетный анализ могут использовать разные NameNode.
• Упрощение управления квотами. Квоты на количество файлов и объём данных можно задавать для каждого пространства имён отдельно.
• Снижение влияния сбоев. Если один NameNode выходит из строя, остальные пространства имён продолжают работу. Однако блоки, принадлежащие неработающему NameNode, становятся недоступными до его восстановления.

Недостатки и ограничения

• Сложность администрирования. Необходимо настраивать и мониторить несколько NameNode, а также управлять конфигурациями клиентов (ViewFs или явные пути).
• Отсутствие глобального пространства имён. По умолчанию клиент не может перемещать файлы между разными NameNode — операция rename не поддерживается между пространствами имён. Копирование возможно только через чтение и запись.
• Неравномерное распределение нагрузки. Если один NameNode получает больше запросов, чем другие, он может стать узким местом. Балансировка нагрузки требует ручного управления.
• Увеличение сетевого трафика. DataNode отправляют отчёты о блоках всем NameNode, что при большом количестве NameNode может создавать дополнительную нагрузку на сеть.

Применение

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

• Мультитенантные среды. Облачные платформы (например, Amazon EMR, Microsoft HDInsight) используют Federation для изоляции данных разных клиентов.
• Разделение потоковых и пакетных нагрузок. В кластерах, где одновременно работают Spark Streaming и MapReduce, Federation позволяет выделить отдельные NameNode под разные типы задач.
• Архивные и операционные данные. Разделение «горячих» и «холодных» данных в разные пространства имён упрощает управление политиками хранения и репликации.

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

В современных версиях Apache Hadoop (3.x) наряду с Federation продолжает развиваться HDFS Router-Based Federation (RBF). RBF вводит слой маршрутизации (Router), который принимает запросы от клиентов и перенаправляет их к нужному NameNode на основе правил монтирования. Это упрощает конфигурацию клиентов и добавляет возможность динамической балансировки нагрузки между NameNode.

Также существуют альтернативные распределённые файловые системы, не имеющие ограничения одного NameNode: например, CephFS (использует кластерные метаданные), GlusterFS (децентрализованное управление) и Lustre (с распределёнными серверами метаданных). Однако HDFS Federation остаётся популярным решением в экосистеме Hadoop из-за обратной совместимости и интеграции с существующими инструментами.

Источники

• Apache Hadoop Documentation: HDFS Federation (HDFS-1052, HDFS-3637)
• Tom White, «Hadoop: The Definitive Guide», 4th Edition, O'Reilly Media, 2015
• HDFS Architecture Guide (Apache Software Foundation)
• Apache Hadoop 3.x: HDFS Router-Based Federation (HDFS-10476)