Databricks SQLでストリーミングテーブルを使用する

Databricks 、 Databricks SQLを使用してデータを取り込むためにストリーミングテーブルを使用することをお勧めします。 ストリーミングテーブル は、ストリーミングまたは増分データ処理の追加サポートを備えたUnity Catalogに登録されたテーブルです。パイプラインはストリーミングテーブルごとに自動的に作成されます。ストリーミングテーブルを使用して、 Kafkaおよびクラウドオブジェクトストレージから増分データをロードできます。

注記

Delta Lake テーブルをストリーミングソースとシンクとして使用する方法については、Delta テーブルストリーミングの読み取りと書き込みを参照してください。

要件

ストリーミングテーブルを使用するには、以下の要件を満たす必要があります。

ワークスペースの要件 :

Databricks SQLで作成されたストリーミングテーブルは、サーバレスパイプラインによってサポートされています。この機能を使用するには、ワークスペースがサーバレスパイプラインをサポートしている必要があります。

サーバーレスが有効になっているDatabricksアカウント。詳細については、「サーバレスSQLウェアハウスを有効にする」を参照してください。
Unity Catalog が有効になっているワークスペース。詳細については、 Unity Catalogの使用を開始する」を参照してください。

コンピュート要件 :

次のいずれかを使用する必要があります。

Currentチャンネルを使用するSQLウェアハウス。
Databricks Runtime 13.3 LTS以降の標準アクセスモード (以前の共有アクセスモード) でコンピュート。
Databricks Runtime 15.4 LTS以降の専用アクセスモード (以前のシングルユーザーアクセスモード) を使用したコンピュート。

Databricks Runtime 15.3 以下では、専用のコンピュートを使用して、 他のユーザー が所有するストリーミングテーブルをクエリすることはできません。Databricks Runtime 15.3以下で専用のコンピュートを利用できるのは、ストリーミングテーブルを所有している場合のみです。テーブルの作成者が所有者です。

Databricks Runtime 15.4 LTS以降では、テーブル所有者でなくても、専用のコンピュートでパイプラインで生成されたテーブルのクエリをサポートしています。データフィルタリング操作を実行するために専用のコンピュートを使用する場合、サーバレスコンピュートリソースに対して料金が発生する可能性があります。専用コンピュートのきめ細かいアクセス制御を参照してください。

権限要件 :

USE CATALOG およびストリーミングテーブルを作成するカタログとスキーマに対するUSE SCHEMA権限。
ストリーミングテーブルを作成するスキーマに対するCREATE TABLE権限。
ストリーミングテーブルのソースデータを提供するテーブルまたは場所にアクセスする権限。

ストリーミングテーブルの作成

ストリーミングテーブルは、Databricks SQLのSQLクエリによって定義されます。ストリーミングテーブルを作成すると、ソーステーブルに現在存在するデータを使用してストリーミングテーブルが作成されます。その後、通常はスケジュールに従ってテーブルを更新し、ソーステーブルに追加されたデータをプルしてストリーミングテーブルに追加します。

ストリーミングテーブルを作成すると、テーブルの所有者とみなされます。

既存のテーブルからストリーミングテーブルを作成するには、次の例のようにCREATE STREAMING TABLEステートメントを使用します。

SQL
CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT product, price FROM STREAM raw_data;

この場合、ストリーミングテーブルsalesは、1 時間ごとに更新されるスケジュールで、 raw_dataテーブルの特定の列から作成されます。使用するクエリは ストリーミング クエリである必要があります。ストリーミングセマンティクスを使用してソースから読み取るには、 STREAMキーワードを使用します。

CREATE OR REFRESH STREAMING TABLEステートメントを使用してストリーミングテーブルを作成すると、初期データの更新と作成がすぐに開始されます。これらの操作では、DBSQL ウェアハウスコンピュートは消費されません。代わりに、ストリーミングテーブルは作成と更新の両方をサーバレスパイプラインに依存します。専用のサーバレスパイプラインは、ストリーミングテーブルごとにシステムによって自動的に作成され、管理されます。

Auto Loaderでファイルをロードする

ボリューム内のファイルからストリーミングテーブルを作成するには、 Auto Loader使用します。クラウドオブジェクトストレージからのほとんどのデータ取り込みタスクには、Auto Loader を使用します。Auto Loader とパイプラインは、クラウドストレージに到着するデータが増え続けるにつれて、それを増分的かつべき等的にロードするように設計されています。

