• 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

  • 相关阅读:
    idae修改默认maven全局设置以及maven的设置
    LINUX 基本察看命令
    tar解压bz2文件报错
    kafka和zookeeper集群部署
    elasticsearch集群部署和kibana插件部署
    tomcat JVM调优
    搭建zookeeper集群的坑
    判断链表是否有环,以及求出入环节点
    判断一个数是否是完全二叉树
    堆排序
  • 原文地址:https://www.cnblogs.com/bianqi/p/12183630.html
Copyright © 2020-2023  润新知