Kubeflow 与其他选项

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

去年关闭。




Improve this question




我试图寻找何时创建您自己的 Kubeflow MLOps 平台是有意义的:

如果你只是 Tensorflow 商店，你还需要 Kubeflow 吗？为什么不只有 TFX？可以使用 Airflow 进行编排。

如果您都在使用 scikit-learn，那么为什么要使用 Kubeflow，因为它不支持 GPU 分布式训练？可以使用 Airflow 进行编排。

如果您确信使用 Kubeflow，云提供商(Azure 和 GCP)正在提供 ML 管道概念(Google 在幕后使用 Kubeflow)作为托管服务。那么何时部署您自己的 Kubeflow 环境才有意义呢？即使您需要在本地部署，您也可以选择使用云资源(云上的节点和数据)来训练模型，并且只将模型部署到本地。因此，使用 Azure 或 GCP AI 平台作为托管服务对交付 ML 管道最有意义吗？

Answer 1

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

特征工程和模型训练是需要流水线编排器的任务，因为它们具有后续任务的依赖性，这使得整个流水线容易出错。

软件构建管道不同于数据管道，而数据管道又不同于机器学习管道。

软件 CI/CD 流程 将代码编译为可部署的工件并加速软件交付过程。因此，输入代码，输出工件。它是通过调用编译任务、执行测试和部署工件来实现的。此类管道的主要协调器是 Jenkins、Gitlab-CI 等。

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

在 机器学习流程 中，ML 工程师编写代码来训练模型，使用数据来评估它们，然后观察它们在生产中的表现以改进它们。所以代码 和 数据输入，模型输出。因此，这种工作流的实现需要我们上面讨论的编排技术的组合。

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

Kubernetes 是最先进的容器编排系统，是在生产中运行工作负载的实际工具，是一种与云无关的解决方案，可帮助您摆脱云供应商锁定，从而优化您的成本。

Kubeflow 定位为通过实现 TFX 在 Kubernetes 中进行 ML 的方式。最终它处理输入的代码和数据，模型输出。它通过以 kubernetes 资源的形式实现 jupyter notebooks 来提供编码环境，称为 notebooks 。所有云提供商都参与了该项目，并在 KF 的组件中实现了他们的数据加载机制。编排通过 KF 管道 实现，模型通过 KF 服务 实现。跨其组件的元数据在整个平台的 kubernetes 资源的规范中指定。

在 Kubeflow 中，TFX 组件以可重用任务的形式存在，实现为容器。这些组件的生命周期管理是通过 Argo 实现的，Argo 是 KF 管道 的编排器。 Argo 将这些工作流实现为 kubernetes CRD。在 workflow 规范中，我们定义了 dag 任务、作为容器的 TFX 组件、将写入元数据存储中的元数据等。这些工作流的执行很好地使用标准 kubernetes 资源(如 pod)以及自定义资源定义进行像 experiments 。这使得管道和组件的实现与语言无关，unline Airflow 仅在 python 中实现任务。这些任务及其生命周期由 kubernetes 本地管理，无需使用像 Airflow 的 kubernetes-operator 这样的管道胶带解决方案。由于一切都是作为 kubernetes 资源实现的，一切都是 yaml，因此您可以找到对 Git 最友好的配置。祝你好运，在 Airflow 的 dag 目录中强制执行版本控制。

生产中模型的部署和管理是通过 KF 使用 inferenceservice 的 CRD 服务 完成的。它利用 Istio 通过其 virtualservices 对模型的安全访问，使用 Knative Serving 的从零开始的缩放 pods 、revisions 进行版本控制的无服务器资源、用于调试的 prometheus metrics 和更多 ELx1945 中的可观察性。在生产中运行模型对 SRE 来说再友好不过了。

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