Ray 源码分析系列(14)—Ray Workflow

前言

ray core原生提供了task和actor两种开发模式，可以让开发者更灵活地根据自己业务所需的方式自由地构造完整的APP。通常而言，每个公司都会在app之上构建一套自己的编排引擎，比如argo\airflow等等。但这些通用workflow 调度框架最大的问题是只能基于container level做任务的分发，也就以为着不同pod之间只能以文件的方式进行交互。Ray Workflow其实就是在解决 container 内，跨app之间的通信问题，如果大规模地应用这种开发模式，毫无疑问将对解决大型软件之间的性能瓶颈问题有极大的帮助。

注意，当前Ray Workflow还是Alpha版本，还不确定啥时候转正。

使用方式

Ray Task

通常情况下，Ray 任务会立即执行（eagerly），意味着当调用任务函数并加上.remote(...)时，任务会马上被调度执行，并且返回的是对象引用（object references）。开发人员可以通过ray.get()或ray.wait()来获取任务执行的结果或者等待任务完成。这种方式适用于一般的分布式计算任务，能够快速地将任务分发到集群中执行，提高计算效率。

Ray Workflow

从 Ray 任务切换到 DAG API 相对简单，只需将所有对.remote(...)的调用替换为.bind(...)。.bind(...)调用会返回 DAG 节点（DAG nodes），这些节点可以像普通 Ray 任务一样进行组合，构建复杂的任务依赖关系图。例如，如果有两个任务task1和task2，在 Ray 任务中可能是task1.remote().task2.remote()，在 DAG API 中则变为task1.bind().task2.bind()

Ray Workflows 为了提供任务的持久性（durability），采用了惰性的 Ray DAG API。这种方式将任务有向无环图（DAG）的定义和执行分离开来。在使用 DAG API 时，任务的定义阶段只是构建了计算图，并不会立即执行任务。

与 Ray 任务不同的是，不允许直接对 DAG 节点调用ray.get()或r