クラウド ストレージ ターゲットの設定

必要に応じて、既定のデータ レイク ランディング設定を変更できます。

一般

更新方法

2 種類の異なるモードでデータをランディングできます。データ レイクのランディング タスクの準備が完了すると、モードの変更はできません。

• 変更テーブルを使用した変更データ キャプチャ (CDC): データ レイクのランディング タスクは、フル ロード (選択されたすべてのテーブルがターゲットにロードされる) から開始されます。ターゲット データは、CDC (変更データ キャプチャ) テクノロジーを使用して最新の状態に保たれます。

  情報メモDDL 操作の CDC (変更データ キャプチャ) はサポートされていません。

  Data Movement gateway を使用する場合、SaaS アプリケーションをソースとする場合を除き、ソースからの変更はほぼリアルタイムでキャプチャされます。Data Movement gateway を使用せずに、または SaaS アプリケーションをソースとして使用して作業する場合、変更はスケジューラーの設定に従ってキャプチャされます。詳細については、「Scheduling tasks」を参照してください。

• リロード: 選択したソーステーブルからターゲットプラットフォームへのデータのフル ロードを実行し、必要に応じてターゲット テーブルを作成します。フル ロードはタスクの開始時に自動的に実行されますが、必要に応じて手動で実行することや、定期的に実行するようにスケジュールすることもできます。

  情報メモSaaS アプリケーションコネクタを使用する場合、この設定は利用できません。

   

使用するフォルダー

ファイルを書き込むバケット フォルダーに応じて、次のいずれかを選択します。

• 既定のフォルダー

  既定のフォルダー形式は <your-project-name>/<your-task-name> です。

• ルート フォルダー

  ファイルはルート バケット フォルダーに書き込まれます。

