Это 6-й день моего участия в августовском испытании обновлений.Подробности о мероприятии:Испытание августовского обновления

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

дизайн-мышление

фон рождения

С быстрым развитием Интернета объем данных, которые необходимо вычислить и обработать, быстро увеличивается. В немного более крупных интернет-компаниях объем данных, которые необходимо вычислить и обработать, часто измеряется петабайтами. Пропускная способность сети (обычно сотни МБ), объем памяти (обычно десятки ГБ), размер диска (обычно несколько терабайт) и скорость работы ЦП, которые может запланировать компьютер, не могут удовлетворить этим вычислительным требованиям.

В этот момент возникает такой фон спроса:

我们需要一个文件系统，可以支持海量数据的存储与计算，并且对外提供一个统一的读写API。

проблема, с которой мы сталкиваемся

Чтобы поддерживать хранение и обработку массивных данных, нам необходимо решить несколько основных проблем:

1. Проблема емкости хранения данных.

​ Поскольку большие данные должны решать задачу расчета данных в несколько петабайт, а общая емкость диска сервера обычно составляет 1-2 ТБ, как хранить такие крупномасштабные данные?

2. Проблема скорости чтения и записи данных.

Непрерывная скорость чтения и записи обычного диска составляет десятки МБ, при такой скорости до скончания века придется читать и записывать десятки петабайт данных.

3. Вопросы надежности данных.

​ Диски являются наиболее уязвимым аппаратным обеспечением в компьютерном оборудовании.Обычно срок службы диска составляет около года.Если диск поврежден, что происходит с данными?

Тиндер мышления

Вертикальное масштабирование против горизонтального масштабирования

В компьютерной сфере есть два способа увеличить вычислительную мощность и увеличить объем хранения данных.

• «Масштабирование», увеличение мощности компьютера за счет модернизации ЦП, памяти, дисков и т. д.;

• «Масштабирование», добавление большего количества компьютеров в систему для достижения большей вычислительной мощности.

  Очевидно, что вертикальное масштабирование означает более высокие затраты, и у вертикального масштабирования есть предел, а у горизонтального масштабирования — нет (или этот предел намного выше, чем у вертикального масштабирования). Поэтому, если мы хотим решить нашу проблему, мы можем начать только с горизонтального масштабирования.

Может ли горизонтальное масштабирование удовлетворить наши потребности?

В настоящее время мы можем пойти только по пути горизонтального масштабирования, так может ли горизонтальное масштабирование удовлетворить потребности?

запрос пользователя

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

Мобильные вычисления более рентабельны, чем мобильные данные

​ Перед лицом данных уровня PB сама программа может иметь только уровень KB или MB. Поскольку объем данных намного больше, чем сама программа, отправлять данные в программу нерентабельно. Мы можем изменить образ мышления и отправить программу по сети туда, где находятся данные, что собственно соответствует идее горизонтального масштабирования.

RAID

Если я вижу дальше других, то это потому, что я стою на плечах гигантов. - Ньютон

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

RAID（独立磁盘冗余阵列）技术是将多块普通磁盘组成一个阵列，共同对外提供服务。主要是为了改善磁盘的存储容量、读写速度，增强磁盘的可用性和容错能力。

Конкретные детали реализации RAID здесь не обсуждаются, а только то, как решить три проблемы, упомянутые выше, когда встречается RAID?

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

1. Проблема емкости хранения данных: RAID использует N дисков для формирования массива хранения.Если используется RAID 5, данные могут храниться на N-1 дисках, что увеличивает объем хранилища в N-1 раз.

2. Проблема скорости чтения и записи данных. RAID делит данные для записи на несколько частей в соответствии с количеством дисков, которые можно использовать, и записывает на несколько дисков одновременно.Очевидно, что скорость записи может быть значительно улучшена, а скорость чтения также может быть значительно улучшена.

3. Вопросы надежности данных. При использовании схемы RAID 10, RAID 5 или RAID 6, поскольку данные хранятся избыточно или сохраняется информация о четности, при повреждении определенного диска данные на других дисках и данные о четности на диске могут быть потеряны. восстановление данных.

Вышеприведенный абзац относительно длинный, на самом деле он состоит из 3 ключевых слов:

N дисков образуют массив хранения

одновременная запись

избыточное резервное копирование

Полный

После приведенного выше обсуждения у нас фактически уже есть относительно полное представление, которое может помочь нам решить три проблемы, упомянутые в начале.

1. Проблема емкости хранилища данных: несколько серверов представляют внешнему миру единую файловую систему, которая объединяет ЦП, диск, память, пропускную способность сети и т. д. и предоставляет внешнему миру унифицированный API чтения и записи.

2. Проблема скорости чтения и записи данных: мы делим данные на несколько блоков и пишем их в систему одновременно.

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

Я резюмирую вышеизложенное в следующую карту разума.

