workflow了解_大数据组件workflow

参考：https://zhuanlan.zhihu.com/p/470740938
https://blog.csdn.net/maaici/article/details/88418157

AI算法产生到AI应用落地，是一个工程化的问题。为了将数据、算法、应用这三个 AI 领域的流程打通，工程师们选择了多种集成的手段，其中以 workflow 作为 AI 工程实践方法的思路上就出现了很多种 workflow 方案。

workflow：即工作流，就是对一个具体任务和任务之间业务规则的抽象，其将任务拆分为若干步骤，然后将这些步骤串起来，协同完成一个或多个任务。

AI workflow：（关于AI的工作流）本质上是通过编排（orchestration）的方式，将散落的函数，微服务，数据库等组件构成的业务逻辑持久化（duration function）的过程。AI workflow 既有高效编排、便捷开发、生态丰富的基础需求，也有直接对接业务请求的现实压力。

有博主说，workflow大致由三个部分组成：编排 orchestration + 执行 execution + 应用 application。除了做好orchestration 和 execution 两个基础之外，还需要能够满足不同的 application。（正因如此，workflow 被寄予了MLOps承载的厚望，光靠workflow本身最多只能解决 orchestration和部分execution的难题，application 则需要 MLOps 更多寄予领域模型的流程的优化）。

workflow 分类

现有的 workflow 有来自工程团队孵化的项目，如 Uber 的 Cadence、Lyft 的 Flyte、Netflix 的 Metaflow；也有以开源社区作为主导的 Apache Airflow、Argo 等方案；也有按领域细分出发的 MLflow 和 Ray workflow等，其分别代表了以实验记录，实验控制，细粒度控制作为主要卖点的方案；也有类似 Dagster 的专注编排的工具等。

1、Cadence

Cadence 项目早于 Lyft，主要用户栈建立在 Java 和 Go 语言上。
Cadence 项目提出初衷是基于复杂机器学习的业务流程，需要多种数据源与计算资源配合，Uber 希望 Cadence workflow 能够提供一种容错的持久化编排能力，去帮助自身的业务团队更好地处理数据驱动的服务构建，在 use case 中主要提及的场景有事件驱动的应用开发，批量作业排布，Big data & ML 等领域。
主要应用包括了欺诈检测，用户行为分析 等 Uber 的基础业务需求。

2、Flyte

Flyte 项目由 Lyft 孵化，与 Cadence 相比，它们想要解决的业务需求是类似的，但技术实现手段差异较大。
Flyte 是一个云原生的 AI workflow 项目，其调度逻辑和应用生态主要聚焦在云原生领域的应用。
通过 LF AI & Data Foundation 的孵化，Flyte 给我们的体验是通过其 Python 客户端书写细粒度的 workflow 逻辑，并且通过其 Go 后端高效地与 k8s 结合，调度并执行多种云原生应用。
其动态 DAG 的设计，本地调测的工具，对于希望以 k8s 作为底座的 AI + 大数据用户来说是比较有吸引力的。

3、Metaflow

Metaflow 是在服务 Netflix 的内部需求时创造出了这个项目，Metaflow 是想通过端到端的 AI + 大数据业务流程构建，直接帮用户做可以获得 "$“的事情（在文档中的 why Metaflow 直接用”$?"美元从哪里来的符号表示）。
Metaflow 做法比较直接，计算资源除了本地之外，直接和 AWS 打通，目前适用于愿意在 AWS 上 scale 它们 workflow 的项目。

4、MLflow

MLflow 严格意义上来说更像是一个 experiment tracking 的工作，不过经过用户的需求迭代，多次更新之后，在任务的编排上也具备了一定的能力。
由于其背后的 databricks 公司，以及活跃的用户社区，在ML实验领域的很多场景都是 the go-to 的选项。借着 autolog 的能力，顺理成章地帮助用户去做ML应用的包装，重复执行，甚至分发都是一个非常合理的场景。
若应用场景以实验为中心，MLflow 值得选择。若愿意选择 databricks 的相关服务，MLflow的使用体验会更好。

5、Apache Airflow

Workflow 领域有一个 meme，把 Apache airflow 的小风车底下改成 Apache fancy crontab。即，这个工具本质上就是一个高级版的 crontab，它能做的 crontab也可以做。虽然这个 meme 不一定完全正确，但是却反映除了 airflow 的普适性，它更像是云上的 crontab，把各种各样的云组件给连接起来。
它的对手包括文中的其他 workflow，但是仅限于一个应用领域，airflow 的编排颗粒使得他成为更通用的 workflow 编排工具。包括但是不限于 AI 和大数据领域，如果你的应用满足这样的特征，airflow会是一个好的选择。
通用需求多，选择airflow。

6、Argo

Argo 也是一个通用需求的 workflow 产品，和 Airflow 的区别在于 Argo 以容器作为编排的粒度。
其原本作为 k8s 的编排工作的身份出现，虽然 k8s 本身也具有编排功能，但是 k8s 本身还是声明式的工作模式，不是通过一步接一步的步骤来显式地操作 k8s，而是通过声明最终想要系统达到的状态去让 k8s 自己通过观察现在的状态自我驱动到目标状态，虽然非常有效但是会让人觉得没有控制感。
为了获得这种控制感，argo 又再造了 DAG 和 step 等概念，让控制欲比较强的程序员以 workflow 的形式操作 k8s。k8s 通用需求多，选择 argo.

7、Kubeflow pipeline

Kubeflow 本身其实更像是一个 AI 和大数据的生态体系，其中的编排部分是 kubeflow pipeline。
Kubeflow pipeline 提供 Python 和 RESTful 的接口，如果你的组件选型和 Kubeflow 的生态支持匹配度高，可尝试 kubeflow。

8、Dagster

UI 的质量，相比于列出的其它项目来说，完全达到了精致的标准，同时也是很特别的定位：为了生产力而创造的数据编排平台。Dagster 的目标是这个领域的商业化产品。
虽然是一个通用流程编排，dagster 对于数据的关注超过了其它项目，适合愿意在技术上尝鲜的团队。

9、Ray workflow

Ray 的 workflow 是一个比较新的项目，按照最新的规划放在了 Ray ML 的功能部分，和 Ray 结合十分紧密。虽然因为发展实践比较短，但归功于 Ray 的执行后端，是一个有共享内存共通的项目。
适合目前有一定 Ray 基础设施能力的团队去做一些前沿探索。

$\cdots \cdots$