メインコンテンツまでスキップ
に最終更新

LakeFlowジョブでGitを使用する

ジョブタスクは、リモートのGitリポジトリからソースコードを直接チェックアウトできます。

次のタスク タイプはリモートGitリポジトリをサポートします。

  • ノートブック
  • Pythonスクリプト
  • SQLファイル
  • データ構築ツール（dbt）プロジェクト

ジョブ内のすべてのタスクは、リモートリポジトリ内の同じコミットを参照する必要があります。ジョブの実行が開始されると、Databricks は指定されたブランチまたはコミットのスナップショットを取得し、その実行内のすべてのタスクが同じバージョンのコードを使用するようにします。

リモートGitリポジトリに保存されたコードを実行したタスクの実行履歴を表示すると、 タスク実行の詳細 ペインに、実行に関連付けられたコミット SHA などのGit詳細が表示されます。 タスク実行履歴の表示を参照してください。

注記

リモートGitリポジトリを使用するように設定されたタスクは、ワークスペース ファイルに書き込むことができません。 これらのタスクは、ドライバノードに接続された一時ストレージに一時データを書き込み、ボリュームまたはテーブルに永続データを書き込む必要があります。

Gitリポジトリ ソースの使用とGitフォルダーの使用。​

このページでは、リモートGitリポジトリからソース コードを直接プルできるタスクについて説明します。 ワークスペースは、ワークスペース内のフォルダーがGitリポジトリと同期されるGitフォルダーと呼ばれる機能もサポートしています。 タスクは、Gitフォルダをソースとして使用できます。ただし、リポジトリとの同期を管理する必要があります。ここで説明されているようにリモートGitリポジトリを使用すると、新しいソース (利用可能な場合) がジョブ実行時に自動的に取得されます。

Databricksは、開発中の迅速な反復とテストのためにのみ、Gitフォルダ内のワークスペースパスを参照することを推奨します。ステージングおよび本番運用ジョブの場合は、代わりにリモートGitリポジトリを参照するようにタスクを構成します。

ジョブ用のGitプロバイダーを設定する​

ジョブ UI には、リモートGitリポジトリを設定するためのダイアログがあります。 このダイアログは、 [ジョブの詳細] ペインの [Git ] 見出しの下、または Git プロバイダーを 使用するように構成されたタスクからアクセスできます。ダイアログにアクセスするには、 ジョブ詳細 ペインの 「Git設定の追加」 をクリックします。

Git ダイアログ (タスク構成中にアクセスされた場合は Git情報 というラベルが付いています) で、次の詳細を入力します。

  • Gitリポジトリ URL 。
  • ドロップダウンリストから Gitプロバイダー を選択してください。
  • Git 参照 フィールドに、実行するソース コードのバージョンに対応するブランチ、タグ、またはコミットの識別子を入力します。
  • ドロップダウンメニューから ブランチ 、 タグ 、または コミット を選択してください。

以下のいずれか1つだけを指定してください。

  • branch : ブランチの名前。例: main 。
  • タグ : タグの名前。例: release-1.0.0 。
  • コミット : 特定のコミットのハッシュ、例: e0056d01 。
注記

ダイアログに次のようなメッセージが表示される場合があります。 「このアカウントの Git 認証情報がありません。認証情報を追加してください 。」リモートGitリポジトリを参照として使用する前に、リモート Git リポジトリを構成する必要があります。 GitフォルダーのGit統合の設定を参照してください。

リモートGitリポジトリに保存されたコードを実行したタスクの実行履歴を表示すると、 タスク実行の詳細 パネルに、実行に関連付けられたコミット SHA などのGit詳細が表示されます。 タスク実行履歴の表示を参照してください。

大規模リポジトリ向けのスパースチェックアウト​

大規模なリポジトリの場合は、スパース チェックアウトを使用して、リポジトリ全体ではなく特定のディレクトリのみをインポートできます。 スパースチェックアウトは、ジョブ実行ごとのチェックアウト時間とリソース使用量を削減します。

しかし、不適切な設定はキャッシュの断片化を引き起こし、ワークスペース全体の実行時間を低下させる可能性があります。このセクションでは、スパースチェックアウトを使用する際に発生する可能性のあるトレードオフと問題点について説明します。

Databricksがリポジトリのチェックアウトをキャッシュする方法​

Databricksは、以下の4つの値に基づいて各Gitチェックアウトをキャッシュします。

  • ワークスペース
  • リポジトリのURL
  • 正確なコミットハッシュ
  • 疎なチェックアウトパターンのフィンガープリント（フォルダパスの正確なセット）

4つの条件すべてに一致するジョブ実行は、キャッシュエントリを再利用し、そのエントリは最大1週間有効です。例えば、3つの異なるジョブがあり、それらすべてが同じ基準を持っている場合、新しいコミットが行われるまで（または1週間後まで）、リポジトリへの同じキャッシュが使用されます。

固有のスパースチェックアウトパターンごとに、個別のフィンガープリントが生成され、したがって個別のキャッシュエントリが作成されます。20人のユーザーがそれぞれ自分のパターンにカスタムフォルダを追加すると、システムは20個の異なるキャッシュキーを作成し、共有フォルダツリーを20回インポートするため、ワークスペースへの負荷が増大します。20 個のフォルダすべてを含む単一の疎なチェックアウト パターンを作成することで (たとえば、 は親フォルダです)、単一のキャッシュがより頻繁に機能し、ジョブのパフォーマンスが向上します。その代償として、チェックアウト時に扱うファイルの数が増えます。

スパースチェックアウトを使用するかどうかを決定する​

