レイク ランディングの設定

レイク ランディング データ タスクの設定を構成できます。

• ランディング タスクを開き、ツール バーの [設定] をクリックします。

「設定: <タスク名>」ダイアログが開きます。使用可能な設定については以下で説明します。

一般

更新方法

ランディングは常にフル ロードで開始します。フル ロードが完了したら、次のいずれかの方法を使用して、ランディング データを最新の状態に保つことができます。

情報メモランディング データ タスクの準備操作が完了すると、更新方法を変更することはできません。

• 変更データキャプチャ (CDC)

  ランディング データは、CDC (変更データ キャプチャ) テクノロジーを使用して最新の状態に保たれます。CDC は、すべてのデータ ソースでサポートされていない可能性があります。CDC は、列の名前変更、またはメタデータの変更などの DDL 操作をキャプチャしません。

  データに CDC をサポートしていないビューまたはテーブルも含まれている場合、2 つのデータ パイプラインが作成されます。CDC をサポートするすべてのテーブルを含む 1 つのパイプラインと、更新方法として [リロード] を使用する他のすべてのテーブルとビューを含む別のパイプライン。

• リロード

  すべてのランディング データは、ソースからリロードされます。これは、ソースが CDC をサポートしていない場合に役立ちますが、サポートされている任意のデータ ソースで使用できます。

  リロードを定期的にスケジュールできます。

  情報メモこの設定は、SaaS アプリケーション プレビュー コネクタを使用する場合は使用できません。[接続を作成] ダイアログおよびオンライン ヘルプの両方で、Preview コネクタは ボタンで表示されます。

使用するフォルダー

ステージング エリアにデータをランディングするときに使用するフォルダーを選択できます。

• 既定のフォルダー

  既定の名前 <project name>/<data task name> のフォルダーが作成されます。

• ルート フォルダー

  ストレージのルート フォルダーにデータを保存します。

• フォルダー

  使用するフォルダーの名前を指定します。

データのアップロード

• 最大ファイル サイズ (MB)

  ファイルが閉じる前に到達できる最大サイズ。並列実行オプションと併用すると、小さいファイルの方がアップロードが速くなり (ネットワークに応じて異なる)、パフォーマンスが向上する可能性があります。ただし、小さなファイルでデータベースを乱雑にすることは一般的に悪い習慣であると考えられています。

  情報メモこの設定は、Qlik Cloud を除くすべてのデータ プラットフォームに関連します。

• 圧縮を使用

  選択すると、CSV ファイルは Google BigQuery にアップロードされる前に (gzip を使用して) 圧縮されます。

  情報メモ

  • この設定は、Google BigQuery にのみ関連します。
  • Data Movement gateway 2023.5.16 以降が必要です。

メタデータ

LOB 列

• LOB 列を含めて列サイズを次に制限 (KB):

  タスクに LOB 列を含めることを選択でき、さらに最大 LOB サイズを設定できます。最大サイズより大きい LOB は切り捨てられます。

  情報メモ Azure Synapse Analytics をターゲットとして使用する場合、最大 LOB サイズは 7 MB を超えることはできません。

コントロール テーブル

ターゲット プラットフォームに作成するコントロール テーブルを次の中から選択します。

• ランディング ステータス: タスクのステータス、タスクによって消費されるメモリ量、データ プラットフォームにまだ適用されていない変更の数、Data Movement gateway が現在読み取りを行っているソース エンドポイント内の位置など、現在のランディング タスクに関する詳細を提供します。
• 一時停止のテーブル: 一時停止されたテーブルのリストと、それらが一時停止された理由を提供します。
• ランディング履歴: ランディング タスク中に処理されたレコードの数と量、CDC タスク終了時の待機時間などを含む、タスク履歴に関する情報を提供します。

• DDL 履歴: タスク中に発生した、サポートされているすべての DDL 変更の履歴が含まれます。

  DDL 履歴テーブルは、次のターゲット プラットフォームでのみサポートされています。

  情報メモAmazon Redshift、Amazon S3、Google Cloud Storage、Snowflake には、Data Movement gateway 2024.11.14 以降が必要です。

  • Databricks

  • Microsoft Fabric
  • Amazon Redshift
  • Amazon S3
  • Google Cloud Storage
  • Snowflake

各コントロール テーブルの詳細については、「コントロール テーブル」を参照してください

フル ロード

パフォーマンスのチューニング

• 並行してロードするテーブルの最大数: ターゲットに一度にロードする、テーブルの最大数を入力します。既定値は 5 です。

• トランザクション整合性タイムアウト (秒): フル ロード操作を開始する前に、開いているトランザクションが閉じるまで待機する秒数を入力します。既定値は 600 (10 分) です。オープンになっているトランザクションがある場合でも、タイムアウト値に達するとフル ロードが開始されます。

  情報メモフル ロードの開始時にオープンしていたが、タイムアウト値に達した後にのみコミットされたトランザクションをレプリケートするには、ターゲット テーブルをリロードする必要があります。
