简介：作为业界少有的EB级数据分布式平台，MaxCompute每天撑持上千万个分布式作业的运行。这些作业特点各异，既有蕴含数十万计算节点的超大型作业，也有中小规模的分布式作业。不同用户对于不同规模/特点的作业，在运行工夫，资源应用效率，数据吞吐率等方面，也有着不同的期待。DAG作为MaxCompute执行引擎的核心技术之一，在提供了底层对立的动静执行框架的同时，实现了一个在离线混合的执行模式(Bubble Execution)，达到了均衡极致性能以及高效的资源利用率的目标。

作为业界少有的EB级别数据分布式平台，MaxCompute零碎每天撑持上千万个分布式作业的运行。在这个量级的作业数目上，毫无疑问平台须要撑持的作业特点也多种多样：既有在"阿里体量"的大数据生态中独有的蕴含数十万计算节点的超大型作业，也有中小规模的分布式作业。同时不同用户对于不同规模/特点的作业，在运行工夫，资源应用效率，数据吞吐率等方面，也有着不同的期待。

Fig.1 MaxCompute线上数据分析

基于作业的不同规模，以后MaxCompute平台提供了两种不同的运行模式，下表对于这两种模式做了总结比照:

Fig.2 离线(batch)模式 vs 一体化调度准实时(smode)模式

从上图能够看到，离线作业和一体化调度的准实时作业，在调度形式，数据传输，应用资源起源等多个方面，都有十分显著的区别。能够说，这两种运行形式别离代表了在海量数据场景上按需申请资源来优化吞吐量和资源利用率，以及在解决中等(大量)数据时通过计算节点的全量预拉起来(以及数据直传等伎俩减速)升高执行时延的两个极其。而这些区别，最终会通过执行工夫和作业资源利用率等方面体现进去。很显然，以高Throughput为次要优化指标的离线模式，和以谋求低Latency的准实时模式，在各方面的性能指标会有很大的区别。比方以1TB-TPCH规范benchmark为例，此报告执行工夫(性能)和资源耗费两个维度来做比拟。能够看到，准实时的(SMODE)在性能上有着非常明显的劣势(2.3X)，然而这样的性能晋升也并不是没有代价的。在TPCH这个特定的场景上，一体化执行的SMODE模式，在获取了2.3X性能晋升的同时，也耗费了3.2X的系统资源(cpu * time)。

Fig.3 性能/资源耗费比拟：离线(batch)模式 vs 一体化调度准实时(smode)模式

这个察看论断其实并不意外，或者从某种程度上是by design的。拿下图一个典型SQL产生的DAG来看，所有计算节点都在作业提交伊始就被拉起，尽管这样的调度形式容许数据得以(在须要的时候)pipeline起来，从而可能减速数据的解决。但并不是所有的执行打算里的所有上下游计算节点都能够有理想化的pipelined dataflow。事实上对于许多作业而言，除了DAG的根节点(下图中的M节点)以外，上游的计算节点在某种程度上都存在着肯定水平的节约。

Fig.4 一体化调度准实时(smode)模式下，可能的资源应用低效

这种空转造成的资源应用的低效，在数据的解决流程上存在barrier算子而无奈pipeline，以及在DAG图比拟深的状况下会尤为显著。当然对于心愿极致优化作业运行工夫的场景而言，通过更多的资源耗费，来获取极致的性能优化，在一些场景上是有其合理性的。 事实上，在一些business-critical的在线服务零碎中，为了保障服务总是能迅速响应并解决峰值数据，均匀个位数的CPU利用率也并非少见。然而对于计算平台这种量级的分布式系统，是否在极致性能以及高效的资源利用率之间，获取一个更好的均衡呢？

答案是必定的。这就是咱们在这里要介绍的混合计算模式：Bubble Execution

1. Bubble Execution 概述

