Hadoop - файловые блоки и коэффициент репликации

Распределенная файловая система Hadoop, т.е. HDFS используется в Hadoop для хранения данных, что означает, что все наши данные хранятся в HDFS. Hadoop также известен своей эффективной и надежной техникой хранения. Вы когда-нибудь задумывались, как Hadoop делает свое хранилище таким эффективным и надежным? Да, вот что вводится в понятие файловых блоков. Фактор репликации - это не что иное, как процесс создания репликации или дублирования данных, поэтому давайте обсудим их один за другим на примере для лучшего понимания.

Файловые блоки в Hadoop

Что происходит, когда вы импортируете какой-либо файл в свою распределенную файловую систему Hadoop, этот файл был разделен на блоки определенного размера, а затем эти блоки данных сохраняются на различных подчиненных узлах. Это нормальное явление, которое случается почти во всех типах файловых систем. По умолчанию в Hadoop1 эти блоки имеют размер 64 МБ, а в Hadoop2 эти блоки имеют размер 128 МБ, что означает, что все блоки, получаемые после разделения файла, должны иметь размер 64 МБ или 128 МБ. Вы можете вручную изменить размер файлового блока в файле hdfs-site.xml .

Давайте разберемся с этой концепцией разбивки файла на блоки на примере. Предположим, вы загрузили файл размером 400 МБ в HDFS, и происходит следующее: этот файл разделен на блоки размером 128 МБ + 128 МБ + 128 МБ + 16 МБ = 400 МБ. Означает, что создается 4 блока по 128 МБ каждый, кроме последнего.

Hadoop не знает или не заботится о том, какие данные хранятся в этих блоках, поэтому он рассматривает окончательные блоки файла как частичную запись. В файловой системе Linux размер файлового блока составляет около 4 КБ, что намного меньше размера файловых блоков по умолчанию в файловой системе Hadoop. Как мы все знаем, Hadoop в основном настроен для хранения данных большого размера, которые измеряются в петабайтах, это то, что отличает файловую систему Hadoop от других файловых систем, поскольку ее можно масштабировать, в настоящее время в Hadoop рассматриваются файловые блоки от 128 МБ до 256 МБ.

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

• Блоки файлов Hadoop больше, потому что, если блоки файлов меньше по размеру, тогда в нашей файловой системе Hadoop, то есть в HDFS, будет очень много блоков. Хранение большого количества метаданных в этих небольших файловых блоках в очень большом количестве становится беспорядочным, что может вызвать сетевой трафик.
• Блоки делаются больше, чтобы мы могли минимизировать затраты на поиск или поиск. Потому что иногда время, необходимое для передачи данных с диска, может быть больше, чем время, необходимое для запуска этих блоков.

Преимущества файловых блоков:

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

Репликация и коэффициент репликации

Репликация обеспечивает доступность данных. Репликация - это не что иное, как копирование чего-либо, и количество раз, когда вы копируете эту конкретную вещь, можно выразить как ее коэффициент репликации. Как мы видели в блоках файлов, HDFS хранит данные в форме различных блоков, в то время как Hadoop также настроен на создание копий этих блоков файлов. По умолчанию коэффициент репликации для Hadoop установлен на 3, который можно настроить, это означает, что вы можете изменить его вручную в соответствии с вашими требованиями, как в приведенном выше примере, мы создали 4 файловых блока, что означает, что создается 3 реплики или копии каждого файлового блока, что означает всего из 4 × 3 = 12 блоков сделано для резервного копирования.

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

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

Вы можете настроить коэффициент репликации в файле hdfs-site.xml .

Здесь мы установили коэффициент репликации равным единице, поскольку у нас есть только одна система для работы с Hadoop, то есть один портативный компьютер, поскольку у нас нет кластера с большим количеством узлов. Вам нужно просто изменить значение в свойстве dfs.replication в соответствии с вашими потребностями.

Как работает репликация?

На изображении выше вы можете видеть, что есть мастер с ОЗУ = 64 ГБ и дисковым пространством = 50 ГБ и 4 ведомых устройства с ОЗУ = 16 ГБ и дисковым пространством = 40 ГБ. Здесь вы можете заметить, что RAM для Master больше. Его нужно хранить больше, потому что ваш Мастер - это тот, кто будет вести этого раба, поэтому ваш Мастер должен действовать быстро. Теперь предположим, что у вас есть файл размером 150 МБ, тогда общее количество файловых блоков будет 2, как показано ниже.

 128 МБ = блок 1
22 МБ = блок 2

Поскольку коэффициент репликации по умолчанию равен 3, у нас есть 3 копии этого файлового блока.

 FileBlock1-Replica1 (B1R1) FileBlock2-Replica1 (B2R1)
FileBlock1-Replica2 (B1R2) FileBlock2-Replica2 (B2R2)
FileBlock1-Replica3 (B1R3) FileBlock2-Replica3 (B2R3)

Эти блоки будут храниться в нашем Slave, как показано на диаграмме выше, что означает, что если предположим, что ваш Slave 1 разбился, тогда в этом случае B1R1 и B2R3 потеряны. Но вы можете восстановить B1 и B2 из других ведомых устройств, поскольку реплика этих файловых блоков уже присутствует в других ведомых устройствах, аналогично, если какой-либо другой ведомый сервер потерпел крах, мы можем получить этот файловый блок на каком-либо другом ведомом устройстве. Репликация увеличит объем нашего хранилища, но нам больше нужны данные.