Databricks Git フォルダーと Git の統合に関する制限事項と FAQ

Databricks Git フォルダーと Git 統合には、次のセクションで指定されている制限があります。 一般的な情報については、 「Databricks の制限」を参照してください。

にジャンプする:

ファイルとリポジトリの制限

Databricks では、リポジトリのサイズに制限は適用されません。 しかし：

  • 作業ブランチは 1 ギガバイト (GB) に制限されています。

  • 10 MB を超えるファイルは、Databricks UI で表示できません。

  • 個々のワークスペース ファイルには、個別のサイズ制限が適用されます。 詳細については、「 制限事項」を参照してください。

Databricks では、リポジトリで次のことを推奨しています。

  • すべてのワークスペース資産とファイルの合計数が 20,000 を超えないこと。

Git 操作では、メモリ使用量は 2 GB に制限され、ディスク書き込みは 4 GB に制限されます。 この制限は操作ごとであるため、現在のサイズが 5 GB の Git repo を複製しようとすると失敗します。 ただし、サイズが 3 GB の Git repo を 1 回の操作で複製し、後で 2 GB を追加すると、次のプル操作は成功します。

リポジトリがこれらの制限を超えると、エラー メッセージが表示される場合があります。 リポジトリを複製するときにタイムアウト エラーが発生する場合もありますが、操作はバックグラウンドで完了する可能性があります。

サイズ制限を超えるリポジトリを操作するには、 スパース チェックアウトを試してください。

クラスターのシャットダウン後に保持したくない一時ファイルを書き込む必要がある場合、一時ファイルを$TEMPDIRに書き込むと、ブランチ サイズの制限を超えることがなくなり、現在の作業ディレクトリ (CWD) に書き込むよりもパフォーマンスが向上します。ワークスペースのファイルシステム内にあります。 詳細については、 「Databricks のどこに一時ファイルを書き込めばよいですか?」を参照してください。 。

ワークスペースあたりの Git フォルダの最大数

ワークスペースごとに最大 2,000 個の Git フォルダーを作成できます。 さらに必要な場合は、Databricks サポートにお問い合わせください。

ワークスペース内の Git フォルダーから削除されたファイルの回復

Git フォルダーに対するワークスペースのアクションは、ファイルの回復可能性によって異なります。 一部のアクションでは 、ごみ箱 フォルダからのリカバリが許可されますが、他のアクションでは許可されません。 以前にコミットされ、リモートブランチにプッシュされたファイルは、リモートGitリポジトリのGitコミット履歴を使用して復元できます。次の表に、各アクションの動作と回復可能性の概要を示します。

操作

ファイルは回復可能ですか?

ワークスペースブラウザでファイルを削除する

はい、 ごみ箱 フォルダから

Git フォルダ ダイアログで新しいファイルを破棄する

はい、 ごみ箱 フォルダから

Git フォルダダイアログで変更したファイルを破棄する

いいえ、ファイルはなくなりました

reset (hard) コミットされていないファイル変更の場合

いいえ、ファイルの変更はなくなりました

reset (hard) コミットされていない、新しく作成されたファイルの場合

いいえ、ファイルの変更はなくなりました

Git フォルダダイアログでブランチを切り替える

はい、リモートの Git リポジトリから

その他のGit操作(コミット&プッシュなど)をGitフォルダダイアログから

はい、リモートの Git リポジトリから

PATCH Repos API からの /repos/id を更新する操作

はい、リモートの Git リポジトリから

ワークスペース UI からの Git 操作によって Git フォルダーから削除されたファイルは、Git コマンド ライン (またはその他の Git ツール) を使用してリモート ブランチ履歴から回復できます (それらのファイルが以前にコミットされ、リモート リポジトリにプッシュされている場合)。 ワークスペースのアクションは、ファイルの回復可能性によって異なります。 一部のアクションでは、ごみ箱から回復できますが、他のアクションでは許可されません。 以前にコミットされ、リモートブランチにプッシュされたファイルは、Git コミット履歴を使用して復元できます。 次の表に、各アクションの動作と回復可能性の概要を示します。

モノレポ対応

Databricks では、モノレポを基盤とする Git フォルダーを作成しないことをお勧めします。モノレポとは、多数のプロジェクトにわたる数千のファイルを含む、大規模な単一組織の Git リポジトリです。

Git フォルダーでサポートされるアセットの種類

Git フォルダーでは、特定の Databricks アセットの種類のみがサポートされます。 サポートされているアセットの種類は、シリアル化、バージョン管理、およびバッキング Git リポジトリへのプッシュを行うことができます。

