Я пишу паркетный файл от DataFrame до S3. Когда я смотрю на пользовательский интерфейс Spark, я вижу все задачи, но 1 быстро завершен на этапе написания (например, 199/200). Эта последняя задача, по-видимому, длится бесконечно, и очень часто она терпит неудачу из-за превышения предела памяти исполнителя.Spark write Parquet to S3 последняя задача берет навсегда
Я хотел бы знать, что происходит в этой последней задаче. Как его оптимизировать? Спасибо.
Похоже, что у вас есть перекос данных. Вы можете исправить это, позвонив repartition на свой DataFrame перед тем, как писать на S3.
Эта статья - The Bleeding Edge: Spark, Parquet and S3 содержит много полезной информации о Spark, S3 и паркетах. В частности, речь идет о том, как драйвер заканчивает запись файлов _common_metadata_ и может занять довольно много времени. Есть способ отключить его.
К сожалению, они говорят, что они продолжают генерировать общие метаданные, но на самом деле не говорят о том, как они это сделали.
Я замечаю, что этот последний исполнитель заданий имеет гораздо больше тасовки, которые сравниваются с другими выполненными исполнителями. Означает ли это, что разбиение не является оптимальным? Как этого избежать? – user2680514
Я использую Spark 1.3.1 – user2680514
Чтобы определить, является ли перекос данных проблемой, нам нужна дополнительная информация о размере этого последнего файла и других. Учитывая то, что вы сказали об ошибках OOM, я думаю, что проблема с искажениями данных. Без какого-либо кода будет сложно помочь ни в чем, кроме попытки попробовать эту попытку. – BAR