データセット アーキテクチャ Qlik Open Lakehouse

ストリーミング ソースは、データをランディング バケットにロードするために Data Movement gateway を必要とせず、レイクハウス クラスターによって動作するため、Qlik Open Lakehouse では独自のアーキテクチャを持っています。

ファイル名にデータ パターンを含むファイルからデータを取り込む場合、レイクハウス クラスターが S3 でターゲットを絞ったリスト操作を実行できるようになり、ファイル リストの読み取り時間が大幅に短縮されます。さらに、Qlik Open Lakehouse は日付パターンに基づいて到着するファイルを予測できます。ストリーミング ランディング タスクは毎回バケット全体をリストする必要がなく、特定の日付範囲内のファイルを S3 からリクエストできます。ファイル リストが小さいほど、パフォーマンスが向上します。オプションの [ロード後に削除] 設定を使用して、ファイル数を少なく維持できます。フル ロードは実行されず、最初のレコードは挿入された変更として扱われます。

Qlik Open Lakehouse では、ストリーミング変換タスクがストレージ タスクに代わります。このタスクは、ランディングされたデータを Iceberg テーブルとして変換および保存するために使用されます。ストリーミング変換タスクは、ストリーミング ランディング タスクの後にのみ追加できます。ストリーミング変換タスクは、レコードを更新するための 2 つのモードをサポートしています。

• 追加のみ: 既存のデータを変更せずに新しいレコードを追加します。複製レコードが到着してもキー制約は適用されません。

• 変更を適用 (マージ): キー項目に基づいて既存のレコードを更新し、新しいレコードを挿入します。このモードでは、ソフト デリートを使用するか、履歴データ (タイプ 2) を保持するオプションがあります。

ストリーミング変換タスクはターゲット ベースのタスクであり、ソースとターゲット間のマッピングを行い、スキーマ進化機能を備えています。ネストされた構造のアンネストや配列のフラット化など、拡張された変換機能を提供します。ストリーミング変換タスクで使用できる関数の詳細については、「変換関数」を参照してください。

ストリーミング ソースから取り込む場合、Iceberg パーティショニング、リテンション管理、ソート列、スナップショットの有効期限を設定してストレージ コストを制御し、クエリ パフォーマンスを最適化できます。

ランディング テーブル

次のヘッダー フィールドがランディング テーブルに追加されます。これらのフィールドはランディング データには常に存在しますが、既定ではダウンストリームの変換には存在しません。式を使用して、フィールドを変換に追加できます。

スキーマ

アーティファクトは、内部スキーマとデータ タスク スキーマで生成されます。

• 内部スキーマには、複数のパーティションを持つ物理テーブルが含まれています。

• データ タスク スキーマには、データを使用するために使用できるビューが含まれています。

  スキーマが複数のデータ タスクに関連付けられている場合、各データ タスクはテーブルとビューに一意のプレフィックスを使用する必要があります。データタスク設定でプレフィックスを設定できます。

内部スキーマのみ、名前の競合がないかチェックされます。他のスキーマの場合は、テーブル名に名前の競合がないことを確認する必要があります。ベストプラクティスは、内部スキーマをデータ タスク スキーマと同じ名前にし、_internal を追加することです。こうすることで、すべてのスキーマとプレフィックスの組み合わせが一意になります。

テーブル

各ソース テーブルに対して、接尾辞 _internal を持つ内部スキーマにテーブルが作成されます。

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

このテーブルには [変更を適用 (マージ)] モードで 5 つのパーティションがあり、それぞれがデータの処理と保存方法において明確な役割を果たしています。各パーティションは、データ ライフサイクルにおける役割に基づいて、テーブルのカラムのサブセットを活用します。[追加のみ] モードでは、テーブルにパーティションがなく、Current パーティション (ODS) のように動作します。

内部データセットは、データ ソースから入力されるデータを効率的に管理する構造になっており、リアルタイムの取り込みと履歴の追跡をサポートします。データのフローは、以下に説明するいくつかの特殊なパーティションを通じて管理されます。

