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

1. 引言
过去10年，是云计算的10年，伴随云计算的爆炸式增长，大数据行业的工作方式也发生了很大的变化：从传统的自建自运维hadoop集群，变成更多的依赖云上的弹性低成本计算资源。海量大数据客户的信任和托付，对阿里大数据系统来说，是很大的责任，但也催生出了大规模、多场景、低成本、免运维的MaxCompute通用计算系统。
同样的10年，伴随着阿里年年双11 ， MaxCompute同样支撑了阿里内部大数据的蓬勃发展，从原来的几百台，到现在的10万台物理机规模。
双线需求，殊途同归，海量资源池，如何自动匹配到大量不同需求的异地客户计算需求上，需要调度系统的工作。本文主要介绍阿里大数据的调度系统FUXI往2.0的演进。先给大家介绍几个概念：

首先，数据从哪里来？数据往往伴随着在线业务系统产生。而在线系统，出于延迟和容灾的考虑，往往遍布北京、上海、深圳等多个地域，如果是跨国企业，还可能遍布欧美等多个大陆的机房。这也造成了我们的数据天然分散的形态。而计算，也可能发生在任意一个地域和机房。可是网络，是他们中间的瓶颈，跨地域的网络，在延迟和带宽上，远远无法满足大数据计算的需求。如何平衡计算资源、数据存储、跨域网络这几点之间的平衡，需要做好“数据调度” 。
其次，有了数据，计算还需要CPU ，内存，甚至GPU等资源，当不同的公司，或者单个公司内部不同的部门，同时需要计算资源，而计算资源紧张时，如何平衡不同的用户，不同的作业？作业也可能长短不一，重要程度不尽相同，今天和明天的需求也大相径庭。除了用户和作业，计算资源本身可能面临硬件故障，但用户不想受影响。所有这些，都需要“资源调度” 。
有了数据和计算资源，如何完成用户的计算任务，比如一个SQL query？这需要将一个大任务，分成几个步骤，每个步骤又切分成成千上万个小任务，并行同时计算，才能体现出分布式系统的加速优势。但小任务切粗切细，在不同的机器上有快有慢，上下步骤如何交接数据，同时避开各自故障和长尾，这些都需要“计算调度” 。
很多不同用户的不同小任务，经过层层调度，最后汇集到同一台物理机上，如何避免单机上真正运行时，对硬件资源使用的各种不公平，避免老实人吃亏。避免重要关键任务受普通任务影响，这都需要内核层面的隔离保障机制。同时还要兼顾隔离性和性能、成本的折中考虑。这都需要“单机调度” 。

本文插图
2013年，伏羲在飞天5K项目中对系统架构进行了第一次大重构，解决了规模、性能、利用率、容错等线上问题，并取得世界排序大赛Sortbenchmark四项冠军，这标志着Fuxi 1.0的成熟。
2019年，伏羲再次出发，从技术上对系统进行了第二次重构，发布Fuxi 2.0版本：阿里自研的新一代高性能、分布式的数据、资源、计算、单机调度系统。 Fuxi 2.0进行了全面的技术升级，在全区域数据排布、去中心化调度、在线离线混合部署、动态计算等方面全方位满足新业务场景下的调度需求。
伏羲2.0成果概览? 业内首创跨地域多数据中心的数据调度方案-Yugong ，通过3%的冗余存储，节省80%的跨地域网络带宽? 业内领先的去中心化资源调度架构，单集群支持10万服务器*10万并发job的高频调度? 动态DAG闯入传统SQL优化盲区， TPC-DS性能提升27% ， conditional join性能提升3X 。 ? 创新性的数据动态shuffle和全局跨级优化，取代业界磁盘shuffle；线上千万job ，整体性能提升20% ，成本下降15% ，出错率降低一个数量级? 在线离线规模化混合部署，在线集群利用率由10%提升到40% ，双十一大促节省4200台F53资源，且同时保障在线离线业务稳定。