熟悉大数据的人应该都知道,HDFS 是一个分布式文件系统,它是基于谷歌的GFS实现的开源系统,设计目的就是提供一个高度容错性和高吞吐量的海量数据存储解决方案。在经典的HDFS架构中有2个NameNode和多个DataNode,如下
从上面可以看出 HDFS 的架构其实大致可以分为两层:
虽然这个架构可以很好的处理海量的大数据存储,但是当文件比较多,特别是集群运行了很长时间产生大量小文件的情况下,这种架构的 NameNode就会产生很严重的问题。这是因为集群中数据的元数据(比如文件由哪些块组成、这些块分别存储在哪些节点上)全部都是由 NameNode节点维护,为了达到高效的访问,NameNode在启动的时候会将这些元数据全部加载到内存中。而HDFS中的每一个文件、目录以及数据块,在NameNode内存都会有记录,每个数据块的信息大约占用150字节的内存空间。当NameNode维护的目录和文件总量达到1亿,数据块总量达到4亿后,常驻内存使用量将达到90GB!这将严重影响HDFS集群的扩展性。
任何一方面,单个NameNode提供读写访问请求,也会影响整个HDFS集群的吞吐量。同时,这种架构中所有租户共享一个命名空间namespace,无法对不同的应用程序进行隔离。
为了解决 HDFS 的水平扩展性问题,社区从 Apache Hadoop 0.23.0 版本开始引入了 HDFS federation(参见 HDFS-1052)。HDFS Federation 是指 HDFS 集群可同时存在多个 NameNode/Namespace,每个 Namespace 之间是互相独立的;单独的一个 Namespace 里面包含多个 NameNode,其中一个是主,剩余的是备,这个和上面我们介绍的单 Namespace 里面的架构是一样的。这些 Namespace 共同管理整个集群的数据,每个 Namespace 只管理一部分数据,之间互不影响。
集群中的 DataNode 向所有的 NameNode 注册,并定期向这些 NameNode 发送心跳和块信息,同时 DataNode 也会执行 NameNode 发送过来的命令。集群中的 NameNodes 共享所有 DataNode 的存储资源。HDFS Federation 的架构如下图所示:
通过 HDFS Federation 架构可解决单 NameNode 存在扩展性、业务隔离以及性能等问题。关于如何配置 HDFS Federation 可以参见这里。
这个版本的 HDFS Federation 虽然能够解决单 Namespace 带来的一些问题,但是又引来了新的问题。比如现在集群中存在多个 Namespace,每个 Namespace 管理一部分数据,那客户端如何知道要查询的数据在哪个 Namespace 上呢?为了解决这个问题,社区引入了视图文件系统(View File System,简称 ViewFs),具体可以参见 HADOOP-7257。ViewFs 类似于某些 Unix / Linux 系统中的客户端挂载表。ViewFs 可用于创建个性化命名空间视图,也可用于创建每个群集的公共视图。那 ViewFs 是如何解决文件映射到对应的 Namespace 上呢?
ViewFs 通过在 core-site.xml 文件里面引入了路径映射配置,如下:
正如上面的配置文件所示,在启用了 HDFS Federation 的集群,fs.defaultFS
的值已经变成了 viewfs://clusterX
,这个和未启用 HDFS Federation 的集群是不一样的。然后紧接着配置了五个属性,用于指定文件和集群的映射关系。
比如用户访问了 /data
路径,那么通过这个配置文件,我们就知道直接到 hdfs://nn1-clusterx.iteblog.com:8020
集群的 /data
路径下拿数据;当用户访问 /iteblog
,那么通过这个配置文件,我们就知道直接到 hdfs://nn2-clusterx.iteblog.com:8020
集群的 /iteblog
路径下拿数据。其他路径的数据获取和这个类似。如果访问的路径在配置文件里面没找到,那么将会访问 fs.viewfs.mounttable.ClusterX.linkFallback
属性配置的集群和路径进行访问。关于详细的 ViewFs 配置可以参见 官方文档
ViewFs 方案虽然可以很好的解决文件命名空间问题,但是它的实现有以下几个问题:
为了解决这个问题,社区从 Hadoop 2.9.0 和 Hadoop 3.0.0 版本开始引入了一种基于路由的 Federation方案(Router-Based Federation),具体参见 HDFS-10467,这个方案主要是由微软和优步的工程师实现。和之前的 ViewFS 不一样,这个是基于服务端实现的。
基于路由的 Federation 方案是在服务端添加了一个 Federation layer,这个额外的层允许客户端透明地访问任何子集群,让子集群独立地管理他们自己的 block pools,并支持跨子集群的数据平衡。为实现这些目标,Federation layer 必须将块访问路由到正确的子集群,维护 namespaces 的状态,并提供数据重新平衡的机制,跨集群的数据平衡可以参见 HDFS-13123。同时,这个层必须具有可扩展性,高可用性和容错性。
Federation layer 的设计架构如上图所示,从上图可以看出,这个层包含了多个组件:Router、State Store 以及 Rebalancing mechanisms。Router 组件和 Namenode 具有相同的接口,并根据 State Store 里面的信息将客户端请求转发到正确的子集群。State Store 是远程挂载表(remote mount table,和 ViewFS 方案里面的配置文件类似,但在客户端之间共享),存储子集群相关的信息包括 load/capacity。下面对这几个模块进行介绍。
一个系统中可以包含多个 Router,每个 Router 主要包含两个作用:
State Store 物理实现是分布式的,在 State Store 里面主要维护以下几方面的信息:
上面四点中的文件夹/文件和子集群之间的映射其实和 ViewFS 里面的远程挂载表类似,内容如下:
hdfs://tmp → hdfs://C0-1/tmp /* Folder tmp is mapped to folder tmp in subcluster C0-1 */
hdfs://share → hdfs://C0-2/share
hdfs://user/iteblog → hdfs://C0-3/user/iteblog
hdfs://user/user2 → hdfs://C0-2/user2
通过这些我们就可以知道数据在哪个子集群,针对这些信息的存储 Hadoop 为我们提供了几种实现,包括基于文件(StateStoreFileSystemImpl)的和基于ZK(StateStoreZooKeeperImpl)的方式,可以通过 dfs.federation.router.store.driver.class 参数配置。关于 Router-Based Federation 更多的情况请访问 Hadoop 的官方文档。
上面已经简单的介绍了 Router-Based Federation 的各个组件等情况,下面我们来看看这个方案客户端访问文件的流程,如下所示:
图中的 R 代表 Router。当客户端需要进行读写操作,它的步骤如下:
由于 Router-based HDFS federation 还算比较新的特性,所以社区分了几个阶段修复或添加了一些新的功能,比如 Apache Hadoop 3.2.0 版本修复或添加了一些功能,参见 HDFS-12615,以及 Router-based HDFS federation 稳定性相关的 ISSUE HDFS-13891,这个 ISSUE 可能会在 Apache Hadoop 3.3.0 版本发布。