关于flink:FlinkStarRocks-实时数据分析新范式

摘要：本文整顿自 StarRocks 社区技术布道师谢寅，在 Flink Forward Asia 2022 实时湖仓的分享。本篇内容次要分为五个局部：

1. 极速数据分析
2. 实时数据更新
3. StarRocks Connector For Apache Flink
4. 客户实际案例
5. 将来布局

点击查看原文视频 & 演讲 PPT

一、极速数据分析

对立 OLAP 剖析的趋势，以及 StarRocks 极速查问剖析的外围能力。计算机科学里所有难题，都能通过加中间层的形式来解决，然而不能加的货色太多。回忆 Hadoop 生态演变的过程，先有了分布式存储，解决了海量数据如何用便宜的设施，来存储的问题。又有 MapReduce 帮忙咱们慢吞吞的解决了，分布式解决的问题。

为了让只会写 SQL 的分析师，可能专一于业务，不必放心 Java 编程的问题，又有了 Hive 帮忙咱们解决，SQL 到 MR 的主动解析。当人们感觉 Shuffle 磁盘太慢，咱们钻研了基于内存的弹性分布式数据集 RDD，让数据在内存里分布式的高效计算。

因为内存里微批的计算仍不能形容所有的实时语义，就有了为实时而生的分布式计算引擎 Flink。

晚期，人们对数据的依赖还没那么深的时候，数据不管怎么进来的，最终能看到就行。随着时代的变迁，除了管理层须要看数，基层小伙伴也须要用数。于是 OLAP 剖析产品，就像雨后春笋似的，有能间接聚合指标的，有能 Adhoc 探查的，有单表无敌的，有能反对数据更新的。

因为组件太多，数据在各个引擎里来回传递，时效性低，口径不统一，硬件资源，人力老本，都十分节约。所以人们期待一种极致性能的剖析型数据库，可能收敛 OLAP 剖析层，开启实时数据分析新范式。

StarRocks 的愿景是心愿帮忙客户，可能实现极速对立 OLAP 剖析的技术架构。首先，通过 2 年的打造，极致的性能曾经深入人心。全面反对了向量化引擎，CBO 技术，智能物化视图等等一揽子技术。使得 StarRocks 能够实现亚秒级极速 OLAP 剖析，保障数据分析利用最初一公里的极速响应。

同时，现代化 MPP 的架构，能够让查问服务充分利用多机多核的资源。保障业务随着硬件，能够 scale-up 和 scale-out。简洁的 fe+be 的架构，能够实现极简运维，优良的实时摄入能力，让实时数据分析变得轻松简略。

在高并发点查的场景，资源正当布局，能够做到上万 QPS。在与云的整合上，咱们曾经在各大云商的半托管服务上，可能疾速部署社区版 StarRocks。周边咱们也在致力整合更丰盛的生态计划。凋谢沉闷的社区也逐步有搭档，帮咱们奉献更多的关键性 Feature。

有这样极致的剖析性能，StarRocks 到底能帮咱们做什么呢？这里演绎总结了 4 个比拟外围的场景。

• BI 报表类业务。这个是 StarRocks 的看家本领，不论你要减速固定报表，还是要自助式 BI，利落拽来摸索式剖析，都能够用 StarRocks 来撑持。
• 实时类的业务。比方实时大屏，Flink+StarRocks 的计划曾经十分成熟了。尤其是增量聚合类的指标，StarRocks 的聚合表模型，能够间接生成 DWS 层的 sum，min，max 的聚合指标。
• 有一些用户在打造客户数据平台时，做用户分群、行为剖析、用户画像等场景也会用 StarRocks 去做。之前很多场景是离线的，StarRocks 实时的链路也能够秒级摄入，这样离线和实时的数据能够联结剖析，让数据的新鲜度更靠前。
• 对立剖析。除了刚刚讲的实时数据和离线数据的对立，StarRocks 还反对 Iceberge/Hudi/Hive 表面查问，能够实现湖和仓的联邦剖析。也有客户用 StarRocks 真真切切的解决了它们的剖析和服务割裂的问题，以及尝试业财一体化剖析等等。

