江苏龙网

  1. 首页 > 人文 > >

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


2.3 上线数据
以下是10w规模集群/10万作业并发场景调度器核心指标（5个Scheduler、5个RMS ， 单RMS负责2w台机器 ， 单Scheduler并发处理2w个作业） 。 通过数据可以看到 ， 集群10w台机器的调度利用率超过了99% ， 关键调度指标 ， 单Scheduler向RMS commit的slot的平均数目达到了1w slot/s 。
在保持原有单调度器各项核心指标稳定不变的基础上 ， 去中心化的多调度器框架实现了机器规模和应用并发度的双向扩展 ， 彻底解决了集群的可扩展性问题 。
阿里经济体核心调度系统Fuxi
本文插图
目前资源调度的新架构已全面上线 ， 各项指标持续稳定 。 在多调度器架构基础上 ， 我们把机器学习场景调度策略进行了分离 ， 通过独立的调度器来进行持续的优化 。 同时通过测试专用的调度器 ， 我们也让资源调度具备了灰度能力 ， 调度策略的开发和上线周期显著缩短 。
4. 计算调度2.0 - 从静态到动态
分布式作业的执行与单机作业的最大区别 ， 在于数据的处理需要拆分到不同的计算节点上 ， “分而治之”的执行 。 这个“分”,包括数据的切分 ， 聚合以及对应的不同逻辑运行阶段的区分 ， 也包括在逻辑运行阶段间数据的shuffle传输 。 每个分布式作业的中心管理点 ， 也就是application master (AM) 。 这个管理节点也经常被称为DAG (Directional Acyclic Graph ，有向无环图) 组件 ， 是因为其最重要的责任 ， 就是负责协调分布式系统中的作业执行流程 ， 包括计算节点的调度以及数据流(shuffle) 。
对于作业的逻辑阶段和各个计算节点的管理, 以及shuffle策略的选择/执行 ， 是一个分布式作业能够正确完成重要前提 。 这一特点 ， 无论是传统的MR作业 ， 分布式SQL作业 ， 还是分布式的机器学习/深度学习作业 ， 都是一脉相承的 ， 为了帮助更好的理解计算调度(DAG和Shuffle)在大数据平台中的位置 ， 我们可以通过MaxCompute分布式SQL的执行过程做为例子来了解：
阿里经济体核心调度系统Fuxi
本文插图
在这么一个简单的例子中 ， 用户有一张订单表order_data ， 存储了海量的交易信息 ， 用户想所有查询花费超过1000的交易订单按照userid聚合后 ， 每个用户的花费之和是多少 。 于是提交了如下SQL query:
INSERT OVERWRITE TABLE result SELECT userid, SUM(spend) FROMorder_data WHERE spend > 1000 GROUP BY userid;这个SQL经过编译优化之后生成了优化执行计划 ， 提交到fuxi管理的分布式集群中执行 。 我们可以看到 ， 这个简单的SQL经过编译优化 ， 被转换成一个具有M->R两个逻辑节点的DAG图 ， 也就是传统上经典的MR类型作业 。 而这个图在提交给fuxi系统后 ， 根据每个逻辑节点需要的并发度 ， 数据传输边上的shuffle方式 ， 调度时间等等信息 ， 就被物化成右边的物理执行图 。 物理图上的每个节点都代表了一个具体的执行实例 ， 实例中包含了具体处理数据的算子 ， 特别的作为一个典型的分布式作业 ， 其中包含了数据交换的算子shuffle——负责依赖外部存储和网络交换节点间的数据 。 一个完整的计算调度 ， 包含了上图中的DAG的调度执行以及数据shuffle的过程 。
阿里计算平台的fuxi计算调度 ， 经过十年的发展和不断迭代 ， 成为了作为阿里集团内部以及阿里云上大数据计算的重要基础设施 。 今天计算调度同时服务了以MaxCompute SQL和PAI为代表的多种计算引擎 ， 在近10万台机器上日均运行着千万界别的分布式DAG作业 ， 每天处理EB数量级的数据 。 一方面随着业务规模和需要处理的数据量的爆发 ， 这个系统需要服务的分布式作业规模也在不断增长；另一方面 ， 业务逻辑以及数据来源的多样性 ， 计算调度在阿里已经很早就跨越了不同规模上的可用/够用的前中期阶段 ， 2.0上我们开始探索更加前沿的智能化执行阶段 。


推荐阅读


上一篇：『美军』美国欠中国的钱可造一万架歼-20，如果不还怎么办？专家称美国不敢

下一篇：那个年薪3亿的“打工皇帝” 终究是雷军得不到的男人