云原生Apache Spark调度与云功调度器

视频记录

-大家好。今天，欢迎来到2020年Spark + AI峰会。

今天我要讲的是云原生Spark调度与云瞻调度器。

我是Li Gao，我是Databricks Compute Fabric的技术首席工程师，之前我是Lyft数据基础设施的技术主管。今天我还和一位名叫Weiwei Yang的人聊了聊，他是Cloudera计算平台的技术主管。bob体育客户端下载他也是Apache Hadoop委员会和PMC成员，前阿里巴巴和IBM。

今天的议程，我将开始讨论为什么Lyft选择在Kubernetes上运行Spark负载。然后讨论如何使用定制的Kubernetes调度来优化Spark在Kubernetes上的运行。然后Weiwei，我们将开始讨论Spark调度与新的Apache YuniKorn调度程序，我们将深入研究YuniKorn的特性。最后，我们将分享云瞻调度器的社区和路线图。

k8在Lyft数据格局中的作用

Kubernetes是我们在Lyft广泛使用的数据和服务，在这张图片中，展示了数据站点的景观，在非常高的水平。我们在Lyft的数据用例，包括商业智能BI用例，主要基于Apache Superset进行用户交互。然后我们有机器学习和深度学习数据科学家使用Jupyter笔记本与我们的数据进行交互。在数据工程方面，我们的大多数数据工程师都利用开源Apache气流来授权ETL工作流。在所有这些不同的用例中，利用这些不同的数据计算处理引擎，将Spark主要应用于我们的批处理计算和许多工作，并与机器学习和深度学习引擎交互。我们还有Presto用于交互式查询引擎，还有Druid用于实时度量存储和计算。所有这些计算引擎都在我们的计算基础设施上运行，这些基础设施主要在Kubernetes上，SAN仍然在EC2上，我们数据环境中的所有数据都在存储云存储中，也就是s3，我们的DataBake，然后在RDS上运行样本元数据。

为什么Spark选择k8

为什么Spark选择Kubernetes ?Kubernetes是目前最活跃的容器编配器开源编配器，选择容器化spark计算的好处是它为我们提供了一个非常共享的资源，横跨不同的机器学习和ETL作业。它们还支持多个Spark版本，就像我们的客户需要的Python版本一样，通过容器化方法，我们还可以在那些共享Kubernetes集群上启用版本控制容器，以实现更快的开发迭代。并为我们稳定的生产进行回滚和前滚。Kubernetes引擎也有一种方式，它为我们提供了统一和先进的可观察性，以及跨数据计算和微服务的资源隔离支持。Kubernetes支持还支持细粒度访问控制，这对我们在这个共享计算资源上支持许多合规性和安全性用例非常有益。

Spark K8s Infra @ Lyft

现在，让我们更深入地谈谈Spark在Kubernetes上是如何在Lyft上使用的。这是对Lyft如何使用Spark的一个非常高水平的概述。

从我们的工作通过核心数据基础设施网关，它在许多基于标签的计算资源上路由流量，标签将穿梭到给定集群池中的不同集群池，可能是一个或多个Kubernetes集群，您可以共享一个或多个s3桶作为我们的持久存储，其中一些可能有自己的专用存储出于隐私和安全原因。计算端所有这些作业也共享相同的元数据集，即它们的模式元数据、沿袭和发现元数据。

Spark K8s作业的多步骤创建

现在，让我们更深入地研究一下如何在Lyft环境下的Kubernetes上启动Spark作业。我的工作是通过第一个资源标签看到这个数据基础设施网关，或者我们降落在集群池上，在集群池中我们有一个叫做集群池控制器的概念，它会给你一个特定的Kubernetes集群，在Kubernetes特定的Kubernetes集群中，我们有一个命名空间组和命名空间组控制器的概念，它可以把任务分成不同的命名空间。当它登陆到特定的Kubernetes命名空间时，它可以实现一个Spark CRD，这是一个由开源Spark on Kubernetes运营商支持的对象，由GCP(谷歌云平台)开源。bob体育客户端下载一旦CRD被写入，被控制器读取，它将实现Spark执行器和驱动pod实现者，最后，计算机可以启动并与数据库对话。

现有Spark K8s基础设施的问题

即使是这样设计的，在我们生产系统后，我们注意到AWS存在问题。那些Kubernetes Spark基础设施。这种设计的第一个值得注意的问题是处理系统规模的多层控制器的复杂性。然后由于多层控制器，某些情况下的延迟会从底层放大到上层。在这两个问题之上。我们还注意到，在添加更多特性时，需要在作业、集群和名称空间之间共享不同的优先级，这很难在不同层之间进行管理和协调。

