阶段 7：规划基础结构即代码方法

在此阶段，你将设计基础结构即代码（IaC）策略，以自动部署和管理Azure Databricks资源。

基础结构即代码工具是启动和管理Azure Databricks工作区的建议方法。 每个云都有自己的 IaC 工具，还有一些与云无关的工具。

选择基础结构即代码工具

Terraform 是跨行业提供大量支持的第三方 IaC 工具。 它是最受欢迎的第三方 IaC 工具，拥有 Azure Databricks 官方支持的 Terraform 提供程序。 terraform.io 中的 Terraform 提供程序文档提供了示例和指南，可帮助你快速入门。

Terraform 功能

  • 管理Azure Databricks帐户资源（例如工作区、网络、存储配置）。
  • 管理工作区资源（例如集群、作业、笔记本、Unity Catalog 资源）。
  • 与云无关：适用于 AWS、Azure 和 GCP，语言相同。
  • 具有模块和最佳做法的大型生态系统。
  • Azure Databricks的官方支持。

Terraform 部署模式

  • 帐户级基础结构：工作区、网络、存储凭据、元存储。
  • 工作区级别配置：群集策略、实例池、工作区设置。
  • Unity 目录资源：目录、架构、外部位置、存储凭据。
  • 笔记本和存储库：将笔记本和 Git 存储库部署到工作区。
  • Secrets：管理Azure Databricks秘密域中的机密。

Terraform 的最佳做法

  • 使用 Terraform 模块为组织创建可重用模式。
  • 将 Terraform 状态存储在远程后端（例如 S3、Azure Blob Storage、GCS）中，并具有状态锁定。
  • 使用 Terraform 工作区或单独的状态文件来隔离不同环境（例如开发、测试、生产）。
  • 使用 Terraform 变量和 tfvars 文件参数化配置。
  • 在应用更改之前，在 CI/CD 管道中启用计划评审。
  • 一致地标记所有资源，以便进行成本归因和治理。
  • 记录模块和维护模块注册表。
  • 使用官方的 Azure Databricks Terraform 提供者示例作为起点。

有关 Terraform 提供程序文档和示例，请参阅 Azure Databricks Terraform 注册表。

声明性自动化捆绑包是Azure Databricks的第一方基础结构即代码工具，可实现数据与 AI 资源的一致打包和部署。 它提供官方支持，并与Azure Databricks工作区集成。

声明性自动化功能集

  • 部署作业、管道和笔记本。
  • 部署和管理 ML 模型。
  • 跨环境管理部署（例如开发、暂存、生产）。
  • 源代码管理与 Git 集成。
  • CI/CD 与 GitHub Actions、Azure DevOps、GitLab CI 的集成。
  • 常见模式的模板化。

声明性自动化捆绑包用例

  • 部署数据工程工作流和 Lakeflow Spark 声明性管道。
  • 部署机器学习工作流和为终结点提供服务的模型。
  • 部署笔记本和 SQL 查询。
  • 管理环境特定的配置。
  • 自动化将开发环境升级到演示环境，再到生产环境。

声明式自动化包的最佳实践

  • 请使用声明性自动化捆绑包来处理数据和 AI 工作负载，例如作业、管道、模型。
  • 将 Terraform 用于基础结构资源（例如工作区、网络、Unity 目录）。
  • 请使用“声明式自动化包模板”来处理常见用例。
  • 与用于自动部署的 CI/CD 管道集成。
  • 使用特定于环境的配置进行开发/暂存/生产。
  • Git 中的版本控制捆绑包定义。

有关声明性自动化捆绑包文档，请参阅 什么是声明性自动化捆绑包？。

云原生基础设施代码化工具

每个云提供商都提供用于管理云资源的原生 IaC 工具。 这些工具可以与 Terraform 一起使用，以补充特定于云的基础设施。

Azure Resource Manager （ARM） 模板和Bicep

Azure使用 Azure Resource Manager （ARM） 模板自动启动、管理和销毁基础结构。 ARM 模板有助于在Azure资源级别预配工作区和所有工作区级别设置，但工作区内的任何配置（例如群集创建、群集策略和 Unity 目录对象）都无法使用 ARM 完成。

Bicep功能

作为 ARM 的替代方法，Bicep模板还可用于部署Microsoft Azure Databricks工作区。 Bicep为 ARM 提供了简化的模块化模板，用于Azure资源部署。

最佳实践：对 Azure 基础结构（例如工作区、VNet、存储帐户）使用 ARM/Bicep，但对 Azure Databricks 工作区配置和 Unity Catalog 资源使用 Terraform。

有关示例 ARM/Bicep 模板，请参阅 Azure Databricks Azure 示例存储库。

设计部署方法

订阅和帐户设置

在执行任何自动化或手动创建任何工作区之前，第一步是订阅云提供商上的Azure Databricks。

Azure 订阅

Microsoft Azure Databricks是第一方Azure服务。 拥有参与者权限的用户可以创建一个 Microsoft Azure Databricks 工作区，如果他们在订阅或资源组中拥有该权限。 虽然可以使用标准资源部署方法创建工作区，但若要使用 Unity 目录，Azure全局管理员必须首次激活帐户控制台。

