vlambda博客
学习文章列表

本文从以下5个方面介绍：

• 第一部分，实时数仓技术的发展趋势和技术挑战，以及为什么 Flink+StarRocks 能够提供端到端的极速实时数仓体验。

• 第二部分，介绍什么是 StarRocks，它有哪些技术特点，擅长的场景是什么，以及为什么作为 OLAP 层的极速分析引擎，它能够很好与 Flink 技术进行整合。

• 第三部分，重点介绍联合 Flink 和 StarRocks 两大技术栈构建实时数仓的方法论。

• 第四部分，介绍一些利用 Flink 和 StarRocks 构建实时数仓的最佳实践案例。

• 第五部分，展望了 StarRocks 在实时数仓方向以及 Flink 社区贡献等方面的后续规划。

1

实时数仓概述

数据源上，早先只能支持单一的数据源，整体的数据表现力较差。而当下，人们不仅希望能对单一数据流进行分析计算，还希望能联合多个数据源进行多流计算，为此不惜想尽一切办法，来让数据的表现力更加丰富。

从工程效率的角度上看，技术团队也逐渐意识到，工程代码开发的成本高企不下，更希望能构建自己的平台化 IDE 工具，让业务人员能基于其上直接进行 FlinkSQL 的开发。在这些演进的过程也逐渐浮现出一些技术难点亟待解决，比如：

• 乱序数据怎么更好的处理？

• 通过Watermark之类的手段，是让过去的数据随即失效，还是希望所有的明细数据都能入库？

• 多流Join到底应该怎么做合适？

• 维表是一次性加载进来，还是放到外存储做热查询，除此之外还有没有其他的技术选择？

• 数据处理作业一旦重启，怎么保证在恢复之后还能做到不丢不重的续接消费？

• 怎么才能提高整体的业务开发效率，保证业务上线时没有业务中断，更优雅快捷的进行业务逻辑迭代？

在此之外，还有一件事也是业务人员或平台架构师最关注的，那就是通过 Flink 这么强大的实时计算引擎，费劲千辛万苦好不容易把计算层效率从小时级或者分钟级的延迟提升到了秒级，结果现有的 OLAP 产品拖了后腿，查询耗费了好几分钟，辜负了计算团队的大量心血。

以上种种，充分证明了极速 OLAP+实时计算的重要性，以此我们就可以打造一套端到端的极速实时数仓解决方案，即所谓“双剑合璧”！

谈到数仓，目前业界落地较多的还是 Lambda 架构，也就是离线数仓和实时数仓分开构建。逻辑分层的形式，也基本形成了业界的共识。业务数据有的是 RDBMS 采集上来的，有的是日志采集上来的，有的是批量抽取上来的，有的是 CDC 或者流式写上来的。原始操作层（ODS）基本都是保持数据原貌，然后经过维度扩展、清洗过滤、转换，构建成明细层（DWD）。再往上层走，数据开始做轻度聚合，并有原子指标出现。最后按照主题或者应用的需要产出 ADS 层里的派生指标或者衍生指标。

企业构建实时数仓，为了让整体的逻辑清晰，通常情况下也会沿用这种分层模式，只不过受限于实时数据到达的先后情况以及业务需要，可能会有些层次的裁剪，不像离线数仓里那么丰富。中间的一些维度信息，可能会同时被离线数仓和实时数仓共享使用。最后将数据送入 OLAP 产品，供报表系统、接口或者Adhoc查询所调用。

基于前面对数仓典型逻辑分层的探讨，问题也随之而来：

是否有一款 OLAP 产品能够很好的和Flink结合，满足持续的秒级的数据摄入和极速分析查询能力？

答案是一定的，StarRocks 的定位正是要提供极速分析查询能力，来适应各种各样的 OLAP 场景。

2

StarRocks 是什么

从左边我们可以看到常见的 Kafka、分布式文件系统、传统关系型数据库，都可以作为 StarRocks 的数据源。

StarRocks 提供了4种模型：

• 如果业务场景只涉及数据的持续 Append，可以选择 Duplicate 明细模型，在其上可以实时构建物化视图加速 DWS 层查询；

• 如果业务场景不关注明细的下钻，StarRocks 还有 Aggregate 聚合模型表，相当于数据直接秒级打入DWS 层，满足高并发的聚合指标查询；