Databricks SQLでAuto Loaderを使用するには、read_files 関数を使用します。次の例は、 Auto Loader を使用して大量の JSON ファイルをストリーミングテーブルに読み込む方法を示しています。

SQL
CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT * FROM STREAM read_files(
    "/Volumes/my_catalog/my_schema/my_volume/path/to/data",
    format => "json"
  );

クラウドストレージからデータを読み取るには、Auto Loader を使用することもできます。

SQL
CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
  's3://mybucket/analysis/*/*/*.json',
    format => "json"
  );

Auto Loaderの詳細については、Auto Loaderとはを参照してください。Auto LoaderでのSQL の使用について、例を挙げて詳しく知りたい場合は、オブジェクトストレージからのデータの読み込みを参照してください。

他のソースからのストリーミング取り込み

Kafka を含む他のソースからの取り込みの例については、「パイプラインでのデータのロード」を参照してください。

新しいデータのみを取り込む

デフォルトでは、 read_files関数はテーブルの作成中にソースディレクトリ内の既存のデータをすべて読み取り、更新ごとに新しく到着するレコードを処理します。

テーブルの作成時にソースディレクトリに既に存在するデータを取り込まないようにするには、 includeExistingFilesオプションをfalseに設定します。つまり、テーブルの作成後にディレクトリに到着したデータのみが処理されます。例えば：

SQL
CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    '/path/to/files',
    includeExistingFiles => false
  );

ランタイムチャンネルを設定する

SQLウェアハウスで作成したストリーミングテーブルはパイプラインを使用して自動更新されます。パイプラインはデフォルトでcurrentチャンネルのランタイムを使用します。リリースプロセスについては、Lakeflow Spark宣言型パイプラインリリースノートとリリースアップグレードプロセスを参照してください。

Databricks本番運用ワークロードにはcurrentチャンネルを使用することをおすすめします。新機能は最初にpreviewチャンネルにリリースされます。テーブルプロパティとしてpreview指定することで、パイプラインをプレビューチャンネルに設定して新機能をテストできます。このプロパティは、テーブルを作成するとき、または ALTER ステートメントを使用してテーブルが作成された後に指定できます。

次のコード例は、CREATE ステートメントでプレビューするチャンネルを設定する方法を示しています。

SQL
CREATE OR REFRESH STREAMING TABLE sales
  TBLPROPERTIES ('pipelines.channel' = 'preview')
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM raw_data;

ストリーミングテーブルの更新をスケジュールする

Databricks SQLストリーミングテーブルを、定義されたスケジュールに基づいて自動的に更新するように構成したり、アップストリームデータが変更されたときにトリガーするように構成したりできます。

スケジュールまたはトリガーを設定するには、次のいずれかを実行します。

ストリーミングテーブルを作成するときに、 SCHEDULE句を使用してスケジュールを構成します。
テーブルを作成するときに、 TRIGGER ON UPDATE句を使用してトリガーを構成します。
ALTER STREAMING TABLEステートメントを使用して、スケジュールまたはトリガーを追加または変更します。

注記

または、 CREATE OR REFRESH STREAMING TABLEまたはREFRESHステートメントのいずれかを含むジョブ内にタスクを作成し、他のジョブと同じようにオーケストレーションします。Lakeflowジョブを参照してください。

スケジュールを作成すると、Databricks は更新を処理するための新しいジョブを自動的に作成します。

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

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

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

機密データを非表示にする

ストリーミングテーブルを使用すると、テーブルにアクセスするユーザーから機密データを隠すことができます。 1 つの方法は、機密性の高い列または行を完全に除外するようにクエリを定義することです。あるいは、クエリを実行するユーザーの権限に基づいて、列マスクまたは行フィルターを適用することもできます。たとえば、グループHumanResourcesDeptに属していないユーザーに対してtax_id列を非表示にすることができます。これを行うには、ストリーミングテーブルの作成時にROW FILTERおよびMASK構文を使用します。詳細については、「行フィルターと列マスク」を参照してください。

ストリーミングテーブルの更新

ストリーミングテーブルの作成時に更新を自動的にスケジュールできます。ストリーミングテーブルを手動で更新することもできます。更新がスケジュールされている場合でも、いつでも手動更新を呼び出すことができます。更新は、ストリーミングテーブルとともに自動的に作成された同じパイプラインによって処理されます。

ストリーミングテーブルを更新するには:

SQL
REFRESH STREAMING TABLE sales;

DESCRIBE TABLE EXTENDEDで最新の更新のステータスを確認できます。

注記

