布朗尼·詹姆斯未来的家

有一段时间没写关于Databricks 资产包 (DABs) 的内容了。我抽空开始将我们的一些基本作业迁移到我们的 Unity Catalog 空间，在我们平台团队那边要求使用 DABs 或类似的标准来创建生产环境中的作业，于是开始认真对待这个问题了。以下是我学到了的一些东西。

我这样组织我的配置存储库：

• 资源文件夹中的每个任务都有自己的 YAML 文件，用于在开发环境中运行该任务所需的配置。
• 开发环境位于与生产环境不同的工作区，在必要时使用变量来区分开发和生产环境（例如集群 ID、服务主体 ID 等）。
• 所有生产任务的覆盖配置都在 databricks.yml 文件中的 prod 目标下指定。

不同的目标让我们很容易将我们在开发环境中想要的所有设置（如集群大小、任务详情等）从开发环境迁移到目标环境，并且只需要在生产环境中覆盖必要的内容（如集群策略ID、webhook等）。就任务配置本身而言，复制旧Databricks实例中的配置作为模板非常简单。总的来说，比原先想象的要简单得多。

注意事项

当然，就像我在这次Unity迁移过程中学到的所有事情一样，这项工作并非没有需要注意的问题。一些设置会从开发环境带到正式环境，并不是所有的参数在部署到不同的目标时都会被重写。我注意到的两个例子是参数和webhook，例如webhook。

工作参数无法复制也不至于大问题，因为我们可以通过改用任务参数来解决（它们之间有什么区别？我在一篇最近的文章中详细讨论了参数化）。不过，无法使用webhooks让人感到不爽，因为这迫使我们在开发阶段放弃webhooks，只能在生产环境中继续使用它们（这一点上没有商量余地）。我认为这可能是因为在Databricks中这些参数集是以列表形式而不是字典形式表示的，而列表的自然行为是追加而非覆盖。如果你在目标中使用变量，可以绕过这一问题，我一开始并没有立刻想到这一点，后来发现这就是解决方案。

另一个需要注意的地方是，您一次不能单独部署捆绑包中的单个工作。默认情况下，所有工作都会一起部署，因此，请确保您的更改不会影响需要保持原样的工作。总的来说，这些是迄今为止我遇到的最大问题，这表明一切都在顺利进行中。

从开始使用DAB以来，我最大的收获是什么？

• 尽可能多地使用变量，便于对任务进行批量更改。
• 使用验证选项在部署捆绑包之前进行合理性验证（这是捕获错误的好方法）。
• 与 CI/CD 集成，以便在提交时自动更新。

我期待的那个最后的部分，这对管理我们工作非常有帮助。目前，我仅通过命令行来处理，通过GitHub Actions或Jenkins工作流来执行这一步会更好。

最后就是结论了

对于真正希望在其 Databricks 开发中采用严格工程实践的用户而言，DAB 是最佳选择。尽管这个功能才推出不到一年，它表现得非常不错。我期待看到它会如何继续改进。