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

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*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。
相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
Cloud Native 关系型数据库 OLAP
云原生数据仓库产品使用合集之阿里云云原生数据仓库AnalyticDB PostgreSQL版的重分布时间主要取决的是什么
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
16天前
|
存储 运维 监控
阿里云 SAE 助力修正商城 3 周内提升系统承载能力 20 倍,轻松应对春晚流量
在 2024 年春节前夕,修正电商事业部面临了前所未有的技术挑战,修正将参与春晚的全民健康好礼派发的活动,且在央视及各大平台进行广告投放,预计流量激增至 16 亿,系统需要承载保底 5 万 QPS,目标 10 万 QPS。修正技术团队迫切需要升级 APP 架构以应对即将到来的超高并发场景。这一挑战不仅是对技术的考验,更是对修正品牌实力的一次展示。为了应对这次巨大的技术挑战,修正技术团队选择与阿里云云原生团队合作,进行 APP 架构的升级。
21611 6
|
14天前
|
关系型数据库 分布式数据库 数据库
PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。
【7月更文挑战第3天】PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。通过数据分片和水平扩展支持微服务弹性,保证高可用性,且兼容MySQL协议,简化集成。示例展示了如何使用Spring Boot配置PolarDB,实现服务动态扩展。PolarDB缓解了微服务数据库挑战,加速了开发部署,为云原生应用奠定基础。
157 3
|
14天前
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
228 2
|
1月前
|
网络协议 安全 调度
阿里云公共DNS发布支持鸿蒙系统版的SDK
阿里云公共DNS发布支持鸿蒙系统版SDK,赋能鸿蒙开发者快速接入阿里云公共DNS服务。公共DNS将帮助接入的鸿蒙应用免除LocalDNS劫持困扰、解析加速、精准调度。
|
2月前
|
消息中间件 编解码 运维
阿里云 Serverless 异步任务处理系统在数据分析领域的应用
本文主要介绍异步任务处理系统中的数据分析,函数计算异步任务最佳实践-Kafka ETL,函数计算异步任务最佳实践-音视频处理等。
175472 349
|
2月前
|
自然语言处理 算法 OLAP
阿里云PAI大模型RAG对话系统最佳实践
本文为大模型RAG对话系统最佳实践,旨在指引AI开发人员如何有效地结合LLM大语言模型的推理能力和外部知识库检索增强技术,从而显著提升对话系统的性能,使其能更加灵活地返回用户查询的内容。适用于问答、摘要生成和其他依赖外部知识的自然语言处理任务。通过该实践,您可以掌握构建一个大模型RAG对话系统的完整开发链路。
|
19天前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用问题之在流水线中无法运行已在系统环境变量中配置的可执行命令,是什么导致的
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
2月前
|
人工智能 监控 开发者
阿里云PAI发布DeepRec Extension,打造稳定高效的分布式训练,并宣布开源!
阿里云人工智能平台PAI正式发布自研的 DeepRec Extension(即 DeepRec 扩展),旨在以更低成本,更高效率进行稀疏模型的分布式训练。