聊聊HDFS BlockManager的服务化改造

前言

---

在现有的HDFS中，NameNode扮演着一个十分重要的角色。它不仅需要处理集群中所有文件相关的操作（此处可理解为INode相关的操作），它还要处理更小粒度级别的操作，也就是block块级别的操作。随着HDFS的快速迭代发展，它所需要执行的操作也越来越重了。另一方面，一旦集群的数据量规模大幅度扩展的时候，相应的INode文件、block块数据信息将会耗掉NameNode大量的内存，这将会大大降低HDFS的可扩展性。所以在这里，我们是否可以将文件服务与块服务完全独立开，毕竟块相关操作是一个更加底层的操作。在进一步地来说，如果真的要将文件服务于块服务完全独立开，这意味着要将BlockManager服务从原先的NameNode进程服务中脱离开，变成一个单一的服务。而它与原先的NameNode内相关联的操作就得需要RPC通信的方式来弥补了。本文笔者就聊聊BlockManager服务改造的一些想法，此想法源自于Hadoop社区早期的一些文档资料，个人感觉还是很有意思的。

NameNode内存占用分析

---

在介绍本文主要内容之前，我们不妨来看看几组有意思的数据，来直观地感受NameNode中文件、块数据所占用的内存开销。

假设目前我们有一个1EB（1EB=1024PB=2的60次方字节）数据量规模的集群，如果按照1台机器12块盘，每块盘5T来算（1个节点的容量就是12*5=60T），那么需要的总节点数量就为1024PB/60T=17476.26666666667，此处约等于17k的机器数量。这已经是一个很恐怖的数字了，我们知道，维护管理一个5000个节点的集群就已经是一个比较困难的事情，更何况是破万节点数的集群。

这里还没完，我们继续来看这么大规模数据量的情况下，它内部的文件、块数据的存储空间容量如何呢？

假设集群中每个块