更新をスケジュール

ソーステーブルが更新されたことがわかっている場合は、スタンドアロンのマテリアライズドビューまたはストリーミングテーブルを手動で更新できます。ただし、時間、ソーステーブルが更新されたとき、またはオーケストレーションによって更新のスケジュールを設定することもできます。

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

スケジュールを作成する

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

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

手法	説明	ユースケースの例
手動	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 を使用します。

情報については、更新 (マテリアライズドビューまたはストリーミングテーブル) を参照してください。

更新時にTrigger

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

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

制限事項

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

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

更新時にTriggerするパイプラインを作成する

ソースデータが変更されたときに自動的に更新されるパイプラインを作成するには、 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を参照してください。
カタログエクスプローラを使用してデータセットを表示します。スケジュールは、概要 tab の 更新ステータス の下に一覧表示されます。カタログエクスプローラとはを参照してください。

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

各時間間隔でスケジュール

この例では、毎時間更新をスケジュールします。EVERY句は、時間、日、および週単位の間隔をサポートしています。1 時間未満の間隔については、代わりに SCHEDULE CRON を使用してください。

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分刻みで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 Jobsを通じてオーケストレーションできます。このアプローチは、パイプラインの更新を、ジョブを使用した既存のオーケストレーションに統合します。

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

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

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

SQL
REFRESH STREAMING TABLE catalog.schema.sales;

注記

スタンドアロンのマテリアライズドビューとストリーミングテーブルの場合、ジョブを通じて更新をオーケストレーションしても、それらは継続的に実行されません。各ジョブのランでは、1 回の Trigger 更新が実行されます。ジョブによる継続的な実行は、LakeFlow Pipelinesにのみ適用されます。継続的なジョブで継続的なパイプラインをランするを参照してください。

このアプローチが適切なのは次の場合です。

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

SQLタスクでは、ジョブに添付されたSQL Warehouseと、更新を実行するServerlessコンピュートの両方を使用します。ストリーミングテーブル定義ベースのスケジュール設定で要件が満たされる場合は、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;

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

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

次の例では、既存のスケジュールを5分ごとに更新するように変更します。EVERY句は分単位の間隔をサポートしていないため、1時間未満のスケジュールにはCRON式を使用します。

SQL
ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE CRON '0 */5 * * * ?';

スケジュールまたはTriggerのドロップ

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

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

更新の状態を追跡する

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

SQL
DESCRIBE TABLE EXTENDED <table-name>;

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

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

ここから、データセット名の下にあるtabを使用して、以下を含むデータセットに関する情報を表示および編集できます。

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

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

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

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

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

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

更新のタイムアウト

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

STATEMENT_TIMEOUT が設定されている場合は、その値が使用されます。「STATEMENT_TIMEOUT」を参照してください。
そうでない場合は、コマンドの実行に使用されたSQLウェアハウスからのタイムアウトが使用されます。ステートメントのタイムアウトを参照してください。
warehouseにタイムアウトが設定されていない場合は、defaultの2日間が適用されます。

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

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

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

SQL
SET STATEMENT_TIMEOUT = 21600;

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 中にキャプチャされたタイムアウトを引き続き使用します。
warehouseのタイムアウトのみを変更しても、既存のスケジュールされた更新には影響しません。

重要

warehouseのタイムアウトを変更した後は、CREATE OR REFRESHを再度実行して、将来のスケジュールされた更新に新しいタイムアウトを適用してください。

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

備考

ベータ版

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

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

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

受信する通知、およびその受信方法について、幅広いオプションがあります。ジョブに通知を追加するを参照してください
SCHEDULE 句でスケジュールされたもの ： SQL 定義の SCHEDULE 句によってスケジュールされたパイプラインから通知を受け取るには、 Catalog Explorer で編集します。
1. カタログエクスプローラでデータセットを開きます。
2. 概要 tabの 更新スケジュール で、通知を受け取るスケジュールを編集するにはをクリックします。
3. その他のオプション で、通知を追加または変更します。
  
  スケジュールされた更新の起動、成功、または失敗時にEメールで通知を受け取るオプションがあります。defaultでは、所有者に失敗のみが通知されます。
  
  Eメールには、スケジュールをオーケストレートするシステム管理ジョブのラン履歴を表示するためのLinkが含まれています。「スケジュールされた更新のラン履歴を表示する」を参照してください。

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

UI を通じて実行する場合、パイプラインで使用されるServerless コンピュートは パフォーマンス最適化モード で実行されます。

SQL 定義でスケジュールされたパイプラインの場合は、カタログエクスプローラーの パフォーマンスの最適化 設定を使用して、Serverless コンピュートパフォーマンスモードを選択できます。この設定が無効になっている場合（default）、パイプラインは標準パフォーマンスモードを使用します。標準パフォーマンスモードは、起動のレイテンシがわずかに長くても許容されるワークロードのコストを削減するように設計されています。標準のパフォーマンスモードを使用するServerless ワークロードは、コンピュートの可用性と最適化されたスケジュールによって異なりますが、通常、Trigger されてから 4 分から 6 分以内に起動されます。

パフォーマンス最適化を有効にすると、パイプラインのパフォーマンスが最適化され、時間的制約のあるワークロードの Startup と実行が高速になります。

両方のモードで同じ SKU が使用されますが、標準パフォーマンスモードの方が消費する DBU が少ないため、コンピュート使用量が少なくなります。

備考

ベータ版

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

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

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

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

手動更新​

更新時にTrigger​

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

ジョブの SQL タスク​

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

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

スケジュールまたはTriggerのドロップ​

更新の状態を追跡する​

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

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

更新のタイムアウト​

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

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

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