Реализовать идеи

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

Вернемся к трем вопросам в начале:

1. Проблема емкости хранилища данных (распределенного)

1. Как узнать, какие серверы хранят какие данные в распределенном кластере?

​ Это не сложно придумать, самое распространенное в распределенных кластерахархитектура «ведущий-ведомый».

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

Далее главный сервер отвечает за взаимодействие с клиентом, а подчиненный сервер отвечает за хранение определенных данных.

2. Как главный сервер узнает, какие данные хранятся на подчиненном сервере?

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

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

3. Что делать, если я отключился от сервера? Что делать, если диск поврежден? Откуда главный сервер знает?

Здесь также используется более классическое мышление -Механизм сердцебиения, подчиненный сервер регулярно связывается с главным сервером.По истечении времени ожидания соединения считается, что подчиненный сервер вешает трубку. Тут надо упомянутьизбыточное резервное копирование. Как только главный сервер определяет, что подчиненный сервер не работает, он получает информацию о хранилище, принадлежащую подчиненному серверу, из локальной памяти, а затем создает новую резервную копию. Если подчиненный сервер определит, что диск поврежден, он сообщит информацию о хранении на диске главному серверу, который узнает, на каких других серверах хранится та же информация, и ему нужно будет только создать новую резервную копию. Соответствующий запрос также будет передан на резервный подчиненный сервер.

На самом деле это отражает распространенное представление об обеспечении доступности системы —отказоустойчивость.

4. Что делать, если завис основной сервер?

Горячее резервное копирование Master-Slave, совместное использование информации метаданных, когда мастер умирает, сервер резервного копирования сразу становится нормальным, тем самым обеспечивая доступность системы.

5. Как быстро восстановиться после неудачи?

​ 1. Во-первых, мы должны иметь возможность думать, что вся файловая система может быть зеркалирована напрямую, и образ может быть загружен сразу после перезагрузки системы;

​ 2. Но будет проблема Долго делать зеркало, а система в это время будет недоступна?

Здесь тоже есть классическое решение:

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

​ 3.Есть еще одна проблема.Если вдруг основной сервер зависнет, то запись данных лог-файла не сливается в зеркальный файл, так что же делать, если после перезагрузки система еще долго недоступна?

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

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

6. Что делать, если памяти одного мастер-сервера недостаточно для больших объемов данных?

​ Если одной памяти мало, то добавлю другую, если двух мало, то добавлю еще! Собственно об этом было сказано вышеГоризонтальное расширениеподумал о.

7. Что делать, если диск с метаданными выходит из строя?

Это снова старая проблема, я думаю, вы можете ляпнуть: избыточное резервное копирование! Да, я могу подготовить несколько копий одних данных на одном сервере.Конечно, есть лучшее решение: использовать общее хранилище на нескольких мастер-серверах или использовать распределенные журналы редактирования.

Во-вторых, проблема скорости чтения и записи данных (блок данных)

1. Как разделить данные на блоки?

​ Данные разделены по фиксированному размеру, что делать, если размер недостаточен? Недостаточный размер тоже считается блоком, поэтому им неудобно управлять.

2. Каков подходящий размер блока данных?

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

Блок данных не может быть слишком большим — как он может соответствовать требованиям параллельной записи? Не забывайте, что цель разбивки данных на части состоит в одновременной записи.

3. Что делать, если я столкнулся с большим количеством мелких данных?

Эта идея также относительно распространена, слияние и сжатие.

3. Проблема надежности данных (избыточное резервное копирование)

1. Где должны быть размещены данные?

​ Узлы не могут быть слишком близко — одно зависание может зависнуть все

Узлы также не могут быть слишком далеко — согласно теореме Шеннона, чем больше расстояние, тем больше время передачи.

2. Какую копию выбрать при чтении данных?

При этом учитывается теорема Шеннона, очевидно, чем ближе, тем лучше, потому что согласно предыдущему выводу данные скачиваются клиентом с сервера, поэтому речь идет о расстоянии между клиентом и подчиненным сервером.

3. Как обеспечить целостность данных?

Здесь также присутствует классическое мышление: чем больше объем данных, тем менее надежна передача по сети, мы найдем способ разделить данные на более мелкие части.

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

Чтение данных — после того, как клиент прочитает контрольную сумму данных и сравнит ее с контрольной суммой в основной памяти сервера, он узнает, успешно ли прочитаны данные.

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

Специально для HDFS

На самом деле, HDFS разработана в соответствии с приведенными выше идеями. Конечно, приведенные выше идеи могут лишь приблизительно помочь вам понять идеи дизайна HDFS. Позже я напишу статью с более конкретным содержанием.

​Каждый из приведенных выше вопросов соответствует одному или нескольким пунктам знаний в HDFS.Подробности см. в интеллект-карте ниже.