Где мои выходные данные редуктора AWS EMR для моей выполненной работы (должны быть на S3, но там ничего)?

У меня проблема, из-за которой моя работа 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 кажется ошибочным; их команда инженеров изучает.


person Dolan Antenucci    schedule 23.06.2012    source источник
comment
Кластеры EMR могут напрямую записывать данные в S3 и HDFS. HDFS на этих кластерах создается из временного хранилища узлов и доступна только в течение всего кластера. Чтобы убедиться, что это проблема с S3, возможно, вы могли бы попробовать запустить проблемный запрос для всего набора данных, но сохранить результаты в HDFS? Если вы видите результаты в HDFS после запроса, это, скорее всего, означает проблему с S3 или его использованием. Кроме того, вы используете путь как s3: // ... или s3n: // ...?   -  person Mark Grover    schedule 23.06.2012
comment
Я использовал s3:// на своем пути. Моя полная работа содержит около 300 файлов по 2 ГБ в качестве входных данных. Когда я запускаю образец задания с 10 из этих файлов размером 2 ГБ, используя тот же синтаксис вывода, он работает нормально (сохраняется в s3). Я изучил HDFS перед выключением кластера и не увидел каталогов, которые, казалось бы, могли содержать данные (хотя я убил кластер, поэтому не могу дважды проверить). Что касается повторного выполнения всего задания и вывода сначала в HDFS, я мог бы это сделать, но для меня довольно высока стоимость провала другого задания. Я надеюсь, что сотрудники AWS ответят на дубликат этого, который я разместил на их форумах.   -  person Dolan Antenucci    schedule 23.06.2012
comment
@MarkGrover - я не понимал, что есть разница между s3: // и s3n: //. Как вы думаете, использование s3: // могло быть причиной того, что мои данные не отображаются?   -  person Dolan Antenucci    schedule 24.06.2012
comment
Оказывается, на EMR s3: // и s3n: // - одно и то же. См. Правку выше. На данный момент я собираюсь сохранить вывод моей работы в HDFS, а затем использовать distcp для передачи на S3.   -  person Dolan Antenucci    schedule 24.06.2012
comment
Какую зону доступности на S3 вы используете? А редуктор только один? Я с радостью могу подтвердить, что FileOutputCommitter, используемый для S3, чреват проблемами, особенно для стандартной (двух береговой) зоны AZ.   -  person Judge Mental    schedule 24.06.2012
comment
Я использую нас-восток-1. Есть 30 редукторов (по 3 на 10 серверах cc1.4xlarge). Выход каждого должен быть около 80 ГБ.   -  person Dolan Antenucci    schedule 25.06.2012
comment
Я наконец получил разрешение на это от Amazon - оказалось, что это ошибка с их стороны. Подробности смотрите в моем ответе. Спасибо всем за помощь   -  person Dolan Antenucci    schedule 12.09.2012


Ответы (1)


Это оказалось ошибкой со стороны AWS, и они исправили ее в последней версии AMI 2.2.1, кратко описанной в эти примечания к выпуску.

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

Если это не исчезнет с кем-либо еще, обратитесь к моему делу номер 62849531.

person Dolan Antenucci    schedule 12.09.2012