DAG框架的外围架构思维，在于对执行打算的逻辑层与物理层的清晰分层设计。物理执行图是通过对逻辑图中的节点、边等的物理个性(如数据传输介质，调度机会，资源个性等)的物化来实现的。比照在Fig.2中形容的batch模式和smode模式，DAG提供了在一套灵便的调度执行框架之上，对立离线模式和准实时一体化执行模式的实现。如同下图所示，通过调整计算节点和数据连贯边的不同物理个性，不仅能对现有的两种计算模式做清晰的表述，在对其进行更通用化的扩大后，还能够摸索一种全新的混合运行模式，也就是Bubble Execution。

Fig.5 DAG框架上的多种计算模式

直观上来了解，如果咱们把一个Bubble当作一个大的调度单位，Bubble外部的资源一起申请运行，并且外部上下游节点的数据均通过网络/内存直连传输。与之绝对的，Bubbles之间连贯边上的数据传输，则通过落盘形式来传输。那么离线和准实时作业执行，其实能够认为是Bubble执行的两个极其场景：离线模式能够认为是每个stage都独自作为single-bubble的特例，而准实时框架则是将作业所有计算节点都布局到一个大Bubble外部，来做一体化调度执行的另一个极其。DAG AM曾经将两种计算模式对立到一套调度执行infra之上。使得在两种模式上进行长处互补成为可能，为引入Bubble Execution奠定了根底。

Bubble Execution通过灵便自适应的子图(Bubble)切割，在现有的两个极其之间，提供了一种选取更细粒度，更通用的调度执行办法，达到作业性能和资源利用率之间获取优化的tradeoff的办法。在依据输出数据量、算子个性、作业规模等信息进行剖析后，DAG的Bubble执行模式能够将一个离线作业切分出多个Bubbles，在Bubble外部充分利用网络/内存直连和计算节点预热等形式晋升性能。这种切分形式下，一个DAG运行图中的计算节点，能够都被切入某个Bubble，依据所在DAG中的地位被切入不同Bubbles，还能够齐全不被切入任何Bubble(仍然以传统离线作业模式运行)。这种高度灵便的混合运行模式，使整个作业的运行能更加灵便的自适应线上多种多样作业的特点，在理论生产中具备重要的意义：

  • Bubble模式使更多作业的减速成为可能：一体化调度的准实时作业具备基于整体规模（线上默认2000）的"一刀切"式的准入条件。这一方面是出于无限资源的偏心应用，另一方面也是为了管制节点failure带来的cost。但对于中大型作业，尽管整体规模可能超过准入门限，然而其外部的不同子图，有可能是规模适合，且能够通过数据pipeline等办法来减速的。此外线上局部计算节点因为其自身的个性（比方蕴含UDF等用户逻辑须要平安沙箱），无奈应用预热的准实时资源池执行，而以后非黑即白的模式，会使得一个作业中，只有蕴含一个这种计算节点，整个作业都无奈应用减速模式执行。Bubble模式能较好的解决这些问题。
  • Bubble模式将enable线上两个资源池的买通：以后离线资源(cold)和准实时资源池(warm)作为两种个性不同的线上资源，齐全隔离，各自治理。这种拆散的现状，可能导致资源的节约。比方对于大规模作业，因为齐全无奈利用准实时资源池，排队期待离线资源，而同时准实时资源池可能正处于闲暇状态，反之亦然。Bubble模式能通过在作业外部拉通不同资源的混合应用，使得两者各自补充，削峰填谷。
  • Bubble模式能够整体上进步资源的利用率：从资源利用的角度来看，对于能够满足准实时模式准入的中型作业，因为准实时模式一体式调度拉起的运行模式，尽管运行速度能有所晋升，但主观上会造成肯定水平资源的空转与节约（尤其是DAG图较深以及计算逻辑有barrier时）。这种状况下，依照节点数目，计算barrier等条件，将一体化模式拆解成多个Bubble。这可能无效的缩小节点大量的空转耗费，而且在拆分条件正当的状况下，性能方面的损失也能够做到较低。
  • Bubble模式能无效升高单个计算节点failure带来的代价：一体化的准实时模式执行，因为其数据pipeline的个性，作业的容错粒度和其调度粒度是严密挂钩的：都是all-in-one。也就是说，只有有一个节点运行失败，整个作业都要从新运行。因为作业规模越大，运行过程中可能有节点失败的概率也就越大，这样的failover粒度无疑也限度了其能反对的最大作业规模。而Bubble模式则提供了一个更好的平衡点：单个计算节点的失败，最多只影响同处于一个Bubble的节点。此外Bubble模式对于各种failover做了细粒度的各种解决，咱们将在下文形容。