如上图所示，展现了 StarRocks 的外围能力，其中第一点，就是 StarRocks 全面反对了 SIMD 指令，充沛去利用单颗 CPU 的解决能力，让它一次指令可能解决更多的数据。

StarRocks 反对十分多的分布式 Join 策略，针对不同的场景，CBO 优化器能够主动抉择适合的分布式 Join 策略。从若干个查问布局候选中，抉择最优的布局，让查问体验最好。

有了 CBO 优化器，能够基于统计信息，主动改写左右表的关系，智能抉择最优的查问布局。此外，比方用低基数全局字典让 String 映射为 int；提早物化来升高有效的 Scan；runtimeFilter 让右表的过滤能够推到左表提前 Scan 等等，还有一揽子极致的优化，整体保障 StarRocks 可能应答非常复杂的剖析查问。

以最大的限度，让使用者关注在业务逻辑自身。从各种参数调优、分布式 Join 策略的抉择等等手动优化的工作中解脱进去，把这些事件交给 StarRocks 主动实现。

StarRock 反对十分丰盛的数据摄入能力。有配套的伎俩能够从传统关系型数据同步存量数据，也能够联合 Primary Key 模型和 Flink-CDC，整合做实时 Upsert、Delete 的数据同步。

此外，对于音讯队列的数据，StarRocks 的 routine load 能够间接生产 Kafka 的音讯，也能够用 Connector 和 Flink 整合。外围的组件 FE，负责元数据管理和 SQL 解析，执行布局的生成等。BE 承载了向量化执行引擎和列式存储。在外层，反对十分丰盛的表面查问能力，能够整合湖和仓的数据一体剖析。StarRocks 做的 BlockCache 的 Feature，能够让湖的查问能力不弱于仓的性能。

另外，StarRocks 部署非常简单，不论你是在云上还是私有化部署，都能够实现极简运维。对外通过 MySQL JDBC 就能轻松连入，去应答 BI 剖析、报表、实时看板等场合。

二、实时数据更新

接下来，重点看看 StarRocks 在有更新的实时链路里，怎么提供高效的剖析查问服务。首先，谈到实时数仓，每个企业每个客户的了解都不尽相同，技术路线的抉择也会有所不同。

有的场景解决逻辑非常复杂，借助 Flink 弱小的计算能力和丰盛的工夫语义，客户能够在 Flink 里实现建模。而后，把加工后的后果长久化到音讯总线。StarRocks 能够去订阅对应的 Kafka 里的分层数据，再把后果同步过去。对于固定报表类的场景，往往聚焦在 ADS/DWS 层的聚合指标查问，要求查问有极高的性能。这种在 Flink 里计算，在 StarRocks 负责极速查问剖析的计划就比拟适宜。有些场景，数据量不大，利用离线数仓跑批的思路，用调度零碎在 StarRocks 里一层一层的做下来，也能实现数仓分层的建设。咱们通常说的 OLAP 多维分析，个别会聚焦在 DWD 宽表和 DWS 轻度汇聚层，更灵便的 Adhoc 查问，可能还会对 ODS 原始数据进行查看。

后面聊的一些实时数仓建设的思路，大部分是建设在 append 流的根底上的。假设咱们的数据只有追加，没有 Upsert/Delete 操作。在有更新的场景下，不论是增量构建，还是微批调度，都很难保障下层的聚合指标，下钻下来，还能跟明细层对应上。

曾经有客户尝试在一些场景下，用 Primary Key 模型做 ODS，保障实时的数据 Upsert/Delete。而后，下面的分层用逻辑视图，保障聚合指标和明细的齐全同步吻合。

另外，咱们跟 Flink 去联合，如果只反对 append 流是远远不够的。那么 StarRocks 能不能解这个难题呢？答案是必定的。

