Databricks SQL で更新をスケジュールする

ソーステーブルが更新されたことがわかっている場合は、 Databricks SQLで作成されたパイプライン (マテリアライズドビューまたはストリーミングテーブル) を手動で更新できます。ただし、時間、ソーステーブルの更新時、またはオーケストレーションによって更新のスケジュールを設定することもできます。このページでは、パイプラインのスケジュールを作成する方法について説明します。

通知を作成したり、スケジュールされた更新のパフォーマンスモードを設定したりすることもできます。

スケジュールを作成する

定義されたスケジュールに基づいて自動的に更新されるように、またはアップストリームデータが変更されたときにトリガーされるように、Databricks SQL パイプラインを構成できます。次の表は、更新をスケジュールするためのさまざまなオプションを示しています。

手法	説明	使用例
手動	SQL `REFRESH`ステートメントまたはワークスペース UI を使用したオンデマンド更新。	開発、テスト、アドホック更新。
`TRIGGER ON UPDATE`	アップストリームデータが変更されたときにパイプラインが自動的に更新されるようにスケジュールします。	データ鮮度 SLA または予測不可能な更新期間を伴う本番運用ワークロード。
`SCHEDULE`	定義された時間間隔でパイプラインを更新するようにスケジュールします。	予測可能な時間ベースの更新要件。
ジョブ内のSQLタスク	更新はLakeFlow Jobsを通じて調整されます。	システム間の依存関係を持つ複雑なパイプライン。

更新をスケジュールした場合でも、更新されたデータが必要な場合はいつでも手動更新を実行できます。

手動更新

パイプラインを手動で更新するには、Databricks SQL から更新を呼び出すか、ワークスペース UI を使用します。

REFRESH statement
Workspace UI

Databricks SQL を使用してパイプラインを更新するには:

の中で SQL エディタで 、次のステートメントを実行します。
SQL
```
REFRESH MATERIALIZED VIEW <table-name>;
```
ストリーミングテーブルの場合は、 REFRESH STREAMING TABLEを使用します。

詳細については、 REFRESH ( MATERIALIZED VIEWまたはSTREAMING TABLE )」を参照してください。

更新時にトリガー

TRIGGER ON UPDATE句は、上流のソースデータが変更されたときにパイプラインを自動的に更新します。これにより、パイプライン間でスケジュールを調整する必要がなくなります。ユーザーが上流のジョブがいつ終了するかを知ったり、複雑なスケジュールロジックを維持したりする必要なく、データセットは最新の状態に保たれます。

これは、特にアップストリームの依存関係が予測可能なスケジュールで実行されない場合に、本番運用ワークロードに推奨されるアプローチです。更新時のトリガーを設定した後、パイプラインはそのソーステーブルを監視し、上流のソースのいずれかの変更が検出されると自動的に更新します。

制限事項

アップストリーム依存関係の制限: パイプラインは最大 10 個のアップストリームテーブルと 30 個のアップストリームビューを監視できます。依存関係を増やすには、ロジックを複数のパイプラインに分割します。
ワークスペースの制限: TRIGGER ON UPDATEを持つパイプラインはワークスペースあたり最大 1,000 個存在できます。 1,000 個を超える数が必要な場合は、Databricks サポートにお問い合わせください。
最小間隔: 最小トリガー間隔は 1 分です。

次の例は、パイプラインを定義するときに更新時にトリガーを設定する方法を示しています。

更新時にトリガーするパイプラインを作成する

ソースデータが変更されたときに自動的に更新されるパイプラインを作成するには、 CREATEステートメントにTRIGGER ON UPDATE句を含めます。

次の例では、顧客注文を読み取り、ソースordersテーブルが更新されるたびに更新するストリーミングテーブルを作成します。

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

スロットル更新頻度

アップストリームデータが頻繁に更新される場合は、 AT MOST EVERYを使用してビューの更新頻度を制限し、コンピュートコストを制限します。これは、ソーステーブルが頻繁に更新されるが、ダウンストリームのコンシューマがリアルタイムデータを必要としない場合に便利です。時間値の前にINTERVALキーワードが必要です。

