【翻译】开源工作流工具调查(MLOps/AIOps)

吃果冻不吐果冻皮

简介

img

实施数据科学项目不是一件简单的任务。至少,数据分析工作流程必须定期运行,以产生最新的结果。比如,一份上周数据的报告,或者由于概念发生变化而重新训练机器学习模型。在某些情况下,这类工作流的输出需要作为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 支持
Airflow11NA12221
Dagster11NA32111
DVC (Data Pipelines)33NANANANA21
Elyra31NANA1NA23
Flyte2NANANA211NA
Kale31NANA2NANA2
Kedro11222NA11
Kubeflow pipelines1NANANA2NA1NA
Luigi31NA1221NA
Metaflow3212111NA
Ploomber33331233
Prefect223NA1131
Tensorflow Extended (TFX)12NA13NANA1

如果满足...条件,使用【工具】

(按字母顺序)

工具名字如果满足...条件,使用【工具】
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

评估部分分数评价
易用性1Airflow是出了名的难以学会。尽管有各种各样的任务类型可用,但在实践中,推荐的编写工作流的方法是专门使用Kubernetes operator以确保环境隔离。
开发实践1工作流可以使用本地执行程序在本地运行,但这需要完整的 Airflow 安装。 此外,一次性工作流执行并不简单,因为 Airflow 对工作流应该如何以及何时执行做出了强有力的假设。 不支持增量构建。
调试NA没有调试工具
测试1Airflow 工作流是 Python 对象,您可以导入它们并检查其属性。 但是,以这种方式测试工作流似乎不是官方或推荐的做法。
部署2缩放和调度是 Airflow 的核心优势。 但是不支持将工作流公开为 API 端点。
编程语言2支持多种SQL后端
可维护性2由于每个任务都是一个Python对象,所以您可以在多个模块中组织大型项目,而不受任何限制。有些任务是由社区贡献的,质量各不相同。
Jupyter notebooks 支持1有一个以编程方式执行notebooks的任务,但是不建议使用它,因为代码是在全局环境中执行的。 不支持交互式开发。

资料

Dagster

评估部分分数评价
易用性1工作流是用Python编写的。这个API有很多特性,但是很难理解和阅读。例如,很多功能都隐藏在“context”参数中。即使对于执行SQL查询这样看似简单的任务,也必须熟悉一些概念并输入大量代码
开发实践1为在本地执行工作流并部署到分布式系统(例如 Airflow、Kubernetes)提供了极大的灵活性。 不支持增量构建。
调试NA没有调试工具。
测试3对测试的大力支持,使用 hooks 可以执行集成测试。可以使用测试框架导入和测试工作流。
部署2Dagster 带有全功能的执行程序和调度程序。 但是,这意味着您必须维护只能执行 dagster 工作流的 dagster 安装。 没有关于将工作流公开为 API 的文档,但这似乎是可能的,因为工作流可以作为任何其他 Python 对象导入和使用。
编程语言1仅支持 postgressnowflake. 不支持 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 支持3Elyra是一个以notebook为中心的工具,其中每个任务都是一个notebook,因此,您可以交互式地开发任务。当您执行您的管道时,notebooks将以编程方式执行。

资料

Flyte

评估部分分数评价
易用性2API是干净的。任务是用带有少量装饰器的Python函数定义的。
开发实践NA工作流不能在本地执行,只能在Kubernetes中执行。不支持增量构建。
调试NA没有调试工具。
测试NA不支持集成测试。不支持管道测试。
部署2运行在Kubernetes上,支持调度。不清楚是否有可能将工作流公开为API端点
编程语言1支持一些与SQL兼容的系统,比如Hive和Presto。也支持Spark。不支持R/Julia,
可维护性1API是干净的,但文档仍在进行中,只有几个代码示例。
Jupyter notebooks 支持NA不支持交互式开发,也不支持以编程方式执行notebooks。

资料

Kale

评估部分分数评价
易用性3在Kale中部署管道只需要向Jupyter notebook单元添加标签。
开发实践1工作流可以本地执行。不支持增量构建。
调试NA没有调试工具。
测试NA不支持集成测试。不支持管道测试。
部署2批量处理的部署是无缝的,一旦您标注了您的笔记本,您就可以将工作流提交到Kubernetes集群。但是,不支持对API端点重新使用特性工程代码。
编程语言NA仅支持Python。
可维护性NA管道必须在单个笔记本文件中声明,这可能会导致很多麻烦,因为单元格副作用难以跟踪。 在解决版本控制冲突时,让多人编辑同一个文件会导致很多麻烦。 最后,您编写的代码不是执行的代码(它们使用 jinja 生成 Kubeflow 代码),这可能会导致调试问题。
Jupyter notebooks 支持2Kale是一个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没有调试工具。
TestingNA不支持集成测试。不支持管道测试。
部署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等测试框架一起使用。
部署1Metaflow 带有一个内置的 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工作流可以在单个进程或多个进程(并行)中本地执行。 提供增量构建。
调试3pdbipdb 集成,您可以在任何任务上启动逐行调试会话,或者让管道运行并在任务崩溃时启动事后分析会话。
测试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数据库(例如postgressnowflakesqlite),但每个模块都有不同的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。
可维护性NATFX 是一个 Tensorflow 独有的框架,这意味着你不能带其他库,比如 numpy 或 pandas。 还有大量样板代码使不熟悉 Tensorflow 生态系统的人难以理解管道。
Jupyter notebooks 支持1您可以交互式地开发pipelines,并在单个notebook中运行它们。不支持以编程方式执行notebooks。

