Router-Based HDFS Federation 在滴滴大数据的应用

最新推荐文章于 2024-07-02 07:54:28 发布

付江

最新推荐文章于 2024-07-02 07:54:28 发布

阅读量1.8k

点赞数

分类专栏：大数据数据库架构文章标签： HDFS Hadoop 大数据开源

本文链接：https://blog.csdn.net/java060515/article/details/86000626

版权

本文介绍了滴滴如何应对HDFS单点瓶颈，采用Router-Based Federation方案解决扩展性、性能和隔离问题。该方案基于服务端的Router组件和State Store组件，提供统一命名空间，具有高可用性和容错性。滴滴在实际应用中进行了部署、兼容性改造，并对方案进行优化，贡献了多个补丁到社区。

摘要由CSDN通过智能技术生成

一、背景

HDFS 的 Master/Slave 架构，使得其具有单点瓶颈，即随着业务数据的大规模膨胀，Master 节点在元数据存储与提供服务上都会存在瓶颈。为了克服 HDFS 单点瓶颈存在的扩展性、性能、隔离问题，社区提出了Federation（https://issues.apache.org/jira/browse/HDFS-1052 ）方案来进行解决。

但是使用该方案之后，暴露给客户的问题就是，同一个集群出现了多个命名空间（namespace），客户需要知道读写的数据在哪个命名空间下才可以进行操作。为了解决统一命名空间的问题，社区提出了基于客户端（client-side）的解决方案 ViewFS（https://issues.apache.org/jira/browse/HADOOP-7257 ），该方案会在客户端做好配置，用户目录一对一的挂载到具体的命名空间目录上，滴滴在解决 Federation 问题时使用的就是这个方案。

ViewFS 方案也存在一些问题：

对于已经发布出去客户端升级比较困难；
对于新增目录需要增加挂载配置，与产品对接，维护起来比较困难。

社区在 2.9 和 3.0 版本中发布了一个新的解决统一命名空间问题的方案 Router-Based Federation（https://issues.apache.org/jira/browse/HDFS-10467 ），该方案是基于服务端进行实现的，在升级管理方面比较好维护，滴滴最近引入了该方案，并进行了一些改造。

二、Router-Based Federation 方案介绍

Router-Based Federation 对外提供了 Router 服务，包含在 Federation layer 中，如下图所示。这个 Router 服务将允许用户透明地访问任何子集群，让子集群独立管理自己的 Blockpool。为了实现这些目标，Federation layer 必须将 Block 访问引导至适当的子群集。同时，它具有可扩展性，高可用性和容错性。

在这里插入图片描述