想知道某位客户现在是否被封禁，系统却只给你一叠按时间排列的“创建、更新、删除”记录，你就得自己从头整理。Kafka——一种分布式事件流平台——采用的正是这种 log-first（日志优先）思路：业务持续追加事件，风控、推荐等应用各自读取，需要长期保存的数据再写入 Amazon S3 等对象存储。
问题在于，S3 只提供文件，不会自动把文件变成可查询的“当前状态”。以客户资料为例，工程团队还得处理更新与删除、数据版本、字段变化和大量小文件。Apache Iceberg、Apache Paimon 等开放表格式能补上表的元数据与一致快照，但 Kafka 到表之间仍需 Kafka Connect、Flink 等系统负责转换、提交和整理。
这便是 log-first 与 table-first（表优先）的分歧：前者把不可变的事件经过当作第一等对象，通用且便于重放；后者把持续变化、可直接查询的表放在中心。文章提到，Confluent Tableflow 试图托管 Kafka 到表的转换，而 Apache Fluss 更进一步，追问流式存储是否一开始就该以表为核心。材料未提供 Fluss 的具体实现与性能数据，但争论的关键已经很清楚：实时架构要把复杂度留给每个下游消费者，还是提前收进存储层。