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に一時ファイルをどこに書き込むべきかを参照してください。

ローカルブランチは、リモートブランチが削除されてから最大 30 日間、関連付けられている Git フォルダーに残ることができます。ローカルブランチを完全に削除するには、リポジトリを削除します。

リポジトリのサイズを小さくする

大きなファイルが原因でリポジトリのサイズが制限を超えた場合、.gitignore に追加してもリポジトリのサイズは小さくなりません。 Git に既にコミットされているファイルは、 .gitignoreに追加された場合でもリポジトリ履歴に残ります。

リポジトリのサイズを小さくするには:

コミット履歴から大きなファイルを削除するには、 git filter-repo や BFG Repo-Cleaner などの Git ツールを使用します。これにより履歴が書き換わり、リモートリポジトリに強制的にプッシュする必要があります。
特定のディレクトリのみを複製します。スパースチェックアウトモードの構成を参照してください。
関連のないコードを別のリポジトリに移動します。

詳細については、GitHubドキュメントリポジトリからの機密データの削除を参照してください。

Monorepo のサポート

Databricks では、多くのプロジェクトで数千のファイルを含む大規模な単一組織の Git リポジトリである monorepos によってサポートされる Git フォルダーを作成しないことを推奨しています。 monorepo を複製すると、Git フォルダーのメモリとディスクの制限を超え、Git 操作が遅くなる可能性があります。リポジトリに複数のプロジェクトが含まれている場合は、それを分割するか、スパースチェックアウトを使用して、複製するディレクトリを制限することを検討してください。スパースチェックアウトモードの構成を参照してください。

構成

すべての標準的な Git 機能が Git フォルダーで機能するわけではありません。コンテンツはローカルクローンとは異なる方法で格納されます。次のトピックでは、ストレージのしくみ、サポートされているサーバー、および .gitignore やサブモジュールなどの機能の動作について説明します。

リポジトリコンテンツストレージ

Azure Databricks、コントロールプレーン内のディスクにリポジトリの内容を一時的に複製します。コントロールプレーンデータベースには、メインワークスペースのノートブックファイルと同様のファイルが格納されます。ノートブック以外のファイルは、最大 30 日間ディスクに格納されます。

オンプレミスおよびセルフホステッド Git サーバー

Databricks Git フォルダーは、サーバーがインターネットにアクセスできる場合に、GitHub Enterprise、Bitbucket Server、Azure DevOps Server、GitLab 自己管理をサポートします。オンプレミス統合については、"Git Proxy Server for Git フォルダ"を参照してください。

インターネットにアクセスできない Bitbucket Server、GitHub Enterprise Server、または GitLab のセルフマネージドインスタンスと統合するには、Azure Databricks アカウントチームにお問い合わせください。

サポートされている資産の種類

サポートされている資産の種類の詳細については、 Git フォルダーでサポートされている資産の種類に関するページを参照してください。

.gitignore ファイルのサポート

Git フォルダーでは、 .gitignore ファイルがサポートされます。 Git がファイルを追跡できないようにするには、ファイル名 (拡張子を含む) を .gitignore ファイルに追加します。 1 つ作成するか、リモートリポジトリから複製された既存のファイルを使用します。

.gitignore は、追跡されていないファイルに対してのみ機能します。既にコミット済みのファイルを .gitignore に追加しても、Git 履歴から削除されたり、リポジトリのサイズが縮小されたりすることはありません。コミットされたファイルを削除するには、「リポジトリのサイズを小さくする」を参照してください。

Git サブモジュールのサポート

標準 Git フォルダーは Git サブモジュールをサポートしていませんが、Git CLI アクセス権を持つ Git フォルダーで使用できます。 Git CLI コマンドの使用 (ベータ) を参照してください。

Azure Data Factory のサポート

Azure Data Factory (ADF) は Git フォルダーをサポートしています。

ソース管理

いくつかの操作は、Git フォルダーと標準の Git ワークフロー (特にノートブックとブランチの削除) とは異なる方法で動作します。

ノートブックダッシュボードとブランチの変更

Azure Databricks のソース形式ノートブックはダッシュボード情報を格納しません。

ダッシュボードを保持するには、ノートブックの形式を .ipynb (Jupyter 形式) に変更します。この形式では、既定でダッシュボードと視覚化の定義がサポートされます。視覚化データを保存するには、出力を含めてノートブックをコミットします。

