欢迎关注Hadoop、Spark、Flink、Hive、Hbase、Flume等大数据资料分享微信公共账号:iteblog_hadoop
  1. 文章总数:1048
  2. 浏览总数:13,939,134
  3. 评论:4138
  4. 分类目录:109 个
  5. 注册用户数:6990
  6. 最后更新:2019年8月18日
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
iteblog_hadoop
大数据技术博客公众号bigdata_ai
开发爱好者社区:
bigdata_ai

Apache Hadoop 的 HDFS federation 前世今生(下)

《Apache Hadoop 的 HDFS federation 前世今生(上)》 已经介绍了 Hadoop 2.9.0 版本之前 HDFS federation 存在的问题,那么为了解决这个问题,社区采取了什么措施呢?

HDFS Router-based Federation

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。同时,这个层必须具有可扩展性,高可用性和容错性。

Router-based HDFS federation
如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:iteblog_hadoop

Federation layer 的设计架构如上图所示,从上图可以看出,这个层包含了多个组件:Router、State Store 以及 Rebalancing mechanisms。Router 组件和 Namenode 具有相同的接口,并根据 State Store 里面的信息将客户端请求转发到正确的子集群。State Store 是远程挂载表(remote mount table,和 ViewFS 方案里面的配置文件类似,但在客户端之间共享),存储子集群相关的信息包括 load/capacity。下面对这几个模块进行介绍。

Router

一个系统中可以包含多个 Router,每个 Router 主要包含两个作用:

  • 通过 Federated interface,Router 为客户端提供单个全局的 NameNode 接口,并将客户端的请求转发到正确子集群中的活动 NameNode 上;路由器接收到客户端的请求,然后检查 State Store 中是否有正确的子集群,并将请求转发到该子集群的活动 NameNode 上。路由器是无状态的,所以可以部署在负载均衡器后面并达到高可扩展性等。为了提高性能,路由器还会缓存远程挂载表里面的信息和子群集的状态。为确保 State Store 的更改可以传播到所有的路由器,每个路由器需要向 State Store 发送心跳信息。
  • 收集 NameNode 的心跳信息,报告给 State Store,这样 State Store 维护的信息是实时更新的。路由器也会定期检查 NameNode 的状态(通常位于同一服务器上),并将其高可用性(HA)状态和负载/空间状态报告给 State Store。为了实现高可用性和灵活性,多个路由器可以监视相同的 Namenode 并将心跳发送到 State Store,这种方式可以提高整个系统的可靠性,State Store 中冲突的 NameNode 信息是由每个 Router 通过 quorum 协议解决。
Router-based HDFS federation
如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:iteblog_hadoop

State Store

State Store 物理实现是分布式的,在 State Store 里面主要维护以下几方面的信息:

  • 子集群的状态,包括块访问负载,可用磁盘空间,HA状态等;
  • 文件夹/文件和子集群之间的映射,即远程挂载表;
  • Rebalancer 操作的状态;
  • Routers 的状态。

上面四点中的文件夹/文件和子集群之间的映射其实和 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 整个访问流程

上面已经简单的介绍了 Router-Based Federation 的各个组件等情况,下面我们来看看这个方案客户端访问文件的流程,如下所示:

Router-based HDFS federation
如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:iteblog_hadoop

图中的 R 代表 Router。当客户端需要进行读写操作,它的步骤如下:

  • 客户端向集群中任意一个 Router 发出某个文件的读写请求操作;
  • Router 从 State Store 里面的 Mount Table 查询哪个子集群包含这个文件,并从 State Store 里面的 Membership table 里面获取正确的 NN;
  • Router 获取到正确的 NN 后,会将客户端的请求转发到 NN 上,然后也会给客户端一个请求告诉它需要请求哪个 子集群;
  • 此后,客户端就可以直接访问对应子集群的 DN,并进行读写相关的操作。

由于 Router-based HDFS federation 还算比较新的特性,所以社区分了几个阶段修复或添加了一些新的功能,比如 Apache Hadoop 3.2.0 版本修复或添加了一些功能,参见 HDFS-12615,以及 Router-based HDFS federation 稳定性相关的 ISSUE HDFS-13891,这个 ISSUE 可能会在 Apache Hadoop 3.3.0 版本发布。

本博客文章除特别声明,全部都是原创!
转载本文请加上:转载自过往记忆(https://www.iteblog.com/)
本文链接: 【Apache Hadoop 的 HDFS federation 前世今生(下)】(https://www.iteblog.com/archives/2573.html)
喜欢 (1)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!