从 Spark 结构化流应用程序写入 S3 的性能问题答案

【问题标题】：Performance issue writing to S3 from Spark Structured Streaming application从 Spark 结构化流应用程序写入 S3 的性能问题
【发布时间】：2020-02-20 23:52:10
【问题描述】：

基本上，我正在运行 24 x 7 的结构化流作业，写入 S3。但是遇到了这个问题，即 _spark_metadata 需要花费数小时来写入单个文件，在此期间没有新的数据摄取处于活动状态。

知道如何解决这个问题并启用无停机摄取吗？

19/10/24 00:48:34 INFO ExecutorAllocationManager: Existing executor 40 has been removed (new total is 1)
19/10/24 00:49:03 INFO CheckpointFileManager: Writing atomically to s3a://.../data/_spark_metadata/88429.compact using temp file s3a://.../data/_spark_metadata/.88429.compact.00eb0d4b-ec83-4f8c-9a67-4155918a5f83.tmp
19/10/24 03:32:53 INFO CheckpointFileManager: Renamed temp file s3a://.../data/_spark_metadata/.88429.compact.00eb0d4b-ec83-4f8c-9a67-4155918a5f83.tmp to s3a://brivo-prod-dataplatform-kafka-streaming/data/_spark_metadata/88429.compact
19/10/24 03:32:53 INFO FileStreamSinkLog: Current compact batch id = 88429 min compaction batch id to delete = 88329
19/10/24 03:32:54 INFO ManifestFileCommitProtocol: Committed batch 88429

【问题讨论】：

您使用的是默认提交者还是 s3a 提交者？
是的，我正在写 AVRO 而不是镶木地板。所以 AWS EMRFS S3-Optimized Committer 不适用。
我实际上是在谈论 Apache s3a 提交者 hadoop.apache.org/docs/r3.1.1/hadoop-aws/tools/hadoop-aws/…，它们不应该有文件类型限制。

标签： amazon-s3 pyspark apache-kafka amazon-emr spark-structured-streaming

【解决方案1】：

rename 在 s3 上模仿复制然后删除并且是 O(data)。更频繁地检查点以创建更小的文件

【讨论】：

这发生在 _SPARK_METADATA 目录下，这是 WAL，而不是原始数据。