HDFS (Hadoop Distributed Filesystem)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 01:39, 15 января 2019.
HDFS
Hadoop Logo
Разработчики: Apache Software Foundation
Выпущена: 10 December 2011 года; 9 years ago (2011-12-10)
Постоянный выпуск: 3.0.0
Состояние разработки: Active
Написана на: Java
Операционная система: Кросс-платформенное
Тип ПО: Распределенная файловая система
Лицензия: Apache License 2.0
Веб-сайт https://hadoop.apache.org/

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

Развёртывание экземпляра HDFS предусматривает наличие центрального узла имён (англ. name node), хранящего метаданные файловой системы и метаинформацию о распределении блоков, и серии узлов данных (англ. data node), непосредственно хранящих блоки файлов. Узел имён отвечает за обработку операций уровня файлов и каталогов — открытие и закрытие файлов, манипуляция с каталогами, узлы данных непосредственно отрабатывают операции по записи и чтению данных. Узел имён и узлы данных снабжаются веб-серверами, отображающими текущий статус узлов и позволяющими просматривать содержимое файловой системы. Административные функции доступны из интерфейса командной строки.

HDFS является неотъемлемой частью Hadoop, однако, Hadoop поддерживает работу и с другими распределёнными файловыми системами без использования HDFS, поддержка Amazon S3 и CloudStore реализована в основном дистрибутиве. С другой стороны, HDFS может использоваться не только для запуска MapReduce-заданий, но и как распределённая файловая система общего назначения, в частности, поверх неё реализована распределённая NoSQL-СУБД Apache HBase, в её среде работает масштабируемая система машинного обучения Apache Mahout. [Источник 1]

Архитектура

HDFS имеет архитектуру master/slave. Кластер HDFS состоит из одного NameNode, главного сервера, который управляет пространством имен файловой системы и регулирует доступ к файлам клиентами. Кроме того, существует несколько DataNodes, обычно по одному на узел в кластере, которые управляют хранилищем, прикрепленные к узлам, на которых они запускаются. HDFS предоставляет пространство имен файловой системы и позволяет сохранять пользовательские данные в файлах. Внутри файл разбивается на один или несколько блоков, и эти блоки хранятся в наборе DataNodes. NameNode выполняет операции с пространством имен файловой системы, такие как открытие, закрытие и переименование файлов и каталогов. Он также определяет отображение блоков в DataNodes. DataNodes отвечают за обслуживание запросов на чтение и запись от клиентов файловой системы. DataNodes также выполняют создание, удаление и репликацию блока по команде из NameNode. Архитектура HDFS изображена на рисунке 1.

Рисунок 1 – Архитектура HDFS


Существование единого NameNode в кластере значительно упрощает архитектуру системы. NameNode - это арбитр и репозиторий для всех метаданных HDFS. Система разработана таким образом, что пользовательские данные никогда не проходят через NameNode. [Источник 2]

Пространство имен файловой системы

HDFS поддерживает традиционную иерархическую организацию файлов. Пользователь или приложение могут создавать каталоги и хранить файлы в этих каталогах. Иерархия пространства имен файловой системы аналогична большинству других существующих файловых систем; Можно создавать и удалять файлы, перемещать файл из одного каталога в другой или переименовывать файл. HDFS еще не вводит пользовательские квоты. HDFS не поддерживает жесткие ссылки или программные ссылки. Однако архитектура HDFS не препятствует реализации этих функций.

NameNode поддерживает пространство имен файловой системы. Любые изменения в пространстве имен файловой системы или его свойствах регистрируются узлом NameNode. Приложение может указать количество реплик файла, которое должно поддерживаться HDFS. Количество копий файла называется коэффициентом репликации этого файла. Эта информация хранится в NameNode.

Механизм репликации

