03 编排器、工作流、计算引擎

本节涵盖的公司和平台包括：

「编排器」是 AI/ML 开发生命周期中的控制引擎。它们组织从数据的提取、清洗和转换，到模型的训练和调优，再到最终模型的部署的所有事务。简而言之，它们是您的 AI/ML 工作流程的操纵者，也是您核心平台选择的竞争者之一。

术语「编排器」和「工作流」常常可以互换使用，尽管它们是类似的术语，但它们有微妙的区别。编排涉及各个步骤的命令和控制，而工作流则是这些步骤本身的系列。 值得注意的是，虽然「工作流」已经成为行业中的标准术语，但它有点误导人。从数据和模型的提取到部署的过程通常是一个带有许多分支步骤的 DAG 或决策树，并且它也是循环的，因为模型永远不会真正完成，而是通过重新经历整个过程来从新的训练数据中学习或进行调优和更新。

尽管如此，我们选择坚持使用标准术语，而不是发明新术语以避免混淆。我们还选择同时使用「编排」和「工作流」这两个词，以表示数据、代码和模型从开始到结束再回到起点的流动，以及控制该流动的模块。与传统的编码工作流不同，特别是持续集成/持续交付（CI/CD）工作流，后者只跟踪代码和自动化测试，AI/ML 工作流跟踪代码、测试、训练以及数据的移动和转换。

暂时回到蓝图上，您可能已经注意到 AIIA 将编排工作流分为两个主要关注领域：

  • 实验工作流
  • 数据工程工作流

实验工作流主要关注数据科学工作流程。在实验工作流中，数据科学家运行不同的实验，训练各种版本的模型，通常是并行进行，并将模型打包供生产环境使用。主要关注的是实验和模型构建。需要注意的是，这些工作流往往从数据清洗开始，经过数据提取和转换，一直到训练和部署阶段。

数据工程工作流更加关注数据工程师角色。数据工程师从各种数据源中摄取数据，进行清洗、转换、错误检查，并为数据科学家准备好可用的数据，而后者往往更关注更高层次的数据抽象。 当然，也有一些数据科学家也兼任数据工程师的角色，但在更先进的团队中，我们发现这些角色越来越专业化。数据工作流从数据提取一直运行到模型打包为生产环境使用。 最后，它们在部署阶段往往与实验工作流重叠，但它们会处理底层系统的部署工作，例如将模型与依赖项打包并安排到容器或服务引擎中。

我们发现，在受访团队中，他们通常面临的最大挑战是收集和清洗数据、进行质量保证和数据转换，而这正是数据工程师的责任所在。

orchestration-1

这也反映在团队的组成上。大多数受访公司雇佣的数据工程师比数据科学家更多。

orchestration-2

这也反映在团队在时间和金钱上投入最多的领域。

orchestration-3

为了进一步说明这两个角色之间的差异，可以考虑以下情况： 数据工程师可能更关注通过 RBAC 令牌连接到外部数据源，从 Snowflake 或 Amazon Redshift 或像 Amazon S3 这样的对象存储中提取数据，并将数据转换为数据科学家使用的工具（如 PyTorch 或 TensorFlow）可读取的格式。 另一方面，数据科学家主要关注更高层次的数据。数据科学家专注于理解数据的特征，例如根据出生日期计算年龄，或者发现图像中表示人或建筑轮廓的像素聚类。

这大致相当于传统编程中的系统管理员和程序员的二分法，尽管并不完全类似。 如今的数据工程师具备编程技能，可以自动化他们工作的许多方面，而许多数据科学家也乐于修改数据，使其适用于特征提取。

在实践中，这两种工作流风格之间通常存在很多重叠，许多平台同时涉及数据工程和实验，但将它们分开考虑是有帮助的，因为根据我们的经验，平台往往倾向于某一端，这会影响它们的接口、API、编程和可视化的表现形式。

有两种主要类型的编排：

  • 松散耦合
  • 紧密耦合

它们各自有优缺点。它们之间的基本区别很简单。松散耦合的编排引擎与底层执行无关。Airflow 就是一个松散耦合编排器的例子。它没有专用的计算和调度引擎。由于它是松散耦合的，它可以在各种计算引擎上执行任务，例如 Kubernetes 或 Spark，并且甚至可以执行其他分布式应用框架，如 Ray 或 Iguazio’s MLRun。

紧密耦合的编排系统与其底层计算引擎紧密绑定。Spark 就是一个完美的例子，因为它既是编排器又是分布式大数据处理引擎。Pachyderm 是另一个紧密耦合的编排器的例子，它与其底层执行引擎紧密耦合。

紧密耦合系统的缺点是它们的编排通常无法扩展到其他系统来执行任务，您必须部署底层计算引擎以使其正常工作。它们的编排局限于该系统。

松散耦合框架最大的优势在于它是通用的，可以在许多不同的引擎上执行任务。它还可以执行其他紧密耦合编排器的任务。这使它成为编排器中的编排器。松散耦合框架在执行的种类上往往更高级、更抽象。Airflow 就是一个松散耦合框架的例子。

松散耦合框架最大的缺点是，由于它更通用，如果没有插件，它无法充分利用所有独特的底层执行引擎能力。即使有插件，松散耦合的编排器也不是双向的。由于 Spark 具有底层数据的知识，它可以在任务之间共享数据。 它还具有关于内存分配、计算资源和不同调度选项的知识，而这些知识无法与 Airflow 共享。

