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

Qlik Open Lakehouse を使用してクラウド データ ウェアハウスでデータセットを生成すると、Qlik Talend Data Integration によって自動的にストレージ テーブル、変更テーブル、ビューが生成されます。これらのビューにクエリを実行すると、Iceberg オープン テーブル形式で保存されている現在および過去のデータにアクセスできます。

直感的でガイド付きのユーザー インターフェイスは、データ パイプラインの構築、モデル化、および実行に役立ちます。手動コーディングなしで、オペレーショナル データ ストア (ODS) と履歴データ ストア (HDS) のスキーマを自動的に生成できます。

スキーマ

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

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

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

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

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

テーブル

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

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

このテーブルには 5 つのパーティションがあり、それぞれのパーティションはデータの処理と保存方法において明確な役割を果たしています。各パーティションは、データ ライフサイクルにおける役割に基づいて、テーブルのカラムのサブセットを活用します。

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

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

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

履歴

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

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

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