技术解读:单集群如何做到 2 万 + 规模

发布于: 13 小时前

【导读】

7月9日,中国通信院在大数据产业峰会·成果发布会上为通过大数据产品能力评测的产品颁发证书,华为云FusionInsight MRS以测试项全部满分的成绩顺利通过评估,并成功突破单集群2万节点的超大规模,树立行业新标杆。

为了应对5G、互联网、IoT发展引发的数据洪流,大数据企业在分布式批处理平台的基础能力方面进一步加强,尤其针对大规模单集群的研发尤为看重。FusionInsight MRS作为华为基于Hadoop生态的大数据产品,一直致力于超大规模单集群承载能力的探索和实践,目的是当数据爆发式增长时代来临时,华为自研的大数据产品能平滑的满足用户需求。2017年华为大数据研发首次将承载华为内部核心业务的FusionInsight MRS生产单集群的规模从500提升到了5000,单集群整体容量提升了10倍。

但随着全社会数字化转型的加速,叠加华为自身业务的快速扩张,数据量暴增超出了预期,与此同时,用户的多场景融合分析的诉求不允许将集群进行拆分,不允许将数据分析业务割裂而导致业务模块之间失去业务关联。用户多次提出了单生态体系下多场景融合的高标准需求。

鉴于以上诉求,华为大数据研发团队开启了单集群2万节点规模探索的序幕。

超大规模集群的技术痛点

对于一个分布式系统来说,当集群规模由小变大以后,简单的问题都会变得异常复杂。随着节点的增多,简单的心跳机制,也会让Master节点不堪重负。2W节点的FusionInsight MRS集群面临着诸多挑战:

如何实现面向多租户场景的批、流、交互式混合负载的高效调度,集群规模与处理能力的线性扩展、引擎之间资源波峰波谷错峰复用

数据的集中存储可以通过超大集群来有效解决,但数据如果仅仅是存着,不会产生价值,只有进行大量的分析才能从数据中找到价值。通过跑批任务,生成固定的报表是大数据平台的常规用法,数百P的数据如果仅仅用来跑批,无论是对数据还是对海量的计算资源都是一种浪费;时间就是金钱,时间就是效率,数据T+0入湖,实时更新入湖,就是不断加速数据价值变现,超大规模集群应该能实现数据的T+0实时数据入湖,全量数据的批量分析,数据分析师的交互式探索分析,确保平台的价值最大。如在一个大集群上,同时快速的实现数据T+0的实时入湖,批分析,还能面向大量分析师的即席查询要求,做到计算资源的隔离和共享,是调度系统需要解决的一个重要问题。

如何面对存储、计算、管理方面的新挑战,突破多个组件的瓶颈限制

计算方面:随着集群规模变大,YARN的ResourceManager可调度的资源变得更多,可以并行的任务更多,这对中心调度进程提出了更高的要求,如果调度速度跟不上,作业任务会在集群入口处堆积,而集群的计算资源无法有效利用。

存储方面:随着存储容量的增加,HDFS在大规模集群上需要管理的文件对象增多,HDFS NameNode元数据量也会相应增加。社区虽然提供了NameNode联邦机制,但需要应用层感知不同NameNode的命名空间,使用和维护都会变得异常复杂。除此之外,还很容易出现各命名空间之间映射的数据量不均衡的问题。同时,随着数据量的增加,Hive元数据中的数据量急剧增长,对元数据库也会形成极大的压力,极易出现所有的SQL语句都堆积在元数据查询环节造成阻塞。

运维管理方面:除了计算和存储面临的瓶颈问题,平台的运维能力,也会随着规模变大,遇到瓶颈问题。如系统的监控系统,当节点从5000变为20000的时候,每秒处理的监控指标会从每秒60万增加到200多万条。

如何提升大规模集群的可靠性和运维能力,确保集群不停服

平台的可靠性一直是平台运维部门最关注的点,当集群承担了全集团的全量数据统一加工分析之后,就意味着集群必须24小时永远在线,但是技术会不断发展,平台必须要确保系统可以支持后续的更新与升级,以确保集群可面相未来持续演进,发展。

另外,随着集群规模的增加,机房空间不足的问题将凸显出来。如果简单地将一个大集群跨机房部署,在带宽负载和可靠性上,都会面临比较大的挑战。如何做到机房级的可靠性,对一个超大规模的集群也至关重要。

超大规模集群优化的实践过程

