阿里妈妈MaxCompute架构演进 - AON(MPI)集群

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 我们的集群规模不断地在加大, 与此同时我们却有着不同的感受,明显感觉到了各种任务的运行效率都在变低,其中AllOrNothing这类任务表现尤为明显

阿里云数加MaxCompute (原名:ODPS;https://www.aliyun.com/product/odps)

1.1   MPI集群

1.1.1   背景

我们的集群规模不断地在加大, 与此同时我们却有着不同的运行体验,明显感觉到了各种任务的运行效率都在变低

1.1.2   问题

问题1:

说明

Aon:all-or-nothing

FIFO/Fair:调度系统支持的两种调度策略

 

问题2:

 

问题3:

 

以上三个问题其实主要原因还是aon类任务跑不起来,但同时却占着大量的资源给不了别的任务用;

1.1.3   项目目标

最终的想法其实也很简单,就是拆出独立AON(但大家习惯了歪叫成MPI)集群,建设规模要达到6000台+,让且仅让所有的生产和实验aon任务(主要是PS和Xlib-mpi)跑在这个上面,尽量减少Aon任务攒资源引起的资源浪费。

1.1.4   项目收益

 

1.1.5   关键问题及解法

这个看似简单的结论却藏着一堆的问题要解

 

  • 关于混合机型;

像MaxCompute这种分布式计算平台的初衷是希望对用户屏蔽掉底层的物理细节的,在MR/Sql这种单instance对资源需求量(1Core + 2~3G)不是很大的情况下是基本成立的,但在这种大的PS任务情况下,发现这个问题很不好搞,AY87B上是混布的s10(128G + 32Core)和N41(192G + 64Core),而一个大的AON任务如PS的Server和Worker单个instance动不动就需要40~50G的资源需求量,你说是设置成50G好还是60G好,用户需要兼顾底层多种机型设置的同时还要考虑任务的执行效率,这给开发同学造成了很大的困扰,因此我们做的第一个决定就是统一aon集群机型,全部使用的是s10系列。

这里面实际还有另外一个问题:用s10还是N41?,考虑到两个我们选的s10,一是LR类迭代任务每轮迭代之后的网络通信量大,在同是万M网卡的情况下我们期望单机的Instance越少越好;二是当时的情况是s10机型为主,腾挪起来方便;

       这里关于机型选择的问题我觉得主要还是网络IO资源能不能纳入资源隔离的问题,如果能很好地控制网络的使用那么机型本身也就不是个多大的问题了。

  • 计算资源量储备

从单机来看,由于单个Instance的资源需求量大,很容易造成一个现象:“资源碎片”,经常出现20G以上的大“碎片”

从任务来看,独立集群的意义主要在于能让AON任务快速拿到资源,避免掉“攒”资源的过程,所以我们基本会按照需求的130%做资源准备

  • 资源利用率和调度策略

由于大碎片和超额的资源配置,集群利用率肯定就不会太高,因此如何把这部分资源用起来就是一个不得不解的问题;

这个时候主要靠的就是全局调度、超卖和抢占了

【全局调度】:顾名思义就是在多个集群间做资源负载均衡的,干的事主要就是当MR集群压力大时且AON集群有空间时将部分MR任务导到AON集群;

但这种做法和以前的做法貌似差别不大,最终也会是MR和AON混跑造成相互影响,唯一好处就是能保证AON是尽量最闲的,因此我们不得不再次升级策略:抢占

【抢占】

       抢占的前提是优先级,目前MaxCompute的任务优先级由project的优先级和job的优先级组成,跑在阿里妈妈AON集群上的任务有三大类:线上AON/实验AON/MR(含sql),他们的优先级通常是递减的。

抢占从粒度上分主要有两种:Quota组间的抢占和Quota内的抢占

       从力度上分也有两种:温和抢占和暴力抢占

       从我们要解决的问题来看,这几个策略都有涉及:

  • AON集群中的Aon资源组vs mr资源组:我们的quota是基于min保障和max共享的,一般max会是min的1倍以上,当AON集群中的mr任务所在的quota组资源用得比较超(大于min)时就需要使用组间抢占让aon组尽快把资源收回来;
  • AON资源组内:我们的aon任务分实验和生产,产生优先级是高于实验的,因此我们期望达到的效果是生产要跑时实验能把资源释放出来给生产用,因此组内也需要开抢占;
  • 暴力抢占:当aon需要抢占mr时,由于mr有自动的failover,因此可以直接把资源抢过来;
  • 温和抢占:从人性化和高效率的角度,这个才是正道,他的主要思想就是基于一个抢占协议和抢占消息,让任务的instance能够感知在X秒内将被强制终止,它可以根据自身情况选择跑完还是保存现场或者立即终止,这个事的难点是让mr/ps/xlib等计算框架都支持和能处理这些协议和消息。

这一整套要实施下来周期较长,在实施的过程中,我们发现了另外一个更有用的方案:超卖;

【超卖】

       抢占有一个不太好的地方就是基于plan资源的,而物理上机器的实际利用率可能不一定高,且由于需要单独划Quota也会挤占fuxi给AON任务的plan资源,因此最终我们决定用超卖的方式来斛利用率这个问题。

       超卖的基本思想:超卖的quota其min是一个很小值,不占用集群的plan额度,直接给集群设定一个超卖率(如20%),当某台机器的负载超过一定阈值的时候就将超卖的任务直接杀掉;

 

当然超卖也是可以和全局调度结合起来用,其实我觉得全局调度+超卖+温和抢占如果能全部支持的话这个场景下的调度策略的问题能解得基本差不多。

1.1.6   一点感想

建设aon集群实际就是在做物理资源的隔离,实际的建设进度不是很快,主要还是还重了(尤其是存储迁移最费事),我们也在想如果存储计算分离做得足够好后,较为轻便的虚拟集群是不是会更高效点,当然需要把相关的自动化配套建设起来才行,否则一大堆人肉工作也是很难受的。
最后感慨一下:系统调度是一个很难十分十美的跨学科工种;

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
载思
+关注
目录
打赏
0
0
0
0
78870
分享
相关文章
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
网易游戏 x Apache Doris:湖仓一体架构演进之路
网易游戏 Apache Doris 集群超 20 个 ,总节点数百个,已对接内部 200+ 项目,日均查询量超过 1500 万,总存储数据量 PB 级别。
网易游戏 x Apache Doris:湖仓一体架构演进之路
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
别光堆数据,架构才是大数据的灵魂!
别光堆数据,架构才是大数据的灵魂!
50 13
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
127 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
【赵渝强老师】达梦数据库MPP集群的架构
达梦数据库提供大规模并行处理(MPP)架构,以低成本实现高性能并行计算,满足海量数据存储和复杂查询需求。DM MPP采用完全对等无共享体系,消除主节点瓶颈,通过多节点并行执行提升性能。其执行流程包括主EP生成计划、分发任务、各EP并行处理及结果汇总返回。为确保高可用性,建议结合数据守护部署。
MaxCompute 近实时增全量处理一体化新架构和使用场景介绍
MaxCompute 近实时增全量处理一体化新架构和使用场景介绍
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
278 56
大数据时代的引擎:大数据架构随记
大数据架构通常分为四层:数据采集层、数据存储层、数据计算层和数据应用层。数据采集层负责从各种源采集、清洗和转换数据,常用技术包括Flume、Sqoop和Logstash+Filebeat。数据存储层管理数据的持久性和组织,常用技术有Hadoop HDFS、HBase和Elasticsearch。数据计算层处理大规模数据集,支持离线和在线计算,如Spark SQL、Flink等。数据应用层将结果可视化或提供给第三方应用,常用工具为Tableau、Zeppelin和Superset。
2009 8

相关产品

  • 云原生大数据计算服务 MaxCompute
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等