咱们能够通过规范的TPCH-1TB测试benchmark来直观评测Bubble执行模式的成果。在下层计算引擎(MaxCompute优化器以及runtime等)放弃不变，并且Bubble的大小维持在500（具体Bubble切分规定下文介绍）时，做一下Bubble执行模式与规范离线模式，以及准实时模式，在性能(Latency) 以及资源耗费(cpu * time)两个方面的比拟：

Fig.6.a 性能(Latency)比拟：Bubble模式 vs 离线(batch)模式 vs 一体化调度准实时(smode)模式

从运行工夫来看，Bubble模式显然要远优于离线模式(整体2X的性能晋升)，而较准实时的一体化调度模式而言，Bubble的执行性能也并没有太显著的降落。当然在一些数据能够十分无效利用pipeline解决的query（比方Q5, Q8等），准实时作业还是有肯定的劣势。但SMODE作业在执行工夫上的劣势并不是没有代价的，如果同时思考资源耗费，在下图中，咱们能够看到，准实时作业的性能晋升是建设在资源耗费远远大于Bubble模式的前提之上的。而Bubble在性能远优于离线模式的同时，其资源耗费，则整体上是相近的。

Fig.6.b 资源耗费(cpu * time)比拟：

Bubble模式 vs 离线(batch)模式 vs 一体化调度准实时(smode)模式

综合起来看，Bubble Execution能够很好的联合batch模式和准实时模式的长处：

  • 在执行工夫层面，对于TPCH测试集中的任意query，bubble模式的执行工夫都比batch模式要短，整体上22个Queries总耗时缩减将近2X，靠近service mode模式的耗时；
  • 在资源耗费层面，bubble模式基本上和batch模式相当，相比于service mode模式有大幅度的缩小，整体缩减2.6X。

Fig.6.c Bubble模式与离线/准实时模式的整体比拟

值得阐明的是，在下面的TPCH Benchmark比拟中，咱们把Bubble切分条件简单化了，也就是整体上之限度bubble的大小在500，而没有充分考虑barrier等条件，如果在切分bubble的时候进一步调优，比方对于数据能够无效pipeline起来的节点，尽量保障切分在bubble外部，那作业的执行性能和资源利用率等方面都还能够进一步失去的晋升，这是咱们在理论生产零碎上线过程中会重视思考的。具体上线的成果见Section 3。

在理解了Bubble执行模式的整体设计思维与架构后，接下来开展来讲一下具体Bubble模式的实现细节，以及将这种全新的混合执行模式推上线所须要的具体工作。

2. Bubble的切分与执行

采纳Bubble Execution的作业（以下简称Bubble作业）和传统的离线作业一样，会通过一个DAG master（aka. Application Master）来治理整个DAG的生命周期。AM负责对DAG进行正当的bubble切分，以及对应的资源申请和调度运行。整体而言，Bubble外部的计算节点，将依照计算加速度准则，包含同时应用预拉起的计算节点以及数据传输通过内存/网络直传进行pipeline减速。而不切在bubble外部的计算节点则通过经典离线模式执行，不在bubble外部的连贯边(包含横跨bubble boundary的边)上的数据，均通过落盘形式进行传输。

Fig.7 混合Bubble执行模式

Bubble切分办法，决定了作业的执行工夫和资源利用率。须要依据计算节点的并发规模，节点外部算子属性等信息综合思考。而在切分出bubble之后，Bubble的执行则波及到节点的执行，与数据pipeline/barrier的shuffle形式怎么做到有机的联合，这里离开做一下形容。

2.1 Bubble 切分原理

