为什么需要 DAG 2.0 架构升级？

作为从阿里云飞天系统创建伊始就开始研发的伏羲分布式作业执行框架，DAG 1.0 在过去十年中支撑了阿里集团的大数据业务，在系统规模以及可靠性等方面都走在了业界领先。

另外一方面，作为一个开发了十年的系统，虽然在这个期间不断的演进，DAG 1.0 在基本架构上秉承了比较明显的 Map-Reduce 执行框架的一些特点，逻辑图和物理图之间没有清晰的分层，这导致在这个基本架构上要继续向前走，支持更多 DAG 执行过程中的动态性，以及同时支持多种计算模式等方面，都比较困难。

事实上今天在 MaxCompute SQL 线上，离线作业模式以及准实时作业模式（smode）两种执行模式，使用了两套完全分开的分布式执行框架，这也导致对于优化性能和优化系统资源使用之间的取舍，很多情况下只能走两个极端，而无法比较好的 tradeoff。除此之外，随着 MaxCompute 以及 PAI 引擎的更新换代以及新功能演进，上层的分布式计算自身能力在不断的增强。对于AM组件在作业管理，DAG 执行等方面的动态性，灵活性等方面的需求也日益强烈。

在这样的个大的背景下，为了支撑计算平台下个 10 年的发展，伏羲团队启动了 DAG 2.0 的项目，将从代码和功能方面，完整替代 1.0 的 JobMaster 组件，实现完全的升级换代。在更好的支撑上层计算需求的同时，也同时对接伏羲团队在 shuffle 服务（shuffle service）上的升级，以及 Fuxi master (Resource Manager) 的功能升级。与此同时，站在提供企业化服务的角度来看，一个好的分布式执行框架，除了支持阿里内部极致的大规模大吞吐作业之外，我们需要支持计算平台向外走，支持云上各种规模和计算模式的需求。

除了继续锤炼超大规模的系统扩展能力以外，我们需要降低大数据系统使用的门槛，通过系统本身的智能动态化能力，来提供自适应（各种数据规模以及处理模式）的大数据企业界服务，是 DAG 2.0 在设计架构中考虑的另一重要维度。

以上内容摘自《“伏羲”神算》电子书，点击https://developer.aliyun.com/topic/download?id=873