変更データキャプチャとは何ですか?

チェンジデータキャプチャ（CDC）とは？

チェンジデータキャプチャ（CDC）は、挿入、更新、削除など、データセットに加えられた行レベルの変更を識別して記録するデータ統合技術です。テーブル全体を繰り返し抽出する代わりに、CDCは変更されたレコードのみをキャプチャし、ダウンストリームシステムに適用します。この増分アプローチは、完全な更新に伴うコストや遅延を発生させることなく、アナリティクスプラットフォーム、業務アプリケーション、機械学習パイプラインを最新の情報に同期させます。

従来のバッチパイプラインは、フルスキャンを実行したり、大規模なデータセットを再読み込みしたりする定期的な取り込みジョブに依存しています。これらのワークフローはシンプルで費用対効果が高いですが、レイテンシーを増加させ、変更されていないデータを繰り返し処理するため、大規模になると非効率になります。CDCは、トランザクションログ、トリガー、タイムスタンプ、ネイティブな変更フィードなどのメカニズムを通じて変更を継続的に検出することでこれらの制限に対処し、データレイクハウス アーキテクチャプラットフォームが、より新しいデータで、かつ、コンピュートのオーバーヘッドを削減して運用できるようにします。

ETL プロセスにおける CDC の仕組み

ETLパイプラインにおいて、CDCは前回のロード以降に変更されたデータのみを抽出する仕組みです。スケジュールされたテーブル全体の抽出を実行するのではなく、CDCはソースデータベースで発生した新規または変更された行をキャプチャします。ログ、トリガー、またはスナップショットの差分から収集された変更イベントのみを処理することで、抽出、変換、ロード（ETL）プロセスを通じてデータセットの継続的な進化を表す差分ストリームを形成できます。

イベントがパイプラインに入ると、ETLプロセスが引き継ぎ、データセット全体ではなく、変更された各レコードに対してクリーニング、エンリッチメント、または検証が実行されます。最終的な読み込みステップでは、これらの増分更新のみをターゲットテーブルまたはリポジトリに適用するため、軽量で継続的な取り込みが実現します。このアプローチにより、I/Oが削減され、ダウンストリームシステムがソースと密接に連携し続けることができます。

CDCは、継続的な抽出、変換、読み込みを可能にすることで、バッチ指向のワークフローだったETLをリアルタイムパイプラインへと最新化します。ストリーミング分析 により、アナリティクス、ダッシュボード、 機械学習パイプライン は、長時間実行されるジョブやメンテナンスウィンドウに頼ることなく、常に最新のデータを反映します。

最新のデータアーキテクチャにおいてCDCが重要な理由

現代のデータエコシステムは、オペレーショナルシステム、分析プラットフォーム、機械学習パイプラインの間を流れるタイムリーで正確な情報に依存しています。e コマース、銀行、物流などの環境では、購入、プロファイルの更新、在庫調整といったアクションを通じて新しいデータが作成されるため、データは絶えず変化します。CDC がないと、それらの更新は次のバッチ ETL ジョブまでソースシステム内に分離されたままになり、その結果ダッシュボード、レポート、モデルは古いデータセットに依存することになります。

CDCはリアルタイム同期を可能にすることでこの問題を解決し、接続されているすべてのシステムを同じ単一の信頼できる情報源と整合させます。

このプロセスはゼロダウンタイムでの移行もサポートしており、これはクラウドの最新化において重要な要素です。書き込みを凍結したり、リスクの高い切り替えを行ったりする代わりに、CDCは新旧システム間の変更を継続的に複製し、シームレスな移行を可能にします。

CDCと従来のETL：主な違い

従来のETLパイプラインは多くの分析ワークロードの中心であり続けていますが、その動作はCDCとは大きく異なります。ETLは通常、1時間ごと、夜間、またはその他の固定間隔など、スケジュールされたバッチでデータを移動します。各ランでは、ソースシステムからデータを抽出し、変換して、Databricks Data Engineeringを利用したダウンストリームのプラットフォームに再読み込みします。このモデルは予測可能ですが、遅延が発生する可能性があり、レコードのごく一部しか変更されていない場合でも、システムはテーブル全体や大規模なパーティションをスキャンする必要があります。

変更が発生したときにキャプチャすることで、CDCはソースシステムでデータが変更された時点と、アナリティクスや運用のために利用可能になる時点との間のギャップを解消します。