Bubble Execution的核心思想在于将一个离线作业拆分成多个Bubble来执行。为了切分出有利于作业整体高效运行的bubble，有几个因素须要综合思考：

  • 计算节点外部算子个性：对于同时拉起bubble所有计算节点的调度模式而言，数据在bubble外部的上下游节点之间是否无效的进行pipeline解决，很大水平上决定了在bubble外部，上游节点是否会因处于空转状态带来资源节约。所以在切分bubble的逻辑中，当节点蕴含barrier个性的算子而可能阻塞数据的pipeline时，将思考不将该节点与其上游切入同一个bubble。
  • 单个Bubble外部计算节点数目的多少：如同之前探讨的，一体化的资源申请/运行，当蕴含的计算节点过多时，可能无奈申请到资源，或者即便能申请到其failure代价也可能无法控制。限定Bubble的大小，能够防止过大的一体化运行带来的负面作用。
  • 聚合计算节点，切割Bubble的迭代方向：思考到bubble大小的限度，从上而下切分bubble与从下而上切分bubble两种形式，可能导致切分的后果的不同。对于线上大部分作业而言，解决的数据往往呈倒三角型，对应的DAG也大多数是倒三角形态，所以默认采纳自底向上的算法来切割bubble，也就是从间隔root vertex最远的节点开始迭代。

在上述的几个因素中，算子的barrier属性由下层计算引擎（e.g., MaxCompute的optimizer）给出。一般而言，依赖global sort操作的算子(比方MergeJoin, SorteAggregate等)，会被认为会造成数据阻塞（barrier），而基于hash个性操作的算子则对于pipeline更加敌对。对于单个Bubble外部容许的计算节点数目，依据咱们对线上准实时作业特点的剖析和Bubble作业的理论灰度试验，选定的默认下限在500。这是一个在大多数场景下比拟正当的值，既能保障比拟疾速的拿到全量资源，同时因为解决数据量和DoP根本成正相干关系，这个规模的bubble个别也不会呈现内存超限的问题。当然这些参数和配置，均容许作业级别通过配置进行微调，同时Bubble执行框架也会后继提供作业运行期间动静实时调整的能力。

在DAG的体系中，边连贯的物理属性之一，就是边连贯的上下游节点，是否有运行上的前后依赖关系。对于传统的离线模式，上下游先后运行，对应的是sequential的属性，咱们称之为sequential edge。而对于bubble外部的上下游节点，是同时调度同时运行的，咱们称连贯这样的上下游节点的边，为concurrent edge。能够留神到，这种concurrent/sequential的物理属性，在bubble利用场景上，理论与数据的传送形式(网络/内存直传 vs 数据落盘)的物理属性是重合的(Note: 但这两种仍然是离开的物理属性，比方在必要的时候concurrent edge上也能够通过数据落盘形式传送数据)。

基于这样的分层形象，Bubble切分算法，实质上就是尝试聚合DAG图的节点，将不满足bubble准入条件的concurrent edge还原成sequential edge的过程。最终，由concurrent edge联通的子图即为bubble。在这里咱们通过一个理论的例子来展现Bubble切分算法的工作原理。假如存在下图所示的DAG图，图中的圆圈示意计算顶点（vertex)，每个圆圈中的数字示意该vertex对应的理论计算节点并发度。其中V1和V3因为在作业提交初始，就因为其外部蕴含barrier算子，而被标注成barrier vertex。圆圈之间的连接线示意上下游的连贯边（edge）。橙色线代表（初始）concurrent edge，彩色线代表sequential edge，初始状态图中的sequential edge依据barrier vertex的输入边均为sequential edge的准则确定，其余边默认均初始化为concurrent edge。

Fig.8 示例DAG图(初始状态)

在这个初始DAG根底上，依照下面介绍过的整体准则，以及本章节最初形容的一些实现细节，上图形容的初始状态，能够通过多轮算法迭代，最终产生如下的Bubble切分后果。在这个后果中产生了两个Bubbles: Bubble#0 [V2, V4, V7, V8]，Bubble#1 [V6, V10]， 而其余的节点则被判断将应用离线模式运行。

Fig.9 示例DAG图Bubble切分后果

在上图的切分过程中，自底向上的遍历vertex，并秉承如下准则：

若以后vertex不能退出bubble，将其输出edge均还原为sequential edge（比方DAG图中的V9）；

