変更データ・キャプチャーとは

変更データ・キャプチャーの定義

変更データ・キャプチャー(CDC)は、データベース内のデータに加えられた変更を検出およびキャプチャーし、それらの変更をダウンストリーム・システムに送信する手法です。CDCは、データベース変更後も、システム間でほぼリアルタイムまたはリアルタイムでのデータ同期複製、イベント駆動処理を可能にします。

変更データ・キャプチャーは、組織内でサイロ化または不整合が生じたままになる可能性のあるデータを統合・調和させるリアルタイム・データ統合の手法です。データ統合の他の方法としては、ストリームデータ統合、データ仮想化アプリケーションの連携などがあります。

CDCがダウンストリームのプロセスやシステムをほぼリアルタイム、リアルタイム、または低遅延のリアルタイムで更新できる能力は、リアルタイムデータ分析、クラウド移行、人工知能(AI)モデルの成功に不可欠です。小売、金融、ヘルスケアなどの分野における不正アクセス検知、サプライチェーン管理、規制遵守など、業種・業務を問わずさまざまなユースケースをサポートしています。

変更データ・キャプチャーには複数のアプローチがあり、ログベースCDC、タイムスタンプベースCDC、トリガーベースCDCが最も一般的です。企業は、データベース・ネイティブ・ツール、オープンソース・プラットフォーム、サードパーティ製ソリューションを活用して変更データ・キャプチャーを導入できます。

変更データ・キャプチャーのメリットとは

現代のデータ管理において、変更データ・キャプチャーは重要なデータ・エンジニアリングの仕組みとして登場しています。現在、企業を取り巻くデータ環境はますます大規模かつ複雑になっています。これらには、モノのインターネット(IoT)デバイス、分散データベース、アプリケーション、その他多様なソースからのデータが含まれている可能性があります。拡大するデータ・エコシステム全体で一貫した高品質データを維持することは継続的な課題です。

同時に、ビジネスはリアルタイムの意思決定に活用できる、正確で最新の情報を求めています。変更データ・キャプチャーは、組織がこの要求に応えるための複数の手法の一つです。

変更データ・キャプチャーは、他のデータ統合手法よりも効率的でリソース消費の少ない形で新鮮なデータを提供する低遅延データ・パイプラインを可能にします。例えば、データ複製は、データセット全体をコピーすることを指します。これに対し、CDCは変更されたデータのみを送信するため、ソース・システムの負荷やネットワーク・トラフィック、計算リソースの要求を削減します。

これにより、最新かつ最も正確な情報に迅速かつ効率的にアクセスできるようになり、以下を含む複数のメリットが得られます。

  • より迅速な意思決定で
  • ゼロダウンタイム移行
  • ETLプロセスの改善
  • AIのパフォーマンス向上

より迅速な意思決定

CDCは、組織が運用データをリアルタイムのデータ分析プラットフォームとダッシュボードにストリーミングすることで、より正確で最新のレポート作成、ビジネス洞察、意思決定を可能にします。これらの機能により、企業は、現代のタイムセンシティブな24時間365日のビジネス環境の要求に対応できます。

ダウンタイムゼロの移行

データ・ソースとターゲット・システム間の継続的な同期により、ダウンタイムや中断を最小限に抑えながら、データベース、クラウド環境、またはアプリケーション間のデータ・マイグレーションをサポートします。例えば、クラウド移行の際、CDCはオンプレミスで発生したデータ変更を迅速に関連するクラウド・ベースのデータ・テーブルに届け、両環境間の整合性を確保します。

ETLプロセスの改善

ETL(抽出、変換、ロード)データ・パイプラインは、データ分析および機械学習のワークストリームに不可欠です。しかし、バッチ処理に依存するETLの実行は、処理速度が遅く、システム・リソースに負荷をかける傾向があります。CDCをETLに組み込むことで、リソースの使用を最適化し、データ移動を加速できます。

人工知能(AI)パフォーマンスの向上

