简介： 大数据时代，以 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 团队会和社区伙伴、合作伙伴一起打造技术和生态，独特打造“存算拆散，按需扩大”、“极致弹性，随用随得”、“运维闭环，高性价比”的愿景。