标签：img 方式 读写 log lock 通信 生态圈 org 凭证
目前大数据和云计算是当下讨论非常火热的2个词，笔者也非常相信在未来的时间内，以Hadoop系统生态圈为代表的大数据工具，将会被更多的企业所使用。在一些更大规模的公司，已经将大数据与云联系在了一起了，举个例子，我们将数据存储在HDFS内，然后在定期同步到云上，相当于云端存储的数据是一个back store。这样做的一个好处是防止本地集群的数据遭到意外的破坏或丢失，至少在云端我们还有备份。或者有另外的一些做法是，我们通过一层适配操作，将用户写入集群的数据直接就写到了远端的云上，但是对于用户而言它是无感知的。目前Hadoop系统中有这个方面的工程，比如hadoop-tools父工程下的hadoop-aws和hadoop-aliyun，分别针对的云服务就是亚马逊的S3和阿里云的OSS服务。面对此类的使用场景，社区在HDFS-9806提出了跨外部存储系统的多层级存储设计。本文笔者就来简单聊聊此话题。如果我们想在HDFS内部支持外部存储介质的读写，我们可以怎么实现呢？
如果HDFS支持了跨外部系统的存储，也就是说，我们能够通过HDFS提供的API将数据写到外部的存储系统中，它可能是一个云上的存储服务，又或者说是一个简单的k-v存储系统。但是不管目标存储系统的存储形如何，它在HDFS内部的命名空间一定是全局一致的，用户还是通过在某个路径下去读写文件。只是这些文件到底是HDFS集群内的数据还是说是外部存储系统内的。所以这里会有一个映射的概念，这点非常类似于笔者之前提过的Hadoop的ViewFS特性。这相当于在HDFS全局的命名空间树内，绝大部分是系统自身路径，而个别目录是挂载到外部的路径上的。如图所示。
这就好比在一台机器上，绝大部分目录都是DISK磁盘类型的，但我们可以挂载一些目录到SSD盘上。当我们想将数据存储到SSD类型的盘上时，我们直接将数据写入与之对应的目录下即可。
基于前面部分的种种假设，我们能够以何种的方式去实现数据跨外部存储系统的读写呢？数据的整体过程与原来的方式大体相同，但是DataNode需要额外执行与远端存储系统进行数据读写的操作。因为很显然，外部存储系统的数据当然不会存在DataNode本地节点上。但是在逻辑上，这些外部存储的数据是属于此节点的。当用户想要从远端的存储系统上读数据时，NameNode还是会寻找这样一批在“逻辑上”拥有此数据的DataNode。下图是HDFS内部跨存储系统通信的整体架构设计。
前面两小节笔者主要阐述了HDFS跨文件系认存储的比较宏观上的设计，下面来聊聊几个比较细的点，有哪些细节需要我们马上需要考虑的呢？
外部存储系统有着各自维护的文件信息结构，这个本身与HDFS自身内部的一定有所不同，所以这里我们需要对HDFS文件块到外部存储文件做一个映射。而且这个映射图还要能够更新，因为外部存储的文件信息是会可能发生变化的。
之前笔者也已经提到过，我们要让DataNode”逻辑上”拥有此块，但是其本身是不存储其物理数据的，而目前DataNode现有的目录StorageType都是完全物理存储在节点本地的，所以我们需要定义一个新的StorageType，比如说PROVIDED，来表明此标签路径下的数据为远端的存储路径。而一旦引入这个新的StorageType的话，现有的FSVolume等类必须做一定的调整，最好的方式是定义一个专门继承类来实现基础的接口。
在大多数情况下，安全问题都是需要引起大家重视的问题，更何况是现在涉及到外部存储通信的情况。针对这点，在HDFS社区的设计文档中，提出了以下2大方向：
归纳地来说，不管使用上述的哪种方式，我们最终要确保的一点是HDFS自身能够有足够的权限来读写外部的存储系统，可以是HDFS内部统一维护的一个身份。
如果HDFS最后真的实现了支持跨文件系统的多层级存储，那么对于用户而言，无疑是多了更多的存储策略的选择。比如说，我们完全可以用更高密度的外部存储方式来存储集群中的冷数据。尽管说目前HDFS已经定义了ARCHIVE的StorageType来针对此类数据的存储，但是这类数据还是会保留在NameNode的命名空间内并被NameNode所管理。如果说我们可以完全将此数据移到外部的存储中，那无疑将会是更优的选择。
[1].Allow HDFS block replicas to be provided by an external storage system, https://issues.apache.org/jira/browse/HDFS-9806.
标签：img 方式 读写 log lock 通信 生态圈 org 凭证
原文地址：http://blog.csdn.net/androidlushangderen/article/details/68957948