以下の両方の条件を満たす場合にのみ、スパースチェックアウトを有効にしてください。

  • サイズ ：リポジトリのサイズが大きい（例えば、ファイル数が2,500を超えている）。
  • 安定したターゲット設定 ：ターゲットブランチの更新頻度が低い（例えば、1時間に1回以下のコミット）。自動化されたCI/CDワークフローによって急速に変化するブランチは避けてください。

スパースチェックアウトを採用する場合、組織は以下のパターン戦略のいずれか、または両方を採用する必要があります。

  • 標準化 ：キャッシュヒット率を最大化するために、組織全体で共有するチェックアウトパターンを3つ以下に抑える。
  • マイクロターゲティング ：各パターンが少数のファイルを対象とするように構造化する。最高のパフォーマンスを得るには、対象とするファイル数を200個未満に抑えてください。

これらは輸入税率を最小限に抑えるのに役立ちます。

輸入税率を計算する​

スパースチェックアウトを有効にする前に、 1時間あたりのファイル インポート率を予測してください。制限はワークスペースレベルで、すべてのジョブとユーザーに適用されます。

1時間あたりのファイル数 = 1時間あたりのジョブ実行数 × キャッシュミス率 × ミス1回あたりのインポートファイル数

要素

それを動かすものは何か

1時間あたりのジョブ実行数

全ユーザーにおけるトリガー頻度

キャッシュミス率

ターゲットブランチでのコミット頻度と固有のスパースパターンの数

ミスごとにインポートされたファイル

リポジトリの合計サイズまたはスパースチェックアウトサブセットのサイズ

例 : 180 実行/時間 × 10% ミス率 × 6,000 ファイル/ミス = 108,000 ファイル/時間

あなたの結果を以下の基準値と比較してください。

1時間あたりのインポートファイル数

予想されるワークスペースへの影響

15万未満

通常動作

15万～30万

パフォーマンスが低下しました。一部のジョブでは遅延や失敗が発生する可能性があります。

30万以上

作業が確実に完了しない。

ベストプラクティス​

パターンを標準化する​

  • 実施事項 ：リポジトリごとに、承認済みのスパースパターンを3つ以下公開する。共通のパターンを使用することで、負荷を軽減し、キャッシュヒット率を最大化できます。
  • 禁止事項 ：チームごとにカスタムパターンを許可すること。フォルダが1つ増えるだけでも、新しいキャッシュエントリが作成され、完全な再インポートがトリガーされます。

コミットの変動を管理する​

  • 実行すべきこと ：ジョブを安定版リリースブランチに向ける。バッチ処理はスケジュールされたリリースウィンドウにマージされるため、複数の実行で同じキャッシュされたコミットが共有されます。
  • 避けるべきこと ： masterやmainのような頻繁に更新されるブランチで疎なチェックアウトを使用すること。キャッシュは正確なコミットハッシュに基づいているため、新しいコミットが行われるたびにキャッシュが無効になり、ジョブ実行ごとに完全な再インポートが発生します。

負荷管理​

  • 推奨事項 : 大きなバイナリ、生成されたアーティファクト、およびデータ ファイルをソース コントロールから削除して、リポジトリのサイズを無条件に削減します。
  • してはいけないこと ：冗長なジョブを高頻度で実行したままにしないこと。継続的な実行を必要としないジョブについては、トリガー頻度を低く設定するか、スケジュールをずらすか、同じチェックアウトを共有するジョブを統合してください。

リリースブランチを使用してコミットの変動を管理する​

ジョブがmasterやmainのような動きの速いブランチをターゲットにする場合、コミットハッシュが頻繁に変更されるため、ほぼすべての実行でキャッシュミスが発生します。固定スケジュールで更新される専用のリリースブランチを使用することで、キャッシュヒット率が向上します。

すべてのジョブを1時間ごとのリリースブランチに指定することで、その時間内に実行されるすべてのジョブは同じコミットハッシュに解決され、同じキャッシュエントリを共有します。

リリースブランチを設定するには：

  1. Gitリポジトリに存続期間の長いブランチ (例: release-candidate ) を作成します。
  2. このブランチをmasterに一致するように、毎時0分などの固定スケジュールで自動的に更新します。
  3. Git を利用したジョブのターゲット Git 参照としてrelease-candidateを使用するように設定してください。

実施前に以下のトレードオフを検討してください。

考慮

説明

コミットラグ

ジョブは最大1時間遅れのコードに対して実行されますmaster 。ほとんどのバッチ処理には適していますが、最新のコミットを必要とするジョブには適さない場合があります。

失敗のタイミング

リリース カット ジョブが失敗した場合、ブランチはその時間更新されず、ジョブは前のコミットに対して実行を継続します。 Databricksは、カットジョブに関するアラートを設定することを推奨しています。

例：GitHub Actionsで自動化する​

次のGitHub Actionsワークフローは、時間ごとのリリース ブランチ カットを自動化します。

ステップ 1 : .github/workflows/cut-release-branch.ymlファイルをリポジトリにコミットします:

YAML
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

ステップ 2 : GitHub Actions手動でトリガーして、 release-candidateブランチが作成されたことを確認します。

ステップ 3 : 既存のジョブを更新して、ターゲット Git 参照としてrelease-candidateを使用するようにします。

Jobs API を使用してスパースチェックアウトを有効にする​

スパースチェックアウトを有効にするには、ジョブの作成または更新時に、 git_sourceブロックの中にsparse_checkoutブロックを含めます。

JSON
{
  "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内の各文字列は、リポジトリのルートからの相対ディレクトリパスです。指定された各ディレクトリ内のすべてのファイルがチェックアウトに含まれます。

このページの見出し