NameNode

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

История

Происхождение

Разработка Hadoop началась в 2005 году в компании Yahoo! под руководством Дага Каттинга (Doug Cutting) и Майка Каффарелла (Mike Cafarella). Проект был вдохновлён двумя публикациями Google: статьёй о Google File System (GFS) (2003) и статьёй о MapReduce (2004). NameNode, как аналог GFS Master в архитектуре Google, был реализован в рамках HDFS — распределённой файловой системы, предназначенной для хранения больших объёмов данных на кластерах из недорогих серверов.

Развитие

Первая версия Hadoop (0.1.0) вышла в апреле 2006 года. В ней NameNode уже выполнял функции управления метаданными, но обладал серьёзным недостатком — единой точкой отказа (SPOF). При выходе из строя NameNode весь кластер становился недоступным, а восстановление требовало ручного вмешательства. В версии Hadoop 2.0 (2012) была представлена High Availability (HA) для NameNode, позволяющая иметь активную и резервную копии. В Hadoop 3.0 (2017) появилась поддержка Erasure Coding (стирающего кодирования), что снизило нагрузку на NameNode за счёт уменьшения количества блоков.

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

Компоненты

NameNode работает в связке с несколькими типами узлов:

• DataNode — рабочие узлы, которые хранят блоки данных (обычно по 128 МБ или 256 МБ) и периодически отправляют NameNode отчёты о своём состоянии (heartbeat) и списке хранимых блоков (block report).
• Secondary NameNode (в Hadoop 1.x) — вспомогательный узел, который периодически объединяет журнал изменений (EditLog) с образом файловой системы (FsImage) для предотвращения переполнения журнала. В Hadoop 2.x и 3.x его функции выполняет Standby NameNode в режиме HA.
• Client — приложение, которое взаимодействует с NameNode для получения информации о расположении блоков и с DataNode для чтения/записи данных.

Хранение метаданных

NameNode хранит метаданные в оперативной памяти (RAM) для быстрого доступа. На диске они сохраняются в двух файлах:

• FsImage — снимок состояния файловой системы на момент последней контрольной точки (checkpoint). Содержит дерево каталогов, имена файлов, атрибуты, права доступа и отображение файлов на блоки.
• EditLog — журнал всех изменений, произошедших после последнего снимка (создание, удаление, переименование файлов, изменение прав и т.д.). При запуске NameNode восстанавливает состояние файловой системы, загружая FsImage и применяя записи из EditLog.

Процесс чтения и записи

1. Чтение: Клиент обращается к NameNode с запросом на чтение файла. NameNode возвращает список блоков и адреса DataNode, на которых эти блоки хранятся. Клиент напрямую соединяется с ближайшим DataNode (с учётом топологии сети) и считывает блоки.
2. Запись: Клиент запрашивает у NameNode разрешение на создание файла. NameNode проверяет права доступа и добавляет запись в метаданные. Затем клиент разбивает файл на блоки и отправляет их на DataNode. NameNode не участвует в передаче данных, но получает от DataNode подтверждение о завершении записи.

Классификация

По режиму работы

• Активный NameNode (Active) — основной узел, обрабатывающий все запросы клиентов и DataNode.
• Резервный NameNode (Standby) — в режиме HA синхронизирует с активным узлом состояние метаданных через JournalNode (специальный кластер для хранения EditLog). При отказе активного узла резервный автоматически переключается в активный режим.

По версиям Hadoop

• NameNode в Hadoop 1.x — единственный узел, единая точка отказа. Восстановление возможно только из резервной копии FsImage и EditLog.
• NameNode в Hadoop 2.x — поддержка HA через два узла (Active и Standby) и JournalNode (минимум 3 узла для обеспечения кворума).
• NameNode в Hadoop 3.x — дополнительно поддерживает Erasure Coding (уменьшает коэффициент репликации с 3 до 1.4, снижая нагрузку на NameNode) и Multiple NameNodes (федерация, позволяющая разделить пространство имён на несколько независимых подсистем).

Характеристики

Ограничения

