基于 EMR OLAP 的开源实时数仓解决方案之 ClickHouse 事务实现

内容框架

背景
机制梳理
技术方案
测试结果
未来规划

一、背景

Flink 和 ClickHouse 分别是实时流式计算和 OLAP 领域的翘楚，很多互联网、广告、游戏等客户都将两者联合使用于构建用户画像、实时 BI 报表、应用监控指标查询、监控等业务，形成了实时数仓解决方案（如图-1）。这些业务对数据的准确性要求都十分严格，所以实时数仓整个链路需要保证端到端的 Exactly-Once。

通常来说 Flink 的上游是可以重复读取或者消费的 pull-based 持久化存储（例如Kafka），要实现 Source 端的 Exactly-Once 只需要回溯 Source 端的读取进度即可。Sink 端的 Exactly-Once 则比较复杂，因为 Sink 是 push-based 的，需要依赖目标输出系统的事务保证，但社区 ClickHouse 对事务并不支持。

所以针对此情况，阿里云 EMR ClickHouse 与 Flink 团队一起深度研发，支持了 Flink 到 ClickHouse 的 Exactly-Once写入来保证整个实时数仓数据的准确性。本文将分别介绍下现有机制以及实现方案。

图-1 实时数仓架构

二 机制梳理

ClickHouse 写入机制

ClickHouse 是一个 MPP 架构的列式 OLAP 系统（如图-2），各个节点是对等的，通过 Zookeeper 协同数据，可以通过并发对各个节点写本地表的方式进行大批量的数据导入。

ClickHouse 的 data part 是数据存储的最小单元，ClickHouse 接收到的数据 Block 在写入时，会按照 partition 粒度进行拆分，形成一个或多个 data part。data part 在写入磁盘后，会通过后台merge线程不断的合并，将小块的 data part 合并成大块的 data part，以此降低存储和读取的开销。

在向本地表写入数据时，ClickHouse 首先会写入一个临时的 data part，这个临时 data part 的数据对客户端不可见，之后会直接进行 rename 操作，使这个临时 data part 成为正式 data part，此时数据对客户端可见。几乎所有的临时 data part 都会快速地成功被 rename 成正式 data part，没有被 rename 成功的临时 data part 最终将被 ClickHouse 清理策略从磁盘上删除。

通过上述分析，可以看出 ClickHouse 的数据写入有一个从临时 data part 转为正式 data part 的机制，加以修改可以符合两阶段提交协议，这是实现分布式系统中事务提交一致性的重要协议。

图-2 Flink 作业写入 ClickHouse

注：多个 Flink Task 可以写入同一个 shard 或 replica

Flink 写机制

Flink 作为一个分布式处理引擎，提供了基于事务的 Sink 机制，该机制可以保障写入的 Exactly-Once，相应的数据接收方需要提供遵守 XA 规范的 JDBC 。由于完整的 XA 规范相当复杂，因此，我们先对 Flink 的处理机制进行梳理，结合 ClickHouse 的实际情况，确定需要实现的接口范围。

为了实现分布式写入时的事务提交统一，Flink 借助了 checkpoint 机制。该机制能够周期性地将各个 Operator 中的状态生成快照并进行持久化存储。在 checkpoint 机制中，有一个 Coordinator 角色，用来协调所有 Operator 的行为。从 Operator 的角度来看，一次 checkpoint 有三个阶段，初始化-->生成快照-->