Открыть сервис
Главная → Блог → Hadoop Distributed File System

Hadoop Distributed File System

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

Архитектура

HDFS имеет архитектуру «главный-подчинённый» (master-slave). Кластер состоит из одного узла NameNode (главный узел) и множества узлов DataNode (узлы данных). В современных версиях (Hadoop 2.x и выше) для обеспечения высокой доступности используется Standby NameNode (резервный главный узел).

NameNode

NameNode является центральным компонентом, управляющим метаданными файловой системы. Он хранит информацию о структуре каталогов, именах файлов, правах доступа, а также о том, на каких DataNode расположены блоки каждого файла. NameNode не хранит сами данные пользователей. Он отвечает за обработку запросов клиентов (чтение, запись, создание, удаление файлов) и за координацию операций с DataNode. В случае выхода NameNode из строя кластер становится недоступным, поэтому для критичных систем обязательно настраивается High Availability (HA) с использованием резервного NameNode и общего хранилища журналов (например, Quorum Journal Manager).

DataNode

DataNode — это рабочие узлы кластера, на которых физически хранятся блоки данных. Каждый DataNode регулярно отправляет NameNode сигналы (heartbeat) и отчёты о состоянии хранящихся блоков (block report). DataNode отвечают за чтение и запись данных по запросу клиентов, а также за репликацию блоков между собой.

Блоки и репликация

Файлы в HDFS разбиваются на блоки фиксированного размера (по умолчанию 128 МБ, в ранних версиях — 64 МБ). Каждый блок хранится на нескольких DataNode для обеспечения отказоустойчивости. Коэффициент репликации (replication factor) по умолчанию равен 3, что означает, что каждый блок существует в трёх копиях, размещённых на разных узлах (обычно в разных стойках). Это позволяет системе переживать отказ нескольких узлов без потери данных.

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

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

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

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

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

Особенности и ограничения

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

  • Отказоустойчивость: автоматическая репликация блоков позволяет восстанавливать данные при выходе из строя узлов.
  • Масштабируемость: добавление новых DataNode увеличивает ёмкость и пропускную способность кластера.
  • Потоковый доступ: оптимизирована для последовательного чтения больших файлов, что эффективно для задач пакетной обработки (MapReduce, Spark).
  • Экономичность: работает на стандартном оборудовании, не требует дорогих хранилищ.

Недостатки

  • Высокая задержка: не подходит для операций с низкой задержкой (например, интерактивные запросы).
  • Неэффективность для малых файлов: большое количество мелких файлов перегружает NameNode, так как каждый файл требует записи метаданных.
  • Ограниченная поддержка произвольного доступа: не поддерживает эффективное изменение данных в середине файла (только добавление в конец).
  • Сложность администрирования: требует настройки и мониторинга кластера, особенно при больших объёмах данных.

История и развитие

HDFS была создана на основе идей, заложенных в файловую систему Google File System (GFS), описанную в статье 2003 года. Разработка началась в 2005 году в рамках проекта Apache Nutch, а затем была выделена в отдельный проект Hadoop. Первая версия (Hadoop 1.0) вышла в 2011 году. В Hadoop 2.x (2013 год) появилась поддержка высокой доступности NameNode и федерации (несколько NameNode). В Hadoop 3.x (2017 год) были добавлены эразурное кодирование (erasure coding) для экономии места, поддержка контейнеров с произвольным доступом и улучшенная работа с несколькими NameNode.

Применение

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

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

На рынке существуют и другие распределённые файловые системы, например:

  • Google Cloud Storage (GCS) — облачное решение от Google.
  • Amazon S3 — объектное хранилище от Amazon, часто используется как альтернатива HDFS в облачных средах.
  • Ceph — распределённая файловая система с поддержкой объектного, блочного и файлового доступа.
  • GlusterFS — распределённая файловая система, ориентированная на высокую производительность.

Источники

  • Apache Hadoop Documentation. «HDFS Architecture Guide». Apache Software Foundation.
  • Tom White. «Hadoop: The Definitive Guide». 4th Edition, O'Reilly Media, 2015.
  • Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. «The Google File System». ACM SIGOPS Operating Systems Review, 2003.
  • Konstantin Shvachko et al. «The Hadoop Distributed File System». IEEE MSST, 2010.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы