阿里云飞天分布式调度（主讲人：陶阳宇）在线视频

亲爱的各位同学大家好

我是陶阳宇

来自阿里云的分布式调度团队

今天我会和大家分享一下

我们在分布式调度系统的

设计 实现 优化

等方面的一些实践

以及由此而总结下来的一些

分布式系统设计的一般性原则

云计算大数据这两个概念

相信大家在无数的场合

报道中都见到过

很多人觉得这两个概念很虚幻

让人感觉云里雾里

有一个共同的问题就是

到底什么是云计算

事实上云计算

并不是无中生有的概念

它其实是将普通的单台

PC的计算能力

通过分布式调度的软件

连接起来

举个例子

假如我们有1TByte的

也就是1024G的

快递运送数据

我们需要统计出

从上海发送到

北京的包裹数量

按单台PC每秒扫描

500兆数据的速度

单台PC处理完所有数据

需要2048秒

大约35分钟

而如果我们通过

分布式调度软件

运行100台机器的集群

那么20秒左右

就可以完成统计任务

这也就是云计算

同学们可以看到

云计算最核心的问题是

如何把100台 1千台

1万台机器

高效的组织起来

灵活的进行任务调度和管理

从而使得我们可以像使用

台式机一样使用云计算

简单而高效

大家都学过计算机

我问一个问题

你觉得台式机中

最核心的模块是什么

那在我们看来最核心的是

处理器CPU

因为他负责整个计算机

所有的CPU时间片

内存等资源的分配

以及多个进程并发运行时

任务调度

今天我要给大家分享的

就是云计算的核心模块

分布式调度

分布式调度就好比是

云计算的中央处理器

在阿里云开发的

云计算系统中

每个模块都有一个特别的

中文名字

整个系统叫飞天

其中的分布式调度叫伏羲

伏羲是古代三皇五帝中的

神话人物

伏羲善于新制

所以我们选了这样一个名字

来表示分布式调度

这样一个模块

这堂课程我们会聊到

分布式调度相关的

最重要的几个话题

任务调度 资源调度

容错机制 规模和隔离

最后我们聊一下

分布式调度的未来发展方向

在这些话题当中

都会有关于分布式系统

设计的一般性原则的总结

那么具体的分布式调度

需要解决什么问题呢

其实就两个问题

第一个问题是任务的调度

如何将几PByte的数据

进行切分并在几千

上万台机器上并行处理

最终汇聚成用户需要的结果

当并行任务中个别失败了

该怎么处理

不同任务之间的数据

如何传递

分布式调度

需要解决的第二个问题是

资源的角度

因为分布式计算天生就是

面向多用户多任务的

如何让多个用户

能够共享集群资源

如何在多个任务之间

调配资源以使得

每个任务公平的得到资源

事实上分布式调度

在业界

已经有好几套实现方案了

大家面临的问题

其实是一样的

除了阿里云的伏羲之外

还有大家知道的Hadoop1.0

以及Hadoop2.0也就是YARN

还有大家知道的

伯克利大学的Mesos系统

下面我会比较一下

这几个系统的主要差别

首先我们看一下

Hadoop系统

在Hadoop1.0系统当中

整个系统会分为

有以下几个角色

第一个是JobTracker

JobTracker是一个中控节点

它集中的进行了资源

和任务的角度

第二个角色是TaskTracker

它是分布在每台机器上的

一个agent负责执行

JobTracker发来的任务

Hadoop1.0这个系统

主要存在的问题是

首先一个规模扩展存在瓶颈

Yahoo报道的最大的

Hadoop1.0的集群规模

是4000台机器

第二个问题是容错性不够强

因为它的JobTracker

是一个单点

单点系统大家知道的

是存在一个单点故障的

它没有failover的功能

第三个问题是整个系统

不利于功能的扩展

比如不同的任务

如果想采用不同的调度策略

在Hadoop1.0系统中

是很难做到的

那在最近很热门的一个

就是Hadoop2.0

改进的一个版本

业界称为YARN系统

YARN系统在1.0的基础上

进行一个最大的改造

是将资源任务调度

进行了分离

它有一个角色叫

ResourceManager

主要负责资源的调度

那任务的调度

是在APP Master

这个角色中完成的

它主要负责在

ResourceManager

分配的资源上

进行任务的调度

每一个运行的任务

都有一个对应的APP Master

YARN系统也存在几个问题

首先一个Resource Manager

目前仅支持memory的调度

不可能支持其他

维度的资源调度

第二点当一个资源用完后

Node Manager

就立即通知

Resource Manager

进行释放

在这种情况下APP Master

无法复用资源

整体的交互效率比较低下

第三个系统是伯克利大学

研发的Mesos系统

它也是一套分布式调度系统

它有一个主控节点叫

Mesos master

主要负责将资源分配给

