注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

変更データキャプチャ（CDC）

変更データキャプチャ（CDC）は、リレーショナルデータベースからリアルタイムで更新情報を他のコンシューマにストリームするためによく使われるエンタープライズデータインテグレーションパターンです。

Foundry は、変更データキャプチャフィードを生成するシステムからのデータの同期、処理、および保存をサポートしています。プラットフォーム全体のコンポーネント、データコネクタ、ストリーム、パイプライン、および Foundry オントロジーはすべて、基礎となるデータのスキーマに設定されたメタデータを使用して、この変更ログデータをネイティブに処理できます。

変更ログメタデータには、以下の属性がデータに必要です。

1つ以上の主キー行
- 変更ログデータには、主キー行が同じ多くのエントリが含まれます。これは、変更ログがその主キーを持つレコードで発生したすべての個々の変更を伝えることを目的としているためです。変更データキャプチャは、編集されているデータに対して特に有用であり、不変または追記のみのデータフィードではありません。
1つ以上の順序付け行
- 順序付け行は数値であり、主キーのセットを持つレコードの変更の相対的な順序を決定するために使用されます。順序付け行は、長い型のタイムスタンプとして表されることがよくありますが、常にそうではありません。最大値は最も新しいものとして理解され、順序付け行がタイムスタンプでなくても同様です。
削除行
- 削除行は、主キーのセットを持つレコードが削除されたかどうかを判断するために使用されます。これは、レコードが削除された場合は真、それ以外の場合は偽である必要があるブール値です。

この変更ログメタデータは、ソースシステム内のデータの現在のビューに変更ログを解決するための解決戦略を指定するために使用されます。変更データキャプチャの解決戦略は以下のように機能します。

主キー行に基づいてデータをグループ化します。
順序付け行の最大値を持つエントリを見つけます。
このエントリが削除行で値 true を持っている場合、それを削除します。

これらのステップの後、変更ログは、上流のソースシステムで生成された変更ログと同じビューにまとめられるはずです。変更ログメタデータと解決戦略は、以下で説明するように、さまざまな Palantir コンポーネントで異なる方法で使用されます。

Data Connection での変更データキャプチャ

Data Connection で利用可能なソースは、変更ログメタデータが適用されたストリームとしてデータを同期するシステムからのデータ同期をサポートしている場合があります。変更ログデータを同期する機能をソースが実装できるかどうかは、ソースシステムが必要な属性（主キー行、順序付け行、および削除行）を持つログデータを生成できるかどうかに依存します。

MySQL、PostgreSQL、Oracle、Db2、および SQL Server など、多くの一般的なデータベースは、CDC 変更ログデータを生成できます。Foundry のこれらのシステム用のデータコネクタは、これらの変更ログを直接同期できるかどうかが異なります。コネクタが現在 CDC 同期をサポートしていなくても、Kafka やその他のストリーミングミドルウェアを介してデータを同期し、Foundry でデータが到着したら変更ログとして使用できます。

Data Connection の以下のソースタイプでは、現在 CDC 同期がサポートされています。

Microsoft SQL Server
PostgreSQL

さらに、次のシステムについては、実験的なコネクタを使用して CDC 同期が利用可能です。このコネクタを使用したい場合は、Palantir の担当者にお問い合わせください。

Oracle
MySQL

Kafka、Kinesis、Amazon SQS、ストリームを使ったプッシュベースのインテグレーションなど、他のソースから変更ログ形式のデータが利用可能な場合は、Pipeline Builder の key-by ボードを使用して、変更ログメタデータを手動で設定する方法を読んでください。

外部データベースで変更データキャプチャを有効にする

サポートされているソースタイプから変更ログフィードを同期するには、関連するテーブルや、場合によってはデータベース全体に正しい設定を有効にする必要があります。

たとえば、Microsoft SQL Server で変更データキャプチャを有効にするには、データベースで CDC を有効にするコマンドを実行する必要があります。

USE <データベース>
GO
EXEC sys.sp_cdc_enable_db -- Change Data Capture (CDC) を有効にする
GO

次に、変更ログを記録するべき各テーブルで別のコマンドを実行します：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'<schema>' -- スキーマ
  , @source_name = N'<table_name>' -- テーブル名
  , @role_name = NULL -- 役割名
  , @capture_instance = NULL -- キャプチャインスタンス
  , @supports_net_changes = 0 -- ネット変更のサポート (0 = サポートしない, 1 = サポートする)
  , @filegroup_name = N'PRIMARY'; -- ファイルグループ名