次の例では、ソースデータがより頻繁に変更される場合でも、ストリーミングテーブルの更新を最大 5 分ごとに制限します。

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

スケジュールされた更新

更新スケジュールをパイプライン定義で直接定義して、一定の時間間隔でビューを更新できます。このアプローチは、データの更新頻度がわかっており、予測可能な更新タイミングが必要な場合に役立ちます。

更新スケジュールがある場合でも、データを更新したい場合はいつでも手動で更新を実行できます。

Databricks は、単純な間隔のSCHEDULE EVERYと正確なスケジュールのSCHEDULE CRONという 2 つのスケジュール構文をサポートしています。SCHEDULEキーワードとSCHEDULE REFRESHキーワードは意味的に同等です。

SCHEDULE句の構文と使用法の詳細については、 CREATE STREAMING TABLE SCHEDULE 句、またはCREATE MATERIALIZED VIEW SCHEDULE 句を参照してください。

スケジュールが作成されると、更新を処理するように新しい Databricks ジョブが自動的に構成されます。

スケジュールを表示するには、次のいずれかを実行します。

Databricks UI の SQL エディターからDESCRIBE EXTENDEDステートメントを実行します。「DESCRIBE TABLE」を参照してください。
カタログエクスプローラーを使用してデータセットを表示します。スケジュールは、 [概要] タブの [更新ステータス] に表示されます。「カタログエクスプローラーとは何ですか?」を参照してください。

次の例は、スケジュールを使用してマテリアライズドビューを作成する方法を示しています。

時間間隔ごとにスケジュールを設定する

この例では、5 分ごとに更新をスケジュールします。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

cronを使用したスケジュール

この例では、UTC タイムゾーンの 15 分ごとに更新をスケジュールします。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

ジョブ内のSQLタスク

パイプラインの更新は、 REFRESHコマンドを含むSQLタスクを作成することで、 LakeFlowジョブを通じて調整できます。このアプローチでは、パイプラインの更新を既存のジョブオーケストレーションワークフローに統合します。

ストリーミングテーブルを更新するためのジョブを作成するには 2 つの方法があります。

SQL エディターから : REFRESHコマンドを記述し、 [スケジュール] ボタンをクリックして、クエリから直接ジョブを作成します。
ジョブ UI から : 新しいジョブを作成し、SQL タスクタイプを追加し、 REFRESHBLEコマンドを使用して SQL クエリまたはノートブックをアタッチします。

次の例は、ストリーミングテーブルを更新するSQLタスク内のSQLステートメントを示しています。

SQL
REFRESH STREAMING TABLE catalog.schema.sales;

このアプローチは次のような場合に適しています。

複雑なマルチステップパイプラインには、システム間で依存関係があります。
既存のジョブオーケストレーションとの統合が必要です。
ジョブレベルのアラートとモニタリングが必要です。

SQLタスクはジョブに付属するSQLウェアハウスと更新を実行するサーバレスコンピュートの両方を使用します。ストリーミングテーブル定義ベースのスケジューリングを使用することで要件が満たされる場合は、 TRIGGER ON UPDATEまたはSCHEDULEに切り替えることでワークフローを簡素化できます。

既存のパイプラインにスケジュールを追加する

作成後にスケジュールを設定するには、 ALTER STREAMING TABLEまたはALTER MATERIALIZED VIEWステートメントを使用します。例えば：

SQL
-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

既存のスケジュールまたはトリガーを変更する

パイプラインにすでにスケジュールまたはトリガーが関連付けられている場合は、 ALTER SCHEDULEまたはALTER TRIGGER ON UPDATEを使用して更新構成を変更します。これは、あるスケジュールから別のスケジュールに変更する場合、あるトリガーから別のトリガーに変更する場合、またはスケジュールとトリガーを切り替える場合に適用されます。

次の例では、既存のスケジュールを 5 分ごとに更新するように変更します。

SQL
ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE EVERY 5 MINUTES;

スケジュールまたはトリガーを削除する

スケジュールを削除するには、 ALTER ... DROPを使用します。

SQL
ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

更新のステータスを追跡する

