hdfs问题之namenode

随着集群中数据规模的不断积累，NameNode内存占用随之成比例增长。不可避免的NameNode内存将逐渐成为集群发展的瓶颈，并开始暴漏诸多问题。

1、启动时间变长。NameNode的启动过程可以分成FsImage数据加载、editlogs回放、Checkpoint、DataNode的BlockReport几个阶段。数据规模较小时，启动时间可以控制在~10min以内，当元数据规模达到5亿（Namespace中INode数超过2亿，Block数接近3亿），FsImage文件大小将接近到20GB，加载FsImage数据就需要~14min，Checkpoint需要~6min，再加上其它阶段整个重启过程将持续~50min，极端情况甚至超过60min，虽然经过多轮优化重启过程已经能够稳定在~30min，但也非常耗时。如果数据规模继续增加，启动过程将同步增加。

2、性能开始下降。HDFS文件系统的所有元数据相关操作基本上均在NameNode端完成，当数据规模的增加致内存占用变大后，元数据的增删改查性能会出现下降，且这种下降趋势会因规模效应及复杂的处理逻辑被放大，相对复杂的RPC请求（如addblock）性能下降更加明显。

3、NameNode JVM FGC（Full GC）风险较高。主要体现在两个方面：（1）FGC频率增加；（2）FGC时间增加且风险不可控。针对NameNode的应用场景，目前看CMS内存回收算法比较主流，正常情况下，对超过100GB内存进行回收处理时，可以控制到秒级别的停顿时间，但是如果回收失败被降级到串行内存回收时，应用的停顿时间将达到数百秒，这对应用本身是致命的。

4、超大JVM Heap Size调试问题。如果线上集群性能表现变差，不得不通过分析内存才能得到结论时，会成为一件异常困难的事情。且不说Dump本身极其费时费力，Dump超大内存时存在极大概率使NameNode不可服务。

针对NameNode内存增长带来的诸多问题，社区和业界都在持续关注并尝试不同的解决方案。整体上两个思路：（1）扩展NameNode分散单点负载；（2）引入外部系统支持NameNode内存数据。

从2010年开始社区就投入大量精力持续解决，Federation方案[3]通过对NameNode进行水平扩展分散单点负载的方式解决NameNode的问题，经过几年的发展该方案逐渐稳定，目前已经被业界广泛使用。除此之外，社区也在尝试将Namespace存储值外部的KV存储系统如LevelDB[4]，从而降低NameNode内存负载。

除社区外，业界也在尝试自己的解决方案。Baidu HDFS2[5]将元数据管理通过主从架构的集群形式提供服务，本质上是将原生NameNode管理的Namespace和BlockManagement进行物理拆分。其中Namespace负责管理整个文件系统的目录树及文件到BlockID集合的映射关系，BlockID到DataNode的映射关系是按照一定的规则分到多个服务节点分布式管理，这种方案与Lustre有相似之处（Hash-based Partition）。Taobao HDFS2[6]尝试过采用另外的思路，借助高速存储设备，将元数据通过外存设备进行持久化存储，保持NameNode完全无状态，实现NameNode无限扩展的可能。其它类似的诸多方案不一而足。

尽管社区和业界均对NameNode内存瓶颈有成熟的解决方案，但是不一定适用所有的场景，尤其是中小规模集群。结合实践过程和集群规模发展期可能遇到的NameNode内存相关问题这里有几点建议：

1. 合并小文件。正如前面提到，目录/文件和Block均会占用NameNode内存空间，大量小文件会降低内存使用效率；另外，小文件的读写性能远远低于大文件的读写，主要原因对小文件读写需要在多个数据源切换，严重影响性能。

2. 调整合适的BlockSize。主要针对集群内文件较大的业务场景，可以通过调整默认的Block Size大小（参数：dfs.blocksize，默认128M），降低NameNode的内存增长趋势。

3. HDFS Federation方案。当集群和数据均达到一定规模时，仅通过垂直扩展NameNode已不能很好的支持业务发展，可以考虑HDFS Federation方案实现对NameNode的水平扩展，在解决NameNode的内存问题的同时通过Federation可以达到良好的隔离性，不会因为单一应用压垮整集群。