Auto Byte

专注未来出行及智能汽车科技

微信扫一扫获取更多资讯

Science AI

关注人工智能与其他前沿技术、基础学科的交叉研究与融合发展

微信扫一扫获取更多资讯

如何实现Spark on Kubernetes?

阿里妹导读:大数据时代,以Oracle为代表的数据库中间件已经逐渐无法适应企业数字化转型的需求,Spark将会是比较好的大数据批处理引擎。而随着Kubernetes越来越火,很多数字化企业已经把在线业务搬到了Kubernetes之上,并希望在此之上建设一套统一的、完整的大数据基础架构。那么Spark on Kubernetes面临哪些挑战?又该如何解决?


云原生背景介绍与思考

“数据湖”正在被越来越多人提起,尽管定义并不统一,但企业已纷纷投入实践,无论是在云上自建还是使用云产品。

阿里云大数据团队认为:数据湖是大数据和AI时代融合存储和计算的全新体系。为什么这么说?在数据量爆发式增长的今天,数字化转型成为IT行业的热点,数据需要更深度的价值挖掘,因此确保数据中保留的原始信息不丢失,应对未来不断变化的需求。当前以Oracle为代表的数据库中间件已经逐渐无法适应这样的需求,于是业界也不断地产生新的计算引擎,以便应对大数据时代的到来。企业开始纷纷自建开源Hadoop数据湖架构,原始数据统一存放在对象存储OSS或HDFS系统上,引擎以Hadoop和Spark开源生态为主,存储和计算一体。

图1是基于ECS底座的EMR架构,这是一套非常完整的开源大数据生态,也是近10年来每个数字化企业必不可少的开源大数据解决方案。

图1  基于ECS的开源大数据解决方案

主要分为以下几层:
  • ECS物理资源层,也就是Iaas层。

  • 数据接入层,例如实时的Kafka,离线的Sqoop。

  • 存储层,包括HDFS和OSS,以及EMR自研的缓存加速JindoFS。


  • 计算引擎层,包括熟知的Spark,Presto、Flink等这些计算引擎。

  • 数据应用层,如阿里自研的Dataworks、PAI以及开源的Zeppelin,Jupyter。

每一层都有比较多的开源组件与之对应,这些层级组成了最经典的大数据解决方案,也就是EMR的架构。我们对此有以下思考:
  • 是否能够做到更好用的弹性,也就是客户可以完全按照自己业务实际的峰值和低谷进行弹性扩容和缩容,保证速度足够快,资源足够充足。

  • 不考虑现有状况,看未来几年的发展方向,是否还需要支持所有的计算引擎和存储引擎。这个问题也非常实际,一方面是客户是否有能力维护这么多的引擎,另一方面是某些场景下是否用一种通用的引擎即可解决所有问题。举个例子来说,Hive和Mapreduce,诚然现有的一些客户还在用Hive on Mapreduce,而且规模也确实不小,但是未来Spark会是一个很好的替代品。

  • 存储与计算分离架构,这是公认的未来大方向,存算分离提供了独立的扩展性,客户可以做到数据入湖,计算引擎按需扩容,这样的解耦方式会得到更高的性价比。

基于以上这些思考,我们考虑一下云原生的这个概念,云原生比较有前景的实现就是Kubernetes,所以有时候我们一提到云原生,几乎就等价于是Kubernetes。随着Kubernetes的概念越来越火,客户也对该技术充满了兴趣,很多客户已经把在线的业务搬到了Kubernetes之上,并且希望在这种类似操作系统上,建设一套统一的、完整的大数据基础架构。所以我们总结为以下几个特征:
  • 希望能够基于Kubernetes来包容在线服务、大数据、AI等基础架构,做到运维体系统一化。

  • 存算分离架构,这个是大数据引擎可以在Kubernetes部署的前提,未来的趋势也都在向这个方向走。

  • 通过Kubernetes的天生隔离特性,更好的实现离线与在线混部,达到降本增效目的。

Kubernetes生态提供了非常丰富的工具,我们可以省去很多时间搞基础运维工作,从而可以专心来做业务。

EMR计算引擎 on ACK

图2是EMR计算引擎 on ACK的架构。ACK就是阿里云版本的Kubernetes,在兼容社区版本的API同时,做了大量的优化。在本文中不会区分ACK和Kubernetes这两个词,可以认为代表同一个概念。

图2 计算引擎Kubernetes化

基于最开始的讨论,我们认为比较有希望的大数据批处理引擎是Spark和Presto,当然我们也会随着版本迭代逐步的加入一些比较有前景的引擎。

