Standard、Premium、または Enterprise サブスクリプションを使用して、データをレプリケートします

レプリケーションタスクを設定するには:

[データ統合]>[プロジェクト] で、 [プロジェクトを作成] をクリックします。
[新しいプロジェクト] ダイアログで、次の操作を実行します。
1. プロジェクトの [名前] を入力します。
2. プロジェクトを作成する [スペース] を選択します。
3. 必要に応じて [説明] を入力します。
4. [ユースケース] として [レプリケーション] を選択します。
5. 必要に応じて、何も構成せずに空のプロジェクトを作成する場合は、 [開く] チェックボックスをオフにします。
6. [作成] をクリックします。
  
  次のいずれかが発生します。
  - [新しいプロジェクト] ダイアログの [開く] チェックボックスがオンになっている場合 (既定)、プロジェクトが開きます。
  - [新しいプロジェクト] ダイアログの [開く] チェックボックスがオフの場合、プロジェクトはプロジェクトのリストに追加されます。プロジェクトのメニューから [開く] を選択すると、後でプロジェクトを開くことができます。
プロジェクトが開いたら、 [データをレプリケートする] をクリックします。

[データをレプリケートする] ウィザードが開きます。
[基本設定] タブで、レプリケーションタスクの名前と説明を指定します。[次へ] をクリックします。
[ソース接続を選択] タブで、ソースデータへの接続を選択します。必要に応じて、 [アクション] 列のメニューから [編集] を選択して、接続設定を編集できます。

データソースへの接続をまだ作成していない場合は、タブの右上にある [接続を作成] をクリックして接続を作成する必要があります。

左側のフィルターを使用して、接続のリストをフィルタリングできます。接続は、ソースタイプ、ゲートウェイ、スペース、所有者でフィルタリングできます。接続リストの上にある [すべてのフィルター] ボタンには、現在のフィルターの数が表示されます。このボタンを使用して、左側の [フィルター] パネルを閉じたり開いたりできます。現在アクティブなフィルターは、使用可能な接続のリストの上にも表示されます。

右側のドロップダウンリストから [最終更新日]、 [最終作成日]、または [アルファベット順] を選択してリストを並べ替えることもできます。ソート順を変更するには、リストの右側にある矢印をクリックします。

データソース接続を選択した後、必要に応じて、タブの右上にある [接続をテスト] をクリックし (推奨)、[次へ] をクリックします。
[データセットを選択] タブで、レプリケーションタスクに含めるテーブルやビューを選択します。データベースからのデータの選択 で説明されているように、ワイルドカードを使用して選択ルールを作成することもできます。
[ターゲット接続を選択] タブで、使用可能な接続のリストからターゲットを選択し、[次へ] をクリックします。機能的には、このタブは前述の [ソース接続を選択] タブと同じです。
[設定] タブで、必要に応じて次の設定を変更し、[次へ] をクリックします。

レプリケーションモード

情報メモSaaS アプリケーションソースからレプリケートする場合、フルロードレプリケーションモードが既定で有効になっており、無効にすることはできません。
- フルロード: 選択したソーステーブルからターゲットプラットフォームにデータをロードし、必要に応じてターゲットテーブルを作成します。フルロードはタスクの開始時に自動的に実行されますが、必要に応じて手動で実行することもできます。
- 変更を適用: ソーステーブルに加えられた変更を反映して、ターゲットテーブルを最新の状態に保ちます。
- 保存先の変更: ソーステーブルへの変更を変更テーブル (ソーステーブルごとに 1 つ) に保存します。
  
  詳細は、変更の保存をご覧ください。
Data Movement gateway を使用する場合、変更はソースからほぼリアルタイムでキャプチャされます。Data Movement gateway を使用しない場合 (コネクタ設定で [データゲートウェイ] を [なし] に設定)、変更はスケジューラ設定に従ってキャプチャされます。既定の変更キャプチャの間隔は 6 時間ごとです。詳細は、Data Movement gateway を使用しない場合のタスクのスケジュール設定をご覧ください。

変更適用モード

情報メモデータウェアハウスターゲットにレプリケートする場合、使用する変更の適用モードを選択することはできません。効率を最大限に高めるために、変更は常にバッチ最適化モードで適用されます。

変更は、次のいずれかの方法でターゲットテーブルに適用されます。
- バッチ最適化: これが既定です。このオプションを選択すると、変更はバッチで適用されます。トランザクションをもっとも効率的な方法でバッチにグループ化するための前処理アクションが発生します。
- トランザクション: このオプションを選択すると、各トランザクションをコミットされた順序で個別に適用します。この場合、すべてのテーブルで厳密な参照整合性が確保されます。
ステージングエリアへの接続

以下にリストされているデータウェアハウスにレプリケーションする場合は、ステージングエリアを設定する必要があります。データは、ウェアハウスに転送される前にステージングエリアで処理および準備されます。
既存のステージングエリアを選択するか、[新規作成] をクリックして新しいステージングエリアを定義し、クラウドストレージへの接続 の指示に従います。

接続設定を編集するには、[編集] をクリックします。接続をテストするには (推奨)、[接続のテスト] をクリックします。

どのステージングエリアがどのデータウェアハウスでサポートされているかについては、ターゲットプラットフォームのユースケースとサポートされるバージョン の [ステージングエリアとしてサポート] 列を参照してください。

レプリケーションスケジューラー

