Apache Hadoop Distributed File System¶

Apache Hadoop Distributed File System (HDFS) — это распределённая файловая система, предназначенная для хранения больших объёмов данных (от десятков терабайт до петабайт) на кластерах из стандартных серверов. HDFS является ключевым компонентом экосистемы Apache Hadoop, обеспечивая отказоустойчивость, высокую пропускную способность и возможность обработки данных по принципу «перемещение вычислений к данным». Разработана на основе идей, изложенных в публикациях Google File System (GFS) 2003 года.

¶Архитектура

HDFS реализует архитектуру «ведущий-ведомый» (master-slave). В кластере выделяются два типа узлов:

• NameNode (ведущий узел): Центральный сервер, управляющий метаданными файловой системы. Он хранит иерархию каталогов и файлов, а также карту соответствия блоков файлов узлам DataNode. NameNode не хранит сами данные, а только информацию о том, где и как они расположены. В стандартной конфигурации NameNode является единой точкой отказа (Single Point of Failure, SPOF), что требует применения дополнительных механизмов высокой доступности (High Availability, HA).
• DataNode (ведомые узлы): Серверы, непосредственно хранящие данные. Каждый DataNode управляет блоками данных, хранящимися на его локальных дисках. Он периодически отправляет NameNode сигналы (heartbeats) и отчёты о состоянии блоков (block reports). DataNode также отвечают за создание, удаление и репликацию блоков по команде NameNode.

¶Ключевые компоненты

• Блоки (Blocks): Данные в HDFS разбиваются на блоки фиксированного размера (по умолчанию 128 МБ в современных версиях, ранее — 64 МБ). Каждый блок хранится как отдельный файл на локальной файловой системе DataNode. Размер блока значительно больше, чем в традиционных файловых системах, что снижает накладные расходы на поиск и ускоряет последовательное чтение.
• Репликация (Replication): Для обеспечения отказоустойчивости каждый блок данных реплицируется на несколько DataNode (по умолчанию коэффициент репликации равен 3). Реплики размещаются по правилу «rack-aware»: первая реплика — на том же узле, где выполняется запись (или на случайном, если клиент вне кластера), вторая — на другом узле в той же стойке, третья — на узле в другой стойке. Это предотвращает потерю данных при отказе одного или нескольких узлов или целой стойки.
• Secondary NameNode: Вспомогательный сервер, который не является резервной копией NameNode. Его задача — периодически объединять журнал изменений (edit log) с образом файловой системы (fsimage) и создавать контрольную точку (checkpoint). Это предотвращает чрезмерное разрастание журнала и ускоряет восстановление NameNode после сбоя. В современных конфигурациях HA эту роль выполняет Standby NameNode.

¶Принципы работы

¶Чтение данных

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

¶Запись данных

1. Клиент запрашивает у NameNode разрешение на создание файла.
2. NameNode проверяет права доступа и отсутствие дубликата, после чего создаёт запись в метаданных.
3. Клиент разбивает данные на блоки и отправляет первый блок на первый DataNode из списка, полученного от NameNode.
4. DataNode, получив блок, начинает реплицировать его на следующий DataNode из списка, а тот — на третий. Формируется конвейер репликации (replication pipeline).
5. После успешной записи всех реплик блока, DataNode отправляет подтверждение клиенту, а клиент — подтверждение NameNode. Процесс повторяется для каждого блока.

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

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

• Отказоустойчивость: Автоматическая репликация блоков позволяет восстанавливать данные при отказе узлов без потерь.
• Масштабируемость: Кластер легко расширяется добавлением новых DataNode. Ёмкость и производительность растут линейно.
• Высокая пропускная способность: Оптимизирован для последовательного чтения/записи больших файлов (потоковая обработка).
• Экономичность: Работает на стандартном, недорогом оборудовании (commodity hardware).
• Переносимость данных: Перемещение вычислений к данным (data locality) снижает сетевой трафик и ускоряет обработку.

¶Недостатки

• Высокая задержка: HDFS не подходит для интерактивных приложений (например, баз данных с низкой задержкой). Время доступа к случайному блоку может составлять десятки миллисекунд.
• Неэффективность для малых файлов: Хранение множества мелких файлов (меньше размера блока) перегружает NameNode, так как каждый файл и блок требуют записи в метаданных.
• Сложность администрирования: Требует квалифицированного персонала для настройки, мониторинга и устранения неполадок.
• Ограниченная поддержка одновременной записи: В стандартной конфигурации HDFS поддерживает только один пишущий процесс для файла (append-only). Модификация существующих данных (update) не поддерживается.
• Единая точка отказа (без HA): При отказе NameNode кластер становится недоступным до восстановления.

¶Применение

HDFS является основой для многих систем обработки больших данных, включая:

• Apache Hadoop MapReduce: Классическая модель пакетной обработки данных.
• Apache Spark: Фреймворк для обработки данных в памяти, часто использующий HDFS как источник данных.
• Apache Hive: Система запросов на SQL-подобном языке (HiveQL), преобразующая запросы в задачи MapReduce или Tez.
• Apache HBase: Распределённая NoSQL база данных, работающая поверх HDFS.
• Apache Flume и Apache Sqoop: Инструменты для импорта/экспорта данных в HDFS из внешних источников.
• Системы машинного обучения и анализа данных: Хранение обучающих наборов и результатов вычислений.

¶История

• 2003 год: Google публикует статью «The Google File System».
• 2004 год: Дуг Каттинг и Майк Кафарелла начинают работу над проектом Nutch, в рамках которого разрабатывается распределённая файловая система NDFS.
• 2006 год: NDFS выделяется в отдельный проект Apache Hadoop. Название меняется на HDFS.
• 2008 год: Yahoo! запускает крупнейший на тот момент кластер Hadoop (4000 узлов).
• 2010 год: Apache Hadoop становится проектом верхнего уровня Apache Software Foundation.
• 2012 год: Выход Hadoop 2.0, включающий поддержку высокой доступности NameNode и механизм федерации (HDFS Federation).
• 2017 год: Выход Hadoop 3.0, вводящий erasure coding (кодирование с удалением) для снижения накладных расходов на репликацию, а также поддержку нескольких NameNode в режиме активный/активный.

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

• HDFS спроектирована для работы с файлами, размер которых значительно превышает размер блока. Типичный файл в HDFS имеет размер от нескольких гигабайт до терабайт.
• В HDFS отсутствует кэширование данных на уровне файловой системы. Вся оптимизация производительности достигается за счёт параллелизма и локальности данных.
• Для обеспечения целостности данных HDFS использует контрольные суммы (checksums) для каждого блока. При чтении данные проверяются на наличие ошибок.
• В Hadoop 3.0 появилась поддержка erasure coding, которая позволяет хранить данные с меньшими накладными расходами (например, 1.5x вместо 3x при репликации), но требует больше вычислительных ресурсов для восстановления.

¶Источники

• Apache Hadoop Documentation. HDFS Architecture Guide.
• White, T. (2015). Hadoop: The Definitive Guide. O'Reilly Media.
• Ghemawat, S., Gobioff, H., & Leung, S. T. (2003). The Google File System. ACM SIGOPS Operating Systems Review.
• Shvachko, K., Kuang, H., Radia, S., & Chansler, R. (2010). The Hadoop Distributed File System. IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST).