はじめに
Salesforce などの業務システムから Snowflake などのデータ基盤へデータを連携する際には、
「更新や削除はどのように反映されるのか？」「削除データをログとして残したい場合はどうするのか？」
といった検討事項が出てきます。
Informatica の CDIR（Cloud Data Ingestion and Replication）では、
ソースシステムで発生したデータ変更をターゲットに反映する際の挙動を、設定一つで簡単に制御できます。
本記事では、CDIRの重要設定であるApply Modeにフォーカスし、
SalesforceからSnowflakeへのデータロードを例に、挙動の違いをデモ形式で解説します。
CDIRのApply Modeとは
CDIR(Cloud Data Ingestion and Replication)は、InformaticaがIDMC(Intelligent Data Management Cloud)上で提供する、大量データロードのためのサービスです。
大規模かつ低レイテンシなデータの移動を、数ステップのウィザード形式で簡単に実現します。
今回の記事では、CDIRの中でも「Apply Mode」に焦点をあてます。
Apply Modeとは、ソースで発生したデータの変更(INSERT, UPDATE, DELETE)を、ターゲットにどのように反映するかを決めるための設定です。
Standard, Soft Deletes, Auditの3つから、データ連携要件にあったものを選択できます。
それぞれの違いは以下の表のとおりです。
通常のデータ基盤へのデータ同期であればStandardを、
誤削除への対応や削除分析が必要な場合はSoft Deletesを、
監査証跡や変更分析ではAuditを、といったようにユースケースに合わせた選択ができます。
2026年3月時点でAuditはSAPのみ対応している旨がドキュメントに記載されていますが、
Salesforceでも他2つの設定と異なる動作が確認できるため、後ほどご紹介します。
DEMO
では、実際の設定と設定値ごとの動作の違いを見ていきましょう。
検証内容
SalesforceのContact(取引先責任者)レコードをSnowflakeに連携する3つのApplication取り込みタスクを作成し、
Salesforceでのデータ更新がどのようにSnowflakeに反映されるかを確認します。
設定
Apply Modeの異なる3つのアプリケーション取り込みタスクを作成しました。
Apply Mode及びロード先であるSnowflakeのスキーマ/ステージ以外の設定は共通です。
それぞれの設定値
-
Standard
-
Soft Deletes
-
Audit
実行
デプロイ
3つのアプリケーション取り込みタスクをデプロイします。
デプロイ後、Snowflakeにターゲットテーブルが自動生成されます。
Salesforceの項目をIDMCが自動でテーブル化するので、DDLを書く必要はありません。Salesforce上の複数オブジェクトを一括でSnowflakeに取り込みたい場合には作業時間を大幅に削減できます。
この時点で、StandardとSoft Deletes/Auditで、カラム数の違いがみられます。
- Standard：65カラム
- Soft Deletes/Audit：66カラム
これは、Soft Deletes/Auditのテーブルには、フラグ用の「INFA_OPERATION_TYPE」というカラムが追加されているためです。
起動
アプリケーション取り込みタスクを起動します。
ステージと差分管理用のテーブルが作成されます。
検証
では、SalesforceのContact(取引先責任者)にレコードを登録していきます。
今回は、3つの検証を行い、Apply Modeの違いを明らかにします。
レコード登録
2件のContact(取引先責任者)を新規登録します。
各テーブルに2件のレコードが追加されました。
-
Standard
-
Soft Deletes
-
Audit
AuditのINFA_OPERATION_TYPEカラムには、「I」が追加されています。
なお、このタイミングでStandard/Soft Deletesのスキーマに、Contact_LOGというテーブルが生成されました。
テーブル定義からは、各項目ごとに新旧の値を保持するテーブルと思われます。
レコード更新
Contact(取引先責任者)：TEST01をTEST03に変更します。
Standard/Soft Deletesでは、Salesforceの変更を反映し、値が直接更新されています。
-
Standard
-
Soft Deletes
一方Auditでは、TEST01レコードを残したまま、INFA_OPERATION_TYPEカラムが「E」であるTEST03のレコードが新規追加されました。
- Audit
レコード削除
Contact(取引先責任者)：TEST02を削除します。
Standardでは、TEST02のレコードが削除されています。(Snowflake上で物理削除)
- Standard
Soft Deletesでは、TEST02のレコードが残ったまま、INFA_OPERATION_TYPEカラムが「D」に更新されています。(Snowflake上で論理削除)
- Soft Deletes
Auditでは、既存のTEST02レコードを残したまま、INFA_OPERATION_TYPEカラムが「D」であるTEST02のレコードが新規追加されました。
- Audit
まとめ
以下の表では、Apply Modeごとに、ソースのレコード変更がどのようにターゲットへ適用されるのかを整理しています。
| Apply Mode | 登録 | 更新 | 削除 |
|---|---|---|---|
| Standard | 新規レコード登録 | レコードを直接更新 | レコードを直接削除 |
| Soft Deletes | 新規レコード登録 | レコードを直接更新 | レコードのフラグを更新(Flag：D) |
| Audit | 新規レコード登録(Flag：I) | 新規レコード登録(Flag：E) | 新規レコード登録(Flag：D) |
INFA_OPERATION_TYPEの値はそれぞれ「I=Insert / E=Edit / D=Delete」に対応していると思われます。
おわりに
今回は、CDIR（Cloud Data Ingestion and Replication）の Apply Mode（Standard / Soft Deletes / Audit） がどのように動作するのかを見ていきました。
実際に比較してみると、
- Standard：常に最新の状態が反映されるシンプルな同期
- Soft Deletes：削除を論理削除として扱い、履歴を残せる
- Audit：すべての変更を蓄積し、変更履歴を取得できる
というように、明確に使い分けるべきということがわかります。
要件に応じて適切な Apply Mode を選択することで、データ基盤の構築や運用を最適化できます。
ぜひ、CDIR 及び Apply Mode を活用し、データ基盤のレベルアップに役立ててみてください。
参考