阿里经济体核心调度系统Fuxi( 七 )

4.1.2 DAG2.0 动态灵活统一的执行框架
DAG2.0通过逻辑图和物理图的清晰分层，可扩展的状态机管理，插件式的系统管理，以及基于事件驱动的调度策略等基座设计，实现了对计算平台上多种计算模式的统一管理，并更好的提供了作业执行过程中在不同层面上的动态调整能力。作业执行的动态性和统一DAG执行框架是DAG2.0的两个主要特色：
作业执行的动态性
如前所诉，分布式作业执行的许多物理特性相关的问题，在作业运行前是无法被感知的。例如一个分布式作业在运行前，能够获得的只有原始输入的一些基本特性(数据量等) ，对于一个较深的DAG执行而言，这也就意味着只有根节点的物理计划(并发度选择等) 可能相对合理，而下游的节点和边的物理特性只能通过一些特定的规则来猜测。这就带来了执行过程中的不确定性，因此，要求一个好的分布式作业执行系统，需要能够根据中间运行结果的特点，来进行执行过程中的动态调整。
而DAG/AM作为分布式作业唯一的中心节点和调度管控节点，是唯一有能力收集并聚合相关数据信息，并基于这些数据特性来做作业执行的动态调整。这包括简单的物理执行图调整（比如动态的并发度调整），也包括复杂一点的调整比如对shuffle方式和数据编排方式重组。除此以外，数据的不同特点也会带来逻辑执行图调整的需求：对于逻辑图的动态调整，在分布式作业处理中是一个全新的方向，也是我们在DAG 2.0里面探索的新式解决方案。
还是以map join优化作为例子，由于map join与默认join方式(sorted merge join)对应的其实是两种不同优化器执行计划，在DAG层面，对应的是两种不同的逻辑图。 DAG2.0的动态逻辑图能力很好的支持了这种运行过程中根据中间数据特性的动态优化，而通过与上层引擎优化器的深度合作，在2.0上实现了业界首创的conditional join方案。如同下图展示，在对于join使用的算法无法被事先确定的时候，分布式调度执行框架可以允许优化提交一个conditional DAG ，这样的DAG同时包括使用两种不同join的方式对应的不同执行计划支路。在实际执行时， AM根据上游产出数据量，动态选择一条支路执行(plan A or plan B) 。这样子的动态逻辑图执行流程，能够保证每次作业运行时，根据实际产生的中间数据特性，选择最优的执行计划。在这个例子中，

当M1输出的数据量较小时，允许其输出被全量载入下游单个计算节点的内存， DAG就会选择优化的map join(plan A) ，来避免额外的shuffle和排序。
当M1输出的数据量大到一定程度，已经不属于map join的适用范围， DAG就可以自动选择走merge join ，来保证作业的成功执行。

本文插图
除了map join这个典型场景外，借助DAG2.0的动态调度能力， MaxCompute在解决其他用户痛点上也做了很多探索，并取得了不错的效果。例如智能动态并发度调整：在执行过程中依据分区数据统计调整，动态调整并发度；自动合并小分区，避免不必要的资源使用，节约用户资源使用；切分大分区，避免不必要的长尾出现等等。
统一的AM/DAG执行框架
除了动态性在SQL执行中带来的重大性能提升外， DAG 2.0抽象分层的点，边，图架构上，也使其能通过对点和边上不同物理特性的描述，对接不同的计算模式。业界各种分布式数据处理引擎，包括SPARK, FLINK, HIVE, SCOPE, TENSORFLOW等等，其分布式执行框架的本源都可以归结于Dryad提出的DAG模型。我们认为对于图的抽象分层描述，将允许在同一个DAG系统中，对于离线/实时/流/渐进计算等多种模型都可以有一个好的描述。
如果我们对分布式SQL进行细分的话，可以看见业界对于不同场景上的优化经常走在两个极端：要么优化throughput (大规模，相对高延时) ，要么优化latency(中小数据量，迅速完成) 。前者以Hive为典型代表，后者则以Spark以及各种分布式MPP解决方案为代表。而在阿里分布式系统的发展过程中，历史上同样出现了两种对比较为显著的执行方式：SQL线离线(batch)作业与准实时(interactive)作业。这两种模式的资源管理和作业执行，过去是搭建在两套完全分开的代码实现上的。这除了导致两套代码和功能无法复用以外，两种计算模式的非黑即白，使得彼此在资源利用率和执行性能之间无法tradeoff 。而在DAG 2.0模型上，通过对点/边物理特性的映射，实现了这两种计算模式比较自然的融合和统一。离线作业和准实时作业在逻辑节点和逻辑边上映射不同的物理特性后，都能得到准确的描述: