Основные сведения и эволюция архитектуры HDFS

предисловие

Перехват шаринга планеты знаний тоже является дополнением к предыдущей HDFS, кстати пусть все пересматривают

Первые две статьи HDFS находятся здесь:

Погрузитесь в бездну больших данных (1) --- основные понятия HDFS

Перенесем вас в бездну больших данных (2) --- Процесс чтения и записи HDFS и некоторые важные стратегии

Content

Децентрализованное хранилище, резервное хранилище

Я могу расширить эти два момента.Прежде всего, нам должно быть ясно, что данные в HDFS делятся нареальные данныеиметаданныеВо-вторых, конечно, метаданные находятся в Namenode, а реальные данные хранятся в Datanode.

Например, сейчас мы хотим хранить большой файл, децентрализованное хранилище означает, что файл будет разбит на блоки данных один за другим, и они будут храниться независимо в определенном Datanode. Тогда возникает вопрос, как узнать, какой файл из каких блоков данных состоит? И на каких узлах данных существуют эти блоки данных? Вот где появляются метаданные.

Хранилище метаданных фактически хранится как в памяти, так и на диске.Основным соображением при хранении в памяти является повышение скорости отклика, а хранение на диске — обеспечение безопасности метаданных. Проблема, к которой это приводит, заключается в следующем: как обеспечить согласованность данных между памятью и диском? В этом разделе вы можете изучить практику Redis, которая обеспечивает как эффективность, так и безопасность.

И почему сказано, что HDFS не подходит для хранения мелких файлов, или даже что у нас будет механизм слияния многих мелких файлов, то есть потому, что метаданные - это не кусок метаданных для файла, а каждый блок данных будет иметь соответствующее описание метаданных. , а размер метаданных каждого блока данных составляет около 150 байт. Например, мы храним 100 М видео в HDFS, что соответствует 150 байтам метаданных. Если мы храним 100 1 М изображений, будет 100 соответствующих 150 байт. Метаданные, так что трата этого ресурса очень ужасна.

А избыточное хранилище означает, что наш блок будет иметь механизм копирования, а процедура хранения этой копии — стратегия хранения в стойке.

стратегия стеллажного хранения

В самом компьютерном зале будут стойки, и в каждой стойке будет несколько серверов. Вообще говоря, мы будем хранить 3 копии блока следующим образом:

1. Первая копия хранится в стойке A, а вторая копия хранится на сервере в другой стойке (например, в стойке B), чем блок

2. При сохранении второй копии копия сначала будет храниться в другой стойке.Это необходимо для предотвращения сбоя питания в одной стойке.Если копия также хранится на другом сервере в той же стойке, данные могут быть сохранены в этом время потеряно.

3. Третья копия хранится на другом сервере в стойке B (обратите внимание, что копии 2 и 3 хранятся в стойке B).

Почему сделан этот выбор, потому что, если мы поместим реплику 3 на другую стойку C, связь между репликой 2 и репликой 3 требует, чтобы реплика 2 контактировала с главным коммутатором через свой коммутатор, а затем главный коммутатор связывался со стойкой Коммутатор C должен пройти очень длинный маршрут, а ресурсы пропускной способности в компьютерном зале очень ценны. Если он находится в ситуации с высоким параллелизмом, легко заполнить пропускную способность компьютерного зала. В это время скорость отклика резко упадет весь кластер.Будут проблемы с сервисом.

Конечно, количество реплик можно увеличить и вручную с помощью команд.Когда клиентского трафика много, нагрузку можно распределить соответствующим образом.

$ hadoop fs -setrep -R 4 path + FileName

На самом деле setrep означает установку репликации, аббревиатуру для установки количества копий.Приведенная выше команда устанавливает количество копий равным 4, за которыми следует путь к файлу и имя файла.

Взаимодействие клиента — это все, что связано с Namenode, то же самое, что и Кафка, который всегда имеет дело с лидером, а не с последователем. Но вы должны знать, что нормальная функция загрузки и выгрузки данных действительно собирается в Datanode.

Архитектура HDFS

Архитектура HDFS: архитектура master-slave, три роли

1. Как лидер кластера Namenode отвечает за метаданные файловой системы HDFS, обработку клиентских запросов на чтение и запись, безопасность данных и балансировку нагрузки внутри кластера HDFS и т. д.
2. Datanode хранит все блоки данных всего кластера и обрабатывает реальные данные чтения и записи.
3. SecondaryNamenode не является строго резервным узлом namenode. Его основная функция — распределять нагрузку на namenode и снижать нагрузку (слияние журнала редактирования метаданных, то есть журнал редактирования).

Механизм сердцебиения

Механизм пульса решает проблему связи между кластерами HDFS и позволяет узлу NameNode инструктировать узел данных о выполнении операций.

1. После запуска master namenode будет открыт сервер ipc.
2. DataNode запускается, подключается к NameNode, каждые 3 секунды отправляет пульс на NameNode и передает информацию о состоянии.
3. NameNode передает инструкции задачи в DataNode через возвращаемое значение этого пульса.

Роль механизма сердцебиения:

