再谈Spark下写S3文件的File Output Committer问题

在《聊一聊Spark写文件的机制——如何保证数据一致性》一文中，我们分析了Spark写文件的机制，探讨了多个File Output Committer在性能与数据一致性上的权衡，以及针对AWS S3这样的对象存储的优化思路。文章结尾处，曾提到我们将会采用EMRFS S3-optimized Committer来解决Rename机制带来的性能与一致性问题。然而，最近在尝试使用这个Committer时，发现其并不如预期那么美好，存在诸多问题，这里将其总结下来，与诸位同道中人分享。

1. 前言

我们先来回顾下之前介绍过的三种Committer：FileOutputCommitter V1、FileOutputCommitter V2、S3A Committer，其基本代表了整体的演进趋势。

FileOutputCommitter V1，采用两次Commit的方式来保证较强的一致性，每次Commit都对应一次文件的Rename。每个Task先将数据写入到Task的临时目录下，写完后将其Rename到Job的临时目录下；所有Task都完成后，由Job负责将其临时目录下的所有文件Rename到正式目录下，此时文件对外可见。对于HDFS而已，Rename是一个十分高效的操作，然而对于S3这样的对象存储来说，则有着很大的代价。原因在于，S3本身并不是文件系统，不存在Rename操作，一个Rename操作需要分解为List + Copy + Delete操作。因此，对于S3而言，两次Rename有着非常大的性能开销。我们经常发现，Spark UI上看到各个Task已经结束了，但是Job就是迟迟不结束，有点像hang住了，其实就是在做第二次Rename。

FileOutputCommitter V2，在V1的基础上减去了第二次Rename，即每个Task先将数据写入到Task的临时目录下，写完后直接将其Rename到正式目录中；所有Task都完成后，Job只是写入一个_SUCCESS文件来标识已完成。显然，V2是牺牲一定的一致性来换取性能。因为，如果Spark Job在执行过程中失败了，就会出现部分成功的Task写入的文件对外可见，成为脏数据。

S3A Committer，最初由Netflix贡献给社区，采用S3 Multipart Upload机制替换了Rename机制。原因在于，对于S3而言，Rename不仅仅会带来性能问题，还可能因为S3的“最终一致性”特性而失败。社区版的这个Committer，会在每个Task中将数据先写入到本地磁盘，然后采用Multipart Upload方式上传到S3；所有Task都完成后，由Job统一向S3发送Complete信号，此时文件对外可见。

综合来看，使用Spark往S3写入文件时，应该尽量选择基于S3 Multipart Upload机制的Committer。在我们的系统中，主要采用AWS EMR来构建Spark集群，数据写入S3存储。EMR在5.19.0之后引入了EMRFS S3-optimized Committer，同样采用S3 Multipart Upload机制，因此我们会优先使用这个Committer。

本文所述均基于EMR5.29.0、Spark2.4.4。

2. AWS EMRFS S3-optimized Committer

EMRFS S3-optimized Committer，如AWS官方博客所言，其思想来自于S3A Committer，但是就目前的实现来看，坦白说，个人感觉比较鸡肋。一方面，这是官方出品，虽然不开源，但是相信其内部做了很多跟EMR集成的东西，因此我们通常会默认选择使用；另一方面，它有两个比较大的缺陷：

• 目前只能对部分符合条件的语法代码生效，比如只能是写Parquet文件，具体可以参考