松散耦合的编排器通常没有底层数据的概念，因此无法根据数据的变化触发流水线。另一方面，紧密耦合的系统（如 ClearML）可以根据数据的变化触发流水线，例如当新的遥测数据流入数据湖时，会触发一个仅使用改变的数据而不是整个数据集的作业。当需要利用底层系统的特殊功能时，松散耦合的系统总是处于劣势，尽管有一些例外，比如松散耦合的编排器 Prefect 可以将状态和数据依赖传递给底层系统。

选择使用哪种编排系统取决于组织的需求和规模。较小的团队可能只需要特定引擎的功能，因此他们将所有精力都集中在该引擎上以满足他们的需求。大型企业 AI/ML 团队由于具有不同类型的 AI/ML 能力需求，可能需要多个计算引擎，因此他们可能在机器学习流水线的不同阶段使用松散耦合框架和底层紧密耦合框架的组合。

既然我们已经探讨了编排，现在让我们转向底层计算引擎。任何 AI/ML 工作负载的基石都是其计算引擎。执行任务的中流砥柱。它们处理数据和代码，调度资源，如内存、磁盘空间、GPU、TPU 和 CPU，执行步骤，以及扩展和并行执行这些步骤。

我们将假设您对虚拟化、容器和并行化有一个一般性的理解，不会深入探讨这些系统的细节。但是，这些是值得思考的重要因素，因为我们发现目前绝大多数AI/ML平台依赖于以下三种计算引擎之一：

还有其他的计算引擎，但是着重关注这三个是值得的，因为它们涵盖了计算引擎可能具有的三个关键重点，即：

  • 通用计算引擎
  • 紧密耦合的编排和计算
  • 专注于机器学习应用的计算

虽然有一些理论上可以运行在「裸机」上的平台，但今天这主要意味着在云中运行在虚拟化容器或无服务器实例上，或者在数据中心运行在虚拟化或无服务器本地实例上。

在这三者中，Kubernetes 是最通用的计算引擎。它起源于 Google 自己的内部容器和编排能力，以及构建一个干净、通用的云「操作系统」的愿望。您可以在这里了解到它的历史和时间线。

Kubernetes 足够通用，可以封装和运行其他计算引擎，使其成为最通用的计算引擎。它与语言无关，允许团队运行任何类型的代码，包括 Bash、C/C++、Python、Rust 和 Java。 而且无论您是构建规模化的分布式 Web 应用程序还是机器学习训练流水线，它都可以运行任何类型的工作负载，因为它是如此通用。

Apache Spark 是第二个最知名的计算引擎，它有着悠久的历史。Spark 拥有经过实战验证的并行处理引擎，不依赖于像 Kubernetes 这样的第三方扩展平台，尽管 Spark 可以部署在 Kubernetes上。

值得注意的是，Spark 是在以 AlexNet 为开端的 AI/ML 深度学习革命之前创建的。它最初是为了处理大数据而设计的，基于 Google 的 MapReduce 论文，并作为 Hadoop 的一个更好的版本，Hadoop 是一种早期的磁盘密集型 MapReduce 类型系统。Spark 最大的创新是将大部分数据保存和处理在内存中，使其比严重依赖磁盘的 Hadoop 快上百倍。这证明了该系统的设计允许额外的用例，如 AI/ML，但并不总是完美适配。

Spark 最擅长处理结构化数据，例如数据库中的列式文本数据和半结构化数据，如 JSON 文件，尽管一直有努力使其更擅长处理非结构化数据，如视频、音频、图像和法律文件等非结构化文本，特别是通过 Delta Lake 项目，尽管这仍不是该平台的主要优势。

正如前面提到的，Spark 既是一个编排/流水线系统，又是一个计算引擎。它的编排是围绕 Scala 构建的，尽管通过端口和封装器，它也支持其他语言，如 Python。

Ray 是第三个计算框架，也是市场上相对较新的一个。它是在加州大学伯克利分校的 RISELab 设计的，主要作为强化学习（RL）的工具，以及具有特定机器学习重点的「Spark 替代品」，因为许多种类的机器学习工作不适用于 MapReduce 风格的范式。正如计算机科学教授 Michael Jordon 在2017年的一篇文章中所写的，在项目的早期阶段：

您需要灵活性。您需要整合的不仅仅是神经网络，还有规划、搜索和模拟等。这会产生各种复杂的任务依赖关系。简单地编写一个 MapReduce 类型的范式并不容易。 虽然您可以编写它，但当您有非常异构的工作负载和任务时，它不会执行得非常有效。它需要根据算法的性能进行适应，随着系统的学习，改变其流程和任务。
—— Michael Jordon

该平台后来经过调整，成为用于机器学习的更通用的计算框架，通过分布式数据加载和计算库 Dataset。尽管它最常用于强化学习和作为一个服务引擎。

Ray 可能是最新、最尖端的框架，但同时它也是最少通用且最专为机器学习工作负载设计的。需要注意的是，将 Ray 称为 Spark 的替代品并不完全正确。Ray 没有自己的底层计算引擎，也不足够底层以充当计算引擎。

它依赖于像 Kubernetes 这样的通用计算框架来运行。相反，它是一套用于构建分布式机器学习应用程序并提供服务的 Python 库。它专注于一些新的、尖端的 AI/ML 技术的关键依赖项，这些技术不适用于 MapReduce 的执行任务后等待的范式。 例如，强化学习通常有许多并行且较不线性的任务，在依赖树中共同工作，它们都需要在下一步继续之前完成。最后，它专门用于 Python 应用程序。

