使用 Git 和 Databricks Git 文件夹 (Repos) 的 CI/CD 技术

了解在 CI/CD 工作流中使用 Databricks Git 文件夹的技术。 通过在工作区中配置 Databricks Git 文件夹,可以对 Git 存储库中的项目文件使用源代码管理,并且可以将它们集成到数据工程管道中。

开发 Git 文件夹自动化的大部分工作主要集中在文件夹的初始配置,以及了解用于自动化 Azure Databricks 作业中的 Git操作的 Azure Databricks Repos REST API。 在开始构建自动化和设置文件夹之前,请查看将纳入自动化流的远程 Git 存储库,并为自动化的不同阶段(包括开发、集成、过渡和生产)选择合适的存储库。

下图概述了使用 Azure Databricks Git 文件夹实现自动化的基本流。 其中,有一些生产文件夹、用户文件夹和自动化是使用 Azure Databricks 作业生成的,这些作业在触发时运行笔记本代码。

用于 Git 文件夹的 CI/CD 技术的概述。

  • 管理工作流:对于生产流,Azure Databricks 工作区管理员必须在工作区中设置顶级文件夹。 管理员在创建 Git 存储库时克隆一个 Git 存储库和分支,并应为这些文件夹提供有意义的名称,例如“生产”、“测试”或“暂存”,这些名称对应于远程 Git 存储库在开发流中的目的。 有关详细信息,请参阅本主题中的 生产 Git 文件夹
  • 用户工作流:用户可以基于远程 Git 存储库创建 Git 文件夹 /Volumes/Users/<email>/ 。 用户必须为用户提交的工作创建本地用户特定的分支,并将其推送到远程存储库。 有关在用户特定的 Git 文件夹中进行协作的信息,请参阅本主题中的 “使用 Git 文件夹进行协作 ”。
  • 合并工作流:用户可以从任何文件夹中创建拉取请求(PR),从而触发 Azure Databricks 作业自动化,以调用 Azure Databricks Repos API 来测试和处理其更改。 还可以使用 Azure Databricks Repos API 将这些更改推送到生产 Git 文件夹的“主”分支。

有关使用 Azure Databricks 的 CI/CD 的更全面概述,请参阅 Azure Databricks 上的 CI/CD

选择 Git 文件夹配置

有两种类型的 Azure Databricks Git 文件夹,它们根据工作区中的使用模式和位置进行区分:

  • 用户级文件夹。 当用户在 Azure Databricks UI 中克隆远程存储库以创建 Git 文件夹时,Git 文件夹默认在其个人文件夹中 /Workspace/Users/<email>/ 创建。 用户级文件夹用于个人开发。 可以将用户文件夹中的 Databricks Git 文件夹视为特定于每个用户的“本地签出”,用于用户修改代码和推送更改的地方。

  • 生产文件夹。 Azure Databricks 管理员在用户工作区之外创建了一个生产文件夹,该文件夹托管来自支持的 Git 存储库的生产分支。 它主要用于部署自动化,并且只能在 PR 合并到后盾分支时更新。

  • 如果尚未准备好采用 Databricks 资产捆绑包 ,但希望代码进行源代码管理,则可以设置生产 Git 文件夹。 使用自动化将它与远程 Git 存储库和分支保持 up-to日期。 这可以通过以下两种方式之一完成:

    1. 使用外部 CI/CD 工具(如 GitHub Actions)将最新提交拉取到生产 Git 文件夹,并创建对远程 Git 存储库和分支的合并请求。
    2. 创建定期任务,以使用生产 Git 文件夹的当前状态刷新工作区中的其他 Git 文件夹。

小窍门

Databricks 资产捆绑包可用于在源文件中定义作业和管道等资源,可以在工作区的 Git 文件夹中创建、部署和管理。

使用 Git 文件夹进行协作

可以使用 Git 文件夹轻松与他人协作,直接从 Azure Databricks UI 拉取更新和推送更改。 例如,使用特性分支或开发分支来聚合跨多个贡献者分支所做的更改。

以下流程描述了如何使用一个基于feature-b分支的main功能分支进行协作。

  1. 将现有 Git 存储库克隆到 Databricks 工作区

  2. 使用 Git 文件夹 UI 从主分支创建功能分支。 为简单起见,此示例使用了单个功能分支 feature-b。 可以创建并使用多个功能分支来完成工作。

  3. 对存储库中的 Azure Databricks 笔记本和其他文件进行修改。

  4. 提交更改并将其推送到远程 Git 存储库

  5. 参与者现在可将 Git 存储库克隆到其自己的用户文件夹中。

    1. 某位同事在新分支上工作,并对 Git 文件夹中的笔记本和其他文件进行更改。

    2. 参与者 提交并推送其更改到远程 Git 存储库

  6. 若要合并来自其他分支的更改,或在 Databricks 的 Git 文件夹界面中变基 feature-b 分支,请使用以下之一:

  7. 当你准备好将工作合并到远程 Git 存储库和 main 分支时,请使用 Git 文件夹界面来合并来自 feature-b 的更改。 如果愿意,可以改为直接将更改合并到支持 Git 文件夹的 Git 存储库。

