简介： 大数据时代，以Oracle为代表的数据库中间件曾经逐步无奈适应企业数字化转型的需要，Spark将会是比拟好的大数据批处理引擎。而随着Kubernetes越来越火，很多数字化企业曾经把在线业务搬到了Kubernetes之上，并心愿在此之上建设一套对立的、残缺的大数据基础架构。那么Spark on Kubernetes面临哪些挑战？又该如何解决？

云原生背景介绍与思考

“数据湖”正在被越来越多人提起，只管定义并不对立，但企业已纷纷投入实际，无论是在云上自建还是应用云产品。

阿里云大数据团队认为：数据湖是大数据和AI时代交融存储和计算的全新体系。为什么这么说？在数据量爆发式增长的明天，数字化转型成为IT行业的热点，数据须要更深度的价值开掘，因而确保数据中保留的原始信息不失落，应答将来一直变动的需要。以后以Oracle为代表的数据库中间件曾经逐步无奈适应这样的需要，于是业界也一直地产生新的计算引擎，以便应答大数据时代的到来。企业开始纷纷自建开源Hadoop数据湖架构，原始数据对立寄存在对象存储OSS或HDFS零碎上，引擎以Hadoop和Spark开源生态为主，存储和计算一体。

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

次要分为以下几层：

  • 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这两个词，能够认为代表同一个概念。

基于最开始的探讨，咱们认为比拟有心愿的大数据批处理引擎是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点：

  • 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提供的存算拆散，必然是后续的支流方向。
  • 对于调度能力，这方面须要特地的加强，做到可能让客户感触不到性能瓶颈，短时间内调度起来大量的作业。同时对于作业队列治理方面，心愿做到更强的资源管制和资源共享。

随着阿里云2.0时代的到来，云原生曾经逐步成为新的配角，越来越多的企业将会享受到云原生所带来的红利。数据湖计算引擎云原生容器化，可能极大中央便客户上云，晋升性价比。然而整体上来讲：大数据云原生的落地是非常具备挑战性的，阿里云EMR团队会和社区伙伴、合作伙伴一起打造技术和生态，独特打造“存算拆散，按需扩大”、“极致弹性，随用随得”、“运维闭环，高性价比”的愿景。