如何基于Flink CDC与OceanBase构建实时数仓，实现简化链路，高效排查

本文作者：阿里云Flink SQL负责人，伍翀，Apache Flink PMC Member & Committer

众多数据领域的专业人士都很熟悉Apache Flink，它作为流式计算引擎，流批一体，其核心在于其强大的分布式流数据处理能力，同时巧妙地融合了流计算与批计算的能力，因此成为了众多企业在进行流式计算业务时的首选。

接下来，本文将探讨Flink CDC与Apache Flink之间的关联与差异。更重要的是，我们将如何巧妙地将Flink CDC与OceanBase数据库相结合，构建一个实时数据仓库系统。

Flink CDC和Apache Flink是什么关系？

从功能上来讲，Flink在批处理能力外，还能够实时读取数据源，进行数据加工，数据打宽和数据聚合，以及下游的存储、分析、服务。Flink CDC是基于Flink流式计算引擎构建的一个实时数据同步和处理的框架。目前，得益于日志变更技术（Change Data Capture），Flink CDC已经支持了十来种常见的数据库，比如MySQL、MongoDB、OceanBase等，在将数据实时同步至数据仓库或数据湖时，还能够实时进行数据加工、数据聚合、数据打宽等。

两个场景说明Flink CDC的由来

为什么会出现Flink CDC？下面以两个场景举例说明。

场景一：数据入仓。

传统的数据入仓方式，我们要通过数据同步工具将数据同步到数仓中分析，比如，使用DataX对业务数据库进行以天为单位的定时全量数据同步，但这种方式有几个比较明显的缺点。

首先，全量数据同步可能会对在线业务造成一定影响；其次，天级别的产出，可能无法满足下游业务的实时性需求。另外，随着数据量的不断增长，数据同步工具的性能瓶颈会越来越明显，比如同步的延时，以及对业务的影响。

很多应用方会在数据同步的基础上增设增量数据的同步，也就是我们常说的Lambda架构，常见的技术方案是采用Canal同步数据库增量数据到Kafka，再通过其他的处理框架将数据实时同步到新的数据库如OceanBase。这种架构虽然减少了对在线业务的影响，但引入了更多的组件，使同步链路变得更长。同时，手动管理全量和增量数据链路的切换也可能导致数据出现问题。

Flink CDC的出现很好地解决了上述问题，它能够一体化地支持全量数据和增量数据的读取，并且是在用户无感知的情况下自动发生的。在不影响业务稳定性的前提下，保证了实时流式传输与毫秒级数据更新。对于全量数据和增量数据的切换，Flink CDC能够保证数据的一致性，用户不用再担心数据丢失的问题。另外，从同步链路而言，需要维护的组件更少，降低了用户的维护成本与故障排查成本。

场景二：ETL数据分析

传统的数据分析链路是把业务数据，通过中间件同步到Canal，再使用Kafka对数据进行加工、计算。这种方案难以保证数据的一致性，其关键在于 Canal组件只支持同步增量数据，不支持同步历史数据。而数据的聚合统计等分析操作如果没有历史数据支撑，那么分析的结果也是有缺失的。

如果使用基于 Flink CDC 的 ETL 数据分析链路，就可以用Flink CDC简单替换如Canal和Kafka的组件。例如，我们现在需要将MySQL和 Postgres的表进行实时关联，再写入OceanBase。我们只需要用Flink CDC写三段SQL：一是定义MySQL实时订单表；二是定义Postgres实时产品表；三是定义Oceanbase结果表。然后用Flink的 Join 语法，实时关联订单和产品数据，并INSERT INTO 到OceanBase的结果表当中，就完成了两张表的实时打宽和关联。整个过程实时地将MySQL和 Postgres的全量数据和增量数据读出来，进行一致性关联后实时写入OceanBase。

Flink CDC的四个核心技术

上述两个场景中提到的功能，涉及FlinkCDC四个核心技术：

• 全增量一体化读取技术
• 动态表（Dynamic Table）
• 连续查询（Continuous Query）
• Changelog Mechanism

1. 全增量一体化的读取技术。