IPYNB ノートブック出力コミットの管理を参照してください。

ブランチマージのサポート

Git フォルダーでは、ブランチのマージがサポートされています。 pull request を作成し、Git プロバイダーを通じてマージすることもできます。

ブランチの削除

ブランチを削除するには、Git プロバイダーで作業する必要があります。

Python 依存関係の優先順位

Git フォルダー内のPython ライブラリは、他の場所に格納されているライブラリよりも優先されます。たとえば、Databricks コンピューティングにライブラリがインストールされていて、同じ名前のライブラリが Git フォルダーに存在する場合、Git フォルダーライブラリがインポートされます。 Python ライブラリの優先順位を参照してください。

セキュリティ、認証、トークン

Azure Databricksは、ローカル環境ではなく、コントロールプレーンに Git 資格情報を格納します。次のトピックでは、Git フォルダーの内容の暗号化方法、トークンの格納と監査方法、認証の問題が発生した場合の対処方法について説明します。

Microsoft Entra ID の条件付きアクセスポリシー (CAP) に関する問題

次の場合、リポジトリの複製時に "アクセス拒否" エラーが発生する可能性があります。

Azure Databricks ワークスペースでは、Microsoft Entra ID認証でAzure DevOpsが使用されます。
Azure DevOpsで条件付きアクセスポリシーとMicrosoft Entra ID条件付きアクセスポリシーを有効にしました。

これを解決するには、Azure Databricks IP アドレスまたはユーザーの条件付きアクセスポリシー (CAP) に除外を追加します。

詳しくは、条件付きアクセスポリシーに関するページをご覧ください。

Microsoft Entra ID トークンを使用した許可リスト登録

Azure DevOpsでの認証にMicrosoft Entra IDを使用する場合、既定の許可リストでは Git URL が以下に制限されます。

dev.azure.com
visualstudio.com

詳細については、 Git URL の許可リストを参照してください。

Git フォルダーの暗号化

Azure Databricksは、既定のキーを使用して Git フォルダーの内容を暗号化します。カスタマーマネージドキーは、Git 資格情報の暗号化でのみサポートされます。

GitHub トークンのストレージとアクセス

Azure Databricks コントロールプレーンには認証トークンが格納されます。従業員は、監査された一時的な資格情報を使用してのみアクセスできます。
Azure Databricksトークンの作成と削除はログに記録されますが、使用状況はログに記録されません。 Git 操作ログを使用すると、Azure Databricks アプリケーションによるトークンの使用状況を監査できます。
GitHub Enterprise はトークンの使用状況を監査します。その他の Git サービスでは、サーバー監査も提供される場合があります。

GPG コミット署名

Git フォルダーでは、コミットの GPG 署名はサポートされていません。

SSH のサポート

Git フォルダーでは、SSH ではなく HTTPS のみがサポートされます。

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 実験には、ワークスペースとノートブックの 2 種類があります。「MLflow 実験を使用してトレーニング実行を整理する」を参照してください。

ワークスペースの実験: Git フォルダーにワークスペース MLflow 実験を作成することはできません。 MLflow のログは、通常のワークスペースフォルダーに作成された実験に対して実行されます。マルチユーザーコラボレーションの場合は、共有ワークスペースフォルダーを使用します。
ノートブックの実験: Databricks Git フォルダーにノートブック実験を作成できます。ノートブックを .ipynb ファイルとしてソース管理にチェックインすると、MLflow によって自動的に作成された実験にログが実行されます。ソース管理は、実験やその実行をコミット（登録）しません。「ノートブックの実験の作成」を参照してください。

MLflow 実験でデータ損失を防止する

リモートリポジトリ内のソースコードで Lakeflow ジョブを使用して作成されたノートブック MLflow 実験は、一時ストレージに格納されます。これらの実験はワークフローの実行後も最初は保持されますが、スケジュールされたクリーンアップ中に削除されるリスクがあります。 Databricks では、ワークスペース MLflow 実験を、ジョブおよびリモート Git ソースと共に使用することをお勧めします。

警告

ノートブックを含まないブランチに切り替えると、関連する 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 プロバイダーを使用するようにジョブタスクを構成します。「Lakeflow ジョブで Git を使用する」を参照してください。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-03