DLT の推奨ワークロード
この記事では、Databricks での DLT の推奨ワークロードについて説明します。
データ取り込み
DLT は、チェンジデータキャプチャ (CDC) フィードなど、変更を含む追加専用ソース とソース からデータを取り込むことができます。 ストリーミングテーブルは、両方のタイプのソース データに対する機能をサポートします。
追加専用データソースからデータを取り込む
ストリーミングテーブルは、追加専用データを取り込む場合に推奨されます。 追加専用とは、新しいデータのみがソース データに追加され、既存のデータは更新または削除されないことを意味します。 追加専用データの例を次に示します。
- テーブル プロパティが
delta.appendOnly = trueの Delta テーブル。 - 新しいファイルを定期的に受信するクラウドストレージの場所。
- イベントを含む Kafka トピック。
DLT とストリーミングテーブルを使用したデータの取り込み (例を含む) の詳細については、「 DLT を使用したデータのロード」を参照してください。
単一の追加専用ソースからデータを取り込む
ストリーミングテーブルは、任意の追加専用データソースからデータを取り込むことができます。
複数の追加専用ソースからデータを取り込む
また、複数の追加専用データソースからストリーミングテーブルにデータを取り込むこともできます。 たとえば、複数の Kafka トピックのイベントを 1 つのストリーミングテーブルに書き込むことができます。 これを行うには、ストリーミングテーブルのクエリを 1 つのソースから読み取り、もう 1 つのソースのクエリで 追加フローを使用するように定義します。
Ingest ヒストリカルデータ from an append-only ソース
バックフィル は、追加専用ソース からデータを取り込む既存のデータセットがあり、ヒストリカルデータをデータセットに一度だけ追加したい場合に使用できます。これを行うには、追加フロー クエリを使用してヒストリカル データを読み込みます。 「バックフィル」を参照してください。
Process チェンジデータフィード and database スナップショット
Databricks では、DLT を使用して、1 つ以上のテーブルからの順不同の変更のシーケンスを含むチェンジデータフィード (CDF) を処理することをお勧めします。 Deltaチェンジデータフィードは、Debezium、Qlik 、Amazon DMS などのシステムに加えて、 テーブルによって生成されます。Python または SQL を使用して、DLT でチェンジデータフィードを処理できます。
また、Databricks では、チェンジデータフィードの代わりに、Oracle データベース、MySQLデータベース、データウェアハウスから生成されたスナップショットなどのデータベース スナップショットを処理する必要がある場合にも、DLT を使用することをお勧めします。データベース・スナップショットの処理は、DLT Python インターフェースでサポートされています。
CDF を処理するには、 APPLY CHANGES API を使用します。 CDC は APPLY CHANGES API でどのように実装されますか?を参照してください。
データベース スナップショットを処理するには、 APPLY CHANGES FROM SNAPSHOT API を使用します。 CDC は APPLY CHANGES FROM SNAPSHOT API でどのように実装されますか?を参照してください。
データの変換
DLTは、データを変換するための2つのソリューションを提供します。マテリアライズドビューは、常に正しい結果を提供し、必要に応じてソースデータを自動的に再処理するため、デフォルトの選択肢として適しています。 ストリーミングテーブルは、非常に大きなストリームに対する複雑さの低い変換に推奨され、高度なユースケースに推奨されます。
マテリアライズドビューによるデータの変換
マテリアライズドビューは、DLT での変換に推奨されるデフォルトです。それらはシンプルで正確です。ただし、マテリアライズドビューは、マテリアライズドビューに対するクエリが正しい結果を返すようにすべての入力データを処理する可能性があるため、遅延が長くなるという欠点があります。
マテリアライズドビューを使用した 1 つのテーブルの変換
マテリアライズドビューは、Delta テーブルまたはストリーミング テーブルから読み取り、入力データに対して任意の変換を実行できます。 マテリアライズドビューは、Databricks 以外のシステムによって生成されたものを含むすべての Delta テーブルを読み取ることができるため、移行やハイブリッド パイプラインに役立ちます。
ファクト テーブルとディメンション テーブルをマテリアライズドビュー (ストリーム-スナップショット結合) で結合する
マテリアライズドビュー は、ベース Delta テーブルまたはストリーミング テーブルと "ルックアップ" Delta テーブルとの間で効率的な増分結合を実行できます。 これらの結合は、可能な限り増分的に処理されます。 ウォーターマークは、マテリアライズドビュー ジョインとストリーム-スナップショット結合で使用する必要はありません。
2 つのファクト テーブルを結合する (ストリーム-ストリーム結合)
マテリアライズドビュー は、2 つのストリーミングテーブルまたは Delta テーブル間で効率的な増分結合を実行できます。 これはストリーム-ストリーム結合と呼ばれ、マテリアライズドビューは可能な限りインクリメンタルに実行します。 ウォーターマークは、マテリアライズド結合とストリーム-ストリーム結合で使用する必要はありません。
ストリーミングテーブルによるデータの変換
ストリーミングテーブルは、大量のストリーミングデータを低レイテンシーで変換する必要がある場合に推奨されます。
ストリーミングテーブルを使用して 1 つのテーブルを変換する
ストリーミングテーブルは、任意の Delta テーブルまたは別のストリーミングテーブルからのデータを変換するために使用できます。
このユースケースには、次の注意事項が適用されます。
- ストリーミングテーブルの定義を更新しても、完全に更新しない限り、ストリーミングテーブル内の既存のデータは変更を反映して更新されません。
ファクト テーブルをディメンション テーブルに結合する (ストリーム-スナップショット結合) : ストリーミング テーブル
ストリーミング テーブルによってファクト テーブルをディメンション テーブルとjoinできます。
このユースケースには、次の注意事項が適用されます。
- ストリーミングテーブルの定義を更新しても、完全に更新しない限り、ストリーミングテーブル内の既存のデータは変更を反映して更新されません。
- ルックアップ テーブルを更新しても、完全に更新しない限り、ストリーミング テーブル内の既存のデータは変更を反映して更新されません。
ストリーミングテーブルを使用して 2 つのファクト テーブルを結合する (ストリーム-ストリーム結合)
ストリーミング・テーブルは、2 つ以上のファクト・テーブルをjoinできます (ストリーム・ストリームjoinとも呼ばれます)。
このユースケースには、次の注意事項が適用されます。
- ストリーミングテーブルの定義を更新しても、完全に更新しない限り、ストリーミングテーブル内の既存のデータは変更を反映して更新されません。
- メモリ不足エラーを回避するには、結合の両側と集計でウォーターマークを使用する必要があります。
- 順不同のデータは処理されず、データが不正確になる可能性があります。 このため、順不同のデータや到着が遅れたデータを手動で処理する必要があります。
ストリームとストリームの結合でのウォーターマークの使用を参照してください。