旧版本Flink CDC的数据库变更读取能力是基于 Debezium 实现的。Debezium 是一个类似于 Canal 的捕获数据库变更数据的类库，该类库提供了全量增量数据的一致性读取。但是该类库有两个核心问题。第一，Debezium使用了数据库的全局锁来保证全量数据和增量数据的一致性，但全局锁会导致数据无法写入，对在线业务造成影响。第二，Debezium只支持单并发读取，当海量数据要入仓时，耗时较长。如果全量数据同步失败，还需要进行重新读取，这会进一步拉长同步耗时。这非常影响系统的稳定性。

针对这些问题，我们在2.0版本迭代时提出了增量快照读取算法。第一，采用增量快照读取算法，无需加锁就能保证全量数据到增量数据的一致性，对业务影响降到最低。第二，将大表切片，切片之间可以并行读取，大幅提升海量数据入仓效率。最后，系统会追踪切片的读取进度，支持按照切片的粒度进行失败回滚，而无需全表重新读取，提升了大规模数据同步场景的稳定性。

2. 动态表（Dynamic Table）。

在读取端将CDC数据读取进来后，我们面对的问题是如何对它进行一致性的处理加工，此处就涉及Flink CDC的第二个核心技术——动态表。

一枚硬币有两面，数据库领域也是如此。动态表意味着数据会随着时间变化，我们在观测动态表时，表的所有变更都是数据流，流和动态表是同一事物的二象性。我们将变更流物化，就得到了一个动态表。我们去观测动态表上的变化，就得到了一个变更流。

3. 连续查询（Continuous Query）。

连续查询和动态表是相辅相成的，当我们在动态表上定义连续查询，就会得到一个新的动态表。这从物理层面而言，产生了一段持续的CDC的流，这条流又可以通过下一个连续查询进行处理和加工，再产生新的动态表，从而编织起一个有分层的流式数仓。

4. Changelog Mechanism。

业界有很多支持流处理的框架，但大多不支持处理CDC的数据，关键原因在于缺乏完整的Changelog数据处理机制。

什么是Changelog数据处理机制？举个例子，现在有一个单词的数据源，我们要对每个单词进行聚合，并且对获取到的词频再进行聚合。比如单词是Hello和World，经统计，我们得到Hello出现一次，World也出现一次，那么词频为1的单词有两个（即[cnt=1, freq=2]）。这时，数据源中又出现一个Hello，那么Hello就出现了两次，第一个聚合节点会输出一条Hello=2的更新，经过词频聚合后，会输出词频为2的单词有1个（即[cnt=2, freq=1]）。但这是结果表中的[cnt=1, freq=2]是错误的。词频为1的单词少了一个（Hello词频从2变成了1），所以cnt=2对应的freq应该为1才对。

因此，我们引入数据处理机制修正错误结果，最终得到正确结果：[cnt=1，freq=1]。当Hello的出现次数从一次变成两次，我们会像传统数据库一样输出一个完整的更新前镜像和后镜像，也就是先输出旧数据的撤回消息-[Helo, 1]，再输出新数据的新增消息+[Hello, 2]。撤回消息在到达聚合节点后，就会对cnt=1的 freq 做减一操作，得到[cnt=1, freq=1]。新增消息会对cnt=2的freq做加一操作，得到[cnt=2,freq=1]。可以看到该结果与批处理的结果一致。通过这种方式，能够保证CDC流处理语义的一致性。Changelog数据处理机制是保证 Streaming SQL 结果正确的关键机制，不需要用户感知，因为优化器会自动判断是否要输出和处理撤回消息（update_before）。

如何基于Flink CDC与OceanBase构建实时数仓？

基于上文Flink CDC的四个核心能力，结合OceanBase，可以构建一个实时的数据仓库，具体怎么做，我们不妨先来了解传统的实时数仓方案。

传统的实时数据仓库基于流式队列方案构建，我们称之为Streaming MQ方案，是目前业界最典型、应用最广泛的方案。将MySQL的数据源同步到Kafka，构建一个ODS数据层，再进行数据打宽、数据清洗，变为DWD的数据层，然后进行聚合，形成一个ADS数据层，最后做数据加工，放进KV层供下游进行消费查询。由于整个过程中数据不可被分析，所以还会将数据同步到分析型数仓。

