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

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

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

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

• Qlik Cloud （ Amazon S3 を通じて）

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

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

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

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

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

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 の追加として識別されます。

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

列の削除

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

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

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

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

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

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

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

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

• Qlik Cloud （ Amazon S3 を通じて）

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

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

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

推奨事項

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

制限事項

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

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

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

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

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

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