Современные тенденции в развитии web-приложений и экспоненциальный рост информации, ими обрабатываемых, привел к потребности в появлении файловых систем ориентированных на обеспечение высокой производительности, масштабируемости, надежности и доступности. В стороне от данной проблемы не могли остаться такие гиганты поисковой индустрии, как Google и Yahoo.
Специфика приложений и вычислительной инфраструктуры Google, построенной на огромном количестве недорогих серверов, с присущими им постоянными отказами, привело к разработке собственной закрытой распределенной файловой системы Google File System (GFS). Данная система нацелена на автоматическое восстановление после сбоев, высокую отказоустойчивость, высокую пропускную способность при доступе к данным в потоковом режиме. Система предназначена для работы с большими объемами данных, подразумевающих большие размеры хранимых файлов, поэтому GFS оптимизирована для соответствующих операций. В частности, в целях упрощения реализации и повышения эффективности GFS не реализует стандартный POSIX-интерфейс.
Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System. Проект активно поддерживается и развивается компанией Yahoo (18 человек). Проведем сравнительный анализ терминов, используемых в данных системах, установим их соответствие и остановимся подробнее на HDFS:
HDFS — распределенная файловая система, используемая в проекте Hadoop. HDFS-кластер в первую очередь состоит из NameNоde-сервера и DataNode-серверов, которые хранят непосредственно данные. NameNode-сервер управляет пространством имен файловой системы и доступом клиентов к данным. Чтобы разгрузить NameNode-сервер, передача данных осуществляется только между клиентом и DataNode-сервером.
Основной NameNode-сервер фиксирует все транзакции, связанные с изменением метаданных файловой системы, в log-файле, называемом EditLog. При запуске основного NameNode-сервера, он считывает образ HDFS (расположенный в файле FsImage) и применяет к нему все изменения, накопленные в EditLog. Затем записывается новый образ уже с примененными изменениями, и система начинает работу уже с чистым log-файлом. Следует заметить, что данную работу NameNode-сервер выполняет единожды при его первом запуске. В последующем, подобные операции возлагаются на вторичный NameNode-сервер. FsImage и EditLog в конечном итоге хранятся на основном сервере.
При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:
— выбор новых DataNode-серверов для новых реплик
— балансировка размещения данных по DataNode-серверам
Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.
Данные хранятся в виде последовательности блоков фиксированного размера. Копии блоков (реплики) хранятся на нескольких серверах, по умолчанию — трех. Их размещение происходит следующим образом:
— первая реплика размещается на локальном ноде
— вторая реплика на другой ноде в этой же стойке
— третья реплика на произвольной ноде другой стойки
— остальные реплики размещаются произвольным способом
При чтении данных клиент выбирает ближайшую к нему DataNode-сервер с репликой.
Ослабленная модель целостности данных, реализованная в файловой системе, не гарантирует идентичность реплик. Поэтому HDFS перекладывает проверку целостности данных на клиентов. При создании файла клиент рассчитывает контрольные суммы каждые 512 байт, которые в последующем сохраняются на DataNode-сервере. При считывании файла, клиент обращается к данным и контрольным суммам. И, в случае их несоответствия происходит обращение к другой реплике.
«При записи данных в HDFS используется подход, позволяющий достигнуть высокой пропускной способности. Приложение ведет запись в потоковом режиме, при этом HDFS-клиент кэширует записываемые данные во временном локальном файле. Когда в файле накапливаются данные на один HDFS-блок, клиент обращается к NameNode-серверу, который регистрирует новый файл, выделяет блок и возвращает клиенту список datanode-серверов для хранения реплик блока. Клиент начинает передачу данных блока из временного файла первому DataNode-серверу из списка. DataNode-сервер сохраняет данные на диске и пересылает следующему DataNode-серверу в списке. Таким образом, данные передаются в конвейерном режиме и реплицируются на требуемом количестве серверов. По окончании записи, клиент уведомляет NameNode-сервер, который фиксирует транзакцию создания файла, после чего он становится доступным в системе»
В силу обеспечения сохранности данных (на случай отката операции), удаление в файловой системе происходит по определенной методике. Вначале файл перемещается в специально отведенную для этого /trash директорию, а уже после истечения определенного времени, происходит его физическое удаление:
— удаление файла из пространства имен HDFS
— освобождение связанных с данными блоков
— отсутствие автоматического запуска главного сервера в случае его сбоя (данная функциональность реализована в GFS)
— отсутствие операций append (предполагается в версии 0.19.0) и snapshot (данные функциональности также реализованы в GFS)
Почитать, что будет в следующих версиях HDFS можно в вики проекта на сайте Apache Foundation. Дополнительную информацию и мнения людей работающих с Hadoop можно найти в блогах компаний активно использующих данную технологию: Yahoo, A9, Facebook, Last.fm, Laboratory
— Dhruba B. Hadoop Distributed File System, 2007
— Tom W. A Tour of Apache Hadoop
— Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System
— Сухорослов О.В. Новые технологии распределенного хранения и обработки больших массивов данных
Данная статья вступительная, ее цель: посветить читателя в атмосферу соответствующих наработок. В случае положительных отзывов и/или заинтересованности читателей мы подготовим ряд дополнительных смежных статей:
Специфика приложений и вычислительной инфраструктуры Google, построенной на огромном количестве недорогих серверов, с присущими им постоянными отказами, привело к разработке собственной закрытой распределенной файловой системы Google File System (GFS). Данная система нацелена на автоматическое восстановление после сбоев, высокую отказоустойчивость, высокую пропускную способность при доступе к данным в потоковом режиме. Система предназначена для работы с большими объемами данных, подразумевающих большие размеры хранимых файлов, поэтому GFS оптимизирована для соответствующих операций. В частности, в целях упрощения реализации и повышения эффективности GFS не реализует стандартный POSIX-интерфейс.
Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System. Проект активно поддерживается и развивается компанией Yahoo (18 человек). Проведем сравнительный анализ терминов, используемых в данных системах, установим их соответствие и остановимся подробнее на HDFS:
| HDFS | GFS | |
| Главный сервер | NameNode | Master |
| Подчиненные сервера | DataNode Servers | Chunk Servers |
| Операции Append и Snapshot | - | + |
| Автоматическое востановление после отказа главного сервера | - | + |
| Язык реализации | Java | C++ |
HDFS — распределенная файловая система, используемая в проекте Hadoop. HDFS-кластер в первую очередь состоит из NameNоde-сервера и DataNode-серверов, которые хранят непосредственно данные. NameNode-сервер управляет пространством имен файловой системы и доступом клиентов к данным. Чтобы разгрузить NameNode-сервер, передача данных осуществляется только между клиентом и DataNode-сервером.
Secondary NameNode:
Основной NameNode-сервер фиксирует все транзакции, связанные с изменением метаданных файловой системы, в log-файле, называемом EditLog. При запуске основного NameNode-сервера, он считывает образ HDFS (расположенный в файле FsImage) и применяет к нему все изменения, накопленные в EditLog. Затем записывается новый образ уже с примененными изменениями, и система начинает работу уже с чистым log-файлом. Следует заметить, что данную работу NameNode-сервер выполняет единожды при его первом запуске. В последующем, подобные операции возлагаются на вторичный NameNode-сервер. FsImage и EditLog в конечном итоге хранятся на основном сервере.
Механизм репликации:
При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:
— выбор новых DataNode-серверов для новых реплик
— балансировка размещения данных по DataNode-серверам
Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.
Стратегия размещение реплик:
Данные хранятся в виде последовательности блоков фиксированного размера. Копии блоков (реплики) хранятся на нескольких серверах, по умолчанию — трех. Их размещение происходит следующим образом:
— первая реплика размещается на локальном ноде
— вторая реплика на другой ноде в этой же стойке
— третья реплика на произвольной ноде другой стойки
— остальные реплики размещаются произвольным способом
При чтении данных клиент выбирает ближайшую к нему DataNode-сервер с репликой.
Целостность данных:
Ослабленная модель целостности данных, реализованная в файловой системе, не гарантирует идентичность реплик. Поэтому HDFS перекладывает проверку целостности данных на клиентов. При создании файла клиент рассчитывает контрольные суммы каждые 512 байт, которые в последующем сохраняются на DataNode-сервере. При считывании файла, клиент обращается к данным и контрольным суммам. И, в случае их несоответствия происходит обращение к другой реплике.
Запись данных:
«При записи данных в HDFS используется подход, позволяющий достигнуть высокой пропускной способности. Приложение ведет запись в потоковом режиме, при этом HDFS-клиент кэширует записываемые данные во временном локальном файле. Когда в файле накапливаются данные на один HDFS-блок, клиент обращается к NameNode-серверу, который регистрирует новый файл, выделяет блок и возвращает клиенту список datanode-серверов для хранения реплик блока. Клиент начинает передачу данных блока из временного файла первому DataNode-серверу из списка. DataNode-сервер сохраняет данные на диске и пересылает следующему DataNode-серверу в списке. Таким образом, данные передаются в конвейерном режиме и реплицируются на требуемом количестве серверов. По окончании записи, клиент уведомляет NameNode-сервер, который фиксирует транзакцию создания файла, после чего он становится доступным в системе»
Удаление данных:
В силу обеспечения сохранности данных (на случай отката операции), удаление в файловой системе происходит по определенной методике. Вначале файл перемещается в специально отведенную для этого /trash директорию, а уже после истечения определенного времени, происходит его физическое удаление:
— удаление файла из пространства имен HDFS
— освобождение связанных с данными блоков
Текущие недостатки:
— отсутствие автоматического запуска главного сервера в случае его сбоя (данная функциональность реализована в GFS)
— отсутствие операций append (предполагается в версии 0.19.0) и snapshot (данные функциональности также реализованы в GFS)
Почитать, что будет в следующих версиях HDFS можно в вики проекта на сайте Apache Foundation. Дополнительную информацию и мнения людей работающих с Hadoop можно найти в блогах компаний активно использующих данную технологию: Yahoo, A9, Facebook, Last.fm, Laboratory
Источники:
— Dhruba B. Hadoop Distributed File System, 2007
— Tom W. A Tour of Apache Hadoop
— Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System
— Сухорослов О.В. Новые технологии распределенного хранения и обработки больших массивов данных
Данная статья вступительная, ее цель: посветить читателя в атмосферу соответствующих наработок. В случае положительных отзывов и/или заинтересованности читателей мы подготовим ряд дополнительных смежных статей:
- Установка Hadoop Core + Hbase на Windows OS (+ php класс реализующий взаимодействие с Hbase при помощи REST API)
- Перевод статьи: «MapReduce: Simplified Data Processing on Large Clusters»