1. Узел NameNode полностью управляет репликацией блоков данных.Он периодически получает сигналы сердцебиения и отчеты о состоянии блоков от каждого узла данных в кластере.Получение сигнала сердцебиения означает, что узел DataNode работает нормально, а отчет о состоянии блока содержит все данные в списке блоков DataNode.

2. DataNode регистрируется в NameNode при запуске и периодически сообщает об отчете о блоке NameNode после его передачи, посылает пульс на NameNode каждые 3 секунды, и NameNode возвращает инструкции DataNode, такие как копирование блока данных в другая машина, или удаление его.Определенный блок данных и т. д. И когда DataNode не отправляет пульс на NameNode более 10 минут, NameNode определит, что DataNode недоступен, и чтение и запись клиента операции не будут передаваться в DataNode.

безопасный режим

3. При запуске кластера хауп он переходит в безопасный режим (99,99%), и используется механизм сердцебиения.По сути, когда кластер только запущен, каждый DataNode будет отправлять отчет о блоке в NameNode, а NameNode подсчитает общее количество блоков, о которых сообщает их число, разделенное на общее число, известное в начале, когда блок/всего

И, чтобы добавить, формула расчета восприятия Namenode времени смерти Datanode в автономном режиме выглядит следующим образом:

timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval

Тайм-аут HDFS по умолчанию составляет 630 секунд, потому что значение по умолчанию heartbeat.recheck.interval составляет 5 минут, а dfs.heartbeat.interval — 3 секунды, и эти два параметра легко понять, один — интервал повторной проверки, другой — параметр. отправлять сердцебиение каждые n секунд, ждать 10 раз и не может его отключить.

Дополнение к безопасному режиму

Безопасный режим — это не только когда кластер только запущен и ждет, пока все узлы данных сообщат об этой ситуации, он перейдет в безопасный режим, но и когда потеря блока данных HDFS достигнет определенной пропорции, он также автоматически перейдет в безопасный режим. , Конечно, мы также можем вручную войти в безопасный режим модели. По умолчанию этот коэффициент составляет 0,1%, и теряется 1000 блоков, что уже является серьезным событием.

Вы можете использовать start-balancer.sh, чтобы заставить HDFS выполнять балансировку нагрузки, но следует отметить, что с этой командой есть определенные проблемы, которая аналогична System.gc() в механизме сборки мусора Java. Говорю вам, сейчас пришло время для сборки мусора, но JVM нас просто игнорирует, почему? Он выполняет сборку мусора только тогда, когда он свободен и в нужное время, и start-balancer.sh — это та же процедура, использующая для этого оставшуюся полосу пропускания.

И эта операция тоже имеет некий эталон, по числовому значению n. Каждый узел вычисляет занятость диска, наибольшая занятость - наименьшая занятость = это стандартное значение n. Значение по умолчанию равно 10%, что легко понять. И эта операция балансировки нагрузки не должна влиять на службы чтения и записи клиента, поэтому HDFS не позволит операции балансировки по умолчанию занимать слишком много полосы пропускания. Но мы можем внести ручные корректировки

hdfs dfs admin -setBalancerBandwidth newbandwidth

Единица измерения newbandwidth по умолчанию — байты, так что эту вещь можно настроить в соответствии с вашими потребностями. По умолчанию 1M в секунду.

Дефекты и эволюция HDFS

Когда версия Hadoop1 была впервые выпущена, она была разработана для решения двух проблем: одна — как хранить массивные данные, а другая — как вычислять массивные данные.

Работа Namenode:

1. Управление информацией о метаданных кластера (дерево каталогов файлов): можно просто понять, что файл разделен на несколько блоков и где эти блоки хранятся.
2. Чтобы быстро реагировать на запросы пользователей об операциях, Namenode загружает метаданные в память.

Работа датанода:

1. Сохраните данные, разделите загруженные данные на блоки файлов фиксированного размера, по умолчанию для hadoop1 установлено значение 64, а затем 128M.

2. В целях обеспечения безопасности данных каждый файловый блок по умолчанию имеет три копии.Три копии здесь на самом деле означают всего 3, а не 4 оригинальных 3 резервных копии.

Архитектурные недостатки в HDFS1

1. Проблема единой точки отказа: Namenode зависает в кластере, и это бесполезно
2. Проблема ограниченной памяти: когда информация метаданных Namenode разрывает память, весь кластер парализован.

Решение QJM решает проблему единой точки отказа

На самом деле, все еще существует решение для нескольких Namenodes для совместного использования общего каталога, но также будут проблемы с общим каталогом, поэтому он не может соответствовать нашим требованиям.

Решение QJM следующее: мы строим отдельный кластер JournalNode, а затем используем их для решения проблемы единой точки отказа.Данные между JournalNodes непротиворечивы.Когда наш основной Namenode, то есть активный Namenode, изменяет метаданных, он изменит JournalNode.Выполняется операция записи, а затем резервный Namenode выполняет синхронизацию для достижения согласованности данных между ведущим и подчиненным Namenode.