更新のステータスを確認するには、パイプライン UI でパイプラインを表示するか、データセットのDESCRIBE EXTENDEDコマンドによって返される 更新情報 を表示します。

SQL
DESCRIBE TABLE EXTENDED <table-name>;

あるいは、カタログエクスプローラーでデータセットを表示し、そこで更新ステータスを確認することもできます。

クリックサイドバーの カタログ 。
左側のカタログエクスプローラーツリーでカタログを開き、データセットが配置されているスキーマを選択します。
選択したスキーマの下の「 テーブル」 項目を開き、「ストリーミングテーブル」または「マテリアライズドビュー」をクリックします。

ここから、データセット名の下のタブを使用して、データセットに関する次のような情報を表示および編集できます。

ステータスと履歴を更新する
テーブルスキーマ
サンプルデータ (アクティブなコンピュートが必要です)
権限
このデータセットが依存するテーブルやその他のパイプラインを含むリネージ
使い方を知る
このデータセット用に作成したモニター

アクティブな更新を停止する

Databricks UI でアクティブな更新を停止するには、 パイプラインの詳細 ページで [ 停止] をクリックしてパイプラインの更新を停止します。 Databricks CLIまたはPOST /api/2.0/パイプライン/{pipeline_id}/stopを使用して更新を停止することもできます。パイプラインREST APIでの操作。

スケジュールされた更新の実行履歴を表示する

カタログエクスプローラーでデータセットを開くと、ワークスペースの右側の詳細ペインに 更新スケジュール が表示されます。スケジュール (たとえば、 1 時間ごと ) リンクをクリックすると、スケジュールを実行する (システム管理の) ジョブのジョブページに移動します。成功または失敗、所要時間など、過去 48 時間の実行のグラフを含む実行履歴を表示できます。特定の実行をクリックすると、詳細が表示されます。

このシステム管理ジョブは編集できません。スケジュールを変更するには、 CREATE OR REFRESHまたはALTERを使用してパイプラインの定義を編集します。「既存のスケジュールまたはトリガーを変更する」を参照してください。

更新のタイムアウト

パイプラインの更新は、実行時間を制限するタイムアウト付きで実行されます。2025 年 8 月 14 日以降に作成または更新された Databricks SQL パイプラインの場合、 CREATE OR REFRESHを実行して更新するとタイムアウトがキャプチャされます。

STATEMENT_TIMEOUTが設定されている場合は、その値が使用されます。STATEMENT_TIMEOUT を参照してください。
それ以外の場合は、コマンドの実行に使用されるSQLウェアハウスからのタイムアウトが使用されます。
ウェアハウスにタイムアウトが設定されていない場合は、デフォルトの 2 日が適用されます。

タイムアウトは最初の作成時に使用されますが、その後のスケジュールされた更新にも使用されます。

2025 年 8 月 14 日より前に最後に更新されたストリーミングテーブルの場合、タイムアウトは 2 日に設定されます。

例: 更新のタイムアウトを設定する データセットの作成または更新時にステートメントレベルのタイムアウトを設定することで、更新の実行を許可する時間を明示的に制御できます。

SQL
SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

これにより、マテリアライズドビューが 12 時間ごとに更新されるように設定され、更新に 6 時間以上かかる場合はタイムアウトになり、次にスケジュールされた更新を待ちます。

スケジュールされた更新がタイムアウトを処理する方法

タイムアウトは、 CREATE OR REFRESH明示的に実行した場合にのみ同期されます。

スケジュールされた更新は、最新のCREATE OR REFRESH中にキャプチャされたタイムアウトを使用して続行されます。
ウェアハウスのタイムアウトのみを変更しても、既存のスケジュールされた更新には影響しません。

重要

ウェアハウスのタイムアウトを変更した後、 CREATE OR REFRESH再度実行して、今後スケジュールされた更新に新しいタイムアウトを適用します。

スケジュールされた更新の通知を受け取る

備考

ベータ版

DDL スケジュール更新機能の通知はベータ版です。ワークスペース管理者は 、マテリアライズドビューおよびストリーミング テーブルプレビューのシステム管理ジョブをオプトインすることで、[ プレビュー] ページからこの機能へのアクセスを制御できます。「Databricks プレビューの管理」を参照してください。