HDFS предназначен для надежного хранения очень больших файлов на машинах в большом кластере. Он хранит каждый файл в виде последовательности блоков; все блоки в файле, кроме последнего блока, имеют одинаковый размер. Блоки файлов реплицируются для отказоустойчивости. Размер блока и коэффициент репликации настраиваются для каждого файла. Приложение может указывать количество реплик файла. Коэффициент репликации может быть указан во время создания файла и может быть изменен позже. Файлы в HDFS записываются один раз и имеют строго одного автора в любое время.

NameNode принимает все решения относительно репликации блоков. Он периодически получает Heartbeat и Blockreport от каждого из DataNodes в кластере. Получение Heartbeat подразумевает, что DataNode функционирует должным образом. Blockreport содержит список всех блоков в DataNode. При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:

  • выбор новых DataNode-серверов для новых реплик
  • балансировка размещения данных по DataNode-серверам [Источник 3]

Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.

Размещение реплик имеет решающее значение для надежности и производительности HDFS. Оптимизация размещения реплик отличает HDFS от большинства других распределенных файловых систем. Это функция, которая требует большого количества настроек и опыта. Цель политики размещения реплик в стойке - повысить надежность, доступность и пропускную способность сети.

Большие экземпляры HDFS запускаются на кластере компьютеров, который обычно распространен на многие стойки. Связь между двумя узлами в разных стойках должна проходить через коммутаторы. В большинстве случаев пропускная способность сети между машинами в одной стойке больше, чем пропускная способность сети между машинами в разных стойках.

NameNode определяет идентификатор стойки, к которому принадлежит каждый DataNode, посредством процесса, описанного в Hadoop Rack Awareness. Простая, но неоптимальная политика заключается в размещении реплик на уникальных стойках. Это предотвращает потерю данных при сбое всей стойки и позволяет использовать полосу пропускания с нескольких стоек при чтении данных. Эта политика равномерно распределяет реплики в кластере, что упрощает балансировку нагрузки при сбое компонента. Тем не менее, эта политика увеличивает стоимость записи, поскольку запись требует передачи блоков на несколько стоек.

Для общего случая, когда коэффициент репликации равен трем, политика размещения HDFS заключается в том, чтобы поместить одну реплику на один узел в локальную стойку, другую на узел в другой (удаленной) стойке, а последнюю в другой узел в той же дистанционной стойке. Эта политика уменьшает трафик записи между стойками, что в целом повышает производительность записи. Вероятность сбоя в стойке намного меньше, чем отказ узла; эта политика не влияет на надежность и надежность данных. Тем не менее, он уменьшает совокупную пропускную способность сети, используемую при чтении данных, поскольку блок размещен только в двух уникальных стойках, а не в трех. С помощью этой политики реплики файла не равномерно распределяются по стойкам. Одна треть реплик находится на одном узле, две трети реплик находятся на одной стойке, а другая треть равномерно распределена по остальным стойкам. Эта политика повышает производительность записи без ущерба для надежности данных или производительности чтения.

Постоянство метаданных файловой системы

Пространство имен HDFS хранится в NameNode. NameNode использует журнал транзакций, называемый EditLog, для постоянной записи каждого изменения, которое происходит с метаданными файловой системы. Например, создание нового файла в HDFS заставляет NameNode вставить запись в EditLog, указывающую на это. Аналогично, изменение коэффициента репликации файла приводит к вставке новой записи в EditLog. NameNode использует файл в своей локальной файловой системе ОС для хранения EditLog. Все пространство имен файловой системы, включая отображение блоков в файлы и свойства файловой системы, хранится в файле с именем FsImage. FsImage также сохраняется в виде файла в локальной файловой системе NameNode.

NameNode хранит изображение всего пространства имен файловой системы и файла Blockmap в памяти. Этот ключевой элемент метаданных спроектирован так, чтобы быть компактным, так что NameNode с 4 ГБ ОЗУ достаточно для поддержки огромного количества файлов и каталогов. Когда NameNode запускается, он считывает FsImage и EditLog с диска, применяет все транзакции из EditLog к представлению FsImage в памяти и сбрасывает эту новую версию в новый FsImage на диске. Затем он может усечь старый EditLog, потому что его транзакции были применены к постоянному FsImage. Этот процесс называется контрольной точкой. В текущей реализации контрольная точка возникает только при запуске NameNode. Ведется работа по поддержке периодической проверки в ближайшем будущем.

