通过

Git 与 Databricks Git 文件夹集成的限制和常见问题解答

  • 项目

Databricks Git 文件夹和 Git 集成具有在以下部分中指定的限制。 有关常规信息，请参阅 Databricks 限制。

跳转到：

若要了解 Git 文件夹中支持的 Databricks 资产类型，请参阅 Git 文件夹支持哪些资产类型？

文件和存储库限制

Azure Databricks 不会对存储库的大小强制施加限制。 但是：

  • 工作分支限制为 1 GB。
  • 大于 10 MB 的文件无法在 Azure Databricks UI 中查看。
  • 单个工作区文件有单独的大小限制。 有关更多详细信息，请阅读限制。

Databricks 建议在存储库中：

  • 工作区资产和文件的总数不超过 20,000。

对于任何 Git作，内存使用量限制为 2 GB，磁盘写入限制为 4 GB。 由于此限制是针对每个操作的，如果尝试克隆一个大小为 5 GB 的 Git 存储库，就会失败。 但如果在一个操作中克隆大小为 3 GB 的 Git 存储库，然后稍后向其添加 2 GB，则下一个拉取操作将成功。

如果存储库超出这些限制，可能会收到错误消息。 克隆存储库时，即使操作仍会在后台完成，你也可能收到超时错误。

若要使用超过大小限制的存储库，请尝试稀疏签出。

如果必须编写在群集关闭后不需要保留的临时文件，请将这些临时文件写入 $TEMPDIR ，这可以避免超过分支大小限制，并比将文件写入工作区文件系统中的工作目录（CWD）获得更好的性能。 有关详细信息，请参阅应在 Azure Databricks 上的什么位置编写临时文件？。

如何在工作区中恢复从 Git 文件夹删除的文件

对 Git 文件夹执行的工作区操作因文件可恢复性而异。 某些操作允许通过 回收站 文件夹恢复，而另一些操作则不允许。 以前提交并推送到远程分支的文件可以使用远程 Git 存储库的 Git 提交历史记录进行还原。 下表概述了每个操作的行为和可恢复性：

操作 文件是否可恢复？
使用工作区浏览器删除文件 是，来自回收站文件夹
放弃包含 Git 文件夹对话框的新文件 是，来自回收站文件夹
放弃包含 Git 文件夹对话框的修改文件 否，文件已消失
reset（硬）用于未提交的文件修改 否，文件修改已消失
reset（硬）用于未提交的新创建的文件 否，文件修改已消失
使用 Git 文件夹对话框切换分支 是，来自远程 Git 存储库
Git 文件夹对话框中的其他 Git 操作，例如提交或推送 是，来自远程 Git 存储库
从 Repos API 更新 PATCH 的 /repos/id 操作 是，来自远程 Git 存储库

单存储库支持

Databricks 建议不要创建 由 monorepos 支持的 Git 文件夹。 monorepo 是一个大型的单组织 Git 存储库，其中包含多个项目中的数千个文件。

常见问题解答：Git 文件夹配置

Azure Databricks 存储库内容存储在何处？

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

Git 文件夹是否支持本地或自承载 Git 服务器？

如果可以通过 Internet 访问服务器，Databricks Git 文件夹将支持 GitHub Enterprise、Bitbucket Server、Azure DevOps Server 和 GitLab 自承载集成。 有关将 Git 文件夹与本地 Git 服务器集成的详细信息，请阅读 Git 文件夹的 Git 代理服务器。

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

Git 文件夹支持哪些 Databricks 资产类型？

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

Git 文件夹是否支持 .gitignore 文件？

是的。 如果将某个文件添加到存储库，并且不希望 Git 跟踪该文件，请创建一个 .gitignore 文件或使用从远程存储库克隆的文件，并添加文件名（包括文件扩展名）。

.gitignore 仅适用于 Git 尚未跟踪的文件。 如果将 Git 已跟踪的文件添加到 .gitignore 文件中，Git 仍会跟踪该文件。

Git 文件夹是否支持 Git 子模块？

否。 可以克隆包含 Git 子模块的存储库，但不会克隆子模块。

Azure 数据工厂 (ADF) 是否支持 Git 文件夹？

是的。

源管理

为什么在拉取或签出其他分支时笔记本仪表板会消失？

这是一个限制，因为 Azure Databricks 源格式笔记本不存储笔记本仪表板信息。

若要在 Git 存储库中保留仪表板，请将笔记本格式更改为 .ipynb （Jupyter 笔记本格式）。 默认情况下，.ipynb 支持仪表板和可视化定义。 若要保留可视化数据，必须提交包含输出的笔记本。

若要了解如何提交 .ipynb 笔记本输出，请参阅 管理 IPYNB 笔记本输出提交。

Git 文件夹是否支持分支合并？

是的。 也可以创建拉取请求并通过 Git 提供程序进行合并。

能否从 Azure Databricks 存储库中删除分支？

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

Python 依赖项包含在 Git 文件夹中时的优先顺序是什么？

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

安全性、身份验证和令牌

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

