基于 Alluxio 的 HDFS 多集群统一入口的实现

本文作者郭业俊,同济大学自动化专业硕士毕业,现担任苏宁易购大数据存储平台负责人。主要负责苏宁Hadoop分布式文件系统方面的优化开发,通过Alluxio实现了HDFS多集群的路由功能,满足了苏宁大规模、高并发的存储需求。在大数据架构方面拥有多年的实战经验,曾在Intel从事Spark的仿真模型的开发和利用。始终专注于分布式计算架构、大规模存储方面的学习和研究。

1 简介

随着苏宁大数据平台的规模越来越大,HDFS集群Namenode逐渐出现性能瓶颈,特别是在凌晨任务的高并发期,Namenode的RPC响应延迟较高,单次写RPC请求甚至超过1s,严重影响了集群的计算性能。因此解决HDFS的扩展性问题,势在必行。

本文将介绍在苏宁我们是怎么解决这个问题的,主要从以下几个方面来展开:

  • 单一的HDFS集群存在的问题和挑战,以及原因分析;

  • 将单一的集群拆分成多集群需要考虑的问题,以及多集群的方案对比;

  • 如何利用Alluxio的统一命名空间来实现HDFS多集群的统一入口;

2 单一HDFS集群的瓶颈和挑战

下图为苏宁大数据平台的软件栈,与其他各家友商的平台大同小异。HDFS作为苏宁大数据平台的底层存储系统,集群达到1500+台Datanode(48TB),已使用30+PB的空间,存储了1.8亿的文件和1.8亿的块,每天运行的任务量接近40万。在凌晨计算高峰期,对Namenode最大并发请求量为3万+。

苏宁大数据平台软件栈

我们使用的Hadoop-2.4.0的版本,下图是HDFS RPC请求及处理的流程图。

HDFS RPC请求及处理流程

从图中可以看到,导致NameNode RPC响应延迟高的原因主要有:

  • 所有对Namenode元数据的写请求都需要获取FSNameSystem的写锁,并发高的情况下,等待锁资源会消耗较长的时间;

  • EditLog和Auditlog的同步写;

下图是我们HDFS集群某一天写请求响应时间的统计图。从图中可以看到,在凌晨3点到5点,RPC的响应时间持续在500ms左右,对上层的任务影响较大。

HDFS Namenode 写请求的RPC响应时间

针对高峰期Namenode RPC响应延迟高的问题,我们做了如下优化:

  • 优化任务,减小对HDFS的读写次数,特别是使用动态分区的任务;

  • 将audit log由同步改成异步;

  • 设置fsImage的合并时间为1小时;

  • disable掉文件系统access time的更新功能;

通过上面的优化,性能有所提升,但是并没有达到我们预期,高峰期RPC延迟仍然很高,我们开始考虑多集群方案。

3 多集群方案调研

设计多集群方案时,我们主要考虑的问题有:

  • 如何做到对用户透明;

  • 如何做到跨集群的数据访问;

  • 集群按照何种维度进行切分;

  • 系统的稳定性;

  • 运维的复杂度;

带着以上问题,我们对社区已有方案进行了调研和对比。

3.1 Federation+Viewfs

该方案在Hadoop-2.4.0版本中已经存在,是基于客户端的配置来实现的。

优点是:

  • 可以做到对用户无感知;

  • 通过客户端的Viewfs可以实现跨集群的数据访问;

  • 很多公司在生产环境中使用,稳定性有保证;

缺点是:

  • 基于客户端配置实现,集群规模越大,账户越多,运维的复杂度会越来越高。

3.2 HDFS Router

在Hadoop-2.9.0的版本中,发布了一个新的feature -- HDFS Router。该方案将路由表做在了服务端,所有的RPC请求都先到Router,Router根据路由表的解析结果对RPC请求进行转发。

该方案虽然可以解决Federation + Viewfs的运维复杂度问题,但没有经过大规模生产验证,稳定性无法保证,不敢轻易使用。

3.3 Alluxio 统一命名空间

Alluxio的统一命名空间特性,支持对不同集群的HDFS路径进行挂载,为用户提供统一的访问入口。经过调研该方案,得出如下结论:对用户访问透明;在服务端进行挂载,运维成本可接受;Alluxio已经被多家一线互联网公司应用于生产环境,成熟度和稳定性有保证。因此,我们决定采用Alluxio统一命名空间来实现多HDFS集群方案。

在下面的章节中,我们会介绍在设计和实施过程中遇到过哪些问题,踩过哪些坑。

4 Alluxio多集群统一入口的设计和实现

我们首先来解决一个问题:集群如何切分?只有在确定了集群的切分维度之后,才能基于该维度去做路由的设计。我们采取的切分策略是:按照账号进行切分,一个账号不能跨两个集群。

如何实现对用户透明?采用同名挂载的方式可以实现对用户的透明,比如集群A的/user/bi路径挂载到Alluxio空间中也是/user/bi。

