StarRocks X Flink CDC，打造端到端实时链路

实时数仓建设背景

实时数仓需求

随着互联网行业的飞速发展，企业业务种类变得越来越多，数据量也变得越来越大。以 Apache Hadoop 生态为核心的数据看板业务一般只能实现离线的业务。在部分领域，数据实时处理的能力已经成为限制企业数据变现的重要瓶颈之一。搭建数据看板快节奏地进行数据分析，已经成为了一种必然的选择。

实时数仓发展

实时数仓有三个著名的分水岭：第一个分水岭是从无到有，Apache Storm 的出现打破了 MapReduce 的单一计算方式，让业务能够处理 T+0 的数据；第二个分水岭是从有到全，Lambda 与 Kappa 架构的出现，使离线数仓向实时数仓迈进了一步，而 Lambda 架构到 Kappa 架构的演进，实现了离线数仓模型和实时数仓模型的紧密结合；第三个分水岭是从繁到简，Flink 技术栈的落地使实时数仓架构变得精简，并且是现在公认的流批一体最佳解决方案。

以 Flink 作为实时计算引擎实现的实时数仓，将一部分复杂的计算转嫁给 OLAP 分析引擎上，使得应用层的分析需求更加灵活。但仍然无法改变数据仓库变更数据的排斥。下一代的实时数仓平台，不仅要提供更为优秀的性能，同时也需要更为完善的功能以匹配不同的业务。

作为一款全平台极速 MPP 架构，StarRocks 提供了多种性能优化手段与灵活的建模方式，在预聚合、宽表和星型/雪花等多种模型上，都可以获得极致的性能体验。通过 StarRocks 结合 Flink 构建开源实时数仓的方案，可以同时提供秒级数据同步和极速分析查询的能力。同时，通过 StarRocks 主键模型，也可以更好地支持实时和频繁更新等场景。

基于 Flink 的开源实时数仓痛点

原有基于 Flink 构建实施数仓的方案中，由于数据源的多样性，需要使用不同的采集工具，如 Flume、Canal、Logstash。对于不同的业务，我们通常会采用不同的分析引擎。比如，对于固定报表业务，根据已知的查询语句可以预先将事实表与维度表打平成宽表，充分利用 ClickHouse 强大的单表查询能力；对于高并发的查询请求，可以使用 Apache Druid 承受大量用户高峰时期集中使用带来的并发压力。通过技术栈堆叠的方式确实可以满足业务要求，但也会让分析层变得臃肿，增加开发与运维的成本。

一般来说，StarRocks X Flink 构建开源实时数仓生态架构分为五层：

• 第一层是数据源。数据源可以是多种多样的，比如说 MySQL Binlog、爬虫数据或者是平面文件；
• 第二层是数据采集层。用户使用多种不同的 CDC 工具，比如 Canal、Debezium 拉取上游的增量数据，通常会将数据写入到 Kafka 中，而后在通过 Flink 消费 Kafka 中的数据；
• 第三层是实时计算层。可以通过 Flink 的实时计算能力完成轻量级的 ETL 工作，如拼宽表或数据清洗等；
• 第四层是数据存储层。Flink 相比其他的实时技术栈更加依赖 OLAP 引擎；
• 最后一层是后端应用层。可以是实时监控系统，实时报表系统，实时推荐系统以及实时数据接口服务。

我们常说，天下武功，唯快不破。以 Flink 为计算引擎构建的实时数仓系统，最关心的就是数据摄入速度足够快，延迟足够低。 在这样一套架构中，数据从数据源到 OLAP 分析系统途径采集工具层，消息队列层，实时计算层。冗长的链路给开发和运维带来了极大的风险，任何一个模块的阻塞都会对实时性产生影响。同时，在数据存储层上，我们也会选择不同的存储引擎适配不同的业务。对于上面的数据链路，我们也面临着诸多的挑战，需要从时效性、功能性及可维护性上做更多的探索，由此可以总结归纳出多个方面尚待优化：

• CDC 组件不统一，链路过长，任何组件出现瓶颈都会对时效性产生影响，组件过多，需要多部门协作维护，学习成本与维护成本成倍增长；
• 部分同步组件，如 Debezium 在保证数据一致性时，需要对读取的表加锁，可能会影响业务更新；
• 分析层使用多种数据存储产品适应不同的业务类型，难以有一种产品能够适应大部分的业务；
• 去重操作对应逻辑复杂，需要在 flink 里面增加 MapStat 逻辑。

Flink CDC，打通端到端链路

Flink CDC 是由 Flink 社区开发的集数据采集、数据转换、数据装载一体的组件，可以直接从 MySQL、PostgreSQL、Oracle 等数据源直接读取全量或增量数据并写入下游的 OLAP 数据存储系统。使用 Flink CDC 后，可以简单高效的抓取上游的数据变更，同步到下游的 OLAP 数据仓库中。

构建一体化数据传输链路

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