предисловие
Мы уже обновили zookeeper для серии high concurrency, начиная с нуля, кстати, предыдущий zookeeper не объяснил это в сочетании с большими данными. С одной стороны, я всегда хотел найти повод обобщить большие данные, с другой стороны, это уловить веяние времени, ведь это тоже для себя, так что начнем без глупостей.
Инструкции по чтению
Это похоже на учебную заметку, но у нее определенно есть начало и конец. В ней будет использоваться самый ясный язык для описания пунктов знаний. Я надеюсь, что каждый может что-то получить.
Ключевой момент: в больших данных слишком много концептуальных проблем, поэтому статья не будет нагромождать код как раньше, а больше будет объяснять концепцию
Если у вас есть большие данные, вы должны смотреть на команды и журналы!
Ссылки на бывших зоопарков (только для Java)
Высокий параллелизм с нуля (1) --- основная концепция Zookeeper
Высокий параллелизм с нуля (2) --- Zookeeper реализует распределенные блокировки
Высокий параллелизм с нуля (3) --- Создание кластера Zookeeper и выбор лидера
Высокий параллелизм с нуля (4) --- распределенная очередь Zookeeper
Высокий параллелизм с нуля (5) --- Приложение центра конфигурации Zookeeper
Высокий параллелизм с нуля (6) --- Выборы мастера Zookeeper и краткий обзор его официального сайта
Во-первых, концепция HDFS
Давайте сначала кратко пробежимся по основным понятиям, хотя бы будем знать, что говорить дальше и для чего используется эта штука
1.1 Архитектура Hadoop
HDFS (распределенная файловая система Hadoop) состоит из 3 модулей: распределенное хранилище HDFS, распределенные вычисления MapReduce, структура планирования ресурсов Yarn.
Большое количество файлов можно распределять и хранить на разных серверах
Один файл относительно большой и не может поместиться на одном диске, его можно разделить на множество небольших блоков и хранить на разных серверах, каждый сервер соединен через сеть, образуя единое целое.
1.2 Основной концептуальный блок
Файлы на HDFS3.x будут разделены на блоки по единице 128M, и они будут разбросаны и сохранены на разных узлах данных кластера.Следует отметить, что эта операция выполняется HDFS автоматически.
Предположим, мы хотим сохранить файл размером 300 МБ, эти 300 МБ будут разделены на
datanode1：128M + datanode2：128M + datanode3：44M
В настоящее время нам нужно знать, что даже если его базовая логика будет разделена на 128 МБ, блок datanode3, который фактически занимает 44 МБ, не будет занимать 128 МБ.
1.3 Копия блока
Почему Hadoop так популярен сегодня, так это то, что его первоначальный дизайн может быть развернут на коммерческих серверах, а мы знаем, что коммерческие серверы очень дешевы, и такие дешевые серверы подвержены сбоям, таким как ЦП, память ввода-вывода и т. д. могут вызвать проблемы
Согласно тому, что мы только что сказали в 1.2, файл делится на 3 блока и хранится на разных узлах данных.Если один из узлов данных зависнет, файл не будет найден, поэтому хауп до сих пор не знает, как получить каждый из наших узлов данных. datanodes?Создается копия блока данных для обеспечения достоверности данных
Количество копий можно установить самостоятельно вручную, обычно 3 копии
hdfs-site.xml
<configuration>
<property>
<name>dfs.replication</name>
<value>3</value>
</property>
</configuration>
Хорошо видно, что значение value равно 3, а количество копий у нас равно 3.
Подобно тому, как мы узнаем, что делают эти свойства, вофициальный сайт хаупЕго можно посмотреть на используемой здесь версии 2.7.3. Нажмите на официальный документ и потяните в нижнюю часть левой боковой панели, чтобы увидеть элемент конфигурации.
Конечно, нам нужно найти правильный файл: hdfs-default.xml для содержимого HDFS, mapred-default.xml для MapReduce и yarn-default.xml для пряжи.
Нажмите hdfs-default.xml, вы можете нажать ctrl+f для поиска, введите dfs.replication и нажмите Enter
Здесь мы видим, что значение по умолчанию для dfs.replication равно 3, следующее описание параметра говорит о репликации блока по умолчанию, а следующий параметр dfs.replication.max означает, что максимальное количество реплик может быть установлено на 512.
Также в основном концептуальном блоке 1.2 упомянутый размер блока составляет 128 МБ, который также можно найти в этом файле.
Таким образом, размер каждого блока данных также может быть установлен независимо.
1.3.1 Политика хранения в стойке
В самом компьютерном зале будетРамка, в каждой стойке будет несколько серверов
Вообще говоря, мы будем хранить 3 копии блока следующим образом:
第一个副本就存储在一个机架A上
第二个副本存储在和这个block块不同机架（比如机架B）的一个服务器上
Когда мы сохраняем вторую копию, мы сначала будем хранить копию в другой стойке.Это необходимо для предотвращения сбоя питания в одной стойке.Если копия также хранится на другом сервере в той же стойке, данные могут быть потерял.
第三个副本存储在机架B的另外一个服务器上（注意副本2,3都存储在了机架B）
Почему сделан этот выбор, потому что, если мы поместим реплику 3 на другую стойку C, связь между репликой 2 и репликой 3 требует, чтобы реплика 2 контактировала с главным коммутатором через свой коммутатор, а затем главный коммутатор связывался со стойкой Коммутатор C должен пройти очень длинный маршрут, а ресурсы пропускной способности в компьютерном зале очень ценны. Если он находится в ситуации с высоким параллелизмом, легко заполнить пропускную способность компьютерного зала. В это время скорость отклика резко упадет весь кластер.Будут проблемы с сервисом.
Конечно, количество реплик можно увеличить и вручную с помощью команд.Когда клиентского трафика много, нагрузку можно распределить соответствующим образом.
$ hadoop fs -setrep -R 4 path+FileName
На самом деле setrep означает установку репликации, аббревиатуру для установки количества копий.Приведенная выше команда устанавливает количество копий равным 4, за которыми следует путь к файлу и имя файла.
Во-вторых, три компонента HDFS
Опять же, большинство фреймворков больших данных представляют собой архитектуры «ведущий-ведомый», то есть один главный и несколько подчиненных.HDFS, о которой мы поговорим позже, представляет собой NameNode, несколько DataNodes, MapReduce — Один ResourceManager, несколько NodeManager и Spark — это Master и несколько Slave.
Введение DataNode на самом деле может быть опущено, пока вам нужно только знать, что его функция заключается в хранении блоков.
2.1 Введение в NameNode
Платформы больших данных распределены, и каждая роль может выполняться на разных серверах.Когда требуется связь, требуется поддержка сети.Когда нашему клиенту необходимо прочитать информацию о файле, мы должны знать, что наш этот файл разделен на сколько блоков, и на каком сервере хранится каждый блок.Такого рода информация, используемая для описания файла, называется метаданными (metaData) файла, а метаданные хранятся в памяти NameNode.
2.2 Введение метаданных
Размер метаданных: файлы, блоки и каталоги занимают около 150 байт метаданных, так почему же HDFS подходит для хранения больших файлов, но не для маленьких? Вполне возможно, что для хранения большого файла есть только одни метаданные размером 150 байт. Хранение N нескольких небольших файлов будет сопровождать N файлов метаданных размером 150 байт, что очень неэкономично.
Информация метаданных сохраняется в виде файла образа пространства имен (далее именуемого fsimage) и журнала редактирования (далее именуемого журналом правок).
fsimage：元数据镜像文件，保存了文件系统目录树信息以及文件和块的对应关系
edits log：日志文件，保存了文件的更改记录
Зачем метаданные нужно хранить в памяти NameNode?Ответ очень простой.Хранить в памяти значит быстро.Конечно будут проблемы,т.е. если NameNode выйдет из строя, то память не читается. В настоящее время, чтобы предотвратить такого рода ситуации, чтобы ускорить восстановление NameNode после сбоя, разработана роль SecondaryNameNode.
Кэш логов: Когда клиент записывает файлы в HDFS, будет записываться журнал операций. В это время мы заранее подготовим две области кеша. Когда лог заполнится первым кешем, он начнет поступать на диск, т.е. есть, редактирует в памяти журнала, NameNode, это состояние представляет собой операцию асинхронной записи с двойным буфером. Это гарантирует, что журнал, написанный клиентом, может быть записан в любое время.
2.3 Введение SecondaryNameNode
Его основные функции заключаются в следующем
1.备份NameNode中的元数据信息
2.提高NameNode的重启速度
3.必要的时候可作为新的NameNode
Почему SecondaryNameNode может повысить скорость восстановления NameNode?
Когда кластер запускается, начнется следующее время записи t, а с прошлым или после того, как файл журнала редактирования заполнен намененным режимом времени, в течение которого время будет запуск операции контрольной точки, будет иметь знания в искру, главная роль для важных данных резервного копирования. эксплуатация
Пошаговое объяснение шагов операции удобно прочитать каждому
1.SecondaryNameNode будет извлекать журнал изменений и информацию fsimage через http get
2. Объедините журнал изменений и fsimage в SecondaryNameNode, чтобы создать новый файл с именем fsimage.ckpt.
3. После завершения слияния в SecondaryNameNode оно передается обратно в NameNode.
4. В это время велика вероятность того, что клиент еще читает и пишет в NameNode, а также будет сгенерирован новый лог, который будет помещен в отдельный файл edits new
5. Только что возвращенный файл fsimage.ckpt декомпозирован, исходный файл журнала fsimage и изменений, но журнал изменений в это время объединит файлы журнала в новых изменениях вместе в виде полного файла журнала изменений.
Почему SecondaryNameNode может повысить скорость перезапуска NameNode
Во-первых, выясните, как NameNode восстанавливается после зависания.
Сначала он прочитает файл изображения fsimage из памяти в память, а затем повторно выполнит все операции, записанные в журнале правок, и восстановит все метаданные перед возвратом в состояние перед выключением, этот процесс очень медленный.
Однако с помощью SecondaryNameNode большая часть информации метаданных может быть восстановлена через предоставленный им файл fsimage.ckpt, а восстановление может быть выполнено напрямую путем выполнения новых операций, записанных в журнале правок и объединенных с новыми правками.
После того, как NameNode определит, что его нельзя перезапустить, SecondaryNameNode может предоставлять внешние услуги в качестве нового NameNode с помощью следующей команды.
hadoop-daemon.sh start namenode
Конечно, нетрудно обнаружить, что этот метод очень неизящный, потому что наш кластер обязательно будет иметь пустой период в период времени, когда NameNode перезапущен или SecondaryNameNode находится в верхней позиции, поэтому упомянутый метод Hadoop HA позже поможет нам решить эту проблему
3. Механизм HDFS
3.1 Механизм сердцебиения
Механизм пульса решает проблему связи между кластерами HDFS и позволяет узлу NameNode инструктировать узел данных о выполнении операций.
1.master namenode启动之后，会开一个ipc server
2.slave DataNode启动，连接NameNode，每隔3s向NameNode发送一个心跳，并携带状态信息
3.NameNode通过对这个心跳的返回值来给DataNode传达任务指令
Роль механизма сердцебиения
1. Узел NameNode полностью управляет репликацией блоков данных.Он периодически получает сигналы сердцебиения и отчеты о состоянии блоков (blockReport) от каждого узла данных в кластере.Получение сигнала сердцебиения означает, что узел DataNode работает нормально, а отчет о состоянии блока содержит список DataNode. всех блоков данных на
2. DataNode регистрируется в NameNode, когда он запускается, и периодически сообщает blockReport в NameNode после его прохождения, посылает тактовые импульсы в NameNode каждые 3 секунды, и NameNode возвращает инструкции в DataNode, такие как копирование блока данных в другой компьютер или удаление определенного. Когда DataNode не отправляет пульс на NameNode более 10 минут, NameNode определяет, что DataNode недоступен, и операции чтения и записи клиента не будут передаваться на DataNode.
3. При первом запуске кластера hadoop он переходит в безопасный режим (99,99%), и используется механизм сердцебиения, фактически, когда кластер только запускается, каждый DataNode отправляет blockReport в NameNode, а NameNode будет подсчитывать общее количество блоков, о которых они сообщают. , разделенное на общее количество, известное в начале, когда блок / общее количество
3.2 Балансировка нагрузки
По сути, это увеличение или уменьшение узлов, или проблема высокого и низкого использования дискового пространства узлов.Основная проблема заключается в переносе данных по сети для достижения высокой доступности.
триггерная команда
$ HADOOP_HOME/sbin/start-balancer.sh -t 5%
На самом деле 5 % — это разница в использовании только что упомянутого диска. Когда она превышает 5 %, срабатывает стратегия балансировки нагрузки.
finally
В следующей статье мы продолжим обновлять процесс чтения и записи и отказоустойчивость HDFS, высокой доступности и федерации.