ソース テーブルが更新されたときにジョブをトリガーする

テーブル更新トリガーを使用すると、ソース テーブルが更新されたときにジョブの実行をトリガーできます。 この機能を使用すると、継続的に実行されるクラスターやテーブルを更新するプロセスに関する知識がなくても、新しいデータの準備ができたときにジョブを実行できます。

テーブル更新トリガーのしくみ

テーブル更新トリガーはテーブルの更新をチェックし、テーブルが更新されるとジョブが実行されます。 トリガーは、1 つのテーブルが更新されたとき、またはトリガーによって監視されているすべてのテーブルが更新されたときに実行できます。 テーブルの更新トリガーでは、テーブルの一覧表示とストレージの場所からの更新の読み取りに関連するクラウド プロバイダーのコスト以外の追加コストは発生しません。

テーブル更新トリガーは、更新、マージ、削除などのデータ変更について 1 つ以上のテーブルを監視するように構成できます。 これらのテーブルには、Unity カタログ Delta および Iceberg マネージド テーブル、Delta Lake によってサポートされる Unity カタログ外部テーブル、具体化されたビュー、ストリーミング テーブル、およびサポートされているテーブルに依存する Unity カタログ ビューまたはメトリック ビューを指定できます。 複数のテーブルを選択する場合、一部またはすべてのテーブルが更新されたときにジョブをトリガーするかどうかを指定できます。

OpenSharingのテーブルやビュー、システムテーブルにもトリガーを設定することができます。 OpenSharing テーブルとシステム テーブルへのトリガーの追加を参照してください。

Requirements

ジョブの 「Run as」 フィールドで設定されたプリンシパルは、トリガーが監視するすべてのオブジェクトに対して SELECT 権限を持つ必要があります。これは、トリガーが各オブジェクトのメタデータや変更履歴を読み取り、更新を検出するためです。 これは、サポートされているすべてのソースに適用されます:

  • Unity Catalogのテーブル: テーブルに対する SELECT、およびそのカタログとスキーマに対する USE CATALOG と USE SCHEMA が必要です。
  • Unity Catalog ビュー: ビューの基となるテーブル上の SELECT。
  • OpenSharing の共有オブジェクトとシステム テーブル: 共有オブジェクトまたはシステム テーブル上の SELECT。

もし Run as principalが監視対象オブジェクトに SELECT を持っていなければ、トリガーは評価に失敗し、ジョブは実行されません。 ジョブの実行ユーザーを確認または変更するには、ジョブ実行時の実行ユーザーの構成を参照してください。

テーブル更新トリガーを追加する

テーブル更新トリガーを既存のジョブに追加するには:

  1. ワークスペースの左側のナビゲーションで、[ ジョブ] と [パイプライン] をクリックします。

  2. ジョブの一覧で、トリガーを追加するジョブの名前をクリックします。

  3. 右側のウィンドウの [ スケジュールとトリガー] で、[トリガーの 追加] をクリックします。

  4. [トリガーの種類] で、[ テーブルの更新] を選択します。

  5. [ テーブル] で、更新プログラムを監視するテーブルを追加します。

    複数のテーブルを選択した場合は、[すべてのテーブルが更新されたとき、または任意のテーブルが更新されたときにジョブの実行をトリガーするかどうかを指定する場合にトリガーする] でオプションを構成します。

  6. (省略可能)[詳細設定] をクリックして、詳細オプションを構成 します。

    • トリガー間の最小待機時間 (秒): 前回の実行の完了後、次の実行をトリガーするまでの最小待機時間です。 この期間中に更新されたテーブルは、待機時間の経過後にのみ実行をトリガーします。 監視対象テーブルが更新された場合でも、Azure Databricks は実行をトリガーする前にこの時間待機します。
    • 最後の変更後の待機時間 (秒単位): テーブルの更新後に実行をトリガーするまでの待ち時間。 この期間中に追加のテーブルが更新され、タイマーがリセットされます。 この設定は、テーブルの更新がバッチで行われ、すべてのテーブルが更新された後にバッチ全体を処理する必要がある場合に使用できます。

    注

    両方のオプションが使用されている場合、トリガーはトリガー間の最小時間を待機し、最後の変更後に設定された時間を待機します。 たとえば、最小時間が 120 秒で、最後の変更が 60 秒後に待機している場合、最初の 60 秒以内にテーブルの更新が行われても、少なくとも 120 秒が経過するまで実行はトリガーされません。 さらに、1 つの更新プログラムが 5 秒で、もう 1 つの更新プログラムが 115 秒に入った場合、最後の変更後の待機は、175 秒後まで実行がトリガーされないことを意味します。

  7. 構成を検証するには、[ テスト トリガー] をクリックします。

  8. [保存] をクリックします。

注

ジョブ API からテーブル更新トリガーを構成することもできます。 trigger、jobs/create、またはjobs/update操作にjobs/reset オブジェクトを追加します。

このトリガーを後で編集、一時停止、または削除するには、[ジョブの詳細] ウィンドウの [スケジュールとトリガー] セクションを使用します。 「 既存のトリガーを管理する」を参照してください。

OpenSharing テーブルとシステム テーブルにトリガーを追加する

ローカル テーブルに加えて、 OpenSharing テーブルと システム テーブルを使用してワークスペースと共有されているデータを監視するようにテーブル更新トリガーを構成できます。 たとえば、新しい課金レコードがシステム テーブルに格納されたときや、プロバイダーが共有テーブルを更新するたびに、ジョブをトリガーできます。

次の共有オブジェクトでトリガーできます。

  • OpenSharing テーブル
  • OpenSharing ビュー
  • OpenSharing メトリックビュー
  • OpenSharing のマテリアライズド ビュー
  • OpenSharing ストリーミング テーブル
  • システム テーブル