不同的计算framework

而不同的运用则称为

计算Framework

各个不同的Framework

决定接收哪些

resource offer

以及每个task

在那些机器上执行

Mesos系统

也存在它的一些问题

第一点不同的计算

Framework只能被动的接收

Mesos master发来的

resource offer

不能精确的描述资源需求

比如某些节点

Framework不想使用

只能在接受offer之后

再拒绝掉

第二个问题是在

Mesos系统中

一次资源分配需要

两次通信的交互

首先Mesos master

将资源offer给

计算Framework

Framework经过调度之后

来accept这个资源offer

所以整体的交互效率也不高

第三个问题是Mesos系统

在做资源调度的时候

不支持资源抢占

在实际的生产环境中

有时候会有一些

非常紧急的任务

需要能够抢占已经

分配下去的资源

来抢先执行

这点在Mesos系统中

目前不支持

那我再给同学们介绍一下

阿里云伏羲这套

分布式调度做了哪些事情

它有什么样的特点

事实上阿里云的伏羲系统

也是在前人的基础上

进行了一系列的改造

首先一个与YARN

和Mesos系统类似

将资源的调度和任务调度

分离开

是一种两层架构

这样的架构的一个

最大的优势有以下几点

首先规模

两层架构

很分辨于进行横向扩展

资源管理和调度模块

只需要负责资源的整体分配

不需要关心具体的任务调度

可以很轻松的扩展

集群的节点规模

第二个优势是容错性

当某一个计算任务

运行失败之后

不会影响集群中

其他任务的执行

同时资源调度失败

也不会影响任务的执行

第三个优势是它的扩展性

不同的计算任务

可以采用不同的参数配置

和调度策略

同时也支持资源的抢占

最后一点优势

是它的调度效率

计算Framework决定

资源的生命周期

可以复用资源

提高资源的交互效率

以上几点就是阿里云的

分布式调度系统伏羲

所具备的一些优势

那现在这套系统

已经在阿里集团

进行了大范围的应用

目前能支持单个集群

5000个节点

也就是5000台机器

同时能并发运行

1万个的任务

能在30分钟完成100T

数据的sort

这个性能是Yahoo在

排序这个Benchmark上的

世界纪录的两倍

接下来我给同学们

介绍一下伏羲的系统架构

首先当整个集群部署好之后

集群中有这样几个角色

第一个Fuxi Master

以及多台Tubo

Fuxi Master是

集群的中控角色

它负责资源的管理和调度

Tubo是每台机器上

都有的一个agent（10：37）

它负责管理本台机器上的

用户进程

同时集群中还有一个角色

叫Package Manager

因为用户的可执行程序

以及一些配置需要事先

打成一个压缩包并上传到

Package Manager上

Package Manager专门负责

集群中包的分发

当集群部署完后

接着用户通过

Client端的工具

向Fuxi Master

提交计算任务

Fuxi Master接收到

任务之后首先通知

某一个Tubo

启动这个计算任务

所对应的APP Master

APP Master启动之后

它获知了自己的计算任务

包括数据分布在哪里

有多少的任务需要计算

等等信息

接着APP Master

会向Fuxi Master

提交资源申请

表明它需要多少计算资源

包括CPU memory

磁盘以及网络带宽

等维度信息

Fuxi Master

经过资源调度以后

将资源的分配结果

下发给APP Master

APP Master在这个

资源的基础之上

进行它的任务调度

来决定哪些机器上

运行哪些计算任务

并且将这个计算任务

发送给对应

机器上的Tubo进程使

Tubo接受到命令之后

就会从Package Manager

上面去下载

对应的可执行程序

并且解压开

然后启动用户的可执行程序

加载用户的配置

也就是图中的APP Worker

APP Worker做的事情

就是根据配置中的信息

读取文件存储系统中的数据

然后进行计算

并且将计算结果

发往下一个APP Worker

那这里我们将数据的切片

称之为Instance

或者叫计算实例

上面这张图就是完整的讲述了

用户如何使用

伏羲进行计算任务的

整个流程

大家可以看到

Fuxi Master与Tubo

这套结构

解决了我们分布式调度中的

第一个任务就是资源调度

每个计算任务的

APP Master以及一组

APP Worker组合起来

就解决了我们分布式调度的

第二个问题任务的调度

那么总结下来

同学们可以看到

飞天伏羲的架构里面

有这么几个特点

首先一个两层的架构设计

将整个分布式调度的问题

进行分解了

第二点Fuxi Master的

扩展性比较强

目前已经支撑了1万个

节点的计算集群

第三点支持多种计算框架

包括离线批处理

在线服务 实时计算

Streaming等多种计算形态

最后一个它的容错性

也比较好

任意角色的故障

不影响任务的执行

同时系统也支持

多个角色的同时的failover