Я пытаюсь реализовать распараллеливаемый алгоритм с использованием 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
Вероятно, вы попали в ошибку, описанную в HADOOP-7199. Случается, что при загрузке файла с copyToLocal он также копирует файл crc в том же каталоге, поэтому, если вы измените свой файл и затем попытаетесь сделать copyFromLocal, он будет делать контрольную сумму вашего нового файла и сравнить с локальным crc файлом и сбой с сообщением об ошибке без описаний.
Чтобы исправить это, проверьте, есть ли у вас этот файл crc, если вы просто удалите его и повторите попытку.
Я сталкиваюсь с той же проблемой, которая решена путем удаления .crc файлов
Хорошо, поэтому мне удалось решить эту проблему, и я пишу ответ здесь, на случай, если кто-то другой столкнется с той же проблемой.
Я просто создал новый файл и скопировал все содержимое из проблемного файла.
Из того, что я могу предположить, похоже, что какой-то файл crc создается и прикрепляется к этому конкретному файлу, поэтому, пытаясь с другим файлом, будет выполнена еще одна проверка crc. Другая причина может заключаться в том, что я назвал файл attr.txt, который может быть конфликтующим именем файла с другим ресурсом. Может быть, кто-то может еще больше расширить мой ответ, так как я не уверен на 100% технических данных, и это всего лишь мои наблюдения.
Файл CRC хранит серийный номер для данных конкретного блока. Целые данные передаются в коллективные блоки. Каждый блок хранит метада вместе с файлом CRC внутри /hdfs/data/dfs/data folder. Если кто-то исправляет файлы CRC... фактические и текущие серийные номера CRC будут несоответствовать, и это вызывает ОШИБКУ!! Лучшей практикой для исправления этой ОШИБКИ является переопределение файла метаданных вместе с CRC файлом.
У меня возникла такая же проблема, и я не нашел решения. Поскольку это был мой первый опыт использования, я не мог следовать инструкциям в Интернете. Я решил эту проблему, форматируя свой namenode.
hadoop namenode -format