データ ソースからのランディング データ

オンボーディング時のデータ転送の最初のステップは、データのランディングです。これには、データ ソースからランディング エリアへのデータの転送が含まれます。

ソース接続を通じて、多くのデータ ソースからデータをランディングできます。

ランディング エリアは、プロジェクトを作成するときに定義されます。

• Qlik Cloud (Amazon S3 経由)

  データを Qlik Cloud にランディング (Amazon S3 経由) すると、それを使用して Qlik Cloud で分析できる QVD テーブルを生成できます。

• クラウド データ ウェアハウス

  データを Snowflake または Azure Synapse Analytics などのクラウド データ ウェアハウスにランディングすると、同じクラウド データ ウェアハウスにテーブルを保存できます。

• Qlik Open Lakehouse

  Qlik Open Lakehouse にデータをランディングすると、データは Iceberg のオープン テーブル形式で保存され、Snowflake にミラーリングすることができます。

データをレイクハウスにランディングし、そこから Snowflake が管理するクラウド ファイル ストレージにデータをランディングすることもできます。詳細については、「レイクハウスへのデータのランディング」を参照してください。

ランディング データ タスクの作成と設定

ここでは、ランディング データ タスクを作成する方法について説明します。データパイプラインを作成する最も簡単な方法は、ランディング データ タスクとストレージ データ タスクを作成し、準備と実行ができるデータをオンボードすることです。詳細については、「データ ウェアハウスへのデータのオンボーディング」を参照してください。

1. プロジェクトで [作成] をクリックし、 [データのランディング] を選択します。

2. [データのランディング] 展開先パスで、データ タスクの名前と説明を入力します。

   [開く] を選択して、作成されたときに、データ タスクのランディングを開きます。

   [作成] をクリックします。

3. [ソースデータの選択] をクリックします。

4. ソース データへの接続を選択し、 [次へ] をクリックします。

   左側のパネルのフィルターを使用して、ソースの種類、スペース、所有者の接続のリストをフィルタリングします。

   ソース データに接続されていない場合は、最初に [接続を追加] をクリックして接続を作成する必要があります。

   サポートされているソースへの接続設定の詳細については、「データソースへの接続の設定」を参照してください。

   情報メモ次の手順でテーブルを選択した場合、ソース接続をオンプレミス データ ソースからクラウド データ ソースに変更すること、またはその逆はできません。接続を変更できるのは、同じ種類の別のデータ ソースのみです。

5. データ タスクに含めるデータセットを選択します。接続しているソースの種類によって選択展開先パスは異なります。

   テーブルを選択したら、 [保存]をクリックします。

   [データセット] が表示されます。

6. ランディングの設定を変更できます。これは必須ではありません。

   • [設定] をクリックします。

   設定の詳細については、「ランディングの設定」を参照してください。

7. 選択したデータ アセットテーブルの構造とメタ データをプレビューできるようになりました。これには、明示的にリストされたすべてのテーブルと、選択ルールに一致するテーブルが含まれます。

   データ ソースからさらにテーブルを追加する場合は、 [ソース データの選択] をクリックします。

8. データのフィルタリング、または列の追加など、データセットに対する基本的な変換を実行できます。これは必須ではありません。

   詳細については、「データセットの管理」を参照してください。

9. 必要な変換を追加したら、[データセットの検証] をクリックしてデータセットを検証できます。検証でエラーが見つかった場合は、先に進む前にエラーを修正してください。

   詳細については、「データセットの検証と調整」を参照してください。

10. 準備ができたら、 [準備] をクリックしてデータ タスクをカタログ化し、実行の準備をします。

    画面下部の [準備の進捗状況] で進捗状況を確認できます。

11. データ タスクが準備され、データのレプリケーションを開始する準備ができたら、 [実行] をクリックします。

レプリケーションが開始され、 [モニター] で進行状況を確認できます。詳細については、「個々のデータ タスクの監視」を参照してください。

データベースからのデータの選択

特定のテーブルまたはビューを選択することや、選択ルールを使用してテーブルのグループを含めるか除外することができます。

% をワイルドカードとして使用して、スキーマとテーブルの選択基準を定義します。

