Kubeflow 与其他选项
Kubeflow vs other options
我正在尝试寻找创建您自己的 Kubeflow MLOps 平台的时机：
- 如果你只购买 Tensorflow，你还需要 Kubeflow 吗？为什么不只有 TFX？可以使用 Airflow 进行编排。
- 如果你都在使用 scikit-learn，为什么还要使用 Kubeflow，因为它不支持 GPU 和分布式训练？可以使用 Airflow 进行编排。
- 如果您确信使用 Kubeflow，云提供商（Azure 和 GCP）正在提供 ML 管道概念（Google 在幕后使用 Kubeflow）作为托管服务。那么什么时候部署自己的 Kubeflow 环境才有意义呢？即使您有部署在本地的要求，您也可以选择使用云资源（云上的节点和数据）来训练您的模型，并且只将模型部署到本地。因此，使用 Azure 或 GCP AI 平台作为托管服务最适合交付 ML 管道？
构建 MLOps 平台是公司为了加速和管理其数据科学家在生产中的工作流程而采取的行动。这个工作流程体现在ML pipelines中，包括feature engineering、training和serving.
这3个主要任务
特征工程和模型训练是需要流水线编排器的任务，因为它们对后续任务有依赖性，这使得整个流水线容易出错。
软件构建管道不同于数据管道，而数据管道又不同于 ML 管道。
A 软件 CI/CD 流程 将代码编译为可部署的工件并加速软件交付过程。因此，代码输入，工件输出。它是通过编译任务的调用、测试的执行和工件的部署来实现的。此类管道的主要协调器是 Jenkins、Gitlab-CI 等
一个数据处理流程获取原始数据并执行转换以创建特征、聚合、计数等。所以数据输入，数据输出.这是通过调用远程分布式任务来实现的，这些任务通过将中间工件存储在数据存储库中来执行数据转换。此类管道的工具是 Airflow、Luigi 和一些 hadoop 生态系统解决方案。
在机器学习流程中，机器学习工程师编写代码来训练模型，使用数据对其进行评估，然后观察它们在生产中的表现以改进它们。所以 编码 和 数据输入，模型输出 。因此，此类工作流的实现需要结合我们上面讨论的编排技术。
TFX 介绍此管道并建议使用执行这些后续任务的组件。它定义了一个现代的、完整的 ML 管道，从构建特征到 运行训练、评估结果、在生产中部署和服务模型
Kubernetes 是最先进的容器编排系统，运行 生产工作负载的实际工具，与云无关的解决方案，可让您摆脱云供应商的困扰锁定并因此优化您的成本。
Kubeflow 定位为通过实现 TFX 在 Kubernetes 中进行 ML 的方式。最终它处理 代码和数据输入，模型输出 。它通过以 kubernetes 资源的形式实现 jupyter notebooks 来提供编码环境，称为 notebooks。所有云提供商都参与了该项目，并在 KF 的组件中实施了他们的数据加载机制。编排通过 KF pipelines 实现，模型服务通过 KF serving 实现。其组件的元数据在整个平台的 kubernetes 资源规范中指定。
在 Kubeflow 中，TFX 组件以可重用任务的形式存在，作为容器实现。这些组件的生命周期管理是通过 KF pipelines 的编排器 Argo 实现的。 Argo 将这些工作流实现为 kubernetes CRD。在 workflow 规范中，我们定义了 dag 任务、作为容器的 TFX 组件、将写入元数据存储的元数据等。这些工作流的执行使用标准的 kubernetes 资源（如 pods，以及 自定义资源定义，例如 experiments。这使得管道和组件的实现与语言无关，unline Airflow 仅在 python 中实现任务。然后，这些任务及其生命周期由 kubernetes 本机管理，无需使用像 Airflow 的 kubernetes-operator 这样的胶带解决方案。由于一切都是作为 kubernetes 资源实现的，一切都是 yaml，因此您可以找到最 Git 友好的配置。尝试在 Airflow 的 dag 目录中实施版本控制祝你好运。
模型在生产中的部署和管理是通过 KF serving 使用 inferenceservice 的 CRD 完成的。它利用 Istio 通过其 virtualservices 对模型的安全访问，无服务器资源使用 Knative Serving 的从零扩展pods、revisions 用于版本控制，prometheus metrics 用于可观察性，logs 在 ELK 中用于调试等等。 运行 生产中的模型对 SRE 的友好程度再高不过了。
关于在云和内部部署之间拆分 training/serving 的话题，kubernetes 的使用更为重要，因为它抽象了每个提供商的自定义基础架构实现，从而为developer/ml 工程师。
我正在尝试寻找创建您自己的 Kubeflow MLOps 平台的时机：
- 如果你只购买 Tensorflow，你还需要 Kubeflow 吗？为什么不只有 TFX？可以使用 Airflow 进行编排。
- 如果你都在使用 scikit-learn，为什么还要使用 Kubeflow，因为它不支持 GPU 和分布式训练？可以使用 Airflow 进行编排。
- 如果您确信使用 Kubeflow，云提供商（Azure 和 GCP）正在提供 ML 管道概念（Google 在幕后使用 Kubeflow）作为托管服务。那么什么时候部署自己的 Kubeflow 环境才有意义呢？即使您有部署在本地的要求，您也可以选择使用云资源（云上的节点和数据）来训练您的模型，并且只将模型部署到本地。因此，使用 Azure 或 GCP AI 平台作为托管服务最适合交付 ML 管道？
构建 MLOps 平台是公司为了加速和管理其数据科学家在生产中的工作流程而采取的行动。这个工作流程体现在ML pipelines中，包括feature engineering、training和serving.
特征工程和模型训练是需要流水线编排器的任务，因为它们对后续任务有依赖性，这使得整个流水线容易出错。
软件构建管道不同于数据管道，而数据管道又不同于 ML 管道。
A 软件 CI/CD 流程 将代码编译为可部署的工件并加速软件交付过程。因此，代码输入，工件输出。它是通过编译任务的调用、测试的执行和工件的部署来实现的。此类管道的主要协调器是 Jenkins、Gitlab-CI 等
一个数据处理流程获取原始数据并执行转换以创建特征、聚合、计数等。所以数据输入，数据输出.这是通过调用远程分布式任务来实现的，这些任务通过将中间工件存储在数据存储库中来执行数据转换。此类管道的工具是 Airflow、Luigi 和一些 hadoop 生态系统解决方案。
在机器学习流程中，机器学习工程师编写代码来训练模型，使用数据对其进行评估，然后观察它们在生产中的表现以改进它们。所以 编码 和 数据输入，模型输出 。因此，此类工作流的实现需要结合我们上面讨论的编排技术。
TFX 介绍此管道并建议使用执行这些后续任务的组件。它定义了一个现代的、完整的 ML 管道，从构建特征到 运行训练、评估结果、在生产中部署和服务模型
Kubernetes 是最先进的容器编排系统，运行 生产工作负载的实际工具，与云无关的解决方案，可让您摆脱云供应商的困扰锁定并因此优化您的成本。
Kubeflow 定位为通过实现 TFX 在 Kubernetes 中进行 ML 的方式。最终它处理 代码和数据输入，模型输出 。它通过以 kubernetes 资源的形式实现 jupyter notebooks 来提供编码环境，称为 notebooks。所有云提供商都参与了该项目，并在 KF 的组件中实施了他们的数据加载机制。编排通过 KF pipelines 实现，模型服务通过 KF serving 实现。其组件的元数据在整个平台的 kubernetes 资源规范中指定。
在 Kubeflow 中，TFX 组件以可重用任务的形式存在，作为容器实现。这些组件的生命周期管理是通过 KF pipelines 的编排器 Argo 实现的。 Argo 将这些工作流实现为 kubernetes CRD。在 workflow 规范中，我们定义了 dag 任务、作为容器的 TFX 组件、将写入元数据存储的元数据等。这些工作流的执行使用标准的 kubernetes 资源（如 pods，以及 自定义资源定义，例如 experiments。这使得管道和组件的实现与语言无关，unline Airflow 仅在 python 中实现任务。然后，这些任务及其生命周期由 kubernetes 本机管理，无需使用像 Airflow 的 kubernetes-operator 这样的胶带解决方案。由于一切都是作为 kubernetes 资源实现的，一切都是 yaml，因此您可以找到最 Git 友好的配置。尝试在 Airflow 的 dag 目录中实施版本控制祝你好运。
模型在生产中的部署和管理是通过 KF serving 使用 inferenceservice 的 CRD 完成的。它利用 Istio 通过其 virtualservices 对模型的安全访问，无服务器资源使用 Knative Serving 的从零扩展pods、revisions 用于版本控制，prometheus metrics 用于可观察性，logs 在 ELK 中用于调试等等。 运行 生产中的模型对 SRE 的友好程度再高不过了。
关于在云和内部部署之间拆分 training/serving 的话题，kubernetes 的使用更为重要，因为它抽象了每个提供商的自定义基础架构实现，从而为developer/ml 工程师。