Ray 的另一个潜在优势是您可以在不需要部署 Kubernetes 的情况下部署单个节点。这使开发人员有机会编写代码、测试代码，然后将其扩展到 Kubernetes 集群，而无需稍后更改该代码，这降低了进入门槛。然而，根据文档，「Ray Serve 无法通过YAML文件以声明方式配置您的 M 应用程序。在 Ray Serve 中，您通过 Python 代码配置所有内容。」

正如前面提到的，我们可以以不同的方式思考这三种平台。Kubernetes 是最底层的平台。它是完全通用的，无论您是在其之上构建 Web 应用程序还是机器学习训练流水线，都没有关系，但正因为如此，这些应用程序的逻辑存在于更高的层次上，因此它本身并不足以创建一个机器学习编排器和流水线。Spark 是最持久且最成熟的紧密耦合编排器，但它并非为了 AI/ML 而设计。它具有内置的扩展和处理能力，在最佳情况下，它可以以极高的灵活性和强大的能力处理适合数据库的数据。 Ray 是最新的框架，专为 AI/ML 而设计，并考虑了该领域的最新技术，如强化学习（RL），但它本身并不是一个执行引擎，需要像 Kubernetes 这样的东西来运行。

了解这些引擎的能力有助于我们理解市场上许多平台的功能，因为它们位于这些平台的基础，并在堆栈的更高层上提供信息。 特别是当营销团队承诺的功能与每种平台的限制不容易匹配时，了解这些平台的限制和特殊性有助于我们看清各种产品的营销宣传。

Kubeflow 是最早也是最知名的编排/流水线系统之一。它作为一个开源项目在 Google 孵化，旨在与 Kubernetes 一起工作，而 Kubernetes 是云应用托管和扩展的事实标准。

Kubeflow 不是一个单独的项目，而是一组项目的集合。在这里提到 Kubeflow 时，我们只指 Kubeflow 流水线，它是该组中最受欢迎的项目，还有 notebooks。Kubeflow 流水线本身主要基于 Argo Workflows。

与 AIIA 蓝图相关，Kubeflow 最符合数据工程流程定义，这在项目的使用中得到了体现，截至2021年，大约73%的使用者是 ML 工程师，也就是数据工程师的另一种称呼。 Kubeflow 项目早于 MLOps 的概念，并在其设计中反映出更多的 DevOps 工作流程。它不包括数据驱动的流水线概念，即新的数据能够触发事件并启动流水线和自动化步骤。 它也缺乏纯语言无关性，主要关注 Python，对 R 的支持很基础。此外，它也缺乏商业支持，这意味着任何在生产环境中运行它的团队都需要完全依靠自己或通过社区来支持它。

一些商业产品已经构建了它们的技术栈以包括 Kubeflow，其中最著名的是 Google 的 Vertex AI，HPE 的 Greenlake 用于 MLOps 和 Arrikto 的 MLOps 平台。 由于 Kubeflow 流水线仍在积极开发中，而且通常很难提供支持，AIIA 目前不建议在生产环境中部署开源版本，除非您有一个强大的开源团队，有支持关键任务应用的开源项目的历史。

迄今为止，没有任何公司专门创建了一个专用的、受支持的、独立的商业版本的流水线。相反，流水线被包装到一个更大的工具结构中，例如 Arrikto 的数据快照文件系统，Google 的 AutoML 工具和 HPE 的 Greenlake 中用于 AI/M L的一套开源工具。对于不太擅长支持上游开源项目的团队，我们建议选择一个供应商，该供应商可以提供 Kubeflow 的支持，并具有快速修复错误、清晰的升级路径和对早期版本的回归修补的功能。

AirFlow 是另一个以数据工程为重点的流水线系统，允许用户使用 Python 构建 DAG 对象，以将工作流定义为代码。

正如前面提到的，它是松散耦合的。许多公司和组织使用 Airflow 来进行 AI/ML 流水线式的 CI/CD 编排，但它并非专为 AI 而构建。它完全以 Python 为中心，不允许轻松地插入其他语言。Airflow 最适合于大部分静态且变化缓慢的工作流。根据项目的自述文件，「它不适用于从一个任务到另一个任务的大量数据」，而且该项目不推荐用于「高容量、数据密集型任务」。此外，「最佳实践是委托给专门处理该类型工作的外部服务」。另外，「Airflow 不是一种流式解决方案，但通常用于处理实时数据，以批次方式从流中获取数据。」

Prefect 是专门开发的，用于解决 Airflow 的一些限制。

特别是，它是一个松散耦合的框架，考虑了底层的数据依赖关系和任务状态，而 Airflow 只考虑状态。它还增加了诸如任务版本控制之类的功能。它是一个 Python 库，旨在尽量减少额外的依赖项，如自己的调度程序。为了运行生产或可并行化的工作流，它依赖于 Dask 来进行分布式运行。

Dbt 是另一个以数据工程为重点的转换引擎，但它不是一个流水线引擎，只允许一系列协调的步骤。它专注于 SQL，并直接在数据仓库中运行这些查询，因此主要适用于 BI 和分析，但不是 AI/ML 工作负载的理想选择；它不支持非结构化工作负载，并且在寻找一般的编排器时，无论是松散耦合还是紧密耦合，都不应考虑它，但它可以非常有用地简化与 SQL 后端的工作。