Streaming MQ方案的优势在于实践经验非常丰富，层次分明，每一个组件的分工明确。但它的劣势也比较明显，比如链路复杂、数据冗余，由于涉及组件较多，排查问题时也非常困难。

因此，我们开始尝试新的构建方案——Streaming OLAP方案，既拥有流式队列的能力，又具备OLAP的处理、分析、查询能力。这一方面基于Flink CDC的核心技术，另一方面得益于OceanBase行列混存的HTAP特性，可以在一套系统中支持交易处理和复杂查询分析的能力。

举个例子，我们通过Flink CDC，把MySQL的全量数据和增量数据同步到OceanBase，形成一个ODS数据层供下游订阅。订阅的同时读取数据做加工和打宽，然后写入下游的OceanBase形成DWD数据层，通过聚合形成DWS数据层，此时就可以为用户提供查询服务和消费提供。

Streaming OLAP方案的优势显而易见，一是避免了Streaming MQ方案的数据冗余问题，不需要再维护一个实时数仓，数据可复用，模型统一，架构简单。二是简化了链路，OceanBase替代了KV服务、分析服务、Kafka等组件。三是解决了排查困难的问题，因为OceanBase每一层都是可查、可更新、可修正的，比如，某一层的数据出现问题，可以直接排查该层的表数据并进行修正，排查更高效。

该套实时数仓方案依赖于两项关键能力：OceanBase的CDC读取能力、OceanBase的CDC写入能力。

1.OceanBase CDC读取的实现机制。

对于全量数据的同步，因为OceanBase兼容MySQL，所以我们可以基于JDBC完成全量数据的读取；增量数据读取方面，基于oblogproxy捕获binlog数据，在数据源，可以通过logproxy-client 订阅 oblogproxy 获取增量数据。因为OceanBase暂时不支持表锁，也不支持行级的binlog位点，所以在全量和增量切换时，只能保证at-least-once读取。也就是说在切换的过程中会多读取数据，不过，Flink 会自动去重，保证最终数据不重复、不丢失。

2.OceanBase CDC写入的实现机制。

由于OceanBase 兼容 MySQL 协议，支持 MySQL 5.6和MySQL 5.7 的绝大多数语法，因此在许多场景下可以将其视作 MySQL 使用，比如，作为 Flink 的目的端数据库，可使用 flink-jdbc-connector 基于 MySQL 协议来写入，支持插入、更新和删除。

OceanBase CDC的读取和写入将整个实时数仓多层之间的数据进行了流式串联。举个例子，我们需要对订单明细表进行聚合，写入DWS层的统计表中。获取每个店铺每天的销售量。只需要三段SQL就可以完成。

第一段命令是定义一个OceanBase CDC的数据源，他是一个来自于orders的表，有这样的一些字段。

第二，使用FlinkCDC统计店铺销售额，将JDBC的表写入OceanBase的表中，形成了店铺指标的统计层。

第三段命令实时读取订单明细层（dwd_orders）的全量数据和增量数据，并进行实时聚合、加工，写入下游的OceanBase中（dws_shops）。该 dwd_shops 表又可以由另一个Flink进行读取，再加工，形成下一层的结果表。从而构建起整个流式数仓的分层概念。

Flink 与 Oceanbase 将全面集成

目前，Flink与数据源之间的集成，主要分成四个维度：源表、维表、结果表、元数据。

在与OceanBase的集成中：

• 源表支持全量数据的读取、增量数据的读取，以及全增量一体化的读取，下一步我们希望支持Exactly-Once 的读取。
• 数据处理和加工过程中最常见的动作是数据补全和数据打宽，在这方面，OceanBase下一步可以作为维表供Flink远程查询。
• 在结果表方面，目前支持数据的实时写入和更新，还有宽表Merge。下一步我们计划支持DDL的实时变更同步及整库的数据同步。
• 在元数据方面，OceanBase将对接Flink Catalog接口。用户填写OceanBase的地址及鉴权信息，OceanBase所有的库表都可以进行实时写入和查询，无需手动定义DDL。

通过这四个维度的集成，Flink结合OceanBase可以打造一站式的实时数仓体验，未来，Flink希望与OceanBase更进一步，进行全面集成。