评价标准（摘要）
在过去的5年里，我在工业和学术研究领域开发了几个机器学习项目。这一评价标准是这一经验的结果。虽然强调了机器学习的工作流程，但这项调查对于需要批处理或工作调度的项目也很有用。
以下各节解释了每个评估部分的逻辑依据。如果您想查看有关这些标准的详细说明（和理由），请滚动到本文的最后一节。
| 评估部分 | 说明 |
| 易用性 | API设计有多么的易于使用。 |
| 开发实践 | 支持增量构建和本地执行。 |
| 调试 | 与现有的Python调试工具(如pdb)集成。 |
| 测试 | 支持集成测试和流水线（pipeline）测试。 |
| 部署 | 在一个生产规模的系统中执行工作流，最好是开源的(例如Kubernetes)。能够在生产中重用预处理训练代码，以消除训练服务偏差。 |
| 编程语言 | sql兼容性。支持其他流行的编程语言，如R或Julia。 |
| 可维护性 | 管道代码量（越少越好）和源代码组织。 还会考虑影响可维护性的特定工具的特性。 |
| Jupyter notebooks 支持 | 支持以交互方式开发流水线任务(即使用jupiter notebooks/lab)和以编程方式运行notebooks以生成可视化报告。 |
每个部分的评分标准为1-3:
| 等级 | 说明 |
| NA | 不支持或者有主要的限制 |
| 1 | 支持但有一定限制 |
| 2 | 良好 |
| 3 | 优秀 |
请记住，此评估标准非常具体，因为它是为评估机器学习工作流程而量身定制的。每个项目都优先考虑某些方面而不是其他方面，本调查的主要目标是提供工具的概述，以便您可以选择最适合您的用例的选项。
免责声明
我是Ploomber的作者，其中一个被评估的工具。我在2019年创办了Ploomber，因为没有一个可用的工具能满足我的需求。由于Ploomber从一开始就基于这一评价标准进行设计，所以它在大多数部分都表现得很好，除了那些功能仍在开发中的部分。
评估
(按字母顺序)
| 工具名字 | 易用性 | 开发体验 | 调试 | 测试 | 部署 | 编程语言 | 可维护性 | Jupyter notebooks 支持 |
| Airflow | 1 | 1 | NA | 1 | 2 | 2 | 2 | 1 |
| Dagster | 1 | 1 | NA | 3 | 2 | 1 | 1 | 1 |
| DVC (Data Pipelines) | 3 | 3 | NA | NA | NA | NA | 2 | 1 |
| Elyra | 3 | 1 | NA | NA | 1 | NA | 2 | 3 |
| Flyte | 2 | NA | NA | NA | 2 | 1 | 1 | NA |
| Kale | 3 | 1 | NA | NA | 2 | NA | NA | 2 |
| Kedro | 1 | 1 | 2 | 2 | 2 | NA | 1 | 1 |
| Kubeflow pipelines | 1 | NA | NA | NA | 2 | NA | 1 | NA |
| Luigi | 3 | 1 | NA | 1 | 2 | 2 | 1 | NA |
| Metaflow | 3 | 2 | 1 | 2 | 1 | 1 | 1 | NA |
| Ploomber | 3 | 3 | 3 | 3 | 1 | 2 | 3 | 3 |
| Prefect | 2 | 2 | 3 | NA | 1 | 1 | 3 | 1 |
| Tensorflow Extended (TFX) | 1 | 2 | NA | 1 | 3 | NA | NA | 1 |
如果满足...条件，使用【工具】
(按字母顺序)
| 工具名字 | 如果满足...条件，使用【工具】 |
| Airflow | 你已经安装有了一个Airflow，同时数据科学家也已经熟悉了它。否则，我建议你使用一个对开发者更友好的库，可该库可以导出到Airflow，以利用Airflow的优势：一个健壮且可扩展的调度器。 |
| Dagster | 你有足够的资源让工程团队来维护一个只能运行dagster工作流的dagster安装工具，数据科学家愿意花时间学习DSL，浏览文档以了解每个模块的API，并且愿意放弃使用Notebooks进行交互式开发。作为交换，你可以得到可以本地运行的工作流，可以像任何其他Python代码一样进行测试，以及用于通过日志监控执行和调试工作流的web界面，。或者，你可以将工作流部署到Airflow，但你会失去dagster原生执行引擎的功能。 |
| DVC (Data pipelines) | 您已经在使用DVC进行数据版本控制，并希望有一种简单的方法(尽管有限)在本地执行小型管道，而不需要部署到Kubernetes这样的生产系统。DVC数据管道与语言无关，因为任务是由shell命令指定的。然而，这种灵活性有一个折衷:由于DVC不知道您的脚本的本质，工作流说明(YAML文件)对于大型管道来说变得冗长。 |
| Elyra | 您希望利用现有的Kubernetes (Elyra需要Kubeflow)安装，并希望提供一种可视化开发工作流的方法，但是每个任务必须是一个Jupyter notebook。由于工作流是用Kubeflow执行的，所以您可以使用Kubeflow pipeline UI监视工作流。但是，它缺乏一些重要的特性，如调试工具、支持集成测试、设计API端点、支持SQL/R或调度。 |
| Flyte | 您有足够的资源专门组建一个工程师团队来维护Flyte (Kubernetes)的安装，您的数据科学家精通Python，愿意学习DSL，并放弃使用Jupyter Notebook。作为交换，你可以获得一个与云无关的、可扩展的工作流管理工具，这个工具已经在Lyft经过了实战测试。**重要提示:**文档仍然有限。 |
| Kale | 您希望利用现有的Kubernetes集群来部署基于notebook的传统管道。对于新的管道，我只推荐Kale用于小型项目，因为管道被限制为单个Jupyter notebook文件。 |
| Kedro | 您可以遵循特定的项目结构约定，拥有严格的基于Python函数的工作流(不直接支持脚本或notebooks)，数据科学家愿意花时间理解kedro的API，并可以放弃与Jupyter的交互开发。作为交换，您可以获得一个可以部署到多个生产服务的管道。 |
| Kubeflow pipelines | 您精通Kubernetes，并希望完全控制计算/存储资源。不需要使用Jupyter notebooks进行交互式开发，愿意花时间学习Python API。其主要缺点是不能本地执行或调试工作流。 |
| Luigi | 你已经安装了Luigi。请记住，Luigi是为数据工程工作流设计的，因此，它确实具有数据科学或机器学习的特定功能。不支持使用Jupyter notebooks进行交互式开发，也不支持以编程方式执行notebooks。 |
| Metaflow | 您使用AWS，并且有足够的资源来专门组建一个工程团队来维护Metaflow的安装工具，并且不介意以非交互式的方式开发流水线任务(不支持Jupyter notebooks)。我建议您详细阅读管理员指南，以确保它符合您的需求，因为有些部署基础设施工具仍然是封闭源代码的(例如DAG调度器)。作为交换，您将获得一个非常健壮的工具，该工具提供了功能强大的工作流开发工具和一个干净、设计良好的Python API。 |
| Ploomber | 您需要一个具有丰富开发经验(调试和测试工具)的简单API。支持所有具有Python连接器和R，支持的SQL后端(支持像Julia这样具有Jupyter内核的语言，但有很小的限制)，使用Jupyter以交互方式开发任务(notebooks、函数脚本)，并以编程方式执行它们。支持Airflow或Kubernetes(通过Argo)部署工作流程。注意:Airflow/Kubernetes的部署是稳定的，但功能有限。 |
| Prefect | 您有足够的资源来维护只能执行Prefect工作流的Prefect安装工具。Prefect在设计时考虑了数据流范式(更接近流处理而不是批处理)，因此，它缺少数据科学或机器学习工作流所需的几个特性：没有增量构建，不支持集成测试，没有交互式开发。**重要提示：**Prefect Server具有非标准许可证. |
| Tensforflow Extended (TFX) | 数据科学家精通Tensorflow，愿意学习新的DSL，可以放弃Numpy、Pandas或scikit-learn等其他库，主要是开发深度学习模型。作为交换，您可以获到一个可以使用Airflow或Beam部署的灵活框架，强大的监控功能，并可以轻松地将pipeline转换为API端点。 |
单独评估
Airflow
| 评估部分 | 分数 | 评价 |
| 易用性 | 1 | Airflow是出了名的难以学会。尽管有各种各样的任务类型可用，但在实践中，推荐的编写工作流的方法是专门使用Kubernetes operator以确保环境隔离。 |
| 开发实践 | 1 | 工作流可以使用本地执行程序在本地运行，但这需要完整的 Airflow 安装。 此外，一次性工作流执行并不简单，因为 Airflow 对工作流应该如何以及何时执行做出了强有力的假设。 不支持增量构建。 |
| 调试 | NA | 没有调试工具 |
| 测试 | 1 | Airflow 工作流是 Python 对象，您可以导入它们并检查其属性。 但是，以这种方式测试工作流似乎不是官方或推荐的做法。 |
| 部署 | 2 | 缩放和调度是 Airflow 的核心优势。 但是不支持将工作流公开为 API 端点。 |
| 编程语言 | 2 | 支持多种SQL后端 |
| 可维护性 | 2 | 由于每个任务都是一个Python对象，所以您可以在多个模块中组织大型项目，而不受任何限制。有些任务是由社区贡献的，质量各不相同。 |
| Jupyter notebooks 支持 | 1 | 有一个以编程方式执行notebooks的任务，但是不建议使用它，因为代码是在全局环境中执行的。 不支持交互式开发。 |
资料
Dagster
| 评估部分 | 分数 | 评价 |
| 易用性 | 1 | 工作流是用Python编写的。这个API有很多特性，但是很难理解和阅读。例如，很多功能都隐藏在“context”参数中。即使对于执行SQL查询这样看似简单的任务，也必须熟悉一些概念并输入大量代码。 |
| 开发实践 | 1 | 为在本地执行工作流并部署到分布式系统（例如 Airflow、Kubernetes）提供了极大的灵活性。 不支持增量构建。 |
| 调试 | NA | 没有调试工具。 |
| 测试 | 3 | 对测试的大力支持，使用 hooks 可以执行集成测试。可以使用测试框架导入和测试工作流。 |
| 部署 | 2 | Dagster 带有全功能的执行程序和调度程序。 但是，这意味着您必须维护只能执行 dagster 工作流的 dagster 安装。 没有关于将工作流公开为 API 的文档，但这似乎是可能的，因为工作流可以作为任何其他 Python 对象导入和使用。 |
| 编程语言 | 1 | 仅支持 postgres 和 snowflake. 不支持 R/Julia. |
| 可维护性 | 1 | 配置机制极其冗长，有几个可选包可以与其他系统集成，但它们都有不同的API。 |
| Jupyter notebooks 支持 | 1 | 支持以编程方式执行notebooks。 不支持交互式开发。 |
资料
DVC (Data pipelines)
| 评估部分 | 分数 | 评价 |
| 易用性 | 3 | 使用 YAML 文件 指定工作流，其中每个任务由要执行的命令指定，文件依赖项和输出文件。 |
| 开发实践 | 3 | 可以(完全)本地运行工作流，并提供增量构建。 |
| 调试 | NA | 没有调试工具。 |
| 测试 | NA | 不支持集成测试。不支持管道测试。 |
| 部署 | NA | 不支持导出到大规模系统。不支持将工作流公开为API端点 |
| 编程语言 | NA | 框架与语言无关，任务是使用命令指定的。但是，这意味着您必须为每个脚本提供一个命令行接口来传递参数。不直接支持SQL。 |
| 可维护性 | 2 | 工作流是用YAML指定的，这对于小项目来说很好，但是对于大项目来说不是很好。一旦项目增长，YAML文件变得冗余，因为你必须指定相同的值多次(即一个脚本' train.py '出现在' cmd '节和' deps '节)。对于几十个任务，这就变得冗长且容易出错。 |
| Jupyter notebooks 支持 | 1 | 任务是用一个命令指定的，这意味着您可以自由地使用notebooks作为流水线任务，以交互式地编辑它们，然后以编程方式运行它。但是，您必须手动指定用于以编程方式执行notebook的命令和参数，因为DVC不知道它的内容。 |
资料
Elyra
| 评估部分 | 分数 | 评价 |
| 易用性 | 3 | 管道可视化编辑器非常容易将一组notebooks转换为管道。 |
| 开发实践 | 1 | 管道可以在本地执行。 不支持增量构建。 |
| 调试 | NA | 没有调试工具。 |
| 测试 | NA | 不支持集成测试。不支持管道测试。| |
| 部署 | 1 | 通过 Kubeflow 管道在 Kubernetes 中运行工作流。 不支持调度工作流。 由于其独有的基于notebook的特性，没有简单的方法可以将工作流转换为 API 端点。 |
| 编程语言 | NA | 仅支持Python。 |
| 可维护性 | 2 | 可视化编辑器非常有助于工作流的编写，但是，有些人可能更喜欢对管道定义进行更多的控制。该定义是以JSON格式编写的，但不清楚是否建议手动编辑此类文件。它限制了任务必须是notebooks。 |
| Jupyter notebooks 支持 | 3 | Elyra是一个以notebook为中心的工具，其中每个任务都是一个notebook，因此，您可以交互式地开发任务。当您执行您的管道时，notebooks将以编程方式执行。 |
