Flyte
| 评估部分 | 分数 | 评价 |
| 易用性 | 2 | API是干净的。任务是用带有少量装饰器的Python函数定义的。 |
| 开发实践 | NA | 工作流不能在本地执行，只能在Kubernetes中执行。不支持增量构建。 |
| 调试 | NA | 没有调试工具。 |
| 测试 | NA | 不支持集成测试。不支持管道测试。 |
| 部署 | 2 | 运行在Kubernetes上，支持调度。不清楚是否有可能将工作流公开为API端点 |
| 编程语言 | 1 | 支持一些与SQL兼容的系统，比如Hive和Presto。也支持Spark。不支持R/Julia， |
| 可维护性 | 1 | API是干净的，但文档仍在进行中，只有几个代码示例。 |
| Jupyter notebooks 支持 | NA | 不支持交互式开发，也不支持以编程方式执行notebooks。 |
资料
Kale
| 评估部分 | 分数 | 评价 |
| 易用性 | 3 | 在Kale中部署管道只需要向Jupyter notebook单元添加标签。 |
| 开发实践 | 1 | 工作流可以本地执行。不支持增量构建。 |
| 调试 | NA | 没有调试工具。 |
| 测试 | NA | 不支持集成测试。不支持管道测试。 |
| 部署 | 2 | 批量处理的部署是无缝的，一旦您标注了您的笔记本，您就可以将工作流提交到Kubernetes集群。但是，不支持对API端点重新使用特性工程代码。 |
| 编程语言 | NA | 仅支持Python。 |
| 可维护性 | NA | 管道必须在单个笔记本文件中声明，这可能会导致很多麻烦，因为单元格副作用难以跟踪。 在解决版本控制冲突时，让多人编辑同一个文件会导致很多麻烦。 最后，您编写的代码不是执行的代码（它们使用 jinja 生成 Kubeflow 代码），这可能会导致调试问题。 |
| Jupyter notebooks 支持 | 2 | Kale是一个notebook优先的框架。您可以交互式地开发管道，而notebook本身也成为管道，但是，它在执行之前已经经历了一些预处理步骤。 |
资料
Kedro
| 评估部分 | 分数 | 评价 |
| 易用性 | 1 | 管道使用Python API定义，其中每个任务都是一个函数。虽然工作流API是干净的，但一些额外的模块具有复杂的API。此外，它是非常固执的，并期望您的项目遵循一个特定的文件夹布局，其中包括几个特定kedro的配置文件。 |
| 开发实践 | 1 | 工作流可以本地执行。不支持增量构建。 |
| 调试 | 2 | 支持调试节点和管道，尽管API看起来很复杂。 |
| 测试 | 2 | 支持在执行时测试任务（钩子），但是，与调试API类似，它看起来很复杂。 |
| 部署 | 2 | 支持部署到 Kubernetes（Argo 和 Kubeflow）、Prefect 和 AWS Batch。 目前尚不清楚是否可以将批处理管道转换为在线 API。 |
| 编程语言 | NA | 仅支持Python。 |
| 可维护性 | 1 | 期望您的项目具有特定的文件夹布局和配置文件。对于简单的项目来说，这是一种限制和过度的做法。 |
| Jupyter notebooks 支持 | 1 | 您可以启动Jupyter notebook并将定义的函数导出为kedro节点（任务），但由于导出的代码必须是一个函数，所以交互性受到限制。不支持以编程方式执行notebooks。 |
资料
Kubeflow pipelines
| 评估部分 | 分数 | 评价 |
| 易用性 | 1 | 工作流是用高度复杂的Python API编写的(这就是Kale存在的原因)。 |
| 开发实践 | NA | 无法在本地运行工作流，因为它是一个仅支持 Kubernetes 的框架。 也不支持增量构建。 |
| 调试 | NA | 没有调试工具。 |
| Testing | NA | 不支持集成测试。不支持管道测试。 |
| 部署 | 2 | 批处理部署很简单，因为 Kubeflow 与 Kubernetes 紧密集成。不清楚我们是否可以组合training和serving管道，以便为API端点重用特性工程代码。 |
| 编程语言 | NA | 仅限Python。 |
| 可维护性 | 1 | 代码很难阅读，而且包含太多的细节，请参见示例. 将相同的参数（项目、群集名称、区域）传递给所有任务。文档已过时。 |
| Jupyter notebooks 支持 | NA | 不支持交互式开发，也不支持以编程方式执行notebooks |
资料
Luigi
| 评估部分 | 分数 | 评论 |
| 易用性 | 3 | 要熟悉API才能开始使用，但是它没有其他API那么复杂。它有一套一致的概念：任务、目标和参数。任务（定义为Python类）的结构基本相同。 |
| 开发实践 | 1 | 可以在本地运行工作流。不支持增量构建（一旦执行任务，即使输入文件发生更改，再次运行它也没有效果）。 |
| 调试 | NA | 没有调试工具 |
| 测试 | 1 | 虽然不是专门为这个目的设计的，但是回调可以用于集成测试。不支持检查管道来测试其属性/定义。 |
| 部署 | 2 | 部署到中央监控工具非常简单。可伸缩性有限，没有内置的调度程序。只有批处理，不转换为API端点。 |
| 编程语言 | 2 | 支持一些SQL后端。 |
| 可维护性 | 1 | 要求将工作流定义为单个类对于协作和代码组织是有问题的。此外，由于任务不是无状态的(由于实例变量的存在)，它可能会导致隐藏的bug。 |
| Jupyter notebooks 支持 | NA | 不支持交互式开发。不支持以编程方式执行notebooks。 |
资料
Metaflow
| 评估部分 | 分数 | 评价 |
| 易用性 | 3 | 开发工作流是使用 Python 类定义的，decorator可用于多种任务，例如在执行任务之前重试任务或安装依赖项。 |
| 开发实践 | 2 | 工作流可以在本地执行，可以从失败的任务中恢复执行。不支持增量构建。 |
| 调试 | 1 | 如果工作流失败，您可以检查数据来确定是什么出错了。尽管如此，您只能在工作流失败后进行调试，不支持启动交互式的事后调试会话，并且您必须使用print语句进行调试，这并不理想。 |
| 测试 | 2 | 可以导入工作流以检查其定义和属性。 虽然没有明确提及，但似乎没有任何限制，您可以将此测试工具与 pytest等测试框架一起使用。 |
| 部署 | 1 | Metaflow 带有一个内置的 AWS 工具 来执行工作流，也可以调度使用 AWS Step Functions的工作流程。然而，Netflix使用了一个内部(封闭源代码)DAG调度器。没有部署到其他云的选项。工作流似乎可以作为api公开，但不清楚这是否是开源包的一部分。 |
| 编程语言 | 1 | 它支持R工作流，尽管它是一个使用Python库作为后端的独立工具，但你不能在同一个工作流中混合使用R和Python。不支持SQL。 |
| 可维护性 | 1 | 要求将工作流定义为单个类对于协作和代码组织是有问题的。此外，由于任务不是无状态的(由于实例变量的存在)，它可能会导致隐藏的bug。 |
| Jupyter notebooks 支持 | NA | 不支持交互式开发。不支持以编程方式执行notebooks。 |