• フル ロード時のコミット レート:一緒に転送できるイベントの最大数。既定値は 10000 です。

フル ロードの完了後

主キーまたは一意を作成: フル ロードが完了するまで、データ プラットフォームの主キーまたは一意のインデックスの作成を遅らせる場合は、このオプションを選択します。

初期ロード用

SaaS アプリケーション ソースからデータを移動する場合、初期フル ロードを実行する方法を設定できます。

エラー処理

データ エラー

データ切り捨てエラーの場合: 1 つ以上の特定のレコードで切り捨てが発生した場合に実行する処理を選択します。リストから次のいずれかを選択できます。

• 無視: タスクは続行され、エラーは無視されます。
• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません
• タスクを停止: タスクは停止され、手動による操作が必要となります。

その他のデータ エラーの場合: 1 つ以上の特定のレコードでエラーが発生した場合に実行する処理を選択します。リストから次のいずれかを選択できます。

• 無視: タスクは続行され、エラーは無視されます。
• テーブルを一時停止: タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません
• タスクを停止: タスクは停止され、手動による操作が必要となります。

その他のデータ エラーが発生した場合にエラー処理をエスカレートします (テーブルごと): このチェック ボックスをオンにすると、非切り捨てデータ エラーの数 (テーブルごと) が指定された量に達したときにエラー処理がエスカレートされます。有効な値は 1 ～ 10,000 です。

エスカレーション アクション: エラー処理がエスカレートされたときに実行される処理を選択します。使用できるアクションは、上記の [その他のデータ エラーの場合] ドロップダウン リストから選択したアクションに応じて異なります。

• テーブルを一時停止 (既定): タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータは landed されません。

• タスクを停止: タスクは停止され、手動による操作が必要となります。

テーブル エラー

テーブル エラーを返す前の再試行回数

このオプションを使用すると、テーブル エラー処理ポリシーがトリガーされるタイミングを制御できます。既定では、テーブル エラーが発生すると、3 回の再試行後にテーブルが一時停止されるか、タスクが停止されます (選択したアクションに応じて)。SaaS アプリケーションの計画メンテナンスにより、テーブル エラーが発生する場合があります。このような場合、テーブル エラー処理ポリシーがトリガーされる前にメンテナンスを完了するには、既定の再試行回数では不十分な可能性があります。タスクが実行されるたびに再試行が実行されるため、これはタスクのスケジュール間隔にも依存します。たとえば、タスクを 1 時間ごとに実行するようにスケジュールし、タスクの実行開始と同時に SaaS アプリケーションがメンテナンスのためにオフラインになった場合、既定の 3 回の再試行により、テーブル エラー処理ポリシーがトリガーされることなく、SaaS アプリケーションを最大 3 時間オフラインにすることができます。メンテナンス期間が長くなると、テーブル エラー処理ポリシーがトリガーされないように、再試行回数を増やす (またはスケジュールを変更する) 必要があります。

まとめると、SaaS アプリケーションが定期的にメンテナンスされることがわかっている場合、テーブル エラー処理ポリシーがトリガーされることなくメンテナンスを完了できるように、スケジュールに従って再試行回数を増やすことがベスト プラクティスとなります。

テーブル エラーが発生した場合: ドロップダウン リストから次のいずれかを選択します。

• テーブルを一時停止 (既定): タスクは続行されますが、エラー レコードのあるテーブルのデータはエラー状態に移行し、そのデータはレプリケートされません。
• タスクを停止: タスクは停止され、手動による操作が必要となります。

テーブル エラーが次の値に達した場合に処理をエスカレート (テーブルごと): このチェック ボックスをオンにすると、テーブル エラーの数 (テーブルごと) が指定された量に達した場合にエラー処理をエスカレートします。有効な値は 1 ～ 10,000 です。

エスカレーション アクション: テーブル エラーのエスカレーション ポリシーは [タスクを停止] に設定されており、変更できません。

環境

• 最大再試行数: このオプションを選択すると、復元可能な環境エラーが発生した場合にタスクを再試行する最大回数を指定できます。タスクが指定された回数再試行されると、タスクは停止され、手動による操作が必要となります。

  タスクを再試行しない場合は、チェック ボックスをオフにするか、「0」を指定します。

  タスクを無限に再試行するには、「-1」を指定します。

  • 再試行の間隔 (秒): カウンターを使用して、システムがタスクを再試行するまでに待機する秒数を選択または入力します。

    有効な値は 0 ～ 2,000 です。

