在大规模平台上启用推测执行的最佳实践bob体育客户端下载

Venkata sowrra…:大家好，我是Venkata，我的同事Ron和我一起来演讲。今天，我们将呈现一个演讲题目，在大规模平台上启用投机执行的最佳实践。bob体育客户端下载好吧。让我们看一下议程。今天的议程我们将从背景和动机开始，讨论在大型平台上实现投机执行的一些问题。bob体育客户端下载然后我们讨论了我们对Spark引擎在推测执行方面所做的改进。用推测执行来配置它。在演讲的后半部分，Ron将讨论投机度量，以及通过案例研究启用投机执行之前和之后所做的分析。然后，我们将分享我们在使用用户指导实现推测执行的过程中获得的一些经验，并最终通过特性工作和总结进行控制。
好的。让我们快速入门一下投机执行。对于我们这些对Spark中的投机执行不感兴趣的人。Spark通过作为一个阶段的一部分并行运行任务来实现[听不清]。在这种情况下，当有任务运行得比其他类似任务慢得多时，Spark启动是在不同主机上重复执行任务，作为推测执行的一部分。在相同任务执行的两个实例之间，无论哪个实例先完成，都可以用于研究。另一个被杀了。通过在Spark中检查这个案例研究，可以进一步确认这一点。我们讲了投机执行。让我们快速查看一些可用于调音的调音旋钮。 Spark speculation conflict is used to enable or disable speculative execution of a Spark application.
触发投机间隔冲突决定了检查任务投机的频率。接下来的两个冲突是投机执行的关键冲突。星火投机多人模式上的星火投机分位数，星火投机多人模式在一个阶段内调整投机执行的侵略性。任务比中值慢多少次才能被考虑为一种推测。火花投机分位数决定了在投机开始之前必须完成的任务的比例。
现在让我们看看谈话的动机。所有这些推测性的执行加速了零散的任务，但增加了额外的开销。所以不需要在团队之间取得平衡。Spark推测执行默认冲突通常是激进的，特别是对于坏的选项卡，而且推测运行几秒钟的任务可能是浪费的。所以为了避免这种情况，我们也要调查数据倾斜的影响，在推测的背景下，开销洗牌服务。另外，在多租户大型集群中默认启用推测性执行的影响需要进行早期研究。现在我们已经看到了演讲的动机，让我们看看我们在投机执行的背景下对Spark本身所做的一些改进。任务只运行几秒钟，猜测这个结果是不必要的。为了防止运行了几秒钟的任务被推测，我们在内部引入了新的Spark冲突，Spark speculative minRuntime Threshold来防止任务在运行一分钟阈值时间之前被推测。根据我们的实验，目前在我们的环境中，这个时间被设置为30秒。
后来Apache Spark作为Spark -33741的一部分也添加了类似的更改。目前，Spark的投机执行没有更多可用的指标。如果没有足够的度量标准，就很难理解投机执行的顺序或结果。为了理解[听不清]现有的AppStatusListener的有用性和开销，特别是在事件中的TaskStart。现在我们看到了许多带有推测性执行的附加指标。让我们看看我们在这里为投机执行添加了哪些附加指标。类似于常规阶段级别的指标，我们添加了用于推测执行的指标。一些指标是某个阶段推测任务的总数，成功推测任务的数量，失败和失败推测任务的数量。现在有了新添加的指标，我们可以得到Spark案例研究下每个阶段的推测摘要，我们可以从截图中看到。这些指标有助于在需要时进一步调整冲突。
不幸的是，默认的推测参数通常过于激进和有用。LinkedIn的Spark职位主要提供糟糕的工作，这意味着投机参数可能处于集中状态。让我们来看看LinkedIn平台的调测参数。bob体育客户端下载在我们的平台中。bob体育客户端下载我们的投机乘数是4，而操作系统是1.5。从我们的实验来看，将投机乘数设置为1.5通常会导致过早的投机，导致[听不清]。此外，Spark的推测分位数为0.9，而OS为1.5。
这是需要的，因为它是最后10%的任务，比一组任务花费的时间长。同样，火花投机的最小阈值设置为30秒，正如我们之前看到的。这意味着运行时间少于30秒的任务会被推测。现在minThreshold被设置为30秒。我们还可以将Spark推测时间间隔放宽到1秒，就像我们不会推测至少运行30秒的任务一样。No Ron将作为案例研究的一部分以及在平台级别进一步带您分析指标。bob体育客户端下载轮到你了，罗恩。

