Apache Fluss 深度解析：面向实时分析与 AI 的流式存储层本文基于 Apache Fluss 当前仓库源码、根 README 与website/docs文档整理。当前工程版本为1.0-SNAPSHOT，项目仍处于 Apache Incubator 阶段，部分能力与边界会随社区路线图演进。一、为什么需要 Fluss过去几年，实时数据栈大致形成了两条路线。一条是流处理路线：Kafka、Flink、Spark Structured Streaming 等系统负责低延迟摄取、计算和分发。它们擅长把事件尽快送到下游，但当业务希望在流上做分析型读取、列裁剪、主键查询、历史回放、状态复用、变更审计时，单纯的消息日志往往不够。另一条是湖仓路线：Iceberg、Paimon、Hudi、Delta Lake 等表格式负责开放存储、批量分析、事务和生态互通。它们擅长长期存储和大规模扫描，但如果把秒级甚至亚秒级新鲜度压到湖格式上，就会遇到典型矛盾：频繁提交会制造大量小文件，不频繁提交又会拉高延迟。Fluss 的定位正落在这两者之间：它不是只做消息队列，也不是只做湖格式适配器，而是一个面向实时分析和 AI 的流式存储系统。它希望把“实时流”和“湖仓表”连接起来：近实时数据先进入 Fluss 的低延迟存储层，历史数据再通过 tiering 服务持续压实到湖仓格式；计算引擎可以读实时层、历史层，也可以读二者的 union view。从用户角度看，Fluss 暴露的是表，而不是零散的 topic、state backend 或文件目录。这个