• 对于 ODS 层做业务库数据还原时，若涉及到数据更新的场合，可以采用 Unique 模型，利用 Flink 的Append 流 Sink 数据进来，完成 ODS 数据去重和更新；

• 另外，StarRocks 最新2.0版本提供的 PrimaryKey 主键模型，比 Unique 模型查询性能快3倍以上，内置了 OP 字段来标记 Upsert/Delete 操作，并且能够很好的吻合 Flink 的 Retract 回撤流语义，聚合计算不必非要开窗转为 Append 流来 Sink，进一步增强了 FlinkSQL 的表现力。

StarRocks 还提供了逻辑 View 和物化视图，提供了更丰富的建模能力。

在上图的右侧是 StarRocks 的物理架构，整体还是非常简洁的，主要就是两种角色：FE 前端节点和 BE 后端节点。

• FE 负责查询规划、元数据管理、集群高可用，并包含 CBO 优化器，为分布式多表关联和复杂 Adhoc 查询提供最优的执行规划。

• BE 节点承载了列式存储引擎和 全面向量化的执行引擎，保障在 OLAP 分析场景中提供极速查询体验。

• 对上层应用提供 MySQL 连接协议，可以用 MySQL 客户端轻松连入进行开发和查询，和主流 BI 工具有很好的兼容性，也可以服务于 OLAP 报表和 API 封装。

3

StarRocks 擅长哪些场景

StarRocks 基于 Roaring Bitmap 提供了 Bitmap 数据结构，并配套有集合计算函数，可以用于精确去重计算和用户画像的客群圈选业务。在实时方面，StarRocks可以用于支撑实时大屏看板、实时数仓，秒级延迟的呈现业务原貌和数仓指标。

最后，基于 CBO 优化器，StarRorcks 在 OLAP 场景下有很好的多表关联、子查询嵌套等复杂查询的性能，可以用于自助BI平台、自助指标平台和即席数据探查等自助分析场景。

StarRocks 能够用于构建实时数仓，得益于他的三种实时数据摄入能力：

• 可以直接消费 Kafka 的消息。

• 可以借助 Flink-connecor 实现 Exactly-once 语义的流式数据摄入。

• 另外，结合 Flink-CDC 和 PrimaryKey 模型，可以实现从 TP 库 Binlog 实时同步 Upsert 和 Delete 等操作，更好的服务于 ODS 层业务库还原。

利用 Flink-Connector-StarRocks 插件，可以实现从 TP 库  Binlog 实时同步 Upsert 和 Delete 等操作，更好的服务于 ODS 层业务库还原。配套的 SMT（StarRocks Migration Tool）工具，可以自动映射 Flink 中的 TP库 Source 和 StarRocks 库的 Sink 建表语句，使得基于 FlinkSQL 的开发工作变得简单便捷。

另外，Flink-Connector 更重要的功能是提供了通用 Sink 能力，开发者把依赖加入后，无论是工程编码还是 FlinkSQL 都可以轻松 Add Sink，保障数据秒级导入时效性。

结合 Flink 的 Checkpoint 机制和 StarRocks 的导入事务标签，还可以保障不丢不重的精准一次导入。

StarRocks 的实时物化视图构建能力，结合 Flink-Connector 的持续增量数据导入，可以在流量类指标计算的建模中，实现 DWD 明细数据导入完成的同时，DWS 聚合指标也同步增量构建完成，极大提升聚合指标产出效率，缩短分层 ETL 的旅程。

StarRocks 提供的 Replace_if_not_null 能力比较有意思，正如语义所述，只要插入的数据不是 null，那么就可以去替换数据。

如图所示，右侧是个建表示例，里面维度列为日期和 Uid，其余3列中 SRC 表示数据源，另外带了 v1，v2两个 Metric；

通过2个 Insert 语句我们可以看到，来自2个 Kafka 主题的数据源的数据，轻松的实现了同时写入一张表的不同列。因此，这个功能提供了两种实时数仓能力：

1) Join on Load，也就是在导入的过程中，基于 StarRocks 来实现流式 Join。

2) 部分列更新能力。

StarRocks 为了支持更好的 Upsert/Delete，提供了 PrimaryKey 表模型。

如上图所示，最左侧是经典的 LSM 模型，也就是 Merge-on-Read 的形式。这种模型写入时不用去判断既有键位，对写友好，但读取时需要 Merge 合并，所以对读取数据不友好。