• %.% は、すべてのスキーマのすべてのテーブルを定義します。

• Public.% は、スキーマの [パブリック] のすべてのテーブルを定義します。

[選択基準] により、選択内容に基づいたプレビューが表示されます。

次のいずれかを実行できるようになりました。

• 選択基準に基づいて、テーブルのグループを含めるまたは除外するルールを作成します。

  [選択条件からルールを追加] をクリックしてルールを作成し、 [含める] または [除外] のいずれかを選択します。

  [選択ルール] の下にルールが表示されます。

• 1 つ以上のデータセットを選択し、 [選択したデータセットを追加] をクリックします。

  [明示的に選択したデータセット] の下に、追加されたデータセットが表示されます。

選択ルールは、現在のテーブルとビューのセットにのみ適用され、将来追加されるテーブルとビューには適用されません。

変更データ キャプチャ (CDC) を使用したランディング タスクの実行

準備ができたら、ランディング タスクを実行できます。これにより、オンプレミスのデータ ソースからランディング エリアにデータを転送するレプリケーションが開始されます。

• [実行] をクリックして、データのランディングを開始します。

レプリケーションが開始され、データ タスクのステータスが [実行中] になります。まず、全データ ソースがコピーされ、次に変更が追跡されます。これは、変更が発見されたときに継続的に追跡および転送されることを意味します。これにより、ランディング エリアのランディングデータが最新の状態に保たれます。

Qlik Talend Data Integration ホームでは、ランディングデータの更新ステータス、日時およびエラーになったテーブルの数を確認できます。また、データ タスクを開き、 [テーブル] タブを選択して、テーブルの基本的なメタデータ情報を確認することもできます。

進捗状況を詳細に監視するには、 でレプリケーションタスクを開き、 [モニター] ビューを選択します。詳細については、「個々のデータ タスクの監視」を参照してください。

すべてのテーブルがロードされ、最初の変更セットが処理されると、データ タスク カードの [Data is updated to] (データ更新) は、その時点までのソースの変更がデータ タスクで利用可能であることを示します。

テーブルのリロード

ソースからデータをリロードできます。

単一のテーブルのリロード

変更データ キャプチャを妨げることなく、特定のテーブルを手動でリロードできます。これは、1 つ以上のテーブルに CDC の問題がある場合に便利です。

1. ランディング データ タスクを開き、 [監視] タブを選択します。

2. リロードするテーブルを選択します。

3. [テーブルのリロード] をクリックします。

テーブルをリロードしても問題が解決しない場合、またはタスク全体に影響する場合は、代わりにすべてのテーブルをターゲットにリロードできます。そうすることで、変更データ キャプチャが再開されます。

すべてのテーブルをターゲットにリロードする

特定のテーブルをリロードしても解決できない CDC の問題が発生した場合は、すべてのテーブルをターゲットにリロードできます。問題の例としては、イベントの欠落、ソース データベースの再編成による問題、ソース データベース イベントの読み取り時の失敗などがあります。

1. データ タスクとそれを消費するすべてのタスクを停止します。

2. データ タスクを開き、 [監視] タブを選択します。

3. [ ...] 、 [ターゲットをリロード] の順にクリックします。

これにより、Drop-Create を使用してすべてのテーブルがターゲットにリロードされ、今後すべての変更データ キャプチャが再開されます。

• ランディング データ タスクを消費するストレージ タスクは、比較によってリロードされ、次回の実行時に適用されて同期されます。既存の履歴は保持されます。タイプ 2 の履歴は、リロードと比較処理が実行された後に変更を反映して更新されます。

  タイプ 2 の履歴の開始日の日付と時刻はリロード日を反映し、必ずしもソースで変更が発生した日付とは限りません。

• ターゲットのリロード操作中、およびストレージが同期されるまで、ストレージ ライブ ビューは信頼できません。ストレージは次の場合に完全に同期されます。

  • すべてのテーブルが比較と適用を使用してリロードされた場合。

  • 各テーブルに対して 1 サイクルの変更が実行された場合。

リロードして比較でのランディング データ タスクの実行

準備ができたら、ランディング データ タスクを使用してデータをコピーできます。

