![3
Change Tableの内容
• Change Tableの名前は、レプリケートされるテーブルと同じですが、各テーブル名にデフォルトで__ctのサフィックスが付加されます。
• 変更テーブルには、元のテーブル列とヘッダー列が含まれます。ヘッダー列には、header__のプレフィックスが含まれています。
• [Task Settings]の[Store Changes Settings]より、プレフィックス・サフィックスは変更が可能です。
Qlik Replicate Control Table
ソースシステム ターゲットシステム
変更内容を履歴として保存される
ヘッダー列 ソースのテーブル列](https://image.slidesharecdn.com/16changetables-210902061501/85/Qlik-Replicate-Change-Tables-3-320.jpg)
![4
Change Tableのテーブル構造
列名 データ型 説明
[header__]change_seq varchar (35)
タスクのすべての変更テーブルに共通する、単調に増加する変更シーケンサー。変更順序の形式は次のとおりです。
YYYYMMDhDHHmSShhxxxxxxxxxxxxxxxxxxxxxxxxx
・YYYY は 4 桁の年です (2012 など)
・MM は 2 桁の月です (範囲は 01 から 12 まで)
・HH は、その日の時間です (範囲は 00 から 23 まで)
・mmは時間の分です(範囲は00から59まで)
・SS は分単位の秒です (範囲は 00 から 59 まで)
・hh は 2 番目の 100 分の 1 です (範囲は 00 から 99 まで)
・xxxxxxxxxxxxxxxxxxxxxx は、19 桁の 0 個のプレフィックス付き変更番号 (タスクごとにグローバル) です。
通常、時間部分は、変更レコードを含むトランザクションのコミット時間を指します。Qlik Replicateにはシーケンス番号の単調性を維持するロジッ
クが含まれているため、エンドポイント時間を変更または調整すると、同じタイムスタンプ内にあるように見えても変更ナンバーが増えているように見え
る複数の変更が発生する可能性があります。
xxx…xxx は、通常、BEFORE-IMAGE レコードの場合は、一致する UPDATE レコードの変更番号と同じである (たとえば、BEFORE-
IMAGE の変更番号が 1000 で、UPDATE の変更番号が 1001 の場合は、両方とも 1001) という点を除いて、データレコードからの内部変
更番号です。これにより、テーブルとそれ自体の間で、左のテーブルはある時点までスキャンするがoperation=before-imageをフィルタアウトし、
右側のテーブルはchange_operは「B」で同じchange_seqと結合できます。
[header__]change_oper varchar (1)
操作の種類。これは、次のいずれかです。
I: INSERT
D: DELETE
U: UPDATE
B: Before Image](https://image.slidesharecdn.com/16changetables-210902061501/85/Qlik-Replicate-Change-Tables-4-320.jpg)
![5
Change Tableのテーブル構造
列名 データ型 説明
[header__] change_mask varbinary (128)
変更マスクは、変更テーブル内のどのデータ列が、ソーステーブルで変更された列に関連付けられているかを示します。
変更マスク内のビット位置は、変更テーブルの列序数に基づいています。つまり、ヘッダー列が 5 個ある場合、それらはビット 0 から 4 を占め、最初のデータ列は変
更マスクのビット 5 になります。
変更マスクは、変更マスクをリトルエンディアン順で表すバイナリ列 (バイト配列) です。
バイト 0 ビット 7 ビット6 ビット5 ビット4 ビット3 ビット2 ビット1 ビット0
バイト 1 ビット 15 ビット14 ビット13 ビット12 ビット11 ビット10 ビット9 ビット8
この例では、bit#Nは序数 N の変更テーブル列が、ソース 表内で変更された列に関連していることを示します。更新マスクが 11000 で、列序数が 3 の場合、
列は変更されませんでした。
以下に、ビットセマンティクスについて説明します。
・INSERT レコードの場合、挿入されたすべての列に関連するビットセットがあります。
・DELETE レコードの場合、主キー (または一意のインデックス) 列にのみ、関連するビットが設定されます。これにより、別のソースから主キー フィールドを見つける
ことなく、アプリケーションが DELETE ステートメントを構築できます。
・BEFORE-IMAGE レコードの場合、すべてのビットはクリア (変更マスクは空にすることができます) です。
・UPDATE レコードの場合、BEFORE-IMAGE と UPDATE の間で値が変更された各列には、関連するビットセットが設定されます。
スペースと処理の効率を高める場合、変更マスクに格納されている実際のバイト数は NULL で切り捨てることができます。つまり、末尾のゼロを格納する必要はあり
ません。処理ロジックでは、この点を考慮する必要があります。
[header__] stream_position varchar (128) ソース CDC ストリームの位置。
[header__] operation varchar (12)
変更レコードに関連付けられている操作。次のいずれかの値を指定できます。
・INSERT
・UPDATE
・DELETE
・BEFOREIMAGE
[header__] transaction_id varchar (32)
変更レコードが属するトランザクションの ID。
値は 128 ビット トランザクション ID の 16 進数の文字列です。
[header__] timestamp timestamp
元の変更 UTC タイムスタンプ (値は概算値である場合があります)。
※ PostgreSQL ソースでは、タイムスタンプはコミットが発生した後にのみ認識されます。したがって、変更がソース表にコミットされるまで、デフォルトの日付が表示さ
れます (例: 1970-01-01)。
[header__] partition_name string
データのパーティション分割の変更が有効な場合にターゲットに作成されたパーティションの名前。パーティション名は、パーティションの開始時刻と終了時刻で構成さ
れます。
例: 20170313T123000_20170313T170000](https://image.slidesharecdn.com/16changetables-210902061501/85/Qlik-Replicate-Change-Tables-5-320.jpg)
![6
Truncateの処理について
• TRUNCATE 操作では、変更テーブルは切り捨てられません。代わりに、 operation=TRUNCATEの追加のレコードがテーブルに追加されます。これは、ま
た、Hadoop ターゲットにレプリケートするときに、変更テーブルに対応する HDFS ファイルが削除されないことを意味します。
• 実際のターゲット表に関しては、 Apply ChangesとStore Changesの両方のレプリケーション・オプションが有効になっている場合、ターゲット表は切り捨てら
れます。これは、Hadoop ターゲットにレプリケートする場合、変更テーブルに対応する HDFS ファイルも削除されることを意味します。
• TRUNCATE 操作を変更テーブルとターゲット テーブルの両方に適用するには (TRUNCATE をサポートするソースの場合)、[Task Settings]の[Store
Changes Settings]タブで：
[DDL options]ドロップダウン リストから [Apply to Change Table] (既定) が選択されていることを確認します。
[When source table is truncated] ドロップダウン リストから [TRUNCATE target table] (既定) が選択されていることを確認します。](https://image.slidesharecdn.com/16changetables-210902061501/85/Qlik-Replicate-Change-Tables-6-320.jpg)
![7
注意事項
• ソース データを変更しないソースに適用されたUPDATE は、ターゲットに適用されますが、対応するChange Tableには適用されません。たとえば、ソースの
列 A の UPDATE 操作で、10 から 1 より大きい値をすべて変更し、列 A のレコードの 1 つが既に 1 である場合、そのレコードの UPDATE はChange
Tableに書き込まれません。
• ソース テーブルから選択した列に加えて、Change Tableには、操作、トランザクション、タイムスタンプなど、行が表す変更に関する詳細情報を提供する特
別なヘッダー列も含まれています。これにより、SQL クエリ言語を使用して、不正検出、傾向分析、ビジネス プロセスのトリガー、ディザスタ リカバリなど、さま
ざまな変更イベントの分析を実行できます。
• 変更テーブルを使用する場合は、変更テーブルに変更を保存するか、ターゲット テーブルに変更を適用するか、または両方の変更を保存して適用するかを
決定できます。これは、レプリケーションタスクを定義するときに決定します。この設定の詳細については、「変更の設定を保存する」を参照してください。
• 変更を適用および保存する場合、以下の条件を満たします。
ターゲットテーブルと変更テーブルは、同じエンドポイントに含まれていなければなりませんが、異なるスキーマを持つことができます。たとえば、変更テーブ
ルにはメタデータ ヘッダーが含まれます。
変更テーブルに適用された変更は、ソース データベースの対応するトランザクションで実行された変更とまったく同じように処理されます。したがって、
Transactional apply modeまたはBatch optimized apply モードを使用して[Preserve transaction consistency]オプション
を選択すると、変更は単一のトランザクションとして処理されます。例外は、エラーが発生し、Replicateが "1 つずつ" 適用モードに切り替わり、どの
変更操作がエラーの原因かを判断する場合です。
同じデータ列が適用され、両方とも、変更ヘッダー列を除いて、保存されている変更テーブルに追加されます。](https://image.slidesharecdn.com/16changetables-210902061501/85/Qlik-Replicate-Change-Tables-7-320.jpg)
Qlik Replicate - Change Tables(変更テーブル)のご説明
- 1. © 2019 QlikTech International AB. All rights reserved. Change Tables (変更テーブル)のご説明 クリックテック・ジャパン株式会社
- 2. 2 Change Tableの有効化 • ソース エンドポイント テーブルからターゲット エンドポイント内の対応するテーブルに変更をレプリケートするだけでなくターゲット エンドポイント内の対応する Change Tableに変更の履歴をレプリケートすることもできます。 • このプロセスは、ターゲットテーブルに変更を適用するときに同時に発生します。 • Qlik Replicateで、変更をターゲットのみにレプリケートするか、Change Tableに変更を保存するか、またはその両方にレプリケートするかを決定できます。
- 3. 3 Change Tableの内容 • Change Tableの名前は、レプリケートされるテーブルと同じですが、各テーブル名にデフォルトで__ctのサフィックスが付加されます。 • 変更テーブルには、元のテーブル列とヘッダー列が含まれます。ヘッダー列には、header__のプレフィックスが含まれています。 • [Task Settings]の[Store Changes Settings]より、プレフィックス・サフィックスは変更が可能です。 Qlik Replicate Control Table ソースシステム ターゲットシステム 変更内容を履歴として保存される ヘッダー列 ソースのテーブル列
- 4. 4 Change Tableのテーブル構造 列名 データ型 説明 [header__]change_seq varchar (35) タスクのすべての変更テーブルに共通する、単調に増加する変更シーケンサー。変更順序の形式は次のとおりです。 YYYYMMDhDHHmSShhxxxxxxxxxxxxxxxxxxxxxxxxx ・YYYY は 4 桁の年です (2012 など) ・MM は 2 桁の月です (範囲は 01 から 12 まで) ・HH は、その日の時間です (範囲は 00 から 23 まで) ・mmは時間の分です(範囲は00から59まで) ・SS は分単位の秒です (範囲は 00 から 59 まで) ・hh は 2 番目の 100 分の 1 です (範囲は 00 から 99 まで) ・xxxxxxxxxxxxxxxxxxxxxx は、19 桁の 0 個のプレフィックス付き変更番号 (タスクごとにグローバル) です。 通常、時間部分は、変更レコードを含むトランザクションのコミット時間を指します。Qlik Replicateにはシーケンス番号の単調性を維持するロジッ クが含まれているため、エンドポイント時間を変更または調整すると、同じタイムスタンプ内にあるように見えても変更ナンバーが増えているように見え る複数の変更が発生する可能性があります。 xxx…xxx は、通常、BEFORE-IMAGE レコードの場合は、一致する UPDATE レコードの変更番号と同じである (たとえば、BEFORE- IMAGE の変更番号が 1000 で、UPDATE の変更番号が 1001 の場合は、両方とも 1001) という点を除いて、データレコードからの内部変 更番号です。これにより、テーブルとそれ自体の間で、左のテーブルはある時点までスキャンするがoperation=before-imageをフィルタアウトし、 右側のテーブルはchange_operは「B」で同じchange_seqと結合できます。 [header__]change_oper varchar (1) 操作の種類。これは、次のいずれかです。 I: INSERT D: DELETE U: UPDATE B: Before Image
- 5. 5 Change Tableのテーブル構造 列名 データ型 説明 [header__] change_mask varbinary (128) 変更マスクは、変更テーブル内のどのデータ列が、ソーステーブルで変更された列に関連付けられているかを示します。 変更マスク内のビット位置は、変更テーブルの列序数に基づいています。つまり、ヘッダー列が 5 個ある場合、それらはビット 0 から 4 を占め、最初のデータ列は変 更マスクのビット 5 になります。 変更マスクは、変更マスクをリトルエンディアン順で表すバイナリ列 (バイト配列) です。 バイト 0 ビット 7 ビット6 ビット5 ビット4 ビット3 ビット2 ビット1 ビット0 バイト 1 ビット 15 ビット14 ビット13 ビット12 ビット11 ビット10 ビット9 ビット8 この例では、bit#Nは序数 N の変更テーブル列が、ソース 表内で変更された列に関連していることを示します。更新マスクが 11000 で、列序数が 3 の場合、 列は変更されませんでした。 以下に、ビットセマンティクスについて説明します。 ・INSERT レコードの場合、挿入されたすべての列に関連するビットセットがあります。 ・DELETE レコードの場合、主キー (または一意のインデックス) 列にのみ、関連するビットが設定されます。これにより、別のソースから主キー フィールドを見つける ことなく、アプリケーションが DELETE ステートメントを構築できます。 ・BEFORE-IMAGE レコードの場合、すべてのビットはクリア (変更マスクは空にすることができます) です。 ・UPDATE レコードの場合、BEFORE-IMAGE と UPDATE の間で値が変更された各列には、関連するビットセットが設定されます。 スペースと処理の効率を高める場合、変更マスクに格納されている実際のバイト数は NULL で切り捨てることができます。つまり、末尾のゼロを格納する必要はあり ません。処理ロジックでは、この点を考慮する必要があります。 [header__] stream_position varchar (128) ソース CDC ストリームの位置。 [header__] operation varchar (12) 変更レコードに関連付けられている操作。次のいずれかの値を指定できます。 ・INSERT ・UPDATE ・DELETE ・BEFOREIMAGE [header__] transaction_id varchar (32) 変更レコードが属するトランザクションの ID。 値は 128 ビット トランザクション ID の 16 進数の文字列です。 [header__] timestamp timestamp 元の変更 UTC タイムスタンプ (値は概算値である場合があります)。 ※ PostgreSQL ソースでは、タイムスタンプはコミットが発生した後にのみ認識されます。したがって、変更がソース表にコミットされるまで、デフォルトの日付が表示さ れます (例: 1970-01-01)。 [header__] partition_name string データのパーティション分割の変更が有効な場合にターゲットに作成されたパーティションの名前。パーティション名は、パーティションの開始時刻と終了時刻で構成さ れます。 例: 20170313T123000_20170313T170000
- 6. 6 Truncateの処理について • TRUNCATE 操作では、変更テーブルは切り捨てられません。代わりに、 operation=TRUNCATEの追加のレコードがテーブルに追加されます。これは、ま た、Hadoop ターゲットにレプリケートするときに、変更テーブルに対応する HDFS ファイルが削除されないことを意味します。 • 実際のターゲット表に関しては、 Apply ChangesとStore Changesの両方のレプリケーション・オプションが有効になっている場合、ターゲット表は切り捨てら れます。これは、Hadoop ターゲットにレプリケートする場合、変更テーブルに対応する HDFS ファイルも削除されることを意味します。 • TRUNCATE 操作を変更テーブルとターゲット テーブルの両方に適用するには (TRUNCATE をサポートするソースの場合)、[Task Settings]の[Store Changes Settings]タブで： [DDL options]ドロップダウン リストから [Apply to Change Table] (既定) が選択されていることを確認します。 [When source table is truncated] ドロップダウン リストから [TRUNCATE target table] (既定) が選択されていることを確認します。
- 7. 7 注意事項 • ソース データを変更しないソースに適用されたUPDATE は、ターゲットに適用されますが、対応するChange Tableには適用されません。たとえば、ソースの 列 A の UPDATE 操作で、10 から 1 より大きい値をすべて変更し、列 A のレコードの 1 つが既に 1 である場合、そのレコードの UPDATE はChange Tableに書き込まれません。 • ソース テーブルから選択した列に加えて、Change Tableには、操作、トランザクション、タイムスタンプなど、行が表す変更に関する詳細情報を提供する特 別なヘッダー列も含まれています。これにより、SQL クエリ言語を使用して、不正検出、傾向分析、ビジネス プロセスのトリガー、ディザスタ リカバリなど、さま ざまな変更イベントの分析を実行できます。 • 変更テーブルを使用する場合は、変更テーブルに変更を保存するか、ターゲット テーブルに変更を適用するか、または両方の変更を保存して適用するかを 決定できます。これは、レプリケーションタスクを定義するときに決定します。この設定の詳細については、「変更の設定を保存する」を参照してください。 • 変更を適用および保存する場合、以下の条件を満たします。 ターゲットテーブルと変更テーブルは、同じエンドポイントに含まれていなければなりませんが、異なるスキーマを持つことができます。たとえば、変更テーブ ルにはメタデータ ヘッダーが含まれます。 変更テーブルに適用された変更は、ソース データベースの対応するトランザクションで実行された変更とまったく同じように処理されます。したがって、 Transactional apply modeまたはBatch optimized apply モードを使用して[Preserve transaction consistency]オプション を選択すると、変更は単一のトランザクションとして処理されます。例外は、エラーが発生し、Replicateが "1 つずつ" 適用モードに切り替わり、どの 変更操作がエラーの原因かを判断する場合です。 同じデータ列が適用され、両方とも、変更ヘッダー列を除いて、保存されている変更テーブルに追加されます。