作者简介
昱康,携程架构师,对分布式计算和存储、调度、查询引擎、在线离线混部、高并发等方面有浓厚兴趣。
本文将分享携程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)运维成本较高,每个机房有独立的集群,配置管理麻烦;