![](https://csdnimg.cn/release/download_crawler_static/88245954/bga.jpg)
务,任务执⾏的时间也可能长短不⼀,执⾏过程有些可能要求同步,也有些可能更适合异步。
另⼀⽅⾯,整个任务流程的DAG图也可能是动态变化的,系统往往可能需要根据前⼀个环节的结果,调整下⼀个环节的
⾏为参数或者流程。这种调整,可能是⽬标系统的需要(⽐如在⾃动驾驶过程中遇到⾏⼈了,那么我们可能需要模拟计算刹
车的距离来判断该采取的⾏动是刹车还是拐弯,⽽平时可能不需要这个环节),也可能是增强学习特定训练算法的需要(⽐
如根据多个并⾏训练的模型的当前收益,调整模型超参数,替换模型等等)。
此外,由于所涉及到的⽬标系统可能是具体的,现实物理世界中的系统,所以对时效性也可能是有强要求的。举个例
⼦,⽐如你想要实现的系统是⽤来控制机器⼈⾏⾛,或者是⽤来打视频游戏的。那么整个闭环反馈流程就需要在特定的时间
限制内完成(⽐如毫秒级别)。
总结来说,就是增强学习的场景,对分布式计算框架的任务调度延迟,吞吐量和动态修改DAG图的能⼒都可能有很⾼的
要求。按照官⽅的设计⽬标,Ray需要⽀持异构计算任务,动态计算链路,毫秒级别延迟和每秒调度百万级别任务的能⼒。
Ray的⽬标问题,主要是在类似增强学习这样的场景中所遇到的⼯程问题。那么增强学习的场景和普通的机器学习,深
度学习的场景⼜有什么不同呢?简单来说,就是对整个处理链路流程的时效性和灵活性有更⾼的要求。
Ray框架优点:
海量任务调度能⼒
毫秒级别的延迟
异构任务的⽀持
任务拓扑图动态修改的能⼒
Ray没有采⽤中⼼任务调度的⽅案,⽽是采⽤了类似层级(hierarchy)调度的⽅案,除了⼀个全局的中⼼调度服务节点
(实际上这个中⼼调度节点也是可以⽔平拓展的),任务的调度也可以在具体的执⾏任务的⼯作节点上,由本地调度服务来
管理和执⾏。
与传统的层级调度⽅案,⾄上⽽下分配调度任务的⽅式不同的是,Ray采⽤了⾄下⽽上的调度策略。也就是说,任务调度的发
起,并不是先提交给全局的中⼼调度器统筹规划以后再分发给次级调度器的。⽽是由任务执⾏节点直接提交给本地的调度
器,本地的调度器如果能满⾜该任务的调度需求就直接完成调度请求,在⽆法满⾜的情况下,才会提交给全局调度器,由全
局调度器协调转发给有能⼒满⾜需求的另外⼀个节点上的本地调度器去调度执⾏。
架构设计⼀⽅⾯减少了跨节点的RPC开销,另⼀⽅⾯也能规避中⼼节点的瓶颈问题。当然缺点也不是没有,由于缺乏全
局的任务视图,⽆法进⾏全局规划,因此任务的拓扑逻辑结构也就未必是最优的了。
第⼗⼋章 后端架构选型及应⽤场景
7/53