2天的Flink Forward Asia 有什么值得关注的点

本文于12.8首发于公众号“狗哥琐话”。系是B站视频的文字稿。有兴趣的同学可以看B站的视频，搜索“抽象狗哥”。

11月29号和30号，Flink Forward Asia 在上海举行。这篇文章给大家搞个省流版，聊聊有什么值得关注的点。

Flink近2年的一个大动作就是把Flink的场景从流式计算到流式湖仓，主要是依托于Apache Paimon来建设的。

流式湖仓和实时数仓是两回事啊。新鲜度上有很大的差别，前者是分钟级，后者是秒级甚至可以到毫秒级。

那Flink已经变成了业界的事实标准。接下来更多是拥抱云原生和AI大模型去做一些事情，以及通过物化实图完成业务层的流批一体。这就是2.0要做的事了。其次是是做了一些非兼容改动的，因此一些connetor的API也需要重新适配。

感觉到时又要给我的插件肝一波了。

2.0展望

云原生

而在云原生这块。主要是围绕着计算和存储解耦展开。众所周知，Flink的状态和TaskManager是有点耦合的，状态一大首先是内存猛猛飙，然后恢复也慢，这种大状态下稳定性会遇到很多挑战。

怎么解呢？搞了个新组件ForStDB。

当年隔壁RisingWave锤Flink其中一个点就是大状态管理啊，说Flink架构太老，有历史包袱，和云原生没什么关系。这下Flink跟上来了。里面有一些技术亮点，后面如果内容反馈不错我会更新对应的内容。

流批一体

流式和批式的数据、代码都是一份，同时满足实时、离线数据的需求。这个我之前还追踪过，是一个非常有价值的事情。天下痛Lambda久已。

2.0还有一个要做的事是物化视图的支持。其实关注Flink发展的同学应该知道，它在1.20版本里就透出了物化视图的MVP版本。

paimon的确一定程度上解决了流批一体存储上的问题，它支持流读流写，批读批写。

但是计算上是有点不同的。因为离线数据是面向静态的，一个个分区算的。而实时是基于无限的流。那么怎么解呢？用物化视图。总得看下来，物化视图的确完成了代码的上的流批一体。

对于更新、回刷，也做了一些支持。

这里面还提到了一些成本优化。

AI支持

在FlinkSQL中，用一些新语法来支持对于大模型的调用。像建catalog一样，定义大模型的输入输出以及参数。

这个方案已经投票通过了，正在开发中。

Paimon1.0

这一节上来先说了一下，Paimon现在能做降本，也能提升数据新鲜度。这是得益于它和Flink生态的结合，因为这玩意儿的前身是叫FlinkTableStore，自然和Flink的联动性是最强的，这波2.0有很多功能是一起迭代出来的。

但它不局限于Flink的生态啊，对上也都是开放的。对于AI支持也是有做的，Python API和Object Table（管理非结构化数据）都是支持的。

功能概览：

然后也请一些嘉宾（来自Vivo、淘天、抖音）讲了下Paimon可以做什么事啊：

• 离线加速场景：

<!---->

• • ODS准实时写入
  • DWV、ADS：更快产出

<!---->

• Lambda链路优化，降本。
• 更新场景，很方便的数据拼接。避免大状态问题。
• 简单的分析场景：upsert模式，拉mysql数据。做一些查询分析，不用做分区，配合时间旅行，很舒服。甚至湖上建仓，上面套SR，也很方便。
• 当作一个延迟分钟级，可以查询、去重的MQ。那就可以给真正需要实时的业务分流，去重还可以减少下游计算资源的浪费，具备查询意味着还可以做一些简单的分析。
• 当中间层的宽表建设也可以。降低下游去消费去重的成本。

总结：

Fluss

那如果说Paimon在分钟级的流式湖仓势头正盛，那么Fluss就要在秒级、毫秒级的实时数仓场景发力了。

动机是：实时数仓一般都是用Kafka中间做数据链接的，但是Kafka有几个问题：

1. 不支持更新。这意味着下游作业要去做去重，浪费资源。然后修数、数据复用都挺不好整。
2. 无法探查。因为它是全扫描的方式去读的，根据特殊条件去点查根本不可能。
3. 数据回溯难。主要因为TTL、然后回溯的时候IO以及page cache都会被影响，追起来也慢。
4. 网络成本高。很多数据只要一些例，但是每次消费都是整行拉出来，浪费网络带宽。Kafka最耗钱的资源在网络带宽上，以阿里的场景为例，88%成本在网络带宽，然后拉出来的数据中，只有49%的列用到了。

那总得来说呢，Kafka主要是为了流消息设计的，不是为流分析设计的。

额外提一嘴，其实我在生产实践的时候，前3个点是可以通过TiDB解决的。然后数据也可以基于TiCDC吐出来。然后我们看下去，会发现Fluss和TiDB有一点点像。

PPT里用了一个四象限啊。在左上是流式，基于行的数据引擎。左下不废话，右下式表式，基于列的数据引擎。显然还缺一个基于列的流引擎。这就是Fluss，老哥说这项目搞了两年。名字来源于：

那这里呢，老哥说Flink其实也是德语里快的意思啊，刚好Fluss也是德语里河流的意思。致敬Flink一波。然后就讲了一下里面的设计：

基于列存，然后根据请求在服务端裁剪，直接减带宽，加吞吐。

里面的实现是基于两份存储来实现的。正常批读走KV，流读Log。聪明的你肯定会觉得很奇怪，为什么Changelog无需去重？如果我发生多次更新，难道一直等在那边吗？一更新就发就不是还要去重吗？后面如果内容反馈不错我会更新对应的内容。

这里也提到，Fluss也可以搞冷热数据分层。

然后放了一张总结的PPT：

最后呢，老哥提到了在Flink双流join大状态下解决的问题。这点对于大状态作业真的很有吸引力。

而且它Fluss还做可以让状态与作业解耦。因为state是flink里的黑盒，出问题只能全部重跑。

这么看下来，Flink 2.0全家桶一把梭上去，会比以前的建仓成本更低。