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

离线作业：每个节点按需去申请资源，一个逻辑节点代表一个调度单位；节点间连接边上传输的数据，通过落盘的方式来保证可靠性；
准实时作业：整个作业的所有节点都统一在一个调度单位内进行gang scheduling；节点间连接边上通过网络/内存直连传输数据，并利用数据pipeline来追求最优的性能。

在此统一离线作业与准实时作业的到一套架构的基础上，这种统一的描述方式，使得探索离线作业高资源利用率，以及准实时作业的高性能之间的tradeoff成为可能：当调度单位可以自由调整，就可以实现一种全新的混合的计算模式，我们称之为Bubble执行模式。

本文插图
这种混合Bubble模式，使得DAG的用户，也就是上层计算引擎的开发者(比如MaxCompute的优化器) ，能够结合执行计划的特点，以及引擎终端用户对资源使用和性能的敏感度，来灵活选择在执行计划中切出Bubble子图。在Bubble内部充分利用网络直连和计算节点预热等方式提升性能，没有切入Bubble的节点则依然通过传统离线作业模式运行。在统一的新模型之上，计算引擎和执行框架可以在两个极端之间，根据具体需要，选择不同的平衡点。
4.1.3 效果
DAG2.0的动态性使得很多执行优化可以运行时决定，使得实际执行的效果更优。例如，在阿里内部的作业中，动态的conditional join相比静态的执行计划，整体获得了将近3X的性能提升。

本文插图
混合Bubble执行模式平衡了离线作业高资源利用率以及准实时作业的高性能，这在1TB TPCH测试集上有显著的体现，

Bubble相对离线作业：在多使用20%资源的情况下， Bubble模式性能提升将近一倍；
Bubble相对准实时模式：在节省了2.6X资源情况下，Bubble性能仅下降15%;

4.2 Fuxi Shuffle 2.0 - 磁盘内存网络的最佳使用
4.2.1 背景
大数据计算作业中，节点间的数据传递称为shuffle, 主流分布式计算系统都提供了数据shuffle服务的子系统。如前述DAG计算模型中， task间的上下游数据传输就是典型的shuffle过程。
在数据密集型作业中， shuffle阶段的时间和资源使用占比非常高，有其他大数据公司研究显示，在大数据计算平台上Shuffle阶段均是在所有作业的资源使用中占比超过50%. 根据统计在MaxCompute生产中shuffle占作业运行时间和资源消耗的30-70% ，因此优化shuffle流程不但可以提升作业执行效率，而且可以整体上降低资源使用，节约成本，提升MaxCompute在云计算市场的竞争优势。
从shuffle介质来看，最广泛使用的shuffle方式是基于磁盘文件的shuffle. 这种模式这种方式简单，直接，通常只依赖于底层的分布式文件系统，适用于所有类型作业。而在典型的常驻内存的实时/准实时计算中，通常使用网络直连shuffle的方式追求极致性能。 Fuxi Shuffle在1.0版本中将这两种shuffle模式进行了极致优化，保障了日常和高峰时期作业的高效稳定运行。
挑战
我们先以使用最广泛的，基于磁盘文件系统的离线作业shuffle为例。
通常每个mapper生成一个磁盘文件，包含了这个mapper写给下游所有reducer的数据。而一个reducer要从所有mapper所写的文件中，读取到属于自己的那一小块。右侧则是一个系统中典型规模的MR作业，当每个mapper处理256MB数据，而下游reducer有10000个时，平均每个reducer读取来自每个mapper的数据量就是25.6KB, 在机械硬盘HDD为介质的存储系统中，属于典型的读碎片现象，因为假设我们的磁盘iops能达到1000, 对应的throughput也只有25MB/s, 严重影响性能和磁盘压力。