• Changes パーティション - リアルタイムの取り込み

  ソース システムからのすべての変更 (挿入、更新、削除) は、最初に Changes パーティションに追加されます。

  • 未加工の変更ログとして機能するパーティションは、変換が行われる前のソース アクティビティの完全なフィードを提供します。

  • 各変更には、どのように処理されるかを示すタイプ (I、U、D) のタグが付けられます。

  • イベントは発生時にソースからキャプチャされます。パーティションはほぼリアルタイムで更新されます。

  • Changes パーティションは、レイク ランディング データ タスクで以下の設定が適用されている場合に使用できます。

    • [全般] タブでは、[更新方法] が [CDC] に設定されています。

    • フル ロードが有効です。

• Asset_state パーティション - 進行状況の追跡

  変更が取り込まれると、Asset_state パーティションは 2 つの重要な日付と時刻を記録します。

  • 変更が最後に Changes パーティションに追加された日時。

  • 変更が最後に Current パーティションに適用された日時。

  これにより、同期パイプラインが完全に可視化され、遅延の監視やトラブルシューティングに役立ちます。

• Current パーティション (ODS) - ソースの最新のレプリカ

  Changes パーティションからの変更は、Current パーティションに定期的に適用され、最新のクエリに最適化されたデータ ソースのコピーが維持されます。

  • バックグラウンド タスクが自動的に実行され、更新が適用されます。これは、固定されたスケジュールではなく、蓄積された変更量に基づいています。

  • 最初のフル ロードは Current パーティションに直接書き込まれます。

  • このパーティションはデータの現在の状態を反映し、効率的なクエリ用に設計されています。

• Prior パーティション (HDS) - 過去のデータ

  Current パーティションでレコードが更新または削除されると、以前のバージョンのコピーが Prior パーティションに書き込まれます。 

  • レコードには、変更履歴やデータが有効な日付範囲などのメタデータが含まれます。

  • これは、タイプ 2 の緩やかに変化する軸 (SCD2) をサポートしています。

  • Prior パーティションは、ストレージ データ タスク設定の [全般] タブで [履歴レコードを保持し、変更記録のアーカイブを変更] が有効になっている場合に使用できます。

  • レコードの更新バージョンが Current パーティションに入ると、以前のレコードは履歴追跡のために Prior パーティションに移動します。

• Reload パーティション

  Reload パーティションは、手動またはスケジュールされたフル リロード時の一時的なステージング エリアとして機能します。

  • 新しいデータはまず Reload パーティションに書き込まれます。

  • 定期的なメンテナンス タスクは、一時停止する前にペンディングの変更をクリアします。

  • データは Current パーティションと比較され、差分のみが Current パーティションに移動されます。

  • 操作が完了すると、Reload パーティションはクリアされます。

  このプロセスにより、フル リロード操作中のメイン データセットの中断を最小限に抑えることができます。

Current パーティション

Prior パーティション

Changes パーティション

Asset_state パーティション

Reload パーティション

Reload パーティションで使用される列は、Current パーティションと同じです。

ビュー

作成されたすべてのビューは、ほぼリアルタイムで更新されます。クエリやレポートを簡素化するために、以下のビューが利用できます。

現行

現在のビューは、データの最新の状態を反映します。このビューは、ほぼリアルタイムで更新されるソーステーブルのレプリカを表します。Current パーティションと Changes パーティションのデータをマージします。

名前: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

テーブル構造にヘッダー列は追加されません。

履歴

データ タスク設定で履歴が有効になっている場合、選択した各ソース テーブルのデータ アセット スキーマに履歴ビューが生成されます。履歴ビューは、Prior パーティションと Changes パーティションのデータをマージします。変更の完全なタイムラインを提供し、監査や履歴分析に最適です。

名前: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

以下のヘッダー フィールドが履歴ビューに追加されます。