本文列出了有关 Databricks 资产捆绑包的常见问题。
如何在 Azure Databricks 上使用 Databricks 资产捆绑包作为 CI/CD 管道的一部分？
可以使用 Databricks 资产捆绑包在 Azure Databricks CI/CD 实现中定义和管理资产，这通常包括：
- 笔记本：Azure Databricks 笔记本通常是数据工程和数据科学工作流的关键部分。 可以对笔记本使用版本控制，还可以在 CI/CD 管道中验证和测试它们。 可以针对笔记本运行自动测试，以检查它们是否按预期运行。
- 库：管理运行已部署代码所需的 库依赖项 。 对库使用版本控制，并将其包含在自动测试和验证中。
- 工作流： Lakeflow 作业 由作业组成，可用于使用笔记本或 Spark 作业计划和运行自动化任务。
- 数据管道：还可以使用 Lakeflow 声明性管道（Databricks 中用于声明数据管道的框架）在 CI/CD 自动化中包含数据管道。
- 基础结构：基础结构配置包括针对目标环境的群集、工作区和存储的定义和预配信息。 基础结构更改可以作为 CI/CD 管道的一部分进行验证和测试，确保它们一致且无错误。
为什么需要单独的开发和生产目标环境？
通过分别设置开发环境和生产环境，可以：
- 安全地隔离开发更改，以免意外影响生产。
- 通过自定义要应用于特定目标环境的资源来防止代码重复。
- 使用特定于环境的配置简化 CI/CD，例如数据库路径、警报和访问控制。
- 跨团队和环境重复使用工作流。
使用目标定义捆绑部署环境。 请参阅目标。
如何使我的软件包在整个组织中保持一致性？
使用捆绑模板实现一致的结构、减少设置错误并提升最佳做法。 可以使用默认捆绑模板，也可以创建自己的自定义捆绑包模板。 请参阅 Databricks 资产捆绑包项目模板。
我的软件包中有很多重复，例如相同的群集定义。 处理此问题的最佳方式是什么？
自定义变量是处理重复以及特定于上下文的设置的最佳方法。 请参阅 自定义变量。
在部署流中使用捆绑包时，有哪些最佳做法？
Databricks 建议：
- 使用 Git 集成工作流从手动部署转移到可靠的自动化。
- 在 CI/CD 管道中使用
databricks bundle validate捆绑包之前进行验证。 - 独立的部署步骤，以确保更改经过审查并是有意的。
- 参数化环境（开发、暂存、生产），并采用替代来隔离更改。
- 在部署后运行集成测试以提前捕获问题。
- 使用 GitHub Actions、Azure DevOps 或 GitLab CI 在提交或 PR 合并时触发部署。
- 跟踪部署的内容、位置和时间，以便每个部署都映射到提交和捆绑版本。
是否可以将现有作业、管道、仪表板和其他 Databricks 对象移植到我的捆绑包中？
是的。 使用databricks bundle generate 命令为本地包中的现有作业、管道或控制台生成配置文件，然后使用databricks bundle deployment bind 将捆绑包资源绑定到工作区中的相应资源。 这非常适合将现有工作流载入结构化版本控制开发。 绑定还会解析绝对工作区引用的相对路径，从而避免路径错误。
请参阅 将现有资源迁移到捆绑包。
如何以迭代方式测试包？
通过迭代式部署和运行，您可以更快速地进行开发：
- 在部署之前进行验证
- 以增量方式部署
- 仅运行所需的内容
- 编辑和重复
这会加速测试和调试，减少上下文切换，在无需完全重新部署的情况下实现更安全、更快的迭代，并在转向生产时强制实施规则。