ETL プロセスは「抽出、変換、読み込み」の略で、ソースシステムから未加工データを抽出し、必要な構造に変換してから、通常はデータ ウェアハウスである宛先システムに読み込むプロセスです。ETL は、データが整理され、クリーンな状態になり、分析やアプリケーションでのダウンストリーム使用の準備が整うようにするのに役立ちます。

従来、ETL は大規模なスケジュールされたバッチで実行され、多くの場合、夜間に行われます。つまり、ターゲット システムのデータは、最新のバッチ実行時のデータと同じ鮮度になります。

主な違いは、CDC がデータを抽出する方法です。CDC では、データセットをバッチで抽出するのではなく、変更が発生したときにキャプチャするため、定期的なバッチ処理に依存するのではなく、常に最新のデータをクエリできます。これにより、変化に迅速に対応し、より正確な分析情報を得ることができます。

変更データ キャプチャは主に、ソースシステムへの負荷を最小限に抑えるために、ソース データベースからすべての増分変更を効率的に抽出することに重点を置いたプロセスです。多くの場合、ほぼリアルタイムで抽出されます。

一方、変化が緩やかなディメンション（SCD）は、ターゲットのデータ ウェアハウスまたは分析システムに適用されるデータ モデリング手法であり、ディメンション データ（顧客レコードや商品属性など）の過去の状態を時間の経過とともに保存および管理する方法に重点を置いています。

CDC は変更の効率的なデータ転送のためのツールですが、これらの変更は通常、特定の SCD 戦略を使用して適用され、移行先システム内で完全かつ正確な履歴が維持されます。

CDC は、データの継続性の確保からリアルタイム分析や AI の強化まで、幅広い重要なユースケースを実現できます。

• レプリケーション: リアルタイムの変更をキャプチャすることで、セカンダリ データベースまたはバックアップがプライマリ システムと一貫性を保ちます。これは、障害復旧と高可用性のアーキテクチャにとって非常に重要です。
• 移行: 進行中の変更を追跡し、ライブ マイグレーション中であっても、移行先システムにソースが正確に反映されるようにすることで、データベースの移行が簡素化されます。
• リアルタイム分析: ライブデータを分析システムにフィードすることで、CDC はトレンドや変化が発生したときに対応し、最新の分析情報を提供します。
• AI トレーニング用のデータ: CDC は最新のデータを提供し、AI モデルと ML モデルが正確で関連性の高い情報でトレーニングできるようにします。これにより、予測と意思決定が改善されます。
• データクラウドの構築: CDC は、統合されたデータクラウドを作成するために不可欠なサービスです。さまざまなサイロ化されたソース（トランザクション データベースや SaaS アプリケーションなど）からのリアルタイムの変更を、中央の分析プラットフォームにストリーミングし、戻します。これにより、データの障壁が取り除かれ、信頼できる唯一の情報源が作成されます。

データベースは、すべてのデータベースに共通するコア コンポーネントであるトランザクション ログがあるため、変更データ キャプチャの最も一般的で信頼性の高いソースです。このログは、すべての変更の不変の順序付きレコードであり、データベースのパフォーマンスに影響を与えることなく、データ変更を正確かつ効率的にキャプチャするための完璧な基盤となります。主なコンセプトについて詳しく見ていきましょう。

実際のデータベース テーブルにデータが書き込まれる前に、変更（挿入、更新、削除）がトランザクション ログに記録されます。最新の CDC ツールは、このログを利用して、非侵入的に変更をキャプチャします。これはデータベース レプリケーション技術の中核をなす部分であり、コンセプトは普遍的ですが、このログの名前は一般的なデータベースによって異なります。代表的な例:

• PostgreSQL: 先行書き込みログ（WAL）
• Oracle: redo ログ
• SQL Server: トランザクション ログ
• MySQL: バイナリログ（Binlog）

