Пример: распределенная файловая система Hadoop (HDFS)
Модель программирования MapReduce позволяет структурировать вычислительные задания с помощью двух функций: map и reduce. Входные данные передаются в mapReduce как пары "ключ-значение", где затем обрабатываются с помощью функции карты и передаются в функцию уменьшения. Затем операция reduce выдает результат, который также представлен в виде пар "ключ-значение". MapReduce предназначен для выполнения множества экземпляров операций map и reduce параллельно на большом вычислительном кластере. Модель программирования MapReduce подробно рассматривается в одном из следующих модулей.
Модель программирования MapReduce предполагает доступность распределенной системы хранения на всех узлах кластера с одним пространством имен. Для этого и используется распределенная файловая система (DFS). DFS размещена вместе с узлами кластера MapReduce. DFS разработана для совместной работы с MapReduce и поддерживает единое пространство имен для всего кластера MapReduce.
Версия MapReduce с открытым кодом, Apache Hadoop2, очень популярна в сфере больших данных. HDFS — это DFS с открытым кодом. HDFS разработана как распределенная, масштабируемая отказоустойчивая файловая система, которая, в основном, работает с моделью программирования MapReduce. В видеоролике 4.12 представлен обзор HDFS.
Важно отметить, что HDFS не соответствует POSIX и не является подключаемой файловой системой самостоятельно. Доступ к HDFS обычно осуществляется через клиентов HDFS или с помощью вызовов интерфейса прикладного программирования (API) из библиотек Hadoop. Однако разработка File system in User SpacE (FUSE) для (HDFS) позволяет подключить ее как виртуальное устройство в UNIX-подобных операционных системах.
Архитектура HDFS
Как было сказано ранее, HDFS представляет собой систему DFS, предназначенную для работы в кластере узлов и спроектированную для следующих целей:
- единое общее пространство имен на уровне кластера;
- возможность хранения больших файлов (например, на несколько терабайт или петабайт);
- поддержка модели программирования MapReduce;
- потоковый доступ к данным с возможностью однократной записи и многократного чтения;
- высокая доступность с использованием стандартного оборудования.
Кластер HDFS продемонстрирован на следующем снимке экрана:
Рис. 1. Архитектура HDFS
HDFS использует модель "главный-подчиненный". Главный узел называется NameNode. NameNode обрабатывает управление метаданными для всего кластера и поддерживает одно пространство имен для всех файлов, хранящихся в HDFS. Подчиненные узлы называются DataNode. DataNode хранят фактические блоки данных в локальной файловой системе внутри каждого узла.
Файлы в HDFS разбиваются на блоки (также называемые фрагментами) с размером по умолчанию 128 МБ. В локальных файловых системах размер блоков обычно составляет около 4 КБ. HDFS использует большие размеры блоков, так как он предназначен для хранения очень больших файлов таким образом, чтобы эффективно обрабатывать задания MapReduce.
Одна задача map в MapReduce настроена по умолчанию для работы с одним блоком HDFS независимо от остальных, поэтому несколько задач map могут параллельно обрабатывать несколько блоков HDFS. Если размер блока слишком мал, необходимо распределить большое количество задач карты по узлам кластера, а затраты на это могут негативно повлиять на производительность. С другой стороны, если блок слишком велик, число задач map, которые могут обрабатывать файл параллельно, сокращается, что влияет на параллелизм. HDFS позволяет задавать размеры блоков для отдельных файлов, поэтому пользователи могут настраивать размер блока для достижения необходимого уровня параллелизма. Взаимодействие MapReduce с HDFS подробно рассматривается в одном из следующих модулей.
Кроме того, так как HDFS рассчитан на отказ отдельных узлов, блоки данных реплицируются между узлами для обеспечения избыточности данных. Этот процесс описан в следующих разделах.
Топология кластера в HDFS
Кластеры Hadoop обычно развертываются в центре обработки данных, который состоит из нескольких стоек серверов, подключенных с помощью топологии утолщенного дерева, как описано в одном из предыдущих модулей. Для этого HDFS разработан с учетом осведомленности о топологии кластера, что помогает принимать решения о блок-размещении, чтобы повлиять на производительность и отказоустойчивость. Обычные кластеры Hadoop имеют от 30 до 40 серверов на стойку с выделенным гигабитным коммутатором для каждой стойки и каналом исходящей связи к основному коммутатору или маршрутизатору, пропускная способность которого совместно используется множеством стоек в центре обработки данных, как показано на следующем рисунке:
Рис. 2. Топология кластера HDFS
Обратите внимание, что в Hadoop предполагается, что суммарная пропускная способность узлов в стойке выше, чем суммарная пропускная способность между узлами в разных стойках. Это предположение встроено в структуру Hadoop и связано с доступом к данным и размещением реплик (рассматривается в следующих разделах).
При развертывании HDFS в кластере системные администраторы могут настроить его с помощью описания топологии, которое сопоставляет каждый узел с определенной стойкой в кластере. Расстояние по сети измеряется в прыжках, где один прыжок соответствует одному каналу в топологии. В Hadoop предполагается топология в стиле дерева, а расстояние между двумя узлами — сумма расстояний до ближайшего общего предка.
В примере на рис. 2 расстояние между узлом 1 и им самим равно нулю (случай, когда два процесса обмениваются данными на одном узле). Расстояние между узлом 1 и узлом 2 равно двум прыжкам, а расстояние между узлом 3 и узлом 4 — четырем.
В следующем видео рассматриваются операции чтения и записи файлов в HDFS.
Рис. 3. Чтение файлов в HDFS
На рис. 3 показан процесс чтения файла в HDFS. Клиент HDFS (сущность, которой требуется доступ к файлу) сначала связывается с NameNode при открытии файла для чтения. Затем NameNode предоставляет клиенту список блочных расположений файла. В Hadoop также предполагается, что блоки реплицируются между узлами, поэтому NameNode фактически находит ближайший блок на клиенте при предоставлении расположения определенного блока. Локальность определяется в следующем порядке (по убыванию): блоки в пределах одного узла с клиентом, блоки в той же стойке, что и клиент, и блоки в другой стойке.
После определения расположения блоков клиент откроет прямое подключение к каждому узлу DataNode и передаст потоком данные из DataNode в клиентский процесс, который выполняется, когда клиент HDFS вызывает операцию чтения для блока данных. Таким образом, блок не должен быть передан полностью, прежде чем клиент сможет начать вычисления, тем самым переключив вычисления и обмен данными. После завершения чтения первого блока клиент повторяет этот процесс с оставшимися блоками, пока клиент не завершит чтение всех блоков, а затем переходит к закрытию файла.
Важно отметить, что клиенты напрямую обращаются к DataNode, чтобы получить данные. Этот контакт позволяет HDFS масштабироваться на большое количество одновременных клиентов для одновременного параллельного чтения данных.
Операции записи файлов в HDFS отличаются от операций чтения (рис. 4). Клиент, которому требуется записать данные в HDFS, сначала связывается с NameNode, а затем уведомляет его о создании файла. NameNode проверяет, существует ли файл и есть ли у клиента разрешения на создание файла. Если проверки пройдены, NameNode создает запись нового файла.
Рис. 4. Запись файлов в HDFS
Затем клиент переходит к записи файла во внутреннюю очередь данных и запрашивает у NameNode расположение блоков на DataNode в кластере. Затем блоки во внутренней очереди передаются в отдельные DataNode в конвейере. Блок записывается на первый DataNode, который затем в виде конвейера передает блок другим DataNode для записи реплик блока. Таким образом блоки реплицируются во время самой записи файла. Важно отметить, что HDFS не признает запись в клиент (шаг 5 на рис. 4.28), пока все реплики этого файла не были написаны DataNodes.
В Hadoop также используется понятие расположения стойки во время размещения реплики. По умолчанию блоки данных в HDFS проходят тройную репликацию. HDFS пытается разместить первую реплику на том же узле, что и клиент, который записывает блок. Если клиентский процесс не выполняется в кластере HDFS, узел выбирается случайным образом. Вторая реплика записывается на узел, который находится в другой стойке. Третья реплика блока записывается на другой случайный узел в той же стойке, что и второй. Последующие реплики записываются на случайные узлы в кластере, но система пытается избежать размещения слишком большого количества реплик в одной стойке. На рис. 5 показано размещение реплики для блока с тройной репликацией в HDFS. Идея размещения реплик HDFS заключается в возможности допускать сбои узлов и стоек. Например, когда вся стойка отключается от сети из-за проблем с питанием или сетью, запрошенный блок по-прежнему можно найти в другой стойке.
Рис. 5. Размещение реплики для трехреплицированного блока в HDFS
Синхронизация: семантика
Семантика HDFS немного изменилась. Ранние версии HDFS использовали неизменяемую семантику. В более ранних версиях HDFS уже записанный файл нельзя было повторно открыть для записи. Но файлы можно было удалять. Текущие версии HDFS поддерживают ограниченное добавление. Это по-прежнему довольно ограничено в том смысле, что существующие двоичные данные после записи в HDFS не могут быть изменены на месте.
Это решение в HDFS был принято потому, что некоторые из наиболее распространенных рабочих нагрузок MapReduce используют шаблон однократной записи и многократного чтения для доступа к данным. MapReduce — это ограниченная вычислительная модель с предопределенными этапами, а выходные данные функций reduce в MapReduce записывают независимые файлы в HDFS в качестве выходных данных. HDFS фокусируется на одновременном и быстром доступе на чтение для нескольких клиентов сразу.
Модель согласованности
HDFS — это строго согласованная файловая система. Каждый блок данных реплицируется на несколько узлов, но запись объявляется успешной только после того, как все реплики были успешно записаны. Поэтому все клиенты должны видеть файл сразу после записи файла, а представление файла на всех клиентах совпадает. Неизменяемая семантика HDFS позволяет относительно просто реализовать этот принцип, поскольку файл можно открыть для записи только один раз в течение его времени существования.
Отказоустойчивость в HDFS
Основной механизм отказоустойчивости в HDFS — репликация. Как уже упоминалось ранее, по умолчанию каждый блок, записанный в HDFS, реплицируется три раза, но при необходимости пользователи могут изменить этот параметр для каждого файла.
NameNode отслеживает DataNode с помощью пакетов пульса. Каждый DataNode передает периодические сообщения с пакетами пульса (каждые несколько секунд) в NameNode. Если DataNode завершается, пакеты пульса в NameNode останавливаются. NameNode обнаруживает, что DataNode умер, если число пропущенных сообщений пульса достигает определенного порога. Затем NameNode помечает DataNode как неработающий и перестает пересылать запросы ввода-вывода к этому узлу. Блоки, хранящиеся на этом DataNode, должны иметь дополнительные реплики на других узлах. Кроме того, NameNode проверяет состояние файловой системы, чтобы обнаруживать нереплицированные блоки, и выполнит повторное распределение кластера, чтобы инициировать репликацию для блоков, у которых меньше требуемого числа реплик.
NameNode — это одна точка сбоя (SPOF) в HDFS, так как сбой NameNode приводит ко всей файловой системе вниз. На внутреннем уровне NameNode поддерживает две структуры данных на диске, в которых хранится состояние файловой системы: файл образа и журнал изменений. Файл образа представляет собой контрольную точку для метаданных файловой системы в определенный момент времени, а журнал изменений — журнал всех транзакций с метаданными файловой системы с момента последнего создания файла образа. Все входящие изменения в метаданных файловой системы записываются в журнал изменений. Через периодические интервалы журналы редактирования и файл изображения объединяются для создания моментального снимка файла изображения, а журнал редактирования очищается. Однако при сбое NameNode метаданные будут недоступны, и сбой диска в NameNode будет катастрофическим, так как метаданные файла будут потеряны.
Чтобы создать резервную копию метаданных в NameNode, HDFS позволяет создать вторичный NameNode, который периодически копирует файлы образов из NameNode. Эти копии помогают восстановить файловую систему в случае потери данных в NameNode, но последние несколько изменений, которые были в журнале редактирования NameNode, будут потеряны. Непрерывная работа над последними версиями Hadoop нацелена на создание избыточного вторичного NameNode, который автоматически активируется в случае сбоя NameNode.
HDFS на практике
Хотя HDFS, в основном, разрабатывался для поддержки заданий Hadoop MapReduce, предоставляя DFS для операций map и reduce, он подходит для множества применений с инструментами работы с большими данными.
HDFS используется в нескольких проектах Apache, которые создаются на основе платформы Hadoop, включая Pig, Hive, HBase и Giraph. Поддержка HDFS также включена в другие проекты, например GraphLab.
Основные преимущества HDFS:
- Высокая пропускная способность для рабочих нагрузок MapReduce. В больших кластерах Hadoop (с тысячами компьютеров) с помощью HDFS постоянно записывается до 1 терабайта в секунду.
- Высокая надежность: отказоустойчивость является основной целью разработки в HDFS. Репликация HDFS обеспечивает высокую надежность и доступность, особенно в больших кластерах, в которых вероятность сбоев дисков и серверов значительно возрастает.
- Низкие затраты на байт: по сравнению с выделенным решением общего диска, например SAN, HDFS стоит меньше за гигабайт, так как хранилище сопоставляется с вычислительными серверами. При использовании сети SAN необходимо оплачивать дополнительные затраты на управляемую инфраструктуру, например корпус дискового массива и корпоративные диски более высокого уровня, для управления сбоями оборудования. HDFS предназначен для работы со стандартным оборудованием, а избыточность осуществляется программными средствами.
- Масштабируемость: HDFS позволяет добавлять DataNodes в запущенный кластер и предлагает средства для ручного перебалансирования блоков данных при добавлении узлов кластера, которые можно сделать без отключения файловой системы.
Основные недостатки HDFS:
- Небольшие неэффективные файлы: HDFS предназначено для использования с большими размерами блоков (64 МБ и больше). Он должен принимать большие файлы (сотни мегабайтов, гигабайтов или терабайтов) и блокировать их в блоки, которые затем можно отправлять в задания MapReduce для параллельной обработки. HDFS неэффективен, если фактический размер файлов невелик (измеряется в килобайтах). Наличие большого количества небольших файлов накладывает дополнительную нагрузку на NameNode, который должен поддерживать метаданные для всех файлов в файловой системе. Как правило, пользователи HDFS объединяют множество небольших файлов в более крупные, используя такие методы, как последовательные файлы.
- Несоответствие POSIX: HDFS не был разработан, чтобы быть совместимой с POSIX, подключаемой файловой системой; приложения должны быть написаны с нуля или изменены для использования клиента HDFS. Существуют обходные пути, позволяющие подключать HDFS с помощью драйвера FUSE, но семантика файловой системы не разрешает запись в файлы после закрытия.
- Модель записи после записи: модель записи один раз является потенциальным недостатком для приложений, которым требуется одновременный доступ на запись в тот же файл. Однако последняя версия HDFS теперь поддерживает добавление файлов.
Короче говоря, HDFS является хорошим вариантом в качестве серверной части хранилища для распределенных приложений, которые следуют модели MapReduce или были специально записаны для использования HDFS. HDFS может эффективно использоваться с небольшим количеством больших файлов, а не с большим количеством небольших файлов.
Ссылки
- Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung (2003). The Google File Systems 19th ACM Symposium on Operating Systems Principles
- White, Tom (2012). Hadoop: The Definitive Guide O'Reilly Media, Yahoo Press