Flink CDC コンポーネント

2023年5月5日 · 約9分

最近リアルタイムデータパイプラインを整理する中で、Flink CDC に関する知識をあらためてまとめ直しました。「データベースの変更をリアルタイムに外へ運び出す」というニーズはほぼすべてのデータチームが直面するものなので、独立した記事として記録しておく価値があると思います。

背景

データ同期をやろうとしたとき、最も素朴な方法は定時バッチです。毎日深夜に業務 DB からフルダンプを取り、データウェアハウスに書き込む。実装はシンプルですが、遅延は時間単位、下手をすると日単位になり、データ量が増えるとソース DB への負荷も無視できません。ビジネス側から「レポートはリアルタイムで見たい」という要望が出た瞬間、バッチ方式は破綻します。CDC はまさにこの問題を解決するために登場した技術路線であり、Flink CDC は CDC の能力とストリーム処理エンジンをかなり徹底的に統合した実装の一つです。

Flink CDC（Change Data Capture）は Apache Flink エコシステムの重要なコンポーネントで、データベース内のデータ変更をリアルタイムにキャプチャし、それらの変更をデータストリームに変換して処理するために使われます。モダンなデータアーキテクチャにおいて、CDC 技術はリアルタイムデータ同期、リアルタイムデータウェアハウス、イベント駆動システムの構築に広く利用されています。

従来のデータ同期方式（定時のフル同期など）と比べ、CDC はデータベースの Binlog / WAL などの変更ログ を読み取ることでデータ変化をキャプチャし、低遅延・低侵襲のデータ同期を実現できます。

CDC とは

CDC（Change Data Capture）とは 変更データキャプチャ のことで、その核心となる考え方は次のとおりです。
データベース内のデータに INSERT / UPDATE / DELETE 操作が発生したとき、それらの変化を記録し、リアルタイムに下流システムへ伝達する。

ここで実装メカニズムを少し掘り下げてみます。CDC は大きく 2 種類に分かれます。1 つはクエリベースのもので、タイムスタンプや自動採番の主キー列をポーリングして新しいデータを発見します。実装は簡単ですが DELETE を捕捉できず、2 回のポーリングの間に複数回変更されたレコードを取りこぼしやすいという欠点があります。もう 1 つはログベースのもので、データベースがマスター・スレーブレプリケーションのために保持している変更ログを直接消費します。MySQL の Binlog、PostgreSQL の WAL がこれに該当します。ログには各行の変更前後の完全な状態が自然に記録されているため、ログベースの CDC は挿入・更新・削除のすべてのイベントを取得でき、しかもソース DB への追加のクエリ負荷はほとんどありません。Flink CDC が採っているのはこのログの路線です。

実際のデータアーキテクチャにおいて、CDC は次のような用途でよく使われます：

データベース → データウェアハウス（リアルタイム DWH）
データベース → Kafka（イベントストリーム）
データベース → 検索エンジン（Elasticsearch など）
データベース → キャッシュシステム（Redis など）

このように、CDC はモダンな リアルタイムデータプラットフォーム（Real-time Data Platform） の重要な基盤能力の一つです。

Flink CDC コンポーネントの動作原理は、ソースデータシステムの変更ログをキャプチャし、それをデータストリームに変換してリアルタイムに処理するというものです。CDC コンポーネントはソースシステムのログを読み取るだけで、ソースシステムへの書き込みは行わないため、このプロセスはソースシステムに影響を与えずに実行できます。データベースの視点から見ると、CDC クライアントは通常のスレーブと本質的な違いはありません。レプリケーションクライアントに擬態してマスターに変更ログを購読し、ログイベントを構造化された変更レコードに解析して Flink に渡します。

Flink CDC コンポーネントの利点は、リレーショナルデータベース（MySQL、Oracle など）と NoSQL データベース（MongoDB、Cassandra など）を含む多様なデータソースをサポートできることです。さらに、JSON、CSV など複数のデータフォーマットにも対応しています。

もう一つ過小評価されがちな利点は、Flink 本体との統合の深さです。変更ストリームが Flink に入ってしまえば、それは普通のデータストリームであり、Flink のウィンドウ計算、複数ストリームの Join、状態管理、checkpoint による耐障害機構をそのまま適用できます。つまり「変更のキャプチャ」と「変更の処理」が同一エンジン内で完結し、中継のために Kafka Connect クラスタを別途運用する必要がなく、パイプラインは短く、運用対象も少なくなります。

Flink CDC コンポーネントを使えば、リアルタイムのデータ同期とデータストリーム処理が実現できます。例えば、CDC コンポーネントで MySQL データベースのデータを Kafka に同期し、その後 Flink でリアルタイムのデータ処理を行うといった使い方ができます。こうしてデータのリアルタイム同期と処理が実現でき、データの効率と正確性が向上します。