现在让我们关注单个集群。即使是单个集群，我们也注意到默认调度器存在高延迟的问题。当我们有大量的批处理作业时，就会发生这种情况，在某些情况下，在Pod甚至Spark Pod可以在给定节点上执行之前，可能会有100秒的延迟。我们注意到的下一个问题是另一端。当我们有一个非常大的批处理作业共享相同的资源池时，在这些pod之间进行FAIR共享就变得不可预测，这对我们的最终结果是不希望的。我们讨论了不同的队列需求，我们需要FIFO和FAIR共享资源，需要作业集群，而默认调度器并没有很好地支持这些。然后会有更多的工作岗位出现，尤其是在数据工程师和数据科学方面，工作量方面。需要对优先级管理提供弹性和分层的支持，这是用于调度pod的默认调度器所缺乏的。最后，我们的客户希望将我们在Hadoop Young World中所拥有的站点行为的一些可见性注入到组件世界中，这是默认调度器所缺乏的。最后，我们希望你们使用这个定制的Kubernetes调度程序或者我们可以在我们的实现中有一个简化的控制器层。

下面交给维维来介绍一下雨瞻的Spark Scheduling，并介绍一下雨瞻的调度器。

-好的，这是Weiwei，接下来我将介绍yuunikorn的Spark Scheduling，并深入研究yuunikorn的功能。

《Running Spark》在K8s上的味道

首先，在Kubernetes上运行Spark有几种不同的版本。一个是Kubernetes上的原生Spark，这实际上是用户同意运行Spark，使启动器Spark驱动舱，然后驱动舱申请Scooterpods的请求。另一种方法是利用Spark Kubernetes操作符，它是由谷歌开源的，它不是通过Spark -submit提交作业，而是创建一个Spark应用程序CRD，然后Spark操作符将帮助管理作业的生命周期，为你提供Spark作业。

k8中的资源调度

对于Kubernetes中的资源调度，当我们运行Spark时，我们看到，我们首先需要了解Kubernetes中的资源调度是如何工作的。所以默认的调度器工作流非常简单。在人类语言中，这就像调度程序每次选择一个pod并找到最合适的节点，然后在该节点上启动pod。从Kubernetes 115开始，它提供了调度器框架，或者你可以从框架扩展中插入一定数量的扩展。你可以做一些过滤，你可以做一些排序，但总的来说工作流程是一样的。

Spark on k8:调度挑战

然后，让我们来看看当我们在Kubernetes上运行Spark时，我们遇到了什么样的调度挑战。我们的目的是，将Spark工作负载从遗留的Hadoop集群转移到基于Kubernetes的集群，因为这将为我们提供一个统一的架构，用于计算平台，支持在prime on cloud混合云上的多个环境。bob体育客户端下载Spark是计算引擎的超能力。它有多个工作负载。它支持多种工作负载类型，包括Ad-Hoc查询、批处理作业、工作流和流式作业。当它们结合在一起时对于平台来说是相当复杂的运行时。bob体育客户端下载当我们将Spark迁移到Kubernetes时，我们注意到一些主要在两方面的挑战。一个是作业调度。因为我们在共享环境中运行了如此多的作业，可能来自多个租户、多个用户团队，因此作业排序变得非常重要。还有工作排队，没有工作排队。 And secondly, the job level priority is also important to ensure some of the urgent jobs can be can run and resource fairness becomes important when we want to share the resources between jobs were the namespaces are queues and also the gang scheduling. The needs for gang scheduling is very essential for the machine learning workloads, as well as for Spark. So the second category is the resource sharing and utilization. What we have observed is when we run Spark on Kubernetes, the utilization is not that good. And sometimes the Spark driver pods occupy all the resources in the namespace, and sometimes there is a resource competition which happens, when it happens the big jobs get starved. And also there are some other misbehave jobs. By that I mean when some of the job maybe have some bad configuration or is being picky on nodes, and depending there those files will waste cluster resource. And also another important factor is the throughput. So for a batch-oriented system, the throughput is very important to ensure the latency. And when we move on the cloud, that is even more important because the throughputs are directly impact the cost. So the summary is the Kubernetes default schedule was not created to tackle those challenges. So it was built for services, normally services. But when it comes to such a complex scenario, it just doesn’t work.