确认了切分和挂载方案后,我们对Alluxio进行了测试,发现如下问题:

  • 存储同样体量的元数据时,Alluxio Master相较于HDFS Namenode会消耗更多的内存空间。因此,做多集群的统一入口时,Alluxio Master的内存会先达到瓶颈;

  • Alluxio采用的Thrift RPC框架,Alluxio客户端和Master采用的是长连接;在凌晨计算高峰期,Master端的服务线程会被打满,从而导致客户端的请求都被堵住;

  • Alluxio Client是以plugin的形式进行部署的,和其他组件的jar包存在兼容性问题;

针对以上问题,我们分别给出了自己的解决方案,下面会分小节做详细介绍。首先来看下我们的总体架构图。

Alluxio多集群统一入口的结构图

客户端通过多集群统一入口访问HDFS集群的流程如下:

  • HDFS的客户端利用Alluxio客户端去Alluxio Master请求路由表;

  • HDFS客户端根据返回的路由表对访问的路径进行解析,获取对应的NameService;

  • 请求相应NameService的Namenode,获取文件的元数据信息;

  • HDFS客户端根据返回的元数据信息,和对应的Datanode进行交互;

4.1 元数据量问题

针对Alluxio Master内存瓶颈的问题,我们采取的解决方案是:Alluxio和HDFS各自管理自己的元数据;下图为各个空间的文件和元数据的示例图。

文件内存元数据管理示例图

从图中可知:

  • File A:表示只存储在Alluxio的数据,没有写到HDFS中,该文件的元数据信息只会保存在Alluxio Master中;

  • File B:表示只存储在HDFS的数据,没有load到Alluxio的内存中,该文件的元数据信息只会保存在HDFS的Namenode中;

  • File C:表示文件同时存储在Alluxio和HDFS中,此时C文件的元数据信息会同时出现在Alluxio Master中和HDFS Namenode中;

元数据分开管理会存在数据一致性的问题,但在我们当前的使用场景中,并不会使用Alluxio进行实际的数据存储,算是从应用场景上规避了这个问题。

4.2 Alluxio客户端和Master之间的长连接问题

针对client和Master存在长连接的问题,我们的解决方案是:client主动去关闭,在需要时再重建连接。关闭重连的消耗时间如下图所示,针对离线集群来说,1ms左右的性能损耗是可以接受的。

客户端关闭重连的压测结果

4.3 jar包兼容性问题

Alluxio客户端jar包和其他组件的jar包冲突问题,我们采用了业界常用的方案:利用maven的shaded插件将Alluxio客户端runtime相关的jar全部shaded住。

5 性能测试

在上线之前,我们对该方案进行了压测。模拟20个和50个账户,并发对单集群和多集群(2个集群)分别进行压测,结果如下:

备注:压测的读写比例请求是按照生产的实际读写比例的请求来进行的;1 Transaction =mkdir:create:listStatus:getfileinfo:open:rename:delete=1:4:5:71:40:3:1,因此1TPS对应底层125个RPC请求。

从压测数据来看,在采用两个集群的方案中,HDFS的TPS增加了40%,响应时间下降了22%。相信随着苏宁的业务的不断增多,多集群的解决方案会取得更好的效果。

6 后续优化

在使用的Alluxio做多集群统一入口的时候,我们发现如下问题需要去优化,我们将在Q2解决:

  • Client需要保存各个集群Namenode的地址信息,不利于客户端的运维。可以将HDFS的配置信息也存储在Alluxio的Master端;

  • Alluxio Master不能感知底层HDFS Namenode的Active和Standby状态,导致客户端在访问Namenode的时候,会按照配置文件的先后顺序会去尝试;

7 后记

在今年的3月份我们将HDFS升级到Hadoop-2.8.2的版本中,得益于新版本对HDFS写流程的优化,升级之后,Namenode的RPC响应延迟大幅下降,写请求的峰值时间下降到50ms以下。

但该版本中Namenode的内存使用量和FSNameSystem的writeLock问题依然没有得到解决。随着业务和数据量的持续增长,仍然会存在较严重的性能问题。因此对于可以预见的大规模使用场景,提前做多集群方案,仍然非常必要。

猜你喜欢

欢迎关注本公众号:iteblog_hadoop:

0、回复 电子书 获取 本站所有可下载的电子书

1、Apache Spark 统一内存管理模型详解

2、HDFS 副本存放磁盘选择策略详解

3、盘点2017年晋升为Apache TLP的大数据相关项目

4、干货 | Spark SQL:过去,现在以及未来

5、Apache Spark 黑名单(Blacklist)机制介绍

6、Kafka 在华泰证券的探索与实践

7、Apache CarbonData里程碑式版本1.3发布,多个重要新特性

8、干货 | Apache Spark 2.0 作业优化技巧

9、[干货]大规模数据处理的演变(2003-2017)

10、干货 | 如何使用功能强大的 Apache Flink SQL

11、更多大数据文章欢迎访问https://www.iteblog.com及本公众号(iteblog_hadoop) 12、Flink中文文档:http://flink.iteblog.com 13、Carbondata 中文文档 http://carbondata.iteblog.com

你可能感兴趣的:(基于 Alluxio 的 HDFS 多集群统一入口的实现)