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

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 在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。
相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
6天前
|
分布式计算 大数据 数据处理
技术评测:MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展,数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame(简称“MaxFrame”)是一个专为Python开发者设计的分布式计算框架,它不仅支持Python编程接口,还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评,探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现,并分析其在实际工作中的应用潜力。
28 2
|
15天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
22天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
54 4
|
1月前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
116 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
1月前
|
存储 NoSQL Java
Java调度任务如何使用分布式锁保证相同任务在一个周期里只执行一次?
【10月更文挑战第29天】Java调度任务如何使用分布式锁保证相同任务在一个周期里只执行一次?
95 1
|
27天前
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
40 0
|
1月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
2月前
|
存储 边缘计算 城市大脑
阿里云入选Gartner®分布式混合基础设施魔力象限
Gartner正式发布了《分布式混合基础设施魔力象限》(Magic Quadrant™ for Distributed Hybrid Infrastructure),阿里云在入选的中国厂商中于执行能力(纵轴)和愿景完整性(横轴)上均处在最高、最远的位置。
|
2月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
65 3
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?