目标问题
一方面，模拟目标系统，收集状态和反馈信息，判断收益，训练参数，生成Action等等行为可能涉及大量的任务和计算（为了选择最佳Action，可能要并发模拟众多可能的行为）。而这些行为本身可能也是千差万别的异构的任务，任务执行的时间也可能长短不一，执行过程有些可能要求同步，也有些可能更适合异步。
另一方面，整个DAG会在运行过程中，随时变化，系统需要根据前一环节的结果，调整下一个环节的行为和参数
Ray需要支持异构计算任务，动态计算链路，毫秒级别延迟和每秒调度百万级别任务的能力。
关于解决问题的思路，比较好玩
针对海量任务调度部分，不同的框架采用的方式不一样。
- flink这样的流式计算，将任务的调度转化为数据和指令的传输问题，换一种处理模型，可能就不需要发起大量的任务调度。统一的lamda架构下，任务的调度转化为数据和任务的传输？
- spark这样的批处理框架，可以通过任务树的拆分，批量统一调度等来分散调度负载。同时，continuous computation，通过建立long run 的任务，简化多个Epoc批次的任务调度流程，减少了需要调度的任务数量。同时，对端到端的计算延迟也有改进
毫秒级的延迟，任务调度本身的延迟，还是整体数据计算的延迟。分流式模型和批量模型，不同的思考思路
异构任务的支持，同批次异构任务的调度
任务拓扑图动态修改的能力，
Ray采用自下而上的策略，本地的调度器如果能满足该任务的调度就直接完成调度，在无法满足的情况下，才会提交到全局调度器。
将任务调度的执行逻辑和任务调度的信息状态进行分离处理，通过全局的GCS来存储状态，调度部分本身是作为一个无状态的服务，从而可以实现任务的迁移、扩展和共享
actor的重新赋能？变成了有状态的任务，通过暴露特定的方法接口供外部进行远程调用，调用记录也存储下来，这样系统也具备了actor状态重建的能力
整体上来看，数据往代码上移动，和现在大数据环境下，典型的代码往数据移动的思想正好相反
全局引入future对象，任务的执行不仅仅是lazy的，结果数据的处理更是异步的。当真正的需要读取数据的时候，才会block等待
修改少