MaxCompute履行引擎核心技术DAG揭秘

作为业界少有的EB级别数据分布式平台,MaxCompute系统每天支撑上千万个分布式功课的运转。在这个量级的功课数目上,毫无疑问平台需要支撑的功课特点也多种多样:既有在”阿里体量”的大数据生态中独有的包含数十万计较节点的超大型功课,也有中小规模的分布式功课。同时不同用户对于不同规模/特点的功课,在运转时间,资材使用效率,数据吞吐率等方面,也有着不同的期待。Fig.1 MaxCompute线上数据分析基于功课的不同规模,当前MaxCompute平台提供了两种不同的运转形式,下表对于这两种形式做了总结对比:Fig.2

作为业界少有的EB级别数据分布式平台,MaxCompute系统每天支撑上千万个分布式功课的运转。在这个量级的功课数目上,毫无疑问平台需要支撑的功课特点也多种多样:既有在”阿里体量”的大数据生态中独有的包含数十万计较节点的超大型功课,也有中小规模的分布式功课。同时不同用户对于不同规模/特点的功课,在运转时间,资材使用效率,数据吞吐率等方面,也有着不同的期待。

image.png

Fig.1 MaxCompute线上数据分析

基于功课的不同规模,当前MaxCompute平台提供了两种不同的运转形式,下表对于这两种形式做了总结对比:

image.png

Fig.2 离线(batch)形式 vs 一体化调剂准及时(smode)形式

从上图可以看到,离线功课和一体化调剂的准及时功课,在调剂方式,数据传输,使用资材来源等多个方面,都有非常显著的区别。可以说,这两种运转方式分别代表了在海量数据场景上按需请求资材来优化吞吐量和资材利用率,以及在处理中等(少量)数据时通过计较节点的全量预拉起来(以及数据直传等手段加速)降低履行时延的两个极端。而这些区别,最终会通过履行时间和功课资材利用率等方面体现出来。很显然,以高Throughput为主要优化目标的离线形式,和以追求低Latency的准及时形式,在各方面的功能指标会有很大的区别。比如以1TB-TPCH标准benchmark为例,此报告履行时间(功能)和资材消耗两个维度来做比较。可以看到,准及时的(SMODE)在功能上有着非常明显的优势(2.3X),但是这样的功能提升也并不是没有代价的。在TPCH这个特定的场景上,一体化履行的SMODE形式,在获取了2.3X功能提升的同时,也消耗了3.2X的系统资材(cpu * time)。

1588374237965-533f7ae9-ca0a-4b07-8bf5-3e526385cf65.png

Fig.3 功能/资材消耗比较:离线(batch)形式 vs 一体化调剂准及时(smode)形式

这个观察结论其实并不意外,或者从某种程度上是by design的。拿下图一个典型SQL产生的DAG来看,所有计较节点都在功课提交伊始就被拉起,虽然这样的调剂方式允许数据得以(在需要的时候)pipeline起来,从而可能加速数据的处理。但并不是所有的履行计划里的所有上下游计较节点都可以有理想化的pipelined dataflow。事实上对于许多功课而言,除了DAG的根节点(下图中的M节点)以外,下游的计较节点在某种程度上都存在着一定程度的浪费。

1588374772549-e3812c1a-f26b-45cf-b9e9-9937aefc6747.png

Fig.4 一体化调剂准及时(smode)形式下,可能的资材使用低效

这种空转造成的资材使用的低效,在数据的处理流程上存在barrier算子而无法pipeline,以及在DAG图比较深的情况下会尤为明显。当然对于希望极致优化功课运转时间的场景而言,通过更多的资材消耗,来获取极致的功能优化,在一些场景上是有其合理性的。 事实上,在一些business-critical的在线服务系统中,为了保证服务总是能迅速响应并处理峰值数据,平均个位数的CPU利用率也并非少见。但是对于计较平台这种量级的分布式系统,能否在极致功能以及高效的资材利用率之间,获取一个更好的平衡呢

答案是肯定的。这就是我们在这里要介绍的混合计较形式:Bubble Execution

1. Bubble Execution 概述