パイプラインのスケジュールを作成すると、それを編集して通知を受け取ることができます。パイプラインをスケジュールする方法は複数あり、通知の受信は選択した方法によって異なります。

ジョブでスケジュール : LakeFlowジョブのSQLタスクから通知を取得するには、タスクを編集して通知を追加します。ジョブの SQL タスクを参照してください。

受信する通知とその受信方法には、さまざまなオプションがあります。ジョブに通知を追加するを参照してください
SCHEDULE句でスケジュールされています : SQL 定義のSCHEDULE句によってスケジュールされているパイプラインから通知を取得するには、カタログエクスプローラーでそれを編集します:
1. カタログエクスプローラーでデータセットを開きます。
2. 「概要」 タブの 「更新スケジュール」 で、通知を受け取りたいスケジュールを編集します。
3. [その他のオプション] で、通知を追加または変更します。
  
  スケジュールされた更新の開始、成功、または失敗時に電子メールで通知を受け取るオプションがあります。デフォルトでは、失敗した場合にのみ所有者に通知されます。
  
  この電子メールには、スケジュールを調整するシステム管理ジョブの実行履歴にアクセスできるリンクが含まれています。スケジュールされた更新の実行履歴の表示を参照してください。

スケジュールされた更新のパフォーマンスモードを選択します

パイプライン実行が UI を通じて実行するときに パフォーマンス最適化モード で使用されるサーバレスコンピュート。

SQL定義でスケジュールされたパイプラインの場合、カタログエクスプローラーの パフォーマンス最適化 設定を使用して、サーバレスコンピュートパフォーマンスモードを選択できます。この設定が無効になっている場合 (デフォルト)、パイプラインは標準パフォーマンスモードを使用します。標準パフォーマンスモードは、起動の遅延がわずかに長くても許容できるワークロードのコストを削減するように設計されています。標準パフォーマンスモードを使用するサーバーレスワークロードは、コンピュートの可用性と最適化されたスケジューリングに応じて、トリガーされてから通常 4 ～ 6 分以内に開始されます。

パフォーマンスの最適化を有効にすると、パイプラインのパフォーマンスが最適化され、時間に敏感なワークロードの起動と実行が高速化されます。

どちらのモードも同じSKUを使用しますが、標準パフォーマンスモードは、コンピュート使用量の低下を反映して消費する DBU が少なくなります。

備考

ベータ版

スケジュールされた更新のパフォーマンスモードの変更はベータ版です。ワークスペース管理者は 、マテリアライズドビューおよびストリーミング テーブルプレビューのシステム管理ジョブをオプトインすることで、[ プレビュー] ページからこの機能へのアクセスを制御できます。「Databricks プレビューの管理」を参照してください。

デフォルトでは、パイプラインは、UI で対話的に実行される場合、またはSQL タスクでスケジュールされる場合はパフォーマンス最適化モードを使用し、スケジュールされる場合は標準モードを使用します。定義内のSCHEDULE句によってスケジュールされたパイプラインのコンピュートモードを設定するには、カタログエクスプローラーでスケジュールを編集します。

カタログエクスプローラーでデータセットを開きます。
「概要」 タブの 「更新スケジュール」 で、変更したいスケジュールを編集します。
今後のスケジュールされた更新でパフォーマンス最適化モードを使用するには、「パフォーマンス の最適化」を オンにします。

スケジュールを作成する​

手動更新​

更新時にトリガー​

スケジュールされた更新​

ジョブ内のSQLタスク​

既存のパイプラインにスケジュールを追加する​

既存のスケジュールまたはトリガーを変更する​

スケジュールまたはトリガーを削除する​

更新のステータスを追跡する​

アクティブな更新を停止する​

スケジュールされた更新の実行履歴を表示する​

更新のタイムアウト​

スケジュールされた更新がタイムアウトを処理する方法​

スケジュールされた更新の通知を受け取る​

スケジュールされた更新のパフォーマンス モードを選択します​