Что будет если записать много маленьких файлов в hdfs
В блоке распределенной файловой системы Hadoop хранится несколько небольших файлов или в блоке хранится только 1 файл?
Несколько файлов не хранятся в одном блоке. Кстати, один файл может храниться в нескольких блоках. Сопоставление между файлом и идентификаторами блоков сохраняется в NameNode.
В отличие от файловой системы для одного диска, файл в HDFS, размер которого меньше одного блока, не занимает всего блока в базовом хранилище.
HDFS предназначена для обработки больших файлов. Если файлов слишком много, то NameNode может быть загружен, поскольку он хранит пространство имен для HDFS. Ознакомьтесь с статьей о том, как решить проблему с слишком много мелких файлов.
Главное нужно понимать в hdfs, file is partioned into blocks based on size а не в том, что в памяти будут какие-то блоки, где хранятся файлы (это заблуждение)
Обычно несколько файлов не хранятся в одном блоке (если это не архив или файл Har).
В блоке будет храниться один файл. Если ваш файл больше, чем размер блока (64/128 / ..), он будет разбит на несколько блоков с соответствующим размером блока.
Что ж, вы могли бы сделать это с помощью файловой системы HAR (Hadoop Archive), которая пытается упаковать несколько небольших файлов в блок HDFS специального файла части, управляемого файловой системой HAR.
Размер блока Hadoop - это концепция хранения Hadoop. Каждый раз, когда вы сохраняете файл в Hadoop, он будет разделен на блоки по размерам и в зависимости от фактора репликации и местоположения данных будет распределен по кластеру.
Когда вы отправляете файл в HDFS, он будет разделен на блоки. Каждый блок подобен отдельному файлу, максимальный размер которого определяется размером блока.
Каждый блок будет содержать файл .meta вместе с ним, чтобы хранить информацию метаданных блока в Hadoop.
Если файл очень маленький, тогда весь файл будет в одном блоке, и блок (файл хранилища) будет иметь тот же размер, что и файл и метафайл.
- Подключитесь к любому узлу данных в вашем кластере [если у вас есть доступ;)]. Затем перейдите в каталоги хранилища для этого узла, и вы увидите фактические блоки, хранящиеся на узле данных, как показано ниже.
(Dir соответствуют моему кластеру - / data2 / dfs / dn /):
Размер БЛОКА: 1 ГБ
Cd / data / dfs / dn -> current -> Finalized -> subDir0 -> ( вот золото )
В блоке используется только КБ хранилища для небольших файлов или может быть, если размер файла равен моему размеру блока + несколько КБ
-rw-r - r-- 1 hdfs hdfs 91K 13 сен 16:19 blk_1073781504
-rw-r - r-- 1 hdfs hdfs 19K 13 сен 16:21 blk_1073781504_40923.meta
Если размер файла больше, то размер блока будет примерно таким, как показано ниже
-rw-r - r-- 1 hdfs hdfs 1.0G 31 августа 12:03 blk_1073753814
-rw-r - r-- 1 hdfs hdfs 8.1M 31 августа 12:04 blk_1073753814_12994.meta
Я надеюсь, что он объяснит, что такое блочное хранилище. Если вы хотите узнать подробности того, как ваши файлы хранятся в блоках, запустите
Процесс работы с файлами HDFS
введение
Давайте сначала разберемся, что такое небольшие файлы в Hadoop: маленькие файлы относятся к тем файлам, размер которых больше, чем размер блока HDFS (вHadoopВ 1.x размер блока по умолчанию составляет 64 МБ, который может быть установлен с помощью dfs.blocksize, но в Hadoop 2.x размер блока по умолчанию составляет 128 МБ, который может быть установлен с помощью dfs.block.size.) Меньшие файлы. Проблема с HDFS в том, что он не может очень эффективно обрабатывать большое количество маленьких файлов. В HDFS любой файл, каталог и блок будут представлены в HDFS как объект, хранящийся в памяти Namenode, и каждый объект занимает 150 байт пространства памяти. Поэтому, если существует 10 миллионов файлов, каждый файл соответствует блоку, то память Namenode 3G будет использоваться для сохранения информации этих блоков. Если масштаб больше, он превысит предел, который может встретить компьютерное оборудование на стадии появления. Мало того, HDFS не существует для эффективной обработки большого количества маленьких файлов. Он предназначен в первую очередь для потокового доступа к большим файлам. Чтение небольших файлов обычно приводит к большому количеству запросов и переходов из Datanode в Datanode для получения файлов, и это очень неэффективный способ доступа.
Необходимые знания: механизм хранения и доступа к HDFS
Проще говоря, это удобно запомнить вместе:
- Файлы в HDFS разбиты на блоки для хранения. Большие файлы будут разбиты на несколько блоков. И хранится в нескольких стойках.
- Информация метаданных файла хранится в памяти NameNode в виде объектов.
2. Обработка с помощью архивирования файлов (например, файлов HAR)
HAR работает путем построения иерархической файловой системы на HDFS. HAR может создать файл HAR с помощью команды архивирования (на самом деле, он также выполняет задание MR для упаковки небольших файлов в HAR)
После создания файла архива исходный файл не будет удален. В это время пользователь может решить, сохранять ли исходный файл. Для клиента все исходные файлы видны и доступны (через har: // URL)
Для конкретной реализации, пожалуйста, обратитесь к официальному описанию веб-сайта:Hadoop Archives Guide
1. Небольшие проблемы с файлами на HDFS
Феномен: в текущем кластере уже существует большое количество небольших файлов и каталогов.
Решение: файл состоит из множества записей (Records), затем вы можете использовать метод sync () HDFS и метод append для объединения и создания большого файла с определенным интервалом. Или вы можете написать программу для объединения этих небольших файлов.
4. Внедрить сторонние системы (например, Hbase)
2. Небольшие проблемы с файлами на MapReduce
Задачи карты обычно обрабатывают один блок размером за один раз (FileInputFormat используется по умолчанию). Если файл очень маленький и содержит большое количество таких маленьких файлов, то каждая задача карты обрабатывает только очень маленькие входные данные, поэтому будет создано большое количество задач карты, и каждая задача карты будет добавлять дополнительные накладные расходы на бухгалтерию. Файл размером 1 ГБ разделен на файлы размером 16 блоков (размер блока по умолчанию - 64 МБ). По сравнению с 10 000 небольших файлов по 100 КБ последний запускает задачу сопоставления для каждого небольшого файла, поэтому время работы будет Десять или даже в сто раз медленнее, чем первый.
I、Hadoop Archive:
Haddop Archive - это инструмент для архивирования файлов, который эффективно помещает небольшие файлы в блоки HDFS и может упаковать несколько небольших файлов в один файл HAR, что одновременно уменьшает использование памяти Namenode.
II、Sequence file:
Файл последовательности состоит из серии двоичных ключей / значений. Ключ - это имя маленького файла, а значение - его содержимое. Вы можете объединить большое количество маленьких файлов в один большой файл.
III、CombineFileInputFormat:
Hadoop предоставляет класс CombineFileInputFormat для обработки небольших файлов. Основная идея состоит в том, чтобы объединить несколько небольших файлов в HDFS в InputSplit в соответствии с определенными правилами, а затем включить Map для обработки файлов в нем. Сократите время выполнения всей работы MR. Класс CombineFileInputFormat наследуется от FileInputFormat и в основном переопределяет метод List getSplits (JobContext job), этот метод будет mapreduce.input.fileinputformat.split.minsize.per.node, mapreduce.input.fileinputformat.split.minsize в соответствии с распределением данных. Параметры per.rack и mapreduce.input.fileinputformat.split.maxsize объединяются для объединения небольших файлов и создания списка. Параметр mapreduce.input.fileinputformat.split.maxsize очень важен: если пользователь не установит этот параметр (значение по умолчанию не установлено), то все небольшие файлы в одной стойке будут формировать InputSplit, который в конечном итоге будет обработан задачей Map. , Если пользователь устанавливает этот параметр, файлы на том же узле (узле) будут формировать InputSplit. Один и тот же InputSplit содержит несколько файлов блоков HDFS. Эта информация хранится в классе CombineFileSplit. В основном она содержит следующую информацию:
private Path[] paths;
private long [] startoffset;
private long [] lengths;
private String[] locations;
private long totLength;
Я читал, что множество маленьких файлов, хранящихся в HDFS, может быть проблемой, потому что множество маленьких файлов означает много объектов памяти Hadoop NameNode.
Однако, поскольку каждый блок хранится в именованном узле как объект, чем он отличается для большого файла? Независимо от того, храните ли вы 1000 блоков из одного файла в памяти или 1000 блоков для 1000 файлов, используется ли объем памяти NameNode одинаковым?
Аналогичный вопрос для вакансий на карте. Поскольку они работают с блоками, какое имеет значение, принадлежат ли блоки к маленьким файлам или к большим?
На высоком уровне вы можете рассматривать Hadoop NameNode как средство отслеживания, где расположены блоки, составляющие «файлы», хранящиеся в HDFS; блоки используются для разбивки больших файлов на более мелкие части при хранении в кластере HDFS.
- Когда у вас есть много маленьких файлов, хранящихся в HDFS, есть также много блоков, и NameNode должен отслеживать все эти файлы и блоки в памяти.
Например, когда у вас есть большой файл - если вы сначала объедините все эти файлы в файлы большего размера - у вас будет меньше файлов, хранящихся в HDFS, и у вас также будет меньше блоков.
Сначала давайте обсудим, как связаны размер файла, блоки HDFS и память NameNode:
Это легче увидеть на примерах и цифрах.
Наше имя узла HDFS block size для этого примера составляет 100 МБ.
Представим, что у нас есть тысяча (1000) файлов размером 1 МБ, и мы храним их в HDFS. При хранении этих 1000 файлов размером 1 МБ в HDFS у нас также будет 1000 блоков, составляющих эти файлы в нашем кластере HDFS.
- Каждый блок, хранящийся в HDFS, требует около 150 байт памяти NameNode, что составляет около 150 КБ памяти для этих 1000 блоков, представляющих 1000 файлов размером 1 МБ.
Теперь представьте, что мы консолидируем или объединяем эти 1000 файлов размером 1 МБ в один файл размером 1000 МБ и сохраняем этот единственный файл в HDFS. При сохранении файла размером 1000 МБ в HDFS он будет разбит на блоки в зависимости от размера блока кластера HDFS; в этом примере размер нашего блока составлял 100 МБ, что означает, что наш файл размером 1000 МБ будет храниться в виде десяти (10) блоков по 100 МБ в кластере HDFS.
- Для каждого блока, хранящегося в HDFS, требуется около 150 байт памяти NameNode, что составляет около 1,5 КБ памяти для этих 10 блоков, представляющих файл размером 1 1000 МБ.
В случае с большим файлом у нас есть те же данные, которые хранятся в кластере HDFS, но используется 1% памяти NameNode по сравнению с ситуацией со многими небольшими файлами.
Блоки ввода и количество задач карты для задания связаны.
Когда дело доходит до Map задач, обычно у вас будет задача с 1 картой на входной блок. Размер входных блоков здесь имеет значение, потому что есть накладные расходы на запуск и завершение новых задач; то есть, когда задачи карты завершаются слишком быстро, объем этих накладных расходов становится большей частью времени завершения каждой задачи, и завершение всего задания может быть медленнее, чем то же задание, но с меньшим количеством блоков ввода большего размера. Для задания на основе MapReduce2 задачи карты также включают запуск и остановку контейнера YARN на уровне управления ресурсами для каждой задачи, что увеличивает накладные расходы. (Обратите внимание, что вы также можете указать заданиям MapReduce использовать пороговое значение минимального входного размера при работе со многими небольшими входными блоками, чтобы устранить некоторые из этих недостатков)
[Hadoop] Большое количество мелких проблем с файлами и их решений.
3. Почему создается большое количество маленьких файлов
По крайней мере, в двух сценариях есть много маленьких файлов:
(1) Все эти небольшие файлы являются частью большого логического файла. Поскольку HDFS начала поддерживать добавление к файлам в версии 2.x, распространенным способом сохранения файлов без полей (например, файлов журналов) до этого (Примечание переводчика: постоянно генерируемые файлы, такие как журналы, генерируемые каждый день) является Записывайте эти данные в HDFS кусками (очень распространенный шаблон для сохранения неограниченных файлов (например, файлов журнала) - записывать их кусками в HDFS).
(2) Сам файл очень маленький. Представьте, что у нас есть большой корпус изображений, каждое изображение - уникальный файл, и нет хорошего способа объединить эти файлы в один большой файл.
Основная мысль
1. Конфигурация.
Настроить объединение входов Hive
Настройка слияния выходов Hive
Контролировать количество редукторов
Чтение файлов HDFS
(2) После получения информации о расположении файла клиент устанавливает сокет-соединение с различными датоданиями для параллельного получения данных.
5. Будет добавлено
3. Измените способ записи файла (например, SequenceFile)
Сохраните маленькое имя файла в качестве ключа и содержимое в качестве значения. И этот метод также поддерживает сжатие.
Эта программа не ограничивает количество пользователей и файлов, но файлы SequenceFile не могут быть записаны дополнительно, что подходит для одновременной записи большого количества небольших файлов. Код является ссылкой на реализацию.
В-третьих, HDFS решение для небольших файлов
Запись файлов HDFS
(2) Клиент разделяет файл на блоки и сохраняет их на Датоде параллельно на разных узлах.После отправки клиент отправляет информацию в Наменод и Датодод одновременно.
(4) После получения информации о подтверждении от Наменоде и Датоде одновременно, Датодод отправляет операцию записи.
2. Небольшая проблема с файлом на MapReduce
Задачи карты обычно обрабатывают один ввод размером блока за раз (по умолчанию используется FileInputFormat). Если файл очень маленький и содержит большое количество таких маленьких файлов, то каждая задача карты обрабатывает только очень маленькие входные данные, поэтому будет создано большое количество задач карты, и каждая задача карты увеличит накладные расходы на бухгалтерский учет (каждая из которых накладывает). дополнительные накладные расходы по бухгалтерскому учету). Файл размером 1 ГБ разделен на 16 файлов размером блока (размер блока по умолчанию - 64 МБ). По сравнению с разделением на 10 000 небольших файлов по 100 КБ, последний запускает задачу сопоставления для каждого небольшого файла, тогда время задания будет В десять, а то и в сто раз медленнее первого.
В Hadoop есть некоторые функции, которые можно использовать для уменьшения накладных расходов на ведение бухгалтерского учета: вы можете разрешить повторное использование JVM задачи в JVM для поддержки выполнения нескольких задач карты в JVM, тем самым уменьшая накладные расходы на запуск JVM (путем установки mapred.job.reuse .jvm.num.tasks, значение по умолчанию - 1, -1 означает неограниченно). (Примечание переводчика: если существует большое количество маленьких файлов, и каждый маленький файл должен запускать задачу карты, JVM должна быть запущена соответствующим образом. Одно из решений, предоставляемых этим, - повторно использовать JVM задачи, чтобы уменьшить накладные расходы на запуск JVM); Один из методов - использовать MultiFileInputSplit, который позволяет обрабатывать несколько разделений на карте.
Архитектура HDFS
HDFS использует архитектуру master / slave. Кластер HDFS состоит из Namenode и определенного количества Datanodes. Namenode - это центральный сервер, отвечающий за управление пространством имен файловой системы и доступом клиентов к файлам. Datanode в кластере, как правило, является узлом и отвечает за управление хранилищем на узле, где он находится. HDFS предоставляет пространство имен файловой системы, и пользователи могут хранить на нем данные в виде файлов. Внутренне, файл фактически делится на один или несколько блоков данных, которые хранятся в наборе Datanodes. Namenode выполняет операции с пространством имен в файловой системе, такие как открытие, закрытие, переименование файлов или каталогов. Он также отвечает за определение отображения блоков данных на конкретные узлы Datanode. Datanode отвечает за обработку запросов на чтение и запись от клиентов файловой системы. Создание, удаление и копирование блоков данных по единому расписанию Наменода.
1. Небольшая проблема с файлом на HDFS
Прежде всего, в HDFS каждый файл, каталог и блок в HDFS представлен как объект в памяти namenode (каждый файл, каталог и блок в HDFS представлены как объект в памяти namenode), и это Ограничено объемом физической памяти NameNode. Каждый объект метаданных занимает около 150 байтов, поэтому, если имеется 10 миллионов небольших файлов и каждый файл занимает блок, NameNode требует около 2 ГБ пространства. Если хранится 100 миллионов файлов, NameNode требует 20 ГБ пространства, что, несомненно, нежелательно для 100 миллионов небольших файлов.
Во-вторых, обработка небольших файлов не является целью разработки Hadoop. Целью разработки HDFS является потоковый доступ к большим наборам данных (на уровне ТБ). Поэтому хранение большого количества небольших файлов в HDFS очень неэффективно. Чтение небольших файлов обычно вызывает множество поисков и много переходов от узла данных к узлу данных для извлечения каждого небольшого файла (чтение небольших файлов обычно вызывает множество поисков и большое количество переходов от узла данных к узлу данных для извлечения каждого небольшого файла) , Это не очень эффективный режим доступа, который серьезно влияет на производительность.
Наконец, обработка большого количества небольших файлов происходит намного медленнее, чем обработка больших файлов того же размера. Каждый небольшой файл занимает слот, и запуск задачи займет много времени или даже большую часть времени, затрачиваемого на запуск и выпуск задач.
Почему там маленькие файлы?
- Потоковая обработка. При использовании SparkStreaming для обработки внешних источников данных после обработки и сохранения в HDFS каждое задание по умолчанию создает большое количество небольших файлов.
- MR автономная обработка: нет точной оценки размера записанных данных.
a) Запустите большое количество карт для обработки (например, условия фильтрации в Hive особенно низки)
b) Уменьшить настройку нецелесообразно. - Сам источник данных представляет собой небольшой файл. Нелегко объединять (например, картинки, небольшие видео)
4. Решение
Эти две ситуации требуют разных решений.
4.1 Первый случай
В первом случае файл состоит из множества записей (Records), затем вы можете вызвать метод sync () HDFS (используемый вместе с методом добавления) для создания большого файла через равные промежутки времени. Или вы можете написать программу для объединения этих небольших файлов (см. Статью Натана Марца о Consolidator, небольшом инструменте).
4.2 Второй случай
Во втором случае необходима некоторая форма контейнера, чтобы сгруппировать эти файлы определенным образом. Hadoop предоставляет несколько вариантов:
4.2.1 HAR File
Архивы Hadoop (файлы HAR) были представлены в HDFS в версии 0.18.0, и это, по-видимому, решило проблему большого количества небольших файлов, потребляющих память NameNode. Файлы HAR работают путем построения иерархической файловой системы в HDFS. Файлы HAR создаются командой hadoop archive, и эта команда фактически запускает задание MapReduce для упаковки небольших файлов в небольшое количество файлов HDFS (Примечание переводчика: объединение небольших файлов в несколько больших файлов). На стороне клиента нет изменений в использовании файлов HAR: все исходные файлы видны и доступны (просто используйте URL-адрес har: // вместо URL-адреса hdfs: //), но количество файлов в HDFS сокращается. .
4.2.2 SequenceFile
Обычный ответ на «проблему с небольшим файлом»: используйте файл последовательности (SequenceFile). Идея этого метода состоит в использовании имени файла (filename) в качестве ключа и содержимого файла (содержимого файла) в качестве значения, как показано ниже. Этот метод очень эффективен на практике. Вернемся к проблеме 10 000 небольших файлов размером 100 КБ. Вы можете написать программу, которая помещает их в один файл SequenceFile, а затем вы можете передавать их (напрямую или с помощью MapReduce) для управления SequenceFile. Это дает одновременно два преимущества: (1) файлы SequenceFiles разделяются, поэтому MapReduce может разделять их на блоки и работать с каждым блоком независимо; (2) они поддерживают сжатие одновременно, в отличие от HAR. В большинстве случаев блочное сжатие является лучшим выбором, поскольку оно сжимает несколько записей в один блок вместо сжатия одного блока на запись. (Блочное сжатие является лучшим вариантом в большинстве случаев, поскольку оно сжимает блоки из нескольких записей (а не по каждой записи)).
В отличие от файлов HAR, нет возможности перечислить все ключи в SequenceFile, поэтому весь файл не может быть прочитан. Файл карты, как и SequenceFile, который сортирует ключи, поддерживает только часть индекса, поэтому они не могут перечислить все ключи, как показано ниже.
Большое количество превосходных статей было обобщено, и написание одной после прочтения также удобно для запоминания.
Введение в новое обучение, если есть ошибки, я надеюсь их критиковать и исправлять.
Что такое маленький файл
I. Обзор
Особенности хранилища HDFS:
(1) Режим потокового чтения в основном используется для одной записи и нескольких операций чтения. Процесс записи использует метод добавления.
(2) Целью проекта является хранение очень больших файлов, в основном для сотен файлов MB, GB, TB и даже PB.
(3) Эта распределенная система построена на кластере из обычных ПК, что значительно снижает стоимость строительства и защищает от сбоев системы, поэтому пользователи могут сосредоточиться на собственных операциях.
(4) HDFS подходит для высокой пропускной способности, но не для доступа с низкой задержкой. Если одновременно хранится 1 миллион файлов, HDFS займет несколько часов.
(5) Метод потокового чтения не подходит для многопользовательской записи и записи в любой позиции. Если вы получаете доступ к небольшим файлам, вы должны перейти с одного Datanode на другой, что значительно снижает производительность чтения.
Известные недостатки:
a) В HAR при поиске в индексном файле второго уровня эффективность определенно не так хороша, как при использовании HDFS напрямую.
b) Созданные методы 2 и 3 не поддерживают модификацию, но все еще очень удобны для сценариев, которые нужно только прочитать.
HDFS, как распределенная файловая система экосистемы Hadoop, предназначена для хранения больших объемов данных и особенно подходит для хранения терабайтов и петабайтов данных. Однако со временем или проблемами с программой в HDFS может появиться большое количество небольших файлов, которые занимают много памяти на NameNode и продлевают время работы программы. Ниже я обобщу опыт обработки небольших файлов для вашей справки.
Вред маленьких файлов
- Метаданные небольших файлов занимают много памяти (небольшие файлы, метаданные не маленькие). Ограничьте возможность горизонтального расширения HDFS.
- Если используется обработка MR, каждая карта будет обрабатывать блок HDFS. Если в данный момент слишком много файлов для чтения, это приведет к запуску большого количества задач карты.
- Чтение и запись небольших файлов в HDFS также требует больше времени. Каждый раз вам необходимо получить информацию из NameNode и установить соединение с соответствующим DataNode.
Читайте также: