入门向：下一代实时计算基础设施-Fluss

本文在绿泡泡“狗哥琐话”首发于2024.12.15 <-关注不走丢。

上期讲Flink Forward Aisa的视频比较受欢迎，这期加更讲Fluss。

为了方便新观众了解Fluss。简单介绍一下Fluss，这玩意儿主要是为实时分析而生的流存储。

所以它会有和Kafka一样的能力，但是比起Kafka，多一个直接查的能力。

用在数据湖场景，比如配合Paimon，那么就可以当作一个实时层，整个链路的延迟会更低。

总体概览

接下来看一下它的架构。

从架构图上看挺清晰的。主要是角色就是Coordinator和TableServer。

Coordinator相当于控制面，管元数据和一些集群操作（比如数据平衡啊、节点故障的切换啊之类的）。

TableServer负责数据存储并直接面向用户提供IO服务。主要由两个部分组成：

• LogStore
• KvStore

因为Fluss支持两种表的创建，一种是日志表，相当于是Kafka的场景，支持流读流写。这种表用上LogStore组件就行了。

还有一种是主键表，对于同个主键的操作是upsert的。这里的话就要用到KvStore了，LogStore在这个时候的作用就是发CDC的，然后做个WAL的存储。

其他的角色：

• ZK是用来协调Coodinator，还有存储它们的一些元数据。
• Remote Storage主要是做LogStore的分层，以及KV Store数据的持久化——快照级。LogStore里是明细级。但这里并不只是个备份，客户端的读是会打到上面去的。

经典的数据分布

经典的OLAP分布方式Fluss里面都是有的——分区和分桶。一般来说分区都是按时间来分的，也支持在SQL里写出TTL。

分桶支持三种算法，Hash（主键表默认），Sticky（日志表默认），Random。

日志表默认Sticky是因为它可以实现更大的批次写入。相当于把一定时间的写入的数据直接打到硬盘一个地方，那就是纯纯的顺序写。等这波过去了，负责元数据管理的组件会去看看，要不要换个桶让你写，这样可以让数据均匀点。

那这种数据分法方式适合对数据顺序无要求的情况。有要求还是走主键分发的。

配合Flink的LakeHouse

LakeHouse是目前大数据里比较新的架构。主要是结合湖仓的能力，尽量通过少的技术栈满足业务需求——即存储成本、可靠性、分析能力。

在文档里呢，我们可以看到Fluss配合Paimon+Flink，可以在原有的LakeHouse能力基础再加上实时分析的能力。

这种能力在FlinkSQL中是非常灵活的。你可以声明一张表，但表下面其实由Fluss和Paimon组成。然后你就可以享受到实时分析了。

如果某些情况下，你需要性能更好，但是接受延迟高点。那么你可以直接用$lake来查Paimon的数据。带上$lake以后，你就可以把它当普通Paimon表来查了，比如time travel之类的

小结

这么下来，相信大家对于Fluss有个大致的了解了啊。

上期关于Fluss的问题，其实是身边一个小伙伴提出来的，如果你有相同的疑问，说明你的确有思考啊。ChangeLog无需去重——是指Fluss自己做了upsert的能力，如果没有这一层，那么一般是做在下游的Flink作业里的，就需要物化所有的数据到state里。

如果这期的内容足够受欢迎，那么后面的文章我将会带大家深挖Fluss里的一些技术：

• 文档里提到的Apache Arrow优化了大批量写入，是做到的？
• Fluss的LogStore其实很多设计借鉴了Kafka，它和Kafka的区别在哪里？有没有什么trade off在里面？
• 大幅降低成本，解决双流join的deltaJoin是怎么个事儿？
• 完全不用本地盘的Zero Disks是怎么做的？业界里有什么成熟的实践吗？