Databricks アセット バンドルのデプロイ モード

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

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

開発モード

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

targets:
  dev:
    mode: development

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

  • ファイルまたはノートブックとしてデプロイされていないすべてのリソースの先頭にプレフィックス [dev ${workspace.current_user.short_name}] を付け、デプロイされた各ジョブとパイプラインに dev Databricks タグを付けます。

  • 関連するすべてのデプロイ済み Delta Live Tables パイプラインを 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

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

targets:
  prod:
    mode: production

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

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

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

    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

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

注：

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

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

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