自動化されたETL（抽出、変換、ロード）とデータ統合のワークフローは、現代のデータドリブン型の企業には不可欠であり、ソースからターゲットとなるデータウェアハウスやデータレイクに迅速かつ効率的にデータを移行することができます。しかし、ETLは一定の間隔で、あるいはリアルタイムで実行しなければなりません。では、どの情報がフレッシュで、どの情報がすでに取り込まれているかをどうやって把握すればよいでしょう？
この問題を解決するのが、Change Data Capture（CDC）です。具体的には、どのような場合にChange Data Captureを使用するのでしょうか？この記事では、ETLの専門家としての立場から、このテーマについてアドバイスします。
Change Data Captureとは?
Change Data Capture（CDC）とは、特定のソースからの新規または変更されたデータを識別するデータ統合テクノロジーを指す言葉です。この新しいデータや変更されたデータは、クラウドのデータウェアハウスやデータレイクに移行することができます。
変更データの取り込みを適用することで、ビジネスインテリジェンス（BI）やアナリティクスのワークロードでは新鮮なデータのみを選択的に取り込むことができます。CDCにより、一定間隔でETLを実行することが可能になり、ウェアハウス内のデータが陳腐化するのを防ぎ、よりスマートなデータドリブン型の意思決定を促進します。
Change Data Captureはどういう場合につかうべきか?
Change Data Captureは、長期的には、特に処理量の多いETLの変換ステージで、多くの時間と労力を節約することができます。しかし、すべてのデータソースでChange Data Captureを使用する必要があるとは限りません。
例えば、アクセスするたびに情報が変化する天気予報モニターのようなストリーミングデータソースを考えてみましょう。このようなデータソースでは、すべてのデータが「新しい」ものであり、前回データ抽出を行ったときの残留情報がないため、CDCは必要ありません。
一方で、CDCは、長期的なデータストレージとして機能するソーステーブルやデータベースにとって非常に重要です。これらのリポジトリには、数千から数百万のレコードが含まれている可能性がありますが、そのほとんどはコピー元とコピー先間でほとんど変更はありません。実際に変更されたレコードに関係なく、毎回データベース全体を無差別にインジェストしようとするのは、愚かで無駄なことです。
ここまでは、主にバッチETL（定期的にETLを実行すること）に対するCDCの影響について説明してきました。CDCはデータがデータソース側で生成された直後にパイプラインを通過するような、リアルタイムETLを実行するためには、ほぼ必須です。
バッチETLにはいくつかの問題があります。大量のデータを取り込むと、CDCによる新鮮なデータに限定しても、時間がかかり、システムやネットワークに負担がかかります。このため、多くの企業では、より多くのリソースが利用でき、人々の業務を妨げる可能性が低い夜間にバッチETLを実行しています。しかし、この遅延は、重要な意思決定者が貴重なデータやインサイトにアクセスするまでにより長く待たなければならないことを意味します。
このような理由から、多くの企業ではリアルタイムETL（ストリーミングETLとも呼ばれる）を採用しています。リアルタイムETLは、データを継続的にデータウェアハウスに送信するため、どの時点でも少ないリソースしか消費しません。
もちろん、新しいデータが利用可能であることを知るためには、どのような情報を収集すべきかを知るためにCDCのような技術を使用する必要があります。もしあなたの組織が、クレジットカード詐欺の検出からIoT分析まで、何らかのリアルタイムのデータ駆動活動に依存しているのであれば、リアルタイムETLが必要であり、そのためにデータの取り込みを変更する必要があります。
各CDCメソッドの使い分け
"いつCDCを使用すべきか？"という質問についても検討する必要があります。"さまざまなCDCの手法をどう使い分ければよいのでしょうか？" ここでは、CDCの手法をどう使いわけるべきかについてのアドバイスを紹介します。
1. ログベースCDC
ログベースのCDCでは、データベースのトランザクションログを使用します。これは、すべてのデータベーストランザクション（UPDATE、INSERT、DELETEステートメントなど）を記録する独立したメタデータファイルです。トランザクションログの目的は、データベースがクラッシュした場合の復旧を支援することですが、CDC の実行にも役立ちます。ログベースのCDCでは、トランザクションログをスキャンして、前回のETL実行以降に新規または変更されたレコードを再構築します。
ログベースのCDCは、一般的に正確で効率的ですが、実装するには技術的に複雑になる可能性があります。データベースシステムごとにトランザクションログのフォーマットが異なるため、システムごとに独自のスクリプトを記述する必要があるかもしれません。
2. トリガーベースCDC
トリガーベースのCDCでは、データベーストリガーを使用します。これは、特定のイベントが発生したとき（例えば、新しいデータがデータベースにロードされたとき）に実行される特殊なデータベース関数です。データベーストリガーが実行される場合、ETL プロセスが新しい情報を取り込むための信号として機能します。
トリガーベースのCDCは、データベースへの変更を識別する信頼性の高い方法です。しかし、データベーストリガーを実行すると、データベース操作に大量のオーバーヘッドがかかります。また、データベース以外のデータソースではこの手法は利用できません（ログベースのCDCも同様ですが）。
3. メタデータ
多くのデータソースには、レコードが最後に変更された日時を示すDATE_MODIFIEDやLAST_UPDATEDカラムなどのメタデータが含まれています。この列を調べることで、どのレコードが前回のETL実行後に変更されたかを特定し、適切なデータを取り込むことができます。
このメタデータベースのアプローチは、比較的簡単で効率的に実装できますが、1つ大きな欠点があります。それは、削除されたレコードが存在しないため、特定することができないことです。削除されたレコードはもはや存在しないため、データウェアハウス内のデータを定期的にクレンジングしたい場合は、このアプローチは適していません。
最後に
CDCとは何か、どのような場合にチェンジデータキャプチャーを使用すべきかについてお話しましたが、実際にCDCを導入するにはどうすればよいのでしょうか？
多くの企業にとっては、Integrate.ioのようなETLツールが正解です。Integrate.ioには、CDCが搭載されているので、必要なデータを正確に取り込み、必要のないデータはスキップすることができます。Integrate.ioのローコードおよびノーコード機能は、変更データの取り込みの際、技術的な細かい部分に心配する必要がなく、より迅速に、効率的に、データドリブンにすることだけを考えることができます。
Integrate.ioは、CDC、100種類以上の組み込み済みの統合およびコネクタ、シンプルなドラッグ＆ドロップのインターフェイスなど、豊富で多様な機能を備えており、データ統合のワークロードを自動化および合理化したい企業にとって最適な選択肢です。Integrate.ioについて詳しく知りたい方は、オンラインデモをお申し込みください。
