次の方法で共有

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

  • [アーティクル]

Databricks Git フォルダーと Git の統合には、次の各セクションに記載されている制限があります。 一般的な情報については、Databricks の制限をご覧ください。

ジャンプ先:

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

Azure Databricks には、リポジトリのサイズに適用される制限はありません。 ただし

  • 作業ブランチは 1 GB (ギガバイト) に制限されています。
  • Azure Databricks UI では、10 MB を超えるファイルを表示できません。
  • 個々のワークスペース ファイルには、個別のサイズ制限が適用されます。 詳細については、「制限」を参照してください。

Databricks では、リポジトリについて次のことが推奨されています。

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

Git 操作の場合、メモリ使用量は 2 GB に制限され、ディスク書き込みは 4 GB に制限されます。 この制限は操作ごとに適用されるため、現在のサイズが 5 GB の Git リポジトリをクローンしようとすると、エラーが発生します。 ただし、サイズが 3 GB の Git リポジトリを 1 回の操作でクローンし、後で 2 GB を追加する場合、次のプル操作は成功します。

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

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

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

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

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

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

Git フォルダーのワークスペース アクションは、ファイルの回復可能性によって異なります。 一部のアクションでは、 Trash フォルダーを介した復旧が許可されますが、そうでないアクションもあります。 以前にコミットされ、リモート ブランチにプッシュされたファイルは、リモート Git リポジトリの Git コミット履歴を使用して復元できます。 次の表は、各アクションの動作と回復可能性の概要を示しています。

アクション ファイルは回復可能ですか?
ワークスペース ブラウザーでファイルを削除する はい。 Trash フォルダーから
[Git フォルダー] ダイアログで新しいファイルを破棄する はい。 Trash フォルダーから
[Git フォルダー] ダイアログで変更したファイルを破棄する いいえ、ファイルは削除されています
reset (ハード) コミットされていないファイル変更の場合 いいえ、ファイルの変更は行われません
reset (ハード) コミットされていない新しく作成されたファイルの場合 いいえ、ファイルの変更は行われません
Git フォルダー ダイアログでブランチを切り替える はい(リモート Git リポジトリから)
Git フォルダー ダイアログからのその他の Git 操作 (コミットとプッシュなど) はい(リモート Git リポジトリから)
PATCH Repos API から /repos/id を更新する操作 はい(リモート Git リポジトリから)

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

Monorepo のサポート

Databricks は、monorepo をベースとする Git フォルダーを作成しないことを推奨しています。ここで、monorepo とは多数のプロジェクトにわたる何千ものファイルを含む大規模な単一組織の Git リポジトリです。

Git フォルダーでサポートされている資産の種類

Git フォルダーでは、特定の Azure Databricks 資産の種類のみがサポートされています。 サポートされている資産の種類は、シリアル化、バージョン管理、およびバッキング Git リポジトリへのプッシュが可能です。

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

