EMRFS S3-optimized committer 分析

最新推荐文章于 2026-06-20 21:52:07 发布

转载最新推荐文章于 2026-06-20 21:52:07 发布 · 109 阅读

本内容遵循CC 4.0 BY-SA版权协议

原文链接：https://aws.amazon.com/blogs/big-data/improve-apache-spark-write-performance-on-apache-parquet-formats-with-the-emrfs-s3-optimized-committer/

GEO检测

标签

#aws #amazon emr #云计算 #emrfs #spark

EMR 专栏收录该内容

2 篇文章

订阅专栏

这里写自定义目录标题

EMRFS S3-optimized committer

EMRFS S3-optimized committer

原文地址 https://aws.amazon.com/blogs/big-data/improve-apache-spark-write-performance-on-apache-parquet-formats-with-the-emrfs-s3-optimized-committer/

EMRFS S3-optimized committer 是一种替代的 OutputCommitter 实现，专为使用 EMRFS 向 Amazon S3 写入文件而优化。该提交器通过避免在作业和任务提交阶段在 Amazon S3 中执行列出和重命名操作，提高了应用程序性能。该提交器从 Amazon EMR 5.19.0 版本开始可用，并在 Amazon EMR 5.20.0 及更高版本中默认启用。该提交器用于使用 Spark、DataFrames 或 Datasets 的 Spark 作业。从 Amazon EMR 6.4.0 开始，此提交器可用于所有常见格式，包括parquet、ORC和文本格式（包括CSV和JSON）。在6.4.0之前的版本中，仅支持Parquet格式。

关于 FileOutputCommitter

通过 Spark 作业写 Parquet 文件到 Amazon S3 的时候，默认使用的提交算法叫做 FileOutputCommitter，这个算法有两个版本。
V1: 一个是提交单个任务输出，另一个是提交已完成/成功任务的整体作业输出
V2: 更高效，因为任务提交直接将文件重命名到最终输出位置。这消除了第二个重命名阶段，但会使部分数据在作业完成前可见，这并非所有工作负载都能容忍。

对于 rename 的操作，在 HDFS 上是非常快的，它只需要对元数据进行操作。然而，当我们写入Amazon S3 等对象存储时，重命名是通过将数据复制到目标位置，然后删除源位置来实现的。这种重命名"代价"在对于目录重命名时尤为严重，这种情况可能在 FileOutputCommitter v1的两个阶段中发生。

为了缓解这个问题，Amazon EMR 5.14.0 开始在 EMRFS 中，如果使用 Spark 向 S3 写入 Parquet 数据时默认使用 FileOutputCommitter v2。新的 EMRFS S3-optimized committer 通过利用 Amazon S3 multipart uploads 的事务特性，完全避免重命名操作。任务可以直接将数据写入最终输出位置，但将每个输出文件的完成时间，将会被推迟到任务提交时间。

性能

对比 FileOutputCommitter V2 与 EMRFS S3-Optimized Committer， EMRFS S3-Optimized Committer 有1.6 倍的性能提升。
在这里插入图片描述

对比 FileOutputCommitter V1 与 EMRFS S3-Optimized Committer， EMRFS S3-Optimized Committer 有14.5 倍的性能提升。

在这里插入图片描述

作业的正确性

EMRFS S3-Optimized Committer 有与 FileOutputCommitter v2 相同的限制，因为两者都通过完全将提交责任委托给各个任务来提高性能。以下是对这种设计选择的显著后果的讨论。

部分结果不完整或失败作业
由于两个提交器都将任务写入最终输出位置，使用它们时，读取用户可以查看这个输出位置的部分结果。如果作业失败，在整个作业失败之前已提交的任何任务的部分结果将被保留下来。如果作业在不先清理输出位置的情况下再次运行，这种情况可能导致重复输出。

缓解此问题的一种方法是确保作业每次运行时使用不同的输出位置，仅在作业成功时才将位置发布给下游读取者。下面的代码块是针对使用Hive 表的工作负载的这种策略的示例。注意每次作业运行时 output_location 都设置为唯一值，并且仅在查询的其余部分成功时才注册表分区。只要读取者专门通过表抽象访问数据，他们就无法在作业完成之前看到结果。

SET attempt_id=<a random UUID>;
SET output_location=s3://bucket/${attempt_id};

INSERT OVERWRITE DIRECTORY ‘${output_location}’
USING PARQUET SELECT * FROM input;

ALTER TABLE output ADD PARTITION (dt = ‘2018-11-26’)
LOCATION ‘${output_location}’;