ジョブ タスクは、リモート Git リポジトリから直接ソース コードをチェックアウトできます。
次のタスクの種類では、リモート Git リポジトリがサポートされています。
- Notebooks
- Python スクリプト
- SQL ファイル
- データ ビルド ツール (dbt) プロジェクト
ジョブ内のすべてのタスクは、リモート リポジトリ内の同じコミットを参照する必要があります。 ジョブの実行が開始されると、Azure Databricksは指定されたブランチまたはコミットのスナップショットを取得し、その実行内のすべてのタスクで同じバージョンのコードが使用されるようにします。
リモート Git リポジトリに格納されているコードを実行するタスクの実行履歴を表示すると、[ タスク実行の詳細 ] ウィンドウには、実行に関連付けられているコミット SHA などの Git の詳細が表示されます。 タスク実行履歴の表示を参照してください。
注
リモート Git リポジトリを使用するように構成されたタスクは、ワークスペース ファイルに書き込むことができません。 これらのタスクでは、ドライバー ノードに接続されているエフェメラル ストレージに一時データを書き込み、永続データをボリュームまたはテーブルに書き込む必要があります。
Git リポジトリ ソースの使用と Git フォルダーの使用。
このページでは、リモート Git リポジトリからソース コードを直接プルできるタスクについて説明します。 ワークスペースでは、 Git フォルダーと呼ばれる機能もサポートされています。この機能では、ワークスペース内のフォルダーが Git リポジトリと同期されます。 タスクでは、ソースとして Git フォルダーを使用できます。 ただし、リポジトリとの同期を管理する必要があります。 ここで説明するようにリモート Git リポジトリを使用すると、ジョブの実行時に新しいソース (使用可能な場合) が自動的にプルされます。
Azure Databricksでは、開発時の迅速な反復とテストのためにのみ、Git フォルダー内のワークスペース パスを参照することをお勧めします。 ステージング ジョブと運用ジョブの場合は、代わりにリモート Git リポジトリを参照するようにタスクを構成します。
ジョブの Git プロバイダーを構成する
ジョブ UI には、リモート Git リポジトリを構成するためのダイアログが表示されます。 このダイアログには、Git 見出しの下の [ジョブの詳細] ウィンドウから、または Git プロバイダーを使用するように構成されたタスクからアクセスできます。 ダイアログにアクセスするには、[ジョブの詳細] ウィンドウで [Git 設定の追加] をクリックします。
Git ダイアログ (タスク構成中にアクセスした場合は Git 情報というラベルが付いた) で、次の詳細を入力します。
- Git リポジトリの URL。
- ドロップダウン リストから Git プロバイダー を選択します。
- Git 参照フィールドに、実行するソース コードのバージョンに対応するブランチ、タグ、またはコミットの識別子を入力します。
- ドロップダウンから ブランチ、 タグ、または コミット を選択します。
次のいずれかを指定する必要があります。
-
branch: ブランチの名前 (例:
main)。 -
tag: タグの名前 (例:
release-1.0.0)。 -
commit: 特定のコミットのハッシュ (たとえば、
e0056d01)。
注
ダイアログに次のメッセージが表示されることがあります。 このアカウントの Git 資格情報がありません。資格情報を追加します。 参照として使用する前に、リモート Git リポジトリを構成する必要があります。 Git フォルダーの統合を構成する方法を参照してください。
リモート Git リポジトリに格納されているコードを実行するタスクの実行履歴を表示すると、[ タスクの実行の詳細 ] パネルには、実行に関連付けられているコミット SHA を含む Git の詳細が表示されます。 タスク実行履歴の表示を参照してください。
大規模なリポジトリのスパース チェックアウト
大規模なリポジトリの場合は、完全なリポジトリではなく、スパース チェックアウトを使用して特定のディレクトリのみをインポートできます。 スパース チェックアウトにより、ジョブの実行ごとのチェックアウト時間とリソース使用量が削減されます。
ただし、不適切な構成ではキャッシュの断片化が発生し、ワークスペース全体の実行時間が低下する可能性があります。 このセクションでは、スパース チェックアウトを使用するときに発生する可能性があるトレードオフと問題について説明します。
Azure Databricks はリポジトリチェックアウトをどのようにキャッシュするのか
Azure Databricksは、次の 4 つの値に基づいて各 Git チェックアウトをキャッシュします。
- Workspace
- リポジトリ URL
- 正確なコミットハッシュ
- スパース チェックアウト パターンのフィンガープリント (フォルダー パスの正確なセット)
4 つの条件すべてに一致するジョブ実行では、キャッシュ エントリが再利用されます。キャッシュ エントリは最大 1 週間有効です。 たとえば、3 つの異なるジョブがあり、すべてが同じ条件を持つ場合、新しいコミット (1 週間後) が発生するまで、リポジトリに対して同じキャッシュが使用されます。
一意のスパース チェックアウト パターンごとに、個別のフィンガープリントが作成されるため、個別のキャッシュ エントリが作成されます。 20 人のユーザーがそれぞれ自分のパターンにカスタム フォルダーを追加した場合、システムは 20 個の個別のキャッシュ キーを作成し、共有フォルダー ツリーを 20 回インポートし、ワークスペースの負荷を乗算します。 20 個のフォルダー (親フォルダーなど) をすべて含む単一のスパース チェックアウト パターンを作成すると、1 つのキャッシュがより頻繁に動作し、ジョブのパフォーマンスが向上します。 トレードオフは、チェックアウト内のファイルの数が多くなります。
スパース チェックアウトを使用するかどうかを決定する
ユース ケースが次の両方の条件を満たしている場合にのみ、スパース チェックアウトを有効にします。
- サイズ: リポジトリが大きい (たとえば、2,500 ファイルを超えています)。
- 安定したターゲット設定: ターゲット ブランチは頻繁に更新されません (たとえば、1 時間あたり約 1 コミット以下)。 CI/CD ワークフローの自動化により、急激に変化するブランチは避けてください。
スパース チェックアウトを使用する場合、組織は次のパターン戦略のいずれかまたは両方を採用する必要もあります。
- 標準化: 組織全体で 3 つ以下の共有チェックアウト パターンを使用して、キャッシュ ヒットを最大化します。
- マイクロターゲット: それぞれが少数のファイルを対象とするようにパターンを構成します。 最適なパフォーマンスを得る場合は、200 個未満のファイルをターゲットにしてください。
これらは、インポートレートを最小限に抑えるのに役立ちます。
インポートレートを計算する
スパース チェックアウトを有効にする前に、予想される 1 時間あたりのファイルの インポート率を見積もってください。 制限は、すべてのジョブとユーザーにワークスペース レベルで適用されます。
1 時間あたりのファイル数 = 1 時間あたりのジョブの実行×キャッシュ ミス率×ミスごとにインポートされたファイル
| 要因 | 何がそれを駆動するか |
|---|---|
| 1 時間あたりのジョブ実行数 | すべてのユーザーのトリガー頻度 |
| キャッシュ ミス率 | ターゲット ブランチでのコミット頻度と一意のスパース パターンの数 |
| ミスごとにインポートされたファイル | リポジトリの合計サイズまたはスパース チェックアウト のサブセット サイズ |
例: 180 回の実行/時間× 10% ミス率× 6,000 ファイル/ミス = 108,000 ファイル/時間
結果を次のしきい値と比較します。
| 1 時間あたりにインポートされたファイル | 予想されるワークスペースへの影響 |
|---|---|
| 150,000 未満 | 通常の操作 |
| 150,000 – 300,000 | パフォーマンスの低下。 ジョブによっては、遅延や失敗が発生する場合があります。 |
| 300,000 以上 | ジョブは確実に完了しません。 |
ベスト プラクティス
パターンを標準化する
- 実行: リポジトリごとに 3 つ以下の承認されたスパース パターンを発行します。 共有パターンは、読み込みを統合し、キャッシュ ヒットを最大化します。
- しない: チームごとのカスタム パターンを許可します。 追加のフォルダーが 1 つでも、新しいキャッシュ エントリが作成され、完全な再インポートがトリガーされます。
コミット チャーンの管理
- Do: ジョブを安定したリリース ブランチに向ける。 バッチはスケジュールされたリリース ウィンドウにマージされるため、複数の実行で同じキャッシュされたコミットが共有されます。
-
使用しないでください:
masterやmainなどの頻繁に更新されるブランチでスパースチェックアウトを。 キャッシュは正確なコミット ハッシュに基づいているため、新しいコミットのたびにキャッシュが無効になり、ジョブの実行ごとに完全な再インポートが行われます。
負荷の管理
- 実行: ソース管理から大きなバイナリ、生成された成果物、およびデータ ファイルを削除して、リポジトリのサイズを無条件に小さくします。
- しない: 冗長ジョブを高頻度で実行したままにします。 継続的な実行を必要としないジョブのトリガー頻度を下げ、スケジュールをずらすか、同じチェックアウトを共有するジョブを統合する。
リリース ブランチを使用してコミット チャーンを管理する
ジョブが master や mainなどの移動が速いブランチをターゲットにすると、コミット ハッシュが頻繁に変更され、ほぼすべての実行でキャッシュ ミスが発生します。 固定スケジュールで更新する専用リリース ブランチを使用すると、キャッシュ ヒット率が向上します。
すべてのジョブを 1 時間ごとのリリース ブランチにポイントすることで、その時間内のすべての実行は同じコミット ハッシュに解決され、同じキャッシュ エントリを共有します。
リリース ブランチを構成するには:
- Git リポジトリに有効期間の長いブランチ (
release-candidateなど) を作成します。 -
masterに一致するように、このブランチを毎正時などの固定スケジュールで自動的に更新します。 - ターゲットの Git リファレンスとして
release-candidateを使用するように Git ベースのジョブを構成します。
実装する前に、次のトレードオフを確認してください。
| 考慮事項 | 説明 |
|---|---|
| コミットの遅延 | ジョブは、 masterから最大 1 時間遅れてコードに対して実行されます。 ほとんどのバッチ ワークロードでは許容されますが、最新のコミットを必要とするジョブには適さない場合があります。 |
| エラー ウィンドウ | リリースカットジョブが失敗した場合、その時間中ブランチは更新されず、ジョブは前のコミットに対して実行を続けます。 Databricks では、カット ジョブに関するアラートを推奨します。 |
例: GitHub Actionsを使用して自動化する
次のGitHub Actionsワークフローは、時間単位のリリース ブランチ カットを自動化します。
手順 1: .github/workflows/cut-release-branch.yml ファイルをリポジトリにコミットする:
name: Cut Hourly Release Candidate
on:
schedule:
- cron: '0 * * * *'
workflow_dispatch:
jobs:
update-branch:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Checkout main branch
uses: actions/checkout@v4
with:
ref: main
fetch-depth: 0
- name: Update release-candidate branch
run: |
git push origin HEAD:release-candidate --force
Step 2: GitHub アクションを手動でトリガーして、release-candidate ブランチが作成されていることを確認します。
手順 3: ターゲット Git 参照として release-candidate を使用するように既存のジョブを更新します。
ジョブ API を使用してスパース チェックアウトを有効にする
スパース チェックアウトを有効にするには、ジョブの作成時または更新時にsparse_checkout内にgit_source ブロックを含めます。
{
"git_source": {
"git_url": "https://github.com/example/my-repo",
"git_provider": "gitHub",
"git_branch": "release-candidate",
"sparse_checkout": {
"patterns": ["src/models", "src/utils"]
}
}
}
patterns内の各文字列は、リポジトリ ルートに対する相対ディレクトリ パスです。 指定された各ディレクトリ内のすべてのファイルがチェックアウトに含まれます。