タイムトラベルクエリを使用する前に、ストリーミングテーブルを更新する必要がある場合があります。

更新の仕組み

ストリーミングテーブルの更新では、最後の更新以降に到着した新しい行のみが評価され、新しいデータのみが追加されます。

各更新では、ストリーミングテーブルの現在の定義を使用して、この新しいデータを処理します。ストリーミングテーブル定義を変更しても、既存のデータは自動的に再計算されません。変更が既存のデータと互換性がない場合は (たとえば、データ型の変更など)、次の更新はエラーで失敗します。

次の例は、ストリーミングテーブル定義への変更が更新動作にどのような影響を与えるかを説明しています。

フィルターを削除しても、以前にフィルターされた行は再処理されません。
列の投影を変更しても、既存のデータの処理方法には影響しません。
静的スナップショットによる結合は、初期処理時のスナップショット状態を使用します。更新されたスナップショットと一致する遅れて到着したデータは無視されます。これにより、ディメンションが遅れると、ファクトが削除される可能性があります。
既存の列の CAST を変更するとエラーが発生します。

既存のストリーミングテーブルでサポートできない方法でデータが変更された場合は、完全な更新を実行できます。

ストリーミングテーブルのフルリフレッシュ

完全更新では、ソースで利用可能なすべてのデータが最新の定義で再処理されます。完全な更新によって既存のデータが切り捨てられるため、データの履歴全体が保持されない、または保持期間が短いソース ( Kafkaなど) で完全な更新を呼び出すことは推奨されません。ソース内でデータが利用できなくなった場合、古いデータを回復できない可能性があります。

例えば：

SQL
REFRESH STREAMING TABLE sales FULL;

ストリーミングテーブルのスケジュールを変更する

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 ( MATERIALIZED VIEWまたはSTREAMING TABLE )」を参照してください。

更新時にトリガー

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

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

制限事項

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

次の例は、ストリーミングテーブルを定義するときに更新時にトリガーを設定する方法を示しています。

更新時にトリガーを行うストリーミングテーブルを作成する

ソースデータが変更されたときに自動的に更新されるストリーミングテーブルを作成するには、 CREATE STREAMING TABLEステートメントに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 句を参照してください。

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

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

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

次の例は、スケジュールを使用してストリーミングテーブルを作成する方法を示しています。

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

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

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE EVERY 5 MINUTES
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

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

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

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

ジョブ内のSQLタスク

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

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

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

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

SQL
REFRESH STREAMING TABLE catalog.schema.sales;

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

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

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

既存のストリーミングテーブルにスケジュールを追加する

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

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>;

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

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

ここから、ストリーミングテーブル名の下のタブを使用して、ストリーミングテーブルに関する以下の情報を表示および編集できます。

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

更新のタイムアウト

長時間実行される更新はタイムアウトする可能性があります。2025 年 8 月 14 日以降に作成または更新されたストリーミングテーブルは、更新の実行に使用されたSQLウェアハウスに関連付けられたタイムアウトを使用します。ウェアハウスにタイムアウトが設定されていない場合は、デフォルトの 2 日が使用されます。

注記

ストリーミングテーブルは、 CREATE OR REFRESHステートメントを手動で実行する場合にのみタイムアウトを同期します。スケジュールされた更新では、最新のCREATE OR REFRESHからのタイムアウトが保持されます。

更新の SQL でSTATEMENT_TIMEOUT構成を使用してタイムアウトを明示的に設定できます。STATEMENT_TIMEOUTを参照してください。

ストリーミングテーブルへのアクセスを制御する

ストリーミングテーブルは、潜在的なプライベートデータの公開を回避しながら、データ共有をサポートするための豊富なアクセス制御をサポートしています。ストリーミングテーブルの所有者またはMANAGE権限を持つユーザーは、他のユーザーにSELECT権限を付与できます。ストリーミングテーブルへのSELECTアクセス権を持つユーザーは、ストリーミングテーブルによって参照されるテーブルへのSELECTアクセス権を必要としません。このアクセス制御により、基盤となるデータへのアクセスを制御しながらデータ共有が可能になります。

ストリーミングテーブルの所有者を変更することもできます。

ストリーミングテーブルに権限を付与する

ストリーミングテーブルへのアクセスを許可するには、 GRANTステートメントを使用します。

SQL
GRANT <privilege_type> ON <st_name> TO <principal>;

privilege_typeは次のいずれかになります。

SELECT - ユーザーはストリーミングテーブルをSELECTできます。
REFRESH - ユーザーはストリーミングテーブルをREFRESHできます。更新は所有者の権限を使用して実行されます。