情報メモこの設定は、Data Movement gateway を使用せずにデータソースにアクセスする場合にのみ関連します。Data Movement gateway の利点とそれを必要とするユースケースの詳細については、「Qlik Data Gateway - データ移動」を参照してください。
- 毎回データをレプリケートする: データソースから変更をキャプチャする頻度をスケジュールし、開始時刻と開始日を設定できます。ソースデータセットが CDC (変更データキャプチャ) をサポートしている場合は、ソースデータへの変更のみがレプリケーションされ、対応するターゲットテーブルに適用されます。ソースデータセットが CDC をサポートしていない場合 (ビューなど)、すべてのソースデータを対応するターゲットテーブルに再ロードすることによって変更が適用されます。一部のソースデータセットが CDC をサポートし、一部がサポートしない場合は、2 つの個別のサブタスクが作成されます ( [変更の適用] または [変更の保存] レプリケーションオプションが選択されていると想定)。 1 つは CDC をサポートしないデータセットを再ロードするためのもので、もう 1 つは CDC をサポートするデータセットへの変更をキャプチャするためのものです。
  
  タスクのセットアップウィザードを使用すると、基本的な 1 時間間隔でスケジュールを設定できます。タスクの設定が完了したら、Data Movement gateway を使用しない場合のタスクのスケジュール設定 で説明されているように、さまざまなスケジュールオプションを検討できます。
データソースの種類とサブスクリプションティアに応じた最小スケジュール間隔の詳細については、「許容される最小スケジュール間隔」を参照してください。
[概要] タブに、データパイプラインのビジュアルが表示されます。選択したデータセットの一部が CDC をサポートしていない場合は、CDC タスク用とリロードタスク用の 2 つのパイプラインが表示されます。[<名前> データタスクを開く]、または [Do nothing] (何もしない) を選択し、 [作成] をクリックします。

選択に応じて、タスクが開かれるか、プロジェクトのリストが表示されます。
タスクを開くことを選択した場合、 [データセット] タブには、選択したソーステーブルの構造とメタデータが表示されます。これには、明示的にリストされたすべてのテーブルと、選択ルールに一致するテーブルが含まれます。

データソースからさらにテーブルを追加する場合は、 [ソースデータの選択] をクリックします。
必要に応じて、 データレプリケーションタスクの設定 の説明に従ってタスク設定を変更します。
データセットの変換を実行し、データをフィルタリングし、列を追加できます。

詳細については、「データセットの管理」を参照してください。
必要な変換を追加したら、[データセットの検証] をクリックしてデータセットを検証できます。検証に失敗した場合は、先に進む前にエラーを修正してください。

詳細については、「データセットの検証と調整」を参照してください。
準備ができたら、 [準備] をクリックしてデータタスクをカタログ化し、実行の準備をします。
データタスクの準備が完了したら、[実行] をクリックします。

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

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

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

[ロードの優先度] をクリックします。
各データセットのロードの優先度を選択します。

既定のロードの優先度は [標準] です。データセットは次の優先順位でロードされます。
- 最高
- より高く
- 高
- 標準
- 低
- より低く
- 最低
同じ優先度のデータセットは順不同でロードされます。
[OK] をクリックします。

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

メタデータの更新

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

この操作は、タスクの [デザイン] ビュー内のテーブルにのみ影響します。

次のいずれかを実行できます:
- [...] をクリックし、 [メタデータを更新] をクリックして、タスク内のすべてのデータセットのメタデータを更新します。
- [データセット] 内のデータセットで [...] をクリックし、 [メタデータを更新] をクリックして、単一のデータセットのメタデータを更新します。
画面の下部にある [メタデータを更新] でメタデータの更新のステータスを確認できます。にカーソルを合わせると、メタデータが最後に更新された日時を確認できます。
変更を適用するには、データタスクを準備します。

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

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

列が削除されると、ストレージから履歴データが失われないように、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 変更を検出できます。一部の変更を自動的に適用することもできます。

スキーマの進化は、ウェブアプリケーションソースまたは Qlik Talend Cloud スターターサブスクリプションでは使用できません。

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

変更タイプごとに、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 精度列への変更はキャプチャされません。

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

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

DDL の変更	変更を実施するには	現在の状態を維持するには
列を追加	メタデータを更新し、タスクを準備してから、タスクを実行します。	必要なアクションはありません
テーブルを作成	メタデータを更新し、タスクを準備してから、タスクを実行します。	必要なアクションはありません
列のデータ型を変更	制限を確認してください。制限が適用されない場合: メタデータを更新し、タスクを準備してから、タスクを実行します。	現在の状態の保持は、常にサポートされているわけではありません。考えられる回避策: 列のデータ型を手動で変更します。この操作をダウンストリームのタスクで繰り返す必要があります。新しい列を作成し、古い列を新しい列に移動してから、2 つの列を結合するビューを手動で作成します。
テーブルの名前を変更	制限を確認してください。制限が適用されない場合: タスクを準備してから、タスクを実行します。	古い名前に対する明示的な名前変更ルールを定義します。
列名を変更	制限を確認してください。制限が適用されない場合: メタデータを更新し、タスクを準備してから、タスクを実行します。	メタデータを更新し、古い名前に対する明示的な名前変更ルールを定義します。

データをレプリケートする際の制限と考慮事項

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

右から左に記述する言語の列では、変換はサポートされません。
名前に特殊文字 (例: #、\、/、-) が含まれる列では変換を実行できません。
LOB/CLOB データ型でサポートされている唯一の変換は、ターゲット上の列をドロップすることです。
変換を使用して列の名前を変更し、同じ名前の新しい列を追加することはサポートされていません。

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

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

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

こちらにフィードバックをお寄せください