DataNode хранит данные HDFS в файлах в своей локальной файловой системе. DataNode не знает о файлах HDFS. Каждый блок данных HDFS хранится в отдельном файле в локальной файловой системе. DataNode не создает все файлы в одном каталоге. Вместо этого он использует эвристику для определения оптимального количества файлов в каталоге и соответствующим образом создает подкаталоги. Не является оптимальным создание всех локальных файлов в одном каталоге, поскольку локальная файловая система может не иметь возможности эффективно поддерживать огромное количество файлов в одном каталоге. Когда DataNode запускается, он просматривает свою локальную файловую систему, генерирует список всех блоков данных HDFS, которые соответствуют каждому из этих локальных файлов, и отправляет этот отчет в NameNode: это Blockreport.

Организация данных

Блоки данных

HDFS предназначена для поддержки очень больших файлов. Приложения, совместимые с HDFS, - это приложения, работающие с большими наборами данных. Эти приложения записывают свои данные только один раз, но читают их один или несколько раз и требуют, чтобы эти чтения выполнялись со скоростью потоковой передачи. HDFS поддерживает семантику «записал один раз -- прочитал много» для файлов. Типичный размер блока, используемый HDFS, составляет 64 МБ. Таким образом, файл HDFS разбивается на фрагменты по 64 МБ, и, если возможно, каждый блок будет находиться на разных узлах DataNode.

Обработка клиентских запросов

Клиентский запрос на создание файла не сразу достигает NameNode. Фактически изначально клиент HDFS кэширует данные файла во временный локальный файл. Записи приложения прозрачно перенаправляются в этот временный локальный файл. Когда локальный файл накапливает данные стоимостью более одного размера блока HDFS, клиент связывается с NameNode. NameNode вставляет имя файла в иерархию файловой системы и выделяет для него блок данных. NameNode отвечает на запрос клиента идентификатором DataNode и целевым блоком данных. Затем клиент сбрасывает блок данных из локального временного файла в указанный DataNode. Когда файл закрыт, оставшиеся неперезаписанные данные во временном локальном файле передаются в узел данных. Затем клиент сообщает NameNode, что файл закрыт. На этом этапе NameNode фиксирует операцию создания файла в постоянном хранилище. Если NameNode отключается до закрытия файла, файл теряется.

Вышеуказанный подход был принят после тщательного рассмотрения целевых приложений, работающих на HDFS. Эти приложения нуждаются в потоковой записи в файлы. Если клиент пишет в удаленный файл напрямую, без какой-либо буферизации на стороне клиента, скорость сети и перегрузка в сети значительно влияют на пропускную способность. Этот подход не без прецедента. Ранее распределенные файловые системы, например AFS использует кэширование на стороне клиента для повышения производительности. Требование POSIX было смягчено для достижения более высокой производительности загрузки данных.

Конвейерная репликация

Когда клиент записывает данные в файл HDFS, его данные сначала записываются в локальный файл, как описано в предыдущем разделе. Предположим, что файл HDFS имеет коэффициент репликации три. Когда локальный файл накапливает полный блок пользовательских данных, клиент извлекает список узлов данных из узла имен. Этот список содержит узлы данных, в которых будет размещаться реплика этого блока. Затем клиент сбрасывает блок данных в первый DataNode. Первый DataNode начинает получать данные небольшими порциями (4 КБ), записывает каждую часть в свой локальный репозиторий и передает эту часть во второй DataNode в списке. Второй DataNode, в свою очередь, начинает получать каждую часть блока данных, записывает эту часть в свой репозиторий и затем сбрасывает эту часть в третий DataNode. Наконец, третий DataNode записывает данные в свой локальный репозиторий. Таким образом, DataNode может получать данные из предыдущего в конвейере и в то же время пересылать данные следующему в конвейере. Таким образом, данные передаются от одного DataNode к следующему.

