HDFSFederation设计动机与基本原理.docxVIP

HDFS Federation是Hadoop最新发布版本Hadoop-0.23.0中为解决HDFS单点故障而提出的namenode水平扩展方案。该方案允许HDFS创建多个namespace以提高集群的扩展性和隔离性。本篇文章主要介绍了HDFS Federation的设计动机和基本原理。1. 当前HDFS概况1.1 当前HDFS架构当前HDFS包含两层结构：（1）?Namespace?管理目录，文件和数据块。它支持常见的文件系统操作，如创建文件，修改文件，删除文件等。（2）?Block Storage有两部分组成：Block Management维护集群中datanode的基本关系，它支持数据块相关的操作，如：创建数据块，删除数据块等，同时，它也会管理副本的复制和存放。Physical Storage存储实际的数据块并提供针对数据块的读写服务。【Block Storage的这两部分分别在namenode和datanode上实现，所以该模块由namenode和datanode分工完成】当前HDFS架构只允许整个集群中存在一个namespace，而该namespace被仅有的一个namenode管理。这个架构使得HDFS非常容易实现，但是，它（见上图）在具体实现过程中会出现一些模糊点，进而导致了很多局限性（下面将要详细说明），当然这些局限性只有在拥有大集群的公司，像baidu，腾讯等出现。1.2 当前HDFS局限性【Block Storage和namespace高耦合】当前namenode中的namespace和block management的结合使得这两层架构耦合在一起，难以让其他可能namenode实现方案直接使用block storage。【namenode扩展性】HDFS的底层存储是可以水平扩展的（解释：底层存储指的是datanode，当集群存储空间不够时，可简单的添加机器已进行水平扩展），但namespace不可以。当前的namespace只能存放在单个namenode上，而namenode在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。【性能】文件操作的性能制约于单个namenode的吞吐量，单个namenode当前仅支持约60K的task，而下一代Apache MapReduce将支持多余100K的并发任务，这隐含着要支持多个namenode。【隔离性】现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。单个namenode难以提供隔离性，即：某个用户提交的负载很大的job会减慢其他用户的job，单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。2. HDFS Federation2.1? 为什么采用Federation采用Federation的最主要原因是简单，Federation能够快速的解决了大部分单Namenode的问题。Federation 整个核心设计实现大概用了4个月。大部分改变是在Datanode、Config和Tools，而Namenode本身的改动非常少，这样 Namenode原先的鲁棒性不会受到影响。这使得该方案与之前的HDFS版本兼容。2.2? Federation架构为了水平扩展namenode，federation使用了多个独立的namenode/namespace。这些namenode之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的datanode被用作通用的数据块存储存储设备。每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。一个block pool由属于同一个namespace的数据块组成，每个datanode可能会存储集群中所有block pool的数据块。每个block pool内部自治，也就是说各自管理各自的block，不会与其他block pool交流。一个namenode挂掉了，不会影响其他namenode。某个namenode上的namespace和它对应的block pool一起被称为namespace volume。它是管理的基本单位。当一个namenode/nodespace被删除后，其所有datanode上对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级。2.3? Federation关键技术点【命名空间管理】Federation中存在多个命名空间，如何划分和管理这些命名空间非常关键。在Federation中并采用“文件名hash”的方法，因为该方法的local