Pachyderm 是一个紧密耦合的以数据工程为重点的编排器/流水线，它还将版本控制和谱系跟踪与包含数据去重的不可变数据湖相结合。 它允许用户使用任何语言串联复杂的转换步骤，因为它是基于容器的，因此与语言无关。它依赖于 Kubernetes 执行来进行扩展，而 Airflow 可以在有或无 Kubernetes 的情况下运行。

Pachyderm 在处理视频、音频、图像等非结构化数据和 JSON 等半结构化数据方面表现出色，但它也可以处理结构化数据，如 CSV 文件。虽然将所有数据保存在统一的数据湖中有优势，但对于严重依赖结构化数据的组织来说，使用数据库进行高事务处理的性能更高。Pachyderm 通过将流水线中的每个步骤视为原子工作单元，使用明确定义的 JSON 或 YAML 定义来自动构建 DAG，而无需用户预先构建。这些定义调用单独的容器来执行代码，以在机器学习生命周期中转换、训练和跟踪模型。

然而，虽然 Pachyderm 可以进行训练和部署模型，但它主要用于复杂的数据预处理和数据准备。对于具有复杂训练需求的团队，应转向像 Horovod 或 Determined AI（现在属于 HPE）这样的框架。在部署方面，通常会使用专用的部署框架，如 Algorithmia（现在属于 DataRobot）、Ubiops、ML-Run 或 Seldon。

正如前面提到的， Apache Spark 既是一个处理/计算引擎，也是一个数据工程流水线，尽管该工具也可以用于数据科学实验。我们在这里将重点放在其流水线功能上。

需要区分 Apache Spark 和多个供应商例如微软提供其作为服务的开源工具，以及 Databricks，它是该项目的主要企业支持者和 Spark 部署中最大的参与者。

Spark 还作为众多其他平台的基础，作为扩展和处理引擎，例如 DataRobot AI 云的某些部分。重要的是要理解，这些不同平台的功能高度依赖于它们在 Spark 之上构建的内容，包括各种 API 和 GUI 以及专有的覆盖应用。当您评估 Spark 作为一个流水线工具与支持 Spark 的公司时，您正在评估非常不同的事物。在许多方面，您应该将 Spark 视为一个计算引擎的选择，具有一些核心功能和限制，然后将构建在 Spark 之上的供应商平台作为单独的考虑因素进行评估。

让我们从 Databricks 的 Spark 版本开始。虽然 Databricks 的产品已经发展成为一个支持从机器学习到分析到可视化的产品套件，但 Spark 最初主要是作为 Hadoop 的替代品而设计的，重点是让数据工程师处理大数据。尽管 Databricks 在营销上将重点转向了人工智能，但在大部分历史上，Spark 的主要用途是处理大数据和分析工作负载。

由于它使用 Parquet 文件存储数据，这是一种列式数据库文件，因此在处理结构化和半结构化工作负载方面表现出色。虽然 Databricks 确实表示可以使用 Spark 作为任何类型数据的统一存储后端，采用其 Lakehouse 架构，但实际上，如果组织处理大型音频、视频或图像文件（例如高分辨率卫星图像），将非结构化数据存储在 Parquet 文件中在很大程度上是不可行的，即使考虑到该格式的压缩能力。

然而，Databricks 的 Spark 是最受欢迎的用于结构化和半结构化批处理工作负载的平台之一，并且有庞大的社区支持。此外，Databricks 的 Spark 及其周围的工具套件使其成为在高速结构化数据处理和结构化 AI/ML 工作负载（如流失预测、需求预测和异常检测）方面得到最好支持和资金支持的公司之一。

Scala 是支撑 Spark 的主要语言，尽管 Databricks 支持 Python，Python 已成为无可争议的机器学习通用语言，但关键 Python 库的支持需要由 Databricks 进行移植，这在很大程度上是 Scala 的封装。这可能会在错误调试中产生一些异常，并意味着团队可能需要等待特定的 Python 库或 Python 库的特定功能被移植，而不是简单地从其源代码库获取最新的 Python 库并与系统进行本地交互。尽管如此，Databricks 的 Python 仍库是他们最持续更新和广泛支持的部分之一。

现在让我们转向 DataRobot，这是为数不多旨在关注数据工程流水线和实验流水线的系统之一。

同样，我们不应将 DataRobot 视为单一产品，而是一套工具。其中一些工具使用不同的流水线后端。AI 云中专注于数据工程的工具称为 Data Mesh，它是通过收购 Paxata 而获得的。该工具具有强大的图形用户界面，在机器学习数据准备方面表现出色，但不是用于任何类型转换的通用数据工程流水线。它使用一组数据连接器连接到各种后端，例如 Amazon Redshift、Snowflake、MySQL、Oracle 和 SAP HANA。由于大多数数据连接器是针对数据库的，DataRobot 主要关注结构化和半结构化数据，并且他们出色的可视化工具支持列式数据，但它们也可以处理非结构化数据。

我们将在下一节关于实验流水线中讨论 DataRobot 平台的数据科学方面。尽管 DataRobot 作为一套完全集成的工具和紧密耦合的流水线系统存在，但团队在过去几年中努力解耦工具，以便更轻松地将外部工具纳入工作流程中。

Amazon Data Wrangler 是 SageMaker 工具集的一部分。与 DataRobot 类似，SageMaker 不是单一的统一工具，而是一套工具。

