Распределённая файловая система нужна там, где кластер хранит очень большие файлы и должен держать высокий суммарный поток чтения и записи, а не обслуживать миллионы мелких случайных запросов.
Эта глава связывает пространство имён, размещение блоков, репликацию, путь записи, путь чтения и восстановление после сбоев в одну рабочую архитектуру кластера.
В интервью и архитектурных обсуждениях кейс полезен тем, что заставляет отдельно объяснить контур управления, прямой путь данных, локальность чтения и разнос копий по доменам отказа.
Пропускная способность кластера
DFS выигрывает там, где большие последовательные чтение и запись можно распределить по многим узлам и сетевым каналам, а не упираться в один сервер.
Метаданные и журнал
Пространство имён, карта блоков и журнал операций должны оставаться компактными, надёжными и быстро восстанавливаться после сбоя мастер-узла.
Горячие блоки
Популярные файлы быстро создают перекос нагрузки, если заранее не продумать чтение с ближайшей копии, дополнительные реплики и фоновую балансировку.
Восстановление после сбоев
Потеря диска, узла или целой стойки не должна останавливать систему: нужны сигналы состояния, ремонт копий и понятный порядок возврата главного узла в строй.
Paper
The Google File System
Классическая работа Google о проектировании распределённой файловой системы для хранения и обработки больших данных.
нужна там, где кластер должен хранить очень большие файлы и держать высокий поток чтения и записи, а не обслуживать миллионы мелких случайных запросов. Она разбивает данные на большие блоки, хранит несколько копий через , держит отдельно от потока байтов и проектируется под высокую даже при регулярных отказах оборудования.
Требования
Для такого хранилища важны не только объём и число узлов, но и предсказуемая всего кластера, и понятная при частичных сбоях.
Функциональные
Хранение очень больших файлов на кластере из обычных серверов.
Последовательная дозапись и чтение больших блоков для пакетной и аналитической обработки.
Репликация блоков между узлами и автоматическое восстановление после сбоев.
Управление метаданными: дерево каталогов, соответствие файла блокам и размещению реплик.
Фоновые процессы: перераспределение блоков, довосстановление копий и очистка осиротевших данных.
Нефункциональные
Долговечность: 11+ девяток на практике
Потеря отдельных дисков и узлов не должна приводить к потере пользовательских данных.
Пропускная способность: Высокий суммарный I/O
Система оптимизируется под большие последовательные чтение и запись, а не под мелкий случайный I/O.
Масштабируемость: Линейное горизонтальное масштабирование
Добавление нового узла данных должно увеличивать и ёмкость, и доступную полосу пропускания кластера.
Доступность: Работа при частичных отказах
Система должна деградировать предсказуемо и оставаться доступной для чтения и записи в основных сценариях.
Высокоуровневая архитектура
Общая схема архитектуры
Высокоуровневая модель DFS в духе GFS и HDFSКонтур управления
Контур данных
В этой архитектуре отвечает за размещение блоков, восстановление и фоновые решения кластера, а обслуживает прямой поток байтов между клиентом и узлами данных. Все критичные изменения сначала попадают в , чтобы мастер-узел мог восстановить состояние после сбоя.
Путь записи и чтения
Во время записи клиент получает у мастер-узла и пишет блок в цепочку реплик. При чтении система выбирает ближайшую копию по и по принципу , чтобы не тратить лишний межстоечный трафик.
Разбор пути чтения и записи
Переключайте сценарий и шаг за шагом смотрите, как проходит запись и чтение блока.
Путь записи: важные детали
- Клиент просит у мастер-узла выделить новый блок и подобрать целевые узлы данных.
- Мастер-узел выбирает узлы с учётом стоек, свободного места и текущей нагрузки.
- Клиент отправляет данные в цепочку из трёх узлов данных.
- Подтверждения возвращаются по той же цепочке; блок считается записанным только после успешной записи всех копий.
- Мастер-узел фиксирует новую версию блока и его размещение в журнале и контрольной точке.
Путь чтения: важные детали
- Клиент получает у мастер-узла карту блоков и список доступных копий.
- Для каждого блока выбирается ближайшая здоровая реплика.
- Чтение идёт напрямую с узла данных, без проксирования полезной нагрузки через мастер-узел.
- Если контрольная сумма не совпала, клиент переключается на другую реплику.
- Мастер-узел работает только с метаданными, поэтому не становится узким местом на пути байтов.
Обработка сбоев
План отказоустойчивости должен покрывать не только потерю узла, но и возврат мастер-узла из . Отдельная на популярных файлах и блоках тоже требует заранее продуманной реакции.
- Если узел данных перестал отвечать, мастер-узел помечает его как недоступный и запускает довосстановление копий.
- Повреждённый блок обнаруживается по контрольным суммам и восстанавливается из здоровой реплики.
- После сбоя мастер-узел поднимается из журнала и контрольной точки, затем повторно применяет незавершённые правки.
- При сетевом разделении помогает схема высокой доступности с активным и резервным мастер-узлом и кворумом журнала.
- Популярные файлы и блоки требуют дополнительных копий для чтения, кэшей и фоновой балансировки.
GFS и HDFS: короткое сравнение
| Аспект | GFS | HDFS |
|---|---|---|
| Главный сценарий | Обработка больших данных внутри экосистемы Google | Экосистема Hadoop и корпоративная аналитика |
| Размер блока | Большие фрагменты, исторически 64 MB | Большие блоки, обычно от 128 MB |
| Модель консистентности | Более свободная семантика, заточенная под дозапись | Классическая модель write-once-read-many |
| Высокая доступность управляющего узла | Внутренние стратегии высокой доступности Google | Высокая доступность NameNode: активный и резервный узлы плюс журнал-кворум |
Что обсудить на интервью
В разговоре про размещение важно ясно объяснить, где проходит каждый и какой ценой даётся межстоечный трафик. Отдельно полезно показать, где DFS дополняет , а где не заменяет его.
- Почему большой размер блока уменьшает нагрузку на слой метаданных и повышает суммарную пропускную способность.
- Как политика размещения балансирует локальность данных, домены отказа и цену сетевого трафика.
- Почему схема с одним мастер-узлом исторически проще и как её эволюционировать в полноценную схему высокой доступности.
- Как проверять целостность данных: контрольные суммы, фоновое сканирование и автоматическое восстановление.
- Где проходит граница между DFS и объектным хранилищем и как они сочетаются внутри платформы данных.
Ключевые выводы
- DFS выигрывает там, где нужно хранить очень большие файлы и распределять большие последовательные чтение и запись по кластеру.
- Главный архитектурный приём — отделить слой метаданных от пути данных, чтобы клиент работал с узлами данных напрямую.
- Эксплуатационная сложность сосредоточена в размещении копий, восстановлении после сбоев и борьбе с горячими блоками.
Reference
HDFS Architecture Guide
Официальное описание архитектуры HDFS: NameNode, DataNode, репликация и отказоустойчивость.
Связанные главы
- Object Storage (S3) - помогает сравнить DFS и объектное хранилище по модели доступа, консистентности и эксплуатационным компромиссам.
- Big Data - добавляет контекст платформ данных, где GFS и HDFS служат базовым слоем хранения для пакетной и аналитической обработки.
- DDIA - укрепляет базу по репликации, разбиению данных и отказоустойчивости в распределённых хранилищах.
- Database Internals - углубляет понимание внутренней механики движков хранения и разделения метаданных и потока данных.