Терминология Hadoop: ноды, блоки, репликация, namespace
Hadoop строится вокруг идеи распределенного хранения и обработки больших данных. В этой главе рассматриваются базовые термины, которые нужно точно понимать, чтобы говорить на языке архитектуры HDFS и сопутствующих компонентов. Мы разберём роли нод, принцип формирования и хранения файлов как блоков, механизмы репликации и концепцию пространства имён (namespace), на котором основана файловая система Hadoop. Понимание этих терминов упрощает дальнейшее восприятие процессов обработки в рамках экосистемы Hadoop и взаимодействия между HDFS и YARN.
Краткое введение
HDFS представляет собой разделяемую файловую систему с ориентиром на масштабируемость и отказоустойчивость. В центре архитектуры лежит разделение ответственности: NameNode управляет пространством имён и метаданными, DataNodes фактически хранят данные в виде блоков. Файлы разбивают на блоки определённого размера; блоки реплицируются на разных DataNodes, чтобы обеспечить доступность при выходе из строя отдельных узлов. Пространство имён (namespace) - это иерархическая структура файлов, управляемая NameNode, которая хранится как в памяти NameNode, так и на диске в виде FSImage и EditLog. Взаимодействие между компонентами реализуется через сетевые протоколы и RPC, а интеграция с YARN обеспечивает обработку данных на кластере. В дальнейшем мы рассмотрим, как эти элементы работают в связке и как они влияют на практические решения по проектированию корпоративных data lake.
- Содержание главы
- Определение ключевых понятий: ноды, блоки, репликация и namespace, их роль в HDFS.
- Архитектура HDFS: NameNode, DataNode, принципы хранения метаданных и данных, HA и федеративные конфигурации.
- Механизмы репликации и отказоустойчивости: как NameNode принимает решения, как DataNodes управляют запасами блоков.
- Протоколы взаимодействия и схемы обмена данными: RPC, протокол передачи блока, HTTP-образ для доступа к данным.
- Namespace, FSImage и EditLog: хранение метаданных, процесс восстановления и роли воркфлоу в федерации namespace.
Ноды и их роли в HDFS
HDFS делит хранение и управление данными на две основные роли нод: NameNode и DataNode. В контексте отказоустойчивости и высокой доступности к ним добавляются концепции Standby NameNode, JournalNode и конфигурации High Availability (HA).
NameNode - центральный регистратор пространства имён
NameNode отвечает за всю файловую систему в рамках конкретного namespace. Он хранит в памяти и на диске сведения о структуре каталогов, файлах и их блоках, а также о размещении каждого блока на DataNode. В отличие от DataNode, NameNode не хранит сами данные файлов - он держит только метаданные: список блоков для каждого файла, порядок чтения и записи, разрешения и ACL. В рамках архитектуры NameNode обеспечивает консистентность: единую «карточку» того, где лежат данные и как они доступны.
DataNode - хранение и обслуживание данных
DataNode физически размещает блоки файлов на локальных носителях. Он отвечает за создание, удаление и репликацию блоков согласно инструкциям NameNode. DataNode регулярно отправляет NameNode блок-отчёты (block reports) и сигналы «heartbeat», чтобы NameNode знал о доступности узлов и состоянии их хранения. В случае выхода DataNode из строя NameNode инициирует перераспределение блоков и создание новых копий на доступных нодах.
Роль вспомогательных нод и HA
Система HA в современных кластерах Hadoop предусматривает Standby NameNode, который может быстро перейти в активное состояние при сбое активного NameNode. Для синхронизации метаданных в HA применяется журнал (JournalNode) или журналируемый механизм (Quorum Journal Manager, QJM), чтобы изменения пространства имён синхронно реплицировались между нодами. В дополнение к этому, федеративная архитектура позволяет иметь несколько namespace с независимыми NameNode-экземплярами, что улучшает масштабируемость и управляемость больших кластеров.
ASCII-диаграмма архитектуры
NameNode отвечает за пространство имён и метаданные
Clients → NameNode (8020) → DataNodes ( блоки размещены на DataNodes )
DataNodes хранят блоки на локальных дисках и отправляют блок-отчёты
блоки читаются напрямую DataNodes через блок-Transfer протокол
Вышеописанная структура обеспечивает четкое разделение ответственности: метаданные не перемещаются вместе с самими данными, что позволяет эффективно масштабировать и восстанавливать данные.
Почему именно так следует проектировать ноды
- Разделение задач позволяет NameNode сосредоточиться на консистентности и доступности пространства имён, не таская за собой тяжелые данные.
- DataNodes оптимизированы под локальное хранение и высокую пропускную способность передачи блоков.
- Отказоустойчивость достигается за счет дублирования блоков и возможности быстрого переключения на standby-узлы в случае сбоя.
- Архитектура поддерживает горизонтальное масштабирование путем добавления DataNodes и, в случае федеративной конфигурации, дополнительных namespaces.
Блоки, хранение и распределение данных
Файлы в HDFS не хранятся целиком на одном узле; они разбиваются на мелкие части - блоки. Размер блока по умолчанию варьируется в зависимости от версии Hadoop и конфигурации, часто 128 МБ или 256 МБ. Каждый файл задаёт последовательность блоков, которые хранятся на разных DataNodes. Блоки - это фактические единицы хранения, которые обеспечивают параллельную обработку и отказоустойчивость.
Ключевые концепты блока
- Блок - это минимальная единица хранения на уровне HDFS. Файл может состоять из одного или нескольких блоков, каждый блок имеет уникальный идентификатор и физически размещается на конкретном DataNode.
- Блок-пул (block pool) - набор блоков, принадлежащий конкретной Namespace и NameNode. В федеративной конфигурации каждый NameNode имеет свой блок-пул.
- Репликация блока - копии блока размещаются на разных DataNodes для обеспечения доступности и отказоустойчивости. Имя репликации хранится в метаданных NameNode и влияет на скорость чтения и устойчивость к отказам.
Хранение и размещение блоков
- Блоки хранятся как файлы на дисках DataNode, помеченные идентификатором блока и локальным ID пула, к которому относится DataNode.
- Реплики блока размещаются на разных DataNodes, предпочтительно в разных стойках/фермах и сетевых сегментах, чтобы снизить риск потери данных из-за сбоев одного узла или целой зоны доступности.
- При чтении клиент запрашивает у NameNode местоположения соответствующих блоков, затем читает данные напрямую с DataNodes через блок-Transfer протокол.
Пример схемы размещения блоков
- Файл A разбивается на блоки A1, A2, A3.
- A1 лежит на DataNode-1, A2 на DataNode-2, A3 на DataNode-3.
- Репликации: A1 копируется на DataNode-4, A2 копируется на DataNode-5, A3 копируется на DataNode-6.
- В случае сбоя DataNode-2 NameNode инициирует перераспределение блока A2, создавая новую реплику на других доступных DataNodes.
Переход к практическим выводам
- Размер блока влияет на эффективность параллельной обработки и на нагрузку на NameNode при сборе метаданных.
- Чрезмерно маленькие блоки увеличивают нагрузку на метаданные и сетевые запросы; слишком большие блоки могут снизить параллелизм чтения.
- Репликация - важный баланс между пропускной способностью сети, отказоустойчивостью и затратами на хранение.
Репликация, отказоустойчивость и консистентность
Репликация - ключевой механизм отказоустойчивости в HDFS. По умолчанию файл реплицируется три раза, но это значение может быть изменено на уровне политики хранения. Репликация обеспечивает доступность данных даже при выходе из строя отдельных DataNodes или целых узлов.
Механизм принятия решений NameNode
- NameNode анализирует доступность DataNodes через heartbeat-сообщения и блок-отчёты.
- В случае падения DataNode NameNode инициирует перераспределение реплик: новые копии создаются на доступных DataNodes, чтобы поддерживать заданный уровень репликации.
- При чтении данных клиент запрашивает у NameNode список блоков и их размещение. Клиент затем читает блоки напрямую с DataNodes, минимизируя нагрузку на NameNode.
Безопасность консистентности
- Репликации требуют синхронности записи: файл записывается целиком через цепочку операций, после чего координация фиксирует факт завершения на NameNode.
- При добавлении блоков или изменении файлов NameNode обновляет FSImage и EditLog, чтобы все сотрудники кластера синхронно увидели новую информацию.
Расширенные варианты:
- Erasure Coding (EC) как альтернатива избыточной репликации: в современных версиях Hadoop EC позволяет хранить данные более экономично при больших сроках хранения, уменьшая избыточность хранения по сравнению с тройной репликацией. EC применим к большому объёму данных и может потребовать более сложного кода чтения, но экономит пространство.
- Поведение в федеративной конфигурации: каждый namespace имеет собственную политику репликации и собственные DataNodes. Репликации между namespace не осуществляются напрямую, что повышает управляемость и масштабируемость кластера.
Концептуальные причины использования репликации
- Отказоустойчивость: в случае выхода DataNode данные остаются доступными благодаря размещению копий на других нодах.
- Пропускная способность: чтение может происходить параллельно с нескольких DataNodes, что повышает общую пропускную способность.
- Географическая устойчивость: в больших кластерах копии блоков могут размешаться по разным стойкам или дата-центрам, снижая риск потерь due to региональные сбои.
Архитектурные принципы и протоколы взаимодействия
Эффективная работа HDFS опирается на набор сетевых протоколов и правил взаимодействия между компонентами. В основе лежат RPC-интерфейсы и специализированные протоколы обмена данными, которые обеспечивают как управление, так и передачу блоков.
Основные RPC-интерфейсы и взаимодействие
- ClientProtocol: набор операций, используемых клиентами для работы с файловой системой. Основные действия включают создание файла, открытие, запись, закрытие и изменение атрибутов. Клиент сначала обращается к NameNode за метаданными, затем читает или записывает блоки напрямую у DataNodes.
- DatanodeProtocol: протокол обмена между DataNode и NameNode, включающий уведомления о состоянии, блок-отчёты и прочие сигналы синхронизации. DataNode сообщает NameNode о доступных блоках, состоянии хранилища и отвечает на периодические «heartbeat».
- Блок-Transfer протокол: механизм прямой передачи блоков между DataNode и клиентом. Этот протокол минимизирует задержки и нагрузку на NameNode, обеспечивая параллельный доступ к блокам.
Web- и HTTP-интерфейсы
- Web-UI и WebHDFS: проблемно-ориентированные интерфейсы для мониторинга и доступа к файлам через HTTP-протоколы. Они упрощают интеграцию с внешними сервисами и инструментами управления данными в корпоративной среде.
- HTTPS и безопасность: для корпоративной среды целесообразно обеспечивать шифрование трафика и аутентификацию на уровне каждого сервиса, что повышает общий уровень доверия к архитектуре.
Протоколы в контексте интеграций и сценариев внедрения
- Интеграция с YARN и обработка данных: DataNode выступает как источник хранения, а YARN - как оркестратор обработки. Обмен данными между ними происходит через файловую систему HDFS и протоколы, обеспечивающие эффективное перемещение данных в рамках заданного кластера.
- Федеративные namespace: возможность разделения нагрузки на Namenodes и соответствующих DataNodes, расширение кластера без потери целостности пространства имён или доступности данных.
Схемы взаимодействия и практические выводы
- В типичной схеме клиент запрашивает у NameNode список блоков и их размещение для требуемого файла. Затем клиент читает данные напрямую с DataNodes, реализуя эффективный путь доступа к файлам.
- Для записи клиент сначала создаёт файл через ClientProtocol, NameNode выделяет блоки и размещает их на DataNodes; затем DataNodes принимают записи и отправляют блок-отчёты, отражая изменение в FSImage через EditLog.
Namespace, FSImage и EditLog: управление файловой системой
Namespace представляет собой иерархическую структуру файловой системы Hadoop. В рамках HDFS Namespace управляется NameNode и хранится в памяти NameNode, а также записывается на диске для восстановления после перезапуска. Метаинформация о файлах, каталогах и их связях с блоками хранится в двух взаимодополняющих структурах: FSImage и EditLog.
FSImage
- FSImage содержит снимок амплитуды состояния пространства имен на конкретный момент времени. Это «стато́вая» копия метаданных файловой системы - структура каталогов, атрибуты файлов и размещение блоков.
- При каждом значимом изменении файловой системы (создание файла, удаление, изменение атрибутов) обновляется EditLog, а периодически формируется новый снимок FSImage.
EditLog
- EditLog - это последовательность операций над файловой системой, которые должны быть воспроизведены при старте NameNode (реиграция). Это позволяет NameNode реконструировать текущее состояние пространства имён, восстанавливая все операции, произошедшие после последнего снимка.
- В случае отказа или сбоя NameNode, процесс восстановления начинается с загрузки FSImage и последующего применения изменений из EditLog, чтобы вернуть файловую систему к состоянию на момент сбоя.
Checkpoint и журналирование (HA)
- В некоторых конфигурациях существует процесс «checkpoint» - периодическое создание нового FSImage посредством объединения текущего FSImage и EditLog. Это снижает размер EditLog и ускоряет восстановление.
- В HA-сценариях и федеративной архитектуре применяется журналируемый механизм репликации изменений между NameNode и Standby NameNode (через JournalNode или QJM). Это обеспечивает согласованность состояния пространства имён между активным и резервным NameNode.
Namespace как элемент корпоративной архитектуры
- Namespace отражает бизнес-логическую организацию данных: каждое подразделение может иметь свой namespace в рамках федерации, что позволяет разделять управление и хранение данных по бизнес-юнитам без потери единства всей экосистемы.
- Этикетки и политика хранения файлов, контроль доступа и аудит тесно связаны с конкретной namespace и его метаданными, которые централизованы через NameNode в рамках соответствующего namespace.
Интеграции и практические выводы
- В крупной организации эффективная работа с namespace требует четкого разделения ответственности между администраторами по хранению и по обработке данных.
- В рамках федерации важно выстроить политики бэкапа и восстановления для FSImage и EditLog, а также поддерживать синхронизацию между NameNode’ами через JournalNode или аналогичный механизм.
- Эффективная настройка лицензий и политики доступа (ACL, Kerberos) должна применяться на уровне namespace, чтобы обеспечить безопасность и соответствие требованиям регуляторов.
Key takeaways
- Нода NameNode управляет пространством имён и метаданными, тогда как DataNode хранит сами данные в виде блоков.
- Файл разбивается на блоки, которые реплицируются на разных DataNodes для обеспечения доступности и отказоустойчивости.
- Пространство имён (namespace) представляет собой иерархию файлов и папок; FSImage и EditLog обеспечивают хранение и восстановление метаданных.
- Репликация и блок-отчёты с heartbeat-на DataNodes поддерживают целостность данных и устойчивость к сбоям.
- Протоколы взаимодействия (ClientProtocol, DatanodeProtocol, блок-Transfer) формируют эффективный путь работы клиента, NameNode и DataNodes.
- Федеративная архитектура namespace и HA повышают масштабируемость, устойчивость и управляемость больших Hadoop-кластеров.
FAQ
- Что такое NameNode и зачем он нужен?
NameNode - центральный управляющий узел файловой системы Hadoop. Он хранит всю информацию о структуре пространств имён и размещении каждого блока в кластере. Без NameNode невозможно определить, какие блоки принадлежат файлу и где они находятся. NameNode обеспечивает согласованность и целостность файловой системы. В HA-конфигурациях существует Standby NameNode для быстрого перехода на активный режим при сбое.
- Что такое DataNode и как он взаимодействует с NameNode?
DataNode - узел, на котором физически хранятся блоки файлов. Он регулярно отправляет NameNode блок-отчёты и heartbeat-сигналы, информируя о своем состоянии и наличии блоков. Когда NameNode получает запрос на чтение или запись файла, он предоставляет клиенту информацию о размещении блоков, а клиент (или DataNode при чтении) обращается непосредственно к DataNode за данными.
- Каковы основные единицы хранения в HDFS?
Основной единицей хранения является блок. Файл разбивается на последовательность блоков заданного размера (например, 128 или 256 МБ). Каждый блок копируется на нескольких DataNodes (репликация). Таким образом, целостность и доступность данных обеспечиваются параллельной обработкой и репликацией.
- Что такое namespace и чем он отличается от файловой системы на локальном диске?
Namespace в HDFS - это управляемая NameNode структура, представляющая иерархию директорий и файлов. В отличие от локальной файловой системы, где данные и метаданные хранятся локально на устройстве, в HDFS метаданные представлены в памяти NameNode и на диске в FSImage и EditLog, а сами данные разбросаны по DataNodes. Namespace позволяет масштабировать метаданные и управлять доступом на уровне кластера.
- Какие преимущества даёт репликация блоков?
Репликация обеспечивает отказоустойчивость: при выходе одного DataNode данные остаются доступными благодаря копиям на других нодах. Она также улучшает пропускную способность чтения - клиенты могут читать блоки с разных DataNodes параллельно. Наконец, репликация повышает устойчивость к сбоям в конкретном дата-центре или сетевом сегменте.
- Что происходит при сбое NameNode или DataNode?
При сбое DataNode NameNode обнаруживает отсутствие HEARTBEAT и инициирует перераспределение блоков на другие DataNodes, чтобы поддержать заданный уровень репликации. При сбое NameNode в HA-конфигурации активный NameNode переходит в Standby, и журналы изменений реплицируются между узлами. В федеративной конфигурации каждый Namespace продолжает функционировать независимо, если затронуты только отдельные компоненты.
- Какие протоколы используются для взаимодействия клиентов и нод в HDFS?
Ключевые интерфейсы - ClientProtocol (операции над пространством имён и файлами), DatanodeProtocol (сообщения DataNode к NameNode о состоянии и отчетах), а также блок-Transfer протокол для прямой передачи блоков между DataNodes и клиентами. Для доступа через HTTP используются WebHDFS и HTTP-based интерфейсы, полезные для интеграций с внешними сервисами.
- Что такое FSImage и EditLog и зачем они нужны?
FSImage - снимок состояния пространства имён на конкретный момент времени. EditLog - журнал всех операций, изменяющих файловую систему. При старте NameNode сначала восстанавливает FSImage, затем воспроизводит операции из EditLog, чтобы вернуть файловую систему в текущее состояние. Этот механизм обеспечивает надёжность восстановления после сбоев.
- Как работает HA в HDFS?
HA подразумевает наличие активного и резервного NameNode. Журналы изменений (JournalNode/QJM) реплицируются между ними, чтобы при переключении активного узла данные Namespace сохранялись корректно. Standby NameNode может включать активную роль без потери доступности, обеспечивая минимальное время простоя.
- Как роль namespace влияет на архитектуру корпоративного data lake?
Namespace определяет область ответственности и доступ к данным внутри корпоративного data lake. В федеративной архитектуре можно разделить пространства имен по бизнес-юнитам или проектам, сохраняя общую инфраструктуру хранения и управляя доступом централизованно. Такой подход упрощает администрирование, обеспечивает безопасность и повышает масштабируемость при росте объёмов данных.
