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