次の例では、ストリーミングテーブルを作成し、ユーザーに選択権限と更新権限を付与します。

SQL
CREATE MATERIALIZED VIEW st_name AS SELECT * FROM source_table;

-- Grant read-only access:
GRANT SELECT ON st_name TO read_only_user;

-- Grand read and refresh access:
GRANT SELECT ON st_name TO refresh_user;
GRANT REFRESH ON st_name TO refresh_user;

Unity Catalogセキュリティ保護可能なオブジェクトに対する権限の付与の詳細については、 Unity Catalog権限とセキュリティ保護可能なオブジェクト」を参照してください。

ストリーミングテーブルから権限を取り消す

ストリーミングテーブルからのアクセスを取り消すには、 REVOKEステートメントを使用します。

SQL
REVOKE privilege_type ON <st_name> FROM principal;

ソーステーブルのSELECT権限が、ストリーミングテーブルの所有者、またはストリーミングテーブルでMANAGEまたはSELECT権限を付与されている他のユーザーから取り消された場合、またはソーステーブルが削除された場合でも、ストリーミングテーブルの所有者またはアクセスを許可されたユーザーは引き続きストリーミングテーブルをクエリできます。ただし、次の動作が発生します。

ストリーミングテーブルの所有者またはストリーミングテーブルにアクセスできなくなった他の人は、そのストリーミングテーブルをREFRESHできなくなり、ストリーミングテーブルは無効になります。
スケジュールを使用して自動化されている場合、次にスケジュールされているREFRESH失敗するか、実行されません。

次の例では、 read_only_userからSELECT権限を取り消します。

SQL
REVOKE SELECT ON st_name FROM read_only_user;

ストリーミングテーブルの所有者を変更する

Databricks SQLで定義されたストリーミングテーブルに対するMANAGE権限を持つユーザーは、カタログエクスプローラーを通じて新しい所有者を設定できます。新しい所有者は、自分自身、または サービスプリンシパルユーザー ロールを持つサービスプリンシパルになります。

Databricksワークスペースから、 カタログ をクリックしてカタログエクスプローラーを開きます。
更新するストリーミングテーブルを選択します。
右側のサイドバーの 「このストリーミングテーブルについて」 の下で、 所有者 を見つけてクリックします。編集。

注記

パイプライン設定で 実行をユーザーとして 変更して所有者を更新するように指示するメッセージが表示された場合、ストリーミングテーブルはDatabricks SQLではなくLakeFlow Spark宣言型パイプラインで定義されています。メッセージにはパイプライン設定へのリンクが含まれており、そこで実行ユーザーを変更できます。

ストリーミングテーブルの新しい所有者を選択します。

所有者は、自分が所有するストリーミングテーブルに対するMANAGE権限とSELECT権限を自動的に持ちます。サービスプリンシパルを自分が所有するストリーミングテーブルの所有者として設定していて、ストリーミングテーブルに対するSELECTまたはMANAGE権限を明示的に持っていない場合、この変更によりストリーミングテーブルへのすべてのアクセスが失われます。この場合、それらの権限を明示的に付与するように求められます。

「保存」 時に付与するには、 「MANAGE」権限 と 「SELECT」 権限の両方を選択します。
所有者を変更するには、 「保存」 をクリックします。

ストリーミングテーブルの所有者が更新されます。今後のすべての更新は、新しい所有者の ID を使用して実行されます。

所有者がソーステーブルに対する権限を失った場合

所有者を変更し、新しい所有者がソーステーブルにアクセスできない場合 (または、基礎となるソーステーブルに対するSELECT権限が取り消された場合)、ユーザーは引き続きストリーミングテーブルにクエリを実行できます。しかし：

ストリーミングテーブルをREFRESHすることはできません。
次にスケジュールされたストリーミングテーブルの更新は失敗します。

ソースデータにアクセスできなくなると更新ができなくなりますが、既存のストリーミングテーブルの読み取りが直ちに無効になるわけではありません。

ストリーミングテーブルからレコードを完全に削除する

備考

プレビュー

ストリーミングテーブルでのREORGステートメントのサポートはパブリックプレビュー段階です。

注記

ストリーミングテーブルでREORGステートメントを使用するには、 Databricks Runtime 15.4 以降が必要です。
REORGステートメントはどのストリーミングテーブルでも使用できますが、削除が有効になっているストリーミングテーブルからレコードを削除する場合にのみ必要です。コマンドは、投下が有効になっていないストリーミングテーブルで使用した場合には効果がありません。