Data Wrangler 本身不是一个通用的流水线工具，而是一种进行数据转换的可视化方式。它完全专注于数据清洗、转换和准备，几乎只针对结构化数据转换。它包含各种连接器和超过300个预定义的转换，例如独热编码，并且允许用户设计自己的数据处理步骤。它不是一个通用的数据转换器，严格专注于为结构化数据创建尽可能多的预构建数据科学转换。

使用 SageMaker 最大的挑战是它被设计为一个完全独立的套件，与其他旨在与第三方工具轻松连接的工具不同，因此很难与第三方外部工具一起使用。然而，如果第三方提供商具有内置集成或提供API，则可以与 SageMaker 一起使用。

Azure Machine Learning 是大型云服务提供商中最注重开源的平台之一。它提供两套不同的专有流水线和一个开源方案。它的 Data Factory 流水线专注于数据摄取和转换，并为从 Oracle、Snowflake 和 MS SQL Server 等主要数据库到通过 FTP 和 NFS 以及对象存储的文件提供了许多预构建连接器。他们的 Data Factory 还包括预定义的转换步骤，可以简化数据摄取和转换的过程。他们的开源替代方案是 Airflow。

Dataiku 拥有一些最先进的可视化工具，用于在图形用户界面中构建数据流水线，并且能够作为许多类型数据的转换器，尽管主要关注的是结构化数据。它的图形用户界面提供了优秀的仪表板和可视化功能，以及针对列式数据和文本的高级标记功能。它提供了一系列插件来处理非结构化数据，但它们大多数要么是第二级支持，要么是不受支持，这意味着它们的使用存在组织自身的风险。Dataiku 在其知识库中提供了一些非结构化数据用于深度学习的示例，但它们大多是预定义的解决方案，例如使用预训练模型进行目标检测。

Dataiku 在后台使用多种流水线的组合来实现其目标。在底层，它可以使用自己的流水线引擎、Hadoop/Spark 或 Kubernetes/Docker，并且可以直接在 Oracle 或 Snowflake 等 SQL 数据库中运行计算。该平台提供了大量的外部数据连接器，从广泛支持的平台（如 Amazon Redshift）到较少见的平台（如直接从 Twitter 获取数据）。

最后值得一提的数据工程流水线是 Dagger，来自 Docker 的前创始人。它具有一些新颖的特点，最值得注意的是可移植容器流水线的概念。

与 Pachyderm 类似，它使用模板化来定义流水线中的步骤，从而使其与编程语言无关。它使用 Google 的 CUE 配置语言框架而不是 YAML 或 JSON。Dagger 不包含任何类型的数据存储或数据驱动流水线的概念。最后，Dagger 最近才推出，目前只适合早期采用者考虑使用。

在 AI/ML 平台中，迄今为止最大的设计模式是专注于数据科学家的实验流水线。这些流水线通常是有向无环图（DAGs），基本上是一系列步骤或任务的概念表示，代表了数据流水线的数学抽象。实验流水线通常隐藏了实际的 DAG（由用户创建），并包含一个众所周知的接口，如 Jupyter Notebooks，作为与系统交互的主要方式。它们通常允许通过 Python 创建步骤，Python 是大多数 AI/ML 任务的默认语言。相比之下，以数据工程为重点的流水线通常要求直接编写 DAG。

几乎每个 AI/ML 平台都包含某种实验流水线的概念，这往往会模糊工程流水线和实验流水线之间的界限。例如，尽管 Kubeflow 主要由数据工程师使用，但它也支持 Jupyter Notebooks，Pachyderm 和 Arrikto 也是如此。然而，我们通过询问平台的主要用户在哪方面花费时间来维持 AIIA 的区分。

如果主要用户在创建容器、在 YAML 或 JSON 中编写流水线步骤以及创建 DAGs，那么他们很可能是数据工程师，我们将流水线的目的归类为数据工程。 如果大多数用户在 notebooks 中工作，运行实验，调整超参数和构建模型，那么主要是数据科学家在使用该平台，我们将其归类为实验流水线。 只要意识到许多流水线可以在两个领域中发挥作用，您将不得不根据团队的技能和构成做出选择。

顺便提一下，在本报告讨论的许多平台中，虽然它们的营销中使用了「端到端」的短语，但 AIIA 建议组织采用更全面的定义，将数据工程师和数据科学家的工作作为一个整体，并接受可能需要一系列工具来同时满足两个群体的需求。 因此，组织应该根据这些要求评估任何平台的功能，以确定它是否真正具备「端到端」的能力。

因此，大多数实验流水线都假设数据已经准备就绪并可以直接使用。它们包括数据摄取功能或指向存储数据的能力，但通常不包括填补缺失或损坏数据、将音频从 WAV 转码为 MP4、调整所有图像大小或将图像转换为其他格式等步骤，这些工作属于数据工程师的职责。有时候它们可能包括这些功能，但总体上，高级的 ETL 概念并不是实验重点平台的一部分。相反，它们专注于帮助数据科学家提取特征，对比测试多个模型，调整超参数并完成模型的生产准备。

实验引擎通常可以分为两类：

  • 包括自己的编排/流水线引擎 和/或 调度器的平台
  • 聚合其他流水线系统的元数据并编排 和/或 可视化这些流水线的平台

ClearML、DataRobot、Google Vertex、Amazon SageMaker、Azure Machine Learning、Neu.ro、Valohai、Iguazio、Flyte 和 ZenML 属于第一类，它们拥有自己的流水线引擎。

