Flink CDC realizes real-time synchronization and conversion of massive data

1. Flink CDC テクノロジー

CDC は Change Data Capture の略称で、変更データをキャプチャする技術です。CDC 技術は長い歴史を持ち、現在、業界には多くの CDC 技術ソリューションが存在します。原則として 2 つのカテゴリに分類できます。

1 つはクエリベースの CDC 技術で、DataX などがあります。現在のシーンではリアルタイム性に対する要求がますます高まっており、このタイプの技術の欠点が徐々に顕著になっています。オフラインスケジューリングやバッチ処理モードでは遅延が大きくなります。オフラインスケジューリングに基づくスライシングではデータ整合性を保証できません。さらに、リアルタイム性も保証できません。
もう 1 つはログベースの CDC 技術で、Debezium、Canal、Flink CDC などがあります。この CDC 技術はデータベースログをリアルタイムに消費でき、ストリーム処理モードによりデータ整合性を保証し、リアルタイムデータを提供できるため、ますますリアルタイム化が進むビジネスニーズに対応できます。

前述の図は一般的なオープンソース CDC ソリューションの比較を示しています。Flink CDC のメカニズムは、増分同期、ブレークポイントからの再開、全量同期において非常に優れたパフォーマンスを発揮し、全量・増分統合同期もサポートしています。一方、多くの他のオープンソースソリューションは全量・増分統合同期をサポートできていません。Flink CDC は分散アーキテクチャであり、大規模データ同期のビジネスシナリオに対応できます。Flink のエコシステムの利点を活かして DataStream API と SQL API を提供し、非常に強力なデータ変換機能を実現しています。さらに、Flink CDC コミュニティと Flink コミュニティのオープンソースエコシステムは非常に充実しており、多くのコミュニティユーザーと企業がコミュニティで共同開発に参加しています。

Flink CDC は全量・増分統合同期をサポートし、リアルタイムで整合性の取れたスナップショットを提供します。たとえば、テーブルに完全な履歴データと新しいリアルタイム変更データが含まれている場合、増分データは Binlog ログファイルに継続的に書き込まれます。Flink CDC はまず全量履歴データを同期し、その後シームレスに増分データの同期に切り替えます。増分同期中に新規挿入データ（前述の図の青いブロック）の場合は、リアルタイム整合性スナップショットに追加されます。更新データ（前述の図の黄色いブロック）の場合は、既存の履歴データが更新されます。

Flink CDC はリアルタイムのマテリアライズドビューを提供し、データベースのテーブルのリアルタイム整合性スナップショットをユーザーに提供します。これにより、データのクリーニング、集約、フィルタリングなどの後続処理を行い、ダウンストリームに書き出すことができます。

2. 従来のデータ統合ソリューションの課題

前述の図は従来のデータストレージアーキテクチャ 1.0 を示しています。主に DataX や Sqoop を使用して HDFS に完全同期を行い、Hive を中心にデータウェアハウスを構築する方式です。

このソリューションには多くの欠点があります。毎日ビジネステーブルからデータを照会する必要があるため、ビジネスの安定性に影響を与えやすくなります。日次バッチ処理ではリアルタイム性が低く、遅延が大きくなります。スケジューリング間隔を数分ごとに調整すると、ソースデータベースに大きな負荷がかかります。スケーラビリティが低く、ビジネス規模が拡大するにつれてパフォーマンスボトルネックが発生しやすくなります。

前述の図は従来のデータウェアハウス 2.0 アーキテクチャを示しています。リアルタイムリンクとオフラインリンクの 2 つの処理に分かれています。リアルタイムリンクでは、Canal を介して Kafka に増分同期を行い、リアルタイム再処理を実行します。通常、完全同期は 1 回のみ行われ、日次増分データは HDFS 上で定期的にマージされ、最終的に Hive データウェアハウスにインポートされます。

この方法では完全同期を 1 回だけ実行するため、ビジネスの安定性にほとんど影響しません。しかし、増分同期は定期バックフローに依存するため、時間レベルまたは日レベルでの維持に限られ、リアルタイム性が比較的低くなります。同時に、全量と増分の 2 つのリンクが分離されているため、保守が必要なリンクやコンポーネントが多くなり、システムの保守性が低下します。

前述の図は従来の CDC ETL 分析アーキテクチャを示しています。Debezium や Canal などのツールで CDC データを収集してメッセージキューに書き込み、計算エンジンでデータの計算とクリーニングを行い、最終的にダウンストリームストレージに送信して、リアルタイムデータウェアハウスとデータレイクを構築します。

従来の CDC ETL 分析では、Debezium や Canal などの多くのコンポーネントをデプロイ・保守する必要があり、Kafka メッセージキュークラスターも保守する必要があります。Debezium の欠点は、全量・増分統合をサポートしているものの、単一並行モデルのため大規模データシナリオに十分対応できないことです。一方、Canal は増分読み取りのみが可能で、全量読み取りには DataX や Sqoop との連携が必要です。つまり、2 つの別々の処理パイプラインを維持する必要があり、管理すべきコンポーネントも増加します。したがって、従来の CDC ETL 分析の課題は、単一並行処理性能の限界、全量・増分処理の分離、そして依存コンポーネントの多さです。

