前言
Hadoop发展至今，它所涵盖的周边生态圈已经非常庞大了。但是作为一套目前看来如此成熟的系统，免不了要做一些兼容性的事情，比如一些第三方服务类型的系统。毕竟有些用户会使用到第三方的系统，但又不想去改变现有程序运行的模式以及学习第三方系统的成本。Hadoop作为一个如此成熟的项目，在兼容其它第三方系统上，肯定是有考虑到。今天，笔者就来讲讲目前Amazon S3服务与Hadoop的集成兼容性问题。
S3Guard：基于Hadoop之上运行Amazon S3
这里要提到一个名词：S3Guard。它其实是Hadoop内部实现的一个新特性：帮助S3服务能够运行于Hadoop系统之上。简单的理解就是，Hadoop能够以S3作为底层存储的文件系统，而S3Guard，做的就是一个Hadoop兼容性文件系统的工作。这么说的话，大家应该能够更好理解一些了吧。
问题：S3与HDFS的一致性问题
在做这样一个兼容性系统的工作中，一个主要的问题是解决S3与HDFS的一致性保证问题。这话怎么理解呢？S3与HDFS不同，HDFS是强一致性的，比如说我们执行了一个创建文件的操作后，然后去list这个文件，文件是能够被立马显示出来的。而S3是最终一致性保证的，它就不能保证在创建动作结束后，能够立刻list出之前的文件，而是需要delay一段时间。这倒不是说S3服务这块做的不如HDFS什么的，而是说不同系统的内部结构，设计的不同罢了。所以问题来了，基于Hadoop的任务是依赖于HDFS这种强一致性保证的，那我们肯定要在这方面做到一定的兼容性吧。这就是S3Guard主要做的事情。
S3Guard的一致性保证实现
S3Guard在这里使用的一个办法是使用一个额外的Metadata Store，来记录元数据的改动。也就是说，在当前系统中，会有2份元数据目录树，如下图所示：
我们还是以刚才的创建文件为例子。假设目前现有文件/a/b/exists,然后此时我们执行了一步创建文件file操作在/a/b目录下，在S3内部的记录如下，不会立即更新，因为是最终一致性，会有一定的延时。而在额外的metadata store中，我们就可以直接在上面做记录，如下图。
创建完文件操作后，当我们对/a/b执行list操作时，S3Guard将会同时向S3和额外的metadata store查询元数据，然后进行结果汇总。
那么其实还有一种特殊的情况：删除文件的情况。S3Guard采用的做法是添加一个删除的标记。然后合并结果的时候，根据此标记把相应的文件剔除掉，如下图。
这就是S3Guard一致性保证工作的一个实现原理，更多细节可以阅读社区设计文档和JIRA。
参考资料
[1].http://blog.cloudera.com/blog/2017/08/introducing-s3guard-s3-consistency-for-apache-hadoop/. Introducing S3Guard: S3 Consistency for Apache Hadoop
[2].https://issues.apache.org/jira/secure/attachment/12821464/S3GuardImprovedConsistencyforS3AV2.pdf”
[3].https://issues.apache.org/jira/browse/HADOOP-13345. S3Guard: Improved Consistency for S3A