虽然 Neu.ro 包括自己的流水线引擎，但它主要将自己定位为第三方工具的编排器和集成器，因此我们将其放在这里。 专注于第三方集成并作为粘合层的公司可能构成第三类，但由于许多平台专注于与第三方集成，如 Dataiku、Iguazio 和 Domino Data Labs，我们认为这并没有增加太多价值。

Weights & Biases、Neptune AI、Comet.ML、Infuse AI’s Piperider 、Domino Data Labs、Infuse AI 和 DAGsHub 在广义上属于第三类，它们依赖于其他流水线系统（如 Spark）进行运行。它们注重可视化和跟踪不同工具上的实验。

通常，你可以通过它们的营销手法中的一个明显特征来识别第二种类型的平台，通常是类似于「一行代码集成」的宣传口号。元数据存储被设计为与其他平台轻松集成，并且致力于成为连接系统中不同元数据的单一真实来源。

让我们依次看一下这些平台，首先是松散和紧密耦合的编排器。

ClearML

ClearML 是一个开源工具套件，涵盖了广泛的 AI/ML 任务。它的编排和流水线既适用于数据工程，也适用于实验，旨在使两者之间的过渡简单易行。编排模块引入了在裸机、云基础设施和 Kubernetes 集群上的调度和远程作业执行。 用户界面专注于构建和测试模型，并将其投入生产，允许直接从实验界面进行作业调度。

它还包括元数据索引工具，用于允许数据科学家搜索、拆分和排序数据。这些工具允许经典的数据科学任务，如即时切片训练数据和测试数据，以及克隆先前的实验。 在此过程中，该平台从代码中生成工件，并将创建的所有模型版本存储在可查询的模型库中。它可以与 Tensorboard、Matplotlib 和 Git 进行集成。最后，它允许在多台机器上进行超参数优化、数据预处理和模型部署，为数据科学家提供了更完整的端到端体验，将模型投入生产。

DataRobot

DataRobot 的实验能力主要基于 Spark，但他们还拥有一些出色的专有界面，使数据科学体验更加简单，尤其适用于结构化用例和大量的可视化。此外，DataRobot 在市场上拥有较好的 AutoML 能力。

在本报告中，我们没有花太多时间讨论 AutoML，因为它会引发一种自动执行数据科学家大部分工作的 AI 的想法，而这并不是现实。然而，DataRobot 对 AutoML 的愿景非常专注和清晰。它基本上涉及同时尝试许多已知的 ML 问题解决方法，并为用户提供查看哪种方法最有效的能力，而不需要进行大量的手动实验。然后，数据科学团队可以专注于进一步优化各种方法。与该领域的其他大型平台一样，DataRobot 希望创建真正的端到端体验，他们的工具不仅处理实验，还涉及一些数据工程、部署、服务和监控方面的任务。

Vertex AI

Vertex AI 是 Google SageMaker 和 Azure machine-learning 云平台的竞争对手。与其他大型平台类似，它实际上是一套松散连接的工具，而不是无缝统一的体验。它是仅有的几个建立在 Kubeflow 流水线（和T ensorflow Extended）之上的商业平台之一，但在内部也使用了许多专有技术，如神经结构搜索和他们自己的特征存储。与一些竞争对手不同，它并不过分关注出色的图形用户界面设计，而且这从来都不是谷歌最擅长的。但它利用了谷歌在容器、大规模系统和命令行方面的专业知识。它比 SageMaker 稍微更模块化一些，但仍然主要是一个封闭的生态系统，不过其 API 比某些更为单体化的引擎更强大。该系统专注于具有丰富编程和命令行经验的团队。

H2O

H2O 是一个开源的、内存中的大数据处理引擎，用于机器学习和分析工作负载，与 Spark 争。与本报告中的许多其他大型平台一样，最好将其视为以内存流水线为核心的一套工具。它最适合结构化数据工作负载，但也支持图像、音频和其他非结构化数据，并且可以读取 Parquet 文件等常见的第三方格式。它支持许多常见的机器学习算法，开发人员会为分布式处理定制编写这些算法。这意味着 H2O 主要用于运行预定义的机器学习模型，而不是开发自己的神经网络。H2O 的框架早于 Pytorch 和其他流行的框架，它与更广泛采用的框架（如 Pytorch ML）竞争，同时也是一个快速的流水线系统。

它由四个主要产品组成：

  • H2O，它的专有内存流水线；
  • Deep Water，它集成了 Tensorflow 并允许其利用；
  • 以及 Sparkling Water，它与 Apache Spark 集成
  • Driverless AI 是一个与 DataRobot 竞争的 AutoML 工具，可以实现自动特征工程、模型选择和调优。

Amazon SageMaker

Amazon SageMaker 是一套工具，包括数据整理、流水线、专有特征存储和标注系统等。其实验流水线运行在专有的 SageMaker 流水线上，并主要通过 SageMaker Studio 访问。 SageMaker 内部的工具套件定期扩展。大多数可视化界面几乎完全针对结构化数据工作负载设计，不太适合运行非结构化工作负载。目前，它是所有平台中最封闭的之一，旨在成为一个全集成套件。

Azure Machine Learning

Azure Machine Learning 将其实验引擎分为专有的流水线系统 Azure Machine Learning pipelines 和名为 Azure pipelines 的 CI/CD 风格的编排器，类似于J enkins。它的 pipelines 是模块化的，允许在 Docker 容器上独立执行。它的编排允许脚本化步骤和Kubernetes、VM、Azure Functions、Azure Web Apps 等的编排。编排器使用阶段、关卡和批准来创建部署策略，并允许来自其他 CI 系统（如 Jenkins）的编排步骤。