• [実行] をクリックして、フル ロードを開始します。

データのコピーを開始し、データ タスクのステータスは [実行中] になります。フル データ ソースがコピーされると、ステータスは [完了] になります。

Qlik Talend Data Integration ホームでは、ランディングデータの更新ステータス、日時およびエラーになったテーブルの数を確認できます。また、データ タスクを開き、 [テーブル] タブを選択して、テーブルの基本的なメタデータ情報を確認することもできます。

進捗状況を詳細に監視するには、 でレプリケーションタスクを開き、 [モニター] ビューを選択します。詳細については、「個々のデータ タスクの監視」を参照してください。

すべてのテーブルがロードされると、 [Data is updated to] (データ更新) には、その時点までのソースの変更がデータ タスクで利用可能であることが示されます。ただし、データ タスクの一部のテーブルは、ロードを開始した時期に応じて、後の時間に更新することができます。これは、データの一貫性が保証されていないことを意味しています。例えば、08:00にロードを開始して4時間かかった場合、ロードが完了すると、 [Data is updated to] (データ更新) に 08:00 と表示されます。ただし、11:30 にリロードを開始したテーブルには、08:00 から 11:30 の間に発生したソースの変更が含まれます。

[Data is updated to] (データ更新) は、正常にロードされたテーブルのみを反映します。テーブルのリロードが失敗したことを示すものではありません。クラウド ターゲットでは、すべてのテーブルにエラーが発生してリロードが完了した場合、項目は空になります。

リロードして比較使用時のデータのリロード

更新方法として [リロードして比較] を使用する場合は、データをリロードしてデータ ソースを最新の状態に保つ必要があります。

• [リロード] をクリックして、すべてのテーブルの手動リロードを実行します。

• スケジュールされたリロードを設定します。

単一のテーブルのリロード

特定のテーブルを手動でリロードできます。これは、1 つ以上のテーブルに問題がある場合に便利です。

1. ランディング データ タスクを開き、 [監視] タブを選択します。

2. リロードするテーブルを選択します。

3. [テーブルのリロード] をクリックします。

リロードして比較ランディング データ タスクのスケジュール

データ タスクのスペースで [操作可能] ロールがある場合は、ランディング データ タスクの定期的なリロードをスケジュールできます。スケジュールをアクティブにするには、データ タスクのステータスが少なくとも [準備完了] である必要があります。

• データ タスクの [...] をクリックし、[スケジュール] を選択します。

  時間ベースのスケジュールを設定できます。

  データ ソースの種類とサブスクリプション ティアに応じた最小スケジュール間隔の詳細については、「許容される最小スケジュール間隔」を参照してください。

データセットのロードの優先度の設定

各データセットにロード優先度を割り当てることで、データ タスクでのデータセットのロード順を制御できます。この機能は、大きなデータセットの前に小さなデータセットをロードする場合などに便利です。

1. [ロードの優先度] をクリックします。

2. 各データセットのロードの優先度を選択します。

   既定のロードの優先度は [標準] です。データセットは次の優先順位でロードされます。

   • 最高

   • より高く

   • 高

   • 標準

   • 低

   • より低く

   • 最低

   同じ優先度のデータセットは順不同でロードされます。

3. [OK] をクリックします。

ランディング データ タスクの操作

タスク メニューから、ランディング データ タスクに対して次の操作を実行できます。

• 開く

  これにより、ランディング データ タスクが開きます。テーブル構造とデータ タスクの詳細を表示できます。

• 編集

  タスクの名前と説明を編集できます。

• 削除

  データ タスクを削除できます。

  次のオブジェクトは削除されないため、手動で削除する必要があります。

  • ランディング エリアのデータ。

• 実行

  データ タスクを実行して、データのコピーを開始することができます。

  変更データ キャプチャ (CDC) を使用したランディング タスクの実行

  リロードして比較でのランディング データ タスクの実行

• 停止

  実行中のデータ タスクの操作を停止できます。ランディング エリアは、変更されたデータで更新されません。

  リロード スケジュールのあるフル ロードのデータ タスクを停止すると、現在のリロードのみが停止されます。データ タスクのステータスが 停止 の場合、またアクティブなリロード スケジュールがある場合、次のスケジュールされた時刻に再びリロードされます。[リロードのスケジュール] でリロードのスケジュールをオフにする必要があります。