Но есть еще проблема, то есть нам нужно вручную переключать резерв в актив, поэтому мы ввели Zookeeper для решения этой проблемы.На самом деле есть некоторые предприятия, которые напрямую используют Zookeeper вместо JournalNode, т.к. задача JournalNode для обеспечения согласованности данных этих узлов.Эта функция может быть полностью достигнута с помощью атомарного широковещательного протокола Zookeeper.

В это время в Zookeeper создается каталог блокировки, а затем NameNode захватит блокировку при запуске.Два NameNode, которые захватят ее первыми, будут в активном состоянии. Кроме того, на каждом NameNode есть служба ZKFC, которая постоянно отслеживает состояние работоспособности NameNode.Если возникает проблема с активным NameNode, ZKFC сообщит об этом Zookeeper, а затем Zookeeper назначит блокировку резервному NameNode. Сделайте так, чтобы он автоматически переключался в активное состояние. На данный момент это архитектура HDFS2.

Рекомендовано JournalNode

Потому что на самом деле задача JournalNode не тяжелая, поэтому нет необходимости в слишком большом кластере.

Ниже 200 узлов ---> 3

200~2000 узлов ---> 5

Федерация устраняет ограничения памяти

Как показано на рисунке выше, это эквивалентно методу горизонтального расширения.Поскольку один Namenode взорвется, несколько Namenode будут нести ответственность за хранение различной информации метаданных. Это похоже на наши диски C, D, E, F, диск C предназначен для хранения некоторых вещей в системе, диск D используется для установки программного обеспечения, а диск E используется для воспроизведения фильмов. И механизм федерации, HDFS автоматически маршрутизирует. Пользователю не нужно заботиться о том, какой namenode используется для хранения.

На этом этапе подводятся небольшие итоги: именные узлы активного+резервного образуют группу, целью которой является обеспечение высокой доступности и предотвращение единой точки отказа. Хотя несколько групп «активный + резервный» образуют федерацию, цель состоит в том, чтобы решить проблему нехватки памяти в одной группе.

Как HDFS управляет метаданными

Помните, когда мы строили кластер, нам нужно было выполнить шаг «форматирования Namenode» перед запуском кластера? Целью этого шага является создание fsimage на диске, который является нашей информацией о каталоге метаданных. Затем эти метаданные загружаются в память.

Как показано на рисунке ниже, если клиент хочет загрузить файл в это время, он будет взаимодействовать с fsimage в памяти, добавит часть метаданных, и эта операция будет записана в журнал редактирования, так как имя предполагает, что это журнал редактирования. Изображение fsimage на диске в это время все еще является первым, в отличие от изображения fsimage в памяти, которое меняется в любое время. В настоящее время

内存fsimage = 磁盘fsimage + edit log 

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

В настоящее время представлен SecondaryNamenode, и его функция заключается в повышении скорости восстановления Namenode и примерном объяснении этапов работы:

1. SecondaryNameNode будет извлекать журнал изменений и информацию fsimage через http get
2. Объединить журнал изменений и fsimage в SecondaryNameNode для создания нового файла с именем

fsimage.ckpt 3. После завершения слияния в SecondaryNameNode оно отправляется обратно в NameNode. 4. В это время велика вероятность того, что клиент все еще читает и пишет в NameNode, а также будут генерироваться новые журналы.В это время можно продолжить по рутине, которая раньше не вводила SNN. В схеме HA это поведение может быть передано резервному серверу для завершения.

Двойной буферный механизм

Метаданные в Namenode хранятся в двух состояниях:

Первое состояние хранится в памяти, это только что упомянутое дерево каталогов, это список, и скорость обновления метаданных в памяти очень высокая. Но если в памяти хранятся только метаданные, данные не очень безопасны.

Итак, мы также храним метаданные на диске, но в этот момент возникает проблема, нам нужно записать данные на диск, и это производительность определенно не очень хорошая. Тем не менее, NameNode, как лидер всего кластера, выполняет такие вычисления, как hive, HBASE, spark и flink на hadoop.Эти данные будут продолжать оказывать давление на NameNode для записи метаданных.Можно записать 100 миллионов штук метаданных за день, поэтому дизайн NameNode должен поддерживать сверхвысокий параллелизм, но операция записи на диск очень, очень медленная, и она ограничена десятками или максимум сотнями в секунду, так что же нам теперь делать?

Во-первых, данные, сгенерированные нашим клиентом (здесь имеются в виду hive, hbase, spark... это не имеет значения) будут проходить через два процесса. Первый процесс будет записывать данные в память.Этот процесс очень быстрый и тоже не сложно понять

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

Механизм двойной буферизации означает, что мы откроем два одинаковых пространства памяти, одно — bufCurrent, сгенерированные данные будут записываться напрямую в этот bufCurrent, а другое — bufReady, где данные записываются в bufCurrent (на самом деле могут быть более одной части данных, после того, как это будет объяснено позже), две части памяти будут заменены. Затем предыдущий bufCurrent отвечает за запись данных на диск, а предыдущий bufReady продолжает принимать данные, записанные клиентом. Фактически, задача записи данных на диск передается фону. Этот подход также полезен в JUC.

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

Finally

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