• 長時間の停止の場合は再試行間隔を長くする: 長時間停止した場合の再試行間隔を長くするには、このチェック ボックスをオンにします。このオプションを有効にすると、最大再試行間隔に達するまで、各再試行と次の再試行の間隔が 2 倍になります (指定された最大間隔に従って再試行を継続します)。
  • 最大再試行間隔 (秒): [長時間の停止の場合は再試行間隔を長くする] オプションが有効になっている場合、カウンターを使用して、タスクの再試行間隔を待機する秒数を選択または入力します。有効な値は 0 ～ 2,000 です。

変更処理のチューニング

トランザクション オフロードのチューニング

次の場合に進行中のトランザクションをディスクにオフロード:

トランザクション データは通常、ソースまたはターゲットに完全にコミットされるまでメモリ内に保持されます。ただし、割り当てられたメモリより大きいトランザクション、または指定された制限時間内にコミットされないトランザクションは、ディスクにオフロードされます。

• 全トランザクションの総メモリ サイズが超過 (MB): すべてのトランザクションがディスクにオフロードされる前に、メモリで占有できる最大サイズ。規定値は 1024 です。
• トランザクション期間が次を超えています (秒): 各トランザクションがディスクにオフロードされるまでに、メモリに留まることができる最大時間。期間は、Qlik Talend Data Integration がトランザクションのキャプチャを開始した時間から計算されます。規定値は 60 です。

バッチ チューニング

このタブの設定の一部

Qlik Cloud を除くすべてのターゲットに関連する設定:

• バッチ変更を一定間隔で適用する:

• More than (最小時間): バッチ変更を適用する際の、各適用間の最小待機時間。既定値は 1 です。

  最小時間 の値を増やすと、変更がターゲットに適用される頻度が減少し、一方でバッチのサイズが増加します。これにより、大規模なバッチの処理用に最適化されたターゲット データベースに変更を適用するときのパフォーマンスが向上します。

• Less than (最大時間): バッチ変更を適用する際の、各適用間の最大待機時間 (タイムアウトを宣言するまで)。つまり、許容できる最大の待機時間のことです。既定値は 30 です。この値により、Larger than (最小時間) の値に達した後、変更を適用するまでの最大待機時間が決定されます。

• 処理メモリ (MB) が次を超えた場合にバッチを強制適用: 前処理に使用するメモリの最大量。規定値は 500 MB です。

  最大バッチ サイズについては、この値をデータ タスクに割り当て可能な最大のメモリ量に設定します。これにより、大規模なバッチの処理用に最適化されたターゲット データベースに変更を適用するときのパフォーマンスが向上します。

• 一括変更を複数のテーブルに同時に適用: このオプションを選択すると、複数のソース テーブルからの変更を適用するときのパフォーマンスが向上します。

  • テーブルの最大数: 一括変更を同時に適用するテーブルの最大数です。既定は 5 です。

  情報メモGoogle BigQuery をデータ プラットフォームとして使用する場合、このオプションはサポートされません。

• 変更処理ステートメントごとに適用される変更数を次に制限: 1 つの変更処理ステートメントで適用される変更の数を制限するには、このオプションを選択します。既定値は 10,000 です。

  情報メモGoogle BigQuery をデータ プラットフォームとして使用する場合にのみ、このオプションがサポートされます。

Qlik Cloud のみに関連する設定:

• トランザクションごとの最小変更数: 各トランザクションに含める変更の最小数。既定値は 1000 です。

  情報メモ

  変更の数がトランザクションごとの最小変更数の値以上の場合、または以下で説明する適用前にトランザクションをバッチ処理する最大時間 (秒) の値に達した場合の、いずれかの先に発生したほうのタイミングでターゲットに変更を適用します。ターゲットに適用される変更の頻度はこれら 2 つのパラメーターによって制御されるため、ソース レコードへの変更がターゲット レコードにすぐに反映されない場合があります。

• 適用前にトランザクションをバッチ処理する最大時間 (秒): タイムアウトを宣言するまでにトランザクションをバッチで収集する最大時間。既定値は 1 です。

Interval (インターバル)

• 次の頻度で変更を読み込む (分)

  ソースから変更を読み取る間隔を分単位で設定します。有効な範囲は 1 ～ 1440 です。

  情報メモ

  このオプションは次の場合にのみ使用できます。

  • Data Movement gatewayを使う
  • SaaS アプリケーション ソースからのデータのランディング
  • タスクは変更データ キャプチャ (CDC)更新方法で定義されます

その他のチューニング

• ステートメントのキャッシュ サイズ (ステートメントの数): 後で実行するためにサーバーに保存する準備済みステートメントの最大数 (ターゲットに変更を適用する場合)。既定値は 50 です。最大値は 200 です。

• プライマリ キー列を更新する際の DELETE と INSERT: このオプションを使用するには、ソース データベースで完全なサプリメンタル ロギングをオンにする必要があります。

スキーマの進化