• リロード

  [リロードして比較] 更新モードで、データ タスクの手動リロードを実行できます。

• [準備]

  これにより、タスクの実行準備が整います。準備には次が含まれます。

  • 設計が有効であることを検証する。

  • 設計に合わせて物理テーブルとビューを作成または変更する。

  • データ タスクの SQL コードを生成する。

  • タスク出力データセットのカタログ エントリを作成または変更する。

  画面下部の [準備の進捗状況] で進捗状況を確認できます。

  情報メモタスクを準備する前に、直接ダウンストリームにあるすべてのタスクを停止します。

• テーブルを再作成

  これにより、ソースからデータセットが再作成されます。

  情報メモ個々のテーブルに問題がある場合は、最初にテーブルを再作成するのではなく、リロードしてみることをお勧めします。テーブルを再作成すると、過去のデータが失われる可能性があります。重大な変更があった場合は、データをリロードできるよう、再作成されたデータ タスクを使用するダウンストリームのデータ タスクを準備することも必要です。

• スケジュール

  [フル ロード] モードで、ランディング データ タスクのスケジュールされたリロードを設定できます。カスタマイズ可能な時間ベースのスケジュールを設定できます。

  スケジュールされたリロードをオンまたはオフにすることもできます。

  リロードをスケジュールするには、データ タスクのスペースで操作可能ロールを保持することが必要です。

• データを保存

  このランディング データ タスクからデータを使用するストレージ データ タスクを作成できます。

メタデータの更新

タスクのメタデータを更新して、タスクの [設計] ビューのソースのメタデータの変更に合わせることができます。Metadata Manager を使用する SaaS アプリケーションの場合、データ タスクでメタデータを更新する前に、Metadata Manager を更新する必要があります。

1. 次のいずれかを実行できます:

   • [...] をクリックし、 [メタデータを更新] をクリックして、タスク内のすべてのデータセットのメタデータを更新します。

   • [データセット] 内のデータセットで [...] をクリックし、 [メタデータを更新] をクリックして、単一のデータセットのメタデータを更新します。

   画面の下部にある [メタデータを更新] でメタデータの更新のステータスを確認できます。 にカーソルを合わせると、メタデータが最後に更新された日時を確認できます。

2. 変更を適用するには、データ タスクを準備します。

   データ タスクを準備し、変更を適用すると、変更は [メタデータを更新] から削除されます。

変更をプロパゲートするには、このタスクを使用するストレージ タスクを準備する必要があります。

列が削除されると、ストレージから履歴データが失われないように、Null 値を使用した変換が追加されます。

メタデータの更新に関する制限

• 同じ時間スロットで、それ以前に削除された列を含む名前変更は、同じデータ型とデータ長である場合、削除された列の名前変更に変換されます。

   

  前: a b c d

  後: a c1 d

  この例では、b が削除され、c の名前が c1 に変更され、b と c のデータ型とデータ長は同じになります。

  これは、b から c1 への名前変更と c の削除として識別されます。

• 最後の列が削除され、その前の列の名前が変更された場合でも、最後の列の名前変更は認識されません。

   

  前: a b c d

  後: a b c1

  この例では、d が削除され、c の名前が c1 に変更されました。

  これは、c と d の削除と c1 の追加として識別されます。

• 新しい列は最後に追加されると想定されます。途中に次の列と同じデータ型の列が追加されると、削除と名前変更として解釈される可能性があります。

スキーマの進化

スキーマの進化により、複数のデータ ソースに対する構造的な変更を簡単に検出し、それらの変更がタスクにどのように適用されるかを制御できます。スキーマの進化を使用すると、ソース データ スキーマに対して実行された DDL 変更を検出できます。一部の変更を自動的に適用することもできます。

変更タイプごとに、タスク設定の [スキーマの進化] セクションで変更を処理する方法を選択できます。変更を適用、変更を無視、テーブルを一時停止、またはタスクの処理を停止できます。

