Databricks アセット バンドルのデプロイ モード
この記事では、Databricks アセット バンドルのデプロイ モードの構文について説明します。 バンドルを使用すると、Azure Databricks ワークフローをプログラムで管理できます。 「Databricks アセット バンドルとは」を参照してください
CI/CD ワークフローでは、開発者は通常、さまざまなフェーズまたは "モード" でソリューションをコーディング、テスト、デプロイ、実行します。 一連のモードのもっとも単純な例としては、運用前の検証のための "開発" モードに検証後の成果物のための "運用" モードが続くというものがあります。 Databricks アセット バンドルには、これらの各モードに対応する既定の動作のオプション コレクションが用意されています。 特定のターゲットに対してこれらのビヘイビアーを使用するには、modeを設定するか、presetsを構成し、targets構成マッピングでターゲットにします。 targetsの詳細については、バンドル構成ターゲットのマッピングを参照してください。
開発モード
開発モードでバンドルをデプロイするには、まず、development に設定された mode マッピングを目的のターゲットに追加する必要があります。 たとえば、dev という名前のこのターゲットは開発ターゲットとして扱われます。
targets:
dev:
mode: development
databricks bundle deploy -t <target-name> コマンドを実行して開発モードでターゲットをデプロイすると、次のビヘイビアーが実装されます。これは、presets を使用してカスタマイズできます：
- ファイルまたはノートブックとしてデプロイされていないすべてのリソースの前にプレフィックス
[dev ${workspace.current_user.short_name}]が付き、デプロイされたそれぞれのジョブとパイプラインにdevAzure 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に設定して、ロックを再度有効にします。
運用モード
運用モードでバンドルをデプロイするには、まず、production に設定された mode マッピングを目的のターゲットに追加する必要があります。 たとえば、prod という名前のこのターゲットは、運用ターゲットとして扱われます。
targets:
prod:
mode: production
databricks bundle deploy -t <target-name> コマンドを実行して運用MODEのターゲットをデプロイすると、次のビヘイビアーが実装されます：
関連するすべてのデプロイ済み Delta Live Tables パイプラインに
development: falseのマークが付いていることを検証します。ターゲットで指定されている Git ブランチと現在の Git ブランチが等しいことを検証します。 ターゲットでの Git ブランチの指定は省略可能です。次のように
gitプロパティを追加して指定できます。git: branch: mainこの検証はデプロイ中に
--forceを指定することでオーバーライドできます。Databricks では、運用デプロイにサービス プリンシパルを使用することをお勧めします。 これを強制するには、サービス プリンシパルに
run_asを設定します。 「サービス プリンシパルを管理する」と「Databricks アセット バンドル ワークフローの実行 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 では、 targets の構成可能なプリセットがサポートされています。これにより、ターゲットのビヘイビアーをカスタマイズできます。 利用可能プリセットを次のテーブルにまとめて示します:
| プリセット | 説明 |
|---|---|
name_prefix |
リソース名の先頭に付加するプレフィックス文字列。 |
pipelines_development |
パイプラインを開発モードで実行するかどうか。 有効な値は true または falseです。 |
trigger_pause_status |
すべてのトリガーとスケジュールに適用する一時停止状態。 有効な値は PAUSED または UNPAUSEDです。 |
jobs_max_concurrent_runs |
同時実行ジョブの最大許容数。 |
tags |
ジョブとテストを含む、タグをサポートするすべてのリソースに適用されるキーと値のタグのセット。 Databricks Asset Bundlesは、 schema リソースのタグをサポートしていません。 |
Note
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