GO

以上の例は、ソースシステムが変更ログデータを生成するために何が必要かについての高レベルの説明を提供しています。特定のシステムの変更データキャプチャログを有効にする方法についての詳細は、そのシステムが提供するドキュメンテーションを参照してください。

変更データキャプチャ用のソース接続を設定する

これで、Data Connector でソースを設定し、そのソースから変更ログをキャプチャするシステムに接続することができます。例を続けると、以下のように Microsoft SQL Server コネクタを使用して接続を設定します：

CDC データの新しいソースページ in Data Connector.

変更データキャプチャの同期を作成する

ソースの概要ページには、CDC Syncs の空のテーブルが表示されます。

例の Microsoft SQL Server ソースの概要ページにある CDC Syncs セクション、赤い四角で囲まれています。

新しい変更データキャプチャの同期を追加するために Create CDC sync を選択します。同期させたいテーブルを指定すると、以下の情報がコネクタによって自動的に導き出されます：

出力ストリーミングデータセットのスキーマ。
変更ログのメタデータ、主キーの行、順序付けされた行、削除行を含む。

新しい同期設定ページ、テーブル、スキーマ、主キーを編集するセクションがあります。

他のストリームと同様に、作成時に予想されるスループットを指定する必要があります。スループットは同期作成後に変更することはできませんので、変更ログデータの予想されるボリュームをサポートするようにストリームが設定されていることを確認してください。デフォルトのボリュームは 5MB/s で、これは通常、ほとんどの変更データキャプチャワークフローには十分なものです。リレーショナルデータベースの変更は、しばしば「人間のスケール」で生成されるため、変更のボリュームと頻度は「マシンスケール」のセンサーや機器データが可能なものよりもはるかに小さいです。

同期設定を保存して、指定された出力ロケーションに新しいストリームを作成します。

現在、CDC ジョブは任意の変更後に手動で (再)開始する必要があります。すべての CDC 同期は単一の多出力抽出ジョブとして実行されるため、同じソースからの既存の CDC ストリームはフィードが追加または削除されるたびに一時的に停止する必要があります。ストリーミング同期ジョブが停止している間に変更されたデータは、ストリームが適切に追いつくようにします。

出力ストリームを開始すると、変更ログデータがフローを開始し、出力ストリーミングデータセットのライブビューに表示されます。

ストリームの変更データキャプチャ

変更ログメタデータを持つストリームは、データへの2つのビューを表示します：

変更ログエントリの完全に展開されたリストを表示する ライブビュー。
データが解決戦略に従って解決され、現在の最新のビューに折りたたまれた アーカイブビュー。

ライブビューとアーカイブビューの間を切り替えるためのドロップダウンメニュー、ページの左上隅に位置しています。

スキーマは、詳細ビューで主キー解決戦略として変更ログメタデータを表示します。

解決戦略付きのストリーミング変更データキャプチャスキーマ。

ストリームは現在、解決を行うために順序列を使用しています。つまり、データは提供された順序列に従ってアーカイブで解決されます、たとえデータが順不同で受信されたとしても。この動作は、Foundry のオントロジーの変更ログデータの動作とは異なり、オントロジーはオブジェクトタイプをバックアップするために使用されるストリームに到着した順序に基づいてデータをインデックス化します。

Pipeline Builder の変更データキャプチャ

Pipeline Builder のストリーミング変換は、変更ログデータを処理するために使用することができます。メタデータ列が変換によって変更されない限り、変更ログメタデータは任意の出力に自動的に伝播します。

入力ストリームに変更ログメタデータがない場合、またはメタデータ列がパイプラインによって変換された場合、"キー指定" ボードを使用してデータを "キー指定" し、出力に変更ログメタデータを適用することができます。

Pipeline Builder の Key By ボード。

オントロジーでの変更データキャプチャ

オントロジーは、変更ログメタデータを使用して、ストリーミングデータソースによってバックアップされた Object Storage V2 のオブジェクトタイプにデータをインデックス化します。ストリームに到着するデータは解決され、オントロジーをクエリするとき（たとえば、Workshop モジュールに表示するため）に利用可能な最新の現在のビューにインデックス化されます。

保持期間が変更ログメタデータを持つデータソースに設定されている場合、保持ウィンドウの時間内に更新が行われないレコードはオントロジーから消えます。