変更データ・キャプチャーを実装することで、モデルのソース・データを最新の状態に保ち、大規模言語モデル(LLM)が正確でタイムリーな出力を提供できるようになります。例えば、検索拡張生成(RAG)のユースケースでは、AIモデルが外部のナレッジ・ベースと連携して、より適切な応答を実現します。

AI Academy

生成AIの成功の鍵はデータ管理

生成AIの使用を成功させるために、高品質のデータが不可欠である理由をご覧ください。

変更データ・キャプチャーの仕組み

変更データ・キャプチャーは、ソース・データ・システムで発生した挿入、更新、削除を特定して記録します。これらのソースには、Oracle Database、PostgreSQL、MySQL、Microsoft SQL Server、Azure SQL Databaseのようなリレーショナル・データベースのほか、Apache CassandraやMongoDBのような非リレーショナル(NoSQL)データベースも含まれます。

現代のCDCシステムでは、一般的にログベースのCDCが使用されており、ツールはデータベース・トランザクション・ログ(データベース内のデータ変更を記録するファイル)を読み取り、変更を識別します。トランザクション・ログ内の各変更イベントは、ログ・シーケンス番号(LSN)などの順序付きログ位置に関連付けられます。これらは、CDCシステムが変更がいつ行われたかを正確に判断するのに役立ちます。

変更がキャプチャーされた後、データレイクデータウェアハウスApache Kafkaなどのストリーミング・データ・プラットフォーム、Apache Sparkなどのストリーム処理エンジン、ETL/ELTパイプラインなどのダウンストリーム・システムにリアルタイムまたはほぼリアルタイムでストリーミングされます。

CDCのアプローチ:プッシュとプル

変更データ・キャプチャーは、ソース・システム(プッシュベースのアプローチ)またはターゲット・システム(プルベースのアプローチ)のいずれかによって開始できます。根本的な違いは、どのシステムが変更をキャプチャして送信するかにあります。

プッシュベースのCDC

プッシュベースのCDCモデルでは、ソース・システムが変更を検知し、即座に「プッシュ」してターゲット・システムに送信します。このアプローチは、データベース・トランザクション・ログ、Event Streams、またはKafkaなどのメッセージ・ブローカーを使用して実装されることが一般的です。

変更が発生するタイミングで送信されるため、プッシュ型CDCは通常、Streaming Analytics、イベント駆動型アーキテクチャ、AI/MLシステムなど、リアルタイムまたはほぼリアルタイムのデータ移動を必要とするユースケースをサポートしています。

プルベースのCDC

プルベースのCDCでは、ターゲット・システムが定期的にソース・システムをポーリングし、変更が見つかった場合に「プル」します。ポーリングは固定スケジュールで実行できるため、プルベースのCDCは、即時の更新を必要としないバッチ指向のワークロードやシステムに適しています。

このアプローチはプッシュベースCDCよりもシンプルで、インフラも複雑ではありませんが、高遅延をもたらし、ソース・データベースへのクエリーの負荷が高まるため、データベースの性能に影響が出る可能性があります。多くの最新のデータ・プラットフォームでは、データのニーズと運用要件に応じて両方のアプローチがサポートされています。

変更データ・キャプチャーの一般的な方法

変更データ・キャプチャーを実行する方法はいくつかあります。一般的なCDCの種類には、次のものがあります。

  • ログベースのCDC
  • タイムスタンプベースのCDC
  • トリガーベースのCDC

ログベースのCDC

データベース・トランザクション・ログはデータベースの標準機能であり、すべてのデータベース・トランザクションを記録するために使用されます。(トランザクション・ログ・ファイルは、システム障害時にデータベースを復旧するために使用されます。)

ログベースのCDCでは、CDCアプリケーションが、ログに記録されたデータベースの変更(データとメタデータの両方)を処理し、更新情報を他のシステムと共有します。ログベースCDCは、その効率性からますます人気が高まっています。クエリではなくログに依存しているため、ソース・システムに大きな負荷がかかる可能性があります。しかし、トランザクション・ログの形式の違いは、異なるデータベース間でのログベースCDCの実行を複雑にする可能性があります。

