У меня проблема, из-за которой моя работа Hadoop в AWS EMR не сохраняется в S3. Когда я запускаю задание на меньшем образце, оно отлично сохраняет результат. Когда я запускаю ту же команду, но с полным набором данных, задание снова завершается, но на S3 ничего не существует, где я указал, что нужно выполнить вывод.
По-видимому, в 2009 г. возникла ошибка AWS EMR, но это было «исправлено».
У кого-нибудь еще была эта проблема? У меня все еще есть кластер в сети, я надеюсь, что данные где-то похоронены на серверах. Если у кого-то есть идеи, где я могу найти эти данные, дайте мне знать!
Обновление: когда я смотрю журналы одного из редукторов, все выглядит нормально:
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.
Когда я подключаюсь к узлу этой задачи, упомянутый временный каталог пуст.
Обновление 2: после прочтения различий между Amazon S3 и S3n в Hadoop, мне интересно, использует ли моя проблема «s3: //» вместо «s3n: //» в качестве пути вывода. И в моем небольшом образце (который хорошо хранится), и в моей полной работе я использовал «s3: //». Есть мысли о том, может ли это быть моей проблемой?
Обновление 3: теперь я вижу, что в EMR AWS s3: // и s3n: // оба сопоставляются с собственной файловой системой S3 (документация AWS EMR).
Обновление 4: я повторно запускал это задание еще два раза, каждый раз увеличивая количество серверов и редукторов. Первый из этих двух закончился тем, что выходы редуктора 89/90 были скопированы в S3. В 90-м заявили, что оно успешно скопировано согласно журналам, но AWS Support сообщает, что файла нет. Они передали эту проблему своей команде инженеров. Мой второй запуск с еще большим количеством редукторов и серверов фактически закончился копированием всех данных в S3 (к счастью!). Одна странность заключается в том, что некоторым редукторам требуется НАВСЕГДА, чтобы скопировать данные в S3 - в обоих этих новых запусках был редуктор, вывод которого занял 1 или 2 часа для копирования в S3, тогда как другим редукторам потребовалось максимум 10 минут. (файлы имеют размер 3 ГБ или около того). Я думаю, что это связано с чем-то не так с S3NativeFileSystem, используемой EMR (например, долгое зависание - за которое, конечно, мне выставляют счет; и предполагаемые успешные загрузки, которые не загружаются). Я бы сначала загрузил в локальную HDFS, а затем в S3, но я был есть проблемы и на этом фронте (ожидает рассмотрения командой инженеров AWS).
TL; DR; Использование AWS EMR для прямого хранения на S3 кажется ошибочным; их команда инженеров изучает.
s3://
на своем пути. Моя полная работа содержит около 300 файлов по 2 ГБ в качестве входных данных. Когда я запускаю образец задания с 10 из этих файлов размером 2 ГБ, используя тот же синтаксис вывода, он работает нормально (сохраняется в s3). Я изучил HDFS перед выключением кластера и не увидел каталогов, которые, казалось бы, могли содержать данные (хотя я убил кластер, поэтому не могу дважды проверить). Что касается повторного выполнения всего задания и вывода сначала в HDFS, я мог бы это сделать, но для меня довольно высока стоимость провала другого задания. Я надеюсь, что сотрудники AWS ответят на дубликат этого, который я разместил на их форумах. - person Dolan Antenucci   schedule 23.06.2012