3. Flink CDC に基づく大規模データのリアルタイム同期と変換

Flink CDC ソリューションは、大規模データのリアルタイム同期と変換にどのような改善をもたらすのでしょうか。

Flink CDC 2.0 は MySQL CDC の増分スナップショット読み取りアルゴリズムを実装しました。最新バージョン 2.2 では、Flink CDC コミュニティが増分スナップショットアルゴリズムをフレームワークとして抽象化し、他のデータソースでも増分スナップショットアルゴリズムを再利用できるようになりました。

増分スナップショットアルゴリズムは、全量・増分統合同期におけるいくつかの課題を解決します。たとえば、Debezium の初期バージョンは全量・増分統合同期の実装にロックを使用し、単一并行モデルで障害時の再実行機構があったため、全量フェーズでのレジュームを実装できませんでした。増分スナップショットアルゴリズムはロックフリーアルゴリズムを採用しており、ビジネステーブルへの影響が非常に少ないです。並列読み取りをサポートしており、大規模データの処理問題を解決します。ブレークポイントからの再開をサポートし、障害時の再実行を回避して、データ同期の効率とユーザー体験を大幅に向上させることができます。

前述の図は全量・増分統合フレームワークを示しています。簡単に言うと、このフレームワークはデータベース内のテーブルをプライマリキーまたはユニークキーに基づいてチャンクに分割し、複数のタスクに割り当てて並列読み取りを実現します。つまり、全量フェーズで並列読み取りが実現されます。全量と増分の自動切り替えをサポートし、ロックフリーアルゴリズムを使用してロックフリーかつ整合性のある切り替えを行います。増分フェーズに切り替えた後、増分部分のデータ解析を担当する単一のタスクのみが必要となり、全増分の統合読み取りを実現します。増分フェーズに入った後、ユーザーはジョブを修正して、ジョブで不要になったリソースを解放できます。

全量・増分統合フレームワークと Debezium 1.6 バージョンで、簡単な TPC-DS 読み取りテストを比較しました。顧客の単一テーブルデータ量が 6,500 万件の場合、Flink CDC で 8 並行を使用すると、スループットは 6.8 倍に向上し、処理時間はわずか 13 分です。これは並列読み取りのサポートによるもので、より高速な読み取り速度が必要な場合、ユーザーは並行数を増やして実装できます。

Flink CDC の設計では、ストレージに優しい書き込み設計も考慮されています。Flink CDC 1.x バージョンでは、exactly-once 同期を実現するために Flink が提供するチェックポイント機構と連携する必要がありました。全量フェーズでチャンク分割を行わない場合、1 つのチェックポイントで完了する必要があります。これにより問題が発生します。各チェックポイントでこのテーブルの全量データをダウンストリームライターに出力する必要があり、ライターはこのテーブルの全量データをメモリに保持するため、メモリに大きな負荷がかかり、ジョブの安定性が特に低下します。

Flink CDC 2.0 で増分スナップショットアルゴリズムを提案した後、チャンク分割によりチェックポイントの粒度をチャンク単位に細かくできます。チャンクサイズはユーザーが設定可能で、デフォルトは 8,096 です。ユーザーはより小さな値に調整することで、ライターの負荷を軽減し、メモリリソースの使用を削減して、ダウンストリームストレージへの書き込み安定性を向上させることができます。

全量・増分統合後、Flink CDC のデータレイク取り込みアーキテクチャは、ビジネスの安定性に影響を与えることなく非常にシンプルになります。分単位の出力が可能なので、ニアリアルタイムまたはリアルタイム分析が実現できます。並列読み取りにより高いスループットを達成し、大規模データシナリオで優れたパフォーマンスを発揮します。リンクが短く、コンポーネントが少なく、運用保守に優しい設計です。

Flink CDC の登場により、従来の CDC ETL 分析の課題も大幅に改善されました。Canal や Kafka メッセージキューなどのコンポーネントは不要になり、Flink だけに依存して全量・増分統合同期とリアルタイム ETL 処理を実現できます。そして、並列読み取りをサポートしており、アーキテクチャ全体としてリンクが短く、コンポーネントが少なく、保守が容易です。

Flink DataStream API と使いやすい SQL API に依存して、Flink CDC は非常に強力で包括的なデータ変換機能を提供し、変換プロセス中の changelog セマンティクスも保証します。従来のソリューションでは、changelog に対して変換を実行し、changelog のセマンティクスを保証することは非常に困難でした。

大規模データのリアルタイム同期と変換の例 1: Flink CDC による異種データソースの統合実現