EMR计算引擎提供以Kubernetes为底座的产品形态,本质上来说是基于CRD+Operator的组合,这也是云原生最基本的哲学。我们针对组件进行分类,分为service组件和批处理组件,比如Hive Metastore就是service组件,Spark就是批处理组件。

图中绿色部分是各种Operator,技术层面在开源的基础上进行了多方面的改进,产品层面针对ACK底座进行了各方面的兼容,能够保证用户在集群中很方便的进行管控操作。右边的部分,包括Log、监控、数据开发、ECM管控等组件,这里主要是集成了阿里云的一些基础设施。我们再来看下边的部分:
  • 引入了JindoFS作为OSS缓存加速层,做计算与存储分离的架构。

  • 打通了现有EMR集群的HDFS,方便客户利用已有的EMR集群数据。

  • 引入Shuffle Service来做Shuffle 数据的解耦,这也是EMR容器化区别于开源方案的比较大的亮点,之后会重点讲到。

这里明确一下,由于本身Presto是无状态的MPP架构,在ACK中部署是相对容易的事情,本文主要讨论Spark on ACK的解决方案。

Spark on Kubernetes的挑战

整体看,Spark on Kubernetes面临以下问题:
  • 我个人认为最重要的,就是Shuffle的流程,按照目前的Shuffle方式,我们是没办法打开动态资源特性的。而且还需要挂载云盘,云盘面临着Shuffle数据量的问题,挂的比较大会很浪费,挂的比较小又支持不了Shuffle Heavy的任务。

  • 调度和队列管理问题,调度性能的衡量指标是,要确保当大量作业同时启动时,不应该有性能瓶颈。作业队列这一概念对于大数据领域的同学应该非常熟悉,他提供了一种管理资源的视图,有助于我们在队列之间控制资源和共享资源。

  • 读写数据湖相比较HDFS,在大量的Rename,List等场景下性能会有所下降,同时OSS带宽也是一个不可避免的问题。

针对以上问题,我们分别来看下解决方案。

Spark on Kubernetes的解决方案

Remote Shuffle Service架构

Spark Shuffle的问题,我们设计了Shuffle 读写分离架构,称为Remote Shuffle Service。首先探讨一下为什么Kubernetes不希望挂盘呢,我们看一下可能的选项:

  • 如果用是Docker的文件系统,问题是显而易见的,因为性能慢不说,容量也是极其有限,对于Shuffle过程是十分不友好的。

  • 如果用Hostpath,熟悉Spark的同学应该知道,是不能够启动动态资源特性的,这个对于Spark资源是一个很大的浪费,而且如果考虑到后续迁移到Serverless K8s,那么从架构上本身就是不支持Hostpath的。

  • 如果是Executor挂云盘的PV,同样道理,也是不支持动态资源的,而且需要提前知道每个Executor的Shuffle数据量,挂的大比较浪费空间,挂的小Shuffle数据又不一定能够容纳下。

所以Remote Shuffle架构针对这一痛点、对现有的Shuffle机制有比较大的优化,图3中间有非常多的控制流,我们不做具体的讨论。主要来看数据流,对于Executor所有的Mapper和Reducer,也就是图中的蓝色部分是跑在了K8s容器里,中间的架构是Remote Shuffle Service,蓝色部分的Mapper将Shuffle数据远程写入service里边,消除了Executor的Task对于本地磁盘的依赖。Shuffle Service会对来自不同Mapper的同一partition的数据进行merge操作,然后写入到分布式文件系统中。等到Reduce阶段,Reducer通过读取顺序的文件,可以很好地提升性能。这套系统最主要的实现难点就是控制流的设计,还有各方面的容错,数据去重,元数据管理等等工作。

图3 Remote Shuffle Service架构图

简而言之,我们总结为以下3点:
  • Shuffle数据通过网络写出,中间数据计算与存储分离架构

  • DFS 2副本,消除Fetch Failed引起的重算,Shuffle Heavy作业更加稳定

  • Reduce阶段顺序读磁盘,避免现有版本的随机IO,大幅提升性能

Remote Shuffle Service性能

我们在这里展示一下关于性能的成绩,图4和图5是Terasort Benchmark。之所以选取Terasrot这种workload来测试,是因为它只有3个stage,而且是一个大Shuffle的任务,大家可以非常有体感的看出关于Shuffle性能的变化。