使用管理工作区进行引导初始化

在执行任何自动化或手动创建任何工作区之前，第一步是在每个所需区域中生成一个工作区，仅用于管理目的（数据平台用户不应有权访问该工作区）。

建立管理工作区的主要原因

  • Unity 目录 API：Unity 目录 API 主要是工作区 API - 若要创建目录、位置等，则需要工作区。
  • 管理任务：用于通过使用系统表来运行仪表板、运行安全分析工具（SAT）和执行其他管理操作。
  • 自动化中心：用于运行 Terraform、声明性自动化捆绑包和其他自动化工具的中心位置。
  • Azure Private Link：在具有Private Link的Azure中，Azure Databricks建议为每个区域创建专用 Web 身份验证工作区。

管理工作区的最佳做法

  • 为每个区域创建一个管理工作区。
  • 仅限制对平台管理员的访问。
  • 将此工作区用于 Unity 目录管理和系统表查询。
  • 在此工作区中部署自动化工具（例如声明性自动化捆绑包、Terraform 执行器）。
  • 记录用途和访问限制。

设计部署模式

模式 1：工作区部署模式

为映射到角色和用例的常见工作区部署模式创建 Terraform 模块。

示例工作区模式

  • ** 数据工程工作区：经典计算，客户管理的虚拟私有云 (VPC)，已启用 Lakeflow Spark 声明性数据管道。
  • 分析工作区：无服务器计算、SQL 仓库、BI 集成。
  • ML 工作区：已启用 GPU 群集、ML 运行时、MLflow。
  • 生产工作区：高可用性、专用链接、客户管理的密钥。

优点

  • 跨环境一致部署。
  • 减少了配置错误。
  • 加快新工作区的预配速度。
  • 按角色明确分离关注点。

模式 2：环境提升模式

创建用于将工作负载从开发环境推广到过渡环境再到生产环境的模式。

环境升级工作流

  1. 开发：使用具有开发配置的声明性自动化捆绑包部署到开发工作区
  2. 暂存：推广到暂存工作区，运行集成测试
  3. 生产：批准后转移到生产工作区

最佳实践

  • 将声明性自动化捆绑包用于特定于环境的配置。
  • 通过 CI/CD 管道自动化推广。
  • 需要为生产部署设置审批检查点。
  • 在生产上线之前应在测试环境进行测试。

模式 3：可重用模块模式

生成 Terraform 模块库作为常见模式的构建基块。

示例模块

  • 工作区模块：使用网络、存储和 Unity 目录附件部署工作区。
  • Unity Catalog 模块：创建包含模式和权限的目录。
  • 群集策略模块：为不同的团队或用例定义群集策略。
  • 网络模块：创建包含子网、NAT 和防火墙规则的VP/VNet。

优点

  • 减少代码重复。
  • 建立组织标准。
  • 简化维护和更新。
  • 为团队启用自助服务。

基础结构即代码建议

推荐

  • 尽可能使用 IaC 工具启动工作区和基础结构。
  • 将 Terraform 用于基础结构资源（例如工作区、网络、Unity 目录、存储）。
  • 对数据和 AI 工作负载使用声明式自动化捆绑包（例如，作业、管道、笔记本、模型）。
  • 使用可用于每个云的现有模式（Terraform 提供程序示例）。
  • 在每个所需区域中生成一个管理工作区。
  • 创建映射到角色和用例的可重用 Terraform 模块。
  • 将 IaC 状态存储在具有状态锁定的远程后端中。
  • 将 IaC 部署与 CI/CD 管道集成。
  • 记录部署模式和模块使用情况。
  • 在所有资源中使用一致的标记。

避免这些模式

  • 不要在生产环境中手动创建工作区（使用 IaC 实现可重复性）。
  • 不要在本地存储 Terraform 状态（使用远程后端）。
  • 请勿在没有计划评审的情况下进行部署（在 CI/CD 中启用计划审批）。
  • 不要混合 IaC 和手动配置（选择一种方法）。
  • 避免创建具有独特配置的“雪花”工作区。

阶段 7 结果

完成阶段 7 后，应具备：

  • 已选择 IaC 工具策略（适用于基础设施的 Terraform、工作负载的声明式自动化包）。
  • 定义的云原生 IaC 工具使用情况（例如 CloudFormation、ARM/Bicep）。
  • 订阅和帐户设置方案已规划。
  • 定义的管理工作区设计（每个区域一个）。
  • 设计的部署模式（例如工作区模式、环境升级、可重用模块）。
  • 计划构建 Terraform 模块库（例如，工作区、Unity Catalog、网络模块、集群策略模块）。
  • 为 IaC 部署定义的 CI/CD 集成策略。
  • 设计远程状态管理策略（例如 S3、Azure Blob、GCS）。
  • 为 IaC 托管的资源定义的标记和命名标准。

下一阶段：阶段 8：设计计算配置

实施指南：有关实现 IaC 策略的分步说明，请参阅 Databricks Terraform 提供程序 和 什么是声明性自动化捆绑包？。

  • Last updated on