このビジネスシナリオでは、製品テーブルや注文テーブルなどのビジネステーブルが MySQL データベースに保存され、物流テーブルが PostgreSQL データベースに保存されています。統合プロセス中に異種データソースの統合とワイドテーブル化を実現する必要があります。製品テーブル、注文テーブル、物流テーブルに対してストリーミングジョインを実行し、結果テーブルをライティングする必要があります。Flink CDC を使用すると、わずか 5 行の Flink SQL でこのプロセス全体を実現できます。ここで使用するダウンストリームストレージは Hudi で、リンク全体で分単位またはそれ以下のレイテンシで出力を得ることができ、Hudi を中心としたニアリアルタイム分析が可能になります。

大規模データのリアルタイム同期と変換の例 2: Flink CDC によるシャーディング（分庫分表）統合の実現

Flink CDC はシャーディングに対して非常に充実したサポートを提供しています。CDC テーブルを宣言する際、正規表現を使用してデータベース名やテーブル名をマッチングできます。正規表現により、複数のデータベースとそれらの下の複数のテーブルをマッチングできます。同時に、メタデータカラムのサポートを提供しています。データがどのデータベースとテーブルから来ているかを確認できます。ダウンストリームの Hudi に書き込む際、メタデータで宣言された 2 つのカラムを持ち込み、元のテーブルのプライマリキー（例: id カラム）と組み合わせて新しいプライマリキーとして使用することで、わずか 3 行の Flink SQL でシャーディングデータのリアルタイム統合が実現でき、非常にシンプルです。

Flink の豊富なエコシステムに依存して、多くのアップストリーム・ダウンストリームの拡張を実現できます。Flink 自体が豊富なコネクタエコシステムを持っており、Flink CDC の追加により、アップストリームではより豊富なソースの取り込みが可能になり、ダウンストリームではより豊富な宛先への書き込みが可能になります。

大規模データのリアルタイム同期と変換の例 3: 3 行の SQL で単品商品の累積販売ランキングをリアルタイム実現

このデモでは、3 行の SQL で依存関係なしに製品のリアルタイムランキングを実現します。まず、Docker で MySQL と ElasticSearch のイメージを追加します。ElasticSearch が出力先です。Docker を起動した後、Flink パッケージと MySQL CDC 用および ElasticSearch 用の 2 つの SQL Connector jar をダウンロードします。Flink クラスターと SQL Client を起動します。MySQL の組み込みライブラリにテーブルを作成し、データを投入します。更新後、Flink SQL でリアルタイム処理・分析を行い、ES に書き込みます。MySQL データベースに注文テーブルを作成し、データを挿入します。

前述の図の 1 行目の SQL は注文テーブルの作成、2 行目は結果テーブルの作成、3 行目は group by クエリを実行してリアルタイムランキング機能を実現し、2 行目の SQL で作成した ElasticSearch テーブルに書き込みます。

ElasticSearch で可視化を行いました。MySQL の注文が継続的に更新されるにつれて、ElasticSearch のランキングリストがリアルタイムで更新されることがわかります。

4. Flink CDC コミュニティの発展

過去 1 年ほどで、コミュニティは 4 つのメジャーバージョンをリリースし、貢献者とコミット数は継続的に増加しており、コミュニティはますます活発になっています。私たちは常に、MySQL の数十億規模の大規模テーブル、増分スナップショットフレームワーク、MySQL の動的テーブル追加などの高度な機能を含む、すべてのコア機能をコミュニティエディションに提供することに注力してきました。

最新の 2.2 バージョンでも多くの新機能が追加されています。まず、データソースとして OceanBase、PolarDB-X、SqlServer、TiDB がサポートされました。さらに、Flink CDC のエコシステムは継続的に充実しており、Flink 1.13 および 1.14 クラスターとの互換性、増分スナップショット読み取りフレームワークの提供があります。また、MySQL CDC の動的テーブル追加をサポートし、MongoDB も改善されました。たとえば、指定コレクションのサポートや、正規表現による柔軟で使いやすい設定が可能になっています。

さらに、ドキュメントはコミュニティにとって特に重要な部分です。独立したバージョン管理コミュニティサイトを提供しており、異なるバージョンが異なるバージョンのドキュメントに対応し、中国語と英語の豊富なデモと FAQ を提供して、初心者がすぐに始められるようサポートしています。


コミュニティの主要な指標、たとえば issue 作成数、PR マージ数、GitHub Stars 数などで、Flink CDC コミュニティは非常に優れたパフォーマンスを発揮しています。

Flink CDC コミュニティの今後の計画は、主に以下の 3 つの側面を含みます。

すべてのデータベースが将来的により優れたフレームワークに接続されることを期待しています。Schema Evolution とデータベース全体の同期についていくつかの探索的な作業を行っており、成熟次第コミュニティに公開する予定です。

エコシステムの統合: より多くのデータベースとバージョンを提供します。データレイクとの統合はよりスムーズなリンクを期待できます。エンドツーエンドのソリューションを提供し、ユーザーは Hudi や Flink CDC のパラメータを気にする必要がなくなります。

使いやすさ: よりすぐに使える体験を提供し、ドキュメントとチュートリアルを充実させます