大数据场景下 Volcano 高效调度能力实践

摘要：本篇文章将会从 Spark on Kubernetes 发展历程以及工作原理，以及介绍一下 Spark with Volcano，Volcano 如何能够帮助 Spark 运行地更高效。

本篇文章将会从 Spark on Kubernetes 发展历程以及工作原理，第二部分大概介绍一下 Spark with Volcano，Volcano 如何能够帮助 Spark 运行地更高效。

Spark on Kubernetes

我们来看 Spark on Kubernetes 的背景。其实 Spark 在从 2.3 这个版本开始之后，就已经支持了 Kubernetes native，可以让 Spark 的用户可以把作业运行在 Kubernetes 上，用 Kubernetes 去管理资源层。在 2.4 版本里增加了 client mode 和 Python 语言的支持。而在今年的发布的 Spark 3.0 里面，对 Spark on Kubernetes 这一方面也增加了很多重要的特性，增加动态资源分配、远端 shuffle service 以及 Kerberos 支持等。

Spark on Kubernetes 的优势：

1）弹性扩缩容

2）资源利用率

3）统一技术栈

4）细粒度的资源分配

5）日志和监控

Spark submit 工作原理

Spark 对于 Kubernetes 的支持，最早的一种工作方式是通过 Spark 官方的 spark submit 方式去支持，Clinet 通过 Spark submit 提交作业，然后 spark driver 会调用 apiserver 的一些 api 去申请创建 executor，executor 都起来之后，就可以执行真正的计算任务，之后会做日志备份。

image

这种方式有一个优势是，传统的 Spark 用户切换到这种方式之后用户体验改变大。但也存在缺少作业周期管理的缺陷。

Spark-operator 工作原理

第二种 Spark on Kubernetes 的使用方式就是 operator。operator 是更 Kubernetes 的方式，你看他的整个作业提交，先是 yaml 文件通过 kubectl 提交作业，在这里面它有自己的 crd，即 SparkApplication，Object。创建了 SparkApplication 之后， Controller 可以 watch 到这些资源的创建，后边流程其实是复用的第一种工作模式，但是通过这种模式，做的更完善的一些。

image

相对于第一种方式来讲，这里的 Controller 可以维护对象生命周期，可以 watch spark driver 的状态，并更新 application 的状态，是一个更完善的解决方案。

这两种不同的使用方式使用是各有优势，不少的公司两种方式都有使用。这一块在官网也有介绍。

Spark with Volcano

Volcano 对于上面提到两种工作方式都进行了集成和支持。这个链接是我们维护的 Spark 开源代码仓库：

https://github.com/huawei-clo...

在这里面 Volcano 做的事情其实也很简单，你看整个提交的过程，首先是通过 spark submit 提交作业，提交作业时会创建一个 podgroup，podgroup 包含了用户配置的一些调度相关的信息。它的 yaml 文件大家可以看到，页面右边这个部分，增加了 driver 和 executor 两个角色。

image

Volcano 队列

队列其实我们在第一堂和第二堂课里面也讲到了。因为 Kubernetes 里面没有队列的支持，所以它在多个用户或多个部门在共享一个机器的时候资源没办法做共享。但不管在 HPC 还是大数据领域里，通过队列进行资源共享都是基本的需求。

image

在通过队列做资源共享时，我们提供了多种机制。图最上面的这种，这里面我们创建两个队列，通过这两个队列去共享整个集群的资源，一个队列给他分 40%的咨询资源，另一个给他分 60%的资源，这样的话就可以把这两个不同的队列映射到不同的部门或者是不同的项目各自使用一个队列。这在一队列里，资源不用的时候，可以给另外一个队列里面的作业去使用。下面讲的是两个不同的 namespace 之间的资源平衡。Kubernetes 里当两个不同的应用系统的用户都去提交作业时，提交作业越多的用户，他获得的集群的资源会越多，所以在这里面基于 namespace，我们进行公平的调度，保证 namespace 之间可以按照权重分享集群的资源。

Volcano: Pod delay creation

之前介绍这个场景的时候，有些同学反映没有太听懂，所以我加了几页 PPT 扩展一下。

举个例子，我们在做性能测试的时候，提交 16 个并发的作业，对于每个作业来讲，它的规格是 1 driver+4 executor，整个集群总共有 4 台机器 16 个核，这样的一个情况。

image

同时提交 16 个 spark job 的时候，driver pod 的创建和 executor pod 的创建之间有一个时间差。因为有这个时间差，当 16 个 spark 的 job 跑起来之后把整个机群全部占满了，就会导致同时提交并发量特别大作业的时候，整个集群卡死。

为了解决这种情况，我们做了这样的事情。

image

让一个节点专门去跑 driver pod。其他三个节点专门去跑 executor pod，防止 driver pod 占用更多的资源，就可以解决被卡死的问题。

但也有不好的地方，这个例子里节点是 1:3 的关系。在真实的场景下，用户的作业的规格都是动态的， 而这种分配是通过静态的方式去划分，没办法跟真实的业务场景里动态的比例保持一致，总是会存在一些资源碎片，会有资源的浪费。

因此，我们增加了 Pod delay creation 的功能，增加这个功能之后不需要对 node 去做静态的划分，整个还是 4 个节点，在 16 个作业提上来的时候，对于每个作业增加了 podgroup 的概念。Volcano 的调度器会根据提上来作业的 podgroup 进行资源规划。

image

这样就不会让过多的作业会提交上来。不但可以把 4 个节点里面所有的资源全部用完，而且没有任何的浪费，在高并发的场景下控制 pod 创建的节奏。它的使用也非常简单，可以按照你的需求配资源量，解决高并发的场景下运行卡死或者运营效率不高的情况。

Volcano: Spark external shuffle service

我们知道原来的 Spark 已经很完善了，有很多特别好用的功能，Volcano 保证了迁移到 Kubernetes 上之后没有大的功能缺失：

1)ESS 以 daemonset 的方式部署在每个节点

2)Shuffle 本地写 Shuffle 数据，本地、远端读 shuffle 数据

3)支持动态资源分配

image

点击关注，第一时间了解华为云新鲜技术~