CDCとETLがデータ移動をどのように処理するかを比較すると、CDCの重要性はさらに明確になります。従来のETLはテーブル全体のスキャンや一括再ロードに依存することが多いのに対し、CDCは差分変更のみを送信します。これにより、データパイプラインにおけるコンピュートのオーバーヘッドが大幅に削減され、全体的な効率が向上します。

バッチ ETL は、一貫性のある読み取りを保証するためにメンテナンスウィンドウにも依存します。CDC は、通常のデータベースアクティビティを中断することなく変更をキャプチャすることで、この依存関係を排除します。このため CDC は、リアルタイムダッシュボード、レコメンデーションエンジン、オペレーショナルアナリティクスなど、非常に最新のデータを必要とするシステムに最適です。しかし、ETL は大規模な履歴のバックフィルや定期的な変換に依然として適しており、CDC と ETL は共に、最新のアーキテクチャにおいて補完的な取り込み戦略を形成できます。

最新のデータエコシステムにおけるCDC

CDCにより、データウェアハウス、レイクハウス、ストリーミングプラットフォーム間で、データを継続的かつ確実に流すことができます。すべての変更が発生した順序でキャプチャされるため、ダッシュボードとアプリケーションはオペレーショナルシステムと同期が維持されます。また、CDCはデータがどのように変化したかの明確な記録を保持することで、監査可能性とガバナンスをサポートします。これは、金融やヘルスケアなどの規制の厳しい業界にとって、特にデータウェアハウスからlakehouseへの移行戦略を実装する際の重要な要件です。

CDC の実装方法: 比較と選択

CDC vs. SCD：その関係性を理解する

CDCとSCDは、データパイプライン内でそれぞれ異なる役割を果たします。CDCはソースシステムから行レベルの変更を検出・抽出する役割を担い、SCDはそれらの変更をターゲットシステムにどのように保存するかを決定します。

顧客が住所を更新するなど、CDC が変更を識別すると、SCD タイプ 1 は履歴値が不要なため既存のレコードを上書きします。一方、SCD タイプ 2 は、完全な履歴を保持するために、開始と終了のタイムスタンプを持つ新しいバージョン管理されたレコードを作成します。言い換えれば、CDC は増分変更イベントを提供し、SCD はそれらのイベントが現在の状態のスナップショットまたは履歴のタイムラインとしてどのように表現されるかを形成するルールを適用します。

組織は、システムのパフォーマンス、複雑さ、ビジネスニーズに応じて、複数の方法で CDC を実装できます。組織が活用する最も一般的な手法は、それぞれ異なる方法で変更を検出します。

ログベースCDC：このプロセスは、MySQLのbinlog、PostgreSQLのWAL、Oracleのredoログなどのデータベースのトランザクションログから直接読み取ります。ライブテーブルにクエリを実行するのではなくデータベースレベルで動作するため、本番運用システムへの影響を最小限に抑えながら、すべての挿入、更新、削除をリアルタイムでキャプチャします。DebeziumのようなフレームワークやApache Kafkaとの連携は、この方法を使用して、信頼性の高い大容量のデータストリームを配信します。

トリガーベースのCDC：この方法では、データベーストリガーまたはストアドプロシージャを使用して、シャドウテーブルに変更を記録します。軽微な書き込みオーバーヘッドは発生するものの、正確な制御を提供し、カスタムロジックや変換を含めることができるため、規制対象のワークロードに有用です。

クエリーベースのCDC：この方法は、タイムスタンプまたはバージョン番号を使用して変更されたレコードを特定します。これはシンプルで、小規模またはレガシーなシステムではうまく機能しますが、削除を見逃す可能性があり、大規模になると効率が低下する場合があります。

システムによって変更がキャプチャされると、緩やかに変化するディメンション（SCD）パターンが、それらをどのように適用するかを定義します。これらは2つの異なる方法で発生します。

SCDタイプ1は、既存のレコードを上書きして最新バージョンのみを保持します。これは、顧客名のスペルミスの修正やユーザーのEメールアドレスの更新など、修正や重要度の低い更新に適しています。Spark宣言型パイプラインでは、これをわずか数行のコードで設定できます。一方、Lakeflowはシーケンス処理、依存関係、順不同のイベントを自動的に処理します。