Apache yuunikorn(孵化)

这就是我们为什么要创建另一个调度器来修复这些差距的原因。因此，在2019年初，我们启动了一个名为“雨牛”的项目。现在是我们的鲈鱼孵化项目。简单地说，这个项目是Kubernetes的一个独立的资源调度程序。它专注于构建调度能力，将大数据导入Kubernetes，其中最重要的一部分是支持Spark。而且很容易看到它的用途。它是一个运行在Kubernetes上的无状态服务，你可以很容易地使用Helm Charts来启动它，也可以用作Kubernetes的备用调度器，因为它是功能完整的Kubernetes调度器。

然后让我们来看看yuunikorn是如何在Spark中进行资源调度的。记住，Kubernetes中调度的工作流程非常简单，只有三步。首先是用户提交一堆应用程序，然后API服务器为应用程序创建一堆pod。在这个蓝框中，资源调度器我们有一些调度逻辑来决定我应该把哪个节点分配pod。然后第三步是将pod绑定到特定的节点。

当我们查看默认调度器时，它的工作原理非常简单。当pod被创建时，调度器会得到通知所有的pod会被放到一个队列中，你知道工人队列。当我们调度程序运行一个循环从队列中选择pod时，同时，它缓存所有烦人的信息，你的排序并为pod找到最佳节点。

然后让我们看看在雨牛发生了什么。因此，在雨korn中，主要的区别是，当在调度程序中找到pod时，它们首先被识别为应用程序，每个应用程序将被附加到层次结构中的某个Lyft队列中。当调度程序进行调度时，它实际上会进一步遍历所有队列，找到资源最多的队列。然后不只是队列，而是遍历所有应用程序，找到最需要资源的应用程序，然后选择最重要的请求，而不是按优先级选择应用程序同时我们还缓存了节点为请求找到最佳节点。其余的五线谱都是相同的，因此将其绑定到节点。

从这个架构中，我们能得到什么，基本上，宇瞻有队列应用的概念，它给我们，提供了作业调度的能力以及对资源配额的细粒度控制。

主要区别(yuunikorn vs .默认调度器)

如果我们比较默认调度和yuunikithorn，我们可以列出这些功能，我们可以从yuunikorn调度受益。第一个是调度应用程序维度。因此，优尼科恩应用程序是一等公民，优尼科恩调度程序根据您选择的策略对应用程序进行排序，例如，应用程序提交时间或优先级或资源使用。其次，工作指令在雨牛也得到了执行。它支持FIFO, FAIR和优先级排序策略。然后细粒度的资源容量管理基本上，云korn可以将集群资源划分成层次结构的队列，每个队列都可以配置最小和最大的资源，给用户保证的资源和最大的资源。资源公平被强制执行。当然，这些队列，更重要的是，优尼科恩本身就支持大数据工作负载。

所以，我们已经为大数据计算引擎做了很多优化，比如Spark, Flink和Tensorflow。所以用户不需要从应用端修改任何东西，他们可以很容易地使用雨牛。在规模和性能方面，雨牛也进行了性能优化。它具有比默认调度器更好的性能。

和雨牛一起运行Spark

然后再详细介绍一下Spark是如何在yuunikorn运行的。第一个用户，这张图展示了它是如何工作的。从用户的角度来看，从Kubernetes集群的角度来看，从yuunikorn发生的事情来看，有三层。从左到右是时间轴。首先，用户提交了一个Spark作业。它可以是Spark -submit或者来自Spark应用程序CRD。用户看到的用户会说驱动pod在Kubernetes上被创建了，状态是挂起的，然后进入yuunikorn会收到pod被创建的通知，它会创建一个应用程序，这个应用程序会被添加到一个叶子队列中。然后是第二阶段，这个yunkorn将循环运行调度，遍历队列找到应用程序Spark应用程序，找到驱动程序部分，然后将驱动程序荚调度到一个节点上。然后用户会说驱动点取决于，但一旦计划完成，云瞻将在中心阶段，云瞻将要求API服务器将pod绑定到某个节点，然后在Kubernetes集群中，将pod绑定。我们说这个用户说Spark驱动程序正在运行。 Once the driver is running, the driver will start to request for a executors and from on Kubernetes the executors are created and they will be all in pending state in the Ender YuniKorn worlds get notified there some new executors for this job. They will be added to the job. Then the next stage we were do the same scheduling cycle as we do for the driver. Traverse the queues, and the app and the request in the allocated pod on the node. Then eventually we do this repeatedly for all the executors and all the executors will be bound. There’s one more stage being escaped by this slide is after while the job is finished, that means the exclusion will be finished, get cleaned up by the driver, then the driver will be complete.