Iguazio

Iguazio 的编排是基于他们的开源 MLRun Python 框架构建的，它在他们的 Nuclio 无服务器平台上执行步骤。这个编排器松散耦合，并且设计用于编排多个平台，如 Spark。它与T ensorflow、Pytorch 和其他主要机器学习框架具有内置集成。它的界面更加注重模型实验，包括工程和训练，但在部署方面也非常出色，可以提供模型服务，并且具有与 Dask 等分布式分析框架的内置集成。

Neu.ro

Neu.ro 是一个松散耦合的编排系统，以能够轻松集成其他系统和对它们进行编排而自豪。由于它是为机器学习而设计的，所以比 AirFlow 等更高级和抽象的松散耦合编排器更细粒度。由于开发团队专注于将其打造成一个编排器，它包括与生态系统中的其他工具（如 Seldon Alibi、Seldon Core、Prometheus 和 Grafana、DVC 和其他平台）的许多集成，旨在将它们紧密地结合在一起，并将它们编织成一个用于机器学习的跨平台 CI/CD 工作流程。

HPE’s Ezmeral

HPE’s Ezmeral 平台利用了许多开源平台，如 Spark 和 MLflow，以及用于扩展的 Kubernetes。它还包括 Airflow 用于松散耦合的编排，可以针对 Kubeflow 流水线、Spark 或其他外部平台执行。由于广泛利用开源平台，它比其他平台更具模块化，可以更轻松地替换组件。它包括一个名为 App Workbench 的专有界面，以帮助连接这些不同的功能，以及一个 API 来更轻松地调度作业。

Shakudo

与 HPE Ezmeral 类似，Shakudo 在 Kubernetes 上构建了他们的平台，使用了一套开源工具，如 Tensorflow、Spark、MLFlow 和 Jupyter，并添加了一个专有界面。 我们预计在这个领域中会看到这种基于开源技术栈的趋势继续发展。集成不同的开源解决方案是一项挑战，我们预计会看到更多公司提供清晰的界面来使用这些解决方案。

Valohai

Valohai 的平台类似于 Pachyderm，它在后端使用 Kubernetes，使用 YAML/JSON 定义流水线中的步骤，并使用容器执行代码。这使得它与语言和框架版本无关。客户可以在一个步骤中使用 Anaconda 的一个版本，在后续步骤中使用另一个版本，同时在另一个步骤中使用完全不同的语言，如Rust。该平台主要关注深度学习，并且其用户界面更加偏向于数据科学部分的流水线，因为它强调实验和实验比较。由于它是语言和工具无关的，因此可以用于数据工程工作负载，但由于它具有明确定义的实验接口，我们主要将其分类为实验流水线。

Flyte

Flyte 是一个紧密耦合的框架，起源于 Lyft，最终在 Linux Foundation 的 LF AI & Data 小组找到了合适的归属。它被设计为 Airflow 的替代品，但专注于 ML 实验和部署，由于它本地运行在 Kubernetes 集群上，因此被认为是更紧密耦合的。 该系统避免使用 YAML 配置步骤，而是专注于直接的代码，如 Python 代码，来编排步骤，类似于 MLRun，但它也支持使用 Java 和 Scala 编写编排步骤。由于它是基于容器的，它可以以与 Pachyderm 或 Valohai 类似的方式执行步骤。

ZenML

ZenML 是一个松散耦合的基于 Python 的编排器，与 Neurolabs 类似，以其与 Spark、SageMaker 和 Argo 等各种组件的广泛集成而自豪。 它被设计为编排器的编排器，能够从各种专有和开源组件中组合出一个 MLOps 技术栈。

现在我们已经介绍了包含自己的编排引擎的平台，我们可以专注于更注重元数据的平台，用于充当跨多个平台的记录系统，并提供可视化和跟踪功能。

Weights & Biases

首先是 Weights & Biases，它本身不是一个编排器或流水线系统，而是与其他编排器集成，提供实验跟踪和实验可视化。它还提供检查点和重新运行实验的能力。最后，它监视 CPU 和 GPU 性能。

Comet.ML

Comet.ML 还通过一行代码的简单集成强调实验和可视化。它旨在简化与现有流程工作流的集成，甚至是自定义的流程工作流，并使团队更容易跟踪和比较这些模型。 它允许团队创建工作区，将机器学习项目和实验整合、管理、协作和报告起来。即使这些框架本身不支持日志记录，Comet.ML 也为许多常用的 Python 机器学习框架提供自动日志记录。

Domino Data Labs

Domino Data Labs 在各个平台之间充当元数据存储，并且其 Workbench 平台作为与 Spark 和 Ray 计算引擎的简单接口。它的目标是在各个平台之间充当记录系统，并使与其他平台的接口更容易，因此它属于松耦合的可视化编排器类别。

PipeRider

Infuse AI’s PipeRider 系统监视工作流的变化，并在违反期望时通知用户，以避免重复失败。与此领域的其他框架一样，它旨在轻松集成到其他平台中，从 DBT 开始，然后到 Snowflake、Tensorflow、Weights & Biases和MLflow。 由于它本身不设计执行编排，因此可以逐步引入到堆栈中。

DAGsHub

DAGsHub 是我们在这里介绍的最后一个元数据和可视化平台。它包括比较和差异文件的能力，并创建 DAG 的版本，允许团队通过评论、注释和共享 DAG 进行协作。它与 Jenkins 等第三方工具集成，并具有模块化设计。

