1

У меня проблема, когда моя работа Hadoop в EMR AWS не сохраняется на S3. Когда я запускаю задание на меньшем образце, задание сохраняет результат просто отлично. Когда я запускаю ту же команду, но на моем полном наборе данных, задание завершается снова, но на S3 ничего не существует, где я указывал свой вывод для перехода.Где мой выход редуктора AWS EMR для моей завершенной работы (должен быть на S3, но ничего там)?

По-видимому, был bug with AWS EMR in 2009, но он был «исправлен».

У кого-нибудь еще есть эта проблема? У меня все еще есть мой кластер в сети, надеясь, что данные будут похоронены на серверах где-то. Если у кого-то есть идея, где я могу найти эти данные, пожалуйста, дайте мне знать!

Update: Когда я смотрю на журналы от одного из восстановителей, все выглядит отлично:

2012-06-23 11:09:04,437 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Creating new file 's3://myS3Bucket/output/myOutputDirFinal/part-00000' in S3 
2012-06-23 11:09:04,439 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' writing to tempfile '/mnt1/var/lib/hadoop/s3/output-3834156726628058755.tmp' 
2012-06-23 11:50:26,706 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' is being closed, beginning upload. 
2012-06-23 11:50:26,958 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' upload complete 
2012-06-23 11:50:27,328 INFO org.apache.hadoop.mapred.Task (main): Task:attempt_201206230638_0001_r_000000_0 is done. And is in the process of commiting 
2012-06-23 11:50:29,927 INFO org.apache.hadoop.mapred.Task (main): Task 'attempt_201206230638_0001_r_000000_0' done. 

При подключении к узлу решения этой задачи, в каталог Temp упоминалось пуст.

Update 2: После прочтения Difference between Amazon S3 and S3n in Hadoop, мне интересно, если моя проблема использования «s3: //» вместо «S3N: //», как мой путь вывода. В моей моей маленькой выборке (которая хорошо хранится) и моей полной работе я использовал «s3: //». Любые мысли о том, может ли это быть моей проблемой?

Update 3: теперь я вижу, что на AWS в ОМ, s3: // и S3N: // как карта к родной файловой системе S3 (AWS EMR documentation).

Обновление 4: Я повторно запустил это задание еще два раза, каждый раз увеличивая количество серверов и редукторов. Первый из этих двух закончил с выходами редуктора 89/90, которые копируются на S3. 90-е сказал, что он успешно скопирован в соответствии с журналами, но поддержка AWS говорит, что файла нет. Они обострили эту проблему в их инженерной команде. Мой второй запуск с еще большим количеством редукторов и серверов фактически завершился с копированием всех данных на S3 (к счастью!). Одна странность состоит в том, что некоторые редукторы принимают FOREVER, чтобы скопировать данные на S3 - в обоих этих новых тиражах был редуктор, выход которого занял 1 или 2 часа, чтобы скопировать на S3, где, поскольку остальные редукторы занимали всего 10 минут (файлы имеют 3 ГБ или около того). Я думаю, что это связано с чем-то неправильным с S3NativeFileSystem, используемым EMR (например, с длинной подвеской, которую я получаю, конечно, и предполагаемыми успешными загрузками, которые не загружаются). Сначала я загружал на локальную HDFS, затем на S3, но я был having issues on this front as well (в ожидании обзора команды AWS).

TLDR; Использование AWS EMR для непосредственного хранения на S3 кажется ошибкой; их инженерная команда изучает.

+0

ЭМИ кластеры могут записывать данные изначально в S3 и HDFS. HDFS на этих кластерах производится из эфемерного хранения узлов и доступен только на время кластера.Чтобы убедиться, что это проблема с S3, возможно, вы можете попробовать запустить проблемный запрос на весь набор данных, но сохранить результаты на HDFS? Если вы увидите результаты в HDFS после запроса, это, скорее всего, будет означать проблему с S3 или его использованием. Кроме того, вы используете путь как s3: // ... или s3n: // ...? –

+0

Я использовал 's3: //' в моем пути. Моя полная работа имеет около 300 файлов 2gb в качестве входных данных. Когда я запускаю образец задания с 10 из этих 2gb-файлов, используя тот же синтаксис вывода, он отлично работает (магазины до s3). Я достиг максимума на HDFS, прежде чем закрывать кластер, и не видел никаких каталогов, которые, казалось бы, содержали бы данные (я убил кластер, хотя, поэтому не могу дважды проверить). Что касается повторной загрузки полной работы, и с выходом в HDFS, я мог бы это сделать, но для меня очень дорого, чтобы я отказался от другой работы. Я надеюсь, что сотрудники AWS ответят на дубликат этого, который я разместил на своих форумах. –

+0

@MarkGrover. Я не понимал, что существует разница между s3: // и s3n: //. Считаете ли вы, что использование «s3: //» может быть причиной того, что мои данные не отображаются? –

ответ

1

Это оказалось ошибкой для части AWS, и они исправили ее в последней версии AMI версии 2.2.1, кратко описанной в these release notes.

Долгое объяснение, которое я получил от AWS, заключается в том, что когда файлы редуктора являются> предел блока для S3 (т. Е. 5 ГБ?), То используется multipart, но не было надлежащей проверки ошибок, поэтому это иногда срабатывало, а иногда и нет.

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