Azure Databricks Git 文件夹限制和引用

本页介绍 Databricks Git 文件夹的大小限制、支持的功能、安全注意事项和 CI/CD 行为。 有关常规 Databricks 资源限制，请参阅 资源限制。 若要了解 Git 文件夹中支持的资产类型，请参阅 Git 文件夹中支持的资产类型。

文件和存储库限制

Azure Databricks不会对存储库大小强制实施限制。 但是，以下限制适用：

  • 工作分支限制为 1 GB。
  • 无法在 Azure Databricks UI 中查看大于 10 MB 的文件。
  • 每个 Git 操作最多支持 2 GB 的内存和 4 GB 的磁盘写入。
  • 单个工作区文件具有单独的大小限制。 请参阅限制。

Databricks 建议将工作区资产和文件的总数保持在 20,000 以下。

由于每个操作都适用限制，因此克隆 5 GB 存储库失败，但克隆 3 GB 存储库，以后再添加 2 GB 会成功。 如果存储库超出这些限制，则在克隆过程中可能会收到错误或超时，但操作可能仍在后台完成。

若要处理大型存储库，请尝试 稀疏签出 或 Git CLI 命令。 若要编写群集关闭后不保留的临时文件，请使用 $TEMPDIR。 这可以避免超过分支大小限制，并且比写入工作区文件系统中的工作目录（CWD）提供更好的性能。 请参阅 我应该在 Azure Databricks 的哪里写入临时文件？。

删除远程分支后，本地分支最多可以保留在关联的 Git 文件夹中 30 天。 若要完全删除本地分支，请删除存储库。

减小存储库大小

如果存储库由于大型文件而超出大小限制，则将其添加到 .gitignore 不会减小存储库大小。 已提交到 Git 的文件仍保留在存储库历史记录中，即使已添加到 .gitignore。

若要减小存储库大小，请执行以下作：

  • 使用 Git 工具（例如 git filter-repo 或 BFG Repo-Cleaner）从提交历史记录中删除大型文件。 这会重写历史记录，需要强制推送到远程存储库。
  • 仅克隆特定目录。 请参阅 配置稀疏签出模式。
  • 将不相关的代码移动到单独的存储库。

有关详细信息，请参阅从存储库中删除敏感数据GitHub文档中。

Monorepo 支持

Databricks 不建议创建由 monorepos 支持的 Git 文件夹，这些是大型的单组织 Git 存储库，包含多个项目中的数千个文件。 克隆 monorepo 可能会超过 Git 仓库的内存和磁盘限制，并导致 Git 操作变得缓慢。 如果存储库包含多个项目，请考虑将其拆分或使用稀疏检出以限制克隆的目录。 请参阅 配置稀疏签出模式。

配置

并非所有标准 Git 功能都在 Git 文件夹中工作，内容与本地克隆中存储的方式不同。 以下主题介绍了存储的工作原理、支持哪些服务器，以及功能（如 .gitignore 和子模块）的行为方式。

仓库内容存储

Azure Databricks临时将存储库内容克隆到控制平面中的磁盘。 控制平面的数据库存储笔记本文件，与主工作区中的文件类似。 非笔记本文件最多在磁盘上存储 30 天。

本地部署和自托管 Git 服务器

Databricks Git 文件夹支持 GitHub Enterprise、Bitbucket Server、Azure DevOps Server 和 GitLab 自管理（如果服务器可访问 Internet）。 有关本地集成，请参阅 Git 文件夹的 Git 代理服务器。

若要与 Bitbucket Server、GitHub Enterprise Server 或 GitLab 无法访问 Internet 的自托管实例集成，请联系Azure Databricks帐户团队。

支持的资产类型

有关支持的资产类型的详细信息，请参阅 Git 文件夹中支持的资产类型。

.gitignore 文件支持

Git 文件夹支持 .gitignore 文件。 若要防止 Git 跟踪文件，请将文件名（包括扩展名）添加到 .gitignore 文件中。 创建一个文件或使用从远程存储库克隆的现有文件。

.gitignore 仅适用于未跟踪的文件。 添加已提交的文件 .gitignore 不会将其从 Git 历史记录中删除或减少存储库大小。 若要删除提交的文件，请参阅 减小存储库大小。

Git 子模块支持

标准 Git 文件夹不支持 Git 子模块，但具有 Git CLI 访问权限的 Git 文件夹可以使用它们。 请参阅“使用 Git CLI”命令（Beta 版）。

Azure 数据工厂 支持

Azure 数据工厂（ADF）支持 Git 文件夹。

源管理

一些操作在 Git 文件夹中的工作方式不同于标准 Git 工作流，尤其是在笔记本和分支删除方面。

笔记本仪表板和分支更改

Azure Databricks源格式笔记本不存储仪表板信息。

若要保留仪表板，请将笔记本格式更改为 .ipynb （Jupyter 格式），该格式默认支持仪表板和可视化定义。 若要保留可视化数据，请提交包含输出的笔记本。

请参阅 管理 IPYNB 笔记本输出提交。

分支合并支持

Git 文件夹支持分支合并。 也可以创建拉取请求并通过 Git 提供程序进行合并。

删除分支

若要删除分支，必须在 Git 提供程序中工作。

Python 依赖项优先级