GDPRコンプライアンスなどの削除を有効にしたストリーミングテーブルの基盤となるストレージからレコードを物理的に削除するには、ストリーミングテーブルのデータに対してvacuum操作を確実に実行するための追加のステップを実行する必要があります。

基礎となるストレージからレコードを物理的に削除するには:

ストリーミングテーブルのレコードを更新または削除します。
APPLY (PURGE)パラメーターを指定して、ストリーミングテーブルに対してREORGステートメントを実行します。たとえばREORG TABLE <streaming-table-name> APPLY (PURGE); 。
ストリーミングテーブルのデータ保持期間が経過するまで待ちます。デフォルトのデータ保持期間は 7 日間ですが、 delta.deletedFileRetentionDurationテーブルプロパティを使用して構成できます。「タイムトラベルクエリのデータ保持を構成する」を参照してください。
REFRESH ストリーミングテーブル。「ストリーミングテーブルの更新」を参照してください。 REFRESH操作から 24 時間以内に、レコードが完全に削除されるようにするために必要なVACUUM操作を含むパイプラインメンテナンスタスクが自動的に実行されます。

クエリ履歴を使用して実行を監視する

クエリ履歴ページを使用すると、クエリの詳細とクエリプロファイルにアクセスできます。これらは、パフォーマンスの悪いクエリや、ストリーミングテーブルの更新を実行するために使用されるパイプラインのボトルネックを特定するのに役立ちます。クエリ履歴とクエリプロファイルで利用できる情報の種類の概要については、「クエリ履歴」と「クエリプロファイル」を参照してください。

備考

プレビュー

この機能はパブリックプレビュー段階です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。「Databricks プレビューの管理」を参照してください。

ストリーミングテーブルに関連するすべてのステートメントはクエリ履歴に表示されます。 ステートメント ドロップダウンフィルターを使用して、任意のコマンドを選択し、関連するクエリを検査できます。すべてのCREATEステートメントの後には、パイプラインで非同期に実行されるREFRESHステートメントが続きます。REFRESHステートメントには通常、パフォーマンスの最適化に関する情報を提供する詳細なクエリプランが含まれます。

クエリ履歴 UI でREFRESHステートメントにアクセスするには、次のステップを使用します。

クリック左側のサイドバーにあるをクリックして、 書き込みー履歴 UIを開きます。
ステートメント ドロップダウン・フィルターから REFRESH チェック・ボックスを選択します。
クエリステートメントの名前をクリックすると、クエリの実行時間や集計されたメトリックなどの概要の詳細が表示されます。
クエリ プロファイルを開くには、[クエリプロファイルを表示 ] をクリックします。クエリプロファイルのナビゲートの詳細については、「クエリプロファイル」を参照してください。
必要に応じて、 [クエリソース] セクションのリンクを使用して、関連するクエリまたはパイプラインを開くことができます。

SQLエディターのリンクを使用するか、 SQLウェアハウスに接続されているノートブックからクエリの詳細にアクセスすることもできます。

外部クライアントからストリーミングテーブルにアクセスする

オープンAPIsをサポートしていない外部のDelta LakeまたはIcebergクライアントからストリーミングテーブルにアクセスするには、互換Modeを使用できます。互換Modeは、 Delta LakeまたはIcebergクライアントからアクセスできる読み取り専用バージョンのストリーミングテーブルが作成されます。

要件​

ストリーミングテーブルの作成​

Auto Loaderでファイルをロードする​

他のソースからのストリーミング取り込み​

新しいデータのみを取り込む​

ランタイムチャンネルを設定する​

ストリーミングテーブルの更新をスケジュールする​

機密データを非表示にする​

ストリーミングテーブルの更新​

更新の仕組み​

ストリーミングテーブルのフルリフレッシュ​

ストリーミングテーブルのスケジュールを変更する​

手動更新​

更新時にトリガー​

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

ジョブ内のSQLタスク​

既存のストリーミング テーブルにスケジュールを追加する​

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

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

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

更新のタイムアウト​

ストリーミングテーブルへのアクセスを制御する​

ストリーミングテーブルに権限を付与する​

ストリーミングテーブルから権限を取り消す​

ストリーミングテーブルの所有者を変更する​

所有者がソーステーブルに対する権限を失った場合​

ストリーミングテーブルからレコードを完全に削除する​

クエリ履歴を使用して実行を監視する​

外部クライアントからストリーミングテーブルにアクセスする​

その他のリソース​

要件