Исправление контрольной суммы при чтении или копировании в hdfs в apache hadoop

Я пытаюсь реализовать распараллеливаемый алгоритм с использованием Apache hadoop, однако мне приходится сталкиваться с некоторыми проблемами при попытке перенести файл из локальной файловой системы в hdf. Исключение контрольной суммы возникает при попытке прочитать или передать файл.

Странно, что некоторые файлы успешно скопированы, а другие - нет (я пробовал с двумя файлами, один немного больше другого, оба они небольшие по размеру). Еще одно замечание, которое я сделал, заключается в том, что метод Java FileSystem.getFileChecksum возвращает во всех случаях null.

Небольшой фон для того, что я пытаюсь достичь: я пытаюсь записать файл в hdfs, чтобы иметь возможность использовать его как распределенный кеш для задания mapreduce, которое я написал.

Я также попробовал команду hadoop fs -copyFromLocal от терминала, и результат был таким же, как и при использовании кода Java.

Я смотрел по всему Интернету, включая другие вопросы здесь, в stackoverflow, но мне не удалось решить проблему. Имейте в виду, что я до сих пор совершенно новичок в hadoop, поэтому любая помощь очень ценится.

Я прикрепляю трассировку стека ниже, которая показывает, что выбрасываемые исключения. (В этом случае я опубликовал трассировку стека, полученную из команды hadoop fs -copyFromLocal из терминала)

[email protected]:~/Desktop/hadoop2$ bin/hadoop fs -copyFromLocal ~/Desktop/dtlScaleData/attr.txt /tmp/hadoop-name/dfs/data/attr2.txt

13/03/15 15:02:51 INFO util.NativeCodeLoader: Loaded the native-hadoop library
    13/03/15 15:02:51 INFO fs.FSInputChecker: Found checksum error: b[0, 0]=
    org.apache.hadoop.fs.ChecksumException: Checksum error: /home/name/Desktop/dtlScaleData/attr.txt at 0
        at org.apache.hadoop.fs.ChecksumFileSystem$ChecksumFSInputChecker.readChunk(ChecksumFileSystem.java:219)
        at org.apache.hadoop.fs.FSInputChecker.readChecksumChunk(FSInputChecker.java:237)
        at org.apache.hadoop.fs.FSInputChecker.read1(FSInputChecker.java:189)
        at org.apache.hadoop.fs.FSInputChecker.read(FSInputChecker.java:158)
        at java.io.DataInputStream.read(DataInputStream.java:100)
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:68)
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:47)
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:100)
        at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:230)
        at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:176)
        at org.apache.hadoop.fs.FileSystem.copyFromLocalFile(FileSystem.java:1183)
        at org.apache.hadoop.fs.FsShell.copyFromLocal(FsShell.java:130)
        at org.apache.hadoop.fs.FsShell.run(FsShell.java:1762)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
        at org.apache.hadoop.fs.FsShell.main(FsShell.java:1895)
    copyFromLocal: Checksum error: /home/name/Desktop/dtlScaleData/attr.txt at 0

Ответ 1

Вероятно, вы попали в ошибку, описанную в HADOOP-7199. Случается, что при загрузке файла с copyToLocal он также копирует файл crc в том же каталоге, поэтому, если вы измените свой файл и затем попытаетесь сделать copyFromLocal, он будет делать контрольную сумму вашего нового файла и сравнить с локальным crc файлом и сбой с сообщением об ошибке без описаний.

Чтобы исправить это, проверьте, есть ли у вас этот файл crc, если вы просто удалите его и повторите попытку.

Ответ 2

Я сталкиваюсь с той же проблемой, которая решена путем удаления .crc файлов

Ответ 3

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

Я просто создал новый файл и скопировал все содержимое из проблемного файла.

Из того, что я могу предположить, похоже, что какой-то файл crc создается и прикрепляется к этому конкретному файлу, поэтому, пытаясь с другим файлом, будет выполнена еще одна проверка crc. Другая причина может заключаться в том, что я назвал файл attr.txt, который может быть конфликтующим именем файла с другим ресурсом. Может быть, кто-то может еще больше расширить мой ответ, так как я не уверен на 100% технических данных, и это всего лишь мои наблюдения.

Ответ 4

Файл CRC хранит серийный номер для данных конкретного блока. Целые данные передаются в коллективные блоки. Каждый блок хранит метада вместе с файлом CRC внутри /hdfs/data/dfs/data folder. Если кто-то исправляет файлы CRC... фактические и текущие серийные номера CRC будут несоответствовать, и это вызывает ОШИБКУ!! Лучшей практикой для исправления этой ОШИБКИ является переопределение файла метаданных вместе с CRC файлом.

Ответ 5

У меня возникла такая же проблема, и я не нашел решения. Поскольку это был мой первый опыт использования, я не мог следовать инструкциям в Интернете. Я решил эту проблему, форматируя свой namenode.

hadoop namenode -format