Kubeflow与其他备选方案

Question

我试图找出什么时候创建自己的Kubeflow MLOps平台是合理的：

• 如果你是Tensorflow专卖店，你还需要Kubeflow吗？为什么不只是TFX？编曲可以用气流来完成。
• 为什么要使用Kubeflow，如果您使用的都是scikit-学习，因为它不支持GPU，分布式训练方式？
• 如果您确信要使用Kubeflow，云提供商(Azure和GCP)将提供ML管道概念(谷歌在幕后使用Kubeflow )作为托管服务。当部署自己的Kubeflow环境是有意义的时候？即使您需要部署on，也可以选择使用云资源(云上的节点和数据)来训练模型，并且只将模型部署到on。因此，使用Azure或GCP AI平台作为托管服务对于交付ML管道

是最有意义的。

Answer 1

构建MLOps平台是公司为加快和管理生产中的数据科学家的工作流程而采取的行动。该工作流反映在ML管道中，包括feature engineering、training和serving三个主要任务。

特征工程和模型训练是需要流水线协调器的任务，因为它们依赖于后续任务，这使得整个管道容易出错。

软件构建管道不同于数据管道，而数据管道又不同于ML管道。

软件CI/CD流编译代码以部署可部署的工件，并加速软件交付过程。所以，代码输入，工件输出。它是通过调用编译任务、执行测试和部署工件来实现的。这类管道的主要策划者是Jenkins、Gitlab等.

数据处理流程获取原始数据并执行转换以创建特性、聚合、计数等。因此，数据输入、数据输出。这是通过调用远程分布式任务来实现的，这些任务通过在数据存储库中存储中间工件来执行数据转换。用于这些管道的工具有气流、Luigi和一些hadoop生态系统解决方案。

在机器学习流程中，ML工程师编写代码来训练模型，使用数据对它们进行评估，然后观察它们在生产中的表现，以便改进它们。因此，编码和数据，建模。因此，这样一个工作流的实现需要结合我们前面讨论过的业务流程技术。

TFX提供了这个管道，并建议使用执行这些后续任务的组件。它定义了一个现代的、完整的ML管道，从构建特性到运行培训、评估结果、在生产中部署和服务模型。

Kubernetes是编排容器的最先进的系统，它实际上是在生产中运行工作负载的工具，是云无关的解决方案，可以将您从云供应商的锁定中拯救出来，从而优化成本。

Kubeflow被定位为通过实现TFX在Kubernetes中实现ML的方法。最后，它处理代码和数据，建立模型。它通过以kubernetes资源的形式实现jupyter笔记本提供了一个编码环境，称为notebooks。所有云提供商都参与了该项目，并在KF的组件中实现了他们的数据加载机制。业务流程通过KF管道实现，模型服务通过KF服务实现。跨其组件的元数据在整个平台的kubernetes资源规范中指定。

在Kubeflow中，TFX组件以可重用任务的形式存在，作为容器实现。这些组件的生命周期管理是通过KF管道的协调器Argo实现的。Argo将这些工作流实现为kubernetes CRD。在workflow规范中，我们将守护任务、TFX组件定义为容器、将写入元数据存储中的元数据等。这些工作流的执行很好地使用了标准的kubernetes资源(如pods )以及自定义资源定义(如experiments )。这使得管道的实现和组件语言无关，不确定的、只在python中实现任务的非线气流。这些任务及其生命周期由kubernetes自行管理，不需要使用像气流的kubernetes操作符这样的管道胶带解决方案。由于一切都是作为kubernetes资源实现的，所以所有东西都是yaml，因此是您所能找到的最友好的Git配置。祝您好运，在气流的dag目录中执行版本控制。

该模型在生产中的部署和管理是通过KF使用inferenceservice的CRD为服务的。它利用Istio通过其virtualservices对模型的安全访问，使用K本地服务的自零扩展pods、revisions用于版本控制、prometheus metrics用于可观察性、logs在ELK中进行调试等无服务器资源。在生产中运行模型不能比这更友好。

关于在云和前提之间分离培训/服务的主题，kubernetes的使用更为重要，因为它抽象了每个提供者的自定义基础结构实现，从而为开发人员/ml工程师提供了一个统一的环境。