Databricks Git フォルダーの制限とリファレンス
このページでは、Databricks Gitフォルダーのサイズ制限、サポートされている機能、セキュリティに関する考慮事項、およびCI/CDの動作について説明します。一般的なDatabricksリソース制限については、 「リソース制限」を参照してください。 Git フォルダーでサポートされているアセットの種類については、 「Git フォルダーでサポートされているアセットの種類」を参照してください。
ファイルとリポジトリの制限
Databricksはリポジトリのサイズに制限を設けていません。ただし、以下の制限が適用されます。
- 作業ブランチは 1 GB に制限されます。
- Databricks UI では 10 MB を超えるファイルを表示できません。
- 各Git操作は、最大2GBのメモリと4GBのディスク書き込みをサポートします。
- 個々のワークスペース ファイルには個別のサイズ制限があります。制限事項を参照してください。
Databricks では、ワークスペース アセットとファイルの合計数を 20,000 未満に抑えることを推奨しています。
操作ごとに制限が適用されるため、5GBのリポジトリをクローンしようとすると失敗しますが、3GBのリポジトリをクローンしてから後で2GBを追加すると成功します。リポジトリのサイズがこれらの制限を超えると、クローン中にエラーやタイムアウトが発生する可能性がありますが、操作自体はバックグラウンドで完了する場合があります。
より大きなリポジトリを操作するには、スパース チェックアウトまたはGit CLIコマンドを試してください。 クラスターのシャットダウン後に持続しない一時ファイルを書き込むには、 $TEMPDIRを使用します。 これにより、ブランチのサイズ制限を超えることを回避でき、ワークスペースファイルシステム内の作業ディレクトリ（CWD）に書き込むよりも優れたパフォーマンスが得られます。Databricks で一時ファイルをどこに書き込むべきかについては、「Databricks で一時ファイルをどこに書き込むべきか」を参照してください。
ローカル ブランチは、リモート ブランチが削除された後、最大 30 日間、関連付けられた Git フォルダー内に残ります。ローカル ブランチを完全に削除するには、リポジトリを削除します。
リポジトリのサイズを削減する
大きなファイルのためにリポジトリのサイズ制限を超えた場合、それらのファイルを.gitignoreに追加してもリポジトリのサイズは縮小されません。すでに Git にコミットされたファイルは、 .gitignoreに追加されてもリポジトリ履歴に残ります。
リポジトリのサイズを縮小するには:
- コミット履歴から大きなファイルを削除するには、
git filter-repoや BFG Repo-Cleaner などの Git ツールを使用してください。これにより履歴が書き換えられ、リモート リポジトリへの強制プッシュが必要になります。 - 特定のディレクトリのみを複製します。スパースチェックアウトモードの構成を参照してください。
- 無関係なコードを別のリポジトリに移動します。
詳細については、 GitHubドキュメントの「リポジトリからの機密データの削除」を参照してください。
モノレポのサポート
Databricks 、 モノレポ （多数のプロジェクトにまたがる数千のファイルを含む、大規模な単一組織のGitリポジトリ）によってバックアップされたGitフォルダを作成しないことを推奨しています。 モノレポをクローンすると、Gitフォルダのメモリとディスクの制限を超え、Gitの操作が遅くなる可能性があります。リポジトリに複数のプロジェクトが含まれている場合は、リポジトリを分割するか、スパースチェックアウトを使用してクローンするディレクトリを制限することを検討してください。「スパースチェックアウトモードの設定」を参照してください。
構成
Gitフォルダでは、標準的なGit機能がすべて動作するわけではなく、コンテンツの保存方法もローカルクローンとは異なります。以下のトピックでは、ストレージの仕組み、サポートされているサーバー、および.gitignoreやサブモジュールなどの機能の動作について説明します。
リポジトリコンテンツの保存
Databricks はリポジトリの内容をコントロール プレーンのディスクに一時的に複製します。コントロール プレーン データベースには、メイン ワークスペースにあるものと同様のノートブック ファイルが格納されます。ノートブック以外のファイルは最大 30 日間ディスクに保存されます。
オンプレミスおよびセルフホスト型のGitサーバー
Databricks Git フォルダーは、サーバーがインターネットにアクセスできる場合、GitHub Enterprise、Bitbucket Server、Azure DevOps Server、および GitLab Self-managed をサポートします。オンプレミス統合のGit フォルダーについては、Git プロキシ サーバーを参照してください。
インターネットにアクセスできない Bitbucket Server、GitHub Enterprise Server、または GitLab のセルフマネージドインスタンスと統合するには、Databricks アカウント チームにお問い合わせください。
サポートされているアセットの種類
サポートされているアセットタイプの詳細については、 「Git フォルダーでサポートされているアセットタイプ」を参照してください。
.gitignore ファイルのサポート
Gitフォルダは.gitignoreファイルをサポートしています。Gitがファイルを追跡しないようにするには、ファイル名（拡張子を含む）を.gitignoreファイルに追加します。新規に作成するか、リモートリポジトリからクローンした既存のファイルを使用してください。
.gitignore 追跡されていないファイルに対してのみ機能します。すでにコミットされたファイルを.gitignoreに追加しても、Git 履歴から削除されたり、リポジトリのサイズが縮小されたりすることはありません。コミットされたファイルを削除するには、 「リポジトリ サイズの削減」を参照してください。
Gitサブモジュールのサポート
標準の Git フォルダーは Git サブモジュールをサポートしていませんが、Git CLI アクセス権を持つ Git フォルダーは Git サブモジュールを使用できます。「Git CLI コマンドの使用 (ベータ版)」を参照してください。
ソース管理
Gitフォルダーでは、特にノートブックやブランチの削除など、いくつかの操作が標準のGitワークフローとは動作が異なります。
ノートブックのダッシュボードとブランチの変更
Databricks ソース形式のノートブックにはダッシュボード情報は保存されません。
ダッシュボードを保持するには、ノートブックの形式を、ダッシュボードと視覚化の定義をデフォルトでサポートする.ipynb (Jupyter 形式) に変更します。視覚化データを保持するには、出力を含むノートブックをコミットします。
ipynbノートブック出力コミットの管理」を参照してください。
ブランチマージのサポート
Gitフォルダはブランチのマージをサポートしています。Gitプロバイダを通してプルリクエストを作成し、マージすることもできます。
ブランチの削除
ブランチを削除するには、Git プロバイダーで作業する必要があります。
Pythonの依存関係の優先順位
Git フォルダー内の Python ライブラリは、他の場所に保存されているライブラリよりも優先されます。たとえば、ライブラリがDatabricksコンピュートにインストールされており、同じ名前のライブラリがGitフォルダーに存在する場合、 Gitフォルダーのライブラリがインポートされます。 Python ライブラリの優先順位を参照してください。
セキュリティ、認証、トークン
Databricksは、Gitの認証情報をローカル環境ではなく、コントロールプレーンに保存します。以下のトピックでは、 Gitフォルダーの内容がどのように暗号化されるか、どのように保存および監査されるか、認証の問題に遭遇した場合の対処方法について説明します。
Gitフォルダの暗号化
Databricks は、デフォルトのキーを使用して Git フォルダーの内容を暗号化します。顧客管理キーは、Git 資格情報の暗号化にのみサポートされます。
GitHubストレージとアクセス
- Databricks コントロール プレーンには認証トークンが保存されます。従業員は監査済みの一時的な資格情報を通じてのみアクセスできます。
- Databricks はトークンの作成と削除を記録しますが、使用状況は記録しません。Git 操作ログを使用すると、Databricks アプリケーションによるトークンの使用状況を監査できます。
- GitHub Enterprise はトークンの使用状況を監査します。他の Git サービスでもサーバー監査が提供される場合があります。
GPGコミットメント署名
Gitフォルダは、コミットのGPG署名をサポートしていません。
SSHサポート
GitフォルダはHTTPSのみをサポートしており、SSHはサポートしていません。
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エクスペリメントLakeFlowリモート リポジトリのソース コードは、一時ストレージに保存されます。 これらのエクスペリメントは、最初はワークフローの実行後に残りますが、スケジュールされたクリーンアップ中に削除される危険性があります。 Databricks 、ジョブとリモートGitソースでワークスペースMLflowエクスペリメントを使用することをお勧めします。
ノートブックを含まないブランチに切り替えると、関連するMLflowエクスペリメント データが失われる危険があります。 30日以内に以前の支店を訪れない場合、この損失は永久的なものとなります。
30 日の有効期限が切れる前に失われた体験データを復元するには、元のノートブック名を復元し、ノートブックを開いて、
右側のペインで。 これによりmlflow.get_experiment_by_name()トリガーされ、経験と実行が回復されます。 30 日後、 Databricks GDPRのために孤立したMLflowエクスペリメントを削除します。
データの損失を防ぐため、リポジトリ内のノートブックの名前を変更しないでください。ノートブックの名前を変更する場合は、すぐに右ペインの「エクスペリメント」アイコンをクリックします。
Git操作中にジョブを実行する
Git 操作中に、一部のノートブックが更新され、他のノートブックがまだ更新されていない場合があり、予期しない動作が発生します。
たとえば、 notebook A %runを使用してnotebook Z呼び出し、Git 操作中にジョブが開始された場合、ジョブは最新のnotebook A古いnotebook Zで実行する可能性があります。ジョブが失敗したり、異なるコミットからのノートブックが実行されたりする可能性があります。
これを回避するには、ジョブタスクの設定で、ワークスペースパスではなくGitプロバイダーをソースとして使用するようにしてください。LakeFlowジョブでGit使用する方法については、 LakeFlowジョブでGitを使用する」を参照してください。
次のステップ
- Gitフォルダのエラーをトラブルシューティングする
- Gitフォルダの作成と管理
- GitフォルダのGit統合を設定する