ZenML Stack 与 Stack Components 完全指南用组件化配置掌控 MLOps 基础设施【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlZenML 中的 Stack栈是一组 Stack Component栈组件的集合它们共同构成运行 ML 流水线的 MLOps 基础设施流水线代码决定做什么而 Stack 决定在哪里、以何种方式运行。本篇指南基于 ZenML 官方文档docs/book/how-to/stack-components/stack_components.md系统讲解 Stack 的结构、CLI/Python API 的完整操作方式并结合仓库源码剖析组件注册、默认组件选取与 flavor 配置发现机制的底层实现帮助你在本地开发与云端生产环境之间无缝切换实现基础设施与流水线代码的真正解耦。什么是 ZenML Stack在 ZenML 中Stack是多个栈组件Stack Components的集合这些组件共同构成运行 ML 流水线所需的完整 MLOps 基础设施。一条流水线的代码pipeline code定义了 ML 工作流中发生什么——包括步骤、数据流和逻辑而 Stack 则决定了这段代码在哪里、如何执行——包括编排方式、存储位置、计算资源与配套工具。从源码看Stack 类内部将所有组件按类型保存在_components: Dict[StackComponentType, List[StackComponent]]中默认使用defaultdict(list)并显式支持同一类型挂载多个组件实例。采用 Stack 抽象可以带来以下关键收益环境灵活性Environment Flexibility同一套流水线代码开发阶段在本地运行生产阶段在云端运行代码无需改动。基础设施分离Infrastructure Separation更换基础设施如从本地编排切换到 Kubernetes时无需修改流水线代码。专业化资源Specialized Resources为 ML 工作流的不同环节选用专业化工具如 GPU 步进算子、专用实验跟踪器。团队协作Team Collaboration在团队间共享基础设施配置新成员一键复用相同的运行环境。可复现性Reproducibility确保流水线在不同环境中获得一致的执行行为。Stack 的结构必需组件与可选组件必需组件Required Components每个 ZenML Stack必须包含以下两个核心组件Orchestrator编排器控制流水线步骤如何被执行。它决定步骤是本地运行、在 Kubernetes 集群中调度还是由其他云编排平台接管。Artifact Store工件存储管理流水线工件的存储位置。步骤的输入输出数据、模型等中间产物都持久化在这里。这两个组件的强制性与Stack类的构造函数签名完全一致在 stack.py 中orchestrator与artifact_store是唯二不带默认值的必填参数而其余组件均为可选。可选组件Optional ComponentsStack 还可以包含以下可选组件Container Registry容器镜像仓库存储流水线步骤的 Docker 镜像云端执行步骤前构建与拉取镜像时使用。Deployer部署器将流水线作为长期运行的 HTTP 服务进行部署。Step Operator步进算子在专用硬件如 GPU上运行特定步骤。Model Deployer模型部署器将模型部署为预测服务。Experiment Tracker实验跟踪器跟踪指标与超参数。Feature Store特征存储管理 ML 特征。Alerter告警器发送流水线事件通知如 Slack 告警。Annotator标注器管理数据标注工作流。从 StackComponentType 枚举可以看出ZenML 当前支持的全部组件类型实际上有 15 种除了上述组件外还包括data_validator数据校验器、image_builder镜像构建器、log_store日志存储、model_registry模型注册表与sandbox沙箱。每种组件类型在StackComponentType中都有唯一的字符串标识如orchestrator、artifact_store这也是 CLI 命令与 API 中使用的类型名。可重复组件Repeatable Components大多数组件类型在一个 Stack 中最多出现一次但有三种组件类型可以重复挂载Step OperatorsExperiment TrackersAlerters如果一个 Stack 挂载了多个同类型组件第一个被挂载的组件就是默认组件。你仍然可以在步骤或流水线配置中按名称指定使用非默认组件也可以稍后通过zenml stack set-default修改默认组件。这一点与源码实现完全吻合在 enums.py 中supports_multiple_per_stack属性对ALERTER、EXPERIMENT_TRACKER、STEP_OPERATOR以及SANDBOX返回True而在 stack.py 的_get_default_component方法中默认组件就是组件列表中下标为 0 的第一个组件components[0]。使用 Stack理解活动栈Active Stack在 ZenML 中你始终有一个活动栈active stack运行流水线时默认使用它。查看和切换活动栈通过 CLI 完成# 查看当前活动栈 zenml stack describe # 切换到另一个栈 zenml stack set STACK_NAME切换到云栈后无需修改任何流水线代码后续运行就会自动使用新的基础设施。这种代码与基础设施解耦正是 Stack 抽象的核心价值所在。管理 Stack创建、注册与更新列出所有栈zenml stack list注册最小 Stack使用最小组件注册一个新栈只需指定必需的 artifact store 与 orchestratorzenml stack register my-stack -a local-store -o local-orchestrator其中-a/--artifact-store指定工件存储-o/--orchestrator指定编排器。注册带附加组件的 Stackzenml stack register production-stack \ --artifact-store s3-store \ --orchestrator kubeflow \ --container-registry ecr-registry \ --experiment-tracker mlflow-tracker挂载多个可重复组件对于可重复组件类型可以在同一条命令中多次传参第一个传入的组件成为默认组件zenml stack register training-stack \ --artifact-store s3-store \ --orchestrator kubernetes \ --step_operator gpu-step-operator \ --step_operator cpu-step-operator \ --experiment_tracker mlflow \ --experiment_tracker wandb提升默认组件将某个已挂载的组件提升为默认组件使用zenml stack set-defaultzenml stack set-default training-stack --step_operator cpu-step-operator从 CLI 实现可以看到set-default命令支持-s/--step_operator、-e/--experiment_tracker、-al/--alerter、-sb/--sandbox四个选项分别对应四种可重复组件类型如果省略栈名参数则默认作用于当前活动栈。发现 flavor 专属配置不同的栈组件 flavor口味/变体拥有不同的配置字段。例如本地 orchestrator 几乎不需要额外配置Kubernetes orchestrator 需要集群与命名空间信息S3 artifact store 需要 bucket 信息。一旦通过-f/--flavor指定了 flavorCLI 就能显示出该 flavor 的具体配置字段zenml orchestrator register -f kubernetes --help zenml artifact-store register -f s3 --help zenml step-operator update my-runai-step-operator --help帮助输出中包含Flavor configuration部分。对于 register 和 update 命令将这些字段以--namevalue参数形式传入即可。这是回答这个 flavor 到底需要我提供什么配置的最快捷方式。这一机制在源码层面由 Flavor 基类支撑每个 flavor 通过name、type、implementation_class、config_class四个抽象属性定义自身其中config_class指定继承自StackComponentConfig的 Pydantic 配置类而config_schema属性config_class.model_json_schema()会生成完整的 JSON SchemaCLI 据此动态渲染出可用的配置项。此外StackComponentConfig 还支持密钥引用secret references所有字符串属性都可以使用{{secret_name.key}}形式引用 ZenML Secrets避免在配置中硬编码敏感信息。通过 Python API 管理 Stack除了 CLI也可以使用 Python 客户端 API 完成栈的查询与激活from zenml.client import Client client Client() # 列出所有栈 stacks client.list_stacks() # 设置活动栈 client.activate_stack(my-stack)底层上Client.activate_stack最终会更新全局配置中的活动栈记录与 CLI 的zenml stack set行为等价。本地栈与云栈ZenML 提供两种主要类型的 Stack本地栈Local Stack使用本地机器进行编排与存储。这是默认配置无需任何额外设置——安装 ZenML 后即可直接运行流水线。云栈Cloud Stack使用云服务进行编排、存储及其他组件。这类栈提供更高的可扩展性与更多功能但需要额外的部署与配置如 Kubernetes 集群、云对象存储、服务连接器等。使用 ZenML 时你从本地栈自动起步随着 ML 项目规模增长通常需要部署云栈以承载更大规模的工作负载并与团队协作。云栈往往涉及云服务认证此时推荐借助Service Connectors统一管理云服务的身份认证详见 Service Connectors 指南。深入源码Stack 如何组织与验证组件组件的内部组织在 stack.py 中Stack类将组件按StackComponentType分组存储all_components属性返回挂载到栈上的全部组件的扁平列表get_components_by_type(component_type)返回某一类型的所有组件序列_get_default_component(component_type)返回该类型的默认组件即列表中的第一个元素。这就是文档所述第一个挂载的组件成为默认组件的源码依据。同时Stack 类还支持environment栈级环境变量与secrets栈级密钥配置在运行该栈上的流水线时注入到运行环境中。从模型还原 StackStack.from_model是服务端栈模型到本地Stack对象的转换入口见 stack.py。它会通过一次分页的list_stack_components(stack_id..., hydrateTrue)调用批量拉取该栈的所有组件避免为每个组件单独发请求逐一构建组件实例如果某个组件所需的集成依赖未安装会抛出ImportError并提示运行zenml stack export-requirements STACK_NAME -o stack-requirements.txt pip install -r stack-requirements.txt来一次性安装该栈的全部依赖——这对于团队共享栈配置后的环境还原非常实用。验证与约束在Stack构造与使用过程中组件之间的依赖与约束例如需要镜像构建的编排器必须配套 container registry由 stack_validator.py 中的校验逻辑统一把关确保注册出的栈结构合法、可运行。下一步学习路径理解 Stack 之后你可以进一步探索在 组件指南 中查阅各类组件orchestrators、artifact-stores、container-registries、deployers、step-operators、model-deployers、experiment-trackers、feature-stores、alerters、annotators 等的详细配置文档阅读 Service Connectors 了解如何统一管理云服务认证为云栈的组件提供安全、可复用的凭证参考仓库中的 quickstart 示例 与 mlops_starter 示例 体验最小栈到完整训练/推理栈的搭建过程在云平台上部署 Stack 时可结合 基础设施部署指南 中的资源部署方法将现有云资源注册为 ZenML 栈组件。掌握 Stack 与 Stack Components 是高效使用 ZenML 的关键一步它让你以声明式的方式管理 MLOps 基础设施在本地与云端、开发与生产之间自由切换同时保持流水线代码的整洁与可移植。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZenML Stack 与 Stack Components 完全指南：用组件化配置掌控 MLOps 基础设施
ZenML Stack 与 Stack Components 完全指南用组件化配置掌控 MLOps 基础设施【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlZenML 中的 Stack栈是一组 Stack Component栈组件的集合它们共同构成运行 ML 流水线的 MLOps 基础设施流水线代码决定做什么而 Stack 决定在哪里、以何种方式运行。本篇指南基于 ZenML 官方文档docs/book/how-to/stack-components/stack_components.md系统讲解 Stack 的结构、CLI/Python API 的完整操作方式并结合仓库源码剖析组件注册、默认组件选取与 flavor 配置发现机制的底层实现帮助你在本地开发与云端生产环境之间无缝切换实现基础设施与流水线代码的真正解耦。什么是 ZenML Stack在 ZenML 中Stack是多个栈组件Stack Components的集合这些组件共同构成运行 ML 流水线所需的完整 MLOps 基础设施。一条流水线的代码pipeline code定义了 ML 工作流中发生什么——包括步骤、数据流和逻辑而 Stack 则决定了这段代码在哪里、如何执行——包括编排方式、存储位置、计算资源与配套工具。从源码看Stack 类内部将所有组件按类型保存在_components: Dict[StackComponentType, List[StackComponent]]中默认使用defaultdict(list)并显式支持同一类型挂载多个组件实例。采用 Stack 抽象可以带来以下关键收益环境灵活性Environment Flexibility同一套流水线代码开发阶段在本地运行生产阶段在云端运行代码无需改动。基础设施分离Infrastructure Separation更换基础设施如从本地编排切换到 Kubernetes时无需修改流水线代码。专业化资源Specialized Resources为 ML 工作流的不同环节选用专业化工具如 GPU 步进算子、专用实验跟踪器。团队协作Team Collaboration在团队间共享基础设施配置新成员一键复用相同的运行环境。可复现性Reproducibility确保流水线在不同环境中获得一致的执行行为。Stack 的结构必需组件与可选组件必需组件Required Components每个 ZenML Stack必须包含以下两个核心组件Orchestrator编排器控制流水线步骤如何被执行。它决定步骤是本地运行、在 Kubernetes 集群中调度还是由其他云编排平台接管。Artifact Store工件存储管理流水线工件的存储位置。步骤的输入输出数据、模型等中间产物都持久化在这里。这两个组件的强制性与Stack类的构造函数签名完全一致在 stack.py 中orchestrator与artifact_store是唯二不带默认值的必填参数而其余组件均为可选。可选组件Optional ComponentsStack 还可以包含以下可选组件Container Registry容器镜像仓库存储流水线步骤的 Docker 镜像云端执行步骤前构建与拉取镜像时使用。Deployer部署器将流水线作为长期运行的 HTTP 服务进行部署。Step Operator步进算子在专用硬件如 GPU上运行特定步骤。Model Deployer模型部署器将模型部署为预测服务。Experiment Tracker实验跟踪器跟踪指标与超参数。Feature Store特征存储管理 ML 特征。Alerter告警器发送流水线事件通知如 Slack 告警。Annotator标注器管理数据标注工作流。从 StackComponentType 枚举可以看出ZenML 当前支持的全部组件类型实际上有 15 种除了上述组件外还包括data_validator数据校验器、image_builder镜像构建器、log_store日志存储、model_registry模型注册表与sandbox沙箱。每种组件类型在StackComponentType中都有唯一的字符串标识如orchestrator、artifact_store这也是 CLI 命令与 API 中使用的类型名。可重复组件Repeatable Components大多数组件类型在一个 Stack 中最多出现一次但有三种组件类型可以重复挂载Step OperatorsExperiment TrackersAlerters如果一个 Stack 挂载了多个同类型组件第一个被挂载的组件就是默认组件。你仍然可以在步骤或流水线配置中按名称指定使用非默认组件也可以稍后通过zenml stack set-default修改默认组件。这一点与源码实现完全吻合在 enums.py 中supports_multiple_per_stack属性对ALERTER、EXPERIMENT_TRACKER、STEP_OPERATOR以及SANDBOX返回True而在 stack.py 的_get_default_component方法中默认组件就是组件列表中下标为 0 的第一个组件components[0]。使用 Stack理解活动栈Active Stack在 ZenML 中你始终有一个活动栈active stack运行流水线时默认使用它。查看和切换活动栈通过 CLI 完成# 查看当前活动栈 zenml stack describe # 切换到另一个栈 zenml stack set STACK_NAME切换到云栈后无需修改任何流水线代码后续运行就会自动使用新的基础设施。这种代码与基础设施解耦正是 Stack 抽象的核心价值所在。管理 Stack创建、注册与更新列出所有栈zenml stack list注册最小 Stack使用最小组件注册一个新栈只需指定必需的 artifact store 与 orchestratorzenml stack register my-stack -a local-store -o local-orchestrator其中-a/--artifact-store指定工件存储-o/--orchestrator指定编排器。注册带附加组件的 Stackzenml stack register production-stack \ --artifact-store s3-store \ --orchestrator kubeflow \ --container-registry ecr-registry \ --experiment-tracker mlflow-tracker挂载多个可重复组件对于可重复组件类型可以在同一条命令中多次传参第一个传入的组件成为默认组件zenml stack register training-stack \ --artifact-store s3-store \ --orchestrator kubernetes \ --step_operator gpu-step-operator \ --step_operator cpu-step-operator \ --experiment_tracker mlflow \ --experiment_tracker wandb提升默认组件将某个已挂载的组件提升为默认组件使用zenml stack set-defaultzenml stack set-default training-stack --step_operator cpu-step-operator从 CLI 实现可以看到set-default命令支持-s/--step_operator、-e/--experiment_tracker、-al/--alerter、-sb/--sandbox四个选项分别对应四种可重复组件类型如果省略栈名参数则默认作用于当前活动栈。发现 flavor 专属配置不同的栈组件 flavor口味/变体拥有不同的配置字段。例如本地 orchestrator 几乎不需要额外配置Kubernetes orchestrator 需要集群与命名空间信息S3 artifact store 需要 bucket 信息。一旦通过-f/--flavor指定了 flavorCLI 就能显示出该 flavor 的具体配置字段zenml orchestrator register -f kubernetes --help zenml artifact-store register -f s3 --help zenml step-operator update my-runai-step-operator --help帮助输出中包含Flavor configuration部分。对于 register 和 update 命令将这些字段以--namevalue参数形式传入即可。这是回答这个 flavor 到底需要我提供什么配置的最快捷方式。这一机制在源码层面由 Flavor 基类支撑每个 flavor 通过name、type、implementation_class、config_class四个抽象属性定义自身其中config_class指定继承自StackComponentConfig的 Pydantic 配置类而config_schema属性config_class.model_json_schema()会生成完整的 JSON SchemaCLI 据此动态渲染出可用的配置项。此外StackComponentConfig 还支持密钥引用secret references所有字符串属性都可以使用{{secret_name.key}}形式引用 ZenML Secrets避免在配置中硬编码敏感信息。通过 Python API 管理 Stack除了 CLI也可以使用 Python 客户端 API 完成栈的查询与激活from zenml.client import Client client Client() # 列出所有栈 stacks client.list_stacks() # 设置活动栈 client.activate_stack(my-stack)底层上Client.activate_stack最终会更新全局配置中的活动栈记录与 CLI 的zenml stack set行为等价。本地栈与云栈ZenML 提供两种主要类型的 Stack本地栈Local Stack使用本地机器进行编排与存储。这是默认配置无需任何额外设置——安装 ZenML 后即可直接运行流水线。云栈Cloud Stack使用云服务进行编排、存储及其他组件。这类栈提供更高的可扩展性与更多功能但需要额外的部署与配置如 Kubernetes 集群、云对象存储、服务连接器等。使用 ZenML 时你从本地栈自动起步随着 ML 项目规模增长通常需要部署云栈以承载更大规模的工作负载并与团队协作。云栈往往涉及云服务认证此时推荐借助Service Connectors统一管理云服务的身份认证详见 Service Connectors 指南。深入源码Stack 如何组织与验证组件组件的内部组织在 stack.py 中Stack类将组件按StackComponentType分组存储all_components属性返回挂载到栈上的全部组件的扁平列表get_components_by_type(component_type)返回某一类型的所有组件序列_get_default_component(component_type)返回该类型的默认组件即列表中的第一个元素。这就是文档所述第一个挂载的组件成为默认组件的源码依据。同时Stack 类还支持environment栈级环境变量与secrets栈级密钥配置在运行该栈上的流水线时注入到运行环境中。从模型还原 StackStack.from_model是服务端栈模型到本地Stack对象的转换入口见 stack.py。它会通过一次分页的list_stack_components(stack_id..., hydrateTrue)调用批量拉取该栈的所有组件避免为每个组件单独发请求逐一构建组件实例如果某个组件所需的集成依赖未安装会抛出ImportError并提示运行zenml stack export-requirements STACK_NAME -o stack-requirements.txt pip install -r stack-requirements.txt来一次性安装该栈的全部依赖——这对于团队共享栈配置后的环境还原非常实用。验证与约束在Stack构造与使用过程中组件之间的依赖与约束例如需要镜像构建的编排器必须配套 container registry由 stack_validator.py 中的校验逻辑统一把关确保注册出的栈结构合法、可运行。下一步学习路径理解 Stack 之后你可以进一步探索在 组件指南 中查阅各类组件orchestrators、artifact-stores、container-registries、deployers、step-operators、model-deployers、experiment-trackers、feature-stores、alerters、annotators 等的详细配置文档阅读 Service Connectors 了解如何统一管理云服务认证为云栈的组件提供安全、可复用的凭证参考仓库中的 quickstart 示例 与 mlops_starter 示例 体验最小栈到完整训练/推理栈的搭建过程在云平台上部署 Stack 时可结合 基础设施部署指南 中的资源部署方法将现有云资源注册为 ZenML 栈组件。掌握 Stack 与 Stack Components 是高效使用 ZenML 的关键一步它让你以声明式的方式管理 MLOps 基础设施在本地与云端、开发与生产之间自由切换同时保持流水线代码的整洁与可移植。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考