タイムスタンプベースのCDC

タイムスタンプベースの変更データ・キャプチャー(クエリベースCDCとも呼ばれる)は、データベース・テーブルのスキーマに、レコード変更の日付と時刻を示すタイムスタンプ列などのカラムがあることを前提としています。CDCツールは、ソース・テーブルのタイムスタンプ列を使って変更されたレコードを特定し、その後ターゲット・システムに更新情報を届けることができます。

タイムスタンプベースのCDCは導入が比較的容易ですが、タイムスタンプ・データのポーリングが頻繁に行われると、システムに追加の負荷がかかる可能性があります。タイムスタンプベースCDCは、行全体とともにタイムスタンプが削除された場合、削除操作を検知できないこともあります。

トリガーベースのCDC

トリガーベースの変更データ・キャプチャーでは、データベース内で挿入、削除、更新などの特定の変更が発生すると、データベース・トリガーと呼ばれるストアド・プロシージャーや関数が実行されます。変更されたデータは、一般にチェンジ・テーブルまたはシャドウ・テーブルと呼ばれる場所に保存されます。

タイムスタンプベースCDCと同様に、トリガーベースCDCも実装が比較的容易です。しかし、トリガーはソース・テーブルでトランザクションが発生するたびに「発動」するため、ソース・システムに負荷がかかる可能性があります。

CDCの一般的な送信元と送信先

CDCの全体像を把握するために、いくつかの一般的なCDCのソースと出力先をレビューしましょう。

CDCソースとは、データが生成されるシステムであり、次のようなものがあります。

CDCの宛先は、データがストリーミングまたは複製されるシステムで、次のようなものがあります。

  • データ・ストリーム・プラットフォーム(Apache Kafka、Amazon Kinesis、Google Cloud Pub/Sub)

  • データウェアハウスとレイクハウス(Snowflake、Amazon Redshift、Google BigQuery)

  • Cloud Object Storage(AWS S3、Azure Blob Storage、Google Cloud Storage)

ソースと宛先の接続には通常、CDCツール、コネクタ、データ統合プラットフォームが必要です。

ETLとCDC:主な差別化要因

ETL(抽出、変換、ロード)と変更データ・キャプチャーはどちらも広く使用されているデータ統合アプローチですが、目的が異なります。

以下に、ETLとCDCの主な違いをいくつか示します。

  • データの移動:ETLパイプラインは通常、データ・セット全体または大規模なデータ・バッチを取り込みます。CDCは、変更内容のキャプチャと送信のみを行います。

  • 処理速度とレイテンシー:ETLは一般的に、スケジュールされた間隔でバッチ指向です。CDCは、低遅延のデータ移動と継続的な同期のために設計されています。

  • 主なユースケース:ETLは、Business Intelligence、履歴レポート、機械学習によく使用されます。CDCは、リアルタイム分析、不正アクセス検知、イベント駆動型アーキテクチャーに一般的に使用されます。

  • データ変換:ETL パイプラインは、ロード前にデータをクレンジングして変換します。CDCシステムは、それ以上の処理を行わずに変更を識別して複製します。

  • システムへの影響:従来のETLプロセスでは、繰り返しのバッチ・ワークロードによってソース・システムの負担が大きくなります。CDCは、変更のみを送信することでオーバーヘッドを最小限に抑えます。

現代の組織では、ETLとCDCの両方を、多くの場合、並行して使用しています。たとえば、CDCは、初期のデータ・ロード後に増分更新を送信することで、ETLパイプラインを補完します。これにより、ソースシステムで変更が発生しても、次のETLジョブの実行を待たずにデータ・セットをリアルタイムで更新できます。

SCDとCDCの違いとは

CDCとゆっくりと変化するディメンション(SCD)が連携して、ターゲット・システムが正確かつ最新の状態に保たれます。