オントロジーは現在、変更ログメタデータで指定された順序列を無視しています。代わりに、Object Storage V2 はデータが基となるデータソースに到着した順序に基づいてデータをインデックス化します。具体的には、特定の主キーについて、順序値 2 のログエントリが t1 で data_column=foo として到着し、その後に順序値 1 の別のログエントリが t2 で data_column=bar として到着すると、レコードは data_column=bar として表示されます。これは、ソースシステムでは最新の値が data_column=foo であるにもかかわらずです。このことは、データが順不同で到着する場合、オントロジーがソースシステムのデータを誤って反映する可能性があることを意味します。

Palantir で使用されるコネクタはデータを順番に配信することが保証されており、Foundry のストリームは順序を維持するため、このオントロジーの動作はカスタムの設定や古いストリーミング変更ログが手動でバックフィルされて同期前に再オーダリングされない場合にのみ影響を及ぼす可能性があります。このような状況に遭遇した場合、オントロジーに同期する前に Pipeline Builder で変換を適用してデータを再オーダリングすることをお勧めします。

Workshop の変更データキャプチャ

Workshop は自動更新をサポートしており、オントロジーで利用可能になった頻繁に更新されるデータをすぐに表示することができます。自動更新は CDC と互換性があり、変更データキャプチャでストリーミングされた任意のデータが Workshop アプリケーションで直ちに利用可能であることを確認するために使用することができます。

自動更新は、Workshop モジュールが開いている間に頻繁に更新されることが予想される任意のデータに利用可能です。データが自動更新を使用するためには、基となるデータソースに変更ログメタデータを持つ必要はありません。

変更データキャプチャを使用する際の注意点

CDC ワークフローを使用する前に、バックフィル、停電、その他の既知の制限に関する以下の情報を確認することをお勧めします。

バックフィル

すべての変更ログ同期は、排他的に「前進」の基準で処理されます。自動バックフィルは行われません。

しばしば、変更ログの完全なバックフィルは不可能であり、ほとんどのシステムはデフォルトでは CDC を有効にしていません。変更ログが有効になっていても、ほとんどのシステムには保持期間があり、その期間が過ぎると変更ログは永久に削除され、回復することはできません。

完全なバックフィルが必要な場合、以下の手順をお勧めします：

"前進" の基準で CDC ストリームを設定します。
バッチ同期を実行して所望の履歴データを抽出します。
履歴バッチデータを各主キーの「作成」レコードのストリームに変換し、そのストリームを CDC ストリームにマージします。

バックフィルはデータが順不同になる可能性があり、オントロジーに同期するためのデータの準備には手動でストリームを再オーダリングまたは再再生する必要があるかもしれません。

停電

CDC ワークフローを使用しているときに以下の停電を経験する可能性があります：

ソースデータベースと Foundry エージェント間のネットワーク接続
Foundry エージェントホストと Foundry 間のネットワーク接続
Foundry の停電
データベースの停電
エージェントの停電

データベースのレプリケーションログと変更ログの保持ウィンドウが最大予想停電よりも長く設定されている場合、停電は適切に対処されます。

例えば、Foundry への接続が数時間ダウンした場合、Microsoft SQL Server のログ保持ウィンドウが1日に設定されていると、データベースは変更ログエントリの記録を続けます。Foundry が再度オンラインになり、Microsoft SQL Server に再接続されると、Foundry はうまく追いつきます。変更ログエントリのキューがクリアされるまで新しいデータはフローしないため、変更が再びリアルタイムに近い速度で Palantir にフローするまでには若干の遅延が生じる可能性があります。

非変更ログソースからの変更ログ形状のデータを使用する

データは変更ログとして取り込まれる必要はありません。Palantir の任意のストリーミングデータは、変更ログメタデータで「キー指定」され、オントロジーに同期した後のワークフローで CDC データとして使用することができます。

これは、例えば、ストリームプロキシを使用したプッシュベースの取り込みが、手動で変更ログ形状のレコードをストリームにプッシュするために使用できることを意味します。

同様に、変更ログデータが Kafka トピックに存在する場合、それは標準の（非 CDC）同期を使用して取り込むことができます。その後、Pipeline Builder を使用して「キー指定」し、オントロジーおよびそれ以降で使用することができます。

変更ログメタデータを削除する

場合によっては、変更ログメタデータを削除することが有用かもしれません。たとえば、変更ログによってキャプチャされたプロセスフローを分析するために、メタデータを削除することを希望するかもしれません。変更ログメタデータを削除するには、以下のいずれかの方法を使用します：

メタデータ列に対して任意の変換を実行する
ストリーミングデータセットのスキーマから解決戦略を手動で削除する