Хотя S3 является хранилищем объектов, Spark, Hive и другие претендуют на свою файловую систему и используют API файловой системы Hadoop.
Некоторые ранние действия искры спасения ():
- вызов
FileSystem.exists(dest)
и сбой, если там что-то есть (если вы не включили добавление к существующим данным)
- звоните
FileSystem.mkdir(dest)
.
- установите под каталогом
_temporary
dir для задания, переименовывая вещи в место, когда задание выполнено.
Действие # 2 запускает сканирование для любой записи в пути /a/b/c/dest
, являющейся файлом (сбой), создает пустой маркерный объект каталога /a/b/c/dest/
. Этот маркер будет удален, как только будет создан дочерний каталог (т. Е. _temporary
).
В конце задания не будет никаких родительских записей маркеров, но они идут туда только для того, чтобы сохранить все те фрагменты кода, которые ожидают, что после вызова mkdirs()
существует созданный каталог.
Наконец, имейте в виду: весь механизм фиксации по переименованию нарушается, когда дело доходит до S3, так как он (а) медленный и (б) риск потери данных из-за непротиворечивости листинга каталога. Вам необходим согласованный уровень листинга (EMR: Consistent S3, Apache Hadoop: S3Guard, Databricks: что-то также основанное на DynamoDB), и, для максимальной производительности поверх Apache Hadoop 3.1, переключитесь на конкретный коммиттер S3A с нулевым переименованием.