【IT168现场报道】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，其实在那个机房的。

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

　　谢谢大家！