現在、サポートされているアセットタイプは次のとおりです。

資産タイプ

詳細

ファイル

ファイルはシリアル化されたデータであり、ライブラリからバイナリ、コード、画像まで、あらゆるものを含めることができます。 詳細については、「ワークスペース ファイルとは」を参照してください。

ノートブック

ノートブックは、具体的にはDatabricksでサポートされているノートブックファイル形式です。 ノートブックはシリアル化されていないため、ファイルとは別の Databricks アセット タイプと見なされます。 Git フォルダーは、ファイル拡張子 ( .ipynbなど) またはファイル コンテンツ内の特別なマーカーと組み合わせたファイル拡張子 (たとえば、 .pyソース ファイルの先頭にある# Databricks notebook sourceコメント) によってノートブックを判別します。

フォルダ

フォルダーは、Git のファイルの論理グループに関するシリアル化された情報を表す Databricks 固有の構造体です。 予想どおり、Databricks Git フォルダーを表示したり、Databricks CLI を使用してアクセスしたりすると、ユーザーはこれを "フォルダー" として体験します。

Git フォルダーで現在サポートされていない Databricks アセットの種類には、次のものがあります。

  • DBSQL クエリー

  • アラート

  • ダッシュボード (レガシーダッシュボードを含む)

  • エクスペリメント

  • Genie Space

Git でアセットを操作する場合は、ファイルの名前付けに関する次の制限に注意してください。

  • フォルダには、ファイル拡張子が異なっていても、同じ Git リポジトリ内の別のノートブック、ファイル、またはフォルダと同じ名前のノートブックを含めることはできません。 (ソース形式のノートブックの場合、拡張機能は Python では .py 、Scala では .scala 、SQL では .sql 、R では .r です。 IPYNB 形式のノートブックの場合、拡張子は .ipynbです。 たとえば、test1.py という名前のソース形式のノートブックと test1 という名前の ipynb ノートブックを同じ Git フォルダーで使用することはできません。これは、ソース形式の Python ノートブック ファイル (test1.py) が test1 としてシリアル化され、競合が発生するためです。

  • 文字 / はファイル名ではサポートされていません。 たとえば、Git フォルダに i/o.py という名前のファイルを含めることはできません。

これらのパターンを持つ名前を持つファイルに対して Git 操作を実行しようとすると、"Git ステータスのフェッチ中にエラーが発生しました" というメッセージが表示されます。 このエラーが予期せず表示される場合は、Git リポジトリ内のアセットのファイル名を確認してください。 これらの競合するパターンを持つ名前のファイルが見つかった場合は、名前を変更して操作を再試行してください。

注：

サポートされていない既存のアセットを Git フォルダーに移動することはできますが、これらのアセットに対する変更をリポジトリにコミットして戻すことはできません。 サポートされていないアセットを Git フォルダーに新規作成することはできません。

ノートブックのフォーマット

Databricks 、 Databricks固有の高レベルのノートブック形式として、「ソース」と「ipynb」の2種類を考慮しています。 ユーザーがノートブックを "ソース" 形式でコミットすると、Databricks プラットフォームは、 、 .py、 .sql、 .scala、 .rなどの言語サフィックスが付いたフラットファイルをコミットします。 "ソース" 形式のノートブックにはソース コードのみが含まれ、ノートブックの実行結果であるテーブル表示や視覚化などの出力は含まれません。

ただし、「ipynb」形式には出力が関連付けられており、それらのアーティファクトは、それらを生成した.ipynbノートブックをプッシュするときに、GitフォルダをバックアップするGitリポジトリに自動的にプッシュされます。コードと共に出力をコミットする場合は、"ipynb" ノートブック形式を使用し、生成された任意の出力をユーザーがコミットできるように構成を設定します。 その結果、"ipynb" は、Git フォルダーを介してリモート Git リポジトリにプッシュされたノートブックの Databricks での表示エクスペリエンスも向上させます。

ノートブックのソース形式

詳細

ソース

コード言語を通知する標準ファイル接尾辞を持つ任意のコードファイル( .py、 .scala、 .r 、 .sqlなど)を指定できます。 ソース" ノートブックはテキストファイルとして扱われ、 Git リポジトリにコミットされるときには、関連する出力は含まれません。

ipynb

"ipynb" ファイルの末尾は " .ipynb で、構成されている場合は、Databricks Git フォルダーからバッキング Git リポジトリに出力 (視覚化など) をプッシュできます。 .ipnynb ノートブックには、 Databricks ノートブックでサポートされている任意の言語のコードを含めることができます (.ipynb のpy部分を除く)。

ノートブックの実行後に出力をリポジトリにプッシュバックする場合は、 .ipynb (Jupyter) ノートブックを使用します。 ノートブックを実行して Git で管理するだけの場合は、 .pyのような "ソース" 形式を使用します。

サポートされているノートブック形式の詳細については、「 ノートブック Databricks エクスポートとインポート」を参照してください。

注：

「アウトプット」とは?

出力は、Databricks プラットフォーム上でノートブックを実行した結果であり、テーブルの表示や視覚化などです。

ノートブックが使用している形式 (ファイル拡張子以外) を確認するにはどうすればよいですか?

Databricks によって管理されるノートブックの上部には、通常、形式を示す 1 行のコメントがあります。 たとえば、 .py "ソース" ノートブックの場合、次のような線が表示されます。

# Databricks notebook source

.ipynbファイルの場合、ファイルの接尾辞は「ipynb」ノートブック形式であることを示すために使用されます。

Databricks Git フォルダー内の IPYNB ノートブック

Jupyter ノートブック (.ipynb ファイル) のサポートは、 Git フォルダーで利用できます。 .ipynb ノートブックを使用してリポジトリを複製し、Databricks で操作してから、.ipynb ノートブックとしてコミットしてプッシュできます。ノートブックダッシュボードなどのメタデータは保持されます。 管理者は、出力をコミットできるかどうかを制御できます。

.ipynbノートブックの出力のコミットを許可する

デフォルトでは、 Git フォルダのadmin設定では、.ipynbノートブックの出力をコミットすることはできません。 ワークスペース管理者は、次の設定を変更できます。

  1. [管理者設定] > [ワークスペース設定] に移動します。

  2. [ Git フォルダー] > [ Git フォルダーに ipynb 出力のエクスポートを許可する] で、[ 許可: ipynb 出力をオンに切り替える] を選択します。

    管理コンソール: Git フォルダに ipynb 出力のエクスポートを許可します。

重要

出力が含まれている場合、ビジュアライゼーションとダッシュボードの設定は .ipynb で保持されます ファイル形式。

IPYNB ノートブック出力アーティファクトのコミットを制御する

.ipynb ファイルをコミットすると、Databricks は出力のコミット方法を制御できる構成ファイル (.databricks/commit_outputs.

  1. .ipynbノートブックファイルがあるが、リポジトリに設定ファイルがない場合は、Git ステータスモーダルを開きます。

  2. 通知ダイアログで、[ コミット ファイルの作成] をクリックします。

    ノートブック コミット UI: コミット ファイルの作成ボタン。

[ファイル] メニューから設定ファイルを生成することもできます。[ファイル] メニューには、構成ファイルを自動的に更新して、特定のノートブックの出力を含めるか除外するかを指定できるコントロールがあります。

  1. [ ファイル ] メニューで、 [ノートブック出力のコミット] を選択します。

    ノートブック editor: コミット ノートブック 出力ステータスと制御。

  2. ダイアログボックスで、ノートブック出力をコミットする選択を確認します。

    [ノートブック出力のコミット] ダイアログ ボックス。

ソースノートブックを IPYNB に変換する

UI を使用して、 フォルダ内の既存のソース ノートブックをGit ipynbノートブックに変換できます。Databricks

  1. ワークスペースでソース ノートブックを開きます。

  2. ワークスペース メニューから [ファイル ] を選択し、 [ノートブック形式 [ソース] の変更] を選択します。 ノートブックがすでに ipynb 形式の場合、メニュー要素では [ソース] は [ipynb] になります。

    ワークスペースのファイルメニューが展開され、[ノートブック形式の変更] オプションが表示されます。

  3. モーダルダイアログで、「Jupyter ノートブック形式 (.ipynb)」を選択し、「 変更」をクリックします。

    ipynbノートブック形式を選択できるモーダルダイアログボックス。

また、次のこともできます。

  • 新しい .ipynb ノートブックを作成します。

  • 差分を Code diff (セル内のコード変更) または Raw diff (コード変更は JSON 構文として表示され、ノートブック出力はメタデータとして含まれる) として表示します。

Databricksでサポートされているノートブックの種類の詳細については、「ノートブックDatabricksエクスポートとインポート」を参照してください。

よくある質問: Git フォルダーの構成

Databricks リポジトリのコンテンツはどこに格納されますか?

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

Git フォルダーはオンプレミスまたはセルフホストの Git サーバーをサポートしていますか?

Databricks Git フォルダーは、サーバーがインターネットにアクセスできる場合、GitHub Enterprise、Bitbucket Server、Azure DevOps Server、および GitLab セルフマネージド統合をサポートします。 Git フォルダーとオンプレミス Git サーバーの統合の詳細については、 「Git フォルダー用の Git プロキシ サーバー」を参照してください。

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

Git フォルダーではどの Databricks アセット タイプがサポートされていますか?

サポートされているアセットタイプの詳細については、「 Git フォルダーでサポートされているアセットタイプ」を参照してください。

Git フォルダーは.gitignoreファイルをサポートしていますか?

はい。 リポジトリにファイルを追加し、Git で追跡したくない場合は、 .gitignore ファイルを作成するか、リモート リポジトリから複製されたファイルを使用して、拡張子を含むファイル名を追加します。

.gitignore Git によってまだ追跡されていないファイルに対してのみ機能します。 Git によって既に追跡されているファイルを .gitignore ファイルに追加しても、ファイルは引き続き Git によって追跡されます。

ユーザー フォルダーではない最上位フォルダーを作成できますか。

はい、管理者は最上位のフォルダーを 1 つの深さまで作成できます。 Git フォルダーは追加のフォルダー レベルをサポートしていません。

Git フォルダーは Git サブモジュールをサポートしていますか?

いいえ。 Git サブモジュールを含む リポジトリを複製することはできますが、サブモジュールは複製されません。

ソース管理

別のブランチをプルまたはチェックアウトするとノートブックダッシュボードが消えるのはなぜですか?

Databricks ノートブックのソース ファイルにはノートブック ダッシュボード情報が格納されないため、これは現在制限です。

ダッシュボードを Git リポジトリに保持する場合は、ノートブック形式を .ipynb (Jupyter ノートブック形式) に変更します。 デフォルトでは、 .ipynb はダッシュボードと視覚化の定義をサポートします。 グラフ データ (データポイント) を保持する場合は、出力を使用してノートブックをコミットする必要があります。

.ipynbノートブック出力のコミットについては、「'.ipynb' ノートブック出力のコミットを許可する」を参照してください。

Git フォルダーはブランチのマージをサポートしていますか?

はい。 プル要求を作成し、Git プロバイダーを介してマージすることもできます。

Databricks リポジトリからブランチを削除できますか?

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

ライブラリがクラスターにインストールされ、同じ名前のライブラリがリポジトリ内のフォルダーに含まれている場合、どのライブラリがインポートされますか?

repo内のライブラリがインポートされます。Python でのライブラリの優先順位の詳細については、「 Python ライブラリの優先順位」を参照してください。

外部のオーケストレーションツールに依存せずにジョブを実行する前に、Gitから最新バージョンのリポジトリをプルできますか?

いいえ。通常、これを Git サーバーで事前コミットとして統合して、ブランチ (main/prod) へのすべてのプッシュで運用リポジトリが更新されるようにすることができます。

リポジトリをエクスポートできますか?

ノートブック、フォルダー、またはリポジトリ全体をエクスポートできます。 ノートブック以外のファイルはエクスポートできません。 リポジトリ全体をエクスポートする場合、ノートブック以外のファイルは含まれません。 エクスポートするには、 Databricks CLIの workspace export コマンドを使用するか、ワークスペースAPIを使用します。

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

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

リポジトリを複製しようとすると、次の場合に "アクセス拒否" エラー メッセージが表示されることがあります。

  • Databricks は、Microsoft Entra ID 認証で Azure DevOps を使用するように構成されています。

  • Azure DevOps で条件付きアクセス ポリシーと Microsoft Entra ID 条件付きアクセス ポリシーを有効にしました。

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

詳細については、「 条件付きアクセス ポリシー」を参照してください。

Databricks Git フォルダーの内容は暗号化されていますか?

Databricks Git フォルダーの内容は、Databricks によってデフォルトのキーを使用して暗号化されます。 顧客管理キーを使用した暗号化は、Git 資格情報を暗号化する場合を除きサポートされません。

GitHub トークンは Databricks のどこにどのように格納されますか? 誰が Databricks からアクセスできますか?

  • 認証トークンは Databricks コントロール プレーンに格納され、Databricks の従業員は監査される一時的な資格情報を介してのみアクセスできます。

  • Databricks は、これらのトークンの作成と削除をログに記録しますが、その使用状況はログに記録しません。 Databricks には、Databricks アプリケーションによるトークンの使用を監査するために使用できる Git 操作を追跡するログがあります。

  • GitHub エンタープライズはトークンの使用状況を監査します。 他の Git サービスにも Git サーバー監査がある場合があります。

Git フォルダーはコミットの GPG 署名をサポートしていますか?

いいえ。

Git フォルダーは SSH をサポートしていますか?

いいえ、 HTTPSだけです.

CI/CD および MLOps

受信した変更によってノートブックの状態がクリアされる

ノートブックのソース コードを変更する Git 操作を行うと、セル出力、コメント、バージョン履歴、ウィジェットなどのノートブックの状態が失われます。 たとえば、 git pullはノートブックのソース コードを変更できます。 この場合、Databricks Git フォルダーは既存のノートブックを上書きして変更をインポートする必要があります。 git commitとpush 、または新しいブランチの作成はノートブックのソース コードに影響を与えないため、ノートブックの状態はこれらの操作で保持されます。

重要

MLflow拡張機能は、DBR 14.x以下のバージョンのGitフォルダーでは動作しません。

リポジトリに MLflow エクスペリメントを作成できますか?

MLflow エクスペリメントには、 ワークスペース と ノートブックの 2 種類があります。 2 種類の MLflow エクスペリメントの詳細については、「 MLflow エクスペリメントを使用してトレーニングの実行を整理する」を参照してください。

Git フォルダーでは、どちらのタイプの MLflow エクスペリメントに対してもmlflow.set_experiment("/path/to/experiment")を呼び出し、実行のログを記録できますが、そのエクスペリメントと関連する実行はソース管理にチェックインされません。

ワークスペース MLflow エクスペリメント

Databricks Git フォルダー (Git フォルダー) にワークスペース MLflow エクスペリメントを作成することはできません。 複数のユーザーが別々の Git フォルダーを使用して同じ ML コードで共同作業する場合、MLflow 実行のログは、通常のワークスペース フォルダーに作成された MLflow エクスペリメントに記録されます。

Notebook MLflow エクスペリメント

ノートブック エクスペリメントは、Databricks Git フォルダーに作成できます。 ノートブックを .ipynb ファイルとしてソース管理にチェックインする場合は、自動的に作成され、関連付けられた MLflow エクスペリメントに MLflow の実行をログに記録できます。 詳細については、 ノートブックエクスペリメントの作成に関する記事を参照してください。

MLflow エクスペリメントでのデータ損失を防ぐ

を使用して作成されたノートブックMLflow エクスペリメントDatabricks ソース コードを持つリモート リポジトリは 、一時的なストレージの場所に格納されます。これらのエクスペリメントは、ワークフローの実行後も最初は保持されますが、後で一時ストレージ内のファイルをスケジュールして削除する際に削除されるリスクがあります。 Databricks では、ワークスペース MLflow エクスペリメントと Jobs およびリモート Git ソースを使用することをお勧めします。

警告

ノートブックが含まれていないブランチに切り替えるたびに、関連するMLflow拡張機能データが失われるリスクがあります。 この損失は、前のブランチが 30 日以内にアクセスされない場合に永続的になります。

30 日間の有効期限が切れる前に不足しているエクスペリメント データを回復するには、ノートブック の名前を元の名前に戻し、ノートブックを開き、右側のウィンドウにある [エクスペリメント] アイコンをクリックすると (これも事実上 mlflow.get_experiment_by_name() API を呼び出します)、回復されたエクスペリメントと実行を確認できます。 30 日後、孤立した MLflow エクスペリメントは、GDPR コンプライアンス ポリシーを満たすために消去されます。

この状況を回避するために、Databricks では、リポジトリ内のノートブックの名前変更を完全に回避するか、ノートブックの名前を変更する場合は、ノートブックの名前を変更した直後に右側のウィンドウの [エクスペリメント] アイコンをクリックすることをお勧めします。

Git 操作の進行中にノートブック ジョブがワークスペースで実行されている場合はどうなりますか?

Git 操作の進行中の任意の時点で、リポジトリ内の一部のノートブックが更新され、他のノートブックは更新されていない可能性があります。 これにより、予期しない動作が発生する可能性があります。

たとえば、 notebook A %run コマンドを使用して notebook Z を呼び出すとします。Git 操作中で実行されているジョブが最新バージョンの notebook Aを起動したが、 notebook Z がまだ更新されていない場合、ノートブック A の %run コマンドによって古いバージョンの notebook Zが開始される可能性があります。 Git 操作中、ノートブックの状態は予測できず、ジョブが失敗したり、異なるコミットから notebook A と notebook Z を実行したりする可能性があります。

この状況を回避するには、代わりに Git ベースのジョブ (ソースがワークスペース パスではなく Git プロバイダー) を使用します。 詳細については、「 ジョブで Git を使用する」を参照してください。

リソース

Databricks ワークスペース ファイルの詳細については、「 ワークスペース ファイルとは」を参照してください。