Paper
The Google File System
Классическая работа Google о проектировании distributed file system для больших данных.
Distributed File System - базовый строительный блок для data-платформ. Идея GFS/HDFS: разделять крупные файлы на большие блоки, реплицировать их по кластеру и держать metadata отдельно от data path. Это упрощает горизонтальное масштабирование и делает систему устойчивой к постоянным hardware-сбоям.
Требования
Функциональные
- Хранение очень больших файлов (гигабайты/терабайты) поверх кластера commodity-серверов.
- Последовательные append/read операции для batch и аналитических workload'ов.
- Репликация блоков между узлами и автоматическое восстановление после сбоев.
- Метаданные файловой системы: namespace, mapping файл -> блоки -> реплики.
- Background процессы: ребалансировка, re-replication, garbage collection orphan-блоков.
Нефункциональные
Durability: 11+ nines (практически)
Потеря отдельных дисков/нод не должна приводить к потере данных.
Throughput: Высокий aggregate I/O
Оптимизация под большие sequential read/write, а не под мелкие random IO.
Scalability: Линейное горизонтальное
Добавление DataNode должно увеличивать и capacity, и bandwidth.
Availability: Работа при частичных сбоях
Система деградирует, но остаётся доступной для majority сценариев.
High-Level Architecture
Architecture Map
DFS high-level structure (GFS/HDFS style)Control Plane
Data Plane
Ключевой паттерн: metadata plane и data plane разделены. Master управляет размещением и namespace, но сами байты текут напрямую между client и data nodes.
Read/Write Flow
Read/Write Path Explorer
Переключай path и прогоняй шаги, как это сделано в object-storage flow.
Write Path: operational notes
- Клиент запрашивает у master выделение нового блока и список целевых DataNode.
- Master выбирает узлы по placement policy (rack-aware, free space, load).
- Клиент стримит chunk в pipeline DataNode1 -> DataNode2 -> DataNode3.
- ACK возвращается цепочкой назад; блок помечается committed после успешной записи всех реплик.
- Метаданные о блоке и версии фиксируются в journal/snapshot контуре master.
Read Path: operational notes
- Клиент получает у master карту блоков и список доступных реплик.
- Для каждого блока выбирается ближайшая реплика (rack/locality aware).
- Чтение идёт напрямую с DataNode, без проксирования payload через master.
- При checksum mismatch клиент переключается на другую реплику.
- Master участвует только в metadata plane, что уменьшает bottleneck.
Failure Handling
- DataNode timeout: master помечает ноду dead и планирует re-replication её блоков.
- Corrupted block: детектируется по checksum; запускается repair из здоровой реплики.
- Master crash: восстановление из journal + checkpoint, затем replay edits.
- Network partition: quorum/HA-механика для active/standby master (в современных реализациях).
- Hot file/block: read replicas и cache tiers уменьшают hotspots на популярных данных.
GFS vs HDFS (коротко)
| Аспект | GFS | HDFS |
|---|---|---|
| Основной use-case | Big data processing внутри Google экосистемы | Hadoop analytics экосистема в enterprise |
| Block size | Большие chunks (классически 64MB) | Большие blocks (обычно 128MB+) |
| Consistency model | Relaxed, append-heavy semantics | Write-once-read-many (классически) |
| Master HA | Внутренние HA-стратегии Google | NameNode HA (active/standby + journal quorum) |
Что обсудить на интервью
- Почему large block size уменьшает metadata overhead и повышает throughput.
- Как placement policy балансирует locality, fault domains и network cost.
- Почему single-master исторически проще, и как эволюционировать к HA.
- Как проверять целостность: checksums, scrubbing, background repair.
- Где граница DFS vs Object Storage и как они сочетаются в data platform.
Связанные главы
Reference
HDFS Architecture Guide
Официальное описание дизайна HDFS: NameNode, DataNode, replication и отказоустойчивость.