而最右侧是 Copy-on-Write 的模型，典型的产品就是 DeltaLake。这种模型和 LSM 正好相反，有比较好的读效率，但是对于写入不是很友好。

比较平衡读取和写入的，就是上图中间的两种 Record 级别冲突检查的模型，Kudu 的 Write Delta和StarRocks 的 Delete+Insert 模型。

由于维护了内存表，PrimaryKey 模型更适合冷热特征明显的场合，对热数据频繁的更新和删除更友好；

另外非常适合 PrimaryKey 较少的表（如用户画像的宽表），虽然列很多，但是主键其实只有 UUID 这种字段。

StarRocks 早期的 Unique 模型就是采用了最左边的 LSM 模型，因此查询效率较差，并且对于 Delete 不友好，结合 Flink 开发应用时，只能使用 Append 流进行 Sink。

StarRocks 2.0 版本中新增加的 PrimaryKey 模型，提供了软删除字段，通过在内存中维护最新数据，使得查询时避免了 Merge 的过程，从而极大提升了查询性能，并且既可以使用 Append 流也可以使用 Retract 流进行 Sink，丰富了与 Flink 结合时的应用场景。

4

构建实时数仓的具体方法

• 基于 MapStat 做状态计算，或者 BroadcastStat 将维度缓存广播出去；

• 用 Flink 关联外部热存储，如 HBase/Redis 等；

• 一些相对稳定、更新频率低的维度数据或者码表数据，可以利用 RichFlatMapFunc 的Open方法，在启动时就全部加装到内存里；

不限于以上这些，其实 Flink 已经在维度扩展上，给了开发者很多可以落地的选择。然而有了 StarRocks，我们会有更多的想象空间。

比如利用前面介绍的 Replace_if_not_null 的能力，开发者可以实现多个数据源稀疏写入宽表的不同列，来实现 Join-on-Load 的效果。

另外 StarRocks 强悍的 CBO 优化器在多表关联查询能力方面也表现优异，如果数据量不大或者在查询并发不高的场景，甚至可以把 Join 的逻辑下推到 OLAP 层来做，这样可以释放掉 Flink 上的一些构建负荷，让 Flink 专注于清洗和稳定的数据导入，而多表关联和复杂查询等业务逻辑在 StarRocks 上进行。

不仅如此，还可以结合 Join-on-Load 和 Join on StarRocks 的两种形式，也就是稀疏写入有限张表，通过表之间做 Colocation join 策略，保证有限的表之间数据分布一致，做 Join 的时候没有节点间 Shuffle，在上层构建逻辑 View 面向查询。

双剑方案1. 微批调度

Flink 清洗导入 Kafka 的日志或者用 Flink-CDC-StarRocks 读取 MySQL Binlog 导入 StarRocks，ETL 过程中埋入批次处理时间，采用外围调度系统，基于批次处理时间筛选数据，做分钟级微批调度，向上构建逻辑分层。

这种方案的主要特点是：StarRocks 作为 ETL 的 Source 和 Sink，计算逻辑在 StarRocks 侧，适用于分钟级延迟，数据体量不大的场景。

双剑方案2. Flink 增量构建

实时消息流通过 Kafka 接⼊，采用 Flink 进⾏流式 ETL、多流 Join、增量聚合等，在内存中完成分层构建，然后将相应的数据，层对层的通过 Flink-connector 写出到 StarRocks 对应表内。各层按需面向下游提供 OLAP 查询能力。

该方案的主要特点是：计算逻辑在Flink侧，适用于需要前导做较重ETL的场景，StarRocks 不参与 ETL，只承载 OLAP 查询，应对较高 QPS 查询负荷。

双剑方案3. StarRocksView视图

Flink 清洗导入 Kafka 的日志或者用 Flink-CDC-StarRocks 工具读取 MySQL Binlog 导入 StarRocks；根据需要选用明细、聚合、更新、主键各种模型，只物理落地 ODS 和 DIM层，向上采用 View 视图；利用StarRocks 向量化极速查询和 CBO 优化器满足多表关联、嵌套子查询等复杂 SQL，查询时现场计算指标结果，保证指标上卷和下钻高度同源一致。

该方案主要特点是：计算逻辑在 StarRocks 侧(现场查询)，适用于业务库高频数据更新的场景，实体数据只在 ODS 或 DWD 存储 (未来 StarRocks 提供多表 Materialized Views，将会进一步提升查询性能)。