Google File System

Google File System (GFS) — это масштабируемая распределённая файловая система, разработанная компанией Google для обеспечения надёжного доступа к большим объёмам данных в условиях использования стандартного, недорогого оборудования. GFS была спроектирована для обработки потоковых чтений и записи данных в одномодовом (single-writer) режиме, ориентирована на большие файлы и устойчива к частым отказам компонентов кластера. Система стала основой для многих технологий хранения и обработки данных, включая Apache Hadoop Distributed File System (HDFS), и сыграла ключевую роль в развитии облачных вычислений и больших данных (Big Data).

История

Разработка GFS началась в конце 1990-х годов, когда инженеры Google столкнулись с ограничениями существующих решений (например, Network File System, NFS) при обработке терабайтных наборов данных, используемых в поисковом индексе и других сервисах. Традиционные файловые системы не обеспечивали необходимой отказоустойчивости, параллельной пропускной способности и автоматического восстановления при сбоях.

Первое публичное описание архитектуры GFS было опубликовано в 2003 году в статье «The Google File System» (Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung). В статье излагались принципы, на которых была построена система:

• Отказоустойчивость как норма: система предполагает постоянные сбои оборудования (среднее наработка до отказа узла — дни или недели), поэтому все данные реплицируются, а контрольные точки и восстановление встроены в архитектуру.
• Огромные файлы: файлы размером в гигабайты и терабайты, состоящие из блоков (chunks) по 64 МБ (позднее — до 128 МБ).
• Оптимизация под потоковую запись: в отличие от традиционных файловых систем, поддерживающих множество мелких операций ввода-вывода, GFS оптимизирована для последовательной записи и чтения больших блоков.
• Атомарные операции: запись в файл происходит от одного клиента; в системе не реализована полная многопользовательская семантика (нет механизма блокировок, аналогичного NFS).

GFS была полностью реализована на C++ и запущена в производственной среде Google в 2001 году. В течение следующих лет она использовалась для хранения данных всех основных сервисов Google: поиска, Gmail, YouTube, Google Maps, Google Drive и других.

Архитектура

Архитектура GFS включает три основные компоненты:

Master-узел (GFS Master)

• Один главный узел (master), который хранит всю метаинформацию о файловой системе: имена файлов, структуру каталогов, расположение блоков (chunk handles) на серверах, контрольные суммы, журналы операций (operation log).
• Master не хранит данные пользователя, только метаданные. Он поддерживает в памяти полное дерево каталогов и отображение файлов в блоки.
• Master отвечает за выявление сбоев серверов, перераспределение реплик, выполнение операций удаления и переименования файлов, а также за координацию записи (выбор первичной реплики).
• Master не участвует в передаче данных — все операции чтения и записи происходят между клиентами и серверами блоков.

Серверы блоков (Chunkservers)

• Каждый сервер блоков хранит локально (на стандартной файловой системе ОС) фрагменты (chunks) данных — блоки размером до 64 МБ (в более поздних версиях — до 128 МБ).
• Каждый блок находится в трёх репликах (по умолчанию) на разных серверах блоков для отказоустойчивости.
• Серверы блоков периодически отправляют master-узлу так называемые «сообщения о состоянии» (heartbeats), сообщая о себе и о хранимых блоках.
• Данные хранятся в простых файлах на локальном диске под управлением операционной системы (Linux). Нет специального RAID или SAN.

Клиент (GFS Client)

• Клиент — это библиотека, встроенная в приложения (например, в MapReduce-задачи). Она реализует API, аналогичный традиционным файловым операциям: open, read, write, append.
• Клиент сначала обращается к master-узлу, чтобы получить местоположение (handle) нужного блока и список серверов, где хранится его копия. Затем клиент связывается напрямую с ближайшей репликой (обычно по локальной сети) и выполняет чтение/запись.
• Клиент кэширует метаданные (адреса серверов блоков) на ограниченное время, чтобы снизить нагрузку на master.

Процесс записи

1. Клиент запрашивает у master разрешение на запись в конкретный файл и получает информацию о серверах блоков.
2. Master назначает одну из реплик первичной (primary) репликой (lease holder) — она координирует порядок записи.
3. Клиент передаёт данные (обычно в потоковом режиме) всем репликам последовательно. После того как все реплики подтвердят получение, клиент отправляет команду на фиксацию записи первичной реплике.
4. Первичная реплика фиксирует операцию и уведомляет остальные реплики. В случае сбоя master перевыбирает первичную реплику.

Процесс чтения

• Клиент указывает файл и смещение. Master возвращает идентификатор блока и список серверов, на которых находятся его реплики.
• Клиент выбирает сервер с наименьшей сетевой задержкой (обычно из той же стойки или подсети) и выполняет чтение блока.
• GFS использует контрольные суммы (checksums) для проверки целостности данных при чтении.