若以后vertex可能退出bubble，执行广度优先遍历算法聚合生成bubble，先检索输出edge连贯的vertex，再检索输入edge连贯的，对于不能联通的vertex，将edge还原为sequential edge（比方DAG图中遍历V2的输入vertex V5时会因为total task count超过500触发edge还原）。

而对任意一个vertex，只有当满足以下条件能力被增加到bubble中：

  • vertex和以后bubble之间不存在sequential edge连贯；
  • vertex和以后bubble不存在循环依赖，即：
    • Case#1：该vertex的所有上游vertex中不存在某个vertex是以后bubble的上游；
    • Case#2：该vertex的所有上游vertex中不存在某个vertex是以后bubble的上游；
    • Case#3：该vertex的所有上游bubble中不存在某个vertex是以后bubble的上游；
    • Case#4：该vertex的所有上游bubble中不存在某个vertex是以后bubble的上游；

注：这里的上游/上游不仅仅代表以后vertex的间接后继/前驱，也蕴含间接后继/前驱

Fig.10 切分Bubble过程可能存在循环依赖的几种场景

而理论线上bubble的切分还会思考到理论资源和预期运行工夫等信息，比方计算节点的plan memory 是否超过肯定数值，计算节点中是否蕴含UDF算子，生产作业中计算节点基于历史信息（HBO）的预估执行工夫是否超长，等等，这里不再赘述。

2.2 Bubble的调度与执行

2.2.1 Bubble调度

为了实现计算的减速，Bubble外部的计算节点的起源默认均来自常驻的预热资源池，这一点与准实时执行框架雷同。与此同时咱们提供了灵便的可插拔性，在必要的状况下，容许Bubble计算节点从Resource Manager当场申请（可通过配置切换）。

从调度机会上来看，一个Bubble外部的节点调度策略与其对应的输出边个性相干，能够分成上面几种状况：

  • 不存在任何input edge的bubble root vertext(比方 Fig.9中的V2)：作业一运行就被调度拉起。
  • 只有sequential edge输出bubble root vertex(比方 Fig.9中的V6)：期待上游节点完成度达到配置的min fraction比例（默认为100%，即所有上游节点实现）才被调度。
  • Bubble外部的vertex（即所有输出边都是concurrent edge，比方 Fig.9中的V4, V8, V10），因为其齐全是通过concurrent edge进行连贯的，会天然的被与上游同时触发调度。
  • Bubble边界上存在mixed-inputs的bubble root vertex(比方 Fig.9中的V7)。这种状况须要一些非凡解决，尽管V7与V4是通过concurrent edge链接，然而因为V7的调度同时被V3通过sequential edge管制，所以事实上须要期待V3实现min-fraction后能力调度V7。对于这种场景，能够将V3的min-fraction配置为较小(甚至0)来提前触发；此外Bubble外部咱们也提供了progressive调度的能力，对这种场景也会有帮忙。

比方图7中的Bubble#1，只有一条SequentialEdge内部依赖边，当V2实现后，就会触发V6 + V10（通过concurrent edge)的整体调度，从而将整个Bubble#1运行起来。

在Bubble被触发调度后，会间接向SMODE Admin申请资源，默认应用的是一体化Gang-Scheduling(GS)的资源申请模式，在这种模式下，整个Bubble会构建一个request，发送给Admin。当Admin有足够的资源来满足这个申请时，会将，再蕴含预拉起worker信息的调度后果发送给bubble作业的AM。

Fig.11 Bubble与Admin之间的资源交互

为了同时反对缓和资源上以及Bubble外部动静调整的场景，Bubble同时还反对Progressive的资源申请模式。这种模式容许Bubble内的每个Vertex独立申请资源和调度。对于这种申请，Admin只有有增量的资源调度即会将后果发送给AM，直到对应Vertex的request齐全满足。对于这种场景上的独特利用这里临时不做开展。

