1、线上的规模与压力:大数据计算的场景与需求正在快速增长。单集群早已突破万台规模,急需提供十万台规模的能力。但规模的增长将带来复杂度的极速上升,机器规模扩大一倍,资源请求并发度也会翻一番。在保持既有性能、稳定性、调度效果等核心能力不下降的前提下,可以通过对调度器持续性能优化来扩展集群规模(这也是伏羲资源调度 1.0 方向),但受限于单机的物理限制,这种优化总会存在天花板,因此需要从架构上优化来彻底规模和性能的可扩展性问题。
2、调度需求的多样性:场景的不同对资源调度的需求也不相同,比如,SQL 类型的作业通常体积小、运行时间短,对资源匹配的要求低,但对调度延时要求高,而机器学习的作业一般体积大、运行时间长,调度结果的好坏可能对运行时间产生直接影响,因此也能容忍通过较长的调度延时换取更优的调度结果。资源调度需求这种多样性,决定了单一调度器很难做到“面面俱到”,需要各个场景能定制各自的调度策略,并进行独立优化。
3、灰度发布与工程效率:资源调度系统是分布式系统中最复杂最重要的模块之一,需要有严苛的生产发布流程来保证其线上稳定运行。单一的调度器对开发人员要求高,出问题之后影响范围大,测试发布周期长,严重影响了调度策略迭代的效率,在快速改进各种场景调度效果的过程中,这些弊端逐渐显现,因此急需从架构上改进,让资源调度具备线上的灰度能力,从而大幅提升工作效率。
以上内容摘自《“伏羲”神算》电子书,点击https://developer.aliyun.com/topic/download?id=873 的灰度能力,从而大幅提升工程效率。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
MaxCompute(原ODPS)是一项面向分析的大数据计算服务,它以Serverless架构提供快速、全托管的在线数据仓库服务,消除传统数据平台在资源扩展性和弹性方面的限制,最小化用户运维投入,使您经济并高效的分析处理海量数据。