hadoop起步耗时

hadoop启动耗时

http://blog.csdn.net/AE86_FC/archive/2010/08/08/5796622.aspx

背景
??? hadoop的HDFS系统结构里，namenode一直是一个单点，不管是单点出错还是单点性能方便，都是单点。这一直是HDFS想要达到7 * 24小时服务的最大的阻碍。在hadoop apache社区和仅有的那几家有能力把hadoop用到这种程度的人群里，对这一点的讨论也已经有很多了，有提出分布式namespace的，有提出 namenode单点热备的，有提出分布式mds(参考ceph和lustre)的，大家都为解决namenode的单点想了很多的办法。最近跟 facebook的Dhruba Borthakur（这位仁兄的名字实在是不会念，只好大家都叫他DB同学）讨论中发现，他们的hdfs也碰到了相同的问题，facebook目前拥有全球最大的hadoop集群，其中就有超过1200个slave节点，存储容量到12PB的HDFS集群，当集群储存的文件越来越多，block越来越多时，namenode单点的瓶颈就越来越明显。暂且不提由于单点的原因造成对namenode ?rpc调用带来的瓶颈（这一点得用更多的篇幅来记录了，相关测试数据和性能瓶颈分析以后再发好了），光就availability而言，每次集群修改了代码需要升级，或者例行升级，或者发生故障hdfs需要重启的时候，这个问题就凸现出来。

??? 熟悉namenode内部程序和逻辑的同仁们都知道（呵呵，我说的就是你们，你们懂的），namenode重启时主要耗时的有两个地方：

1. 对fsimage的加载，这个中间还包括对 editlog文件，edits.new文件的加载，然后和先前加载的fsimage做merge，最后save fsimage到磁盘的时间。这其中还不排除有secondarynamenode挂掉导致edits log文件变得奇大无比（我碰到的最大的居然有18G！），导致加载fsimage没多久，而load和merge editlog却需要花费几个小时的情况……（提到这个不得不说，以前还真是没有经验，遇到这种情况的时候居然不知道是因为 secondarynamenode挂掉导致的，还以为在上次checkpoint之后对hdfs的操作频繁到能够写18G editlog的程度……）。
2. 另外一个大头就是接收所有datanode通过 rpc发送过来的blockReport，这个才是namenode启动时最耗时的地方。因为namenode本身并没有持久化block和 datanode对应的mapping信息，所以namenode里最耗内存的blockMap的结构在启动时需要初始化就必须接收datanode的 blockReport，这个地方就是最耗时，也是最令人头疼，也是yahoo（非中国）和facebook，以及我司（就是“我们公司”的意思，这个词是从一位有着”活百科全书”的神一样的男子那引用来的）的同仁们讨论的最多，想象空间最大，改造和优化空间最大的地方。

数据
??? 这里有一组测试数据：

节点数存储容量文件和目录数fsimage加载时间blockReport时间120012PB7000 万10分钟左右35分钟左右6507PB4500 万6分钟左右30分钟左右

??? 由于测试数据和集群环境并非来自同一个地方，所有稍微有一些出入，但是总体能够看出，基本上影响HDFS 7 * 24 服务，High availability的瓶颈，就在这两个地方了。

查看更多 下一篇