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. 开发实践
数据科学/机器学习是高度迭代的，特别是在”原型“阶段。
我们首先粗略地了解我们必须进行什么样的分析，并随着我们对数据了解的加深而进一步完善。数据科学家花费大量时间修改代码的一小部分，然后重新运行分析，看看这些更改如何影响结果(例如添加一个新特性)。
增量构建是促进这个迭代过程的关键。当数据科学家在单个任务中修改几行代码时，不需要从端到端（从头到尾）重新执行管道，只需要执行被修改/受影响的任务。
部署的数据流水线（Pipeline）通常由生产系统(如：Airflow 调度器或 Kubernetes)管理，然而，能够在不需要任何额外基础设施的情况下进行本地开发对于促进快速开发至关重要。
3. 调试
众所周知，数据流水线（Pipeline）很难调试，因为错误可能来自不正确的代码或出乎意料的数据属性。能够启动一个交互式会话来调试我们的代码比查看一堆打印(或日志)语句更有效。
工作流管理器经常以特定的方式执行我们的代码(例如，multiprocessing、远程workers等)，这可能会导致标准的Python调试工具无法工作。我们评估是否有可能使用标准工具来调试工作流。
4. 测试
出乎意料的数据会以多种方式破坏流水线（Pipeline）。
最好的情况是，下游任务因为架构兼容性而崩溃，最坏的情况是:管道成功地运行，但产生不正确的结果(例如，一个性能很差的模型)。
为了防止这种隐蔽的bug，在任务执行之后测试制品变得越来越普遍，这被称为集成测试或数据测试。例如，在对数据集应用转换后，检查数据集中是否没有“NULL”值。我们评估对集成测试的支持。
第二个(经常被忽略的)特性是测试我们的工作流的能力。工作流是复杂的，因为它们包含了多个阶段的过程，这些过程之间存在依赖关系。能够在测试环境中运行和检查我们的工作流有助于在开发而不是生产期间检测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 文件作为执行工作流任务的结果，类似于有丰富的日志，以方便调试。