DAG框架的核心架构思想,在于对履行计划的逻辑层与物理层的清晰分层设计。物理履行图是通过对逻辑图中的节点、边等的物理特性(如数据传输介质,调剂时机,资材特性等)的物化来实现的。对比在Fig.2中描述的batch形式和smode形式,DAG提供了在一套灵活的调剂履行框架之上,统一离线形式和准及时一体化履行形式的实现。如同下图所示,通过调整计较节点和数据连接边的不同物理特性,不仅能对现有的两种计较形式做清晰的表述,在对其进行更通用化的扩展后,还可以探索一种全新的混合运转形式,也就是Bubble Execution。

1.png

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)两个方面的比较:

1.png

Fig.6.a 功能(Latency)比较:Bubble形式 vs 离线(batch)形式 vs 一体化调剂准及时(smode)形式

从运转时间来看,Bubble形式显然要远优于离线形式(完全2X的功能提升),而较准及时的一体化调剂形式而言,Bubble的履行功能也并没有太明显的下降。当然在一些数据可以非常有效利用pipeline处理的query(比如Q5, Q8等),准及时功课还是有一定的优势。但SMODE功课在履行时间上的优势并不是没有代价的,如果同时考虑资材消耗,在下图中,我们可以看到,准及时功课的功能提升是建立在资材消耗远远大于Bubble形式的前提之上的。而Bubble在功能远优于离线形式的同时,其资材消耗,则完全上是相近的。

1.png

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。

1.png

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的边)上的数据,均通过落盘方式进行传输。

1.png

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。

1.png

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

在这个初始DAG基础上,按照上面介绍过的完全原则,以及本章节最后描述的一些实现细节,上图描述的初始状态,可以经过多轮算法迭代,最终产生如下的Bubble切分结果。在这个结果中产生了两个Bubbles: Bubble#0 [V2, V4, V7, V8],Bubble#1 [V6, V10], 而其他的节点则被判断将使用离线形式运转。

1.png

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的直接后继/前驱,也包含间接后继/前驱

1.png

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。

1.png

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实现粒度更精细的容错机制等等。

1.png

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。

1.png

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会重头开始履行。

2.png

Fig 14. AM Failover with Bubbles

3. 上线效果

当前Bubble形式已经在公共云全量上线,SQL功课中34%履行Bubble,日均履行包含176K个Bubble。

我们针对signature相同的query在bubble execution关闭和打开时进行对比,我们发现在完全的资材消耗基本不变的基础上,功课的履行功能提升了34%,每秒处理的数据量提升了54%。

image.png

image.png

Fig 15. 履行功能/资材消耗对比

除了完全的对比之外,我们针对VIP用户也进行了针对性的分析,用户Project在打开了Bubble开关之后(下图中红色标记的点为打开Bubble的时间点),功课的平均履行功能有非常明显的提升。

image.png

Fig 16. VIP用户开启Bubble后平均履行时间对比

image.png

原创文章,作者:阿里云大数据AI技术,如若转载,请注明出处:https://www.iaiol.com/news/maxcompute-lyu-xing-yin-qing-he-xin-ji-shu-dag-jie-mi/

(0)
上一篇 2021年 8月 25日 下午2:45
下一篇 2021年 8月 25日 下午2:47