图4中,蓝色部分是Shuffle Service版本的运行时间,橙色部分是原版Shuffle的运行时间。我们测试了2T,4T,10T的数据,可以观察到随着数据量越来越大,Shuffle Service优势就越来越明显。图5红框部分说明了作业的性能提升主要体现在Reduce阶段,可见10T的Reduce Read从1.6小时下降到了1小时。原因前边已经解释的很清楚了,熟悉Spark shuffle机制的同学知道,原版的sort shuffle是M*N次的随机IO,在这个例子中,M是12000,N是8000,而Remote Shuffle就只有N次顺序IO,这个例子中是8000次,所以这是提升性能的根本所在。

图4 Remote Shuffle Service性能

图5 Terasort作业的stage图

其他方面的重点优化

这里讲一下EMR在其他方面做的优化。

调度性能优化,我们解决了开源的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等等。

总体来说,EMR版本的Spark on ACK,无论在架构上、性能上、稳定性上、易用性方面都有着很大的提升。

Spark云原生后续展望

从我的视角来观察,Spark云原生容器化后续的方向,一方面是达到运维一体化,另一方面主要希望做到更好的性价比。我们总结为以下几点:
  • 可以将Kubernetes计算资源分为固定集群和Serverless集群的混合架构,固定集群主要是一些包年包月、资源使用率很高的集群,Serverless是做到按需弹性。

  • 可以通过调度算法,灵活的把一些SLA不高的任务调度到Spot实例上,就是支持抢占式ECI容器,这样可以进一步降低成本。

  • 由于提供了Remote Shuffle Service集群,充分让Spark在架构上解耦本地盘,只要Executor空闲就可以销毁。配合上OSS提供的存算分离,必定是后续的主流方向。

  • 对于调度能力,这方面需要特别的增强,做到能够让客户感受不到性能瓶颈,短时间内调度起来大量的作业。同时对于作业队列管理方面,希望做到更强的资源控制和资源共享。

图6 Spark on Kubernetes混合架构

随着阿里云2.0时代的到来,云原生已经逐渐成为新的主角,越来越多的企业将会享受到云原生所带来的红利。数据湖计算引擎云原生容器化,能够极大地方便客户上云,提升性价比。但是整体上来讲:大数据云原生的落地是十分具有挑战性的,阿里云EMR团队会和社区同伴、合作伙伴一起打造技术和生态,共同打造“存算分离,按需扩展”、“极致弹性,随用随得”、“运维闭环,高性价比”的愿景。
阿里技术
阿里技术

分享阿里巴巴的技术创新、实战案例、经验总结,内容同步于微信公众号“阿里技术”。

专栏二维码
工程大数据技术云计算
1
相关数据
调度技术

调度在计算机中是分配工作所需资源的方法。资源可以指虚拟的计算资源,如线程、进程或数据流;也可以指硬件资源,如处理器、网络连接或扩展卡。 进行调度工作的程序叫做调度器。调度器通常的实现使得所有计算资源都处于忙碌状态,允许多位用户有效地同时共享系统资源,或达到指定的服务质量。 see planning for more details

数据管理技术

数据管理是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程,其目的在于充分有效地发挥数据的作用。

数据库技术

数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据运行新增、截取、更新、删除等操作。 所谓“数据库”系以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

操作系统技术

操作系统(英语:operating system,缩写作 OS)是管理计算机硬件与软件资源的计算机程序,同时也是计算机系统的内核与基石。操作系统需要处理如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。操作系统也提供一个让用户与系统交互的操作界面。

阿里云机构

阿里云创立于2009年,是全球领先的云计算及人工智能科技公司,致力于以在线公共服务的方式,提供安全、可靠的计算和数据处理能力,让计算和人工智能成为普惠科技。 阿里云服务着制造、金融、政务、交通、医疗、电信、能源等众多领域的领军企业,包括中国联通、12306、中石化、中石油、飞利浦、华大基因等大型企业客户,以及微博、知乎、锤子科技等明星互联网公司。在天猫双11全球狂欢节、12306春运购票等极富挑战的应用场景中,阿里云保持着良好的运行纪录。 阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。 2014年,阿里云曾帮助用户抵御全球互联网史上最大的DDoS攻击,峰值流量达到每秒453.8Gb 。在Sort Benchmark 2016 排序竞赛 CloudSort项目中,阿里云以1.44$/TB的排序花费打破了AWS保持的4.51$/TB纪录。在Sort Benchmark 2015,阿里云利用自研的分布式计算平台ODPS,377秒完成100TB数据排序,刷新了Apache Spark 1406秒的世界纪录。 2018年9月22日,2018杭州·云栖大会上阿里云宣布成立全球交付中心。

https://www.aliyun.com/about?spm=5176.12825654.7y9jhqsfz.76.e9392c4afbC15r
推荐文章
暂无评论
暂无评论~