変更タイプごとに、DDL 変更を処理するために使用するアクションを設定できます。すべての変更タイプで、一部のアクションは使用できません。

• ターゲットに適用

  変更を自動的に適用します。

• 無視

  変更を無視します。

• テーブルを一時停止

  テーブルを一時停止します。[モニター] では、テーブルがエラーとして表示されます。

• タスクを停止

  タスクの処理を停止します。これは、すべてのスキーマ変更を手動で処理する場合に便利です。これにより、スケジュールも停止され、スケジュール済みの実行は行われなくなります。

次の変更がサポートされています。

• 列を追加

• 列名を変更

• 列のデータ型を変更

• 選択パターンに一致するテーブルを作成する
  

  [選択ルール] を使用してパターンに一致するデータセットを追加した場合、パターンを満たす新しいテーブルが検出され、追加されます。

タスク設定の詳細については、「スキーマの進化」を参照してください。

スキーマの進化によって処理される変更に関する通知を受け取ることもできます。詳細については、「動作変更時の通知の設定」を参照してください。

スキーマの進化に関する制限

スキーマの進化には次の制限が適用されます。

• スキーマの進化は、更新方法として CDC を使用する場合にのみサポートされます。

• スキーマの進化の設定を変更した場合は、再度タスクを準備する必要があります。

• テーブルの名前を変更すると、スキーマの進化はサポートされません。この場合、タスクを準備する前にメタデータを更新する必要があります。

• タスクを設計している場合は、スキーマの進化の変更を受け取るためにブラウザを更新する必要があります。変更があった場合に通知を受け取るように設定できます。

• ランディング タスクでは、列のドロップはサポートされていません。列をドロップして追加すると、テーブル エラーが発生します。

• ランディング タスクでは、テーブルのドロップ操作を実行してもテーブルはドロップされません。テーブルをドロップしてからテーブルを追加しても、古いテーブルが切り捨てられるだけで、新しいテーブルは追加されません。

• ターゲット データベースのサポートによっては、すべてのターゲットで列の長さを変更できない場合があります。

• 列名が変更されると、その列を使用して定義された明示的な変換は列名に基づいているため反映されません。

• メタデータの更新に対する制限は、スキーマの進化にも適用されます。

DDL の変更をキャプチャする場合、次の制限が適用されます。

• ソース データベースで一連の操作が高速に実行されると (例: DDL > DML > DDL)、Qlik Talend Data Integration はログを間違った順序で解析し、データが欠落したり、予期しない動作が発生したりする可能性があります。このような事態が発生する可能性を最小限に抑えるベストプラクティスとして、次の操作を実行する前に、変更がターゲットに適用されるまで待機してください。

  たとえば、変更キャプチャ中に、ソース テーブルの名前が立て続けに複数回変更されると (2 回目の操作で元の名前に戻される)、ターゲット データベースにテーブルが既に存在するというエラーが発生する可能性があります。

• タスクで使用されるテーブルの名前を変更してからタスクを停止すると、タスクの再開後に Qlik Talend Data Integration はそのテーブルに加えられた変更をキャプチャしません。

• タスクが停止している間にソース テーブルの名前を変更することはサポートされていません。

• テーブルのプライマリ キー列の再割り当てはサポートされていません (したがって、DDL 履歴コントロール テーブルには書き込まれません)。
• タスクが停止している間に列のデータ型が変更され、(同じ) 列の名前が変更されると、タスクが再開されたときに DDL の変更が DDL 履歴コントロール テーブルに「列をドロップ」として表示され、その後「列を追加」として表示されます。待機時間が長引いた場合にも、同じ動作が起こる可能性があることに注意してください。
• タスクが停止している間にソースで実行された CREATE TABLE 操作は、タスクが再開されるとターゲットに適用されますが、DDL 履歴コントロール テーブルに DDL として記録されません。