SCD Type 2は、_START_AT列と_END_AT列を自動的に管理して完全な履歴を保持し、Delta LakeによるACIDトランザクションで監査と時間ベースの分析をサポートすることで、過去の状態を分析用に利用できるようにします。これは、顧客の住所の経時的な追跡、製品価格の変更のモニタリング、コンプライアンスのための監査証跡の維持といったタスクに最適です。

CDC 手法と Spark宣言型パイプライン を組み合わせることで、ユーザーは、バッチ環境とストリーミング環境の両方でスケールする、メンテナンスの手間がかからない本番運用対応の CDC パイプラインを作成できます。

CDCの実装：ステップバイステップのデプロイ

効果的なCDCは、計画と準備から始まります。まず、データ量、遅延の許容度、更新頻度などのビジネス要件とシステム要件を評価します。高スループットのシステムではストリーミングインジェストが必要になる場合がある一方、更新が遅いソースでは定期的な更新に依存する場合があります。次に、ソースシステムへのアクセス権と権限を確認し、トランザクションlogsやスナップショットを読み取れるようにします。最後に、パーティショニングやバージョニング戦略を使用して、現在のデータとヒストリカルデータの両方を保存できるターゲットスキーマを設計します。

DatabricksはLakeflow宣言型パイプラインを通じてCDCを簡素化します。これにより、Delta LakeによるACID準拠のストレージレイヤーを含む、スケーラブルで増分的なデータ処理が提供され、単一のデータコピーでバッチとストリーミングの両方のワークロードに対応し、一貫性の確保とコスト削減を実現します。

Lakeflowはこれを基盤にAUTO CDC APIsを構築し、シーケンス処理の自動管理、順序がばらばらになったレコードの解決、スキーマの一貫性の維持を行います。ユーザーは、決定論的な順序付けのために、タイムスタンプ、ID、または複合キーによってデータをシーケンス処理できます。

ネイティブの変更フィードがないシステムの場合、AUTO CDC FROM SNAPSHOT は、Oracle や MySQL からのテーブルやエクスポートなどの連続したスナップショットを比較して、変更を効率的に検出します。

MERGE INTOやforeachBatchのような手動の方法と比較して、AUTO CDCはDatabricks Lakeflow Connectによって提供されるDELETEおよびTRUNCATE操作の組み込みサポートを備えたローコードの代替手段です。Deltaテーブルと統合されたこれらのパイプラインは、Kafka、Iceberg、またはデータウェアハウスに更新をストリーミングでき、多様なアナリティクスおよびストリーミングのユースケースをサポートします。

Delta LakeとLakeflowを組み合わせることで、CDCは宣言的で信頼性が高く、本番運用に対応したものとなり、リアルタイムのunified analyticsというDatabricksのlakehouseビジョンに合致します。

プラットフォーム固有の CDC 実装

CDCの動作はソースデータベースによって異なります。

SQL Server: SQL ServerのネイティブCDC機能は、ソーステーブルからの挿入、更新、削除をデータベース内の専用の変更テーブルに自動的にキャプチャします。これらのテーブルには、操作の種類やコミットのタイムスタンプなどのメタデータが含まれており、特定の期間にどの行が変更されたかを簡単に判断できます。SQL Serverはまた、下流システムがキャプチャされたイベントを読み取るのに十分な時間を確保しつつ、無制限の増大を防ぐためのリテンション制御も提供します。組織はSQL ServerからDatabricksへの移行戦略を活用して、データインフラストラクチャをモダナイズできます。

Oracle: Oracleは、LogMinerやGoldenGateなどのテクノロジーを通じてCDCを可能にします。これらのテクノロジーは、ソースのワークロードに影響を与えることなく、REDO logsを読み取ってコミットされた変更を検出します。これらのツールにより、大容量かつ低レイテンシーのレプリケーションが可能になり、チームはOracleからDatabricksへの移行のベストプラクティスに従って、実装を成功させることができます。

MySQL：MySQLはバイナリログを通じて変更イベントを公開し、CDCツールが行レベルの更新を効率的に取り込めるようにします。

PostgreSQL: PostgreSQLは、先行書き込みログ（Write-Ahead Log）を使用して論理デコーディングを可能にします。これにより、下流のコンシューマーが処理できる変更イベントが表出化されます。

