hadoop 1000台集群优化经验---大数据面试

• 性能挑战

hdfs 是一个分布式系统，只要有足够的资源，可以扩容到上千台的集群，name node rpc queue time在持续的一周左右时间性能恶化。在极端环境下，出现一个rpc查询需要等待好几分钟。

to close file because the last block does not have enough number of replicas.

重启集群以后问题可以得到缓解，但是这个问题需要从根本上考虑如何解决。

• 性能优化

rpc变慢的根源在于hdfs的namenode的吞吐量和性能瓶颈。namenode存在最大吞吐量限制，每一次写的请求都会产生排它性写锁，强制其他任何操作必须在队列里等待它完成。namenode rpc queue time指标可以显示表达这个系统当前状态，对我们从代码和业务两方面进行优化。

• Datanode延迟块汇报

当datanode上新完成一个块，默认会立即汇报给namenode,在一个大规模的hadoop集群上，每时每刻都在写数据，datanode上随时都会有写完数据块汇报给namenode的情况，因此namenode处理datanode这种汇报请求，会频繁地持有锁，其实会非常影响共他rpc和响应时间。

优化方案

通过延迟块汇报配置datanode写完块后汇报次数，提高namenode处理rpc的响应时间和处理速度。

<property>
   <name>dfs.blockreport.incremental.intervalMsec</name>
   <value>300</value>
</property>

目前我们HDFS集群上此参数配置为300毫秒，就是当datanode新写一个块，不是立即汇报给namenode，而是要等待300毫秒，在此时间段内新写的块一次性汇报给namenode。

删除块个数配置：

由于hdfs的单一锁设计，nn对于大目录删除行为并没有表现出很好的执行效果。严重时甚至会出现长时间block其它应用的正常请求处理。hadoop新版本引入新结构foldedtreeset来存储数据，但它并利于update操作，因此删除问题在升级后的版本中体现更为明显了。

后续我们在研究HDFS删除块的行为中，发现NN在每次batch删除块的时候，是以固定size按照batch方式定期删除收集到的块信息。在每次batch间隙，其它请求就有机会得到NN锁的机会。于是我们考虑到一个改进手段，即是否能让batch size变得更加灵活可配置化，以此来控制给其它请求得到NN锁处理的概率。基于这个思路，我们新建了以下配置项，并改动了相关代码逻辑。

此优化也已经被我们贡献到Hadoop社区，相关JIRA链接：https://issues.apache.org/jira/browse/HDFS-13831（点击阅读原文即可进入页面）