大規模な既存のデータベースの場合、ネットワーク パフォーマンスやその他の制約により、トランザクション ログから履歴全体を読み取ることは現実的ではない可能性があります。実際の一般的なパターンは、最初に一括読み込みを実行し、次に CDC を使用して同期することです。このプロセスには以下の操作が含まれます。

1. 特定の時点におけるデータベースの一貫性のあるスナップショットまたはバックアップの取得。
2. その大きなスナップショットを宛先システムに読み込む。
3. スナップショットが取得された正確なログ位置から CDC ストリームを開始する。

この「スナップショットとキャッチアップ」方式により、宛先には履歴データが完全にシードされ、その後はすべてのライブ変更と完全に同期されます。Google Cloud の Datastream や Database Migration Service などのマネージド サービスは、このようにしてシームレスで信頼性の高いバックフィルを実行します。

このプロセスを確実に管理するために、CDC はトランザクション ログ内の一意の識別子（通常はログ シーケンス番号（LSN）と呼ばれる）に依存しています。これらの数値は、変更ストリームの正確なブックマークとして機能します。以下の点で重要です。

• ポジショニング: ストリームの開始または停止位置をログ内で正確に把握する
• 復元: CDC プロセスが失敗した場合、最後に正常に処理された LSN から再開できるため、データの損失や重複なしに、すべての変更が正確に 1 回だけキャプチャされることが保証されます。

トランザクション ログ、初期スナップショット、ログ シーケンス番号というこれらのメカニズムが連携して機能することで、データベース CDC の効率性と信頼性が高まります。

CDC と重複または補完するテクノロジーは複数あり、データ変更の管理とリアルタイム処理の実現にさまざまなアプローチを提供しています。CDC と他の主要なアプローチの比較:

HTAP は、トランザクション（OLTP）ワークロードと分析（OLAP）ワークロードを単一のシステムに統合し、データに対する即時の分析を提供します。HTAP は自己完結型の環境で統合分析を行うのに適していますが、組織全体に存在する多様で分散されたデータソースとの同期には苦労する可能性があります。一方、CDC は複数のシステム間でデータの整合性を維持し、分散ワークフローを可能にするのに優れています。

フェデレーション クエリ（および「外部テーブル」と呼ばれる同様のアプローチ）を使用すると、データ ウェアハウスやクエリエンジンは、クエリが実行された瞬間に、トランザクション データベースなどの外部ソースシステムから直接データを読み取ることができます。このアプローチでは、データをコピーまたは移動する必要がなく、情報が保存されている場所でライブアクセスできます。

この方法は、レプリケーション パイプラインのセットアップなしで即座にアクセスできるため、アドホック分析や一時的なクエリに最適です。ただし、頻繁に使用されるクエリやパフォーマンスが重要なクエリの場合、クエリごとにソースの運用システムに直接負荷がかかるため、非効率的になる可能性があります。CDC は、最適化された分析のために変更のストリームを宛先にプロアクティブにプッシュしますが、フェデレーションはオンデマンドでデータをプルするため、高頻度のワークロードには適さない場合があります。

Kafka は、高スループットのデータ ストリーミングと処理のために設計されたオープンソース プラットフォームです。Kafka は大規模なデータフローを効率的に管理しますが、CDC を置き換えるのではなく、CDC を補完します。CDC は、データベースの正確な変更をリアルタイムでキャプチャすることに重点を置いていますが、Kafka は、ウェブサイトのクリック、IoT センサーの読み取り、ショッピング カートへのアイテムの追加など、より広範なイベントデータをストリーミングします。これらのテクノロジーを組み合わせることで、リアルタイム ワークフローのための強力な組み合わせが実現します。

CDC はノーコード アプローチを使用してデータを複製しますが、アプリケーション レイヤで接続する統合テクノロジーは、ローコード アプローチを使用してシステムと SaaS プラットフォームを接続します。プラットフォーム間を移動する際にデータを変換する機能が必要な場合は、Google Cloud の Application Integration などのアプリケーション レベルの統合プロダクトが適しています。