HDFS Federation是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 Federation
2.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”的办法,由于该办法的locality十分差,比方:检查某个目录下面的文件,假如选用文件名hash的办法寄存文件,则这些文件或许被放到不同namespace中,HDFS需求拜访一切namespace,价值过大。为了便利办理多个命名空间,HDFS Federation选用了经典的Client Side Mount Table。
如上图所示,每个深色三角形代表一个独立的命名空间,上方淡色的三角形代表从客户视点去拜访下方的子命名空间。各个深色的命名空间Mount到淡色的表中,客户能够拜访不同的挂载点来拜访不同的命名空间,这就如同在Linux体系中拜访不同挂载点相同。这便是HDFS Federation中命名空间办理的根本原理:将各个命名空间挂载到大局mount-table中,就能够做将数据到大局同享;相同的命名空间挂载到个人的mount-table中,这就成为运用程序可见的命名空间视图。
2.4 首要长处
【扩展性和阻隔性】
支撑多个namenode水平扩展整个文件体系的namespace。可依照运用程序的用户和品种别离namespace volume,从而增强了阻隔性。
【通用存储服务】
Block Pool笼统层为HDFS的架构敞开了立异之门。别离block storage layer使得:
<1> 新的文件体系(non-HDFS)能够在block storage上构建
<2> 新的运用程序(如HBase)能够直接运用block storage层
<3> 别离的block storage层为将来彻底分布式namespace打下根底
【规划简略】
Federation 整个中心规划完结大约用了4个月。大部分改动是在Datanode、Config和Tools中,而Namenode自身的改动十分少,这样 Namenode原先的鲁棒性不会受到影响。尽管这种完结的扩展性比起真实的分布式的Namenode要小些,可是能够无能为力满意需求,别的Federation具有杰出的向后兼容性,已有的单Namenode的布置装备不需求任何改动就能够持续作业
3. HDFS Federation缺乏
【单点故障问题】
HDFS Federation并没有彻底处理单点故障问题。尽管namenode/namespace存在多个,可是从单个namenode/namespace看,依然存在单点故障:假如某个namenode挂掉了,其办理的相应的文件便不能够拜访。Federation中每个namenode依然像之前HDFS上完结相同,配有一个secondary namenode,以便主namenode挂掉一下,用于复原元数据信息。
【负载均衡问题】
HDFS Federation选用了Client Side Mount Table分摊文件和负载,该办法更多的需求人工介入已达到抱负的负载均衡。
原文链接:http://shitouer.cn/2012/12/HDFS-federation-introduction/
【修改引荐】
- 分布式文件体系HDFS规划
- 分布式文件体系HDFS中Block介绍
- HBase规划:看上去很美
- 三种东西永久不要放到数据库里
- 没有数据驱动的流程和产品 大数据将毫无价值