干货 | 携程Hadoop跨机房架构实践

作者简介

 

昱康，携程架构师，对分布式计算和存储、调度、查询引擎、在线离线混部、高并发等方面有浓厚兴趣。

本文将分享携程Hadoop跨机房架构实践，包含Hadoop在携程的发展情况，整个跨机房项目的背景，我们跨机房的架构选型思路和落地实践，相关的改造和对未来的展望，希望给大家一些启迪。

 

一、Hadoop在携程的落地及发展情况

 

携程Hadoop是从2014年引进的，基本上每年较前一年以两倍的速度在增长，我们对Hadoop集群做了大量性能方面的改造和优化。

1）目前，HDFS存储层面拥有数百PB的数据，数千的节点，分为4个namespace做Federation，自研了namenode proxy来路由rpc到对应的namespace，2019年初上了一套基于Hadoop 3的Erasure Code集群来做对用户透明的冷热存储分离，目前已迁移几十PB数据到EC集群，节省一半的存储资源。

2）计算层面，搭建了两套离线和一套在线Yarn集群做Federation，总量15万+core，每天30万+ Hadoop作业，其中90%为spark。所有节点分布在四个机房，其中离线集群部署在其中两个机房，在线集群部署在三个机房。

 

二、跨机房项目背景

来看下整个项目的背景。之前我们的Hadoop机器部署在金和福两个机房，95%的机器在福。去年底，携程自建了日机房，同时福机房的机架数达到了物理上限，没办法继续扩容。另外按照目前计算和存储的增速来看，预计2024年底集群规模会达到万台，新采购的机器只能加在日机房，我们需要多机房架构和部署的能力。

这其中的难点在于，两个机房的带宽仅200Gbps，正常情况下网络延迟在1ms，当带宽打满情况下，延迟会达到10ms，同时会有10%的丢包率。我们需要尽可能减少跨机房的网络使用带宽。

 

2.1 原生Hadoop架构问题

 

看下原生Hadoop的问题。网络IO开销主要来自两方面，Shuffle读写和HDFS读写。

 

1）先看shuffle，MR和Spark作业的前一个stage会将中间临时文件刷到磁盘，下一个stage通过网络来Fetch。如果分配的map task在机房1，reducetask在机房2，就会产生跨机房流量开销。

 

2）其次HDFS层面，对于读场景，三个副本存放在不同的节点，客户端会从namenode拿到按照距离排好序的副本信息，优先从最近的副本所在的节点读取。但是当三个副本都和客户端不在一个机房的情况下，就会产生跨机房读网络IO开销。写场景的话，HDFS采用Pipeline写，选择副本时只考虑到机架层面的存放策略，会将三个副本放在两个机架，如果选择的两个机架跨机房了，也会有跨机房网络写开销。

 

2.2 可选的方案

 

当时我们讨论下来有两种架构解决方案，多机房多集群和多机房单集群，两种各有利弊。

 

2.2.1 多机房多集群

 

多机房多集群方案的优势是不需要修改源代码，可以直接部署。缺点是：

1）对用户不透明，用户需要修改配置，指定提交到某个集群；

2）运维成本较高，每个机房有独立的集群，配置管理麻烦；