すべてのプラットフォームでパターンは一貫しています。ソースデータベースが変更をlogsまたは変更テーブルに書き込み、CDCツールがそれらのイベントを抽出してダウンストリームのパイプラインに供給します。

CDC の最適化: パフォーマンスとデータ品質

実行が開始されたら、CDCパイプラインはパフォーマンス、品質、回復力の観点から調整する必要があります。強力なデータ品質管理は、パイプラインの信頼性を維持します。

これは並列化とパーティショニングから始まり、データをリージョン、日付、またはキーで分割して複数のストリームを並行して処理します。バッチサイズとリソース割り当てを調整することで、レイテンシーとコストのバランスをさらに取ることができます。たとえば、バッチサイズを小さくするとラグが減少し、大きくするとスループットが向上します。

複数のシステム間でデータを移動する際、CDCは完全なレプリケーションのようなリソースを大量に消費するオーバーヘッドなしに、ターゲットシステム間の一貫性を確保します。ソースシステムからの変更のみを処理することで、下流のアプリケーションが時間に制約のある意思決定のために更新されたデータを受信できるようにしつつ、下流のコンシューマーに対する低レイテンシーを維持します。

コミットレイテンシーや失敗数などの主要なメトリクスを定期的にモニタリングすることで、ユーザーはパフォーマンスの問題を早期に発見できます。さらに、明確に定義されたリテンションポリシーにより変更テーブルの不必要な増大が防がれ、自動化されたスキーマ進化によりソース構造が変化しても互換性が維持されます。Databricksに組み込まれた検証機能は更新がスキーマ要件を満たしていることを確認し、監査証跡は透明性のためにすべての挿入、更新、削除を追跡します。

もちろん、データを扱う際には、単一のマイクロバッチ内での複数回の更新など、複数の課題が生じます。これを解決し、正確性を確保するために、Databricksはプライマリーキーでレコードをグループ化し、シーケンスカラムを使用して最新の変更のみを適用します。順序がばらばらな更新は決定論的なシーケンシングを通じて処理され、論理削除パターンでは、後でクリーンアップジョブがレコードを削除する前に、レコードを非アクティブとしてマークします。これらの戦略により、オペレーションを中断することなくデータ完全性が維持されます。

高度なユースケースと今後の考慮事項

CDCは単純なレプリケーションにとどまりません。組織はCDCを使用して、複数のシステムやクラウドを接続し、分散環境を同期させ、リアルタイム分析を強化しています。CDCはイベントの順序を保持するため、負荷の高いバッチジョブを必要とせずに、プラットフォーム間で一貫した状態を維持します。

CDCは、継続的な更新を配信することで機械学習の特徴量パイプラインもサポートします。これにより、トレーニングと推論の整合性が保たれ、オンライン/オフラインのスキューが削減されます。Databricks Feature Storeなどの特徴量ストアは、正確で時間認識型のルックアップのためにCDCデータを利用し、高度なmachine learningの特徴量エンジニアリングを可能にします。

アーキテクチャが進化するにつれて、Lakeflow JobsとSpark宣言型パイプラインによる自動化がオーケストレーションとモニタリングを簡素化します。サーバーレスCDCは運用オーバーヘッドを削減し、DeltaやIcebergなどのオープンテーブルフォーマットは柔軟性を高め、イベント駆動型の設計は高速で信頼性の高いデータ移動のバックボーンとしてCDCを活用します。

CDCとイベントストリーミング：Kafkaとの連携

CDCとSCDで見たように、CDCとApache Kafkaはデータ移動パイプラインの異なる部分に対応しますが、両者は非常に補完的です。CDCが新しいデータをキャプチャするのに対し、Kafkaはデータストリーミングプラットフォーム機能を通じてイベントデータを大規模に転送および処理するために設計された分散ストリーミングプラットフォームです。この2つは、データパイプライン内で一緒に使用されることがよくあります。

一般的なアーキテクチャでは、DebeziumのようなlogsベースのCDCツールが、データベースのトランザクションlogsから直接変更イベントを読み取ります。Debeziumはこれらのイベントをターゲットテーブルにすぐに書き込むのではなく、Kafkaトピックにパブリッシュします。そこでイベントは耐久性のあるイベントストリームの一部となります。Kafka Connectはこれを可能にする連携レイヤーを提供し、MySQL、PostgreSQL、SQL ServerといったソースがカスタムコードなしでKafkaに新しいデータを供給できるようにします。CDCイベントがKafkaに入ると、データウェアハウスやレイクハウスなどの他のシステムが、到着した最新のデータを保存します。

