メイン コンテンツをスキップする 補完的コンテンツへスキップ

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

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

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

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

  • Qlik CloudAmazon S3 を通じて)

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

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

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

情報メモデータ タスクは、その所有者のコンテキストで動作します。必要なロールと権限の詳細については、「データスペースのロールと権限」を参照してください。

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

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

  1. Qlik Cloud データ統合 のホームで [新規追加] をクリックし、 [データのランディング] を選択します。
  2. [データのランディング] 展開先パスで、データ タスクの名前と説明を入力します。

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

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

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

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

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

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

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

    情報メモ次の手順でテーブルを選択した場合、ソース データ接続をオンプレミス データ ソースからクラウド データ ソースに変更すること、またはその逆はできません。接続を変更できるのは、同じ種類の別のデータソースのみです。
  5. データ アセットに含めるテーブルとビューを選択します。接続しているソースの種類によって選択展開先パスは異なります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

情報メモ選択にビューが含まれる場合、CDC はサポートされません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

テーブルのリロード

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

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

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

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

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

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

情報メモこのオプションは、ランディング タスクが少なくとも 1 回実行された後に使用可能になります。ランディング タスクが実行されていないときにクリックした場合、次回のタスク実行時にテーブルがリロードされます。

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

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

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

情報メモこの操作は、更新方法が変更データ キャプチャ (CDC) で、少なくとも 1 回実行されたタスクでのみ使用できます。

  1. データ タスクとそれを消費するすべてのタスクを停止します。
  2. データ タスクを開き、 [監視] タブを選択します。

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

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

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

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

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

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

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

情報メモメタデータの変更はサポートされていません。ソースにメタデータの変更がある場合、データのリロード時に変更がランディングに伝達されますが、適切に処理されません。これにより、ストレージの消費が失敗する可能性があります。

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

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

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

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

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

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

すべてのテーブルがロードされると、 [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 回実行された後、タスクが実行されていない場合にのみ使用可能になります。
  • メタデータの変更はサポートされていません。ソースにメタデータの変更がある場合、データのリロード時に変更がランディングに伝達されますが、適切に処理されません。これにより、ストレージの消費が失敗する可能性があります。

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

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

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

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

情報メモスケジュールされたリロードが開始されようとしているときにデータ タスクがまだリロードされている場合、スケジュールされたリロードは次のスケジュールされたリロード イベントまでスキップされます。

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

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

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

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

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

    • 最高

    • より高く

    • 標準

    • より低く

    • 最低

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

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

情報メモSaaS アプリケーション ソースからのデータセットには、ロード順序の依存関係が含まれている可能性があります。ロードの優先順位を設定するときは、この点を考慮してください。

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

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

  • 開く

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

  • 編集

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

  • 削除

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

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

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

  • 実行

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

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

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

  • 停止

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

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

  • リロード

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

  • [準備]

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

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

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

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

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

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

  • テーブルを再作成

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

    また、このデータ タスクを消費するすべてのダウンストリーム データ タスクを作成する必要もあります。

  • スケジュール

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

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

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

  • データを保存

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

列の削除

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

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

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

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

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

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

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

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

  • Qlik CloudAmazon S3 を通じて)

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

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

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

制限事項

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

詳細を見る

このページは役に立ちましたか?

このページまたはコンテンツに、タイポ、ステップの省略、技術的エラーなどの問題が見つかった場合は、お知らせください。改善に役立たせていただきます。