Понимание того, как работает HDFS (распределенная файловая система Hadoop), очень важно для решения любой проблемы с большими данными. HDFS - это файловая система на основе Java, которая обеспечивает масштабируемое и надежное хранилище данных, построенное на больших кластерах с очень дешевыми и ненадежными машинами. Он следует архитектуре «главный / подчиненный», в которой мастер или Namenode хранит метаданные, а подчиненные устройства или Datanode хранят фактические данные. HDFS построен с использованием языка Java; любая машина, поддерживающая Java, может запускать программное обеспечение Namenode или Datanode.
HDFS больше предназначен для пакетной обработки, а не для интерактивных результатов данных в реальном времени. Он больше ориентирован на высокую пропускную способность ввода, а не на малую задержку вывода.
HDFS обычно имеет один главный узел, который хранит метаданные, разрешения доступа, информацию о разделах и информацию обо всех блоках, содержащихся в узле данных, в то время как узлы данных хранят основные данные. Несмотря на то, что HDFS построена на дешевых, ненадежных машинах, вся система становится отказоустойчивой из-за репликации данных. Каждый блок данных присутствует на нескольких узлах данных (обычно 3), информация о которых сохраняется с именем узла. Следовательно, всякий раз, когда узел выходит из строя, очень маловероятно, что данные будут потеряны. Он работает по тому же принципу, что и Cassandra, то есть система в конечном итоге станет согласованной.
HDFS разработана для обеспечения высокой отказоустойчивости. Каждый файл в HDFS сохраняется в виде последовательности блоков, при этом каждый блок реплицируется на нескольких машинах. Размер блока и коэффициент репликации настраиваются. Благодаря своей конструкции он больше подходит для однократной записи и многократного чтения. Не рекомендуется обновлять какие-либо данные в HDFS, поскольку распространение обновленного значения на несколько узлов может занять одно и то же время, и, следовательно, система может привести к несогласованности.
Каждый узел данных периодически отправляет импульсный сигнал на узел имени, сигнализируя о том, что он все еще жив. Обычно существует настраиваемое пороговое время, по истечении которого именной узел может предположить, что машина не работает, и убедиться, что ни один из запросов не направлен на этот узел в последующих запросах чтения / записи. Вплоть до Hadoop 1 namenode был единственной точкой отказа для HDFS, то есть вся система выйдет из строя, если namenode выйдет из строя. Эта проблема была решена в Hadoop 2, где пользователь может настроить несколько узлов имен, каждый из которых имеет одну и ту же копию данных. Это было поддержано машиной с очень высокой доступностью, обычно Zookepper, на которую все узлы имен отправляют сердцебиение. Чем больше количество именных узлов, тем медленнее будут запросы, поскольку запись данных на именном узле должна будет распространяться по всем именным узлам.
Запрос на запись в HDFS проходит примерно так: пользователь передает файл размером 150 МБ на главный узел. Предположим, что для block_size установлено значение 64 МБ (это значение по умолчанию), а для replication_factor установлено значение 3. Также предположим, что имеется 10 узлов данных и 1 Namenode. Когда файл передается в namenode, он разбивает его на 3 блока: два по 64 МБ и один по 22 МБ (64 МБ + 64 МБ + 22 = 150 МБ). Главный узел будет запускать 3 рабочих (при условии, что максимальный предел количества рабочих установлен на что-то большее, чем 3), каждый из которых пойдет и запишет данные на три узла данных (рабочие могут в конечном итоге записать данные на одном узле данных. слишком). Предположим, что блок 1 был записан на узел данных 1, блок 2 был записан на узел данных 2, а блок 3 был записан на узел данных 1. Эта информация будет храниться в namenode, указывая, что файл xyz имеет 3 блока, каждый из которых сохраняется в datanode 1,2,1 соответственно. Пользователь получит уведомление о том, что его запись была успешной, и его данные теперь хранятся в HDFS. Между тем, три воркера начнут реплицировать эти блоки на разных узлах данных replication_factor количество раз и обновят namenode о его местонахождении.
Общий запрос на чтение выглядит примерно так: пользователь отправляет запрос на чтение некоторого файла xyz в namenode. Namenode по своим метаданным проверяет, сколько блоков присутствует в этом файле и на каком узле данных они присутствуют. Затем он запускает некоторое оптимальное количество воркеров, чтобы получить эти блоки, гарантируя, что ни один из воркеров не будет отправлен на узел данных, который прекратил посылать свое контрольное сообщение. Как только все блоки присутствуют в namenode, он размещает их в правильном порядке и возвращает пользователю.
Обратите внимание, что редко бывает, чтобы кто-то использовал HDFS только для хранения данных. Вычислительный блок, то есть Map-Reduce или Spark или Presto, обычно присутствует вместе с HDFS для выполнения некоторых вычислений / обработки данных и сохранения результата. HDFS - это просто система хранения данных, и у нее нет функционирующего механизма. Вся описанная выше логика является общей работой того, как обычно распространяются данные. HDFS также можно использовать с другим алгоритмом чтения и записи данных.
