云原生计算引擎挑战与解决方案
Posted 阿里云云栖号
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了云原生计算引擎挑战与解决方案相关的知识,希望对你有一定的参考价值。
本文来源 | 阿里技术
云原生背景介绍与思考
图一是基于ECS底座的EMR架构,这是一套非常完整的开源大数据生态,也是近10年来每个数字化企业必不可少的开源大数据解决方案。主要分为以下几层:
-
ECS物理资源层,也就是Iaas层 -
数据接入层,例如实时的Kafka,离线的Sqoop
存储层,包括HDFS和OSS,以及EMR自研的缓存加速JindoFS -
计算引擎层,包括熟知的Spark,Presto、Flink等这些计算引擎 -
数据应用层,如阿里自研的Dataworks、PAI以及开源的Zeppelin,Jupyter
-
是否能够做到更好用的弹性,也就是客户可以完全按照自己业务实际的峰值和低谷进行弹性扩容和缩容,保证速度足够快,资源足够充足 -
不考虑现有状况,看未来几年的发展方向,是否还需要支持所有的计算引擎和存储引擎。这个问题也非常实际,一方面是客户是否有能力维护这么多的引擎,另一方面是是否某些场景下用一种通用的引擎即可解决所有问题。举个例子说Hive和Mapreduce,诚然现有的一些客户还在用Hive on Mapreduce,而且规模也确实不小,但是未来Spark会是一个很好的替代品。 -
存储与计算分离架构,这是公认的未来大方向,存算分离提供了独立的扩展性,客户可以做到数据入湖,计算引擎按需扩容,这样的解耦方式会得到更高的性价比。
![1.png 云原生计算引擎挑战与解决方案](https://image.cha138.com/20210403/896ea2f17b83491a9608a78ebedde779.jpg)
(图1 基于ECS的开源大数据解决方案)
-
希望能够基于Kubernetes来包容在线服务、大数据、AI等基础架构,做到运维体系统一化 -
存算分离架构,这个是大数据引擎可以在Kubernetes部署的前提,未来的趋势也都在向这个方向走 -
通过Kubernetes的天生隔离特性,更好的实现离线与在线混部,达到降本增效目的 -
Kubernetes生态提供了非常丰富的工具,我们可以省去很多时间搞基础运维工作,从而可以专心来做业务
EMR计算引擎 on ACK
-
引入了JindoFS作为OSS缓存加速层,做计算与存储分离的架构 -
打通了现有EMR集群的HDFS,方便客户利用已有的EMR集群数据 -
引入Shuffle Service来做Shuffle 数据的解耦,这也是EMR容器化区别于开源方案的比较大的亮点,之后会重点讲到。
![2.png 云原生计算引擎挑战与解决方案](https://image.cha138.com/20210403/7caa254eb4704536b0daff142dcb2fdd.jpg)
Spark on Kubernetes的挑战
-
我个人认为最重要的,就是Shuffle的流程,按照目前的Shuffle方式,我们是没办法打开动态资源特性的。而且还需要挂载云盘,云盘面临着Shuffle数据量的问题,挂的比较大会很浪费,挂的比较小又支持不了Shuffle Heavy的任务。 -
调度和队列管理问题,调度性能的衡量指标是,要确保当大量作业同时启动时,不应该有性能瓶颈。作业队列这一概念对于大数据领域的同学应该非常熟悉,他提供了一种管理资源的视图,有助于我们在队列之间控制资源和共享资源。 -
读写数据湖相比较HDFS,在大量的Rename,List等场景下性能会有所下降,同时OSS带宽也是一个不可避免的问题。
Spark on Kubernetes的解决方案
Remote Shuffle Service架构
-
如果用是Docker的文件系统,问题是显而易见的,因为性能慢不说,容量也是极其有限,对于Shuffle过程是十分不友好的。 -
如果用Hostpath,熟悉Spark的同学应该知道,是不能够启动动态资源特性的,这个对于Spark资源是一个很大的浪费,而且如果考虑到后续迁移到Serverless K8s,那么从架构上本身就是不支持Hostpath的。 -
如果是Executor挂云盘的PV,同样道理,也是不支持动态资源的,而且需要提前知道每个Executor的Shuffle数据量,挂的大比较浪费空间,挂的小Shuffle数据又不一定能够容纳下。
-
Shuffle数据通过网络写出,中间数据计算与存储分离架构 -
DFS 2副本,消除Fetch Failed引起的重算,Shuffle Heavy作业更加稳定 -
Reduce阶段顺序读磁盘,避免现有版本的随机IO,大幅提升性能
Remote Shuffle Service性能
![5.png 云原生计算引擎挑战与解决方案](https://image.cha138.com/20210403/a59ada06cca146558d4018d003afbae0.jpg)
(图4 Remote Shuffle Service性能Benchmark)
其他方面的重点优化
-
调度性能优化,我们解决了开源的Spark Operator的一些不足,对于Executor pod的很多配置Spark Operator把他做到了Webhook里边,这个对调度来说是十分不友好的,因为相当于在API Server上绕了一圈,实际测试下来性能损耗很大。我们把这些工作直接做到spark内核里边,这样避免了这方面的调度性能瓶颈。然后从调度器层面上,我们保留了两种选择给客户,包括ACK提供的Scheduler FrameworkV2实现方式和Yunicorn实现方式 -
读写OSS性能优化,我们这里引入了JindoFS作为缓存,解决带宽问题,同时EMR为OSS场景提供了Jindo Job Committer,专门优化了job commit的过程,大大减少了Rename和List等耗时操作 -
针对Spark本身,EMR积累了多年的技术优势,也在TPCDS官方测试中,取得了很好的成绩,包括Spark性能、稳定性,还有Delta lake的优化也都有集成进来。 -
我们提供了一站式的管控,包括Notebook作业开发,监控日志报警等服务,还继承了NameSpace的ResourceQuota等等。
Spark云原生后续展望
-
可以将Kubernetes计算资源分为固定集群和Serverless集群的混合架构,固定集群主要是一些包年包月、资源使用率很高的集群,Serverless是做到按需弹性。 -
可以通过调度算法,灵活的把一些SLA不高的任务调度到Spot实例上,就是支持抢占式ECI容器,这样可以进一步降低成本。 -
由于提供了Remote Shuffle Service集群,充分让Spark在架构上解耦本地盘,只要Executor空闲就可以销毁。配合上OSS提供的存算分离,必定是后续的主流方向。 -
对于调度能力,这方面需要特别的增强,做到能够让客户感受不到性能瓶颈,短时间内调度起来大量的作业。同时对于作业队列管理方面,希望做到更强的资源控制和资源共享。
-
存算分离,按需扩展 -
极致弹性,随用随得 -
运维闭环,高性价比
更多精彩
点此阅读作者更多好文!
以上是关于云原生计算引擎挑战与解决方案的主要内容,如果未能解决你的问题,请参考以下文章