资料

评价标准

1.易用性

对于任何软件工具来说,拥有一个允许用户快速入门的干净API都是必不可少的,而对于数据分析工具来说更是如此,因为用户的编程熟练程度各不相同。通常情况下,数据分析项目是实验性的/探索性的,并会经历初始的“原型设计”阶段。实践者往往远离“生产工具”,因为他们通常有一个陡峭的学习曲线,这会减慢进度,因此,许多数据科学家将整个数据pipelines写在一个notebook上。这是一个糟糕的实践,因为它创建了不可维护的软件。避免这种糟糕实践的唯一方法是提供添加最小开销的生产工具,使它们更吸引人,并且实践者从第一天开始就使用它。这是一种糟糕的做法,因为它会创建无法维护的软件。避免这种糟糕做法的唯一方法是提供增加最小开销的生产工具,使它们更具吸引力,从业者从一开始就使用它。

2. 开发实践

数据科学/机器学习是高度迭代的,特别是在”原型“阶段。我们首先粗略地了解我们必须进行什么样的分析,并随着我们对数据了解的加深而进一步完善。数据科学家花费大量时间修改代码的一小部分,然后重新运行分析,看看这些更改如何影响结果(例如添加一个新特性)。增量构建是促进这个迭代过程的关键。当数据科学家在单个任务中修改几行代码时,不需要从端到端(从头到尾)重新执行管道,只需要执行被修改/受影响的任务。

部署的数据管道通常由生产系统(如Airflow调程器或Kubernetes)管理,然而,能够在不需要任何额外基础设施的情况下进行本地开发对于促进快速开发至关重要。

3. 调试

众所周知,数据pipeline很难调试,因为错误可能来自不正确的代码或出乎意料的数据属性。能够启动一个交互式会话来调试我们的代码比查看一堆打印(或日志)语句更有效。工作流管理器经常以特定的方式执行我们的代码(例如,multiprocessing、远程workers等),这可能会导致标准的Python调试工具无法工作。我们评估是否有可能使用标准工具来调试工作流。

4. 测试

出乎意料的数据会以多种方式破坏管道。最好的情况是,下游任务因为架构兼容性而崩溃,最坏的情况是:管道成功地运行,但产生不正确的结果(例如,一个性能很差的模型)。为了防止这种隐蔽的bug,在任务执行之后测试加工品变得越来越普遍,这被称为集成测试或数据测试。例如,在对数据集应用转换后,检查数据集中是否没有“NULL”值。我们评估对集成测试的支持。

第二个(经常被忽略的)特性是测试我们的工作流的能力。工作流是复杂的,因为它们包含了多个阶段的过程,这些过程之间存在依赖关系。能够在测试环境中运行和检查我们的工作流有助于在开发而不是生产期间d检测bug。考虑使用诸如“pytest”之类的测试工具测试工作流的能力。

5. 部署

数据工作流的两种最常见的部署模式是批处理和在线。批处理部署的一个例子是它处理新的观察结果(通常是按计划进行的),进行预测并将其上传到数据库的工作流,。在线场景涉及到将管道作为API(例如REST/RPC)公开,该API接受输入数据并返回预测结果。当服务期间的预处理代码与训练期间的预处理代码不同时,部署期间就会发生一个常见错误(训练服务倾斜)。我们评估重用现有训练代码的能力,以消除这个问题。

我们还评估了部署方案,并支与其他开源部署工具(如Airflow、Kubernetes)集成。

6. 编程语言

虽然由于深度学习,使用非结构化数据训练ML模型变得越来越普遍,但表格数据和经典ML算法仍然是最常见的应用类型(见本报告第19页)。表格数据通常存储在SQL数据库中,这意味着我们的管道通常是SQL和Python的组合。我们还评估了将SQL脚本作为工作流程一部分的能力。最后,我们还评估了对其他流行的数据分析语言(如R和Julia)的支持

7. 可维护性

本节评估项目的可维护性。要考虑的第一个方面是声明管道所需的代码量(更少的代码更好)。第二个方面是代码组织,我们确定库是否施加了限制,从而限制了我们在单独的函数/模块中组织代码的能力。还评估了可能影响代码可维护性的特定工具的特性。

8. Jupyter notebooks 支持

在生产pipelines中使用notebooks总是会引发激烈的争论,但我认为问题来自于糟糕的开发实践,而不是notebooks本身。notebooks是探索工作的绝佳环境,这正是我们在学习数据时所需要的。能够交互式地开发工作流对生产力有很大的积极影响。

notebooks的第二个重要用途是作为输出格式。.ipynb格式支持在单个文件中嵌入表格和图表,无需任何额外的代码。这是一个巨大的时间节省,因为当我们可以用图表查看数据时,调试工作流会容易得多,而使用基于文本的日志查找错误严重限制了这个过程。拥有一个.ipynb文件作为执行工作流任务的结果,类似于有丰富的日志,以方便调试。

原文链接Open-source Workflow Management Tools: A Survey

阅读 700
9 声望
0 粉丝
0 条评论
9 声望
0 粉丝
文章目录
宣传栏