Ключевые особенности

• Масштабируемость: GFS поддерживает кластеры из тысяч машин и петабайты данных. Master-узел может масштабироваться вверх (за счёт увеличения оперативной памяти), но является единственной точкой отказа (single point of failure); в практических реализациях Google использовались shadow master'ы для репликации метаданных.
• Отказоустойчивость: репликация (обычно 3 копии), автоматическое восстановление при отказе диска или сервера, сканирование целостности блоков, поддержка замены оборудования без остановки работы.
• Оптимизация под потоковую запись: большие блоки (64–128 МБ) уменьшают количество метаданных и позволяют эффективно использовать пропускную способность сети.
• Поддержка только последовательной записи (append-only): GFS не поддерживает произвольную запись (overwrite) внутри файла; поддерживается только добавление данных (append) или перезапись целого файла. Это упрощает реализацию и соответствует практическим нагрузкам Google (поиск, логирование, MapReduce).
• Слабая согласованность (relaxed consistency): после аварийного отказа master или сервера блоков, данные могут быть потеряны на короткое время; для обеспечения более строгой согласованности приложение должно использовать транзакции на уровне прикладного кода (например, в Bigtable).

Применение

GFS использовалась во всех основных продуктовыхподсистемах Google до середины 2010-х годов. Примеры:

• Хранение индекса поиска: сотни миллионов документов, разбитых на шарды, реплицированные на множество машин.
• YouTube: хранение видеофайлов и метаданных (до масштабирования и отказа от GFS в пользу собственной распределённой файловой системы Colossus).
• Gmail и Google Drive: хранение писем и файлов пользователей (с дополнительным уровнем репликации).
• MapReduce: все промежуточные и выходные данные задач MapReduce сохранялись на GFS.

В 2010 году Google анонсировала преемника GFS — Colossus (также известный как Google File System II, GFS2). Colossus устранил ограничение единственного master-узла, используя распределённые метаданные, и улучшил поддержку произвольной записи. Colossus до сих пор является основной файловой системой Google.

Влияние

GFS оказала огромное влияние на индустрию обработки данных. Статья 2003 года вдохновила разработчиков проекта Apache Hadoop на создание Hadoop Distributed File System (HDFS), которая скопировала многие архитектурные решения GFS: один namenode (master), блоки 64–128 МБ, репликация, разделение метаданных и данных, подход «write-once-read-many». GFS также повлияла на проекты Ceph, GlusterFS и MooseFS.

Некоторые принципы GFS, такие как хранение метаданных в памяти и репликация как основной механизм отказоустойчивости, легли в основу более современных систем управления данными (например, Amazon DynamoDB и Apache Cassandra используют аналогичные идеи, но в привязке к NoSQL-моделям).

Критика и ограничения

• Единственная точка отказа: master-узел являлся центральным узким местом и потенциальной точкой сбоя. Google использовала shadow master'ы, но это не гарантировало полной отказоустойчивости.
• Неэффективность для малых файлов: из-за большого размера блоков (64 МБ) хранение миллионов мелких файлов приводило к избыточности и неэффективному использованию дискового пространства.
• Отсутствие поддержки произвольной записи: GFS не поддерживала overwrite, что ограничивало типы приложений.
• Сложности с согласованностью: модель слабой согласованности требовала от разработчиков приложений использования собственных механизмов (тайм-ауты, повторы, транзакции).
• Проприетарный исходный код: GFS не была выпущена как открытый продукт, что ограничило прямое использование, но знания о ней стимулировали развитие открытых альтернатив.

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

• Google не публиковала официально исходный код GFS. Всё, что известно о системе, взято из трёх ключевых публикаций: 2003, 2006 и 2010 годов, а также из косвенных упоминаний в других работах.
• Один из создателей GFS, Санджай Гемават, позже участвовал в разработке Bigtable, Spanner и других систем Google.
• GFS стала одним из примеров, который популяризировал концепцию «программно-определяемого хранилища» (software-defined storage) на основе commodity-оборудования.

Источники

• Ghemawat, Sanjay; Gobioff, Howard; Leung, Shun-Tak (2003). The Google File System. SOSP’03.
• Dean, Jeffrey; Ghemawat, Sanjay (2004). MapReduce: Simplified Data Processing on Large Clusters. OSDI’04.
• Corbett, James C., et al. (2012). Spanner: Google’s Globally-Distributed Database. OSDI’12.
• Описание Colossus из блога Google Cloud (2016) — Google’s Colossus File System (запись на Google Cloud Platform Blog).
• White, Tom (2015). Hadoop: The Definitive Guide (4th Edition). O’Reilly Media.