编排和计算是 AI/ML 中最重要的组成部分之一。它们构成了系统中工作完成的基础，选择正确的框架一旦出错可能会带来高昂的代价，因为编排器和流水线与系统的所有或大部分其他方面都有连接。这是每家公司都应该广泛研究可用选项并花费时间确保平台与他们的需求及未来需求相匹配的领域。

在这个领域中，许多公司提供类似的功能，而那些打算在选择使用哪个平台上做出决策的公司应考虑以下因素：

  • 团队的主要能力
    • 他们是强大的程序员，还是需要强大的可视化图形用户界面，或者两者都需要？
  • 平台的能力范围
  • 需要支持的 AI/ML 项目类型
    • 结构化、半结构化、非结构化或以上所有类型？
  • 连接器和集成支持
  • 客户团队和支持
  • 专有工具的能力
  • 图形化前端界面

我们建议公司不仅要仔细考虑当前的 AI/ML 用例，还要考虑到将来可能需要处理的用例。市场上有很多功能强大的编排和流水线平台，但并不是每个平台都能满足所有需求。如果不小心选择了一个适用于结构化数据和数据库的强大系统，然后在深度学习方面遇到困难，那么您可能需要一套工具来实现组织的所有目标。

look beyond marketing」 [1] 是很重要的。许多平台承诺可以做到一切并处理任何类型的工作负载，但一定要要求公司展示一系列能力，并注意是否有花招。如果一家公司承诺可以像处理文本数据一样轻松处理高分辨率卫星图像，请务必检查能够详细展示这种功能的示例和案例研究。

此外，很难知道未来工作负载需要什么样的能力，而平台的限制可能直到团队使用平台一段时间后并转向新的用例，才会显露出来，只有在该平台内实现他们的目标变得具有挑战性。很可能您的团队需要使用一系列工具，包括一个或多个紧密耦合的数据工程框架，以及一个松耦合的编排器和一个实验引擎。

在当前一代平台中，Spark 是最主要的之一。这主要是因为它是现有代码库中最古老的，那些围绕它构建自己能力的公司有最长的时间来完善它们的界面、API 和这些能力。如果您正在处理结构化工作负载，Spark 具有出色的能力和成千上万个成功的用例。

然而，MapReduce 在 AI/ML 方面存在一些限制。像强化学习（RL）这样的新型 AI 范例具有级联的任务依赖，不容易适应 MapReduce 结构。尽管有 Delta Lake 等努力，非结构化数据在该平台上并不理想，这使得它不太适合深度学习。 就像 Spark 是为数据处理而构建的一样，新的框架（如 Ray 或 Google Pathways 培训架构）从头开始构建，考虑到现有的 AI/ML 工作负载和更具前沿性的工作负载。

随着 AI/ML 领域的发展以及新技术从研究实验室走向常见，我们预计 MapReduce 的局限性将继续显现其老化的特点。我们预计在未来五年内会出现更多像 Ray 和 Pathways 这样的框架，并且它们将竞争成为未来十年的默认分布式处理和分布式 AI/ML 应用框架。我们还预计将出现更多面向 AI/ML 的跨语言框架。尽管大多数主要工作都是以 Python 开始的，其他语言可以并且确实为 AI/ML 工作负载的各个步骤增加价值。我们还预计这些平台将吸纳依赖于这种基础逻辑的新型 AI/ML工 作负载。尽管如此，我们坚信 Spark 将继续在结构化数据应用中发挥强大作用，并在各种其他类型的商业智能和分析方面继续取得卓越成果。

虽然我们预计在 AI/ML 框架领域会出现竞争，但我们不认为会有其他通用计算引擎出现与 Kubernetes 竞争。Kubernetes 本身已经成为事实上的获胜者，击败了其他强有力的竞争对手，如 Apache Mesos、Docker Swarm 和 Rancher。 它们中没有一个像 Kubernetes 那样拥有广泛的关注度和黏性力，或者具有它的通用能力和可扩展潜力，除了 Mesos，后者已不再是云计算领域的严肃竞争对手。Kubernetes 服务现在可以在本地和每个主要的公共云上使用，我们并不认为会突然出现对它的严峻竞争。因此，可以预期 Kubernetes 在很大程度上充当底层计算层，而 AI/ML 框架层将在其之上运行，或者在类似 Nuclio 或 Amazon 的 Lambda 这样的无服务器平台上运行。

我们预计在未来五年内，数据工程流程层和实验流程层的竞争将继续激烈。我们可能会看到一些轻量级集成型平台（如 Weights & Biases）之间的整合，已经有一些出色的可视化平台存在。

除此之外，我们预计一些公司由于资金、管理或市场适应性等原因可能会失败或筹码耗尽。我们也看到一些收购和合并正在缩小这个领域的空间。尽管如此，我们肯定还没有看到该领域的新参与者的最后一位，因为这是一个令人兴奋且仍在发展的领域，所以新的参与者可能会弥补那些失败的老参与者的损失。

最后，有几个平台很可能开始在竞争中拉开差距，吸纳市场份额和客户，但我们不认为在未来五年内，该领域会完全由一两个完全主导的玩家决定。

脚注:

[1]  「look beyond marketing」: 这句话的意思是让人们超越营销的视角来看待事物。它鼓励人们不仅仅关注产品或服务的市场推广和销售，而是更深入地理解产品或服务本身。 ↩︎