生存中咱们总说覆水难收，比喻事件已成定局，难以挽回。然而弱小的 Flink，就有回撤流这种性能，这里提供了一个词频统计的简略 SQL。

能够看到，在新的数据“StarRocks, 1”进来后，如果没有数据回撤，来标记上一轮 Sink 进来的数据生效的状况下，再叠加新进来的数据，就会造成后果的谬误。反之，有了 Flink Retract，能够发出上一批次的论断，而后吐出正确的指标。

这种状况下，Flink 端能搞定回撤的问题了，然而 OLAP 端怎么办呢？如果没有高效稳固的 Upsert/Delete 能力，非常容易造成数据的反复和后果的谬误。

在一年前，咱们在 1.9 版本中公布了新的存储引擎 Primary Key 表模型，在反对实时更新的同时，还能放弃查问的高性能。它内置了 OP 字段，以 0 或 1 的模式来标记数据的 Upsert/Delete，恰好吻合了 Flink 回撤流的数据特色。联合咱们提供的 Flink Connector，能够间接将 Flink 的回撤流，对接进 Primary Key 模型。

它基于 Delete+Insert 的形式或者叫 merge-on-write 的形式，实现更新。相比原来 merge-on-read 的 unique 模型，在导入性能简直不受影响的前提下，查问性能晋升了 3-10 倍。

它非常适合 TP->AP 实时同步数据，并减速查问的场景。通过 Flink-CDC 工具，将 TP 业务零碎，比方 MySQL 间接同步到 StarRocks，极大的简化了实时剖析数据流，简略易用。目前，己经有多个用户在线上零碎中采纳，是实时数据分析的典型范式。

2022 年，咱们对 pk 模型做了长久化主键索引的性能，来升高主键模型的内存开销。原来的主键索引是基于全内存哈希表的，新的长久化索引同样应用了基于 Hash 的设计，并且应用了相似 LSM 的多层设计。

第一层 Hash 为内存 Hash 表，第二层是基于磁盘的 Hash 表构造。为了节约存储空间，应用了相似原全内存 Hash 表的 Shard by length 设计。测试结果显示，内存占用个别只有原来 1/10。因为查问索引实质上，是大量的随机 IO 操作，如果须要长久化索引，举荐应用固态硬盘。

这个是咱们导入测试时的内存比照，右边是 BE 过程的内存总占用，左边是索引的内存占用。在全内存索引模式下，随着数据继续导入，总内存最高到 120G，索引内存最高到 60G 左右。

在长久化索引模式下，随着数据继续导入，总内存最高到 70-80G，索引内存最高到 3-4G 左右，内存应用降落非常明显。

另一个 Feature 是，局部列更新的反对。在去年的 FFA 峰会上，我分享了基于聚合模型的 replace_if_not_null，来实现局部列更新的办法。应用这个办法有肯定的开发成本，开发者须要把宽表的下标凑齐，没有数据的地位须要显式的去补 null 值。

明天谈的 PK 模型的局部列更新性能，开发成本会更低，数据接入时只须要指定该数据流的相干列名即可。尽管 SR 在多表查问方面性能十分好，然而在一些场景下，用户还是冀望大宽表带来的极速性能。

目前，如果想要实现这个成果，有几个常见计划。

1. 在上游数据流中插入一个 Join 模块或者算子，通常应用 Flink 等流式计算平台。用多流 Join，拼成整行数据。

   如果上游多个数据流的数据达到工夫不统一，很难设计适合的 window 去在计算引擎里打宽数据，启用 mapState 之类的状态计算又过于定制，迭代效率又是个问题。

2. 用 TP 零碎建宽表。上游模块以局部列更新形式写入 TP 零碎，再通过 TP 零碎，同步给 AP 零碎。这样须要额定搭一套 TP 模块和同步模块。
3. 先分模块导入 AP 零碎，AP 零碎中通过 DML 定期做 Join，后置的定期去刷新大宽表，这样会就义肯定实时性。