尝试克隆存储库时，可能会在以下情况下收到“拒绝访问”的错误消息：

  • Azure Databricks 配置为将 Azure DevOps 与 Microsoft Entra ID 身份验证配合使用。
  • 你已在 Azure DevOps 中启用条件访问策略且启用了 Microsoft Entra ID 条件访问策略。

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

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

包含 Microsoft Entra ID 令牌的允许列表

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

  • dev.azure.com
  • visualstudio.com

有关详细信息，请参阅允许列表限制使用远程存储库。

Azure Databricks Git 文件夹的内容是否加密？

Azure Databricks Git 文件夹的内容将由 Azure Databricks 使用默认密钥进行加密。 除非加密 Git 凭据，否则不支持使用客户管理的密钥进行加密。

GitHub 令牌在 Azure Databricks 中的存储方式和位置是？ 谁有权从 Azure Databricks 访问？

  • 身份验证令牌存储在 Azure Databricks 控制平面中，Azure Databricks 员工只能通过经审核的临时凭据获取访问权限。
  • Azure Databricks 记录这些令牌的创建和删除，但不记录其使用情况。 Azure Databricks 会通过日志记录跟踪 Git 操作，这些日志可用于审核 Azure Databricks 应用程序的令牌使用情况。
  • GitHub 企业审核令牌使用情况。 其他 Git 服务也可能进行 Git 服务器审核。

Git 文件夹是否支持对提交进行 GPG 签名？

否。

Git 目录是否支持使用 SSH 进行 Git 操作？

不，只有支持 HTTPS 协议。

将 Azure Databricks 连接到不同租户中的 Azure DevOps 存储库时出错

尝试在单独的租户中连接到 DevOps 时，可能会收到消息 Unable to parse credentials from Azure Active Directory account。 如果 Azure DevOps 项目与 Azure Databricks 位于不同的 Microsoft Entra ID 租户中，则必须使用来自 Azure DevOps 的访问令牌。 请参阅使用 DevOps 令牌连接到 Azure DevOps。

CI/CD 和 MLOps

传入更改清除笔记本状态

更改笔记本源代码的 Git 操作会导致笔记本状态丢失，包括单元格输出、注释、版本历史记录和小组件。 例如，git pull 可以更改笔记本的源代码。 在这种情况下，Databricks Git 文件夹必须覆盖现有笔记本才能导入更改。 git commit 和 push 或创建新分支不会影响笔记本源代码，因此在这些操作中笔记本状态会被保留。

重要

MLflow 试验不适用于使用 DBR 14.x 或更低版本的 Git 文件夹。

是否可以在 Git 文件夹中创建 MLflow 试验？

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

  • 工作区试验：无法在 Git 文件夹中创建工作区 MLflow 试验。 相反，将 MLflow 运行记录到常规工作区文件夹中创建的 MLflow 实验中。 如果多个用户使用单独的 Git 文件夹协作处理同一代码，请将 MLflow 运行记录到在共享工作区文件夹中创建的 MLflow 实验中。

  • 笔记本试验：可以在 Databricks Git 文件夹中创建笔记本试验。 如果将笔记本作为 .ipynb 文件签入源代码管理，可以将 MLflow 运行记录到自动创建的和关联的 MLflow 试验。 但是，试验和关联的运行不会签入源代码管理。 若要了解详细信息，请参阅 创建笔记本试验。

防止 MLflow 试验中的数据丢失

使用源代码在远程存储库中的 Databricks 作业创建的笔记本 MLflow 试验存储在临时存储位置。 这些试验最初会在工作流执行后保留，但之后在计划内的临时存储内文件移除期间，它们将面临被删除的风险。 Databricks 建议将工作区 MLflow 试验与作业和远程 Git 源一起使用。

警告

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

若要在 30 天到期前恢复缺少的试验数据，请将笔记本名称更改为原始名称，打开笔记本，然后单击右侧窗格中的 “试验”图标 ，这会触发对函数的 mlflow.get_experiment_by_name() 调用。 函数返回时，可以看到恢复的试验和运行。 30 天后，将清除任何无主 MLflow 试验，以满足 GDPR 合规性策略。

为防止这种情况，Databricks 建议不要重命名存储库中的笔记本。 如果确实重命名笔记本，请在重命名笔记本后立即单击右侧窗格中的“试验”图标。

在 Git 操作进行期间，如果笔记本作业在工作区中运行，会发生什么情况？

在任何 Git 操作正在进行时，存储库中的某些笔记本可能已经更新，而其他的则可能没有更新。 这可能会导致不可预知的行为。

例如，假设 notebook A 使用 notebook Z 命令调用 %run。 如果在进行 Git 操作期间运行的作业启动了最新版本的 notebook A，但 notebook Z 尚未更新，则 %run 中的 notebook A 命令可能启动较旧版本的 notebook Z。 在 Git 操作期间，笔记本状态不可预知，作业可能会失败，或者从不同的提交运行 notebook A 和 notebook Z。

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

资源

有关 Databricks 工作区文件的详细信息，请参阅什么是工作区文件？。