导读： 随着大数据技术的倒退，Spark 成为当今大数据畛域最受关注的计算引擎之一。在传统的生产环境中，Spark on YARN 成为支流的工作执行形式，而随着容器化概念以及存算拆散思维的遍及，尤其是 Spark3.1 版本下该模式的正式可用（GA），Spark on K8s 已成燎原之势。
明天的介绍会围绕上面两点开展：
- Spark on K8s 的根底概念和个性
- Spark on K8s 在阿里云 EMR 的优化和最佳实际
点击查看直播回放
Spark on K8s 的根底概念和个性
首先和大家分享下 Spark on K8s 的一些背景。
1. Spark 的集群部署模式
Spark 现如今反对 4 种部署模式：
- Standalone：应用 Spark 的内置调度器，个别用于测试环境，因为没有充分利用到大数据的调度框架，无奈充分利用集群资源。
- Hadoop YARN：最常见的一种形式，源自 Hadoop，领有良好的社区生态。
- Apache Mesos：与 YARN 相似，也是一个资源管理框架，当初曾经逐步退出历史舞台。
- Kubernetes：即 Spark on K8s，Spark3.1.1 对这种部署模式正式提供可用反对，越来越多的用户也在踊跃做这方面的尝试。
应用 Spark on K8s 的 劣势 如下：
- 进步资源利用率：无需依照应用场景部署多个集群，所有 Spark 作业共享集群资源，能进步总体集群利用率，而且在云上应用时能够弹性容器实例，真正做到按量付费。
- 对立运维形式：能够利用 K8s 的社区生态和工具，对立保护集群，缩小集群切换带来的运维老本。
- 容器化：通过容器镜像治理，进步 Spark 工作的可移植性，防止不同版本 Spark 带来版本抵触问题，反对多版本的 A/B Test。
尤其须要关注的一点是，依据咱们的测试，在雷同的集群资源条件下，Spark on K8s 和 Spark on YARN 的性能差距简直能够忽略不计。再加上充分利用 Spark on K8s 的弹性资源，能够更好地减速 Spark 作业。
总结来看，Spark on K8s 相较于 Spark on YARN 的模式来说，其实是利大于弊的。
2. Spark on K8s 的部署架构
以后环境下，想要把 Spark 作业提交到 K8s 上，有两种形式：
- 应用原生的 spark-submit
在这种形式下，K8s 集群无需提前装置组件。像当初应用的 YARN 的提交形式一样，提交作业的 Client 端须要装置 Spark 的环境，并且配置 kubectl，就是连贯 K8s 集群的一个工具，而后在提交命令中标注 K8s 集群地址以及应用的 Spark 镜像地址即可。
上图具体的展现了应用原生的 spark-submit 提交工作到 K8s 的工作运行流程。用户在 Client 端执行 spark-submit 命令后会在本地启动一个过程，该过程会连贯 K8s 的 api server 申请创立一个 Driver Pod。Driver Pod 在启动过程中会启动 Spark Context，并负责申请 Executor Pod。工作执行结束后，Driver Pod 会负责清理 Executor Pod。但 Driver Pod 完结后会保留，用于日志或状态的查看，须要手动清理。
长处：
这种提交形式合乎用户的应用习惯，缩小用户学习老本，与现有的大数据平台集成性更好。因为是 Client 模式提交，反对本地依赖，反对 Spark-shell 的交互式作业模式。
- 应用 Spark-on-K8s-operator
Spark-on-K8s-operator 是 Google 开源的一个组件，须要提前在 K8s 集群中部署一个常驻 pod，以提供相干服务。与第一种形式不同的是，应用这种形式不再是以命令行的形式提交，而是应用 kubectl 提交一种 yaml 文件来提交作业。实质上来说，这种工具具体实现还是应用的 spark-submit 的形式，只是相当于命令行中的信息换了一种格局以文件的模式提交。然而 Spark-on-K8s-operator 在第一种形式的根底上，做了一些辅助工具，包含定时调度、监控、作业管理等。
从流程上来说，用户提交了一个 yaml 文件，在 K8s 集群上常驻的 Spark-on-K8s-operator 就监听到了这个事件，通过解析文件转化成执行 spark-submit 命令启动一个 Spark 工作。
除了提交形式的不同，咱们刚刚也提到这个工具提供了一些辅助的性能。Spark-on-K8s-operator 通过 K8s 的 Mutating Admission Webhook 机制，拦挡了 K8s 的 Api 申请，在启动 Driver 和 Executor Pod 资源时，能够对其进行一些自定义配置解决。另一方面，工具能够监听 Driver 和 Executor Pod 的事件，从而跟踪和治理工作的执行进度。
长处：
工具的存在反对作业的治理，包含记录、重试、定时执行等。提供作业监控指标，也能够对接 Prometheus 不便对立监控。反对主动清理作业资源，也能够主动配置 Spark UI 的 service/ingress。
3. Spark on K8s 的社区停顿
Spark2.3 之前，有人尝试过通过在 K8s 上部署 YARN 的形式来反对 Spark on K8s，然而实质上 Spark 还是跑在 YARN 的资源管控下，所以并不能称之为残缺意义上的 Spark on K8s。
Spark2.3，社区首次公布反对了原生的 Spark on K8s，全是第一次官网反对这样的部署形式。
Spark2.4 做了大量的个性优化，真正欠缺了这个性能是在 Spark3 版本，尤其是 Spark3.1 正式可用（GA）。以后 Spark on K8s 方向热度很高，所以如果感兴趣的同学倡议间接降级到 Spark3.1 来尝试这个部署形式。
4. Spark on K8s 的重点个性
- 优化 Spark Pod 配置属性
K8s 的 Pod 定义通常采纳 Yaml 的形容解决，晚期的 Driver 和 Executor Pod 定义只能通过 Spark Conf 进行配置，灵活性很差，毕竟不是所有的配置都能通过 Spark Conf 解决。Spark3.0 开始，反对应用模板文件。用户能够建设模板文件，定义 Pod 的属性，而后通过 spark 的配置传入，相较于单条配置更加便当，灵活性加强了很多。
- 动静资源分配（Dynamic Allocation）
Spark2 版本时，动静资源分配只能应用 External Shuffle Service（ESS）的形式，这种形式下，executor 在执行时产生的 shuffle 数据全副交由 ESS 服务接管，executor 执行结束随时回收。然而这种形式个别由 YARN 的 Node Manager 启动治理，很难在 K8s 上部署。
Spark3 版本中反对了 Shuffle Tracking 的个性，就是能够在没有 ESS 的状况下，利用自身对 executor 的治理，做到动静资源配置的成果。然而这种形式的毛病就是，在 shuffle read 阶段 executor 不能动静回收，仍须要保留以供 reducer 读取 shuffle 数据，而后须要等到 driver 端 gc 之后才会标记这个 executor 能够开释，资源开释效率低。
- 节点优雅下线（node decommissioning）
在 K8s 的环境中，节点的缩容，抢占式实例回收这些场景还是比拟常见的，尤其是在一些场景下，将局部 Spark 的工作优先级调低以满足其余高优先级的工作的应用。这种场景下，executor 间接退出可能会存在 stage 重算等状况，缩短了 Spark 的执行工夫。Spark3.1 提供了“优雅下线”个性，反对 Executor Pod 在“被迫”下线前，能够告诉 Driver 不再调配新的 Task，并将缓存的数据或者 shuffle 的文件迁徙到其余的 Executor Pod 中，从而保障对应 Spark 工作的效率，防止重算。
以后这个性能还属于试验性质，也就是默认不开启。
- PersistentVolumeClaim 复用
PersisentVolumnClaim（简称 pvc），是 K8s 的存储申明，每个 Pod 都能够显式地申请挂载。Spark3.1 反对动态创建 pvc，意味着不须要提前申明申请，能够随着执行动静的申请挂载资源。然而这个时候 pvc 的生命周期随同着 Executor，如果呈现上述的抢占式被迫敞开的状况，同样会呈现保留在 pvc 下面的数据失落重算的问题。所以在 Spark3.2 中，反对了 pvc 从新利用，它的生命周期随同 Driver，防止了从新申请和计算，保障整体的效率。
Spark on K8s 在阿里云 EMR 的优化和最佳实际
接下来和大家分享下阿里云 EMR 对于 Spark on K8s 的优化和最佳实际。
1. Spark on ACK 简介
ACK：阿里云容器服务 Kubernetes 版，简称 ACK。
EMR：阿里云开源大数据平台 E-MapReduce，简称 EMR。
在阿里云公共云上，咱们有一款 EMR on ACK 的产品，其中蕴含了 Spark 类型的集群，前面简称 Spark on ACK。Spark on ACK 这个产品是一套半托管的大数据平台，用户首先须要有一个本人的 ACK 集群，也就是 k8s 集群，而后咱们会在这个集群内创立一个用于 Spark 作业的 namespace，并装置一些固定组件 pod 比方 spark-operator、historyserver 之类，后续的 Spark 作业 pod 也会在这个 namespace 下运行，这些 Spark 作业 pod 能够利用用户本人的 ACK 节点机器来跑，也能够利用咱们的弹性实例 ECI 来跑，来实现按量付费。这个所谓弹性实例 ECI 是什么，接下来咱们具体介绍一下。
2. 云上弹性劣势
Spark 在云上最大的劣势就是更好的弹性，在阿里云的 ACK 的环境中，提供了一个弹性容器实例 ECI 的产品，有了 ECI 意味着，咱们申请 pod 时不再是占用本人的机器节点的资源了，而是齐全利用云上资源来创立 pod，而且能够做到疾速拉起，秒级付费。利用 ECI 来跑 spark 作业我认为是十分划算的，因为通常大家用 spark 作业跑批处理工作，凌晨顶峰，白天可能只有大量查问，这种峰谷显著的特点搭配疾速弹性和按量付费是很适宜的，外加 ECI 能够应用 spot 抢占式实例，有 1 个小时的保护期，并联合 Spark 的 Node decommissioning 个性，能够节俭很多老本。
3. RSS 优化 Shuffle 和动静资源
Spark Shuffle 对本地存储依赖较大，然而云上环境下，存储拆散的机器很难保障自带本地磁盘，应用云盘大小也无奈预估，性价比不高。另一方面，Spark 原生的无 ESS 的动静资源配置，executor 的开释资源效率较低，可能因为无奈回收造成资源节约。
Spark Shuffle 自身也有很多毛病。Mapper 的输出量增大，导致 spill 到本地磁盘，引发额定的 IO；Reducer 并发拉取 Mapper 端的数据，导致大量随机读的产生，升高效率；在 shuffle 过程中，产生 numMapper * numReducer 个网络连接，耗费过多 CPU 资源，带来性能和稳定性问题；Shuffle 数据单正本导致数据失落时，须要从新计算，浪费资源。
阿里云提供了独立部署的 RSS，目前曾经在 github 上开源，能够间接对接 ACK，用户无需关注 Shuffle 数据是否有本地磁盘反对。原先的 spark shuffle 数据保留在 executor 本地磁盘，应用 RSS 后，shuffle 的数据就交给 RSS 来治理了。其实采纳 push based 的内部 shuffle service 业界曾经是一种共识了，很多公司都在做这方面的优化。长处有很多，Executor 执行结束即可回收，节约资源；RSS 还将传统的大量随机读优化成了追加写，程序读，进一步补救了 Spark Shuffle 的效率问题；RSS 服务反对 HA 部署，多正本模式，升高反复计算的可能性，进一步保障 Spark 工作的效率。
4. 加强 K8s 作业级别调度
K8s 默认的调度器调度粒度是 Pod，然而传统的 Spark 任务调度默认粒度是 application。一个 Application 的启动，会随同启动多个 Pod 执行反对。所以，忽然提交大量 Spark 工作时，可能呈现大量 Driver Pod 启动，单都在期待 Executor Pod 启动，从而导致整个集群死锁。另一方面，K8s 的多租户场景反对不佳，也不反对租户之间的弹性调度，以及动静配额等。相比于 YARN 的调度策略，K8s 的调度策略繁多，为默认优先级 +FIFO 的形式，无奈做到偏心调度。
阿里云 ACK 在这个方面做了加强：
- 调度时优先判断资源是否满足，解决上述可能呈现的死锁问题。
- 基于 NameSpace 实现多租户树状队列，队列能够设置资源上上限，反对队列间抢占资源。
- 实现了以 App 粒度调度 Spark 作业的优先级队列，反对队列间的偏心。调度，并基于 Spark-on-K8s-operator 的扩大，提交作业会主动进入队列。
5. 云上数据湖存储与减速
- 在 K8s 环境下，相比于传统的 Hadoop 集群，应用数据湖存储 OSS 更贴合存算拆散的架构。Spark on ACK 内置 Jindo SDK，无缝对接 OSS。
- Fluid 可撑持 Spark on K8s 部署模式下的缓存减速，在 TPC-DS 场景下，能够晋升运行速度 30% 左右。
6. 应用 DLF 构建云上数据湖
在 K8s 上想要应用 Hadoop 生态圈的组件，还须要额定部署。然而 Spark on ACK 无缝对接阿里云 DLF（Data Lake Formation），DLF 提供了对立的元数据服务，反对权限管制和审计，另外提供数据入湖的性能，反对 Spark SQL 的交互式剖析，以及数据湖治理性能，反对进行存储剖析和老本优化。
7. 易用性晋升
Spark on ACK 提供了一个 CLI 工具，能够间接以 spark-submit 语法来提交 spark 作业，同时也会记录到 spark-operator 外面来治理。之前咱们提到了 2 种提交作业形式的优劣，spark-operator 具备比拟好的作业管理能力，然而提交作业不兼容老的命令语法，也无奈跑交互式 shell，从老集群迁徙的用户改变比拟麻烦，因而利用咱们这种工具，能够同时享受 2 种提交形式的长处，对用户的易用性来说是个比拟大的晋升。
在日志收集这一点，Spark on ACK 提供日志收集计划，并通过 HistoryServer 让用户能够像 Spark on YARN 一样在界面上查看。