Надежность

Основная задача HDFS - надежное хранение данных даже в случае сбоев. Наиболее распространены три типа сбоев: сбои NameNode, сбои DataNode и сетевые разделы.

Отказ диска данных, heartbeat и повторная репликация

Каждый DataNode периодически отправляет сообщение Heartbeat в NameNode. Сетевой раздел может привести к тому, что подмножество DataNode теряет связь с NameNode. NameNode обнаруживает это состояние по отсутствию сообщения Heartbeat. NameNode помечает узлы данных без недавних сообщений как мертвые и не пересылает им новые запросы ввода-вывода. Любые данные, которые были зарегистрированы на мертвом DataNode, больше не доступны для HDFS. Сбой DataNode может привести к тому, что коэффициент репликации некоторых блоков упадет ниже заданного значения. NameNode постоянно отслеживает, какие блоки должны быть реплицированы, и инициирует репликацию при необходимости. Необходимость повторной репликации может возникнуть по многим причинам: узел данных может стать недоступным, реплика может быть повреждена, жесткий диск на узле данных может выйти из строя или коэффициент репликации файла может быть увеличен.

Перебалансировка кластеров

Архитектура HDFS совместима со схемами перебалансировки данных. Схема может автоматически перемещать данные из одного DataNode в другой, если свободное пространство в DataNode падает ниже определенного порога. В случае внезапного высокого спроса на конкретный файл схема может динамически создавать дополнительные реплики и перебалансировать другие данные в кластере. Эти типы схем перебалансировки данных еще не реализованы.

Целостность данных

Возможно, что блок данных, извлеченный из DataNode, прибывает поврежденным. Это повреждение может происходить из-за сбоев в устройстве хранения данных, сбоев сети или ошибок программного обеспечения. Клиентское программное обеспечение HDFS осуществляет проверку контрольной суммы содержимого файлов HDFS. Когда клиент создает файл HDFS, он вычисляет контрольную сумму каждого блока файла и сохраняет эти контрольные суммы в отдельном скрытом файле в том же пространстве имен HDFS. Когда клиент получает содержимое файла, он проверяет, соответствуют ли данные, полученные им от каждого узла данных, контрольной сумме, хранящейся в соответствующем файле контрольной суммы. Если нет, то клиент может выбрать получение этого блока из другого DataNode, который имеет реплику этого блока.

Ошибка метаданных на диске

FsImage и EditLog являются центральными структурами данных HDFS. Повреждение этих файлов может привести к неработоспособности экземпляра HDFS. По этой причине NameNode может быть настроен для поддержки нескольких копий FsImage и EditLog. Любое обновление FsImage или EditLog приводит к тому, что каждый из FsImages и EditLogs обновляется синхронно. Это синхронное обновление нескольких копий FsImage и EditLog может снизить скорость транзакций в секунду, поддерживаемую NameNode. Однако это ухудшение допустимо, поскольку, хотя приложения HDFS по своей природе очень интенсивно используют данные, они не требуют интенсивного использования метаданных. Когда NameNode перезапускается, он выбирает последний совместимый FsImage и EditLog для использования.

Машина NameNode является единственной точкой отказа для кластера HDFS. Если машина NameNode выходит из строя, необходимо ручное вмешательство. В настоящее время автоматический перезапуск и аварийное переключение программного обеспечения NameNode на другой компьютер не поддерживается.

Источники

  1. Apache Hadoop // Wikipedia [2008-2019]. Дата обновления: 30.10.2018. URL: https://ru.wikipedia.org/wiki/Hadoop (Дата обращения 24.12.2018)
  2. HDFS Architecture Guide // Apache Hadoop [2008-2019]. Дата обновления: 09.07.2018. URL: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html (Дата обращения: 26.12.2018)
  3. Hadoop Distributed File System // Habrahabr [2008-2019]. Дата обновления: 21.10.2008. URL:https://habr.com/post/42858/ (Дата обращения: 07.10.2018)