你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
建议在 Microsoft Azure 中使用云规模分析来将数据科学项目付诸实践,并采用这些最佳做法。
开发模板
开发一个模板,用于捆绑一组数据科学项目的服务。 使用捆绑一组服务的模板来帮助跨各种数据科学团队的用例提供一致性。 建议以模板存储库的形式开发一致的蓝图。 可以将此存储库用于企业内的各种数据科学项目,以帮助缩短部署时间。
数据科学模板指南
使用以下准则为组织开发数据科学模板:
开发一组基础结构即代码(IaC)模板来部署 Azure 机器学习工作区。 包括密钥保管库、存储帐户、容器注册表和 Application Insights 等资源。
包括这些模板中的数据存储和计算目标的设置,例如计算实例、计算群集和 Azure Databricks。
部署最佳做法
实时
- 在模板和 Azure AI 服务中包含 Azure 数据工厂或 Azure Synapse 部署。
- 模板应提供执行数据科学探索阶段和模型初始作所需的所有工具。
初始设置注意事项
在某些情况下,组织中的数据科学家可能需要一个环境来快速进行按需分析。 如果未正式设置数据科学项目,则这种情况很常见。 例如,在 Azure 中可能缺少项目经理、成本代码或成本中心,这些可能在交叉收费中是必需的,因为这些缺失的元素需要审批。 组织或团队中的用户可能需要访问数据科学环境来了解数据,并评估项目的可行性。 此外,由于少量的数据产品,某些项目可能不需要完整的数据科学环境。
在其他情况下,可能需要完整的数据科学项目,并完成专用环境、项目管理、成本代码和成本中心。 全面的数据科学项目对于想要协作、共享结果,并在探索阶段成功后需要将模型投入应用的多个团队成员非常有用。
设置过程
设置模板后,应按项目部署模板。 每个项目应至少接收两个实例,以便将开发和生产环境分开。 在生产环境中,不应有个人访问权限,所有内容都应通过持续集成或持续开发管道和服务主体进行部署。 这些生产环境原则很重要,因为 Azure 机器学习在工作区中不提供基于角色的精细访问控制模型。 不能限制用户访问特定的一组试验、终结点或管道。
相同的访问权限通常适用于不同类型的工件。 务必要将开发与生产环境严格区分,以防止误删除工作区中的生产管道或终结点。 除了模板,还需要生成一个过程,以便数据产品团队可以选择请求新环境。
我们建议基于每个项目设置不同的 AI 服务,例如 Azure AI 服务。 通过为每个项目设置不同的 AI 服务,将针对每个数据产品资源组进行部署。 此策略从数据访问的角度明确分离,并缓解了错误团队未经授权的数据访问的风险。
流式场景
对于实时和流式处理用例,应在缩减的 Azure Kubernetes 服务(AKS)上测试部署。 测试可以在开发环境中节省成本,然后再部署到用于容器的生产 AKS 或 Azure 应用服务。 应执行简单的输入和输出测试,以确保服务按预期响应。
接下来,可以将模型部署到所需的服务。 此部署计算目标是唯一一个正式发布,建议用于 AKS 群集中的生产工作负荷。 如果需要图形处理单元(GPU)或现场可编程门阵列支持,则此步骤更为必要。 支持这些硬件要求的其他本机部署选项目前在 Azure 机器学习中不可用。
Azure 机器学习需要一对一映射到 AKS 群集。 与 Azure 机器学习工作区的每个新连接都会中断 AKS 和 Azure 机器学习之间的先前连接。 缓解该限制后,建议将中央 AKS 群集部署为共享资源,并将其附加到各自的工作区。
如果在将模型移动到生产 AKS 之前应执行压力测试,则应托管另一个中心测试 AKS 实例。 测试环境应提供与生产环境相同的计算资源,以确保结果与生产环境类似。
批处理场景
并非所有用例都需要 AKS 群集部署。 如果大量数据仅需要定期评分或基于事件,则用例不需要 AKS 群集部署。 例如,大量数据可以根据数据存入特定存储帐户的时机来判断。 在这些类型的方案中,应使用 Azure 机器学习管道和 Azure 机器学习计算群集进行部署。 应在数据工厂中协调和执行这些管道。
确定正确的计算资源
在 Azure 机器学习中将模型部署到 AKS 之前,用户需要指定应为相应模型分配的 CPU、RAM 和 GPU 等资源。 定义这些参数可能是一个复杂而繁琐的过程。 需要使用不同的配置执行压力测试,以识别一组良好的参数。 可以使用 Azure 机器学习中的 模型分析 功能简化此过程,该功能是一项长时间运行的作业,用于测试不同的资源分配组合,并使用已识别的延迟和往返时间(RTT)来推荐最佳组合。 此信息可以帮助 AKS 上的实际模型部署。
为了在 Azure 机器学习中安全地更新模型,团队应使用受控推出功能(预览版)来最大程度地减少停机时间,并使模型的 REST 终结点保持一致。
MLOps 的最佳做法和工作流
在数据科学存储库中包含示例代码
如果你的团队拥有相关的制品和最佳实践,则可以简化和加速数据科学项目。 建议创建可以在使用 Azure 机器学习和数据产品环境的各自工具时供所有数据科学团队使用的工件。 数据和机器学习工程师应创建并提供工件。
这些工件应包括:
示例笔记本展示如何:
- 加载、装载和使用数据产品。
- 记录和保存指标及参数。
- 将训练作业提交到计算群集。
运营化所需的工件:
- 示例 Azure 机器学习管道
- 示例 Azure Pipelines
- 执行管道所需的更多脚本
Documentation
使用设计良好的工件来操作化管道
工件可以加快数据科学项目的探索和操作实施阶段。 DevOps 分支策略可帮助跨所有项目扩展这些工件。 由于此设置可提升 Git 的使用,因此用户和整个自动化过程可以从提供的项目中受益。
小窍门
应使用 Python 软件开发人员工具包(SDK)或基于 YAML 语言生成 Azure 机器学习示例管道。 新的 YAML 体验将更具未来性,因为 Azure 机器学习产品团队目前正在开发新的 SDK 和命令行界面(CLI)。 Azure 机器学习产品团队确信 YAML 将充当 Azure 机器学习中所有项目的定义语言。
示例管道不适用于每个项目,但可用作基线。 可以调整项目的示例管道。 管道应包含每个项目最相关的方面。 例如,管道可以引用计算目标、引用数据产品、定义参数、定义输入以及定义执行步骤。 应为 Azure Pipelines 完成相同的过程。 Azure Pipelines 还应使用 Azure 机器学习 SDK 或 CLI。
管道应演示如何:
- 从 DevOps 管道内连接到工作区。
- 检查所需的计算是否可用。
- 提交作业。
- 注册并部署模型。
产出组件并不总是适合所有项目,可能需要自定义,但拥有一个基础可以加快项目的运营和部署速度。
构建 MLOps 存储库
用户可能会遇到无法找到和存储工件的位置的情况。 为了避免这些情况,应请求更多时间来通信和构造标准存储库的顶级文件夹结构。 所有项目都应遵循文件夹结构。
注释
本部分中提到的概念可以跨本地、Amazon Web Services、Palantir 和 Azure 环境使用。
下图演示了 MLOps(机器学习操作)库推荐的顶层文件夹结构:
以下用途适用于存储库中的每个文件夹:
| 文件夹 | 目的 |
|---|---|
.cloud |
在此文件夹中存储特定于云的代码和项目。 工件包括 Azure 机器学习工作区的配置文件,包括计算目标定义、作业、已注册的模型和端点。 |
.ado/.github |
在此文件夹中存储 Azure DevOps 或 GitHub 项目,例如 YAML 管道或代码所有者。 |
code |
在此文件夹中包括作为项目一部分开发的实际代码。 此文件夹可以包含 Python 包和一些脚本,这些脚本用于机器学习管道的相应步骤。 建议分离需要在此文件夹中完成的各个步骤。 常见步骤包括 预处理、 模型训练和 模型注册。 定义每个文件夹的依赖项,例如 Conda 依赖项、Docker 映像或其他依赖项。 |
docs |
将此文件夹用于文档目的。 此文件夹存储 Markdown 文件和图像来描述项目。 |
pipelines |
将此文件夹中的 Azure 机器学习管道定义存储在 YAML 或 Python 中。 |
tests |
编写需要执行的单元和集成测试,以发现此文件夹中项目早期出现的 bug 和问题。 |
notebooks |
使用此文件夹将 Jupyter 笔记本与实际的 Python 项目分开。 在该文件夹中,每个人都应有一个子文件夹,以检查他们的笔记本和防止 Git 合并冲突。 |