OceanBase full incremental integrated data integration solution

1. OceanBase の概要

OceanBase は Ant Group が独自に開発した分散データベースです。2010 年にプロジェクトが設立され、開発と迭代を重ねてきました。最も初期のユーザーは Taobao です。2014 年に OceanBase の開発チームは Taobao から Ant Group に異動し、主に Alipay 内部の IOE 置き換え、つまり Alipay が使用するデータベースの移行を担当しました。現在、Ant Group のデータベースはすべて OceanBase に移行済みです。2021 年 6 月 1 日、OceanBase は正式にオープンソース化され、MySQL 互換バージョンがリリースされました。

OceanBase データベースは 3 世代のアーキテクチャアップグレードを経てきました。E コマースに最初に適用された分散ストレージシステムから、汎用分散データベースを経て、現在のエンタープライズ向け分散データベースに至ります。

前述の図に OceanBase のアーキテクチャを示します。

最上位アプリは OBProxy（負荷分散エージェント）を通じて OceanBase データベースのサーバー側にアクセスします。サーバー側にはデータの複数のレプリカが存在します。レプリカ間の関係はデータベースアーキテクチャにおけるマスター・スレーブ関係に似ていますが、テーブルレベル、つまりパーティションレベルでの複製です。テーブルレベルで複数のレプリカを持ち、それらを分散させて複数のサーバーに配置します。

OceanBase のアーキテクチャには以下の特徴があります。

シェアードナッシングアーキテクチャ：各ノードは完全な SQL エンジン、ストレージエンジン、トランザクション処理ロジックを備え、ノード間は完全にピアツーピアで階層構造がありません。
パーティションレベルの可用性：パーティションレベルの可用性を提供します。OceanBase データベースでは、パーティションは信頼性とスケーラビリティの基本単位であり、アクセスルーティング、負荷分散、自動障害回復を実現します。
高可用性 + 強整合性：データの複数のレプリカが存在するため、Paxos プロトコルを使用してレプリカ間の高信頼性を提供し、多数派ノードでのログ永続化の成功を保証します。

OceanBase には以下の 6 つのコア機能があります。

高可用性：Paxos プロトコルに基づく強整合性。少数のレプリカに障害が発生しても、データは失われず、サービスは継続します。
高スケーラビリティ：オンラインでの水平拡張・縮小、ノード間の自動負荷分散をサポートします。
高互換性：Community Edition は MySQL プロトコルおよび構文との互換性を提供します。
低コスト：OceanBase データベースのストレージコストは MySQL の約 1/3 です。ハードウェア品質への要求が低く、ストレージを大幅に最適化しているため、「ストレージ圧縮率」が非常に高くなっています。
マルチテナント：テナント間のリソースは完全に分離されており、各ビジネス部門は自身のテナント内のデータのみを管理すればよく、一定のコスト削減が可能です。
HTAP：単一のエンジンで OLTP と OLAP の両機能を実現します。

2. Flink CDC OceanBase Connector の実装原理

現在の主流な CDC 実装方法は、主にデータベースログに依存しています。データベースの増分ログを取得した後、その順序性と完全性を保証し、これらのログを処理してから、データウェアハウスやクエリエンジンなどの宛先に書き込みます。

OceanBase は増分データ取得用のコンポーネントを提供しています。分散データベースであるため、データはログに書き込まれる際にも分散されています。obcdc コンポーネントを使用してデータベースログを取得します。RPC で OceanBase サーバーと通信し、元のログ情報をプルします。一定の処理を経て、順序付きのログストリームを出力し、ダウンストリームは obcdc コンポーネントにアクセスして順序付きログストリームを消費できます。

現在、ダウンストリームのコンシューマーは主に 3 種類あります。

oblogproxy：オープンソースコンポーネントで、ログストリームを消費するサービスです。Flink CDC はこのコンポーネントを利用して増分データのプルを実現します。
OMS store：OceanBase が提供するデータ移行サービスです。OMS の商用版は多くのバージョンを重ね、多数のデータソースをサポートしています。昨年、OMS は Community Edition のサポートを提供し、主に OceanBase Community Edition と MySQL の 2 つのデータソースに対応しています。
JNI クライアント：JNI ログクライアントを通じて obcdc を直接使用して OBServer と通信し、増分ログをプルできます。オープンソース化の計画に含まれています。

現在、オープンソースコミュニティが提供する OceanBase CDC のコンポーネントは主に 2 つあります。

OceanBase Canal：Canal は Alibaba がリリースしたオープンソースの MySQL 増分ログプルツールです。Canal のオープンソース版の最新コードに基づき、OceanBase コミュニティは OceanBase の増分ログをプルして解析する機能を追加しました。
Flink CDC：oblogproxy を通じて obcdc を使用し、OceanBase から増分ログをプルし、別のオープンソースコンポーネントである logproxy-client を通じて増分ログを消費して処理します。

前述の図の左下には動的テーブルの定義があります。データフローは Flink 内で動的テーブル形式のテーブルに変換されます。テーブルに変換して初めて SQL 操作を実行できます。その後、Continuous Queries が継続的に増加するストリームテーブルをクエリし、取得したデータは引き続きテーブル構造で、その後ストリームデータに変換されてダウンストリームに送信されます。

Flink CDC Connector はソースデータの読み取りのみを行います。つまり、データソースから Flink エンジンへのデータ読み取りにのみ責任を持ちます。

現在の Flink CDC Connector は主に以下の 3 つのカテゴリに分かれています。