スキーマ内の次のタイプの DDL 変更を処理する方法を選択します。スキーマの進化の設定を変更した場合は、再度タスクを準備する必要があります。次の表には、サポートされている DDL 変更に対して使用できるアクションが示されています。

文字置換

ターゲット データベース内のソース文字の置換または削除、および/または選択した文字セットでサポートされていないソース文字の置換または削除ができます。

ソース文字の置換または削除

[ソース文字の置換または削除] テーブルを使用して、特定のソース文字の置換を定義します。これは、文字の Unicode 表現がソース プラットフォームとターゲット プラットフォームで異なる場合などに便利です。たとえば、Linux では、Shift_JIS 文字セットのマイナス文字は U+2212 と表されますが、Windows では U+FF0D と表されます。

選択した文字セットでサポートされていないソース文字の置換または削除

[文字セットでサポートされていないソース文字] テーブルを使用して、選択した文字セットでサポートされていないすべての文字に対して 1 つの置換文字を定義します。

詳細オプション

これらのオプションは特定のバージョンまたは環境にのみ関連するため、UI では公開されていません。したがって、Qlik サポートまたは製品ドキュメントにより明示的に指示されない限り、これらのオプションを設定しないでください。

オプションを設定するには、オプションを [機能名の追加] 項目にコピーし、 [追加] をクリックします。次に、受け取った指示に従って値を設定するか、オプションを有効にします。

データセット セグメントの並列ロード

フル ロード中は、データセットをセグメントに分割して並列でロードすることで、大規模なデータセットのロードを高速化できます。テーブルは、データ範囲、すべてのパーティション、すべてのサブパーティション、または特定のパーティションごとに分割できます。

詳細については、「並列のランディング データセット セグメント」を参照してください。

タスクのスケジューリング

次のユース ケースでは、ターゲット データを最新の状態に保つためにスケジュール間隔を定義する必要があります。

• Data Movement gateway を使用せずにデータ ソースにアクセスする
• 変更を読み取る頻度設定をサポートしない SaaS アプリケーションコネクタの使用

スケジュールにより、ソース データセットの変更に応じてターゲット データセットを更新する頻度が決定されます。更新頻度はスケジュールによって決定されますが、更新方法はデータセットの種類によって決まります。ソース データセットが CDC (変更データ キャプチャ) をサポートしている場合は、ソース データへの変更のみがレプリケーションされ、対応するターゲット テーブルに適用されます。ソース データセットが CDC をサポートしていない場合 (ビューなど)、すべてのソース データを対応するターゲット テーブルに再ロードすることによって変更が適用されます。一部のソース データセットが CDC をサポートし、一部がサポートしない場合は、2 つの個別のサブタスクが作成されます。1 つは CDC をサポートしないデータセットをリロードするためのもので、もう 1 つは CDC をサポートするデータセットへの変更をキャプチャするためのものです。この場合、データの一貫性を確保するために、両方のタスクに対して同じスケジュール間隔を維持しないことを強くお勧めします (将来、更新頻度を変更する場合)。

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

スケジュールを変更するには:

1. データ プロジェクトを開き、次のいずれかを実行します。

   • タスク ビューで、データ タスクの [] をクリックし、 [スケジュール] を選択します。
   • パイプライン ビューで、データ タスクの [] をクリックし、 [スケジュール] を選択します。
   • ランディング タスクを開き、 [スケジュール] ツールバー ボタンをクリックします。
2. 必要に応じてスケジュール設定を変更し、 [OK] をクリックします。

Data Movement gateway に基づいて実行されなかったタスクを実行する

ネットワークの問題により、Data Movement gateway への接続が失われる場合があります。次回のスケジュールされた実行の前に Data Movement gateway への接続が復元されない場合、データ タスクはスケジュールどおりに実行できません。このような場合、接続が復元された直後に実行するかどうかを選択できます。

すべての Data Movement gateway のデフォルト設定は、管理 アクティビティセンターで定義されています。以下の説明に従って、個々のタスクに対してこれらの設定を上書きできます。

これを行うには

1. プロジェクトを開き、次のいずれかを実行します。

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

   • パイプライン ビューで、データ タスクの [] をクリックし、 [スケジュール] を選択します。

   • データ タスクを開き、 [スケジュール] ツール バー ボタンをクリックします。

   [スケジュール - <タスク>] ダイアログが開きます。

2. [このタスクにカスタム設定を使用] をオンにします。

3. ダイアログの下部で、次のいずれかの [未実行のスケジュール済みタスクを実行] オプションを選択します。

   • 可能な限り早く、その後はスケジュールどおりに: 次のスケジュールされたインスタンスの前にタスクを実行することが重要である場合

   • スケジュールどおり: 次のスケジュールされたインスタンスでタスクを実行

4. 設定を保存します。

参照先:実行されなかったスケジュールのタスクの実行。