Databases 15 min read

How Flink CDC Connects to OceanBase: Architecture, Features, and Future Roadmap

This article, based on a Flink CDC Meetup talk by OceanBase expert Wang He, introduces OceanBase’s architecture and core features, explains the implementation principles of the Flink CDC OceanBase connector, outlines its current capabilities and use cases, and discusses future enhancements and roadmap.

Alibaba Cloud Developer
Alibaba Cloud Developer
Alibaba Cloud Developer
How Flink CDC Connects to OceanBase: Architecture, Features, and Future Roadmap
本文整理自 OceanBase 技术专家王赫(川粉)在 5 月 21 日 Flink CDC Meetup 的演讲。主要内容包括: OceanBase 介绍 Flink CDC OceanBase Connector 实现原理 Flink CDC + OceanBase 应用场景 Flink CDC OceanBase Connector 未来展望

OceanBase Introduction

OceanBase 是蚂蚁集团自研的分布式数据库。从 10 年开始立项并研发迭代,最早的用户是淘宝的收藏夹。14 年,OceanBase 研发团队从淘宝迁移至蚂蚁集团,主要负责支持支付宝内部的去 IOE 工作,即替换支付宝所用的 Oracle 数据库。目前,蚂蚁集团数据库已经全部迁移到 OceanBase。2021 年 6 月 1 号,OceanBase 正式对外开源,开放了 MySQL 兼容的版本。

OceanBase 数据库经历了三代架构升级,从最初应用于电商的分布式存储系统,到后面通用的分布式数据库,再到如今企业级的分布式数据库。

最上层的 App 通过 OBProxy(负载均衡代理)访问 OceanBase 数据库的 server 端, server 端的数据存在多个副本,副本之间的关系类似于数据库架构中的主从关系,但它是表级别的,即分区表的分区是以表级别为单位存在多个副本,然后打散存在于多个 server 中。

OceanBase 的架构具有以下几个特点:

无共享架构 :每个节点均有自己完整的 SQL 引擎、存储引擎和事务处理逻辑,节点之间完全对等,不存在分层结构。

分区级可用性 :提供分区级的可用性。在 OceanBase 数据库中,分区是可靠性和扩展性的基本单元,实现了访问路由、负载均衡以及自动故障恢复。

高可用 + 强一致性 :由于数据存在多个副本,多个副本之间通过 Paxos 的一致性协议来提供高可靠性,并且确保日志的持久化在多数派节点成功。

OceanBase 的核心特性有以下六点:

高可用 :基于 Paxos 协议,强一致性。少数副本故障,数据不丢,服务不停。

高扩展 :支持在线水平扩展、缩容,且各个节点之间可以自动实现负载均衡。

高兼容 :社区版提供了 MySQL 协议和语法的兼容。

低成本 :OceanBase 数据库存储的使用成本约为 MySQL 的 1/3 左右。因为其对硬件品质要求较低,且对存储进行了非常多的优化,“存储压缩比” 极致。

多租户 :租户之间的资源完全隔离,不同业务方只需在自己的租户中进行数据管理,可以节省一定的成本。

HTAP :在一套引擎中同时实现了 OLTP 和 OLAP 的功能。

Flink CDC OceanBase Connector Implementation Principles

当前主流的 CDC 实现方式主要是借助于数据库的日志,获取到数据库的增量日志之后,要确保它的有序性和完整性,再针对这些日志做处理,然后写入到目的端,比如数仓或查询引擎。

OceanBase 对于增量数据的获取提供了一些组件。因其本身是分布式数据库,那么它的数据在落到日志时也是分散状态。它提供了一个 obcdc 组件用于获取数据库日志。它会与 OceanBase server 端通过 RPC 进行交互,拉取到原始的日志信息。经过一定的处理后,可以吐出有序的日志流,下游再通过接入 obcdc 组件消费有序的日志流。

目前主要的下游消费端有三类:

oblogproxy :开源组件,消费日志流的服务, Flink CDC 依赖于此组件来实现增量的数据拉取。

OMS store :OceanBase 对外提供的数据迁移服务。商业版的 OMS 已经迭代了很多版本,支持很多数据源。去年,OMS 提供了社区版的支持,主要支持了 OceanBase 的社区版以及 MySQL 两种数据源。

