升级到 v2
Azure 机器学习的 v2 REST API、Azure CLI 扩展和 Python SDK 引入了一致性和一组新功能，以加速生产机器学习生命周期。 本文将概述如何升级到 v2，并提供一些建议，以帮助你决定是选择 v1、v2 还是两者。
先决条件
- 大致熟悉 Azure 机器学习和 v1 Python SDK。
- 了解什么是 v2？
我应该使用 v2 吗？
如果正在开始一个新的机器学习项目或工作流，则应该使用 v2。 如果要使用 v2 中提供的新功能，则应该使用 v2。 具体功能包括：
- 托管推理
- 管道中的可重用组件
- 改进了管道的计划
- 负责任 AI 仪表板
- 资产注册表
新的 v2 项目可以重用现有 v1 资源（如工作区和计算）以及现有资产（如使用 v1 创建的模型和环境）。
v2 中的一些功能差异包括：
- 作业中的 Spark 支持 - 目前在 v2 中处于预览状态。
- 将作业（v1 中的管道）作为终结点发布。 但是，可以计划管道而不发布。
- 支持 SQL/数据库数据存储。
- 能够将设计器中的经典预生成组件与 v2 配合使用。
然后，应确保 v2 中所需的功能满足组织的要求，例如已正式发布。
重要
Azure 机器学习中的新功能将仅在 v2 中发布。
我该使用哪一个 v2 API？
在 v2 中，可以使用通过 REST API、CLI 和 Python SDK 的接口。 应使用的接口取决于你的场景和首选项。
| API | 说明 |
|---|---|
| REST | 依赖项和开销最少。 用于在作为平台的 Azure 机器学习上直接以编程语言构建应用程序（无需提供 SDK），或根据个人偏好构建应用程序。 |
| CLI | 推荐用于使用 CI/CD 或根据个人偏好实现自动化。 允许使用 YAML 文件进行快速迭代，并在 Azure 机器学习和 ML 模型代码之间直接分离。 |
| Python SDK | 推荐用于复杂的脚本编写（例如，以编程方式生成大型管道作业）或根据个人偏好。 允许使用 YAML 文件进行快速迭代或仅在 Python 中进行开发。 |
Python SDK v1 到 v2 的映射
请参阅以下每个文章，了解 SDK v1 与 v2 的代码映射比较。
| 资源和资产 | 文章 |
|---|---|
| 工作区 | SDK v1 和 SDK v2 中的工作区管理 |
| 数据存储 | SDK v1 和 SDK v2 中的数据存储管理 |
| 数据 | SDK v1 和 v2 中的数据资产 |
| 计算 | SDK v1 和 SDK v2 中的计算管理 |
| 培训 | 运行脚本 |
| 培训 | 本地运行 |
| 培训 | 超参数优化 |
| 培训 | 并行运行 |
| 培训 | 管道 |
| 培训 | AutoML |
| 模型 | SDK v1 和 SDK v2 中的模型管理 |
| 部署 | 将部署终结点升级到 SDK v2 |
v1 和 v2 中的资源和资产
本部分概述了 Azure 机器学习中的特定资源和资产。 有关每个实体在 v2 中的使用情况的详细信息，请参阅每个实体的概念文章。
工作区
工作区无需升级到 v2。 无论使用的是 v1 还是 v2，都可以使用相同的工作区。
如果使用自动化创建工作区，请考虑将用于创建工作区的代码升级到 v2。 Azure 资源通常通过 Azure 资源管理器（和 Bicep）或类似的资源预配工具进行管理。 或者，可以使用 CLI (v2) 和 YAML 文件。
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 SDK v2 中的工作区管理。
重要
如果工作区使用专用终结点，它将自动启用 v1_legacy_mode 标志，从而阻止使用 v2 API。 有关详细信息，请参阅如何使用 v2 配置网络隔离。
连接（v1 中的工作区连接）
v1 中的工作区连接保留在工作区中，并且在 v2 中完全可用。
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 SDK v2 中的工作区管理。
数据存储
使用 v1 创建的对象存储数据存储类型完全可用于 v2。 不支持数据库数据存储；导出到对象存储（通常是 Azure Blob）是推荐的迁移路径。
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 SDK v2 中的数据存储管理。
数据（v1 中的数据集）
数据集重命名为数据资产。 提供了向后兼容性，这意味着可以在 V2 中使用 V1 数据集。 在 V2 作业中使用 V1 数据集时，你会注意到它们会自动映射到 V2 类型，如下所示：
- V1 FileDataset = V2 文件夹 (
uri_folder) - V1 TabularDataset = V2 表 (
mltable)
应注意，未提供向前兼容性，这意味着无法在 V1 中使用 V2 数据资产。
本文详细介绍如何在 v2 中处理数据 - 在作业中读取和写入数据
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 v2 中的数据资产。
计算
AmlCompute 和 ComputeInstance 类型的计算完全可用于 v2。
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 SDK v2 中的计算管理。
作业（v1 中的试验、运行、管道）
在 v2 中，“试验”、“运行”和“管道”合并到作业中。 作业有不同类型。 大多数作业都是运行命令的 command 作业，如 python main.py。 作业中运行的内容与任何编程语言无关，因此你可以运行 bash 脚本、调用 python 解释器、运行一组 curl 命令或其他任何内容。 另一种常见的作业类型是 pipeline，它定义了可能具有输入/输出关系的子作业，形成有向无环图 (DAG)。
有关 SDK v1 和 v2 代码的比较，请参阅
Designer
可以使用设计器通过自己的 v2 自定义组件和注册表中的新预生成组件生成管道。 在这种情况下，可以在管道中使用 v1 或 v2 数据资产。
可以继续使用设计器通过经典预生成组件和 v1 数据集类型（表格、文件）生成管道。 不能将现有设计器经典预生成组件与 v2 数据资产配合使用。
不能使用现有的设计器经典预生成组件和 v2 自定义组件生成管道。
型号
从 v1 创建的模型可用于 v2。
有关 SDK v1 和 v2 代码的比较，请参阅 SDK v1 和 SDK v2 中的模型管理
终结点和部署（v1 中的终结点和 Web 服务）
使用 SDK/CLI v1，可以在 ACI 或 AKS 上部署模型作为 Web 服务。 现有的 v1 模型部署和 Web 服务会继续正常运行，但使用 SDK/CLI v1 在 ACI 或 AKS 上部署模型作为 Web 服务现在已被视为旧版。 对于新的模型部署，建议升级到 v2。 在 v2 中，我们提供托管终结点或 Kubernetes 终结点。 下表列出了我们的建议：
| v2 中的终结点类型 | 从 | 说明 |
|---|---|---|
| Local | ACI | 在本地快速测试模型部署；不用于生产。 |
| 托管联机终结点 | ACI、AKS | 企业级托管模型部署基础结构，具有准实时响应和大规模生产缩放。 |
| 托管批处理终结点 | 用于批量评分的管道中的 ParallelRunStep | 企业级托管模型部署基础结构，具有用于生产的大规模并行批处理。 |
| Azure Kubernetes 服务 (AKS) | ACI、AKS | 管理自己的 AKS 群集以进行模型部署，以 IT 开销为代价提供灵活性和精细控制。 |
| Azure Arc Kubernetes | 空值 | 在其他云或本地管理自己的 Kubernetes 群集，以 IT 开销为代价提供灵活性和精细控制。 |
有关 SDK v1 和 v2 代码的比较，请参阅将部署终结点升级到 SDK v2。 有关从现有 ACI Web 服务迁移到托管联机终结点的步骤，请参阅我们的升级指南文章和博客。
环境
从 v1 创建的环境可用于 v2。 在 v2 中，环境有了新的功能，例如从本地 Docker 上下文创建。
管理机密
与 V1 相比，V2 中密钥保管库机密的管理明显不同。 V1 set_secret 和 get_secret SDK 方法在 V2 中不可用。 应改用密钥保管库客户端库进行直接访问。 从训练脚本访问机密时，可以使用计算或标识的托管标识。
有关密钥保管库的详细信息，请参阅在 Azure 机器学习训练作业中使用身份验证凭据机密。
机器学习生命周期中的场景
在使用 Azure 机器学习的机器学习生命周期中，有一些常见的场景。 我们将探讨其中一些场景，并给出升级到 v2 的一般建议。
Azure 设置
Azure 建议使用 Azure 资源管理器模板（通常通过 Bicep 以便于使用）来创建资源。 这也是创建 Azure 机器学习资源的一个好方法。
如果你的团队仅使用 Azure 机器学习，则可以考虑改为通过 YAML 文件和 CLI 预配工作区和任何其他资源。
原型制作模型
对于原型制作模型，建议使用 v2。 如果你的模型训练代码是 Python 或任何其他编程语言，可以考虑使用 CLI 来交互式地使用 Azure 机器学习。 或者，你可以采用仅使用 Azure 机器学习 SDK 的 Python 的完整堆栈方法，或者采用 Azure 机器学习 Python SDK 和 YAML 文件的混合方法。
生产模型训练
建议使用 v2 进行生产模型训练。 作业整合了术语，并提供了一组一致性，允许更轻松地在类型之间转换（例如，command 到 sweep），以及一个对 GitOps 友好的进程，用于将作业序列化到 YAML 文件中。
使用 v2 时，应将机器学习代码与控制平面代码分开。 这种分离可以简化迭代，并允许在本地和云之间更轻松地转换。 我们还建议使用 MLflow 进行跟踪和模型日志记录。 有关详细信息，请参阅 MLflow 概念文章。
生产模型部署
建议使用 v2 进行生产模型部署。 托管终结点抽象了 IT 开销，并为联机（准实时）和批处理（大规模并行）场景的部署和评分模型提供了高性能解决方案。
v2 通过 AKS 支持 Kubernetes 部署，从而实现由组织管理的 Azure 云和本地部署。
机器学习运营 (MLOps)
MLOps 工作流通常通过外部工具涉及 CI/CD。 通常在 CI/CD 中使用 CLI，但也可以调用 Python 或直接使用 REST。
v2 中的 MLOps 解决方案加速器正在 https://github.com/Azure/mlops-v2 上开发，可用作参考或用于机器学习生命周期的设置和自动化。
关于使用 v2 的 GitOps 的说明
v2 的一个关键范例是使用 git 将机器学习实体序列化为 YAML 文件以进行源代码管理，从而实现比 v1 更好的 GitOps 方法。 例如，可以强制实施这样的策略，即只有 CI/CD 管道中使用的服务主体才能创建/更新/删除部分或所有实体，从而确保更改通过一个受治理的过程进行，如所需审阅者的拉取请求。 由于源代码管理中的文件是 YAML，因此很容易区分和跟踪一段时间内的更改。 升级到 v2 时，你和你的团队可能需要考虑转向这种范例。
可以通过 az ml <entity> show --output yaml 使用 CLI 获取任何实体的 YAML 表示形式。 此输出具有系统生成的属性，可以忽略或删除这些属性。
是否应将现有 v1 代码升级到 v2
可以在 v2 工作流中重用现有 v1 资产。 例如，在 v1 中创建的模型可用于在 v2 中执行托管推理。
（可选）如果要将现有 v1 代码的特定部分升级到 v2，请参阅本文档中提供的比较链接。
能否将 v1 和 v2 一起使用？
v1 和 v2 可以共存于工作区中。 可以在 v2 工作流中重用现有资产。 例如，在 v1 中创建的模型可用于在 v2 中执行托管推理。 工作区、计算和数据存储等资源可以跨 v1 和 v2 工作，但也有例外。 用户可以调用 v1 Python SDK 来更改工作区的说明，然后使用 v2 CLI 扩展再次更改它。 可以通过 v1 或 v2 Python SDK 将作业（v1 中的试验/运行/管道）提交到相同的工作区。 工作区可以同时具有 v1 和 v2 模型部署终结点。
结合使用 v1 和 v2 代码
不建议在同一代码中同时使用 v1 和 v2 SDK。 从技术上讲，可以在同一代码中使用 v1 和 v2，因为它们使用不同的 Azure 命名空间。 但是，这些命名空间中有许多具有相同名称的类（如 Workspace、Model），这可能会导致混淆，并使代码的可读性和可调试性具有挑战性。
重要
如果工作区使用专用终结点，它将自动启用 v1_legacy_mode 标志，从而阻止使用 v2 API。 有关详细信息，请参阅如何使用 v2 配置网络隔离。