Проблемы с Hadoop distcp от HDFS до Amazon S3

Я пытаюсь переместить данные с HDFS на S3, используя distcp. Задача distcp кажется успешной, но на S3 файлы создаются неправильно. Существует два вопроса:Проблемы с Hadoop distcp от HDFS до Amazon S3

Имена файлов и пути не реплицируются. Все файлы заканчиваются как block_<some number> в корне ковша.
Он создает множество дополнительных файлов на S3 с некоторыми метаданными и журналами.

Не удалось найти документацию/примеры для этого. Что мне не хватает? Как я могу отлаживать?

Вот еще некоторые детали:

$ hadoop version 
Hadoop 0.20.2-cdh3u0 
Subversion -r 
Compiled by diego on Sun May 1 15:42:11 PDT 2011 
From source with checksum 
hadoop fs –ls hdfs://hadoopmaster/data/paramesh/ 
…<bunch of files>… 

hadoop distcp hdfs://hadoopmaster/data/paramesh/ s3://<id>:<key>@paramesh-test/ 
$ ./s3cmd-1.1.0-beta3/s3cmd ls s3://paramesh-test 

         DIR s3://paramesh-test// 
         DIR s3://paramesh-test/test/ 
2012-05-10 02:20   0 s3://paramesh-test/block_-1067032400066050484 
2012-05-10 02:20  8953 s3://paramesh-test/block_-183772151151054731 
2012-05-10 02:20  11209 s3://paramesh-test/block_-2049242382445148749 
2012-05-10 01:40  1916 s3://paramesh-test/block_-5404926129840434651 
2012-05-10 01:40  8953 s3://paramesh-test/block_-6515202635859543492 
2012-05-10 02:20  48051 s3://paramesh-test/block_1132982570595970987 
2012-05-10 01:40  48052 s3://paramesh-test/block_3632190765594848890 
2012-05-10 02:20  1160 s3://paramesh-test/block_363439138801598558 
2012-05-10 01:40  1160 s3://paramesh-test/block_3786390805575657892 
2012-05-10 01:40  11876 s3://paramesh-test/block_4393980661686993969

источник

2012-05-10 Paramesh

Вы должны использовать S3N вместо s3.

s3n - это реализация встроенной файловой системы (т. Е. Регулярные файлы), используя s3, налагает структуру блоков hdfs на файлы, поэтому вы не можете их прочитать, не просматривая библиотеки hdfs.

Таким образом:

hadoop distcp hdfs://file/1 s3n://bucket/destination

источник

2012-05-10 23:19:14

Обратите внимание, что если использовать AWS EMR, s3n и s3, по-видимому, указывают на один и тот же путь (только при использовании EMR AWS - я знаю, автор не упоминал, но полагал, что другие могут запутаться). source: http://docs.amazonwebservices.com/ElasticMapReduce/latest/DeveloperGuide/FileSystemConfig.html –

Обычно hdfs является абсолютным путем, начиная с косой черты: hdfs: /// file/1 – ramn

А что, если файл был более 5 ГБ? Так как s3n ограничено 5 ГБ в качестве собственной файловой системы. S3 // для файлов размером более 5 ГБ, хотя он не позволит вам использовать его с другими приложениями. Я прав, или есть способ, например, сделать внешнюю таблицу из файла размером более 5 ГБ на S3? Шахта работает, если это s3n, и она меньше 5 ГБ, иначе это дает мне странный результат. – Maziyar

Amazon создала версию distcp, который оптимизирован для передачи между HDFS и s3, которые они называют, соответственно, s3distcp. Вы можете также проверить это. Он предназначен для использования с Amazon EMR, но банку доступно в s3, поэтому вы можете использовать его за пределами потока задач EMR.

http://docs.amazonwebservices.com/ElasticMapReduce/latest/DeveloperGuide/UsingEMR_s3distcp.html

источник

2012-05-25 06:34:20 dcsesq

Попробуйте solution. По крайней мере, это сработало для меня. (Я переместил dir с файлом 30Gb).

источник

2012-09-07 11:37:03 denys

В том случае, если ваши файлы в HDFS больше, чем 5ГБ, вы будете сталкиваться с ошибками в вашей distcp работы, которые выглядят как:

Caused by: org.jets3t.service.S3ServiceException: S3 Error Message. -- ResponseCode: 400, ResponseStatus: Bad Request, XML Error Message: <?xml version="1.0" encoding="UTF-8"?><Error><Code>EntityTooLarge</Code><Message>Your proposed upload exceeds the maximum allowed size</Message><ProposedSize>23472570134</ProposedSize><MaxSizeAllowed>5368709120</MaxSizeAllowed><RequestId>5BDA6B12B9E99CE9</RequestId><HostId>vmWvS3Ynp35bpIi7IjB7mv1waJSBu5gfrqF9U2JzUYsXg0L7/sy42liEO4m0+lh8V6CqU7PU2uo=</HostId></Error> at org.jets3t.service.S3Service.putObject(S3Service.java:2267) at org.apache.hadoop.fs.s3native.Jets3tNativeFileSystemStore.storeFile(Jets3tNativeFileSystemStore.java:122) ... 27 more Container killed by the ApplicationMaster. Container killed on request. Exit code is 143 Container exited with a non-zero exit code 143

Чтобы исправить это, используйте либо s3n файловую систему @ МЭТЬЮ-Рэтбоун предложил, но с -Dfs.s3n.multipart.uploads.enabled=true как:

hadoop distcp -Dfs.s3n.multipart.uploads.enabled=true hdfs://file/1 s3n://bucket/destination

ИЛИ

Используйте "следующего поколения" s3 файловая система, s3a как:

hadoop distcp -Dfs.s3a.endpoint=apigateway.us-east-1.amazonaws.com hdfs://file/1 s3a://bucket/destination

Параметры и документации для них здесь живут: https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html

источник

2016-02-22 20:30:07 Sean

Для пользователей cloudera 5.2 не поддерживает протокол 's3a', поэтому требуется опция' s3n' с параметром multipart. Версия 5.5 и более поздних версий поддерживает более новую 's3a'. –

Обновление это для Apache Hadoop 2.7+, и игнорируя Amazon EMR, как они изменили вещи там.

Если вы используете Hadoop 2.7 или новее, используйте s3a over s3n. Это также относится к последним версиям HDP и AFAIK, CDH.
Это поддерживает файлы с 5 + ГБ, имеет другие приятные функции и т. Д. При чтении файлов ощутимо лучше, и со временем станет лучше.
Apache s3: // должен считаться устаревшим - вам он больше не нужен и не должен его использовать.
Amazon EMR использует «s3: //», чтобы ссылаться на свой собственный, настраиваемый, привязывающий к S3. Это то, что вы должны использовать, если вы работаете с EMR.

Улучшение надежности и производительности distcp, работающих с хранилищами объектов, по-прежнему и продолжающаяся часть работы ... вклады, как всегда, приветствуются.

источник

2016-09-02 12:50:26

Проблемы с Hadoop distcp от HDFS до Amazon S3

ответ

Смежные вопросы