Qlik Replicate からのデータのオンボーディング
既存の Replicate インフラストラクチャを維持したまま、 Qlik Open Lakehouse のすべての機能を利用できます。データ オンボーディング ウィザードを使用すると、Qlik Replicate の Amazon S3 出力からのデータを処理し、Qlik Open Lakehouse を使用して Iceberg テーブルとして保存するパイプラインを作成できます。
前提条件
データ オンボーディング ウィザードを起動する前に、次の前提条件が満たされていることを確認してください。
Qlik Replicate の前提条件
Amazon S3 ターゲット エンドポイント経由で Amazon S3 バケットにデータを移動するための Qlik Replicate タスクをセットアップします。
Qlik Replicate タスクの前提条件
-
[フル ロード] および/または [変更の保存] (データを最新の状態に保つために必要) レプリケーション オプションのみを有効にします。
-
タスク設定の [変更の保存設定] タブ:
-
[変更テーブル設定] を次のように設定します。
-
サフィックス: __ct
-
ヘッダー列のプレフィックス: header__
-
DDL オプション: 変更テーブルに適用
-
更新時: 更新後のイメージのみを保存
-
-
[変更データのパーティショニング] は無効 (既定) のままにします。
-
-
タスク設定の [メタデータ] > [コントロール テーブル] タブで、 [例外の適用] コントロール テーブルと [DDL 履歴] コントロール テーブルが選択されていることを確認します。
これらの設定の詳細については、「Qlik Replicate タスク設定のヘルプ (英語のみ)」を参照してください。
Qlik Replicate Amazon S3 ターゲット エンドポイントの前提条件
[一般] タブで:
- [メタデータ ファイル] セクションで、 [ターゲット フォルダにメタデータ ファイルを作成] (Replicate November 2025 以前) または [データ ファイルごとにメタデータ ファイルを作成] (Replicate May 2026 以降) オプションを有効にします。これにより、S3 バケットに .dfm 拡張子のファイルが作成されます。
- [ファイル属性] セクションで、以下を確認します。
- [形式] に [CSV] が選択されていること (既定)
- [次を使用してファイルを圧縮 ] が [なし] に設定されていること (既定)
- [メタデータ ヘッダーを追加] オプションの両方が有効になっていること (列名ありおよびデータ タイプあり)
- Amazon S3 ストレージ設定を構成する際、バケットに Replicate 以外のファイルが含まれている場合は、 [ターゲット フォルダー] を指定することをお勧めします。そうすることで、Qlik Open Lakehouse でデータのオンボーディングを行う際に、必要な出力を特定しやすくなります。
これらの設定の詳細については、「Amazon S3 ターゲット エンドポイントのヘルプ (英語のみ)」を参照してください。
Qlik Open Lakehouseの前提条件
Replicate Amazon S3 出力にアクセスするように構成された AWS S3 Data Stream コネクタ。
手順については、「AWS S3 データ ストリーム」を参照してください。
Replicate が S3 内のデータを整理する方法
Qlik Replicate が S3 内のデータを整理するために使用する構造を理解しておくと、以下で説明する [オンボーディング タスクを作成する] の [ディレクトリ ブラウザー] でファイルを見つけやすくなります。
-
s3://bucket-name/target-path/schema.table/
次の例のように、フル ロード ファイルと DFM メタデータ ファイルがシーケンシャル形式で含まれています。
-
LOAD00000001.csv
-
LOAD00000001.dfm
-
LOAD00000002.csv
-
LOAD00000002.dfm
-
-
s3://bucket-name/target-path/schema.table__ct/
次の例のように、変更データ キャプチャ ファイルと DFM メタデータ ファイルがタイムスタンプ形式で含まれています。
-
20250121-083015000.csv
-
20250121-083015000.dfm
-
20250121-091522000.csv
-
20250121-091522000.dfm
-
オンボーディング タスクを作成する
Replicate データのオンボーディング タスクを設定するには、次の手順を実行します。
-
次の手順でオンボーディング ウィザードを起動します。
-
新しいプロジェクト: プロジェクト ウィンドウの中央にある [データのオンボード] をクリックします。
-
既存のプロジェクト:Qlik Open Lakehouse プロジェクトの右上にある [新規作成] > [データのオンボード] をクリックして、オンボーディング ウィザードを起動します。
-
- タスク名と説明を入力します。
- [データの起点] オプションから [Qlik Replicate] を選択します。[次へ] をクリックします。
- 事前に設定した [AWS S3 データ ストリーム] コネクタを選択します。[次へ] をクリックします。
-
左側の [ディレクトリ ブラウザー] ペインで、Replicate の出力を含むルート ディレクトリを選択します。
ヒント メモReplicate Amazon S3 ターゲット エンドポイント設定でターゲット フォルダーを指定しなかった場合 (上記の前提条件で推奨)、バケットに無関係なファイルが多数含まれている可能性があります。この場合、正確なパスがわかっていれば、 [Replicate ルート ディレクトリ パス] フィールドに直接貼り付けることができます。 - [ロード] をクリックして、利用可能なテーブルを検出します。利用可能なテーブルが [登録対象のテーブル] リストに表示されます。
- 右側の [テーブルを検出するデータ ソースの選択] 領域では、次の設定を使用できます。
- 現在のすべてのテーブルを含める: オンに切り替えると、既存のすべてのテーブルがランディングされます。このオプションをオフに切り替えた場合は、個々のテーブルを選択する必要があります。
取り込み後、ソースファイルを削除: オンに切り替えると、ファイルが正常に処理された後、Replicate S3 バケットからファイルが完全に削除されます。
S3 ファイルが削除されると、それらの S3 ファイルをソースとして使用しているすべての接続済みパイプラインは非アクティブとなり、機能しなくなります。したがって、他のパイプライン プロセスでファイルが必要ないことが確実な場合にのみ、このオプションを有効にする必要があります。
- [次へ] をクリックします。
- [コンテンツ タイプ] ステップで、ファイル形式 (CSV) が Replicate データから自動的に検出されます。次のオプションも利用できます。
- 履歴データ ストア (タイプ 2): レコードの履歴バージョンを維持し、変更のアーカイブを保持する必要がある場合は、オンに切り替えます。
- イベントが正しくロードされていることを確認する: データセットを選択して、正しいデータが含まれていることを確認できます。
- [次へ] をクリックします。
- タスク構成を確認し、 [作成] をクリックしてオンボーディング タスクを作成します。
-
[準備] をクリックしてデータ タスクをカタログ化し、実行の準備をします。
タスク タイルで準備の進行状況を追跡できます。完了すると、 [準備: 成功] が表示されます。
-
データのオンボーディングを開始する準備ができたら、 [実行] をクリックします。
その後の動作
オンボーディング タスクが有効化されると、次が実行されます。
- Replicate S3 バケットのデータ変更の監視を開始する
- Replicate からのフル ロードおよび CDC (変更データ キャプチャ) ファイルを検出する
- ファイルを処理し、Qlik Open Lakehouse に Iceberg テーブルを作成する
- 継続的に新規データを監視する
- 有効な場合、取り込みが正常に完了した後にソース ファイルを自動的に削除する
タスク設定
タスク設定を変更するには、Onboarding_Qlik_Replicate (デフォルト名) タスクを開き、ツール バーの [設定] ボタンをクリックします。
[設定: <タスク名>] ダイアログが開きます。
[一般] タブ
これらのオプションについては、上記の [ランディング タスクを作成] のステップ 7 で説明されています。
-
現在および将来のすべてのテーブルを自動的に含める
-
取り込み後、ソースファイルを削除
[ランタイム] タブ
[レイクハウス クラスター] を変更します。
考慮事項と制限事項
一般的な考慮事項と制限事項
- Iceberg テーブルにデータが表示されるまでに、フル ロードおよびリロード操作で処理の遅延が発生する場合があります。システムは、ファイルが完全であることを確認するために、フル ロードの完了後最大 15 分間待機します。その結果、Replicate でフル ロードを 15 分未満の間隔で実行すること (スケジュールまたは手動) はサポートされていません。
- 空の Replicate テーブル (データ ファイルのないテーブル) は、システムによって検出または登録されません。
- [取り込み後、ソース ファイルを削除] を有効にすると、ランディング タスクをリロードできなくなります。データをリロードするには、Replicate で再生成する必要があります。
- Qlik Replicate の テーブルはすでにロードされています。 (英語のみ)詳細な実行オプションからの変更処理の開始はサポートされていません。タイプ 2 (履歴データ) が有効な場合、このオプションを使用すると履歴テーブルが破損します。
- スキーマの進化はサポートされません。
CDC vs Replicate パイプライン
CDC ソースから取り込む通常のパイプラインでは、 [データの更新日時] メトリクスは常にデータの現在の鮮度を示します (例: 1 分前)。これは、パイプラインがデータベースのトランザクション ログに直接アクセスできるためであり、これによりすべての INSERT/UPDATE/DELETE イベントをリアルタイムで把握できます。しかし、Replicate からデータを取り込むパイプラインでは、 [データの更新日時] メトリクスはデータの現在の鮮度を示すものではなく、実際にデータが古いという誤った印象を与える可能性があります (例: 8 時間前)。これは、Replicate パイプラインがトランザクション ログに直接アクセスできないためです。代わりに、Replicate は S3 バケットにファイルを書き込み、パイプラインはファイルの作成タイムスタンプをチェックしてデータの鮮度を判断します。したがって、ソース データベースにしばらく新しい変更がない場合、Replicate は新しいファイルを作成せず、 [データの更新日時] タイムスタンプが古くなります (データが古いという誤った印象を与えます)。