Недавно мы перешли из "EMR на HDFS" → "EMR на S3" (EMRFS с включенным согласованным просмотром), и мы поняли, что запись Spark "SaveAsTable" (формат паркета) на S3 была ~ 4 раза медленнее по сравнению с HDFS, но мы обнаружили обходной путь использования DirectParquetOutputCommitter - [1] с Искры 1.6.
Причина медленности S3. Нам пришлось заплатить так называемый паркет tax- [2], где коммиттер вывода по умолчанию записывает во временную таблицу и переименовывает его позже, когда операция переименования в S3 очень дорога
Также мы понимаем риск использования "DirectParquetOutputCommitter", который позволяет предотвратить повреждение данных с помощью спекулятивных задач.
Теперь w/Spark 2.0 этот класс устарел, и нам интересно, какие параметры у нас есть в таблице, чтобы мы не получали более медленную запись ~ 4x при обновлении до Spark 2.0. Любые мысли/предложения/рекомендации будут высоко оценены.
Одним из обходных решений, о котором мы можем думать, является: - Сохранить на HDFS, а затем скопировать его на S3 через s3DistCp (любые мысли о том, как это можно сделать разумно, поскольку наш хранилище метаданных Hive указывает на S3?)
Также похоже, что NetFlix исправил это - [3], любую идею о том, когда они планируют открыть исходный код?
Благодарю.
[2] - https://www.appsflyer.com/blog/the-bleeding-edge-spark-parquet-and-s3/
[3] - https://www.youtube.com/watch?v=85sew9OFaYc&feature=youtu.be&t=8m39s http://www.slideshare.net/AmazonWebServices/bdt303-running-spark-and-presto-on-the-the -netflix-большой-данных платформы
Вы можете использовать: sparkContext.hadoopConfiguration.set("mapreduce.fileoutputcommitter.algorithm.version", "2")
поскольку вы находитесь на EMR, просто используйте s3 (нет необходимости в s3a)
Мы используем Spark 2.0 и довольно быстро записываем Parquet на S3 (примерно так же быстро, как HDFS)
если вы хотите больше узнать об этом билете jira SPARK-10063
Я думаю, что коммиттер S3 из Netflix уже открыт по адресу: https://github.com/rdblue/s3committer.