• Объём памяти: NameNode хранит метаданные в RAM. Каждый файл, блок и каталог занимают определённое количество байт (обычно около 150–200 байт на объект). Для кластера с 1 миллиардом файлов требуется около 200 ГБ оперативной памяти.
• Скорость обработки: NameNode может обрабатывать до 10–20 тысяч запросов в секунду на один узел (зависит от аппаратного обеспечения и версии Hadoop).
• Единая точка отказа (без HA): при выходе из строя NameNode кластер становится недоступным до восстановления.

Масштабируемость

Для преодоления ограничений NameNode в больших кластерах применяется федерация HDFS (HDFS Federation), введённая в Hadoop 2.x. При федерации создаётся несколько независимых NameNode, каждый из которых управляет своим пространством имён (namespace) и набором блоков. DataNode при этом являются общими для всех NameNode.

Применение

Использование в экосистеме Hadoop

NameNode является неотъемлемой частью HDFS, которая, в свою очередь, используется в качестве основного хранилища для:

• MapReduce — классическая модель обработки данных, где NameNode управляет расположением входных и выходных данных.
• Apache Hive — система управления данными на основе SQL, которая выполняет запросы к данным, хранящимся в HDFS.
• Apache Spark — фреймворк для обработки больших данных, который может читать и писать данные в HDFS через NameNode.
• Apache HBase — распределённая база данных, которая хранит свои файлы (HFile) в HDFS.

Примеры реальных кластеров

• Yahoo! — один из крупнейших пользователей Hadoop. В 2012 году кластер Yahoo! содержал более 42 000 узлов и 600 петабайт данных, управляемых несколькими NameNode в режиме федерации.
• **Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ)** (организация Meta признана экстремистской и запрещена в РФ) — использует HDFS для хранения логов, фотографий и других данных. В 2014 году кластер Facebook насчитывал более 100 000 узлов.
• Alibaba — применяет модифицированную версию HDFS (Aliyun HDFS) для облачных сервисов.

Критика

Узкие места

• Единая точка отказа (до внедрения HA): даже кратковременный сбой NameNode приводил к остановке всего кластера. Восстановление могло занимать часы, особенно при большом объёме EditLog.
• Ограничение по памяти: NameNode не может хранить метаданные для кластеров с миллиардами файлов без значительного увеличения RAM. Это ограничивает применение HDFS в сценариях с очень большим количеством мелких файлов (например, в системах реального времени).
• Задержки при старте: при запуске NameNode загружает FsImage и применяет EditLog. Для кластера с миллионами файлов этот процесс может занимать десятки минут.

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

Для преодоления ограничений NameNode были разработаны альтернативные распределённые файловые системы:

• Ceph — использует распределённые метаданные без центрального узла.
• GlusterFS — не имеет единого сервера метаданных, управление осуществляется через алгоритмы хеширования.
• Apache Cassandra — NoSQL-база данных, которая не требует отдельного узла для управления метаданными.

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

• Название «NameNode» происходит от его функции — хранения имён (names) файлов и каталогов.
• В ранних версиях Hadoop (до 0.20) NameNode назывался «Namenode» (с маленькой буквы), но впоследствии стандартизировали написание «NameNode».
• В 2014 году команда Hadoop из Yahoo! выпустила HDFS Router-Based Federation, которая позволяет динамически перенаправлять запросы между несколькими NameNode, улучшая балансировку нагрузки.
• В Hadoop 3.0 была добавлена поддержка Erasure Coding, которая снижает нагрузку на NameNode примерно на 30% за счёт уменьшения количества блоков (при репликации 3 каждый блок хранится в трёх копиях, при Erasure Coding — только в 1.4).

Источники

• Apache Hadoop Documentation. «HDFS Architecture Guide». Apache Software Foundation.
• Tom White. «Hadoop: The Definitive Guide». 4th Edition. O'Reilly Media, 2015.
• Konstantin Shvachko et al. «The Hadoop Distributed File System». Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST).
• Dhruba Borthakur. «The Hadoop Distributed File System: Architecture and Design». Apache Software Foundation, 2007.
• Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. «The Google File System». ACM SIGOPS Operating Systems Review, 2003.