注意

Databricks 建议每个开发人员在其自己的功能分支上工作。 有关如何解决合并冲突的信息,请参阅解决合并冲突

生产环境 Git 文件夹

生产文件夹是指定用于生产和部署的 Git 文件夹。 可以在用户文件夹中创建或在\Workspace下创建团队文件夹,例如\Workspace\Production。 Azure Databricks 建议创建生产特定的 Git 文件夹。

生产文件夹是从远程存储库创建的,这些分支用于聚合更改或表示生成和部署自动化中的不同阶段,并具有限制用户直接提交内容的权限。 对于生产 Git 文件夹,限制用户对只读的访问权限,只允许管理员和 Azure Databricks 服务主体编辑其内容。 支持它的远程 Git 存储库和分支应该是专门为生产就绪代码和资产指定的存储库和分支。

Git生产文件夹映射到远程存储库中的主分支。

创建 Git 生产文件夹:

  1. 选择专用于代码和资产生产和部署的 Git 存储库和分支。 为存储库配置服务主体身份验证并限制任何 Git 用户权限,以便组织外部的用户无法轻松更改源。

  2. 为专用于项目或团队的 Git 存储库和分支下 Workspace 或子文件夹创建 Azure Databricks Git 文件夹。 为它提供一个易于识别的名称,例如“生产”或“部署”。

  3. 在选择文件夹后或在工作区树下右键单击文件夹,选择共享共享(权限)。 使用以下权限配置 Git 文件夹:

    • 为必须从该文件夹中运行笔记本或其他代码的任何项目用户设置 “可运行 ”。
    • 为任何将运行其自动化的 Azure Databricks 服务主体帐户设置 “可运行”
    • 如果适合项目,请为工作区中的所有用户设置 “可查看” ,以鼓励发现和共享。

    “共享 Git 文件夹模式”对话框窗口。

  4. 选择 并添加

生产作业工作流

Databricks Git 文件夹提供两个用于运行生产作业的选项:

  • 选项 1:在作业定义中提供远程 Git 引用。 例如,在 Git 存储库的 main 分支中运行特定笔记本。
  • 选项 2:设置生产 Git 存储库并调用 Repos API 以编程方式更新该存储库。 针对克隆此远程存储库的 Databricks Git 文件夹运行作业。 Repos API 调用应该是作业中的第一个任务。

选项 1:使用远程存储库中的笔记本运行作业

通过使用远程 Git 存储库中的笔记本运行 Azure Databricks 作业,来简化作业定义过程并保留单一事实源。 此 Git 引用可以是 Git 提交、标记或分支,由你在作业定义中提供。

这有助于防止对生产作业进行意外更改,例如,当用户在生产存储库中进行本地编辑或切换分支时。 这样还可以自动完成 CD 步骤,因为你不需要在 Databricks 中创建单独的生产 Git 文件夹、管理其权限并使其保持更新状态。

请参阅将 Git 与作业配合使用

选项 2:设置生产 Git 文件夹和 Git 自动化

此选项设置生产 Git 文件夹和自动化,以便在合并时更新 Git 文件夹。

步骤 1:设置顶级文件夹

首先,让 Azure Databricks 管理员在工作区中创建顶级文件夹,以包含用于开发、过渡和生产分支的单个 Git 文件夹。 例如,如果公司将 main 分支用于生产,则必须将生产 Git 文件夹配置为使用 main 分支。

通常,这些顶级文件夹的权限对于工作区中的所有非管理员用户都是只读的。 对于这些顶级文件夹,Databricks 建议你仅向服务主体提供 Can EditCan Manage 权限,以避免工作区用户意外编辑生产代码。

顶级 Git 文件夹。

步骤 2:使用 API 设置 Databricks Git 文件夹的自动更新

若要使用最新版本的源文件和资产使 Databricks 中的 Git 目录保持最新,可以设置 Git 自动化以调用 Repos API。 使用 Git 提供程序的 CI/CD 工具(或兼容的第三方工具),设置自动化流程,以便在每次成功将 PR 合并到主分支后,在相应的 Git 目录中调用 Repos API 端点,将其更新到最新版本的源代码。 例如,如果 GitHub 是提供商,则可以使用 GitHub Actions

有关 Azure Databricks Repos API 的详细信息,请参阅 Repos 的 Databricks REST API 文档

其他资源