然后在下一节中，我们将深入研究yuunikorn的一些特性，以及它们对Spark的重要性，并包括一些性能数据。

第一件事是工作顺序。我们已经讨论过几次了。

工作顺序

所以这很重要。因为从用户的角度来看，他们通常期望有一些特定的三个用例。首先，如果我先提交作业，我希望作业先运行。第二种情况是我不想丢掉工作。我不希望我的工作因为其他工作或其他用户而挨饿，使用我的资源和某些用例，我有一个紧急的工作，我想先运行。

因此，为了支持所有这些场景，雨korn有可插拔的排序策略。包括先进先出、公平和优先级。所以Priority目前正在开发中，它将在0.9发布。

下一个主要特性是关于资源配额管理。因此，对于现有的Kubernetes集群，用户非常熟悉命名空间ResourceQuota，它定义了资源限制。实际上，它执行得更好配额准入控制器甚至不是由调度程序完成的。ResourceQuota不足以让场景运行Spark。ResourceQuota存在几个问题。一是很难控制ResourceQuota何时过度提交，因为为了获得集群的一定利用率，ResourceQuota(命名空间)总是超预定。因此在这种情况下，用户很难合理地设置一个namespace的Quota。其次，用户没有保证的资源，这意味着即使您有配额，也可能无法获得任何资源，因为其他名称空间或其他用户正在使用您的资源。第三，电话可能会被滥用。我的意思是，在传统的批处理系统中，总是有一些待处理的作业或待处理的pod。 In that case, the even for the pending pods, the Quota will be used and in that case, the utilization is really bad. And also it doesn’t provide any queuing for the jobs. All this sum up together is what lead up into some problem like the utilization is really, really low and also the latency of the job could be impact.

资源配额管理:yunkorn Queue Capacity

管理配额的另一种方法是使用yuunikorn队列容量。队列为资源配额管理提供了最优解决方案。我为什么这么说?基本上有几个原因。一个是队列可以自动映射到一个或多个名称空间，这意味着这为队列管理提供了零配置和零开销。其次，雨korn的容量从最小到最大是有弹性的，这意味着用户不会获得队列的保证资源，同时也会强制最大。第三，队列尊重资源公平，这意味着我们在队列之间执行公平，资源公平，每个队列都将有助于避免工作和用户挨饿。

然后，配额只对实际消耗了资源的pod计算。这意味着对作业的资源计数更加准确，也有助于提高利用率。最后，队列提供了排队，作业排队。作业可以在调度程序中排队等待某些条件，我们在等待资源。因此，这种方式将使客户端逻辑非常简单。

云瞻队列中的资源公平

这张图是关于资源公平评估的。我们将Kubernetes集群从2000节点模拟到4000节点进行了实验。这是我们在队列之前建立的一个非常简单的例子我们向每个队列提交了很多不同的pod。从图表中，我们可以看到资源公平正在被强制执行。

调度器吞吐量基准

我们也做了更多的测试，作为吞吐量基准。这个测试是在模拟环境中完成的，在20个物理节点上有2000个节点和4000个节点，我们在集群上安排了50,000个pod。我们观察到的是红线代表yuunikorn，绿线代表默认调度器，粗略地说，在任何技能上，我们都可以获得比默认调度器好两倍的性能。

完全兼容K8s

还有一件很重要的事。YuniKorn完全兼容Kubernetes，这意味着它支持所有Kubernetes谓词节点选择器、pod亲和性/反亲和性、污染容错等，也支持卷。卷绑定，动态供应，它与Kubernete事件系统集成，在那里你可以直接获取事件来描述pod。它也可以和集群自动缩放器一起工作。这实际上也是我们最重要的用例之一。支持配额节点等管理命令。

因此，在另一方面，yuunikorn提供了一个管理控制台，让我们可以了解集群资源的使用情况，以及在该集群中运行的应用程序。

雨牛管理控制台

这是一个集群信息汇总页面，在这里您可以了解有多少应用程序正在运行以及一些历史信息。还有一个节点页面，您可以了解有多少节点正在运行以及节点的资源利用率。

类似地，对于应用程序，我们可以在这个页面中显示一个应用程序列表，在这里您可以实际查看它们的应用程序及其位置。

