伏羲—阿里云分布式调度系统-阿里云开发者社区

开发者社区> 场景研读> 正文

伏羲—阿里云分布式调度系统

简介: 在12月12日的云栖社区在线培训上,“飞天”分布式系统核心开发人员陶阳宇分享了《伏羲-阿里云分布式调度系统》。他主要从伏羲系统架构、任务调度、资源调度、容错机制、规模挑战、安全与性能隔离方面介绍了伏羲分布式系统架构和设计理念。
+关注继续查看

今天,大数据已经从概念发展到在很多行业落地生根。广泛用在电商、金融、企业等行业,帮助行业分析数据、挖掘数据的价值。即使在传统的医疗、安全、交通等领域也越来越多的应用大数据的技术。数据、价值二者之间的联系是计算,计算是大数据中最核心的部分。大数据计算就是将原来一台台的服务器通过网络连接起来成为一个整体,对外提供体验一致的计算功能,即分布式计算。

点击查看回顾视频

伏羲系统架构

分布式调度系统需要解决两个问题:

任务调度:如何将海量数据分片,并在几千上万台机器上并行处理,最终汇聚成用户需要的结果?当并行任务中个别失败了如何处理?不同任务之间的数据如何传递?

资源调度:分布式计算天生就是面向多用户、多任务的,如何让多个用户能够共享集群资源?如何在多个任务之间调配资源以使得每个任务公平的得到资源?

业界几种调度系统的比较

Hadoop MR

由一个JobTracker和若干个TaskTracker组成,client可以提交多个任务执行。其特点和存在问题如下图所示:

72c3caff0beecd056da98f62308afa445d9800af

YARN

其特点和存在问题如下图所示:

39689fd4151f12f24b2089301407f4f76efbd88b

Mesos

该系统与YARN类似,其特点和存在问题如下图所示:

aa0bdde2926b192d559fe835fd22dc6ea400b56e

伏羲系统架构

当飞天集群部署完毕后,主控为Fuxi Master,Package Manager为代码包。Fuxi Master和Tubo之间彼此有心跳通信,当用户通过Fuxi Master向系统提交任务时,Fuxi Master会通过调度选择一台Tubo启动App Master。App Master启动后会联系Fuxi Master将其需求发送给Fuxi Master触发调度,Fuxi Master经过资源调度并将结果返回给App Master,App Master与先相关资源上的Tubo联系,启动App Worker。App Worker也会上报到App Master准备开始执行任务。App Master将分片后的任务发送给App Worker开始执行,每个分片称为Instance。App Master和App Worker一起称之为计算框架。伏羲系统是多任务系统,可以同时运行多个计算框架。

87e2959408ea449e09bfc1c3b875bb47fcc212b7

伏羲架构也是资源调度和任务调度分离,两层架构。其优势在于:

规模:易于横向扩展,资源管理和调度模块仅负责资源的整体分配,不负责具体任务调度,可以轻松扩展集群节点规模;

容错:某个任务运行失败不会影响其他任务的执行;同时资源调度失败也不影响任务调度;

扩展性:不同的任务可以采用不同的参数配置和调度策略,支持资源抢占;

效率:计算framework决定资源的生命周期,可以复用资源,提高资源交互效率。

App Master和App Worker解决了任务调度,Fuxi Master和Tubo解决了资源调度。总体来说,伏羲架构:两层架构设计,分解问题;FuxiMaster扩展性强;支持多种计算框架,包括离线批处理、在线服务、实时计算、Streaming;容错性好,任意角色的故障不影响任务执行,支持多角色failover。

任务调度

海量数据如何并行处理?PC时代的多线程、多进程解决不了问题的时候,MapReduce通过化整为零、数据切片、分解、聚合解决了上述问题。传统的MapReduce模型是Map任务紧接着Reduce任务,模式相对固定。但是实际过程中问题的处理涉及多个步骤,难以用一个MapReduce模型描述。伏羲将MapReduce扩展到更广阔的DAG有向无环图。伏羲任务调度过程如下图所示:

b812e50e7ae86567a409515c5addec30ef886b86

App Master 的主要任务如上图所示。App Worker的任务是:接收App Master发来的Instance,并执行用户计算逻辑;向App Master报告执行进度等运行状态;读取输入数据、将计算结果写到输出文件。

数据Locality

App Worker处理数据时,尽量从本地磁盘读取,输出也尽量写本地磁盘,避免远程读写。这样就对调度的要求,尽量让Instance(数据分片)数据最多的节点上的App Worker来处理该Instance。

数据Shuffle

