ストリーミング テーブルは、ストリーミングまたは増分データ処理の追加サポートを備えた Delta テーブルです。 ストリーミング テーブルは、パイプライン内の 1 つ以上のフローの対象にすることができます。
ストリーミング テーブルと具体化されたビューまたはビューを使用するタイミングのガイダンスについては、「 パイプラインとは」を参照してください。
ストリーミング テーブルは、次の理由からデータ インジェストに適しています。
- 各入力行は 1 回だけ処理されます。これは、インジェスト ワークロードの大部分をモデル化します (つまり、行をテーブルに追加またはアップサートすることによって)。
- 追記可能な大量のデータを処理できます。
また、ストリーミング テーブルは、行や期間を超えて推論したり、大量のデータを処理したり、待ち時間の短い処理を提供したりできるため、待機時間の短いストリーミング変換にも適しています。
次の図は、フローがストリーミング ソースから読み取り、パイプライン内のストリーミング テーブルに増分的に書き込む方法を示しています。
各更新で、ストリーミング テーブルに関連付けられているフローは、ストリーミング ソース内の変更された情報を読み取り、そのテーブルに新しい情報を追加します。
ストリーミング テーブルは、1 つのパイプラインによって所有および更新されます。 パイプラインのソース コードでストリーミング テーブルを明示的に定義します。 パイプラインによって定義されたテーブルは、他のパイプラインでは変更または更新できません。 1 つのストリーミング テーブルに追加する複数のフローを定義できます。
Azure Databricks は、ストリーミング テーブル処理をサポートする内部テーブルを作成します。 これらのテーブルは system.information_schema.tables に表示されますが、カタログ エクスプローラーやその他のワークスペース UI ページには表示されません。
Note
Lakeflow パイプラインの外部でスタンドアロン ストリーミング テーブルを作成すると、Azure Databricksテーブルの更新に使用されるパイプラインが作成されます。 ワークスペースの左側のナビゲーションから [ジョブ] と [パイプライン ] を選択すると、パイプラインを表示できます。 [ パイプラインの種類 ] 列をビューに追加できます。 パイプラインで定義されているストリーミング テーブルには、 ETLの種類があります。 スタンドアロン ストリーミング テーブルには、 MV/STの種類があります。
フローの詳細については、「 Lakeflow パイプライン フローを使用したデータの増分読み込みと処理」を参照してください。
インジェスト用のストリーミング テーブル
ストリーミング テーブルは、追加専用のデータ ソース用に設計され、入力を 1 回だけ処理します。 これにより、データが継続的に到着するインジェスト ワークロードに適しており、既存のレコードを再処理することなく確実にキャプチャする必要があります。 Azure Databricksでは、クラウド オブジェクト ストレージ (自動ローダーを使用) からストリーミング テーブルへの取り込みと、Apache Kafka、Azure Event Hubs、Google Pub/Sub などのストリーミング メッセージ バスからの取り込みがサポートされます。 インジェストの使い方とコード例については、「 パイプラインにデータを読み込む」を参照してください。
Note
時間の経過と同時に変化するソース データ (たとえば、ソースで更新または削除されたレコード) をストリーミングするには、 AUTO CDC を使用して、変更を追加するのではなく、ストリーミング テーブルに適用します。
データ キャプチャとスナップショットの変更を参照してください。
次の図は、追加専用ストリーミング テーブルのしくみを示しています。
ストリーミング テーブルに既に追加されている行は、パイプラインに対する後の更新では再クエリされません。 クエリを変更する場合 (たとえば、 SELECT LOWER (name) から SELECT UPPER (name))、既存の行は大文字に更新されませんが、新しい行は大文字になります。 完全更新をトリガーして、ソース テーブルから以前のすべてのデータを再クエリして、ストリーミング テーブル内のすべての行を更新できます。
ストリーミング テーブルと低遅延ストリーミング
ストリーミング テーブルは、境界付き状態での待機時間の短いストリーミング用に設計されています。 ストリーミング テーブルではチェックポイント管理が使用されるため、待機時間の短いストリーミングに適しています。 ただし、そのために、ストリームが自然に区切られていること、またはウォーターマークによって区切られていることが想定されています。
自然に境界付けられたストリームは、明確に定義された開始と終了を持つストリーミング データ ソースによって生成されます。 自然境界ストリームの例として、ファイルの最初のバッチが配置された後に新しいファイルが追加されないファイルのディレクトリからデータを読み取る方法があります。 ストリームは、ファイルの数が有限であり、すべてのファイルが処理された後にストリームが終了するため、境界付けされたと見なされます。
ウォーターマークを使用してストリームをバインドすることもできます。 構造化ストリーミングにおけるウォーターマークは、遅延データを処理する際に、システムが遅れたイベントを待機する期間を指定することで時間枠を完了と見なすメカニズムです。 透かしがない無制限のストリームは、メモリ圧力によりパイプラインが失敗する可能性があります。
可能な限り短い待機時間を必要とする運用ワークロードの場合は、パイプラインをリアルタイム モードで実行して、サブ秒のエンドツーエンドの待機時間でレコードを処理できます。
詳細については、以下を参照してください:
ストリーミング テーブルの制限事項
ストリーミング テーブルには、次の制限があります。
-
限られた進化: データセット全体を再計算せずにクエリを変更できます。 完全な更新がない場合、ストリーミング テーブルでは各行が 1 回しか表示されないため、異なるクエリで異なる行が処理されます。 たとえば、クエリのフィールドに
UPPER()を追加した場合、変更後に処理された行のみが大文字になります。 つまり、データセットで実行されているすべての以前のバージョンのクエリに注意する必要があります。 変更前に処理された既存の行を再処理するには、完全な更新が必要です。 - 状態管理: ストリーミング テーブルは待機時間が短く、自然に境界付けられたり、透かしで囲まれたりするストリームが必要です。 詳細については、「 ウォーターマークを使用したステートフル処理の最適化」を参照してください。
- 結合は再計算されません。 ストリーミング テーブルの結合は、ディメンションが変更されたときに再計算されません。 この特性は、"高速だが間違った" シナリオに適している可能性があります。 ビューを常に正しくする場合は、具体化されたビューを使用できます。 具体化されたビューは、ディメンションが変更されたときに自動的に結合を再計算するため、常に正しいです。 詳細については、「 具体化されたビュー」を参照してください。 ストリームを静的ディメンション テーブルに結合する例については、「 Stream-static joins」を参照してください。
-
CLONEサポートなし: ストリーミング テーブルは、ディープ クローンまたはシャロー クローンのソースまたはターゲットとして使用できません。 サポートされていないその他のコマンドについては、「 制限事項」を参照してください。 -
パイプラインを表示するために必要な
REFRESH特権: ストリーミング テーブルをバックアップするパイプラインを表示するには、管理者以外のユーザーには、パイプラインに対するアクセス許可に加えて、ストリーミング テーブルに対するREFRESH特権が必要です。 パイプラインとその出力を表示できるユーザーを参照してください。
