GCP Kubeflow和GCP云编写器有什么区别？

Question

我正在学习GCP，遇到了Kuberflow和。

据我所理解，两者似乎都用于编排工作流，授权用户调度和监视GCP中的管道。

我能找到的唯一不同之处是Kuberflow部署和监视机器学习模型。我说的对吗？在这种情况下，由于机器学习模型也是对象，我们不能使用Composer来编排它们吗？在管理机器学习模型方面，Kubeflow有什么帮助，比Composer好吗？

谢谢

Answer 1

• 库贝流是一个开发和部署机器学习(ML)系统的平台。其组分专注于创建旨在构建ML系统的工作流。
• Composer提供了运行https://airflow.apache.org/docs/stable/的基础结构。它的组件称为气流操作者，工作流是这些操作符之间的连接，称为DAG。

这两个服务都运行在Kubernetes上，但是它们基于不同的编程框架；因此，您是正确的，Kuberflow部署和监视机器学习模型。以下是你的问题的答案：

1. 在这种情况下，由于机器学习模型也是对象，我们不能使用Composer来编排它们吗？

您需要找到一个满足您需要的操作符，或者创建一个具有创建模型所需结构的自定义操作符，请参阅这个例子。即使可以执行，这可能比使用Kubeflow更困难。

1. 在管理机器学习模型方面，Kubeflow有什么帮助，比Composer好吗？

Kubeflow隐藏了复杂性，因为它专注于机器学习模型。专门用于机器学习的框架比使用Composer更容易，在这种情况下，Composer可以被看作是一个通用工具(重点是链接由气流运算符支持的现有服务)。

Answer 2

Kubeflow和Kubeflow管道

Kubeflow与Kubeflow管道不完全相同。Kubeflow项目主要开发用于分布式ML培训(TFJob，PyTorchJob)的Kubernetes算子。另一方面，管道项目开发了一个在Kubernetes上创作和运行管道的系统。KFP还有一些示例组件，主要产品是管道创作SDK和管道执行引擎。

Kubeflow管道诉云作曲家

这些项目非常相似，但也有不同之处：

• KFP使用Argo执行和编排。云编写器使用Apache气流。
• KFP/Argo是为在Kubernetes上分布式执行而设计的。Composer/Apache气流更适合单机执行。
• KFP/Argo与语言无关-组件可以使用任何语言(组件描述容器化命令行程序)。Composer/Apache气流使用Python (气流运算符被定义为Python类)。
• KFP/Argo有数据传递的概念。每个组件都有输入和输出，管道将它们连接成一个数据传递图。Composer/ Airflow并没有真正的数据传递(气流具有全局变量存储和XCom，但它与显式数据传递不是一回事)，管道是一个任务依赖图，而不是大多数数据依赖图(KFP也可以具有任务依赖关系，但通常不需要它们)。
• KFP支持执行缓存功能，它可以跳过之前已经执行的任务的执行。
• KFP将管道产生的所有工件记录在ML元数据数据库中。
• KFP有实验适配器，允许使用气流操作器作为组件。
• KFP拥有大型快速增长的自定义组件生态系统。

Answer 3

直接从kubeflow.org得到这个

Kubeflow项目致力于使在Kubernetes上部署机器学习(ML)工作流变得简单、可移植和可伸缩。我们的目标不是重新创建其他服务，而是提供一种简单的方法，为ML部署最优秀的开放源代码系统，以适应不同的基础设施。无论你在哪里运行Kubernetes，你都应该能够运行Kubeflow。

正如您所看到的，它是由许多软件组成的套件，在ML模型的生命周期中非常有用。它附带了tensorflow，木星等。现在真正的交易是，当涉及Kubeflow时，“在Kubernetis集群上很容易地部署一个ML模型”。

然而，在GCP上，您已经是一个在云、datalab、云构建等方面的ML套件了。所以，如果不需要“可移植性”因素，那么我不知道这对kubernetis集群的效率有多大。

云作曲家是真正的交易，同时也涉及到工作流的编排。它是Apache气流的“托管”版本，对于任何变化很大的“简单”工作流来说，它都是理想的，因为您可以通过可视化UI和python来更改它。

实现基础设施操作自动化也是理想的做法：

​

​