这三种形式都有肯定的复杂度，如果 SR 可能间接反对局部列更新，将带来全新的思路，能很好的解决这个问题，简化多流 Join 的链路。

从 2.3 版本开始反对了局部列更新性能，实现形式还是以现有的 Insert+Delete 模式为根底，流程能够参考图中的例子。我要把第一列为 3 的那行最初那个值列 c 改为 y。须要先找到 3 所在的行，而后把跟本次更新无关的列带进去，标记这行为 Delete，而后再追加更新后新的行进去。

剩下的操作就和原来的 Full Row Upsert 相似了。因为采纳 Delete+Insert 的形式，实现部份列更新，读写放大问题其实对这种用法造成了肯定的限度，特地是对大宽表仅更新很少一部分列的状况。

比方有个表有 10000 列，咱们只更新其中的一列。须要先读取其余的 9000 多列，再写入全副 10000 列。所以，咱们目前举荐部份列更新，仅在列不是特地多的场景下应用（比方小于 500 列的状况下），并且尽量在固态盘上应用这个性能。为了部份解决这个问题，咱们前面打算引入行存，这样可能解决一部分读放大的问题。

另一个 Feature 是，条件更新。在导入时增加了条件的性能，只有条件满足时，才进行更新。罕用的场景比方导入的数据有乱序，或者因为并发导致的数据乱序。

为了避免乱序数据笼罩正确的数据，个别会设计一个工夫戳字段。这样在更新时能够指定一个条件，当工夫戳大于以后工夫，才进行更新操作，否则疏忽该行。

在 Flink-CDC 同步时，如果工作并发十分高，导致事务数量较多的话，咱们新减少了基于 Stream Load 的事务导入接口，能够将多个导入工作合并成一个事务。在定期 Sink 开始前，开启事务。而后，并行写入数据。最初，全副 Task 实现数据传输后，整体提交事务。

这样下面的例子中，总事务数就从 4 个缩小到了 1。高频导入的瓶颈实质上是事务数量高的问题，升高事务数量，就能够晋升实时导入的能力。

三、StarRocks Connector For Apache Flink

接下来，咱们看下 StarRocks 怎么和 Flink 通过 Connector 来整合。上图描述了 Flink Connector 的整体状况，StarRocks 提供了 Source Connector。用户能够把 StarRocks 的表作为数据源，用 Flink 分布式的提取 StarRocks 的数据。能够用于跨机房的数据迁徙，或者基于 Flink 做进一步简单的分布式解决。

Sink Connector 次要是把 Flink 内存里的数据，走 StarRocks 的向量化导入接口，将实时的流数据高效的导入到 StarRocks。

之前客户为了实现 Flink 读 StarRocks 表，须要本人定制 Source，以 MySQL JDBC 的模式读取数据，BE 的数据最终须要单点抽上来，效率较差。

StarRocks 提供的 Source Connector，进行了分布式设计。先在 FE 找到对应的分片元数据信息，而后分布式的间接从存储层提取数据，整体的吞吐能力大大晋升。

Sink Connector 的应用会比 Source 更多，借助 Flink 弱小的流批一体解决能力，能够解决流式音讯，也能够抽取 TP 数据库的数据，乃至于 Hive 数仓的数据。通过 Flink 的加工之后，通过 Sink Connector，走 Stream Load 接口，同步到 StarRocks。

这里举个局部列更新的例子，原来有“101，Tom，80”的记录。当初须要追加一些新的数据，并做数据更新。指标是要把 101 的 Tom 改为 Lily。咱们看到，对于接口侧，只须要指定主键 id 列和须要更新的 name 列，依照失常数据导入的模式导入就行。

在 Flink-Connector 配置也非常简单，和 Stream Load 接口用法统一，只须要启用 partial_update，而后指定数据的列名就能够了。

四、客户实际案例

