导读: 本文讲分享Flink Table Store v0.2适用的应用场景,以及支撑这些应用场景的核心功能。 同时介绍Flink Table Store未来的规划。
今天的主题围绕以下四点展开:
-
应用场景
-
核心功能
-
未来展望
-
项目信息
01
应用场景
首先了解一下 Flink Table Store v0.2的架构 (如图 1) ,它首先是一个湖存储,以低成本无服务的方式存储大量数据。湖存储中通过Manifest管理文件,每个Bucket中是一个 LSM Tree。在湖存储上也支持了和Kafka的集成,让你一张表同时存储离线和实时数据。
上游支持Streaming或Batch写入数据,下游支持Flink Streaming、Flink Batch、Hive、Spark和Trino消费。湖存储的数据存储在DFS上,也可以使用Object Store、Cloud Storage来存储。
图1 Flink Table Store v0.2的架构
接下来分享v0.2主要面向的四个场景。
1. 场景一:离线数仓加速
第一个场景是离线数仓的加速(如图 2),这个场景中是典型湖存储的应用场景,支持Flink Streaming写入,下游支持各种计算引擎的批量查询(Batch Read)或OLAP查询。
目前 Hudi、Iceberg 也具有以上能力,那 Flink Table Store v0.2 对比它们有什么特点?
第一个特点 ,Flink Table Store 湖存储面向Flink写入,需要支持Flink Streaming SQL产生的实时更新的所有类型。包括主键更新、无主键更新和AppendOnly数据。
第二个特点 ,由于它面向Flink Streaming SQL,因此它支持实时更新。比如业界把Hive、Iceberg作为偏离线的数仓,Hudi作为近实时的数仓。而Table Store想要支持的是更快更大吞吐的实时更新。
Table Store需要哪些能力满足以上两个特点? 从 写入 和 读取 两个方面来说明。
在写端,首先,所有的更新都应基于存储自身而不应依赖Flink的状态,这样的好处是易用性非常高。由于存储的更新不依赖写入作业的状态,写入作业可以在流处理和批处理之间随意切换;其次,存储是基于非常高效的LSM的Sorted Merge,因此它的更新性能非常高。
对于读端,基于LSM非常快速的Sorted Merge,可以实现高效的 MOR(Merge On Read),有序的合并开销非常低,对比Iceberg或者Hive这种Copy On Write(COW)表的查询时延差不多。同时,由于数据按照主键排序,相当于主键上有索引。如果有基于主键或部分主键的Filter或Range Filter 查询,查询速度会非常快。因为底层基于排序的查询已经排除掉大量的文件,点查最快可以在100毫秒返回。
图 2 离线数仓加速
2. 场景二:Partial Update(COALESCE)
如图3中的 CREATE TABLE 语句中定义了一个 pk,然后定义 merge-engine 为partial-update。图3中INSERT语句写入数据时merge两张表,每张表更新的字段不同,其中表Src1更新column_1,表Scr2更新column_2。这里写的方式与传统的 Partial Update 有些区别,是将不需要更新的字段设置为 NULL 。这里的 Partial Update类似于SQL引擎中的COALESCE函数,非NULL字段