さらに、サービスはデータベースを繰り返しポーリングするのではなく、変更イベントをサブスクライブできるため、遅延が削減され、スケーラビリティが向上します。CDCは、生成されるとすぐに最新のデータがKafkaに入るようにするため、マテリアライズドビューの更新、ワークフローのTrigger、リアルタイムアナリティクスの実行など、ダウンストリームのプロセスは常に最新の情報で動作します。このように、CDCが変更イベントを供給し、Kafkaはそれらのイベントを組織のデータエコシステム全体に効率的に配布するシステムとして機能します。

FAQ

チェンジデータキャプチャに関するよくある質問

ETLにおけるCDCプロセスとは何ですか？

CDCは、前回の抽出以降に変更された行のみを識別して配信するメカニズムです。テーブル全体をスキャンまたは再読み込みする代わりに、CDCはソースシステムから直接、挿入、更新、削除をキャプチャし、それらを増分イベントとしてダウンストリームに送信します。これにより、変換および読み込みステージを固定のバッチ間隔ではなく、継続的にランできます。新しい各イベントがパイプラインを流れる際に、ほぼリアルタイムで検証、変換され、ターゲットシステムに適用されます。

ETLとCDCの違いは何ですか？

ETLは、ソースシステムからデータを抽出し、一貫性のために変換し、ダウンストリームのデータウェアハウスまたはレイクハウスに読み込む、広範なデータワークフローです。従来のETLは、多くの場合バッチ処理に依存しており、テーブル全体または大きなパーティションがスケジュールされた間隔で移動されます。一方、CDCは、ETLサイクル間で発生する変更のみを識別して送信することに焦点を当てています。CDCはETLを置き換えるものではなく、抽出ステップを増分的かつ継続的にすることでETLを強化します。これにより、コンピュートのオーバーヘッドが削減され、バッチウィンドウへの依存がなくなり、ダウンストリームシステムが完全な再読み込みなしでタイムリーな更新を確実に受け取れるようになります。

CDCとSCDの違いは何ですか？

CDCとSCDは、データパイプラインの異なるレイヤーで動作します。CDCはソースシステムから変更をキャプチャするのに対し、SCDはキャプチャされた変更をターゲットシステムにどのように保存するかを決定するモデリングパターンです。例えば、CDCが更新を検出した場合、SCDタイプ1は既存のレコードを上書きし、SCDタイプ2は完全な履歴を維持するために起動と終了のTimestampを持つ新しいバージョン管理された行を追加します。

CDCとKafkaの違いは何ですか？

CDCとKafkaは補完的な目的を果たします。CDC はソースデータベースから行レベルの変更をキャプチャする技術であり、一方、Kafka はそれらのイベントを大規模に保存、転送、処理するために設計された分散型イベントストリーミング プラットフォームです。多くの最新アーキテクチャでは、Debezium のような CDC ツールがログベースのキャプチャを使用してソースシステムの新しいデータを検出し、結果として得られたイベントを Kafka トピックにパブリッシュします。そこから、ダウンストリームのアプリケーション、サービス、またはデータ プラットフォームが、最新のデータをリアルタイムでコンシュームします。

まとめ

チェンジデータキャプチャは、現代のデータチームにとって中核的な機能となっています。リアルタイムのダッシュボードへの電力供給、機械学習モデルへのデータ供給、あるいはクラウドデータウェアハウスのモダナイゼーションやレイクハウスアーキテクチャによるシームレスなデータ移行の実現など、CDCはリアルタイムのデータ同期により、システムの整合性を保ち、データの信頼性を維持するのに役立ちます。

このプロセスの成功は綿密な設計にかかっています。適切な手法を選択し、スケールを計画し、品質を監視することが重要です。ここからは、これらの原則が自社のアーキテクチャにどのように適合するかを評価し、概念実証（PoC）で小さく始めてから、成長に合わせて改良していきます。適切なアプローチを取ることで、CDC は単なるパイプラインタスクにとどまらず、永続的なビジネス上の利点となります。

最新のデータエンジニアリングに関するヒントやベストプラクティスをもっと知りたいですか？信頼性の高いデータパイプラインのためのリソースを集めたデータエンジニアリングツールキットを入手しましょう。