Map和Reduce之间数据的传递取决于实际问题的逻辑,可能存在3种形式(1:1,1:N,M:N)。伏羲将数据shuffle过程封装成streamline lib,用户不用关心shuffle细节。

Instance PVC重试

在任务运行期间,App Master会监控Instance的运行进度,如果失败,会将Instance调度分配到其他App Worker上重新运行。造成Instance进程失败的原因有:进程重启、机器故障等。重跑是最直接最常见的容错方式,但是还存在数据读取失败,比如磁盘故障、文件丢失,伏羲采用PVC(pipe version controle)进行重试。

Backup instance

App Master还会监控Instance的运行速度,如果运行慢,容易造成长尾,App Master会在另外的App Worker上同时运行该Instance,取最先结束的那一份。判断依据是:运行时间超过其他Instance的平均运行时间;数据处理速度低于其他Instance平均值;已完成的Instance比例。

资源调度

资源调度解决的问题是如何将集群的CPU、Memory资源在多个任务之间调度?目标是:集群资源利用率最大化;每个任务的资源等待时间最小化;能分组控制资源配额;能支持临时紧急任务。其操作是当有空闲资源时,从等待队列中选取一个任务进行调度。

伏羲的资源调度方法如下图所示:

983e1899c429b5d9ebe32d2caadef93b6282ad69

优先级和抢占策略

每个job在提交时会带一个priority值,一个整数值,越小优先级越高(可以理解为排队在前面)。相同优先级按提交时间,先提交的优先级高。FuxiMaster在调度时,资源优先分配给高优先级的job,剩余的资源继续分配给次高优先级job。如果临时有高优先级的紧急任务加入,FuxiMaster会从当前正在运行的任务中,从最低优先级任务开始强制收回资源,以分配给紧急任务,此过程称为“抢占”。抢占递归进行,直到被抢任务优先级不高于紧急任务(换句话,不能抢比自己优先级高的任务)。

公平调度策略

当有资源时,Fuxi Master依次轮询的将部分资源分配给各个job,并按优先级分组,同一优先级组内平均分配,有剩余资源再去下一优先级组分配。

配额策略

多个任务组成一个group,通常按不同业务区分。集群管理员设定每个group资源上限,称为Quota。每个group的job所分配的资源总和不会超过该group的Quota。某个group没用完的Quota可以共享给其他group(按Quota比例)。

容错机制

在分布式集群中,故障是常态,所以分布式调度中需要容错机制。好的容错机制要求:正在运行的任务不受影响,对用户透明,自动故障恢复,高可用。

任务调度failover

App Master进程重启后如何进行恢复?App Master具有Snapshot机制,将Instance的运行进度保存下来,当App Master重启后加载snapshot后继续运行instance。App Master进程failover,当App Master重启后,从App Worker汇报的状态中重建出之前的调度结果,继续运行Instance。

资源调度failover

Fuxi Master进程重启后恢复状态需要两种信息来源:Hard State,包括application的配置信息,来自snapshot;Soft State,来自各个Tubo和App Master的新消息中恢复,包括机器列表、每个App Master的资源请求、资源调度结果等。

81fcd4892e663bc8c0969d2c7541358bb47bf566

上图是Fuxi Master重启恢复的示意图。Fuxi Master重启后会通知Tubo,上报在该Tubo上分配的情况。

规模挑战

分布式系统设计主要目标之一就是横向扩展,也叫水平扩展。

多线程异步

b46e36b7836b3fc038cdb0f1612bb1ccfebd9343

以通信模块为例,使用线程池高效处理海量的通信消息,不同的节点之间互不阻塞,独立”泳道”解决队头阻塞(HoL)问题。比如,App Master除了与Fuxi Master有通信外,还与大量Tubo有通信,通常采用线程池处理进来的RPC消息。但是,如果App Master将Fuxi Master与Tubo的消息混在一个队列中,那么Fuxi Master的消息会被大量的Tubo消息阻塞。实际上,Fuxi Master的消息更为重要些。因此,好的做法事为Fuxi Master准备一个单独的队列防止阻塞。

增量资源调度

8cb9b0066976bb251932dc81d6a564533f840816

Fuxi采用增量消息和资源调度。比如通常的做法,App Master申请1000个单位,Fuxi Master只有200个空闲资源,App Master接着申请剩余的800,此时Fuxi Master没有空闲资源。然后接着申请,这种协议消息比较繁琐,App Master需要多次申请才能拿到需要的资源。而在伏羲里,App Master只申请一次,Fuxi Master一旦有资源就分配给App Master,效率比较高。

安全与性能隔离