您还可以尝试通过搜索，使用一些关键字来筛选应用程序，它还提供了一个队列视图，您可以在其中查看集群的集群层次结构队列的层次结构，以及每个队列目前的利用率。所以，这是非常重要的，对集群的其他方法很有用。

比较yuunikorn和其他K8s调度器

对比yuunikorn和其他Kubernetes调度器，在寻道调度中，除了默认调度器还有一个叫kube-batch的调度器。我们做一个简单的构型。这主要是基于功能。从我们的角度来看，我们认为调度程序需要涵盖的主要特性是资源共享、资源公平、抢占、枪械调度和吞吐量。基本上，当我们和它们比较的时候。玉牛内置了所有这些功能。对于吞吐量，我们已经与默认调度器做了一些比较，但我们还没有对Kube-batch进行任何测试，但基于现有的问题，我认为它可能不是那么好。

然后让我们来总结一下社区和一些路线图。

项目的当前状态。因此，雨korn于2019年7月开源。

并于2020年1月进入Apache孵化器。最新的可发布版本是0.8，将于5月发布。现在我们有一个非常多样化的社区，成员来自阿里巴巴、Cloudera、微软、Linkedin、苹果、腾讯、英伟达，所有这些成员都给出了很多很好的反馈，帮助我们构建了一个全面的调度器，以满足我们刚才谈到的所有需求。

社区

在社区方面，我们已经有了一些早期用户，第一个是Lyft。李，我想介绍一下Lyft的部分。——确定。因此，在网站上的社区中，我们于2020年初在非生产Kubernetes集群中部署了yuunikorn调度器的早期版本。在这个非生产集群上，我们每天都要损失数百美元的工作，而yuunikorn队列为您提供了队列，根据我们对一些大型作业的观察，调度程序延迟在一些高峰时段减少了三倍。然后，我们还注意到在这个大型作业集群上，Kubernetes集群的整体资源利用率在每台计算的成本方面比默认的kube-scheduler在混合工作负载方面有所提高。最后，与默认调度相比，FIFO和FAIR请求的要求得到了更多的满足。回到维维。-在Cloudera，云korn提供了Cloudera公共云产品。为Spark提供了资源配额管理和高级作业调度功能。 And more importantly, it is responsible for both Microsoft’s service and the batch job scheduling. So it’s used as a replacement as the default scheduler. And it is running on Cloud with auto-scaling enabled And in Alibaba, so Alibaba is a early community user for YuniKorn and also very important member in the community. So Alibaba deployed on the pre-production environment with over 100 nodes for well, and that is measured on prime and they plan to deploy on 1000 more nodes in production use for this year. And this is, so Alibaba is leveraging YuniKorn features such as hierarchy queues, resource fairness to run large scale Flink jobs on Kubernetes. And from the observation that we observe there’s almost four times improvements for the scheduling performance. And the roadmap. So currently we 0.8 is the latest datable version and already shipped with a bunch of features such as Hirechay queues, cross queue fairness, Fair/FIFO job ordering policies, Fair/Bin-packing nodes sorting policies, self queue management, pluggable discover, metrics system, Prometheus integrations, this is a long list, but one simple summary is YuniKorn can be used as primary schedular to support the use case to run Spark, run big data. And the data coming in 0.9. We are working on the gang scheduling, job and task priority support, and also to support a Spark dynamic allocation.

我们的愿景-大数据和机器学习的资源管理

把所有这些放在一起，这就是我们的愿景。对于计算，我们知道对于大数据，我们想要将大数据从遗留的Hadoop集群转移到Kubernetes。我们想要在Kubernetes上少运行一些计算。这包括数据工程，实时流，机器学习和计算引擎，如Spark, Flink, Hive, TensorFlow(低语)，而且平台还需要支持微软批处理作业，长时间运行的工作负载，集群中可能发生的各种工作负载，以及从用户角度来看的目标，我们希望提供多租户环境，以SLA支持适当的资源共享，良好的利用率，良好的成本管理，bob体育客户端下载预算等等。所以，所有这些，我们的愿景是建立一个统一的计算平台，用于大数据和机器学习，这是基于Kubernetes加上以yuunikornbob体育客户端下载为调度器的功能。

所以，雨korn仍然是一个年轻的项目，所以加入我们的社区。我们在这里列出了网站和一些你们可能想要查看的材料，我们也有一些委员会会议来思考和讨论这些问题。