メインコンテンツまでスキップ

Databricks Asset Bundle のデプロイ モード

この記事では、 Databricks Asset Bundle デプロイ モードの構文について説明します。 バンドルを使用すると、Databricks ワークフローをプログラムで管理できます。 「Databricks アセット バンドルとは」を参照してください。

CI/CD ワークフローでは、開発者は通常、さまざまなフェーズまたは モードで ソリューションのコーディング、テスト、デプロイ、および実行を行います。 たとえば、最も単純なモードには、本番運用前の検証のための 開発 モードと、検証された成果物のための 本番運用 モードがあります。 Databricks Asset Bundles には、これらの各モードに対応するデフォルトの動作のオプションのコレクションが用意されています。 これらの動作を特定のターゲットに使用するには、targets構成マッピングでターゲットにmodeを設定するか、ターゲットのpresetsを設定します。targetsに関する情報については、バンドル構成ターゲットのマッピングを参照してください。

開発モード​

バンドルを開発モードでデプロイするには、まず development に設定された mode マッピングを目的のターゲットに追加する必要があります。 たとえば、dev という名前のこのターゲットは開発ターゲットとして扱われます。

YAML
targets:
  dev:
    mode: development

databricks bundle deploy -t <target-name> コマンドを実行して開発モードでターゲットをデプロイすると、次の動作が実装され、プリセットを使用してカスタマイズできます。

  • ファイルまたはノートブックとしてデプロイされていないすべてのリソースの先頭にプレフィックス [dev ${workspace.current_user.short_name}] を付け、デプロイされた各ジョブとパイプラインに dev Databricks タグを付けます。
  • デプロイされたすべての関連する DLT パイプラインを development: trueとしてマークします。
  • bundle deploy コマンドの関連呼び出しで --compute-id <cluster-id> を使用できるようにします。これにより、関連するバンドル構成ファイルで既に指定されているすべての既存のクラスター定義がオーバーライドされます。bundle deploy コマンドの関連呼び出しで --compute-id <cluster-id> を使用する代わりに、ここで compute_id マッピングを設定するか、bundle マッピングの子マッピングとして、使用するクラスターの ID に設定できます。
  • デプロイされたリソース (ジョブや品質モニターなど) のすべてのスケジュールとトリガーを停止します。 個々のジョブのスケジュールとトリガーの一時停止を解除するには、 schedule.pause_status を UNPAUSEDに設定します。
  • デプロイされたすべてのジョブで並列実行を有効にして、イテレーションを高速化します。 個々のジョブの並列実行を無効にするには、 max_concurrent_runs を 1に設定します。
  • デプロイメント・ロックを無効にして、反復処理を高速化します。 このロックにより、開発モードで発生する可能性が低いデプロイの競合が防止されます。 bundle.deployment.lock.enabledをtrueに設定して、ロックを再度有効にします。

本番運用モード​

バンドルを本番運用モードでデプロイするには、まず、 mode マッピングを productionに設定して目的のターゲットに追加する必要があります。 たとえば、この prod という名前のターゲットは、本番運用ターゲットとして扱われます。

YAML
targets:
  prod:
    mode: production

databricks bundle deploy -t <target-name> コマンドを実行して本番運用モードでターゲットをデプロイすると、次の動作が実装されます。

  • 関連するすべてのデプロイ済み DLT パイプラインが development: falseとしてマークされていることを検証します。

  • 現在の Git ブランチが、ターゲットで指定された Git ブランチと等しいことを検証します。 ターゲットでの Git ブランチの指定はオプションであり、次のように追加の git プロパティを使用して実行できます。

    YAML
    git:
      branch: main

    この検証は、デプロイ中に --force を指定することでオーバーライドできます。

  • Databricks では、本番運用のデプロイにはサービスプリンシパルを使用することをお勧めします。 これを強制するには、 run_as をサービス プリンシパルに設定します。 「サービスプリンシパルの管理」および「Databricks Asset Bundles ワークフローの実行 ID の指定」を参照してください。サービスプリンシパルを使用しない場合は、次の追加の動作に注意してください。

    • artifact_path、file_path、root_path、state_path のマッピングが特定のユーザーに上書きされていないことを検証します。
    • run_as と permissions のマッピングが指定されていることを検証して、どの ID にデプロイ用の特定の権限があるかを確認します。

  • modeマッピングを developmentに設定する前述の動作とは異なり、modeマッピングを production に設定しても、関連するバンドル構成ファイルに指定されている既存のクラスター定義 (例えば、--compute-id <cluster-id> オプションや compute_id マッピングを使用) はオーバーライドできません。

カスタムプリセット​

Databricks Asset Bundles は、 ターゲットの構成可能なプリセットをサポートしているため、ターゲットの動作をカスタマイズできます。 使用可能なプリセットを次の表に示します。

Preset

説明

name_prefix

リソース名の先頭に追加するプレフィックス文字列。

pipelines_development

パイプラインが開発モードであるかどうか。 有効な値は true または falseです。

trigger_pause_status

すべてのトリガーとスケジュールに適用する停止するステータス。 有効な値は PAUSED または UNPAUSEDです。

jobs_max_concurrent_runs

ジョブに許容される並列 実行の最大数。

tags

キーのセット タグは、タグをサポートするすべてのリソース (ジョブとエクスペリメントを含む) に適用されます。 Databricks アセット バンドルは、 schema リソースのタグをサポートしていません。

source_linked_deployment

将来の使用のために予約されています。 デプロイ中に作成されたリソースが、ワークスペースのコピーではなくワークスペース内のソース ファイルを指すかどうか。

注記

modeとpresetsの両方が設定されている場合、プリセットはデフォルトのモード動作を上書きし、個々のリソースの設定はプリセットを上書きします。たとえば、スケジュールが UNPAUSEDに設定されていて、 trigger_pause_status プリセットが PAUSEDに設定されている場合、スケジュールの一時停止は解除されます。

次の例は、 devという名前のターゲットのカスタムプリセット設定を示しています。

YAML
targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance
に最終更新