相关推荐

  • 如何更迷信地研讨AI+迷信?顶级学者将云集这次ICML研讨会

    ICML将举行一个AI+迷信的研讨会,由来自全球顶尖机构的研讨职员举行,集结了AI+各迷信畛域的领跑者。

    2022年 3月 30日
  • 模型听人讲几句就能学得更好?斯坦福提出用谈话表明辅助进修

    谈话是人与人之间最自然的沟通方式,能帮助我们传递很多重要的信息。斯坦福大学人工智能实验室(SAIL)近日发表博客,介绍了其两篇 ACL 2020 论文。这两项研究立足于近段时间 BERT 等神经谈话模型的突破性成果,指出了一个颇具潜力的新方向:利用谈话表明来辅助进修 NLP 乃至计算机视觉范畴的使命。

    2020年 12月 1日
  • 揭秘Hologres如何支持超高QPS在线办事(点查)场景

    Hologres(中文名交互式分解)是阿里云自研的一站式及时数仓,这个云原生系统融合了及时办事和分解大数据的场景,全面兼容PostgreSQL协定并与大数据生态无缝打通,能用同一套数据架构同时支持及时写入及时盘问以及及时离线联邦分解。它的出现简化了业务的架构,为业务提供及时决策的能力,让大数据发挥出更大的商业价值。本期将为大家揭秘Hologres如何支持超高QPS点查。传统的 OLAP 系统在业务中往往扮演着比较静态的角色,以通过分解海量的数据得到业务的洞察(比如说预计算好的视图、模型等),从这些海量数据分解到的结

    2021年 7月 29日
  • 华盛顿大学《天生模型》2020秋季课程完结,课件、讲义全部放出

    这门课聚焦天生建模技术的理论和数学基础,探讨多种天生模型技术。

    2021年 1月 29日
  • 香港中文大学薛天帆老师招收全奖博士生、硕士生 | 2023夏季

    新的一期招生正式启动!本期我们将为大家介绍香港中文大学多媒体实验室招收全日制全奖博士生和硕士生等相关信息。

    2022年 10月 26日
  • 此芯科技退出Linaro Windows on Arm工作组,推动Arm全世界生态建设

    近日,通用智能芯片公司此芯科技宣布退出致力于Arm生态系统软件开发的全世界协调工程组织Linaro,成为国内首家退出Windows on Arm工作组的成员。Windows on Arm 工作组旨在为 Windows 建立一个健康的、可持续的 Arm 生态系统。该工作组可为开发人员供应种种工具、编程语言及专业框架支援,助力程序编译速度的提升及Windows on Arm要地开发的兑现。此芯科技专一推动Arm架构设备的智能计较发展。退出Windows on Arm 工作组后,此芯科技将负责Arm原生开发、原生应用支援及

    2022年 7月 27日
  • 量子力学与机械进修相结合,展望低温下的化学反应

    编辑/凯霞在低温下从氧化物中提炼金属不仅对于钢铁等金属的生产至关重要,而且对回收利用也必不可少。但当前的提炼过程是碳密集型的,会排放大量温室气体。钻研人员一直在探索开发「更绿色」的工艺法子。第一性道理理论的自下而上的计较过程设想,将是一个有吸引力的替代方案,但迄今为止尚未实现。来自哥伦比亚大学的钻研团队开发了一种新的计较技术,将量子力学和机械进修相结合,可准确展望金属氧化物对其「贱金属」的复原温度。该法子在计较上与常规计较一样有效,并且在测试中,比利用量子化学法子对温度效应的计较要求高的模拟更准确。该钻研以「Aug

    2021年 12月 13日
  • 优化器怎么选?一文教你挑选适合不同ML项目的优化器

    为机械进修项目挑选符合的优化器不是一件简单的事。

    2021年 1月 5日
  • 超越现有标的57.3%,邢波教授、胡志挺教授团队提出一致NLG评估框架

    长期以来,评估机器天生的文本比较困难。近日,CMU邢波(Eric Xing)教授和UCSD胡志挺(Zhiting Hu)教授的团队提出用一种运算符,一致各类天生恣意的评估方式,为未来各种新恣意、新要求提供了更加一致的指导。实验表明,基于一致框架安排的评估标的,在多个恣意上超过了现有标的与野生评分的类似度,现在通过PyPI和GitHub可以直接调用。

    2022年 1月 28日
  • 四位RISC先驱获「工程学界诺贝尔奖」,图灵奖得主David Patterson、John Hennessy获奖

    2022 年度的「工程学界诺贝尔奖」——查尔斯 · 斯塔克 · 德拉普尔奖颁给了四位 RISC 架构的先驱。其中,David A. Patterson 和 John L. Hennessy 是 2017 年的图灵奖得主,Stephen B. Furber 和 Sophie M. Wilson 共同计划了全球第一款商业 RISC 处理器——第一个 Arm 原型(Arm1)。

    2022年 1月 11日

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注