CDCは、ソースシステムからの変更をキャプチャして送信しますが、SCD はそれらの変更がデータウェアハウスのディメンション・テーブル内でどのように管理および保存されるかを定義します。

(この文脈では、ディメンション・データは通常、顧客所在地や電話番号などの記述的な属性を保管するデータウェアハウス内のディメンション・テーブルを指します。)

SCDには、2つの一般的なタイプがあり、タイプ1、タイプ2と呼ばれます。

SCDタイプ1:履歴を保持せずに、ディメンション・テーブル内の既存のデータを新しいデータで上書きします。

SCDタイプ2:ディメンション・テーブルに新しい行を追加し、長期にわたる完全な履歴変更を保持します。

変更データ・キャプチャー・ツール

変更データ・キャプチャー(CDC)ツールは、データベースの変更をリアルタイムでキャプチャーして配信し、組織が最新のデータ統合、分析、イベント駆動型アーキテクチャーをサポートできるように支援します。

CDC機能は、AWS Database Migration Service(DMS)のように特定のデータベース環境にネイティブなものもあれば、より広範に実装されるものもあります。一般的なCDCソリューションには、Debeziumなどのオープンソース ツールや、IBM StreamSetsやOracle GoldenGateなどの商用プラットフォームがあります。

多くの組織は、CDCパイプラインの基盤としてApache Kafkaを使用しています。KafkaベースのCDCアーキテクチャーは、データベースの変更をキャプチャし、Kafkaトピックを通じてストリーミングし、ダウンストリームのアプリケーション、データウェアハウス、分析プラットフォーム、AIシステムに配信します。

CDCツールを評価する際、組織は多くの場合、以下を考慮します。

  • 拡張性
  • 料金体系
  • レイテンシー
  • コネクターのサポート
  • Kafka統合
  • 信頼性
  • 柔軟なデプロイメント
  • APIサポート

変更データ・キャプチャーのユースケース

企業はさまざまな用途で変更データ・キャプチャーをデプロイできます。

不正アクセス検知

変更データ・キャプチャーを活用して財務記録の変化を継続的に追跡することで、大きな損失が発生する前に不正行為を検出できます。

モノのインターネット(IoT)の実現

CDCは、IoTデバイスから生成される膨大なリアルタイム・データを効率的に統合し、予知保全やリアルタイム監視を可能にします。

インベントリーとサプライチェーン管理

変更データ・キャプチャーによってサポートされるリアルタイムの販売、在庫、サプライチェーン情報へのアクセスは、企業が品切れを回避し、利益を生む価格設定の判断を下すのに役立ちます。

法規制への準拠

変更データ・キャプチャーは、高度に規制された企業が報告および規制・法律(GDPRサーベンス・オックスリー法(SOX法)、米国のHIPAAなど)への準拠に必要な正確な記録を維持するのに役立ちます。

執筆者

Alice Gomstyn

Staff Writer

IBM Think

Alexandra Jonker

Staff Editor

IBM Think

関連ソリューション
データ管理ソフトウェアとソリューション

データ・サイロを排除し、複雑さを軽減し、データ品質を向上させることで、卓越した顧客体験と従業員体験を実現するデータ・ストラテジーを設計します。

データ管理ソリューションの詳細はこちら
IBM watsonx.data

watsonx.dataを使用すると、オープンでハイブリッド、かつ管理されたデータ・ストアを通じて、データがどこに保存されていても、すべてのデータを使用して分析とAIを拡張できます。

watsonx.dataについてはこちら
データ分析コンサルティングサービス

IBMコンサルティングと連携することで、企業データの価値を引き出し、ビジネス上の優位性をもたらす洞察を活用した組織を構築します。

分析サービスを発見する
次のステップ

データ・サイロを排除し、複雑さを軽減し、データ品質を向上させることで、卓越した顧客体験と従業員体験を実現するデータ・ストラテジーを設計します。

  1. データ管理ソリューションの詳細はこちら
  2. watsonx.dataについてはこちら