针对以上各方面的挑战,FusionInsight MRS在3.0版本进行了系统性的优化。如果说当年从500到5000节点,主要是在代码级的优化,那么从5000到2W,仅凭代码级的优化已经无法达成,很多问题需要架构级的优化才能解决。

自研Superior超级调度器,解决超大规模调度效率和面向多租户场景的混合负载的问题

FusionInsight引入数据虚拟化引擎,在统一的大集群上提供了交互式查询的能力,解决了面向分析师的查询效率问题。为了支撑在超大集群上同时支持多样化的负载,在自研的Superior调度器上,实现了为租户同时分配保留资源与共享资源,租户独享保留资源的权益同时还满足了资源共享的需求。对于更重要的业务,则可以通过绑定固定资源池的方式,将一批固定的机器分配给某个租户,做到物理上的隔离。通过计算引擎和调度引擎的协同,真正做到了数据不出湖,在一个大平台上的业务闭环。

在多租户能力方面,随着租户越来越多,租户间的资源隔离成为用户的核心诉求。Hadoop社区提供了基于队列的计算资源隔离能力,基于Quota的存储资源阈值限制能力,但是在任务或者读写操作被分配到同一台主机上时,依然会相互争抢资源。针对此场景,在MRS产品上提供了以下几种方式进行更加细粒度的隔离:

  • 标签存储:给承载存储资源的DataNode打标签,在文件写入时指定标签,实现了最大程度的存储资源隔离。该特性可以有效应用于冷热数据存储和硬件资源异构的场景。

  • 多服务:在同一个集群中的不同主机资源上,部署多个同种服务,不同的应用可根据需求,使用各自的服务资源,并且相互之间互不干扰。

  • 多实例:在同一个集群中的同一台主机资源上,独立部署同种服务的多个实例资源,以达到主机资源的充分利用,不与其它服务实例共享。例如:HBase多实例、Elasticsearch多实例、Redis多实例等。

技术攻坚,突破计算、存储、管理等各方面的瓶颈

在计算任务的调度效率方面,通过专利调度算法进行优化,将一维的调度转换为二维调度,实现了相对开源调度器在效率上数倍提升。在实际的大规模集群生产环境下,针对自研Superior和开源Capacity性能对比:

  • 同步调度情况下,Superior比Capacity快30倍

  • 异步调度情况下,Superior比Capacity快2倍

同时通过对2W集群的深度优化,FusionInsight MRS 3.0版本的Superior可以达到调度35w/s个Container的调度速率,完全超出了大规模集群在调度速率上的用户预期,并且集群资源利用率达到98%以上,超过开源Capacity的能力近一倍,为大规模集群的平稳商用奠定了坚实的基础。

下图是分别在Superior和Capacity下关于“资源利用率”的监控视图:可以看出Superior近乎100%的资源使用率,而Capacity下资源无法得到充分利用。

Superior资源利用率

Capacity资源利用率

在存储方面,Hadoop社区为解决HDFS在文件对象管理上的瓶颈,推出了联邦解决方案。但是大量不同命名空间的引入,直接导致上层业务在开发、管理、维护上复杂度上升。为解决这一问题,社区又推出了Router Based Federation特性,由于在NameNode之上加了一层Router进行交互,导致性能下降。

针对以上问题,FusionInsight MRS对产品方案做了如下优化:

  • 通过在大集群生产环境中识别关键瓶颈,FusionInsight MRS利用合并单次读写流程中的交互次数、使用改良的数据通信压缩算法等技术方案,将性能下降控制在4%以内。

  • 为解决不同命名空间之间数据不均衡的问题,FusionInsight MRS利用DataMovementTool自动均衡不同命名空间之间的数据,大大降低了集群维护成本。

随着数据量的增加,Hive的元数据在面对海量表/分区的时候,也面临着非常大的瓶颈。虽然Hive的社区推出了Metastore Cache的解决方案,但并未解决多个Metastore之间的缓存一致性的问题,导致此方案无法在大规模的集群上规模商用。FusionInsight MRS通过引入分布式缓存Redis作为替代方案,结合分布式锁、缓存黑白名单机制、缓存生命周期管理等技术手段增强了Metastore Cache的可用性。

在运维管理面方面,当集群规模增长到2W节点后,运维压力陡然增加:

  • 系统需要采集的监控指标数量也从原来的每秒采集60W+条数据,增长到200W+条

  • 告警并发处理从原来的200条/s增长到1000条/s

  • 配置管理的总条目数从50万增长到200多万