• メタデータの変更に関連する操作 (ALTER TABLE、再編成、クラスター化インデックスの再構築など) は、次のいずれかの方法で実行された場合、予期しない動作を引き起こす可能性があります。

  • フル ロード時

    -または-

  • [プロセスの変更開始] のタイムスタンプと現在の時刻 (つまり、ユーザーが [詳細な実行オプション] ダイアログで [OK] をクリックした時点) の間。

    例:

    次の場合:

    指定された [プロセスの変更開始] 時刻は午前 10:00 です。

    および:

    午前 10 時 10 分に、 [年齢] という列が [従業員] テーブルに追加されました。

    および:

    ユーザーは午前 10 時 15 分に [詳細な実行オプション] ダイアログで [OK] をクリックします。

    その結果:

    10:00 から 10:10 の間に発生した変更により、CDC エラーが発生する可能性があります。

  情報メモ

  上記のいずれの場合でも、データがターゲットに適切に 移動済み されるように、影響を受けるテーブルをリロードする必要があります。

• DDL ステートメント ALTER TABLE ADD/MODIFY <column> <data_type> DEFAULT <> は、既定値をターゲットにレプリケートせず、新しい列または変更された列は NULL に設定されます。列を追加または変更した DDL が過去に実行された場合でも、発生する可能性があることに注意してください。新しい列または変更された列が NULL 可能である場合、ソース エンドポイントは DDL 自体をログに記録する前にすべてのテーブル行を更新します。その結果、Qlik Talend Data Integration は変更をキャプチャしますが、ターゲットは更新しません。新しい列または変更された列が NULL に設定されているため、ターゲット テーブルにプライマリ キーまたは一意のインデックスがない場合、後続の更新では「影響を受ける行は 0 行です」というメッセージが生成されます。

• TIMESTAMP および DATE 精度列への変更はキャプチャされません。

自動的に適用されない変更の処理

ここでは、ターゲットに適用できない変更 (アクションの無視、一時停止、タスクの停止) を処理する方法について説明します。

列の削除

履歴が有効なストレージ データ タスクによって消費される列を削除する場合は、次の手順に従って履歴を保存し、データ損失の可能性を回避する必要があります。

1. ランディング データ タスクを停止します。

2. ストレージ データ タスクを実行して、すべてのランディング データが確実に読み取られるようにします。

3. ランディングの列を削除します。

4. ランディング データ タスクを実行します。

5. ストレージで、既定の式 (Null または既定値) で列を追加するか、列を削除します。

ソース接続またはデータ ゲートウェイの変更

ソース接続またはソース データ ゲートウェイを変更する場合は、すべてのテーブルを再作成する必要があります。

ランディング エリアのメンテナンス

ランディング エリアの自動クリーンアップはサポートされていません。これはパフォーマンスに影響する可能性があります。
ランディング エリアで古いフル ロード データの手動クリーンアップを実行することをお勧めします。

• Qlik Cloud ( Amazon S3 を通じて)

  フルロードデータのフォルダーが複数ある場合は、最新のフォルダーを除くすべてを削除できます。処理された変更データ パーティションを削除することもできます。

• クラウド データ ウェアハウス

  処理されたフル ロードと変更テーブル レコードを削除できます。

推奨事項

• ソース テーブルの主キーが更新できる場合、[変更処理の調整] の [主キー列の更新時に DELETE および INSERT] オプションを有効にします。

制限事項

• 8000 バイトを超える varchar データ、または 4000 バイトを超える Nvarchar データのレプリケーションはサポートされていません。

• 移動された列では、直接変更または変換ルールを使用して Null 可能性を変更することはサポートされていません。ただし、タスクで作成された新しい列は、既定で Null 可能です。

• CLOB および BLOB 型のソース列は、ソースで NULL 不可としてマークされている場合でも、既定で NULL 可能として設定されます。これを null 非許容に変更することもできますが、ソースから null として到着した場合に備えて、null 以外の値を追加する数式を追加する必要があります。これは削除されたレコードで発生する可能性があります。

変換には次の制限があります。

• 右から左に記述する言語の列では、変換はサポートされません。

• 名前に特殊文字 (例: #、\、/、-) が含まれる列では変換を実行できません。

• LOB/CLOB データ型でサポートされている唯一の変換は、ターゲット上の列をドロップすることです。
• 変換を使用して列の名前を変更し、同じ名前の新しい列を追加することはサポートされていません。