Python Git 文件夹中的库优先于存储在其他位置的库。 例如，如果在 Databricks 计算上安装库，并且 Git 文件夹中存在同名的库，则会导入 Git 文件夹库。 请参阅 Python 库优先级。

安全性、身份验证和令牌

Azure Databricks将 Git 凭据存储在控制平面中，而不是存储在本地环境中。 以下主题介绍了如何加密 Git 文件夹内容、如何存储和审核令牌，以及遇到身份验证问题时该怎么办。

Microsoft Entra ID 的条件访问策略 (CAP) 问题

克隆存储库时，可能会收到“拒绝访问”错误（如果：

  • Azure Databricks工作区使用Azure DevOps，并通过Microsoft Entra ID进行身份验证。
  • 已在Azure DevOps和Microsoft Entra ID条件访问策略中启用条件访问策略。

若要解决此问题，请将排除项添加到Azure Databricks IP 地址或用户的条件访问策略（CAP）。

有关详细信息，请参阅条件访问策略。

带有Microsoft Entra ID令牌的 Allowlist

如果使用Microsoft Entra ID对Azure DevOps进行身份验证，则默认允许列表将 Git URL 限制为：

  • dev.azure.com
  • visualstudio.com

有关详细信息，请参阅 Git URL 允许列表。

Git 文件夹加密

Azure Databricks使用默认密钥加密 Git 文件夹内容。 仅支持客户管理的密钥来加密 Git 凭据。

GitHub 令牌存储和访问

  • Azure Databricks 控制平面存储身份验证令牌。 员工只能通过审核的临时凭据访问它们。
  • Azure Databricks记录令牌创建和删除，但不记录使用情况。 通过 Git 操作日志记录，可以审核Azure Databricks应用程序的令牌使用情况。
  • GitHub企业审核令牌使用情况。 其他 Git 服务也可能提供服务器审核。

GPG 提交签名

Git 仓库不支持提交的 GPG 签名。

SSH 支持

Git 文件夹仅支持 HTTPS，不支持 SSH。

Azure DevOps 跨租户错误

在单独的租户中连接到 DevOps 时，你可能会看到 Unable to parse credentials from Azure Active Directory account。 如果 Azure DevOps 项目和 Azure Databricks 位于不同的 Microsoft Entra ID 租户中，请使用 Azure DevOps 访问令牌。 请参阅 个人访问令牌。

CI/CD 和 MLOps

如果针对 Git 文件夹中的文件运行作业，请注意 Git 操作如何以可能不明显的方式影响笔记本状态和 MLflow 试验。

传入更改清除笔记本状态

更改笔记本源代码的 Git 操作会导致笔记本状态丢失，包括单元格输出、注释、版本历史记录和小组件。 例如， git pull 可以更改笔记本源代码，要求 Git 文件夹覆盖现有笔记本。 操作（例如 git commit，push 或创建新分支）不会影响源代码，同时保留笔记本状态。

重要

MLflow 试验不适用于 Databricks Runtime 14.x 或更早版本的 Git 文件夹中。

Git 文件夹中的 MLflow 试验

有两种类型的 MLflow 试验：工作区和笔记本。 请参阅使用 MLflow 试验组织训练运行。

  • 工作区试验：无法在 Git 文件夹中创建工作区 MLflow 试验。 将 MLflow 运行记录到常规工作区文件夹中创建的实验中。 对于多用户协作，请使用共享工作区文件夹。

  • 笔记本试验：可以在 Databricks Git 文件夹中创建笔记本试验。 如果将笔记本作为 .ipynb 文件签入源代码管理，MLflow 会将运行日志记录到自动创建的实验中。 源代码控制不会检查试验或其运行。 请参阅创建笔记本试验。

防止 MLflow 试验中的数据丢失

使用 Lakeflow 作业创建的笔记本 MLflow 试验和远程存储库中的源代码 存储在临时存储中。 这些实验在工作流执行后会继续保留，但在计划清理期间有被删除的风险。 Databricks 建议在作业和远程 Git 源中使用工作区 MLflow 试验。

警告

切换到不包含笔记本的分支可能会丢失关联的 MLflow 试验数据。 如果在 30 天内未访问之前的分支，则此损失将成为永久性的。

若要在 30 天到期前恢复缺失的试验数据，请还原原始笔记本名称，打开笔记本，然后单击右窗格中的 “试验”图标 。 这会触发 mlflow.get_experiment_by_name() 并恢复试验并运行。 30 天后，Azure Databricks 清除未关联的 MLflow 试验以符合 GDPR 合规性。

若要防止数据丢失，请避免重命名存储库中的笔记本。 如果重命名笔记本，请立即单击右窗格中的试验图标。

在 Git 操作期间运行作业

在进行 Git 操作时，某些笔记本可能会更新，而其他笔记本尚未更新，从而导致行为不可预测。

例如，如果notebook A使用notebook Z调用%run，并且作业在Git操作期间启动，则作业可能会使用较新的notebook A与较旧的notebook Z版本一起运行。 作业可能会失败，或者运行来自不同提交的笔记本。

若要避免这种情况，请将作业任务配置为使用 Git 提供程序作为源而不是工作区路径。 请参阅 将 Git 与 Lakeflow 作业配合使用。

后续步骤

  • Last updated on