Ron:谢谢你，Venkata。现在我要向你们展示我们进行的投机度量数据。我也会和你们分享我们的绩效分析我们关心ROI，投资回报。我们想知道回报或绩效收益的程度。对于给定的性能增益。我们还想知道投资的程度或额外的开销，我们在一个拥有10,000多台机器的非常大的集群上测量一周的各种指标。基本上，我们的环境是一个多租户环境，每天有超过40,000个Spark应用程序在运行。我们实现了动态分配，资源共享和争用，工作性能由于一些变化的延迟或拥塞而变化。
现在，让我们看看任务级别和一周期间的统计数据。我们看看所有发射推测任务的比例。顺便说一下，正如Venkata前面提到的，我们将投机阈值设置为30秒。因此，我们将考虑那些持续时间大于30秒的任务进行推测。现在我们来看看这个持续时间。投机任务的持续时间占所有常规任务持续时间的比例只是这0.32%中的一个很小的百分比。而且在一周的时间里，我们一共启动了273万次投机任务。现在我要介绍这个富有成效的思辨任务的概念。我们的思辨任务如果能早于相应的常规任务完成，是卓有成效的。这里我们发现，如果我们把富有成效的任务总数除以所有启动的投机任务，我们得到60%。 The success rate at 60% is high. This is because we set conservative values in our configuration parameters.
现在让我们看看阶段级别的统计数据。这里我们只考虑持续时间为30秒的阶段。而且一个阶段至少要完成10个任务。我们称这个阶段为合格阶段。在所有符合条件的阶段中，41%的阶段已经启动了投机任务。在那些已经启动投机任务的阶段中，76%的阶段获得了一定的性能收益。这意味着他们已经完成了一些富有成效的任务。让我们看看应用程序级别的统计信息。在一周内，我们总共有157个Spark应用程序。38%的Spark应用程序启动了投机任务，其中87%的应用程序受益于投机执行，因为这些应用程序至少有一个富有成效的投机任务。
超过82%的Spark应用程序受益于推测和执行。在我们的多租户环境中，我们有许多生产作业，也有许多开发作业围绕着我们的许多启动集群。工作每天都在变化。这里我们只是对一个关键任务应用程序进行抽样。而且这个应用每天都在运行，它总共有29个Spark应用流程。有些火花流每天运行，有些火花流每小时运行，每个流都有明确定义的SLA。表层协议。我们在开始投机前两周和投机后两周对所有流量进行了测量。在这个图中，我们可以看到启用推测之前和之后的作业运行时间。为了给每个作业流提供相同的路径，我们计算所有流程的所有作业消耗时间的几何平均值。 And that we found out that after we enabling speculation, we were able to reduce job elapsed time by 17%.
我们还完成了所有作业运行时间的标准偏差的几何平均值。我们发现，在启用推测之后，我们能够将作业运行时间的标准差降低41%。所以41%的标准差下降是很显著的。这是因为在启用推测功能之前，所有作业都是运行的，作业的运行时间范围很大。所以他们中的许多人没有达到SLA，表面上的协议。在我们启用了推测之后，我们能够减少作业运行时间的变化，使它们都可以在一个狭窄的范围内完成，从而满足SLA。我们还以千兆小时为单位查看总资源消耗。这里用千兆字节表示内存消耗，也就是在CPU上消耗的小时数或者以小时为单位的持续时间千兆字节-小时是CPU和内存资源消耗的总和。
我们使用这个公式:驱动程序内存(gb)乘以应用程序持续时间(小时)。这是驱动程序总资源消耗。对于执行器资源消耗，我们使用执行器运行时间，即任务运行时间。我们基本上是把阶段内所有任务的时间都加起来，我们把它们加在一起。然后我们把所有阶段的数字加在一起，然后乘以执行程序的内存，单位是gb。然后我们可以得到总的执行程序资源消耗。我们发现，在启用投机之后，我们能够将总资源消耗减少24%。现在，这个任务直到什么情况推测才有帮助。第一种情况是，映射器任务很慢，因为舍入执行器太忙，或者由于硬件或软件问题导致系统挂起。在我们启用推测之前，我们经常看到“run away”任务有时是由于一些系统挂起。 Basically, we see the system hang after a Spark driver has launched a task. But Spark driver has been waiting for a long time without ending response.
我们称之为“逃跑”任务。在启用投机之后，我们很少看到“逃跑”任务。这是因为“逃跑”任务稍后被杀死，因为它们对应的推测任务可以更早完成。还有另一种情况。网络路由拥塞。在某处。当我们启动推测任务时，这个推测任务可能会采取不同的网络路线。在更好的局部性方面，常规任务通常会达到NODE。本地或机架。本地副本。推测任务通常到达“ANY”数据副本。如果初始任务没有以最优的方式启动，它的推测任务可以有更好的局部性。 Also to have some situation where a speculation cannot help. The first one is data skew. When a data skew exist, even we launch a speculation task using different data copy, however, data skew still exist. So speculation cannot help the data skew case.
第二种情况是shuffle曲面过载，导致减速器任务延迟。因为shuffle服务是由[听不清]中的所有执行者共享的。然后也只有一个shuffle数据副本。所以推测对这个案子没有帮助。第三种情况，没有足够的内存，导致任务磁盘溢出。基本上，Spark driver不知道任务停止的根本原因。它不知道集群系统中所有组件的当前状态。您将根据我们设置的配置参数值启动其他推测任务。现在，我们要总结一下关于什么思想。在LinkedIn，我们进一步增强了Spark引擎来监控投机指标，并且在这个想法中，我们分享了我们的配置设置来管理投机的执行。
我要说的是，根据您的性能目标，您需要决定您可以容忍多少开销。然后，您可以设置相应的配置参数。我想指出的是，如果你的工作流程像LinkedIn的工作流程一样，很多批次的离线和工作，那么你可以使用我们的工作配置参数，设置作为参考。就投资回报率而言。如果投机参数设置得当，就会有一些投资开销，也会有一些回报。第一投入，网络消息有小幅增加。第二次投资。Spark驱动的开销很小。还有一些回报。第一个返回值很好地节省了执行器资源。 The second return is a good reduction in the job elapsed time. The third return is, you can get significant reduction in the variation of the job elapsed time. You can’t have better predictable and more consistent job performance.
在我们未来的工作中，我们将研究在Spark driver中添加智能，以决定是否启动推测任务。就像我提到的，有些情况下投机任务是有帮助的。也有一些情况是投机任务无法帮助的。我们需要区分这两种情况，如果我们可以知道我们集群系统中所有组件的状态，这可以帮助我们区分我们有哪种情况。同样在今天，许多人在云上运行Apache Spark。在云端，我们有无限的资源。但是，我们需要考虑每月的费用。启动额外的执行器不是成本。最后，我们要感谢Eric Boideschweiler、Sunitha Beeram和LinkedIn Spark团队的所有成员，感谢他们启发性的讨论和富有洞察力的评论。我们的演讲到此结束。 We welcome your feedback. Thank you.