LakeFlowジョブでGitを使用する

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

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

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

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

リモートGitリポジトリに保存されたコードを実行したタスクの実行履歴を表示すると、 タスク実行の詳細 ペインに、実行に関連付けられたコミット SHA などの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リポジトリに保存されたコードを実行したタスクの実行履歴を表示すると、 タスク実行の詳細 ペインに、実行に関連付けられたコミット 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回あたりのインポートファイル数

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

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

ベストプラクティス​

パターンを標準化する​

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

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

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

負荷管理​

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

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