专业网站建设市场,在线装修设计软件免费版,两个网站如何使用一个虚拟主机,wordpress 主题骨架2019年#xff0c;是阿里巴巴第11个双11。众所周知#xff0c;阿里的电商在线体系经过多年发展#xff0c;可以支持峰值超过每秒50几万笔交易。但鲜有人知的是#xff0c;海量的交易#xff0c;创造了海量的数据#xff0c;爆炸性的数据量激增#xff0c;给狂欢过后的大…
2019年是阿里巴巴第11个双11。众所周知阿里的电商在线体系经过多年发展可以支持峰值超过每秒50几万笔交易。但鲜有人知的是海量的交易创造了海量的数据爆炸性的数据量激增给狂欢过后的大数据处理带来了大难题。
今年双11阿里巴巴MaxCompute大数据云数仓服务单日数据吞吐量接近EB级别任务数达到千万级而我们所有重保高优先级任务却都做到了按时产出同时我们还通过在离线混部承载了交易系统的65%的峰值交易。这很大程度上得益于全新亮相的MaxCompute调度系统Fuxi2.0。分布式大数据处理最大的问题之一是如何在数万节点间有效交换传输海量的数据确保内存、磁盘、网络硬件的最高效使用但又不会因为硬件高负载而出现软硬件故障导致无效运行。另一个问题是数据在真正被计算处理前我们并不知道真实的数据分布情况导致静态生成的执行计划很糟糕我们需要动态根据实时输入、或中间生成的数据调整执行计划方能最优。而这正是本文要解决的双11大数据处理的问题之二。本文干货满满希望能对大家的大数据处理帮助一二。
伏羲Fuxi是十年前创立飞天平台时的三大服务之一分布式存储 Pangu分布式计算 MaxCompute内部代号ODPS分布式调度 Fuxi当时的设计初衷是为了解决大规模分布式资源的调度问题本质上是多目标的最优匹配问题。目前Fuxi 2.0是MaxCompute内置的调度系统。
过去十年来伏羲在技术能力上每年都有新的进展和突破2013年5K2015年Sortbenchmark世界冠军2017年超大规模离在/在离线混部能力2019年的 Yugong 发布并且论文被VLDB2019接受等。
随着 Fuxi 2.0 首次亮相2019双11今年飞天大数据平台在混部侧支持和基线需要重保的高优先级作业保障2个方面均顺利完成了目标。其中混部支持了双十一 60%在线交易洪峰的流量超大规模混部调度符合预期。在基线保障方面单日数据处理 970PB较去年增长超过60%。在千万级别的作业上不需要用户额外调优基本做到了无人工干预的系统自动化。
伏羲Fuxi是十年前创立飞天平台时的三大服务之一分布式存储 Pangu分布式计算 ODPS分布式调度 Fuxi当时的设计初衷是为了解决大规模分布式资源的调度问题本质上是多目标的最优匹配问题。
随着阿里经济体和阿里云业务需求尤其是双十一的不断丰富伏羲的内涵也不断扩大从单一的资源调度器对标开源系统的YARN扩展成大数据的核心调度服务覆盖数据调度Data Placement、资源调度Resouce Management、计算调度Application Manager、和本地微自治调度等多个领域并在每一个细分领域致力于打造超越业界主流的差异化能力。
新的挑战
随着业务和数据的持续高速增长MaxCompute 双十一的作业量和计算数据量每年的增速都保持在60%以上 。
2019双十一MaxCompute 日计算数据量规模已接近EB级作业量也到了千万量级在如此大规模和资源紧张的情况下要确保双十一稳定运行所有重要基线作业按时产出压力相当之大。 在双十一独特的大促场景下2019双11的挑战主要来自以下几个方面
超大规模计算场景下以及资源紧张的情况下如何进一步提升平台的整体性能来应对业务的持续高速增长。双十一会给MaxCompute带来全方面超压力的极端场景如几亿条的热点key、上千倍的数据膨胀等这对集群磁盘IO的稳定性、数据文件读写性能、长尾作业重跑等各方面都是挑战。近千万量级作业的规模下如何做到敏捷、可靠、高效的分布式作业调度执行。以及对高优先级作业如重要业务基线的资源保障手段。今年也是云上集群首次参与双十一并且开始支持混部。
如何应对挑战
为了应对上述挑战与往年相比除了常规的HBO等调整之外飞天大数据平台加速了过去1-2年中技术积累成果的上线尤其是 Fuxi 2.0 首次亮相双十一最终在单日任务量近千万、单日计算量近千PB的压力下保障了基线全部按时产出。
在平台性能优化方面对于挑战#1和#2StreamlineX Shuffle Service 根据实时数据特征自动智能化匹配高效的处理模式和算法挖掘硬件特性深度优化IO内存CPU等处理效率在减少资源使用的同时让全量SQL平均处理速度提升将近20%出错重试率下降至原来的几十分之一大大提了升MaxCompute 平台整体效能。在分布式作业调度执行方面对于挑战#3DAG 2.0 提供了更敏捷的调度执行能力,和全面去阻塞能力能为大规模的MR作业带来近50%的性能提升。同时DAG动态框架的升级也为分布式作业的调度执行带来了更灵活的动态能力能根据数据的特点进行作业执行过程中的动态调整。在资源保障方面为应对挑战#4Fuxi 对高优先级作业 主要是高优先级作业采取了更严格、更细粒度的资源保障措施如资源调度的交互式抢占功能和作业优先级保障管控等。目前线上最高优先级的作业基本能在90s内抢占到资源。其他如业务调优支持等如业务数据压测配合与作业调优等。
StreamlineX Shuffle Service
挑战
上面提到今年双十一数据量翻倍接近EB级作业量接近千万整体资源使用也比较紧张通过以往经验分析双十一影响最关键的模块就是Streamline (在其他数据处理引擎也被称为Shuffle或Exchange)各种极端场景层出不穷并发度超过5万以上的Task多达几亿条的热点Key单Worker数据膨胀上千倍等全方位覆盖的超压力数据场景都将极大影响Streamline模块的稳定运行从而对集群磁盘IO的稳定性数据文件读写性能机器资源竞抢性能长尾Worker PVCPipe Version Control提供了某些特定情况下作业失败重跑的机制重跑等各方面产生影响任何一个状况没有得到及时的自动化解决都有可能导致基线作业破线引发故障。
Streamline 与 Shuffle Service 概述
★ Streamline
在其他OLAP或MPP系统中也有类似组件被称为Shuffle或Exchange在MaxCompute SQL中该组件涉及的功能更加完善性能更优主要包含但不限于分布式运行的Task之间数据序列化压缩读写传输分组合并排序等操作。
SQL中一些耗时算子的分布式实现基本都需要用到这个模块比如joingroupbywindow等等因此它绝对是CPUmemoryIO等资源的消耗大户在大部分作业中运行时间占比整个sql运行时间30%以上一些大规模作业甚至可以达到60%以上这对于MaxCompute SQL日均近千万任务量日均处理数据接近EB级的服务来说性能每提升1个多百分点节省的机器资源都是以上千台计因此对该组件的持续重构优化一直是MaxCompute SQL团队性能提升指标的重中之重。今年双十一应用的SLX就是完全重写的高性能Streamline架构。
★ Shuffle Service
在MaxCompute SQL中它主要用于管理全集群所有作业Streamline数据的底层传输方式和物理分布。调度到不同机器上成千上万的Worker需要通过精准的数据传递才能协作完成整体的任务。在服务MaxCompute这样的数据大户时能否高效、稳定地完成每天10万台机器上千万量级worker间传输几百PB数据量的数据shuffle工作很大意义上决定了集群整体的性能和资源利用效率。
Shuffle Service放弃了以磁盘文件为基础的主流shuffle文件存储方式突破了机械硬盘上文件随机读的性能和稳定性短板基于shuffle数据动态调度的思想令shuffle流程成为了作业运行时实时优化的数据流向、排布和读取的动态决策。对准实时作业通过解构DAG上下游调度相比network shuffle性能相当资源消耗降低50%。
StreamlineX Shuffle Service关键技术
★ StreamlineX (SLX) 架构与优化设计
SLX逻辑功能架构如图所示主要包含了SQL runtime层面的数据处理逻辑重构优化包括优化数据处理模式算法性能提升内存分配管理优化挖掘硬件性能等各方面来提升计算性能而且底座结合了全新设计的负责数据传输的Fuxi ShuffleService服务来优化IO读写以及Worker容错性等方面让SLX在各种数据模式以及数据规模下都能够有很好的性能提升和高效稳定的运行。 SQL Runtime SLX主要包含Writer和Reader两部分下面简要介绍其中部分优化设计
框架结构合理划分: Runtime Streamline 和fuxi sdk 解耦Runtime 负责数据处理逻辑Fuxi SDK 负责底层数据流传输。代码可维护性功能可扩张性性能调优空间都显著增强。支持 GraySort 模式: Streamline Writer 端只分组不排序逻辑简单省去数据内存拷贝开销以及相关耗时操作Reader 端对全量数据排序。整体数据处理流程 Pipeline 更加高效性能显著提升。支持 Adaptive 模式: StreamlineReader支持不排序和排序模式切换来支持一些 AdaptiveOperator 的需求并且不会产生额外的 IO 开销回退代价小Adaptive 场景优化效果显著。CPU 计算效率优化: 对耗时计算模块重新设计 CPU 缓存优化的数据结构和算法通过减少 cache miss减少函数调用开销减少 cpu cache thrashing提升 cache 的有效利用率等手段来提升运算效率。IO 优化支持多种压缩算法和 Adaptive 压缩方式并重新设计 Shuffle 传输数据的存储格式有效减少传输的 IO 量。内存优化: 对于 Streamline Writer 和 Reader 内存分配更加合理会根据实际数据量来按需分配内存尽可能减少可能产生的 Dump 操作。
根据以往双十一的经验11月12日凌晨基线任务数据量大幅增加shuffle过程会受到巨大的挑战这通常也是造成当天基线延迟的主要原因下面列出了传统磁盘shuffle的主要问题
碎片读一个典型的2k*1k shuffle pipe在上游每个mapper处理256MB数据时一个mapper写给一个reducer的数据量平均为256KB而从HDD磁盘上一次读小于256KB这个级别的数据量是很不经济的高iops低throughput严重影响作业性能。稳定性由于HDD上严重的碎片读现象造成reduce input阶段较高的出错比率触发上游重跑生成shuffle数据更是让作业的执行时间成倍拉长。
Shuffle Service彻底解决了以上问题。经过此次双11的考验结果显示线上集群的压力瓶颈已经从之前的磁盘转移到CPU资源上。双十一当天基线作业执行顺畅集群整体运行持续保持稳定。 Shuffle Service 主要功能有
agent merge彻底解决传统磁盘shuffle模式中的碎片读问题灵活的异常处理机制相较于传统磁盘shuffle模式在应对坏境异常时更加稳定高效数据动态调度运行时为任务选择最合适的shuffle数据来源内存PreLaunch对准实时的支持性能与network shuffle相当的情况下资源消耗更少。
StreamlineX Shuffle Service双十一线上成果
为了应对上面挑战突破现有资源瓶颈一年多前MaxCompute SQL就启动性能持续极限优化项目其中最关键之一就是StreamlineX (SLX)项目它完全重构了现有的Streamline框架从合理设计高扩展性架构数据处理模式智能化匹配内存动态分配和性能优化Adaptive算法匹配CPU Cache访问友好结构设计基于 Fuxi Shuffle Service 服务优化数据读写IO和传输等各方面进行重构优化升级后的高性能框架。
至双十一前日均95%以上弹内SQL作业全部采用SLX90%以上的Shuffle流量来自SLX0故障0回退的完成了用户透明无感知的热升级在保证平稳上线的基础上SLX在性能和稳定性上超预期提升效果在双十一当天得到充分体现基于线上全量高优先级基线作业进行统计分析
在性能方面全量准实时SQL作业e2e运行速度提升15%全量离线作业的Streamline模块Throughput(GB/h)提升100%在IO读写稳定性方面基于FuxiShuffleService服务整体集群规模平均有效IO读写Size提升100%磁盘压力下降20%在作业长尾和容错上作业Worker发生PVC的概率下降到仅之前的几十分之一在资源优先级抢占方面ShuffleService保障高优先级作业shuffle 数据传输比低优先级作业降低25%
正是这些超预期优化效果MaxCompaute 双十一当天近千万作业涉及到近10万台服务器节省了近20%左右的算力而且针对各种极端场景也能智能化匹配最优处理模式做到完全掌控未来数据量不断增长的超大规模作业的稳定产出。
上面性能数据统计是基于全量高优先级作业的一个平均结果实际上SLX在很多大规模数据场景下效果更加显著比如在线下tpch和tpcds 10TB测试集资源非常紧张的场景下SQL e2e运行速度提升近一倍Shuffle模块提升达2倍。
★ StreamlineXShuffle Service 展望
高性能SLX框架经过今年双十一大考觉不是一个结束而是一个开始后续我们还会不断的完善功能打磨性能。比如持续引入高效的排序编码压缩等算法来Adaptive匹配各种数据Parttern根据不同数据规模结合ShuffleService智能选择高效数据读写和传输模式RangePartition优化内存精准控制热点模块深度挖掘硬件性能等各方向持续发力不断节省公司成本技术上保持大幅领先业界产品。
DAG 2.0
挑战
双十一大促场景下除了数据洪峰和超过日常作业的规模数据的分布与特点也与平常大不相同。这种特殊的场景对分布式作业的调度执行框架提出了多重挑战包括
处理双十一规模的数据单个作业规模超过数十万计算节点并有超过百亿的物理边连接。在这种规模的作业上要保证调度的敏捷性需要实现全调度链路overhead的降低以及无阻塞的调度。在基线时段集群异常繁忙各个机器的网络/磁盘/CPU/内存等等各个方面均会收到比往常更大的压力从而造成的大量的计算节点异常。而分布式调度计算框架在这个时候不仅需要能够及时监测到逻辑计算节点的异常进行最有效的重试还需要能够智能化的及时判断/隔离/预测可能出现问题的物理机器确保作业在大的集群压力下依然能够正确完成。面对与平常特点不同的数据许多平时的执行计划在双十一场景上可能都不再适用。这个时候调度执行框架需要有足够的智能性来选择合理的物理执行计划以及足够的动态性来根据实时数据特点对作业的方方面面做出及时的必要调整。这样才能避免大量的人工干预和临时人肉运维。
今年双十一适逢计算平台的核心调度执行框架全新架构升级- DAG 2.0正在全面推进上线DAG 2.0 很好的解决了上述几个挑战。
DAG 2.0 概述
现代分布式系统作业执行流程通常通过一个有向无环图(DAG)来描述。DAG调度引擎是分布式系统中唯一需要和几乎所有上下游(资源管理机器管理计算引擎, shuffle组件等等)交互的组件在分布式系统中起了重要的协调管理承上启下作用。作为计算平台各种上层计算引擎(MaxCompute, PAI等)的底座伏羲的DAG组件在过去十年支撑了上层业务每天数百万的分布式作业运行以及数百PB的数据处理。而在计算引擎本身能力不断增强作业种类多样化的背景下对DAG架构的动态性灵活性稳定性等多个方面都提出了更高的需求。在这个背景下伏羲团队启动了DAG 2.0架构升级。引入了一个在代码和功能层面均是全新的DAG引擎来更好的支持计算平台下个十年的发展。
这一全新的架构赋予了DAG更敏捷的调度执行能力并在分布式作业执行的动态性灵活性等方面带来了质的提升在与上层计算引擎紧密结合后能提供更准确的动态执行计划调整能力从而为支持各种大规模作业提供了更好的保障。例如在最简单的MR作业测试中DAG 2.0调度系统本身的敏捷度和整个处理流程中的全面去阻塞能力, 能为大规模的MR作业(10万并发)带来将近50%的性能提升。而在更接近线上SQL workload特点的中型1TB TPCDS作业中调度能力的提升能带来20%的e2e时间缩短。
DAG 2.0的架构设计中结合了过去10年支持集团内外各种计算任务的经验系统的对实时机器管理框架backup instance策略以及容错机制等方面进行了考虑和设计为支持线上多种多样的实际集群环境打下了重要基础。而另一挑战是2.0架构要在日常数百万分布式作业的体量上做到完全的上线在飞行中换引擎。从FY20财年初开始DAG2.0推进线上升级至今已经实现了在MaxCompute离线作业PAI平台Tensorflow CPU/GPU作业等每天数百万作业的完全覆盖。并经过项目组所有成员的共同努力在双十一当天交出了一份满意的答卷。
DAG 2.0 关键技术
能取得上述线上结果和DAG2.0众多的技术创新密不可分受篇幅限制这里主要选取和双11运行稳定性相关的两个方面做重点介绍。
★ 完善的错误处理能力
在分布式环境中由于机器数量巨大单机发生故障的概率非常高因此容错能力是调度系统的一个重要能力。为了更好的管理机器状态提前发现故障机器并进行主动归并DAG2通过完整的机器状态管理完善了机器错误的处理能力 如上图所示DAG2将机器分为多个状态。并根据一系列不同的指标来触发在不同状态之间的转换。对于不同状态的机器根据其健康程度进行主动规避计算任务迁移以及计算任务主动重跑等操作。将机器问题造成的作业运行时间拉长甚至作业失败的可能性降到最低。
另一方面在一个DAG上当下游读取数据失败时需要触发上游的重跑而在发生严重机器问题时多个任务的链式重跑会造成作业的长时间延迟对于基线作业的及时产出造成严重影响。DAG2.0上实现了一套基于血缘回溯的主动容错策略如下图这样的智能血缘回溯能够避免了层层试探层层重跑在集群压力较大时能够有效的节约运行时间避免资源浪费。 ★ 灵活的动态逻辑图执行策略Conditional join
分布式SQL中map join是一个比较常见的优化其实现原理对小表避免shuffle而是直接将其全量数据broadcast到每个处理大表的分布式计算节点上通过在内存中直接建立hash表完成join操作。
Map join优化能大量减少额外shuffle和排序开销并避免shuffle过程中可能出现的数据倾斜提升作业运行性能。但是其局限性也同样显著如果小表无法fit进单机内存那么在试图建立内存中的hash表时就会因为OOM而导致整个分布式作业的失败。所以虽然map join在正确使用时可以带来较大的性能提升但实际上优化器在产生map join的plan时需要偏保守导致错失了很多优化机会。而即便是如此依然没有办法完全避免map join OOM的问题。
基于DAG 2.0的动态逻辑图执行能力MaxCompute支持了开发的conditional join功能在对于join使用的算法无法被事先确定时允许优化器提供一个conditional DAG这样的DAG同时包括使用两种不同join的方式对应的不同执行计划支路。在实际执行时AM根据上游产出数据量动态选择一条支路执行(plan A or plan B)。这样子的动态逻辑图执行流程能够保证每次作业运行时都能根据实际作业数据特性选择最优的执行计划详见下图 出于对上线节奏把控的考虑双十一期间conditional join尚未覆盖高优先级作业。双十一期间我们也看到了重要基线上由于数据膨胀导致Mapjoin hint失效作业OOM需要临时调参以及因为Mapjoin未能被正确选中而导致作业未能选中优化执行计划而延迟完成的情况。在conditional join在重要基线上线后能够有效的避免这一情况让基线的产出更加流畅。
DAG 2.0 双十一线上成果
双十一作为阿里集团所有技术线的大考对于DAG2.0这一全新的组件同样是一个重要的考验也是DAG2线上升级的一个重要的里程碑
双11当天DAG2.0覆盖支持线上80%project。截至目前已完成全面上线日均支持几百万的离线作业执行。对于signature相同的基线作业DAG 2.0下instance 运行的overhead开销有1到2倍的降低。双11当天使用DAG 2.0的高优先级基线在双十一数据洪峰下没有任何人工干预的前提下未发生任何作业失败重跑。其中DAG2.0提供的实时机器管理backup instance策略等智能容错机制发挥了重要作用。支持开发环境中近百万量级作业在作业平均规模更大的前提下双11期间毫秒级(执行时间小于1s的作业)分布作业占比相比1.0提升20%。新框架上更高效的资源流转率也带来了资源利用率的明显提升等待在线资源超时而回退的在线作业比例降低了将近50%。DAG 2.0还支持了PAI引擎为双十一期间的搜索、推荐等业务的模型提前训练提供了有力的支持。双十一前PAI平台的所有TensorFlow CPU/GPU作业就已经全量迁移到DAG 2.0上其更有效的容错和资源使用的提升保证了各条业务线上模型的及时产出。
除了基础提升调度能力提升带来的性能红利外DAG2在动态图亮点功能上也完成了新的突破。包括增强Dynamic Parrellism LIMIT优化 Conditional Join等动态图功能完成上线或者正在上线推动中。
其中Conditional Join一方面保证了优化的执行计划能尽可能的被选用同时也保证了不会因为错误选择而带来OOM导致作业失败通过运行时数据统计来动态决定是否使用Mapjoin保证更加准确决策。
双十一前在集团内部做了灰度上线线上日均生效的conditionl节点10万其中应用Map join的节点占比超过了90%0 OOM发生。推广的过程中我们也收到了各个BU多个用户的真实反馈使用conditional join后因为能选择最优的执行计划多个场景上作业的运行时间都从几个小时降低到了30分钟以下。
★ DAG 2.0 展望
在双十一值班的过程中我们依然看到了大促场景下因为不同的数据分布特点数据的倾斜/膨胀对于分布式作业整体的完成时间影响非常大。而这些问题在DAG 2.0完备的动态图调度和运行能力上都能得到较好的解决相关功能正在排期上线中。
一个典型的例子是dynamic partition insert的场景在某个高优先级作业的场景上一张重要的业务表直接采用动态分区的方式导入数据导致表文件数过多后续基线频繁访问该表读取数据导致pangu master持续被打爆集群处于不可用状态。采用DAG2.0的Adaptive Shuffle功能之后线下验证作业运行时间由30小时降低到小于30分钟而产生的文件数相比于关闭reshuffle的方式降低了一个数量级在保障业务数据及时产出的前提下能极大缓解pangu master的压力。动态分区场景在弹内生产和公共云生产都有广阔的应用场景随着Adaptive Shuffle的上线dynamic insert将是第一个解决的比较彻底的数据倾斜场景。
此外DAG2.0也持续探索其他数据倾斜(data skew)的处理例如join skew等相信随着在2.0上更多优化功能的开发我们的执行引擎能做到更动态更智能化包括数据倾斜问题在内的一众线上痛点问题将可以得到更好的解决。今天最好的表现是明天最低的要求。我们相信明年的双十一在面对更大的数据处理量时计算平台的双十一保障能够更加的自动化通过分布式作业运行中的动态化调整在更少人工干预的前提下完成。
资源调度的交互式抢占
挑战
FuxiMaster是fuxi的资源调度器负责将计算资源分配给不同的计算任务。针对MaxComput超大规模计算场景下不同应用间多样的资源需求过去几年资源调度团队对的核心调度逻辑做了极致的性能优化调度延时控制在了10微秒级别集群资源的高效流转为MaxComputer历年双十一大促的稳定运行提供了强有力的保障。
而其中高先级基线作业的按时完成是双十一大促成功的重要标志也是资源保障中的重中之重。除了空闲资源的优先分配还需要对低优先级作业占用的资源进行腾挪在不影响集群整体利用率的前提下快速地将资源分配给高优先级基线作业。
交互式抢占概述
在高负载的集群若高优先级作业无法及时拿到资源传统的做法是通过抢占直接杀掉低优先级作业然后将资源分配给高优先级作业这种“暴力”抢占有资源快速腾挪的特点但抢占“杀人”也会导致用户作业中途被杀计算资源浪费的缺点。交互式抢占是指在明确资源从低优先级流向高优先级的前提下不立即杀掉低优先级作业而是通过协议让低优先级作业尽快在可接受的时间内目前是90s快速跑完既不浪费集群的计算资源同时也保障了高优先级作业的资源供给。
目前弹内线上针对高优先级SUschedule unit是资源管理的基本单位开启组内交互式抢占在大多情况下可以保障基线作业的资源供给。然而目前即使通过交互式抢占也还会存在一些作业无法及时获得资源的情况。例如高优先级交互式抢占每隔30s的触发处理高优先的SU数量受全局配置约束而该段时间还存在大量其他早已经提交进来的高优先级SU会导致该作业的SU被轮空。另外交互式抢占指令发出后需要对应instance结束后定向还这份资源而对应的instance的运行时间都非常长导致交互式无法及时拿回对应的资源。基于上述问题我们进一步优化了交互式抢占策略。交互式抢占关键技术针对前文提到的几个问题交互式抢占做了如下优化
通过性能优化放宽了高优先级每轮处理的SU限制个数交互式抢占超时后强制回收预留的低优先级资源对于优先启动的、占据大量资源、instance运行时间较长的低优先级作业需要强制回收资源。采用预留外的资源供给高优先级资源可以通过预留外的其他资源为交互式抢占的SU继续分配资源同时抵消对应的交互式抢占部分。
双十一线上成果
2019双十一期间面对远超以往的数据量所有的高优先级作业顺利按期产出资源调度方面顺利保障了基线资源供给其丝般顺滑程度让整个基线保障的过程几乎感受不到资源调度的存在。其中基线作业交互式抢占以及加速功能提供了有效的资源保障能力及时、有效的抢占到所需资源。下文给出了某个云上集群的资源供给情况。
★ 交互式抢占加速为基线作业快速提供可用资源
从下面几张图中可以看到在基线时间段(00:00 ~ 09:00), 基线作业超时拿不到资源发起交互式抢占revoke的频率明显高于其他时段 这意味着通过交互式抢占加速的手段基线作业可以顺利拿到所需资源。双十一期间的线上运行情况也证明了 在资源压力大的情况下高优先级基线作业明显通过了交互式抢占revoke获得了资源。 ★ 基线作业的SU拿资源时间比例分布
下边为主要几个集群SU拿资源的时间分布 (fuxi基本调度单元) 可以发现这几个集群90%分位拿资源的时间基本都在1分钟左右符合线上基线作业等待资源达到90s进行抢占配置预期。 原文链接 本文为阿里云原创内容未经允许不得转载。
