在maintain我们的daily spark jobs时，发现有的时候一些spark jobs在insert数据到hive table时会在所有tasks完成后hang住很长一段时间后整个job才结束。经过一些调查分析后，我们发现这段时间里，spark是在把.hive-staging_hive*/-ext-10000目录里的文件一个一个地move到hive table的location目录下，由于我们一些spark job生成的hive表的文件数据比较多（数万个）。正常情况下，这也不是什么大问题，这个moving过程总共也就消耗几分至十几分钟。但是，当namenode的负载特别高时，这个moving过程可能持续一个或几个小时，这就有点接受不了了。
问题
要解决问题，先要搞清楚问题的来龙去脉， 本文的目的就是为了搞清楚以下问题：
1. spark job是怎么commit每个write task的？
2. spark job是怎么commit整个write job的？
3. .hive-staging_hive*目录是在什么时候被move到hive table的location目录下的？
为了搞清楚以上问题，我们查阅了spark源码（版本为2.3.0）。
注意，本文的目的是讲清楚在我们遇到的scenario下，Spark InsertIntoHiveTable是如何commit结果数据的，对于其他不同配置导致的不同scenario，请读者自行阅读源码（文中会对我们的配置情况稍加说明）。
对于如何解决上面提到的hang住一个或几个小时的问题，最好的解决方案还是保证namenode的正常响应速度，在正常情况情况下，以上问题影响不大。
至于如何通过修改commit过程使得最终数据文件的moving耗时更短，读者可以在了解了commit具体过程后加以思考。
committer的生成
InsertIntoHive的run方法会调用其processInsert方法进行处理，processInsert会做一些validation和准备工作，然后会调用SaveAsHiveFile.saveAsHiveFile方法，saveAsHiveFile也会做一些准备工作，然后会生成一个FileCommitProtocol类型的committer对象：
这里使用了反射生成commiter对象：
这里的className就是前面SaveAsHiveFile.saveAsHiveFile中的sparkSession.sessionState.conf.fileCommitProtoclClass, 这个值由参数spark.sql.sources.commitProtocolClass控制， 默认为SQLHadoopMapReduceCommitProtocol :
SQLHadoopMapReduceCommitProtocol继承自HadoopMapReduceCommitProtocol， 只是重写了其setupCommitter方法，setupCommitter方法的作用是生成HadoopMapReduceCommitProtocol内部的committer对象，而这个对象是OutputCommitter类型，其commitTask和commitJob方法会被用于commit每个task的结果和整个job的结果。
注意，这里其实是有两层committer，一层是HadoopMapReduceCommitProtocol内部的committer，另一层就是HadoopMapReduceCommitProtocol本身。在HadoopMapReduceCommitProtocol的commitTask和commitJob方法中都会直接或间接地调用其内部commiter对象的对应方法：
因为在我们的case中主要是依靠内部committer来进行结果数据文件的moving，所以本文主要关注内部committer（也就是OutputCommitter）的commit行为，对于HadoopMapReduceCommitProtocol层的commit行为，读者可阅读HadoopMapReduceCommitProtocol的commitTask, commitJob, newTaskTempFile, newTaskTempFileAbsPath等方法，可以结合FileFormatWriter中的DynamicPartitionWriteTask和SingleDirectoryWriteTask的newOutputWriter方法一起阅读。
task的commit
前面讲到，我们主要看OutputCommitter的commit行为，OutputCommitter是一个抽象类，我们主要来看一下其子类org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter的实现。
FileOutputCommitter的commitTask方法将单个task attempt生成的结果数据文件move到指定的committedTaskPath 或者 outputPath：
注意，commitTask这里的行为受变量algorithmVersion控制，而这个变量的值由参数mapreduce.fileoutputcommitter.algorithm.version控制，可选值为1和2. 在我们的scenario下，该值为2，所以最终调用了mergePaths方法把task attempt的输出目录中的数据文件都move到outputPath下面。
这里的outputPath就是对应的.hive-staging_hive*下的目录, 比如：/path/to/table/location/.hive-staging_hive_2020-05-03_16-14-42_568_1802626970789985228-1/-ext-10000. 而task attempt的输出目录是.hive-staging_hive*下的针对每个task attempt创建的临时目录，比如：/path/to/table/location/.hive-staging_hive_2020-05-03_16-14-42_568_1802626970789985228-1/-ext-10000/_temporary/0/_temporary/attempt_20200503162201_0005_m_000065_0.
FileOutputCommitter.mergePaths的功能就是把源路径（可以是目录，也可以是文件）的所有文件都move到目标路径下，如果源和目标有冲突，则以源覆盖目标，可以看看这个函数的code，其实就是个递归实现。
至此，我们知道了，对于InsertIntoHiveTable的每个task，在它执行完后都会把自己的结果文件从task attempt的临时folder移到.hive-staging_hive*/-ext-10000中来。每个task都只负责move自己生成的数据文件，这个过程也是各个task并行进行的。
job的commit
上面讲述了单个task如何commit自己的数据文件，那么当一个job的所有task都完成commit后，这个job的commit又做了些什么呢？
主要逻辑在commitJobInternal中实现：
对于algorithmVersion为2的情况，因为在FileOutputCommitter.commitTask方法中已经调用mergePaths将task生成的数据文件merge到了.hive-staging_hive_*/-ext-10000下面，所以在commitJob中，对于algorithmVersion为2的情况，只需要清理_temporary目录并创建_SUCCESS的marker文件。
.hive-staging_hive目录中文件的moving
如上文所述，InsertIntoHive的processInsert会调用SaveAsHiveFile.saveAsHiveFile进行hive 文件的写入，写入的文件最终都会commit到.hive-staging_hive*/-ext-10000目录中，那么.hive-staging_hive*目录又是怎么被move到hive table的location目录下的呢？这个工作是在processInsert方法调用完SaveAsHiveFile.saveAsHiveFile之后，再通过调用org.apache.hadoop.hive.ql.metadata.Hive的loadDynamicPartitions方法完成的。
总结
通过上述分析，我们知道了：
1. 对于spark的InsertIntoHiveTable，结果rdd的每个partition的数据都有相应的task负责数据写入，而每个task都会在目标hive表的location目录下的.hive-staging_hive*/-ext-10000目录中创建相应的临时的staging目录，当前task的所有数据都会先写入到这个staging目录中；
2. 当单个task写入完成后，会调用FileOutputCommitter.commitTask把task的staging目录下的数据文件都move到.hive-staging_hive*/-ext-10000下面，这个过程就是单个task的commit
3. 当一个spark job的所有task都执行完成并commit成功后，spark会调用FileOutputCommitter.commitJob把临时的staging目录都删除掉，并创建_SUCCESS标记文件
4. 当spark成功将数据都写入到staging_hive*/-ext-10000中 （也就是commitJob成功后），spark会调用hive的相应API把数据文件都move到目标hive表的location目录下，并更新hive meta data以enable新的hive partition