「 テーブル更新を追加」トリガー の手順に従い、監視したい共有テーブル、ビュー、システムテーブルを選択します。

ファイル イベントを使用したテーブル更新トリガー

パフォーマンスとスケーラビリティを最大限に高めるには、テーブルが格納されている外部の場所で ファイル イベントを有効にします 。 この 1 回限りのセットアップ手順により、テーブル更新トリガーの効率が向上し、パフォーマンスの高い 自動ローダー や ファイル到着トリガーなど、他の機能のロックが解除されます。

ファイル イベントが有効になっている場合、Databricks では、クラウド プロバイダーの変更通知を使用してインジェスト メタデータが自動的に追跡されるため、テーブルの更新が迅速かつ効率的になります。

ファイルイベントは、トリガーが10テーブル以上を監視するために必要です。 表がどのように トリガーリミットにカウントされるかをご覧ください。

テーブルがメタストア ルート レベルのストレージ内にある場合は、最初にテーブルを 外部の場所に変換してから、その場所で ファイル イベントを有効にします 。

ファイル イベントに関する一般的な質問については、「 ファイル イベントに関する FAQ」を参照してください。

テーブル更新トリガーに関連付けられているジョブ パラメーター

ジョブにテーブル更新トリガーを使用する場合、3 つの新しい動的値参照をジョブのパラメーター値として使用できます。

  • {{job.trigger.table_update.updated_tables}} - 最後のジョブの実行以降に更新されたテーブルの JSON リスト。
  • {{job.trigger.table_update.`<catalog.schema.table>`.commit_timestamp.iso_datetime}} - ジョブの実行をトリガーした最新のコミット タイムスタンプ。
  • {{job.trigger.table_update.`<catalog.schema.table>`.version}} - ジョブの実行をトリガーした最新のコミット バージョン。

commit_timestampとversionには、動的値参照の複数のバージョンがあります。 監視対象の各テーブルには、データが必要なテーブルの完全修飾名を持つ <catalog.schema.table> があります。 トリガーで監視されているテーブルが 1 つしかない場合は、 <catalog.schema.table>のない値が表示されます。 たとえば、 {{job.trigger.table_update.commit_timestamp.iso_datetime}}を使用できます。

ジョブ パラメーターの詳細については、「ジョブの パラメーター化」を参照してください。

失敗したテーブル更新トリガーの通知を受信する

テーブル更新トリガーの評価に失敗した場合に通知を受け取る場合は、ジョブの失敗時に電子メールまたはシステムの送信先通知を構成します。 「ジョブについての通知を追加する」をご覧ください。

制限事項

テーブル更新トリガーには、 次の制限があります。

  • トリガーは最大25テーブルを監視できます。 10以上のテーブルを監視するには、監視される各テーブルごとに ファイルイベント を有効にする必要があります。 表がどのように トリガーリミットにカウントされるかをご覧ください。
  • ファイル イベントのない場所に存在するテーブルの場合、テーブル更新トリガーを使用して最大 1,000 個のジョブを構成できます。
  • OpenSharing オブジェクトまたはシステム テーブルでは、ワークスペースごとに最大 1,000 個のテーブル更新トリガーを作成できます。
  • クロスレギュラトリードメインのOpenSharingは、テーブル更新トリガーにはサポートされていません。

Unity カタログ ビューのトリガーには、次の追加の制限があります。

  • テーブル更新トリガーでは、テーブル更新トリガーでもサポートされているテーブルに依存する Unity カタログ ビューまたはメトリック ビューの監視のみがサポートされます。 なお、次のビューはサポートされていません:

    • read_filesを使用するビュー (ファイルを読み取るサポートされているテーブルから読み取ることができますが、read_filesを直接使用することはできません)。
    • Unity カタログにないテーブルに依存するビュー。
    • フェデレーション テーブルに依存するビュー。

  • サポートされていない依存関係を含むビューのトリガーの作成は引き続き成功しますが、サポートされていない依存関係が更新されるとジョブの実行はトリガーされません。

  • テーブル更新トリガーは、ビューの依存テーブルに対する変更を監視し、いずれかの依存テーブルが更新された場合にビューが更新されたと見なします。 ビュー定義によってフィルター処理されたデータ変更に対してジョブ実行がトリガーされる可能性があります。

  • ビューのソーステーブルは、各テーブルでファイルイベントが有効な場合、1トリガーあたり25テーブルの上限に含まれます。 ファイルイベントが無効な場合、その上限は10です。

    • 例えば、ビューが26テーブルに依存している場合、テーブル更新トリガーで使用することはできません。 同様に、それぞれが14個のテーブルに依存する2つのビューを持つトリガーは、28個のテーブルとしてカウントされます。

テーブルがトリガーリミットにカウントされる仕組み

テーブルの制限はトリガーが監視する物理テーブルに適用され、選択したオブジェクトの数には適用されません。

  • 各テーブル、マテリアライズドビュー、またはストリーミングテーブルは1つのテーブルとしてカウントされます。
  • 各ビューやメトリックビューは、依存するソーステーブルの数としてカウントされます。 ソーステーブルは各ビューごとに別々にカウントされるため、2つの監視対象ビューが依存するテーブルは2回カウントされます。

10以上のテーブルを監視するには、監視対象のビューのソーステーブルを含むすべての監視テーブルで ファイルイベントを有効にし ます。 これらのテーブルのいずれかにファイルイベントが有効でない場合、10個を超えるテーブルを監視するトリガーは保存できず、評価に失敗します。 これらのテーブルのいずれかでファイルイベントが後で無効化されると、ファイルイベントを再有効化するか、トリガーを10テーブル以下に減らすまでトリガーは評価されません。

  • 最終更新: