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时间
1200	12PB	7000 万	10分钟左右	35分钟左右
650	7PB	4500 万	6分钟左右	30分钟左右

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