简介
施行数据迷信我的项目不是一件简略的工作。至多，数据分析工作流程必须定期运行，以产生最新的后果。比方，一份上周数据的报告，或者因为概念发生变化而从新训练机器学习模型。在某些状况下，这类工作流的输入须要作为 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。 |
材料
- 文档
- 源码
评估规范
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