• フォルダー

  フォルダーの名前を指定します。フォルダーがまだ存在しない場合は、データ タスクの実行中に作成されます。

  情報メモ フォルダー名に特殊文字 (@、#、! など) を含めることはできません。

データのアップロード

ファイル属性

項目区切り記号

ターゲット ファイル内の項目 (列) を区切るために使用される区切り記号。既定はカンマです。

区切り記号としてカンマを使用する例:

"mike","male"

区切り記号には、標準文字または 16 進数値を使用できます。「0x」というプレフィックスは、16 進数の区切り記号 (例: 0x01 = SOH) を示すために使用する必要があります。[項目区切り記号]、 [レコード区切り記号]、 [Null 値] 項目では、区切り記号は連結された 16 進数値 (例: 0x0102 = SOHSTX) で構成できますが、 [引用符] および [エスケープ文字を引用符で囲む] 項目では、単一の 16 進数値のみを使用できます。

16 進数 0x00 はサポートされていません (0x01-0xFF のみがサポートされます)。

Null 値

ターゲット ファイル内で Null 値を示すために使用される文字列。

例 (\n はレコード区切り記号、@ は Null 値):

レコード区切り記号

ターゲット ファイル内のレコード (行) を区切るために使用される区切り記号。既定は改行 (\n) です。

例:

引用符

テキスト列の最初と最後に使用される文字。既定は二重引用符 (") です。列区切り記号を含む列が二重引用符で囲まれている場合、列区切り記号は列区切り記号としてではなく、実際のデータとして解釈されます。

例 (@ は引用符):

エスケープ文字を引用符で囲む

実際のデータで引用符をエスケープするために使用される文字。既定は二重引用符 (") です。

例 (" は引用符、\ はエスケープ文字):

Parquet バージョン

ターゲット プラットフォームがサポートするバージョンに応じて、使用するバージョンを選択します。Parquet バージョン 1.0 は MICRO タイムスタンプ ユニットのみをサポートしますが、Parquet バージョン 2.6 は MICRO タイムスタンプ ユニットと NANO タイムスタンプ ユニットの両方をサポートします。

Parquet タイムスタンプ ユニット

Parquet バージョンが 2.6 に設定されている場合は、MICRO または NANO を選択します。Parquet バージョンが 1.0 に設定されている場合は、MICRO のみがサポートされます。

Parquet 最大 LOB サイズ (KB)

既定の最大 LOB サイズは 64 KB で、この項目に入力できる最大値は 10,000 KB です。LOB 列の処理にはより多くのリソースが必要となり、パフォーマンスに影響を与えます。64 KB を超える LOB データをレプリケートしており、すべての LOB データをターゲットにレプリケートする必要がある場合にのみ、この値を増やします。

最大ファイル サイズ

ファイルが閉じる (および必要に応じて圧縮される) 前に到達できる最大サイズ。

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

次を使用してファイルを圧縮:

圧縮オプションの 1 つを選択してターゲット ファイルを圧縮するか、圧縮しない場合は [NONE] (既定) を選択します。使用できる圧縮オプションは、選択したファイル形式に応じて決定されます。

メタデータ ヘッダーを追加

必要に応じて、データ ファイルにヘッダー行を追加できます。ヘッダー行には、ソース列名および/または中間 (例:Qlik Talend Data Integration) データ タイプを含めることができます。

[列名あり] と [データ タイプあり] の両方が選択されている場合の、ヘッダー行のあるターゲット ファイルの例:

Position:DECIMAL(38,0),Color:VARCHAR(10)

1,"BLUE"

2,"BROWN"

3,"RED"

...

変更処理

このセクションでは、変更処理の条件設定について説明します。

変更の適用/保存のタイミング

• ファイル サイズが到達: ファイルをターゲットにアップロードする前に蓄積する変更データの最大サイズを指定します。
• 経過時間が到達: 経過時間が x に達しました。

メタデータ ファイル

[ターゲット フォルダにメタデータ ファイルを作成] オプションが選択されている場合、各データ ファイルに対応する拡張子 .dfm のメタデータ ファイルが、指定したターゲット フォルダの下に作成されます。メタデータ ファイルは、ソース コネクタ タイプ、ソース テーブル名、データ ファイル内のレコード数など、タスク/データに関する追加情報を提供します。

メタデータ ファイルの詳細な説明と使用方法については、「メタデータ ファイルの説明 」を参照してください

メタデータ

LOB 列

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

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

JSON 列のマッピング

互換性のあるソース JSON 列とターゲット JSON 列のマッピング

このオプションを選択すると、ソース上の JSON カラムはターゲット上の JSON カラムに自動的にマッピングされます。

このオプションの状態や見え方は、以下の要因によって決まります。

• 新規タスク: このオプションは、ソースとターゲットの両方が JSON データ型をサポートしている場合、デフォルトで有効になります。

• 既存のタスク: このオプションは、ソースとターゲットの両方が JSON データ型をサポートしている場合でも、デフォルトで無効になります。これは、ターゲット データが STRING 形式であることを期待する (レガシー動作) 変換などの下流プロセスとの後方互換性を維持するためです。このオプションを無効のままにすることも、下流のプロセスを編集して JSON 形式と互換性を持たせてからこのオプションを有効にすることもできます。

• 新規および既存のタスク: ソースのみが JSON データ型をサポートしている場合、このオプションは表示されません。後の段階でターゲットに JSON サポートが追加された場合、このオプションは表示されるようになりますが、無効のままになります。これは、ターゲット データが STRING 形式であることを期待する (レガシー動作) 変換などの下流プロセスとの後方互換性を維持するためです。

コントロール テーブル

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

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

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

フル ロード

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

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

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

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

フル ロードの完了後

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

初期ロード用

変更の保存

変更データ キャプチャ (CDC) の更新方法を選択すると、ソース データへの更新はターゲット プラットフォーム上の変更テーブルに保存されます。変更テーブルは、ソースからのすべての挿入、更新、削除操作をキャプチャし、後続のアプリケーションが変更を増分処理できるようにします。

このセクションでは、DDL の処理、更新イメージの格納、テーブル作成時の動作といった、変更テーブルのオプションを設定する方法について説明します。

変更テーブルの詳細については、「変更テーブルの使用」を参照してください。

基本設定

DDL オプション

DDL (データ定義言語) オプションは、ソースからのスキーマ変更を変更テーブルでどのように処理されるかを決定します。

• 変更テーブルに適用: このオプションを選択すると、システムはソース テーブルからの DDL 変更 (列の追加や削除など) を、対応する変更テーブルに自動的に適用します。ダウンストリーム アプリケーションが、ソースからのすべてのスキーマ変更を変更テーブルに反映する必要がある場合に、このオプションを使用します。

• 無視: システムは、ソースに対するすべての DDL 変更を無視します。変更テーブルの構造は変更されていません。ソースでの DDL 変更が保存済みの変更に影響を与えないようにする場合、またはターゲット システムで固定のテーブル スキーマが必要な場合に、このオプションを使用します。

詳細設定

更新時

UPDATE 設定は、ソース レコードが更新されたときにどのデータをキャプチャするかを制御します。

更新前後のイメージを保存: システムは、元のデータ (更新前) と変更されたデータ (更新後) の両方をキャプチャします。このオプションはより多くのストレージを必要としますが、完全な監査情報を提供するため、ダウンストリームのシステムで新旧の値を比較したり、複雑な変更分析を実行したりできます。アプリケーションが完全な変更コンテキストを必要とする場合に、これを使用します。

このオプションが無効になっている場合、システムは変更されたデータ (更新後) のみをキャプチャし、元の値はキャプチャしません。このオプションにより、ターゲット上のストレージ要件が削減されます。変更されたレコードの現在の状態のみが必要で、変更前の値の履歴を必要としない場合に使用します。

変更テーブルの作成

デフォルトの変更テーブルのサフィックスとヘッダー列のプレフィックスを上書きする

• サフィックス: すべての変更テーブルのサフィックスとして使用する文字列を指定します。規定値は __ct です。変更テーブル名は、ターゲット テーブルの名前にサフィックスが追加されたものです。たとえば、既定値を使用すると、変更テーブルの名前は HR__ct になります。
• ヘッダー列のプレフィックス: すべての変更テーブルのヘッダー列のプレフィックスとして使用する文字列を指定します。既定値は header__ です。たとえば、既定値を使用すると、ヘッダー列 stream_position は header__stream_position になります。

フル ロードの開始時に既存の変更テーブルをどのように処理するかを決定する

フル ロードが開始されると、これらの設定によって、ターゲット上の既存の変更テーブルの処理方法が決定されます。データ リカバリとストレージの要件にもっとも適したオプションを選択します。

• DROP および CREATE: システムは既存の変更テーブルを完全に削除し、新しい空のテーブルを作成します。以前に保存された変更はすべて削除されます。フル ロード サイクルごとに、新しく開始したい場合にこれを使用してください。

• 古い変更を削除し、新しい変更を既存の変更テーブルに保存する: システムは、既存の変更テーブルの構造やメタデータに影響を与えることなく、そこからすべてのデータを削除します。新しい変更は同じテーブルに保存されます。テーブル構造は維持しつつ、以前の変更をクリアしたい場合にこれを使用してください。

• 既存の変更テーブルに古い変更を保持し、新しい変更を保存する: システムは、変更テーブル内の既存のすべてのデータおよびメタデータを保持します。既存のデータに新しい変更が追加されます。複数のフル ロード サイクルにわたってすべての変更を累積する必要がある場合にこれを使用してください。

データ パーティションの変更

標準的なランディング タスク (データ パーティションの変更を使用しない場合) では、変更は順不同でターゲットにランディングされます。データ パーティションの変更により、多くのテーブルからの変更データを一貫した方法で処理できるようになります。パーティションの期間とパーティション化の基準時間を定義できるため、パーティション化されたデータの全体的な一貫性が確保されます (部分的なトランザクションがない、注文行のない注文ヘッダーがない、など)。

パーティションに関する情報は、ターゲット データベースの attrep_cdc_partitions コントロール テーブルに記録されます。この情報は、さらに処理が必要なパーティション化されたデータを識別するために使用できます。

ソース タイプに応じたパーティショニングの仕組みを理解する

• データベース ソースから:

  標準的なランディング タスク (データ パーティションの変更を使用しない場合) では、変更は順不同でターゲットにランディングされます。データ パーティションの変更により、多くのテーブルからの変更データを一貫した方法で処理できるようになります。パーティションの期間とパーティション化の基準時間を定義できるため、パーティション化されたデータの全体的な一貫性が確保されます (部分的なトランザクションがない、注文行のない注文ヘッダーがない、など)。

  • スケジュールされた CDC: スケジュールされたタスク インスタンスの実行時にパーティションが作成されます。たとえば、タスクが毎日深夜に実行されるようにスケジュールされており、 [パーティション分割間隔] が 4 時間に設定されている場合、作成されるパーティションの数は、直近 24 時間の間にコミットが行われた時刻に基づいて決まります。コミットが 01:00～03:00 と 16:15～18:00 に発生し、 [パーティション基準時間] が 0:00 に設定されている場合、0:00～04:00 と 16:00～20:00 の 2 つのパーティションが作成されます。

  • 継続的な CDC: パーティション分割間隔が 4 時間に設定されている場合、Replicate はその期間中に発生したすべてのコミットを含むパーティションを 4 時間ごとに作成します。4 時間コミットがなかった場合、その期間のパーティションは作成されません。

• SaaS アプリケーション ソースから:

  SaaS アプリケーション ソースからデータを抽出するタスクは、常にスケジュールされます。SaaS アプリケーション ソースにはコミットの概念が存在しないため、パーティションはデータ抽出時間に基づきます。スケジュールされたタスク インスタンスが実行されると、データ抽出が開始されます。たとえば、タスクが毎日深夜に実行されるようにスケジュールされており、 [パーティション分割間隔] が 4 時間に設定されている場合、作成されるパーティションの数は、データ抽出の期間に基づいて決まります。データ抽出にかかる時間が 2 時間未満の場合、単一のパーティションが作成されます。ただし、例として抽出に 6 時間かかる場合、2 つのパーティションが作成されます。

パーティション化のオプション

• パーティション間隔 - 各パーティションの長さ (時間と分) を指定します。

  情報メモ

  パーティションの長さは 1 時間を超えるように指定することをお勧めします。パーティションの長さを 1 時間未満に指定すると待機時間が改善される可能性がありますが、ターゲット上に多数のパーティションを作成すると、(ターゲットの) パフォーマンスに影響を与える可能性もあります (特に大量の変更を伴うシステムの場合)。

  最後のパーティションが作成された時刻より前からタスクを再開すると、データ レイクのランディング タスクは、すでに閉じられたパーティションに書き込みます。

• パーティション基準時間 - パーティションは 24 時間の期間内に作成されます。これは、ソース データベースで指定された UTC 時間の「パーティション基準時間」に従って計算されます。たとえば、パーティション間隔が 8 時間、「パーティション基準時間」時刻が 02:00 の場合、02:00-10:00、10:00-18:00、18:00-02:00 のパーティションが作成されます。ただし、必ずしもこの順序である必要はありません。たとえば、タスクが 01:00 に開始された場合、最初のパーティションのタイムフレームは 18:00-02:00 になります。さらに、タスクがパーティションの途中 (04:00 など) で開始された場合、04:00 より前に変更がキャプチャされなかったとしても、その変更データは 02:00-10:00 のパーティションに挿入されます。

テーブルのヘッダー列

変更テーブルには、設定可能なプレフィックスを持つシステム メタデータ列が含まれています。デフォルトでは、これらの列にはプレフィックスとして header__ が付加されます (例: header__stream_position、header__operation)。これらの列は、操作タイプ (INSERT、UPDATE、DELETE) や変更が発生した順序など、各変更レコードに関する情報を提供します。

そのメタデータが不要な場合は、変更テーブルから特定のヘッダー列を除外できます。これにより、ターゲット プラットフォームにおけるストレージ要件が削減されます。

エラー処理

データ エラー

データ切り捨てエラー

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

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

その他のデータ エラー

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

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

データ エラー処理のエスカレーション

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

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

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

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

テーブル エラー

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

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

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

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

環境

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

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

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

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

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

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

変更処理のチューニング

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

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

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

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

バッチ チューニング

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

  情報メモ

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

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

Interval (インターバル)

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

  ソースからの変更の読み取り間隔 (分単位)。有効な範囲は 1 ～ 1440 です。

  情報メモ

  このオプションは、以下を使用するタスク専用です。

  • Data Movement gateway
  • 変更データ キャプチャ (CDC) の更新方法

変更をチェック

• デルタ抽出間隔に従う:  このオプションを選択すると、データ タスクは [デルタ抽出間隔] に従って変更をチェックします。

  情報メモ間隔は各「ラウンド」の後に開始されます。ラウンドは、データ タスクがソース テーブルから変更を読み取り、それをターゲットに送信 (単一のトランザクションとして) するのにかかる時間として定義できます。ラウンドの長さはテーブルの数や変更に応じて異なります。したがって、間隔を 10 分に指定し、ラウンドに 4 分かかる場合、変更をチェックする実際の時間は 14 分になります。

  • デルタ抽出間隔: システムからデルタが抽出される頻度。既定は 60 秒ごとになっています。

• スケジュールどおり: このオプションを選択すると、データ タスクはデルタを 1 回抽出して停止します。その後はスケジュールどおりに実行が継続されます。

  情報メモこのオプションは、CDC サイクル間の間隔が 24 時間以上の場合にのみ関連します。

  スケジュールに関する情報:

  • レプリケーション プロジェクトの「データレイクにデータをランディングする」タスクについては、「レイク ランディング タスクの CDC のスケジュール設定」を参照してください

その他のチューニング

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

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

  情報メモこの設定は、SaaS アプリケーション コネクタを使用するタスクでは利用できません (ただし、Lite コネクタを使用する場合を除きます)。

スキーマの自動進化

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

文字置換

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

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

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

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

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

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

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

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

詳細オプション

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

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

レイク ランディング タスクの CDC のスケジュール設定

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

• Data Movement gateway を使用せずにデータ ソースにアクセスする
• Lite コネクタではない SaaS アプリケーションコネクタを使用します。
• SAP ODataソースから変更をキャプチャする際に、スケジュール済みオプションを使用する場合。

スケジュールにより、ソース データセットの変更に応じてターゲット データセットを更新する頻度が決定されます。更新頻度はスケジュールによって決定されますが、更新方法はデータセットの種類によって決まります。 データセットが CDC をサポートしている場合、そのデータセットに対する変更のみが取得され、対応するターゲット テーブルに伝播されます。データセットが CDC をサポートしていない場合 (ビューなど)、データセット全体を再ロードすることで変更が伝播されます。 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. 設定を保存します。

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