The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
変更データ・キャプチャーは、組織内でサイロ化または不整合が生じたままになる可能性のあるデータを統合・調和させるリアルタイム・データ統合の手法です。データ統合の他の方法としては、ストリームデータ統合、データ仮想化、アプリケーションの連携などがあります。
CDCがダウンストリームのプロセスやシステムをほぼリアルタイム、リアルタイム、または低遅延のリアルタイムで更新できる能力は、リアルタイムデータ分析、クラウド移行、人工知能(AI)モデルの成功に不可欠です。小売、金融、ヘルスケアなどの分野における不正アクセス検知、サプライチェーン管理、規制遵守など、業種・業務を問わずさまざまなユースケースをサポートしています。
変更データ・キャプチャーには複数のアプローチがあり、ログベースCDC、タイムスタンプベースCDC、トリガーベースCDCが最も一般的です。企業は、データベース・ネイティブ・ツール、オープンソース・プラットフォーム、サードパーティ製ソリューションを活用して変更データ・キャプチャーを導入できます。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
現代のデータ管理において、変更データ・キャプチャーは重要なデータ・エンジニアリングの仕組みとして登場しています。現在、企業を取り巻くデータ環境はますます大規模かつ複雑になっています。これらには、モノのインターネット(IoT)デバイス、分散データベース、アプリケーション、その他多様なソースからのデータが含まれている可能性があります。拡大するデータ・エコシステム全体で一貫した高品質データを維持することは継続的な課題です。
同時に、ビジネスはリアルタイムの意思決定に活用できる、正確で最新の情報を求めています。変更データ・キャプチャーは、組織がこの要求に応えるための複数の手法の一つです。
変更データ・キャプチャーは、他のデータ統合手法よりも効率的でリソース消費の少ない形で新鮮なデータを提供する低遅延データ・パイプラインを可能にします。例えば、データ複製は、データセット全体をコピーすることを指します。これに対し、CDCは変更されたデータのみを送信するため、ソース・システムの負荷やネットワーク・トラフィック、計算リソースの要求を削減します。
これにより、最新かつ最も正確な情報に迅速かつ効率的にアクセスできるようになり、以下を含む複数のメリットが得られます。
CDCは、組織が運用データをリアルタイムのデータ分析プラットフォームとダッシュボードにストリーミングすることで、より正確で最新のレポート作成、ビジネス洞察、意思決定を可能にします。これらの機能により、企業は、現代のタイムセンシティブな24時間365日のビジネス環境の要求に対応できます。
データ・ソースとターゲット・システム間の継続的な同期により、ダウンタイムや中断を最小限に抑えながら、データベース、クラウド環境、またはアプリケーション間のデータ・マイグレーションをサポートします。例えば、クラウド移行の際、CDCはオンプレミスで発生したデータ変更を迅速に関連するクラウド・ベースのデータ・テーブルに届け、両環境間の整合性を確保します。
ETL(抽出、変換、ロード)データ・パイプラインは、データ分析および機械学習のワークストリームに不可欠です。しかし、バッチ処理に依存するETLの実行は、処理速度が遅く、システム・リソースに負荷をかける傾向があります。CDCをETLに組み込むことで、リソースの使用を最適化し、データ移動を加速できます。
変更データ・キャプチャーは、ソース・データ・システムで発生した挿入、更新、削除を特定して記録します。これらのソースには、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モデルでは、ソース・システムが変更を検知し、即座に「プッシュ」してターゲット・システムに送信します。このアプローチは、データベース・トランザクション・ログ、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ツール、コネクタ、データ統合プラットフォームが必要です。
ETL(抽出、変換、ロード)と変更データ・キャプチャーはどちらも広く使用されているデータ統合アプローチですが、目的が異なります。
以下に、ETLとCDCの主な違いをいくつか示します。
現代の組織では、ETLとCDCの両方を、多くの場合、並行して使用しています。たとえば、CDCは、初期のデータ・ロード後に増分更新を送信することで、ETLパイプラインを補完します。これにより、ソースシステムで変更が発生しても、次のETLジョブの実行を待たずにデータ・セットをリアルタイムで更新できます。
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ツールを評価する際、組織は多くの場合、以下を考慮します。
企業はさまざまな用途で変更データ・キャプチャーをデプロイできます。
変更データ・キャプチャーを活用して財務記録の変化を継続的に追跡することで、大きな損失が発生する前に不正行為を検出できます。
CDCは、IoTデバイスから生成される膨大なリアルタイム・データを効率的に統合し、予知保全やリアルタイム監視を可能にします。
変更データ・キャプチャーによってサポートされるリアルタイムの販売、在庫、サプライチェーン情報へのアクセスは、企業が品切れを回避し、利益を生む価格設定の判断を下すのに役立ちます。
変更データ・キャプチャーは、高度に規制された企業が報告および規制・法律(GDPR、サーベンス・オックスリー法(SOX法)、米国のHIPAAなど)への準拠に必要な正確な記録を維持するのに役立ちます。
データ・サイロを排除し、複雑さを軽減し、データ品質を向上させることで、卓越した顧客体験と従業員体験を実現するデータ・ストラテジーを設計します。
watsonx.dataを使用すると、オープンでハイブリッド、かつ管理されたデータ・ストアを通じて、データがどこに保存されていても、すべてのデータを使用して分析とAIを拡張できます。
IBMコンサルティングと連携することで、企業データの価値を引き出し、ビジネス上の優位性をもたらす洞察を活用した組織を構築します。