Flink Table Store v0.2 应用场景和核心功能

导读： 本文讲分享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字段更