Слияние кода завершено, страница обновится автоматически
В пакетах Hadoop, связанных с I/O, содержатся следующие:
Кроме пакета org.apache.hadoop.io.serializer.avro, используемого для сериализации данных для Avro, все остальные используются для I/O-операций в Hadoop. I/O-операции в Hadoop эволюционировали из традиционных I/O-операций, но имеют и свои отличия. Во-первых, в обычных компьютерных системах данные централизованы, то есть, независимо от количества фильмов, музыки или документов, они находятся на одной и той же машине на одном и том же жестком диске. В Hadoop же данные часто распределены на нескольких компьютерных системах. Во-вторых, объем данных в обычных ПК обычно невелик и находится в гигабайтах, тогда как Hadoop обрабатывает данные в петабайтах.
Изменения приводят к проблемам. Эти изменения приводят к тому, что I/O-операции в Hadoop должны учитывать не только стоимость I/O-операций на локальной машине, но и стоимость передачи данных между различными машинами. В то же время, методы адресации данных в Hadoop должны быть изменены, чтобы справиться с нагрузкой адресации, вызванной огромным объемом данных.
Хотя вероятность возникновения ошибки при каждом I/O-действии на диске или в сети очень мала, при обработке данных в объеме, превышающем пределы Hadoop, вероятность повреждения данных становится очень высокой.Самый распространенный метод проверки данных — это вычисление контрольной суммы (checksum) при первом введении данных в систему и повторное вычисление контрольной суммы при передаче данных через ненадежный канал. Это позволяет обнаружить повреждение данных. Если обнаружена ошибка, эта техника не может её исправить. (Контрольная сумма также может быть повреждена.) Обычными контрольными суммами являются CRC-32 (циклический избыточный код), который вычисляет контрольную сумму в виде 32-битного целого числа для любого объёма данных.
HDFS вычисляет контрольные суммы для всех записанных данных и проверяет их при чтении. Для каждого блока данных размером в io.bytes.per.checksum байт вычисляется контрольная сумма. По умолчанию размер блока составляет 512 байт, а поскольку CRC-32 контрольная сумма занимает 4 байта, то дополнительные затраты на хранение контрольных сумм составляют менее 1%.Datanode отвечает за хранение данных и проверку контрольных сумм после получения данных от клиента или при копировании данных из других datanode. Клиент, который записывает данные, отправляет данные и контрольные суммы последовательности datanode, где последний datanode вычисляет контрольную сумму. Если datanode обнаруживает ошибку, клиент получает исключение ChecksumException, являющееся подклассом IOException, которое должно быть обработано в зависимости от конкретного приложения, например, путем повторной попытки операции.Клиент проверяет контрольные суммы при чтении данных от datanode, сравнивая их с контрольными суммами, хранящимися на datanode. Каждый datanode сохраняет постоянный журнал проверки контрольных сумм, поэтому он знает время последней проверки каждого блока данных. После успешной проверки данных клиент сообщает об этом datanode, который обновляет журнал. Сохранение этой информации полезно для обнаружения поврежденных дисков.
Не только клиент проверяет контрольные суммы при чтении блока данных, но каждый datanode также запускает в фоновом режиме DataBlockScanner для регулярной проверки всех блоков данных, хранящихся на этом datanode. Это мера является эффективным способом решения проблем с повреждением физического носителя.Поскольку DFS хранит реплики каждого блока данных, он может восстановить поврежденные блоки данных с помощью этих реплик, создавая новый, неповрежденный блок. Основная идея заключается в том, что клиент, который читает данные, если обнаруживает ошибку, сначала сообщает namenode о поврежденном блоке данных и datanode, который пытается прочитать данные. Затем выбрасывается исключение ChecksumException. Namenode помечает реплику блока данных как поврежденную и не отправляет запросы напрямую к этому узлу или не пытается скопировать эту реплику на другой datanode. Затем он планирует копирование реплики блока данных на другой datanode, таким образом, фактор репликации блока данных возвращается к желаемому уровню. После этого поврежденная реплика блока данных удаляется.Для отключения проверки контрольных сумм перед использованием метода open() для чтения файла, можно передать значение false методу setVerifyChecksum() объекта FileSystem. Если использовать команду с параметром -ignoreCrc в командной строке или эквивалентную команду -copyToLocal, можно достичь аналогичного эффекта. Если необходимо проверить поврежденный файл и принять решение о дальнейших действиях, эта функциональность может быть очень полезной. Например, возможно, вы захотите попытаться восстановить часть данных перед удалением файла.
LocalFileSystem в Hadoop выполняет проверку контрольных сумм на стороне клиента. Если вам нужно создать файл с именем a, клиент файловой системы создаст скрытый файл с именем a.crc в том же каталоге, который будет содержать контрольные суммы для каждого блока файла. Как и в случае с HDFS, размер блока файла контролируется параметром io.bytes.per.checksum, который по умолчанию равен 512 байтам. Размер блока файла хранится в метаданных в файле .crc, поэтому даже если размер блока файла изменился, файл можно будет правильно прочитать. При чтении файла проверяются контрольные суммы, и если обнаружены ошибки, LocalFileSystem выбросит исключение ChecksumException.Стоимость вычисления контрольных сумм довольно низкая (Java использует локальные методы для вычисления контрольных сумм), что увеличивает I/O только незначительно. Если поддержка контрольных сумм включена в нижележащей файловой системе, можно использовать RawLocalFileSystem вместо LocalFileSystem для отключения вычисления контрольных сумм. Если требуется глобальное отключение вычисления контрольных сумм в приложении, можно установить свойство fs.file.impl на org.apache.hadoop.fs.RawLocalFileSystem для переключения URI. Также можно отключить вычисление контрольных сумм для некоторых операций чтения, создав новый экземпляр RawLocalFileSystem, как показано ниже:```java
Configuration conf;
FileSystem fs = new RawLocalFileSystem();
fs.initialize(null, conf);
### 3. ChecksumFileSystem
LocalFileSystem использует ChecksumFileSystem для выполнения своих задач, что позволяет легко добавлять контрольные суммы в другие файловые системы (без контрольных сумм), так как LocalFileSystem является подклассом ChecksumFileSystem.
Нижележащая файловая система называется "сырой" (raw) файловой системой, и она может быть получена с помощью метода getRawFileSystem() экземпляра ChecksumFileSystem. Класс ChecksumFileSystem также содержит другие методы, связанные с контрольными суммами, такие как getCkecksumFile(), который позволяет получить путь к файлу контрольных сумм для любого файла. Подробное использование этих методов можно найти в документации API. Если при чтении файла произошла ошибка, класс ChecksumFileSystem вызывает свой метод reportChecksumFailure(). Этот метод по умолчанию реализован пустым, но класс LocalFileSystem перемещает этот повреждённый файл вместе с его контрольной суммой в стороннюю директорию с именем `bad_files` на том же устройстве. Администраторы должны регулярно проверять эти повреждённые файлы и принимать соответствующие меры.
Исправления:
- "getCkecksumFile()" на "getChecksumFile()"
- "reportChecksumFailure()" на "reportChecksumFailure()" (оставлено без изменений, так как это имя метода)
- "bad_files" на "bad_files" (оставлено без изменений, так как это имя директории)
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )