StarRocks × Apache Flink：如何构建简单强大的实时数仓架构

在传统的实时数仓建设中，数据采集工具是不可或缺的。由于上游的数据源不一致，通常来说我们可能会在数据采集层接入不同的同步与采集工具，比如采集 Oracle 中的数据时，我们通常选择 GoldenGate，而对于 MySQL，我们可能会选择 Canal 或 Debezium。有些采集工具支持全量数据同步，有些支持增量数据同步。数据经过采集层后，会传输到消息队列中如 Apache Kafka（下文简称“Kafka”），然后通过 Flink 消费 Kafka 中的增量数据再写入下游的 OLAP 数据仓库或者数据湖中。

在业务开发中，上游的数据源、消息中间件、Flink 以及下游的分析性数据仓库通常在不同的部门进行维护。遇到业务变更或者故障调试时，可能需要多个部门协作处理，增加了业务开发与测试的难度。通过使用 Flink CDC 替换上图中的数据采集组件与消息队列，将虚线框中的采集组件与消息队列合并到计算层 Flink 中，从而简化数据链路，降低维护成本。同时更少的组件也意味着更少的故障与传输瓶颈，数据实效性会进一步提高。

在使用 Flink CDC 之后，数据链路中的组件变得更少，架构变得清晰简单，维护变得更方便。如在上面的例子中，我们使用 Flink CDC 拉取 MySQL 中的增量数据，通过 Flink SQL 创建事实与维度的 MySQL CDC 表，并在 Flink 中进行打宽操作，将结果写入到下游的 StarRocks 中。通过一个 Flink CDC 作业就可以完成抓取、转换、装载的全过程。 

StarRocks，让实时数据更新成为可能

—

StarRocks 在 1.19 版本推出了主键模型（Primary Key model）。主键模型可以更好地支持实时更新等场景。主键模型要求表有唯一的主键（传统 OLTP 数据库中的 Primary Key），支持对表中的行按主键进行更新和删除操作。

在 OLAP 数据仓库中，可变数据通常是不受欢迎的。在传统数仓中，一般我们会使用批量更新的方式处理大量数据变更的场景。对于数据的变更我们有两种方法处理：

• 在新的分区中插入修改后的数据，通过分区交换完成数据变更。

• 部分 OLAP 数据仓库产品提供了基于 Merge on Read 模型的更新功能，完成数据变更。

分区交换数据更新模式

对于大部分的 OLAP 数据仓库产品，我们可以通过操作分区的方式，将原有的分区删除掉，然后用新的分区代替，从而实现对大量数据的变更操作。通过交换分区来实现大规模数据变更是一个相对较重的操作，适用于低频的批量数据更新。由于涉及到了表定义的变更，一般来说开发人员无法通过该方案独立完成数据变更。

Merge on Read 数据更新模式

Merge on Read 模式在写入时简单高效，但读取时会消耗大量的资源在版本合并上，同时由于 Merge 算子的存在，使得谓词无法下推、索引无法使用，严重影响了查询的性能。部分的 OLAP 数据仓库提供了基于 Merge on Read 的数据变更模型，如 ClickHouse 提供了 MergeTree 引擎， 可以完成异步更新，但无法做到数据实时同步。在指定 FINAL 关键字后，ClickHouse 会在返回结果之前完成合并，从而实现准实时的数据更新同步操作。但由于 FINAL 操作高昂的代价，会导致查询性能下降非常大，不足以支撑实时数仓带来的维度实时更新需求。

StarRocks 也提供了与 ClickHouse Merge Tree 类似的更新模型：Unique Key model。通过使用 Unique Key model，我们以 Merge on Read 的模式完成数据变更。在 StarRocks 存储内部会给每一个批次导入的数据分配一个版本号，同一主键的数据可能有多个版本，在执行查询时实时进行版本合并。Merge on Read 的更新模式牺牲了一部分的查询性能，由此 StarRocks 推出了更适合高频数据变更的 Primary Key model，以 Delete and Insert 的模型完成数据的实时变更。

StarRocks 提供了基于 Delete and Insert 模式的主键模型，避免了因为版本合并导致的算子无法下推的问题。主键模型适合需要对数据进行实时更新的场景，可以更好地解决行级别的更新操作，支撑百万级别的 TPS，特别适合 MySQL 或其他业务库同步到 StarRocks 的场景。

在 TPCH 标准测试集中，我们选取了部分的查询进行对比，基于 Delete and Insert 模式的主键模型相较于基于 Merge on Read 的 Unique Key 模型，性能有 3-5 倍以上的提高：

在某些复杂的业务，如自助 BI 报表、运营分析等场景中，分析师往往会从不同的维度进行数据探查，大宽表模型无法支持大量的维度，以及维度数据变更需要重刷大宽表代价巨大。星型模型可以很好支持查询的灵活性要求，以满足使用者“随意”在页面上拉去指标和维度、下钻、上卷和关联查询，也可以很好支持对维度数据进行变更。

StarRocks 提供了不同的 Join 方式，如 Boardcast Join、Shuffle Join、Bucket Join、Replica Shuffle Join、Colocation Join。CBO 会根据表的统计信息选择 Join Reorder 与 Join 的类型。同时也提供了多种优化手段，如谓词下推、Limit 下推、延迟物化等功能，进行多表关联的查询加速。同时通过 Primary Key 模型对于数据变更的支持，可以在 StarRocks 中创建缓慢变化维实现维度数据变更。

通过星型/雪花模型构建的开源实时数仓，在 Flink 中，只需要做 ODS 层数据的清洗工作，维度表与事实表会通过 Flink CDC 同步写入到 StarRocks 中。StarRocks 中会在 ODS 层进行事实数据与维度数据的落地，通过聚合模型或物化视图完成与聚合操作。利用 StarRocks 的极速多表关联查询能力，能够快速计算查询结果，保证业务在不同模型层的数据高度同源一致。

在真实业务中，维度的属性并非静止，会随着时间的流逝发生变化。星型模型可以将事实表与维度表独立存储，将维度数据从宽表中解藕，从而利用 StarRocks 的主键模型处理维度表变更的问题。

StarRocks × Flink 用户案例

—

在某知名电商平台业务中，通过使用 StarRocks 与 Flink CDC 极大程度地简化了数据链路的复杂度。用户通过 StarRocks 构建实时数据看板平台，实现了多维度数据筛选、灵活漏斗分析、不同维度上卷下钻的灵活分析。

数据传输层：通过 Flink CDC 可以直接拉取上游的埋点数据与 MySQL 订单库中的增量数据。相比于 MySQL -> Canal -> Kakfa -> Flink 的链路，架构更加清晰简单。特别是对于上游的 MySQL 分库分表订单交易库，可以在 Flink CDC 中通过 Mapping 的方式，将不同的库中的表和合并，经过清洗后统一写入到下游的 StarRocks 中。省略了 Canal 与 Kafka 组件，减少了硬件资源成本与人力维护成本。

数据存储层：通过 StarRocks 替换 ClickHouse，可以在业务建模时，不必限制于宽表的业务模型，通过更为灵活的星型模型拓展复杂的业务。主键模型可以适配 MySQL 业务库中的订单数据变更，根据订单 ID 实时修改 StarRocks 中的存量数据。同时，在节点扩容时，StarRocks 更为简单，对业务没有侵入性，可以完成自动的数据重分布。

性能方面：单表 400 亿与四张百万维度表关联，平均查询时间 400ms，TP99 在 800ms 左右，相较于原有架构有大幅的性能提升。替换 StarRocks 后，业务高峰期 CPU 使用从 70% 下降到 40%。节省了硬件成本。