在准实时执行框架降级后，SMODE服务中的资源管理(Admin)和多DAG作业管理逻辑（MultiJobManager）曾经解耦，因而bubble模式中的资源申请逻辑，只须要和Admin进行交互，而不会对于失常准实时作业的DAG执行治理逻辑带来任何影响。另外，为了反对线上灰度热降级能力，Admin治理的资源池中的每个常驻计算节点均通过Agent+多Labor模式运行，在调度具体资源时，还会依据AM版本，进行worker版本的匹配，并调度满足条件的labor给Bubble作业。

2.2.2 Bubble数据Shuffle

对于穿梭Bubble bourndary上的sequential edge，其上传输的数据和一般离线作业雷同，都是通过落盘的形式来进行数据传输。这里咱们次要探讨在Bubble外部的数据传输方式。依据之前形容的作业bubble切分准则，bubble外部的通常具备充沛的数据pipeline个性，且数据量不大。因而对于bubble外部concurrent edge上的数据，均采纳执行速度最快的网络/内存直传形式来进行shuffle。

这其中网络shuffle的形式和经典的准实时作业雷同，通过上游节点和上游节点之间建设TCP链接，进行网络直连发送数据。这种push-based的网络传送数据形式，要求上下游必须同时拉起，依据链式的依赖传递，这种网络push模式强依赖于Gang-Scheduling，此外在容错，长尾躲避等问题上也限度了bubble的灵活性。

为了更好的解决以上问题，在Bubble模式上，摸索了内存shuffle模式。在这一模式下，上游节点将数据间接写到集群ShuffleAgent(SA)的内存中，而上游节点则从SA中读取数据。内存shuffle模式的容错，扩大，包含在内存不够的时候将局部数据异步落盘保障更高的可用性等能力，由ShuffleService独立提供。这种模式能够同时反对Gang-Scheduling/Progressive两种调度模式，也使其具备了较强的可扩展性，比方能够通过SA Locality调度实现更多的Local数据读取，通过基于血统的instance level retry实现粒度更精密的容错机制等等。

Fig.12 Network Shuffle VS Memory Shuffle

鉴于内存shuffle提供的诸多可扩大劣势，这也是线上Bubble作业选用的默认shuffle形式，而网络直传则作为备选计划，容许在容错代价很小的超小规模作业上，通过配置应用。

2.3 Fault-Tolerance

作为一种全新的混合执行模式，Bubble执行摸索了在离线作业和一体化调度的准实时作业间的各种细粒度均衡。在线上简单的集群中，运行过程中各种各样的失败在劫难逃。而bubble这种全新模式下，为了保障失败的影响最小，并在可靠性和作业性能之间获得最佳的均衡，其对于失败解决的策略也更加的多样化。

针对不同的异样问题，咱们设计了各种针对性容错策略，通过各种从细到粗的力度，解决执行过程中可能波及的各种异样场景解决，比方：向admin申请资源失败、bubble中的task执行失败(bubble-rerun)、bubble屡次执行失败的回退(bubble-renew)，执行过程中AM产生failover等等。

2.3.1 Bubble Rerun

目前Bubble在外部计算节点失败时，默认采纳的retry策略是rerun bubble。即当bubble内的某个节点的本次执行（attempt）失败，会立刻rerun整个bubble，勾销正在执行的同一版本的attempt。在偿还资源的同时，触发bubble从新执行。通过这种形式，保障bubble内所有计算节点对应的(retry) attempt版本统一。

