开源机器学习流水线（Pipeline）工具调研（MLOps）

吃果冻不吐果冻皮

已于 2022-03-30 22:50:43 修改

阅读量2.3k

点赞数 7

分类专栏：人工智能工程化（MLOps）文章标签：机器学习深度学习

于 2021-07-02 20:09:08 首次发布

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/scgaliguodong123_/article/details/118422486

版权

人工智能工程化（MLOps）专栏收录该内容

74 篇文章 53 订阅

订阅专栏

简介

实施数据科学项目不是一件简单的任务。至少，数据分析工作流程必须定期运行，以产生最新的结果。比如，一份上周数据的报告，或者由于概念发生变化而重新训练机器学习模型。在某些情况下，这类工作流的输出需要作为API公开，例如，一个经过训练的机器学习模型，通过点击REST端点来生成预测结果。

这就需要开发实践允许工作流(也称为pipeline)是可重现、可重复，并且可以很容易地部署。近年来，涌现了大量开源工作流管理工具。由于有太多的选择，团队很难选择最适合他们需求的工具，本文回顾了13种开源工作流管理工具。

评价标准（摘要）

在过去的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将以编程方式执行。

资料

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。

资料

Ploomber

评估部分	分数	评价
易用性	3	使用约定优于配置的方法，开始时，您只需在脚本/notebooks中包含两个特殊变量，Ploomber 将编排执行。为了获得更大的灵活性，您可以使用 YAML 指定您的pipeline，对于高级用例，请使用 Python API。
开发实践	3	工作流可以在单个进程或多个进程（并行）中本地执行。提供增量构建。
调试	3	与 `pdb` 和 `ipdb` 集成，您可以在任何任务上启动逐行调试会话，或者让管道运行并在任务崩溃时启动事后分析会话。
测试	3	在任务执行时使用`on_finish`钩子执行集成测试。管道是常规的Python对象，您可以导入它们并使用您选择的测试框架进行测试。
部署	1	支持将工作流导出到 Airflow 和 Argo (Kubernetes)，然而，此功能仅提供基本功能，但正在积极开发中。 Python批处理管道可以导出到内存中审阅观察结果，此对象可与任何 Web 框架一起使用，以创建 API 端点。
编程语言	2	支持任何带有 Python 连接的数据库。完整的 R 支持。对具有 Jupyter 内核的语言（例如 Julia）的支持有限。
可维护性	3	任务可以是脚本 (Python/R/SQL)、notebook或 Python 函数，您可以选择对您的项目更有用的任何内容。任务库（公开统一的 API）为常见任务（例如运行 SQL 脚本、转储数据库表）提供了功能。以减少样板代码。
Jupyter notebooks 支持	3	可以使用 Jupyter 以交互方式开发脚本和notebooks，然后以编程方式执行。

资料

Prefect

评估部分	分数	评价
易用性	2	基于函数的工作流是用干净的Python API编写的。任务库包含各种各样的任务，然而，只有少数与数据科学/机器学习项目相关。
开发实践	2	工作流可以在本地执行。不支持增量构建。
调试	3	您可以查看每个任务的输出和状态。还有使工作流调试变得简单的工具。
测试	NA	不支持集成测试。不支持pipeline测试。
部署	1	可以使用web界面部署(调度)工作流，但该界面只能执行Prefect工作流。不支持在其他系统中运行工作流。Prefect server有一个非标准开源许可证
编程语言	1	虽然支持一些SQL数据库(例如postgres， snowflake， sqlite)，但每个模块都有不同的API。不支持R和Julia。
可维护性	3	很棒的API和最小的样板代码。
Jupyter notebooks 支持	1	支持以编程方式执行notebooks。不支持以交互方式开发任务。

资料

Tensorflow Extended (TFX)

评估部分	分数	评价
易用性	1	该API非常复杂，它要求您在开始使用之前熟悉几个模块。
开发实践	2	可以在本地执行管道。不支持增量构建。
调试	NA	没有调试工具。
测试	1	技术上可行，因为您可以在本地运行工作流，但是，本地工作流必须显式启用交互模式，当在测试框架下运行时，这是否会引起麻烦还不清楚。不支持管道测试。
部署	3	共有三个部署选项：Airflow、Kubeflow Pipelines 和 Apache Beam，但是，示例仅针对 Google Cloud 提供。可以使用Tensorflow serving将工作流公开为API。
编程语言	NA	仅限Python。
可维护性	NA	TFX 是一个 Tensorflow 独有的框架，这意味着你不能带其他库，比如 numpy 或 pandas。还有大量样板代码使不熟悉 Tensorflow 生态系统的人难以理解管道。
Jupyter notebooks 支持	1	您可以交互式地开发pipelines，并在单个notebook中运行它们。不支持以编程方式执行notebooks。