資産の種類 詳細
ファイル ファイルはシリアル化されたデータで、ライブラリからバイナリ、コード、イメージまであらゆるものが含まれます。 詳細については、「ワークスペース ファイルとは」を参照してください
ノートブック ノートブックは、特に Databricks でサポートされているノートブック ファイル形式です。 ノートブックはシリアル化されないため、ファイルとは別の Azure Databricks アセット タイプと見なされます。 Git フォルダーは、ファイル拡張子 ( .ipynb など) またはファイル拡張子とファイルコンテンツ内の特別なマーカー (ソース ファイルの先頭にある # Databricks notebook source コメントなど) によってノートブック .py 決定します。
フォルダー フォルダーは Azure Databricks 固有の構造で、Git でのファイルの論理的なグループ化に関するシリアル化された情報を表します。 予想どおり、Azure Databricks Git フォルダーを表示したり、Azure Databricks CLI でアクセスしたりする場合、ユーザーはこれを "フォルダー" として認識します。

Git フォルダーで現在サポートされていない Azure Databricks 資産の種類は次のとおりです。

  • DBSQL クエリ
  • 警告
  • ダッシュボード (レガシ ダッシュボードを含む)
  • 実験
  • Genie スペース

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 リポジトリ内のアセットのファイル名を確認してください。 これらの競合するパターンを持つ名前のファイルを見つけた場合は、それらの名前を変更して操作をやり直してください。

Note

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

ノートブックの形式

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

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

ノートブックのソース形式 詳細
source .py、.scala、.r、.sql など、コード言語を示す標準のファイル サフィックスを持つ任意のコード ファイルを指定できます。 "source" ノートブックはテキスト ファイルとして扱われ、Git リポジトリにコミットされたときに関連付けられた出力は含まれません。
ipynb "ipynb" ファイルは .ipynb で終わります。また、構成されている場合、Databricks Git フォルダーからバッキング Git リポジトリに出力 (視覚化など) をプッシュできます。 .ipnynb ノートブックには、(.ipynb の py 部分に関係なく) Databricks ノートブックでサポートされている任意の言語のコードを含めることができます。

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

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

Note

"出力" とは

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

ファイル拡張子以外で、ノートブックが使っている形式を見分ける方法はありますか?

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

# Databricks notebook source

.ipynb ファイルの場合、ファイル サフィックスは、それが "ipynb" ノートブック形式であることを示すために使われます。

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

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

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

既定では、Git フォルダーの管理者設定では、.ipynb ノートブック出力のコミットは許可されていません。 ワークスペース管理者はこの設定を次のように変更できます。

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

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

    管理コンソール: Git フォルダーでの IPYNB 出力のエクスポートを許可する。

重要

出力を含めると、視覚化とダッシュボードの構成は .ipynb ファイル形式で保持されます。

IPYNB ノートブック出力成果物のコミットを制御する

.ipynb ファイルをコミットすると、Databricks により、出力のコミット方法を制御できる構成ファイルが作成されます (.databricks/commit_outputs)。

  1. .ipynb ノートブック ファイルはあっても、リポジトリに構成ファイルがない場合、Git Status モーダルを開きます。

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

    ノートブック コミット UI: commit_outputs ファイル ボタンを作成します。

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

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

    ノートブック エディター: ノートブックの出力の状態と制御をコミットします。

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

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

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

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

  1. ワークスペースでソース ノートブックを開いてください。

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

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

  3. モーダル ダイアログで、[Jupyter Notebook 形式 (.ipynb)] を選択し、[変更] をクリックしてください。

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

さらに、以下を実行できます。

  • 新しい .ipynb ノートブックを作成します。
  • 差分をコード差分 (セル内のコード変更) または未処理の差分 (コード変更は JSON 構文として表示され、ノートブックの出力がメタデータとして含まれます) として表示します。

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

よく寄せられる質問: Git フォルダーの構成

Azure Databricks リポジトリの内容はどこに格納されますか?

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

Git フォルダーではオンプレミスまたはセルフホステッドの Git サーバーはサポートされていますか?

サーバーがインターネットでアクセス可能な場合、Databricks Git フォルダーは、GitHub Enterprise、Bitbucket サーバー、Azure DevOps Server、GitLab 自己管理型統合をサポートしています。 Git フォルダーとオンプレミスの Git サーバーとの統合の詳細については、Git フォルダー用の Git Proxy サーバーに関するページを参照してください。

インターネットからアクセスできない Bitbucket サーバー、GitHub Enterprise Server、または GitLab 自己管理型サブスクリプション インスタンスとの統合については、Azure Databricks アカウント チームにお問い合わせください。

Git フォルダーでサポートされている Databricks アセットの種類は何ですか?

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

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

はい。 リポジトリに追加したファイルが、Git によって追跡されないようにしたい場合は、.gitignore ファイルを作成するか、リモート リポジトリからクローンしたものを使用して、拡張子を含むファイル名を追加します。

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

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

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

Git フォルダーでは Git のサブモジュールはサポートされていますか?

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

Git フォルダーは Azure Data Factory (ADF) でサポートされていますか?

はい。

ソース管理

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

これは、Azure Databricks ノートブックのソース ファイルにノートブック ダッシュボード情報が格納されないことに起因する、現時点における制限です。

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

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

Git フォルダーではブランチのマージがサポートされていますか?

はい。 pull request を作成し、Git プロバイダーを通じてマージすることもできます。

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

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

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

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

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

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

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

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

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

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

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

  • Azure Databricks は、Microsoft Entra ID 認証で Azure DevOps を使用するように構成されています。
  • Azure DevOps の条件付きアクセス ポリシーと Microsoft Entra ID 条件付きアクセス ポリシーを有効にしました。

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

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

Azure AD トークンを含む許可リスト

Azure DevOps での認証に Azure Active Directory (AAD) を使用する場合、既定の許可リストでは 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 をサポートしていますか?

いいえ、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 フォルダーでは機能しません。

リポジトリに MLflow 実験を作成できますか?

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

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

ワークスペース MLflow 実験

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

ノートブック MLflow 実験

Databricks Git フォルダーにノートブック実験を作成できます。 ノートブックを .ipynb ファイルとしてソース管理にチェックインすると、自動的に作成され関連付けられた MLflow 実験に MLflow 実行を記録できます。 詳細については、「ノートブック実験の作成」をご覧ください。

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

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

警告

ノートブックを含まないブランチに切り替えると、関連する MLflow 実験データが失われるリスクがあります。 この損失は、30 日以内に以前のブランチにアクセスしなかった場合に永続的になります。

30 日間の有効期限が切れる前に失われた実験データを復旧するには、ノートブックの名前を元の名前に戻し、ノートブックを開き、右側ペインの「実験」アイコンをクリックする (これは mlflow.get_experiment_by_name() API を効果的に呼び出すことにもなります) ことで、復旧された実験と実行を確認できます。 30 日後、孤児となった MLflow 実験は、GDPR コンプライアンス ポリシーを満たすために消去されます。

このような事態を防ぐため、Databricks では Repos 内のノートブック名の変更をすべて回避するか、ノートブック名を変更した直後に右側ペインの「実験」アイコンをクリックすることをお勧めします。

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 ワークスペースの詳細については、「ワークスペース ファイルとは」を参照してください。