接下来，分享一个实际案例。次要是对于京东物流，用 Flink 和 StarRocks 的 Primary Key 模型，来解决剖析和服务一体化的问题。

首先，看下京东物流的数据特色，以及面临的次要挑战。大家晓得在京东 APP 下单之后，订单由商城域进入物流域，从仓储进分拣，从配送到妥投，最初到消费者手里。整体的物流业务很简单，流程也很长。随着实体包裹在物流地位上的运输，数据通过了很多环节，还有物流批次的一些行业概念，又多了一些工夫维度。整体的数据环节简单，呈现出多维平面散布的特色。

除此之外，流程简单，业务零碎也很多。因为既有架构演进的历史起因，依然存在多种数据源。所以京东物流的数据架构上，比拟依赖联邦查问的能力。

在业务层面，有很多宏观的数据汇总指标，来领导生产。须要把聚合后的后果，进行关联出对立数据指标。所以聚合查问，和多表关联也是一个特色。

咱们能够看下京东物流的晚期架构，整体分为数据服务链路和数据分析链路，这两条线基本上是割裂的。

数据服务的链路，由 Flink 生产音讯队列的数据，送入到一些数据库产品当中。次要有 ClickHouse，ES 还有 MySQL，为了接口可能提供稳固高效的查问服务。而灵便剖析的场景，没有固定的模型可能应答所有查问，可能会基于 Hive 或者 Presto，以 Adhoc 的模式实现比较复杂的 SQL。

总体剖析，晚期架构有这样一些问题。

• 数据源多样，保护老本比拟高。
• 性能有余，写入提早大，大促的场景会有数据积压，交互式查问体验较差。
• 各个数据源割裂，无奈关联查问，造成泛滥数据孤岛。而后从开发的角度，每个引擎都须要投入相应的学习开发成本，程序复杂度比拟高。

京东物流经验了大数据产业化的整个历程，数据利用多种多样，应用数据的形式也各不相同。于是，着力打造了 UData 平台，作为数据资产和数据利用之间的桥梁，以数据接入或者表面关联的模式，造成对立数据收口。StarRocks 作为 UData 平台的外围底座，撑持了两个次要场景：

1. 以接口的模式，提供稳固牢靠的数据服务模块。
2. 给业务人员提供极速的灵便剖析模块。让业务能够在数据指标地图上，在线查找本人须要的数据指标。

并且做了指标配置化开发、指标积木式编排、可视化 SQL 编辑等平台侧赋能，解决数据应用的最初一公里问题。

往年，京东物流用 StarRocks 在实时链路里，替换掉了 ClickHouse，解决查问并发和多表关联的瓶颈。而后，在实时服务链路和数据分析链路后面，将 StarRocks 作为数据的对立查问入口，实现剖析和服务的一体化。

与此同时，京东物流也积极参与 StarRocks 社区的技术共建工作。基于既有架构实现的表面聚合下推和排序下推性能。能够在一些场合，无效升高网络带宽的传输，并且欠缺了 RPC 和 Http 接口的表面反对。

在局部场景开启聚合下推的性能，聚合查问性能有大幅晋升。这里举例了一个 6 表关联的简单 SQL，从之前的 30 秒优化到 6s，性能晋升数倍。从右侧的监控也能看到，两头测试开启了一段时间的下推性能，QPS 有显著的晋升。

在往年 (2022 年) 双 11，StarRocks 承载了运单实时数据更新和自助式剖析查问的场景。这个场景的 QPS 不高，然而查问非常灵活，会基于数百列的表做任意的筛选和关联查问。另外一个特点是，运单的工夫语义字段有好几个。比方下单工夫、发货工夫、妥投工夫等等，而且工夫数据会被批改，查问的时候不肯定是用哪个字段去过滤。这就没有方法从中选出一个正当的分区字段用于分区，在查问时无奈进行分区裁剪。

从左侧监控的示意图能够看到，两头有个十分大的 latancy 尖峰，就是因为这种 SQL 会有大量的 Scan，从而造成查问的高提早。

