2013-11-26 00:00:00
来 源
中存储
大数据
2013年11月22-23日,作为国内唯一专注于Hadoop技术与应用分享的大规模行业盛会,2013 Hadoop中国技术峰会(China Hadoop Summit 2013)于北京福朋喜来登集团酒店隆重举行。来自国内外各行业领域的近千名CIO、CTO、架构

2013年11月22-23日,作为国内唯一专注于Hadoop技术与应用分享的大规模行业盛会,2013 Hadoop中国技术峰会(China Hadoop Summit 2013)于北京福朋喜来登集团酒店隆重举行。来自国内外各行业领域的近千名CIO、CTO、架构师、IT经理、咨询顾问、工程师、Hadoop技术爱好者,以及从事Hadoop研究与推广的IT厂商和技术专家将共襄盛举。

                          京东Hadoop工程师刘涛

大会第二天上午主会场,来自京东商城的Hadoop工程师刘涛做了《京东Hadoop NameNode Cluster方案》演讲。刘涛从为什么要做这样的方案,我们方案是什么,我们如何解决这些问题的,我们解决过程中遇到的哪些问题等方面进行了详细的介绍。

刘涛谈到,为什么要做NameNode Cluster这样的方案呢?因为存储文件的增加,机器的内存会逐渐的增加,已经达到了内存的瓶颈,我们前段时间刚把NameNode 主机升到128个G,插条已经插满了,随着这样的增长可能是无法提供存储的服务了。另外的问题是对大内存的管理也是存在问题的,内存也不可能无限的增大,总会达到瓶颈的。

另一方面,随着集群规模的扩大,要管理的快以及要响应客户端的请求,之前的系统也有性能的瓶颈。这样两个方向把我们做成集群化的方案可能是比较好的方式,NameNode 集群化方案有很多已经出来了。对HDFS Federation是分离的两层架构的模式,不同的地方是区分了不同的子格。

另一个比较成熟的方案是,MapR,它的设计目标是简单应用、可靠、稳定,它的性能也是比Hadoop更快。已经有这样的现成方案的基础上,为什么还要做自己的集群化方案呢。我们在用的时候发现,对于之前如果是增加新的内容要进行重新的修改。我们希望以后的NameNode 的划分是可以动态的调整,这个东西可以做到对客户端对应用的透明性,对于MapR现在是非开源的版本。现在已经有很大规模的文件系统已经在上面了,如果要迁移上去,可能有一些迁移的工作,以及上面应用跑的业务也要考虑兼容性的问题。

这样的基础上起到自己的NameNode Cluster的方案,我们的改进是基于HDFS基础上的改进,所以还是保留了这样双层的结构,但是NameNode Cluster不同的地方是相对于静态的划分,我们系统需要去做到划分要做动态的扩展,屏蔽掉对用户的改动。

原来的NameNode 关于权限、目录、数据、节点和快的管理集合的功能分别的进行了重新的划分,让NameNode 关注于我们的目录结构和权限的管理。

如果我们实现了这样的系统,我们希望系统就具有这样的特性。NN做到不停机的维护和扩展,BM争取做到通用性的存储,BM之上意味着可以架设NN,也可以架设类似于S3这样的东西,希望做到通用的存储。以后完全可以根据现在访问的情况去增加我们的NameNode 节点。

我们要去实现把NameNode 进行划分,实现的过程中是引入了新的数据节点的类型,相对于原先的引入了新的方案,我们的NameNode存储的指数寻找到的其他的进程,NameNode 的进程,存的是URTC地址,如何实现目录式的划分,第一步是要把分出去的子的目录节点下的所有的子数,保存在一个空间,让其他的NameNode 进行加载,当NameNode,从而使自己本身维护的数据节点变少。

我们要实现对KN和ZX分离出去,会形成几个重新身份的子目录空间,中间不在包含分出去的部分,有K下面的KN和ZX。一个是我们的对于K和KN是对于原来的方案是不支持分离出来子目录有路径上的重合,我们是没有这样的限制条件。另外一方面我们分出去的N2、N3、N4,从分出的节点是没有存从它节点到根路径所有节点,这是考虑到如果存这样的全路径节点,以后对路径上层做一些目录的重命名或者是修改权限和用户的属性,这样会面临着现在是不能做这样的修改的,我们就没有存这个。那么另外一个问题,要需访问这部分数据,必须要先对它进行数据上的访问路径上重新的转换,接下来的问题如何去访问有的路径,但是路径被分配到其他的NameNode 上的问题。

我们每次访问的时候从根目录开始,从N找到K,我们引入了新的数据结构我们称之为“主干树”,它的含义是用来描述当前分布式文件系统,从虚拟节点到根节点完整的路径节点,不包含其他的不在虚拟节点路径上的部分,实际上只包含有限的几个节点,“主干树”本身所占的数据大小是比较小的,它可以被我们的客户端加载,也可以被我们的NameNode 加载,我们在做路径转换的时候也是要求客户端先去加载也许的“主干树”,NameNode 也要加载,根据“主干树”重新定位我们要访问的地方。

最后分成了几个数据结构,我们在主干树上找,能够匹配到最远虚拟节点的位置,再去找到多余的NN地址,从这个NN地址去发起访问,NN在收到响应请求的时候,先去做一个到本地的转换。对这样的情况,对我们的题目中的问题就会通过主干树到NN3,NN3做了路径展缓直到KN。

这样是对客户端路径的访问,可以做到对客户端,我们实现是把主干树用了单独的进程去管理保存的。每个节点的权限全都记录在主干树上,现在在验证权限的时候是由NameNode 先从主干树上,根据主干树先去进行验证,如果有权限再放到下一轮由NameNode 自己去验证权限的部分。我们可以实现最后的权限验证,采用这样的结构能够解决之前提到的问题,有天要去改虚拟节点到根路径上的某个目录的名字,或者是改上面的用户或者是改权限,直接通过修改主干树的功能达到这样的修改,也就可以让用户感受不到我们的变化。

之后是模式的完善和优化上,实际上是对我们来说,主干树因为是比较重要,是需要客户端都要保存的,因为这个东西要经常访问就有缓存,就会意味着管理的主干树变就会引入版本的验证和控制。我们最后会把这部分的东西独立出来,形成单独的RDB。

数据块独立的功能,对这样的内容是相对比较简单的,我们要把对应的关系进行重新的分配,我们增加一个Filed属性,我们做了一些完善和优化,分配全局每次给一个段范围的Filed,每次自己从这个段的Filed自己去递增的分配,当分配完了之后再请求分配新的段。

NameNode 汇报给BM的时候也不需要把所有的BM,我们结合了把实现了段的路由的功能整合到之前的进程中去,我们在这个基础上增加了High Availability,我们可以把这部分的工作放到RDB上做,由RDB去发现主或者是从,只需要从可用的NameNode 上去重新选一台机器,修改路由表进项的指向达到让访问重新定位一个问题。昨天听了安里同事体的NameNode 跨机房的方案,他们是从真实的实践的角度去解决问题的,这个听了之后受益匪浅。我下来也想了一下,我们的东西也可以去用来解决那样的问题,它如果跨机房我们在不同机房设置,启动不同的BM,其实在那个机房的。

下一步的工作系统并不完善,现在是比较依赖于共享存储的,我们希望一些自动化运维和管理上的工具,也期待大家和我们联系,让我们一起把系统做更加的完善。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。