AWS S3存储基于Hadoop之上的一致性保证

前言


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

猜你喜欢

转载自blog.csdn.net/androidlushangderen/article/details/79938065