Fluss 是什么？Flink 为什么需要一个流存储？
面试怎么回答
Kafka 做实时数仓存储有几个痛点：行式存储只能整行读，宽表下游只用几列也得全读；不支持主键更新和点查，去重和维表要靠 Flink 状态或外部 KV；双流 Join 状态巨大；实时数据和湖里的历史数据割裂。Fluss 是为实时分析设计的流存储，日志表用 Arrow 列式存储，支持列裁剪；主键表支持 upsert、自动产生 Changelog，还能按主键点查当维表；数据自动分层到 Paimon，查询时实时和历史合并读，做到湖流一体；配合 Flink 的 Delta Join，Join 时直接查存储，不再在状态里存全量。Kafka 适合通用消息传递，Paimon 是分钟级的湖存储，Fluss 介于两者之间做秒级实时层。它生态还不成熟，一般从宽表、维表、大状态 Join 这些痛点场景切入。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Fluss 是阿里 2024 年底开源、2025 年进入 Apache 孵化的流存储项目，定位是「为实时分析设计的流存储」。面试官问这题，不是要你背它的 API，而是想看你清不清楚 Kafka + Flink 这套实时架构的痛点。
Kafka 做实时数仓存储的几个痛点
- 只能整行读：Kafka 消息是行式的，一张 100 个字段的宽表，下游只要 3 个字段也得把整条消息读出来反序列化，网络和 CPU 浪费严重；
- 不支持更新：Kafka 是追加日志，主键更新只能靠下游 Flink 用状态去重，或者把 Changelog 交给下游处理；
- 不能点查：维表 Join 需要按主键查询，Kafka 做不到，只能另外放 HBase / Redis；
- 双流 Join 状态巨大：两条流 Join 要把历史数据都存在 Flink 状态里，状态动辄几百 GB 到 TB，Checkpoint 和恢复都很慢；
- 和湖仓割裂：实时数据在 Kafka，历史数据在湖里，要维护两套链路和两份数据。
Fluss 的设计
- 列式流存储：日志表底层用 Arrow 列式格式存储，读的时候支持列裁剪，只读需要的列，宽表场景下读取量大幅下降；
- 主键表：支持按主键 upsert，自动生成 Changelog 给下游消费，同时支持按主键点查，可以直接当维表用；
- 湖流一体：数据会自动分层（Tiering）到 Paimon 等湖格式，近期数据在 Fluss、历史数据在湖里，查询时可以合并读两部分，对用户来说是一张表；
- Delta Join：Flink 新版本的 Delta Join 可以借助 Fluss 主键表的点查能力，Join 时直接去存储里查另一侧的数据，而不是在 Flink 状态里存全量，大状态问题大大缓解。
和 Kafka、Paimon 怎么区分
- Kafka：通用消息队列，生态最成熟，适合系统之间的消息传递、事件总线；
- Paimon：湖存储，分钟级新鲜度，适合大规模历史数据和批流一体分析；
- Fluss：毫秒到秒级的实时分析存储，介于两者之间，主要服务 Flink 实时计算和湖仓的「实时层」。
现实情况
Fluss 还在快速发展期，生态（连接器、运维工具、社区经验）远不如 Kafka 成熟。落地时一般从宽表列裁剪、维表点查、大状态双流 Join 这几个痛点最明显的场景切入，而不是一上来替换全部 Kafka。