伏羲系统中定义了可信区域边界,并且提供了全链路的访问控制,比如:Client端不可信区域访问伏羲系统,伏羲系统内部RPC通信,系统访问外部存储等资源。伏羲安全访问验证精细到每个RPC,在Tubo上运行代码时,伏羲提供进程级别沙箱(Sandbox)隔离。系统设计时要求节点上多个进程间性能隔离,不能互相干扰。

总结

伏羲分布式调度资源任务两层架构,支持超大规模,水平扩展,提供优先级、抢占、Quota等灵活的资源调度功能。DAG任务调度,高效容错和长尾处理,任务之间有效隔离,提供全链路安全ACL。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
调度系统设计精要
本文会介绍调度系统的常见场景以及设计过程中的一些关键问题,调度器的设计最终都会归结到一个问题上 — 如何对资源高效的分配和调度以达到我们的目的,可能包括对资源的合理利用、最小化成本、快速匹配供给和需求。
236 0
独家下载 | “伏羲”神算!阿里巴巴经济体核心调度系统揭秘
阿里巴巴 9 位技术专家为你深度解析阿里巴巴经济体核心调度系统“伏羲”。伏羲(Fuxi)作为十年前最初创立飞天平台时的三大服务之一(分布式存储 Pangu,分布式计算 MaxCompute,分布式调度 Fuxi),十年来,在技术能力上持续演进。本书从面向大数据、云计算的调度挑战出发,介绍伏羲调度系统及各子领域的关键技术进展,并以双11为典型场景进行最佳实践的介绍,为你呈现大数据分布式调度技术的深水区玩法。— 《“伏羲”神算》现在可以免费下载阅读啦,快来先睹为快吧。
33646 0
云服务器linux系统与windows怎么选择?一般那种系统好?
现在的电脑技术发展很快,特别是操作系统,用不了多久就会进行更新,很多人在windows云服务器和linux系统之间不知怎么选择。下面笔者就给大家介绍windows云服务器与linux系统哪种比较好,大家应该如何选择?
296 0
基于Kubernetes的瓜子云的任务调度系统
很大的挑战。 接下来我讲详细介绍一下瓜子云的任务调度系统搭建所遇到的问题和解决方案。 需求 瓜子最早的时候,任务调度用的是Crontab,后来由于数据仓库的复杂调度需求,我们引入了Airflow。Airflow支持DAG依赖,失败重试,历史状态记录,log收集等多种非常使用的功能。
2400 0
Kubernetes 调度系统之 Scheduling Framework
阿里云容器服务团队结合多年Kubernetes产品与客户支持经验,对Kube-scheduler进行了大量优化和扩展,逐步使其在不同场景下依然能稳定、高效地调度各种类型的复杂工作负载。 本文帮助大家更好地了解Kubernetes调度系统的强大能力和未来发展方向。
564 0
Function Compute构建高弹性大数据采集系统
解决问题: 1.利用服务器自建数据采集系统成本高,弹性不足。 2.利用服务器自建数据采集系统运维复杂,成本高。
73 0
调度系统设计精要
本文会介绍调度系统的常见场景以及设计过程中的一些关键问题,调度器的设计最终都会归结到一个问题上 — 如何对资源高效的分配和调度以达到我们的目的,可能包括对资源的合理利用、最小化成本、快速匹配供给和需求。
728 0
调度系统设计精要
本文会介绍调度系统的常见场景以及设计过程中的一些关键问题,调度器的设计最终都会归结到一个问题上 — 如何对资源高效的分配和调度以达到我们的目的,可能包括对资源的合理利用、最小化成本、快速匹配供给和需求。
113 0
阿里视频云曾福华:世界杯百T级CDN智能流量调度系统的实战分享
在刚刚落幕的重庆云栖上,阿里云高级技术专家仔晟为现场观众带来议题《百T级CDN智能流量调度系统的实战分享》,重点介绍了在世界杯直播业务场景之下,阿里云CDN的产品架构、技术方案与客户实践。
8835 0
Azkaban 任务调度系统(安装搭建)
无论是在业务开发还是在大数据开发中,脚本都是必不可少的存在,在初期我们会使用crontab来解决问题,那么当发现规模变大监控需求可视化需求的到来Crontab已经显然满足不了需求,抱着一颗解决大数据任务脚本和业务任务脚本难题的心态最终在oozie和Azkaban选择了使用Azkaban来作为公共任务调度系统,那么就随着笔者一同来学习Azkaban的基础搭建场景和基本使用吧.
1923 0
+关注
场景研读
技术学习永无止境
476
文章
8
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载