触发bubble rerun的场景有很多，比拟常见的有以下几种：

  • Instance Failed：计算节点执行失败，通常由下层引擎的runtime谬误触发(比方抛出retryable-exception)。
  • Resource Revoked：在线上生产环境，有很多种场景会导致资源节点重启。比方所在的机器整机oom、机器被加黑等。在worker被杀之后，重启之后的worker会按照最后的启动参数从新连回admin。此时，admin会将这个worker重启的音讯封装成Resource Revoked发送给对应的AM，触发bubble rerun。
  • Admin Failover: 因为Bubble作业所应用的计算资源来自于SMODE的admin资源池，当admin因为某些起因Failover，或者SMODE整体服务被重启时，调配给AM的计算节点会被进行。Admin在Failover之后不感知以后各个节点被调配的AM信息，无奈将这些重启的音讯发送给AM。目前的解决办法是，每个AM订阅了admin对应的nuwa，在admin重启之后会更新这个文件. AM感知到信息更新后，会触发对应的taskAttempt Failed，从而rerun bubble。
  • Input Read Error：在计算节点执行时，读不到上游数据是一个很常见的谬误，对于bubble来说，这个谬误实际上有三种不同的类型：
    • Bubble内的InputReadError：因为shuffle数据源也在bubble内，在rerun bubble时，对应上游task也会重跑。不须要再做针对性的解决。
    • Bubble边界处的InputReadError: shuffle数据源是上游离线vertex（或也可能是另一个bubble）中的task产生，InputReadError会触发上游的task重跑，以后bubble rerun之后会被delay住，直到上游血统（lineage）的新版本数据全副ready之后再触发调度。
    • Bubble上游的InputReadError: 如果bubble上游的task呈现了InputReadError，这个事件会触发bubble内的某个task重跑，此时因为该task依赖的内存shuffle数据曾经被开释，会触发整个bubble rerun。

2.3.2 Bubble Renew

在Admin资源缓和时, Bubble从Admin的资源申请可能等因为期待而超时。在一些异常情况下，比方bubble申请资源时刚好onlinejob服务处于重启的距离，也会呈现申请资源失败的状况。在这种状况下，bubble内所有vertex都将回退成纯离线vertex状态执行。此外对于rerun次数超过下限的bubble，也会触发bubble renew。在bubble renew产生后，其外部所有边都还原成sequential edge，并在所有vertex从新初始化之后，通过回放外部所有调度状态机触发事件，从新以纯离线的形式触发这些vertex的外部状态转换。确保以后bubble内的所有vertex在回退后，均会以经典离线的模式执行，从而无效的保障了作业可能失常terminated。

Fig. 13 Bubble Renew

2.3.3 Bubble AM Failover

对于失常的离线作业，在DAG框架中，每个计算节点相干的外部调度事件都会被长久化存储，不便做计算节点级别的增量failover。然而对于bubble作业来说，如果在bubble执行过程产生了AM failover重启，通过存储事件的replay来复原出的bubble，有可能复原到running的中间状态。然而因为外部shuffle数据可能存储在内存而失落，复原成两头running状态的bubble内未实现的计算节点，会因读取不到上游shuffle数据而立即失败。

这实质上是因为在Gang-Scheduled Bubble的场景上，bubble整体是作为failover的最小粒度存在的，所以一旦产生AM的failover，复原粒度也应该在bubble这个层面上。所以对于bubble相干的所有调度事件，在运行中都会被当作一个整体，同时当bubble开始和完结的时候别离刷出bubbleStartedEvent和bubbleFInishedEvent。一个bubble所有相干的events在failover后复原时会被作为一个整体，只有结尾的bubbleFInishedEvent才示意这个bubble能够被认为齐全完结，否则将重跑整个bubble。

比方在下图这个例子中，DAG中蕴含两个Bubble(Bubble#0: {V1, V2}, Bubble#1: {V3, V4})，在产生AM重启时，Bubble#0曾经TERMINATED，并且写出BubbleFinishedEvent。而Bubble#1中的V3也曾经Terminated，然而V4处于Running状态，整个Bubble #1并没有达到终态。AM recover之后，V1，V2会复原为Terminated状态，而Bubble#1会重头开始执行。

Fig 14. AM Failover with Bubbles

3. 上线成果

以后Bubble模式曾经在公共云全量上线，SQL作业中34%执行Bubble，日均执行蕴含176K个Bubble。

咱们针对signature雷同的query在bubble execution敞开和关上时进行比照，咱们发现在整体的资源耗费根本不变的根底上，作业的执行性能晋升了34%，每秒解决的数据量晋升了54%。

Fig 15. 执行性能/资源耗费比照

除了整体的比照之外，咱们针对VIP用户也进行了针对性的剖析，用户Project在关上了Bubble开关之后（下图中红色标记的点为关上Bubble的工夫点），作业的均匀执行性能有非常明显的晋升。

Fig 16. VIP用户开启Bubble后均匀执行工夫比照

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。