FusionInsight MRS原有架构中主备模式的监控、告警、配置、元数据存储模块,因为数据量的暴涨受到了巨大的性能挑战,为解决这一问题,新版本利用Flink、HBase、Hadoop、Elasticsearch等成熟的分布式组件技术,将原来的集约主从模式调整成了可弹性伸缩的分布式模式,成功解决了运维管理面临的难题,并且为后续运维数据的二次价值挖掘打下了基础。

通过滚动升级/补丁、任务级“断点续传”、跨AZ高可用等部署能力,保障平台持续稳定运行

滚动升级/补丁:FusionInsight从2.7版本开始支持滚动升级功能,实现了平台升级/补丁等操作的业务无感知。但随着时间的发展 ,社区能力却不支持滚动升级,如Hadoop2到Hadoop3的大版本升级这意味着很多超大集群不得不一直停留在老版本而无法升级,当然这是业务无法接受的。FusionInsight MRS通过对社区接口的兼容性处理,成功实现了Hadoop大版本间的滚动升极,并在2020年Q2完成了1W+节点集群规模的滚动升级。在FusionInsight的客户中,滚动升级成了500+规模集群的必备能力。

任务级“断点续传”:在大规模集群上,持续运行着一些超大任务,动辄包含几十万个Container,这类任务往往运行时间长,中间一旦出现个别故障,有可能导致任务需重新执行,造成大量的计算资源白白浪费。

FusionInsight MRS提供了多种机制保障任务的可靠运行,例如:

  • 当Hive beeline断连、Hive Server重启、MapReduce JobHistory无响应等都会导致Hive任务失败,从而只能重跑任务。MRS推出了Hive不中断业务的能力,将beeline提交的任务与Yarn上运行的任务进行关联,并实时刷新任务执行状态,当beeline或者Hive Server发生异常时,不再中断正在执行的Yarn任务,任务得以继续运行直至成功。并且将JobHistory的状态进行解耦,去除JobHistory异常对任务的影响。

  • Yarn中的Application Master故障后,虽然能够立即被其它的节点拉起,但之前已执行的计算任务只能从头开始重新执行。为解决这一问题,MRS提供了Application Master的断点续传能力,记录任务的执行状态,区分任务执行进度,待Application Master因故障重新被拉起后,依然可以按照之前记录的状态继续执行。

跨AZ高可用:2W节点的大规模集群,由于受限机房空间规划限制,单集群跨AZ部署成为一个不二选择。但不同的AZ之间毕竟无法像同一个机房一样提供充足的带宽,因此FusionInsight MRS分别在计算、存储两方面提供了消减优化措施:

  • 存储上提供感知AZ的文件存储策略,将文件自身及其副本分别放置在不同的AZ上,用户发起读写操作时,优先在本AZ内寻找资源,只有在AZ故障的极端场景下,才会出现跨AZ的网络读写流量。

  • 计算上提供感知AZ的任务调度机制,将用户提交的任务充分分配在同一个AZ内完成,避免同一个任务的不同计算单元之间消耗网络资源。

通过以上的存储块放置策略和计算任务的本地化调度,还可实现单集群跨AZ的高可用,单AZ故障的时候,核心数据和计算任务不受影响。

【结束语】

FusionInsight MRS 单集群21000节点在2020年7月获信通院颁发大数据产品能力评测证书,成为业界第一个单集群突破2W节点的商用大数据平台,树立行业新标杆。未来,FusionInsight MRS将持续深入大数据技术的探索和研究,在大集群技术的基础上进一步实现存算分离,通过统一的元数据和安全管理,实现数算分离(数据+元数据和计算分离),从而实现数据在更大范围的共享,进而实现一份数据,多个计算集群的灵活部署和弹性伸缩,通过平滑扩展的架构,可支持10万级,甚至百万级别的集群规模,不断适应企业大数据应用多场景融合的核心诉求。

未来架构演进方向

十多年来FusionInsight 致力于为全球60+国家地区、3000+政企客户构建企业级智能数据湖,结合平台+生态战略,与800+商业合作伙伴 ,广泛应用于金融、运营商、政府、能源、医疗、制造、交通等多个行业,在政企数字化转型中,释放数据价值,助力政企客户业务高速增长。MRS源于开放的大数据生态,叠加了企业级的关键能力,既保持了开放性,又给客户提供了企业级融合大数据平台,帮助客户实现T+0数据入湖,一站式融合分析,让数据“慧”说话。

用户头像

FI局座

关注

还未添加个人签名 2020.07.01 加入

还未添加个人简介

评论

发布
暂无评论
技术解读:单集群如何做到2万+规模