JNI client :可以通过 JNI 的日志客户端直接使用 obcdc 与 OBSserver 进行交互拉取增量日志,正在开源计划中。

目前开源社区提供的 OceanBase CDC 组件主要有两个:

OceanBase Canal :Canal 是阿里巴巴对外开源的 MySQL 增量日志拉取工具。OceanBase 社区基于开源版的 Canal 最新代码,增加了对于 OceanBase 增量日志的拉取解析能力。

Flink CDC :通过 oblogproxy 使用 obcdc,从 OceanBase 拉到增量日志之后通过另外的开源组件 logproxy-client 消费增量日志,并进行处理。

Flink CDC Connector 只做对源端数据的读取,即只负责将数据从数据源读到 Flink 引擎。

当前的 Flink CDC Connector 主要分为以下三类:

MySqlSource :实现了最新的 source 接口以及并发读取。

DebeziumSourceFunction :基于 Debezium 实现了 SourceFunction,支持旧版 MySQL、Oracle、MongoDB、SqlServer、PostgreSQL。

OceanBaseSourceFunction :实现了 SourceFunction 接口,分别基于 JDBC 和 logproxy-client 实现了全量和增量读取。

增量数据首先通过 logproxy 进行拉取, logproxy-client 会监听到增量日志的数据流,数据流进入到 Flink CDC 之后通过 Flink CDC 的处理逻辑写入到 Flink。全量数据通过 JDBC 进行拉取。

当前 Flink CDC OceanBase Connector 支持的能力,主要受限于 logproxy,目前能够支持从指定时间拉取数据。但由于 OceanBase 是分布式数据库,无法精确地找到日志增量数据的起点,而通过时间戳来指定可能会存在一些重复数据。

在全量阶段,又因为 OceanBase 社区版没有表锁,因此全量数据的读取也无法通过加锁来确定数据边界。

基于以上两方面的考虑,目前暂时只支持 at-least-once 工作模式,还未实现 exactly-once。

Flink CDC + OceanBase Application Scenarios

Scenario 1: Data Integration Across Sharded Tables

Flink CDC is fully incremental and the OceanBase Connector supports regex matching of tables. For sharding scenarios, dynamic tables can be created to read source data and write into a single table for aggregation.

Scenario 2: Cross‑Cluster / Cross‑Tenant Data Integration

OceanBase is multi‑tenant; the community edition does not yet support cross‑tenant access. Multiple database connections can be used to read each tenant’s data, with each tenant represented as a dynamic table in Flink for aggregation.

Scenario 3: Integration of Multiple Data Sources

Data from MySQL‑compatible sources such as TiDB can be merged with minimal transformation cost because the data formats are identical.

Scenario 4: Building OLAP Applications

OceanBase is an HTAP database, supporting both TP and OLAP workloads. Using Flink’s JDBC connector, data read by Flink CDC can be written into OceanBase, treating it as a data warehouse.

Future Outlook for the OceanBase Connector

Future work will first optimize data reading: parallelize the full‑load phase using the new source interface’s parallel framework, and bypass logproxy for incremental reads by using the JNI client to pull data directly via obcdc.

Second, enrich functionality: extend support to the enterprise edition (incremental log components are identical), add incremental DDL handling, implement exactly‑once semantics, and introduce throttling.

Third, improve code quality: add end‑to‑end tests, replace JdbcValueConverters with a runtime converter for better performance, and support the new parallel source interface.

Q&A

Q: How usable and stable is the Flink CDC OceanBase Connector after open‑source? A: Over the past year we have added many open‑source components such as OMS and OCP. OceanBase is heavily used internally at Ant Group and the MySQL‑compatible version is deployed at more than 20 enterprises, ensuring strong stability.

Q: Where are OceanBase’s shard and index metadata stored? A: They are stored inside the OB server and can be queried directly via SQL.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Connectordistributed databaseData IntegrationFlink CDCOceanBase
Alibaba Cloud Developer
Written by

Alibaba Cloud Developer

Alibaba's official tech channel, featuring all of its technology innovations.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.