MySqlSource：最新のソースインターフェースと並行読み取りを実装します。
DebeziumSourceFunction：Debezium に基づいて SourceFunction を実装し、旧バージョンの MySQL、MongoDB、SQL Server、PostgreSQL をサポートします。
OceanBaseSourceFunction：SourceFunction インターフェースを実装し、JDBC と logproxy-client にそれぞれに基づいて全量および増分読み取りを実装します。

増分データはまず logproxy を通じてプルされ、logproxy-client が増分ログのデータフローを監視します。データフローが Flink CDC に入ると、Flink CDC の処理ロジックを通じて Flink に書き込まれます。全量データは JDBC を通じてプルされます。

Flink CDC OceanBase Connector が現在サポートする機能は、主に logproxy の制限に依存します。現在、指定された時刻からのデータプルをサポートしています。ただし、OceanBase は分散データベースであるため、ログ増分データの開始点を正確に特定できず、タイムスタンプ指定時に一部の重複データが発生する可能性があります。

全量ステージでは、OceanBase Community Edition にはテーブルロックがないため、全量データの読み取り時にロックをかけてデータ境界を確定できません。

上記 2 つの考慮事項に基づき、現在 At-Least-Once の動作モードのみをサポートしており、Exactly-Once はまだ実装されていません。

3. Flink CDC + OceanBase のアプリケーションシナリオ

3.1 シナリオ 1：シャーディングに基づくデータ統合
Flink CDC は全量増分一体型統合であり、OceanBase Connector はデータテーブルの読み取りに正規表現マッチングをサポートしています。シャーディングのシナリオでは、OceanBase Connector を通じて動的テーブルを作成し、データソースのデータを読み取ってから 1 つのテーブルに書き込むことで、テーブルデータの集約を実現できます。

3.2 シナリオ 2：クラスター / テナント間のデータ統合
OceanBase はマルチテナントシステムです。現在、Community Edition の MySQL テナントではクロステナントアクセスが実現されていません。そのため、クロステナントデータを読み取るには、複数のデータベースに個別に接続して読み取る必要があります。Flink CDC はこの用途に自然に適しており、各テナントに対応する動的テーブルをデータソース読み取りのチャネルとして、Flink 内で集約できます。


3.3 シナリオ 3：複数データソースのデータ統合
異なるタイプのデータソース間でデータ集約を実行できます。MySQL プロトコルに互換性のあるデータソース（MySQL や TiDB など）の統合は、データ形式が同じであるため、基本的に変更コストはありません。

3.4 シナリオ 4：OLAP アプリケーションの構築
OceanBase は HTAP データベースであり、強力な TP 機能を備えるだけでなく、データウェアハウスとしても使用できます。Flink の JDBC コネクタは MySQL プロトコルに互換性のあるデータベースへのデータ書き込みをサポートしています。したがって、Flink CDC を使用してソースデータを読み取り、Flink JDBC コネクタを通じてこれらのデータを OceanBase に書き込み、OceanBase を宛先として使用できます。

現在、OceanBase は SQL、Table API、HBase API の 3 つのデータ利用方法を提供しており、すべての利用方法に必要なコンポーネントはオープンソースです。

4. OceanBase Connector の将来展望

前述の図に OceanBase CDC ソリューションの現状を示します。

OMS Community Edition：OMS Commercial Edition の機能サブセットですが、オープンソースではありません。GUI ツールとしてユーザーフレンドリーで、全量増分一体型統合を備え、データ検証および運用・保守機能を備えています。欠点はデプロイプロセスがやや煩雑なことです。MySQL と OceanBase Community Edition の 2 つのデータソースのみをサポートし、増分 DDL には対応していません。

DataX + Canal/Otter：DataX + Canal/Otter を使用したデータ移行のオープンソースソリューションです。Otter は Canal の親プロジェクトで、主にリモートマルチアクティブを対象とし、双方向データ同期をサポートします。増分データの読み取りは Canal に基づいています。このソリューションの利点は、多様な宛先をサポートし、HBase、ES、リレーショナルデータベース RDB に対応している点です。欠点は Canal と Otter が増分を担当し、DataX が全量を担当するため、増分と全量の分離方法が比較的断片的であり、接続部分にデータ冗長性が生じることです。

Flink CDC：純粋なオープンソースソリューションで、アクティブなコミュニティと急速に成長するコミュニティユーザーを持ち、マルチソース・マルチ宛先、全量増分一体型統合をサポートしています。また、Flink は非常に優れたビッグデータ処理エンジンとして ETL を実行できます。欠点は OceanBase Connector が現在増分 DDL をサポートしておらず、Exactly-Once を実装していないため、増分と全量のオーバーラップ部分にデータ冗長性が生じる可能性があることです。

将来的には、まずデータ読み取りの最適化を行います。全量部分はソースインターフェースの新しい並列処理フレームワークを使用して並列化し、増分部分は logproxy サービスをスキップして OceanBase データベースから直接増分データをプルします。つまり、obcdc コンポーネントを使用して JNI クライアントを通じて直接データをプルします。

次に、機能強化を図ります。現在 Flink CDC は OceanBase の Community Edition のみをサポートしていますが、OceanBase Community Edition と Enterprise 版は増分ログ読み取りで全く同じコンポーネントを使用しているため、わずかな変更で Enterprise 版の増分読み取りをサポートできます。増分 DDL、Exactly-Once モード、レート制限もサポートする予定です。

最後に、コード品質の向上を図ります。まず、エンドツーエンドテストを追加します。フォーマット変換部分では、パフォーマンス向上のため JdbcValueConverters の代わりにランタイムコンバーターを使用します。新しいバージョンのソースインターフェース（並列処理フレームワーク）のサポートも実装されます。