声明性自动化捆绑包常见问题解答

本文列出了有关声明性自动化捆绑包（以前称为 Databricks 资产捆绑包）的常见问题。

为什么 Databricks 资产捆绑包重命名为声明性自动化捆绑包（Declarative Automation Bundles）？

新的名称声明性自动化捆绑包更准确地反映了捆绑包的用法和功能。 此外，术语 资产 引起了一些混淆，因为它在 Databricks 中具有多个含义。 此名称更改是非破坏性的。 bundle不需要修改 CLI 命令和所有现有配置。

如何在 Azure Databricks 上使用声明性自动化捆绑包作为 CI/CD 管道的一部分？

可以使用 Declarative Automation Bundles 在 Azure Databricks CI/CD 实现中定义和管理资产，这通常包括：

• Notebooks：Azure Databricks笔记本通常是数据工程和数据科学工作流的关键部分。 可以对笔记本使用版本控制，还可以在 CI/CD 管道中验证和测试它们。 可以针对笔记本运行自动测试，以检查它们是否按预期运行。
• 库：管理运行已部署代码所需的 库依赖项 。 对库使用版本控制，并将其包含在自动测试和验证中。
• 工作流： Lakeflow 作业 由作业组成，可用于使用笔记本或 Spark 作业计划和运行自动化任务。
• 数据管道：还可以在 CI/CD 自动化中包含数据管道，使用 Lakeflow Spark 声明性管道（用于声明数据管道的 Databricks 中的框架）。
• 基础结构：基础结构配置包括针对目标环境的群集、工作区和存储的定义和预配信息。 基础结构更改可以作为 CI/CD 管道的一部分进行验证和测试，确保它们一致且无错误。

为什么需要单独的开发和生产目标环境？

通过分别设置开发环境和生产环境，可以：

• 安全地隔离开发更改，以免意外影响生产。
• 通过自定义要应用于特定目标环境的资源来防止代码重复。
• 使用特定于环境的配置简化 CI/CD，例如数据库路径、警报和访问控制。
• 跨团队和环境重复使用工作流。

使用目标定义捆绑部署环境。 请参阅目标。

如何使我的软件包在整个组织中保持一致性？

使用捆绑模板实现一致的结构、减少设置错误并提升最佳做法。 可以使用默认捆绑模板，也可以创建自己的自定义捆绑包模板。 请参阅 声明性自动化捆绑包项目模板。

我的软件包中有很多重复，例如相同的群集定义。 处理此问题的最佳方式是什么？

自定义变量是处理重复以及特定于上下文的设置的最佳方法。 请参阅 自定义变量。

在部署流中使用捆绑包时，有哪些最佳做法？

Databricks 建议：

• 使用 Git 集成工作流从手动部署转移到可靠的自动化。
• 在 CI/CD 管道中使用 databricks bundle validate 捆绑包之前进行验证。
• 独立的部署步骤，以确保更改经过审查并是有意的。
• 参数化环境（开发、暂存、生产），并采用替代来隔离更改。
• 在部署后运行集成测试以提前捕获问题。
• 使用 GitHub Actions、Azure DevOps 或 GitLab CI 在提交或 PR 合并时触发部署。
• 跟踪部署的内容、位置和时间，以便每个部署都映射到提交和捆绑版本。

是否可以将现有作业、管道、仪表板和其他 Databricks 对象移植到我的捆绑包中？

是的。 使用databricks bundle generate 命令为本地包中的现有作业、管道或控制台生成配置文件，然后使用databricks bundle deployment bind 将捆绑包资源绑定到工作区中的相应资源。 这非常适合将现有工作流载入结构化版本控制开发。 绑定还会解析绝对工作区引用的相对路径，从而避免路径错误。

请参阅 将现有资源迁移到捆绑包。

如何以迭代方式测试包？

通过迭代式部署和运行，您可以更快速地进行开发：

• 在部署之前进行验证
• 以增量方式部署
• 仅运行所需的内容
• 编辑和重复

这会加速测试和调试，减少上下文切换，在无需完全重新部署的情况下实现更安全、更快的迭代，并在转向生产时强制实施规则。