为了解决这个问题，咱们和京东物流的同学一起剖析探讨了这种非凡的场景。一种解法是，把这些工夫语义的字段，做一些归类梳理。而后，按不同的工夫语义，拆成多个表应用。这种办法会大大的晋升分区裁剪的成果，然而开发成本会比拟大，须要上下游零碎的联动。对于双 11 这样的工夫紧工作重的大促流动，很难再做出比拟大的结构性调整。

于是，咱们尝试了在日期字段上加 Bitmap 索引的计划。如图所示，在加上索引后，Scan 无效失去升高，问题失去了解决。

利用 StarRocks 胜利应答了双 11 的大促挑战之后，京东物流对将来技术架构做了进一步的布局。在计算层，打算把离线链路的 Spark 计算引擎优化掉，采纳 Flink 实现流和批的一体化解决。在剖析层，将逐步优化掉既有的一系列剖析组件，把 StarRocks 作为对立的底座，让数据分析和数据服务，收敛到 StarRocks 上来。

五、将来布局

接下来，分享下 StarRocks 在实时数据分析方面，会进一步做出哪些工作。

一方面从易用性角度，反对主键与排序键拆散。在目前的主键模型中，能够认为 Sort Key 和 Primary Key 是对立在一起的。例如左边的例子，主键是 id。如果数据依照 id 排序，对 City 过滤的查问，就须要扫描全表，或者须要加其它二级索引，想方法减速过滤。

如果能把 Sort Key 和 Primary 拆离开，建表时能够让 Sort Key 和 Primary 用不同的字段。比方 id 作为主键，负责更新的惟一束缚；City 作为 Sort Key，负责数据的存储程序。这样就能减速一些常见的查问。

其实能够进一步思考，目前 StarRocks 的好几种表模型，duplicate/aggr/unique 面对不同场合，客户须要稍作抉择。这些都能够对立到一种语法表白，对立之后，对用户来说，只有一种表更容易了解，能够进一步晋升易用性。

另一个重要的方向是。多表物化视图。目前，主键模型并不反对 ROLLUP 和物化视图，而 ROLLUP 性能也比拟无限。StarRocks 新一代的多表物化视图架构会反对更加高级的性能，包含通明的查问减速，离线的全量构建和实时的增量构建；能够写比较复杂的表达式，多表关联，子查问嵌套等等；以相似 Insert into overwrtie 的语义异步或者同步的主动实现物化。

增量物化视图的构建，须要可能提供表的增量批改数据。咱们会在外部实现相似 binlog 的机制，来辅助实时增量多表物化的工作。

有了增量多表物化视图，更易用，性能又更好的 Primary Key 模型，乃至于局部列更新，LocalCache 减速等 Feature 的加持。将来实时数据分析或将迎来新的范式。人们不用再设计非常复杂的 ETL 架构，保护那么多的外围程序，做了很多有效的数据搬运工作，消耗了不少人力和物力，交付节奏总跟不上新需要爆发的速度。

将来，你有可能通过 Flink，将实时数据从音讯队列或者 TP 的 CDC 秒级的继续稳固的摄入进 StarRocks。在 StarRocks 里，间接去面向剖析，开发咱们的指标和模型。表面的模式也好，逻辑视图也好，CTE 也好，以最麻利的模式疾速迭代开发。开发完 SQL 逻辑之后，联合场景，哪些指标是须要高并发低提早的服务的？哪些层是须要重复被其它上游频繁调用的？不论是宽表，还是多表关联的简单 SQL，咱们都能够按需的去上卷或构建物化。直面剖析，按需减速，让数据分析的链路更经济，效率更好。

实时即将来，StarRocks 在逐步实现这样的能力，StarRocks 和 Flink 联合去构建实时数据分析体系的联结解决方案，将在肯定水平上颠覆既有的一些禁锢，造成实时数据分析新范式。

点击查看原文视频 & 演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://click.aliyun.com/m/1000372333/