夜雨聆风原文：https://fluss.apache.org/blog/fluss-for-ai/
作者：Giannis Polyzos
翻译：雪尽
实时智能系统的 Data Infra
Apache Fluss最初作为面向实时分析的流式存储（Streaming Storage）而诞生，设计之初便与 Apache Flink 等流处理引擎紧密协作。它始终专注于数据新鲜度、高效的分析型访问以及持续数据流，让快速变化的数据流无需经过批处理系统或纯日志管道，即可被直接使用。
过去一年，Fluss 的定位已超越了最初的框架。你会看到它被描述为"面向实时分析与 AI 的流式存储"。这一变化反映了当今数据系统的使用趋势：越来越多的工作负载依赖于持续更新的数据、对持续演进状态的低延迟访问，以及在上下文变化时进行推理的能力。
在此语境下，"AI"并非指在 Fluss 中训练或部署模型，而是指一类依赖于新鲜特征（Fresh Features）、动态上下文和实时状态来持续做出决策的智能系统。无论这些系统使用传统机器学习模型、新兴 AI 技术，还是二者结合，它们都依赖于相同的Data Infra。
这一转变解释了 Apache Fluss 近期的演进方向，对无状态计算（Stateless Compute）、更丰富的数据类型，零拷贝的 Schema Evolution的支持，以及通过集成 Lance 实现的向量支持，这些投入都源于一个核心问题：
一个能够可靠、大规模支撑实时智能系统的Data Infra，应该是什么样子？
本文将回答这个问题。我们将解释从 Apache Fluss 视角出发，"AI"意味着什么，以及为什么以流为中心的特征、上下文和状态基础设施，对构建下一代智能系统至关重要。
我们所说的"实时智能系统"
在本文中，"实时智能系统"并非特指某一类模型或某种 AI 技术，而是描述一类由其随时间推移的行为方式和与持续变化数据的交互模式所定义的系统。
这类系统至少具备以下特征：
首先，它们持续摄取实时数据：事件、更新、交互、信号——来自周围世界的各种数据。数据永不停歇，系统也需要持续跟进，在数据到达时即刻处理，而非等待周期性的批处理窗口。
其次，它们维护随时间演进的状态。这些状态可能代表用户画像、计数器、风险评分、偏好、嵌入向量（Vector Embeddings）或衍生特征。关键在于，状态不是静态的——它随新数据到来而增量更新，旧信息也会随时间推移变得不那么相关或被淘汰。
此外，实时智能系统需要反复进行决策——并非每天一次或每个作业运行一次，而是持续不断地进行评分、排序、过滤、推荐或触发行动。其输出需要随条件变化而自适应调整。数据、状态与决策之间的反馈回路是紧密且持续的。
从流式存储系统的角度来看，这一定义至关重要。智能可能来源于 ML 模型、规则引擎、LLM 或 Agent，但系统本质上是关于数据加上随时间演进的状态。新鲜数据、历史上下文与持续更新的状态才是真正的输入——而高效实现这种组合，正是Data Infra的关键价值所在。
Fluss 的起源：面向实时分析的流式存储
要理解 Apache Fluss 为何朝着当前方向演进，需要先回顾它最初要解决的架构问题。传统流处理系统擅长快速传递事件，但在让这些事件在流动过程中便于查询方面，效果却不尽如人意。
由此产生了一种常见架构：生产者写入 Kafka，Flink 等流处理器消费并处理数据，状态存储在计算层内部，结果被推送到多个下游系统。分析查询通常发生在后期，针对的是通过异步方式填充的 OLAP 系统或数据湖仓（Lakehouse）。
随着时间推移，这演变成一个熟悉但复杂的技术栈：Kafka 负责传输，Flink 负责计算，数据库存储最新状态，OLAP 引擎支撑分析，数据湖仓存储历史数据。每个组件都解决了实际问题，但同一份数据需要在每一层被复制、转换、重新摄入。
这种重复带来了代价：数据管道（Pipeline）变得难以理解，数据新鲜度在不同系统间参差不齐，基础设施成本随各层维护独立存储和索引策略而攀升。简单地查询"当前正在发生什么"往往意味着要对接多个从未设计为协同工作的系统。
Apache Fluss 正是对这种碎片化的回应。其核心理念是：一次性摄入流式数据，持久化存储，并使用分析型访问模式实现近实时直接查询。与将流视为短暂传输通道不同，Fluss 将流视为持久数据集——一个既能服务于持续处理，又能支撑实时分析的数据集，无需频繁的数据搬运。
过去一年：三大关键投入，重新定义 Fluss 的可能性
Apache Fluss 是一个开源项目，过去一年的演进体现了深思熟虑的架构选择，而非零散功能的堆砌。这段时间的投入始终围绕一个核心问题：
对于持续运行、有状态且需要随时间演进的系统，它们需要怎样的Data Infra？
这些投入聚焦于三大领域。每一项都解决了我们在真实流式架构中观察到的反复出现的瓶颈，每一项都推动 Fluss 超越其原本"仅是"实时分析流式存储的角色。三者共同定义了 Fluss 能够支撑的下一阶段能力。
第一项投入聚焦于计算与状态的交互方式；第二项解决实际系统在数据模型层面的演进问题；第三项将 Fluss 扩展至向量领域——这已成为众多智能工作负载的基础。虽然乍看之下这些领域相互独立，但它们在系统层面相互强化。
重要的是，这些变化也影响了 Fluss 在更广泛数据湖仓生态中的定位。我们强化了其作为持久化、可查询层的角色，能够与 Flink、Spark、DuckDB 等引擎互操作，并与 Apache Iceberg、Paimon、Lance 等开放表格式（Open Table Formats）无缝集成，而非作为一个游离于数据湖仓之外的专用系统。
以下是对每项投入的深入剖析：它们各自的重要性，以及如何共同推动 Fluss 成为实时智能系统的长期Data Infra。
投入一：无状态流计算（Zero-State Streaming）
现代流式架构最明确的趋势之一是计算与状态的分离。过去一年，我们在无状态流计算上投入巨大，核心理念是：计算应轻量、可替换，而状态应持久化、外置化。
在许多传统流处理系统中，状态存储在流处理引擎内部。这导致长周期状态与计算运行时紧密耦合，使得故障恢复缓慢、扩缩容成本高昂、运维复杂度居高不下。重启或调整作业规模往往意味着在系统恢复可用之前，需要重建大量状态。
采用无状态计算后，流处理引擎专注于纯粹的计算处理，而持久化状态由 Fluss 在外部管理。计算变得可丢弃，状态则保持稳定且可查询，独立于任何单一作业或运行时。
这种分离带来更快的故障恢复、弹性伸缩，以及显著简化的运维复杂度。它还为有状态作业提供了更强的 RTO（恢复时间目标）和 RPO（恢复点目标）特性，因为状态不再被困在临时的计算容器中。
对于实时智能系统而言，这一点至关重要。因为这类系统天然是持续运行的，依赖于不断演进的状态。使计算无状态化[1]，让团队能够迭代业务逻辑、扩展工作负载、从故障中恢复，而不会动摇建立在状态之上的智能系统。
投入二：复杂数据类型和零拷贝 Schema Evolution
如果 Schema Evolution 是痛苦的，创新就会放慢，技术债务就会堆积。真实系统不会一成不变，其数据模型亦然。随着时间推移，新字段被添加，现有结构变得更加嵌套，起初简单的记录逐渐积累更丰富的上下文。
为此，我们投入了对复杂数据类型和零拷贝 Schema Evolution（Zero-Copy Schema Evolution）的支持。这使 Fluss 能够处理丰富的嵌套结构，而无需强制用户扁平化数据或在每次需求变更时重新设计Pipeline。
零拷贝 Schema Evolution意味着 Schema 可以演进而无需重写现有数据或触发大规模迁移。一条记录可以从几个标量字段扩展到包含嵌套结构、上下文属性甚至嵌入向量，而旧数据仍然有效且可访问。
这一能力在 Fluss 既作为流式存储又作为更广泛数据湖仓架构一部分的环境中尤为重要。通过与开放格式对齐并改进与 Apache Iceberg 等系统的互操作性，Fluss 可以参与分析工作流而无需添加严格的 Schema 限制。
对于智能系统，这种灵活性不可或缺。特征、用户画像和上下文记录快速演进，Data Infra必须跟上节奏，同时不能破坏Pipeline或强制进行昂贵的重新计算。
注意：Schema 变更也会向下游传播到 Apache Iceberg、Paimon 和 Lance 等开放表格式，确保数据在不同系统中保持可访问和可用。
投入三：向量支持和 Lance
现代智能系统越来越依赖嵌入向量（Vector Embeddings）来表示文本、图像、音频和视频等非结构化数据。这些嵌入支持基于相似度的查询，是语义搜索、推荐和内容发现等场景的核心能力。
传统上，向量存储在专用的向量数据库中，与流处理系统和数据湖仓分离。这种分离又引入了一个数据孤岛，伴随而来的是额外的数据摄入Pipeline和一致性挑战。
过去一年，我们通过与 Lance 集成，致力于将向量支持引入 Fluss。这使得向量数据可以与结构化数据和流式数据共存，而非被隔离在独立系统中。
通过将向量与其他数据共同存储，Fluss 可以支持混合工作负载——结构化属性、流式信号和向量嵌入都成为同一逻辑数据集的组成部分。这也与正在进行的数据湖仓工作相契合，使得向量感知的工作负载更容易与分析引擎以及 Iceberg 等表格式集成。
对于实时智能系统，这显著降低了集成摩擦。当向量不再是独立孤岛时，构建端到端Pipeline——从数据摄入到特征生成再到检索——就变得更简单、更一致，且更易于大规模运维。
你可以在这里找到一个快速上手教程[2]。
"顿悟"时刻：实时特征存储和零偏差设计
当这些能力汇聚在一起时，我们开始注意到一个反复出现的模式：越来越多的团队提出了实时特征存储（Feature Store）的需求，即便他们并没有明确要"构建一个特征存储"。一旦流式数据、持久化状态和低延迟访问在同一个系统中融合，这种需求就会自然涌现。
从本质上讲，特征存储的存在是为了计算和服务特征——即机器学习模型所消费的结构化输入。这些特征可能代表近期活动、聚合行为、衍生指标，或持续更新的评分，用于捕捉实体随时间的变化。
特征存储之所以存在，根源在于生产环境 ML 系统中一个众所周知的失效模式：训练数据通常由批处理管道离线计算，而推理数据则由流式或请求时逻辑在线计算。随着时间推移，这两条路径在逻辑、时序或语义上逐渐分化。
这种分化通常被称为训练-服务偏差（Training–Serving Skew）。它微妙、难以早期发现，却是大量模型在生产环境中表现不佳的元凶——尽管它们在训练和评估阶段看起来完全正确。
一旦从Data Infra的视角审视这个问题，答案就变得清晰：消除偏差的关键不在于增加更多工具，而在于确保训练和服务建立在相同的底层数据之上，使用相同的语义。
为什么选择 Fluss 作为特征存储？
由于 Fluss 持久化存储流式数据，它既可以作为历史记录，也可以作为持续更新状态的来源——无需将数据拆分到不同系统中。
基于同一数据集，Fluss 既可以支持用于训练的历史扫描，也可以支持用于在线推理的最新状态访问。数据无需被复制、重新物化，或被重塑成两条不同的Pipeline。
这种统一才是关键性的转变。当训练和服务基于同一数据集运作，使用相同的 Schema 和更新语义时，偏差就变得更容易避免。系统通过设计本身来强制一致性，而非依赖于约定俗成。
在实际应用中，这意味着特征计算逻辑可以被共享或复用，离线特征视图与在线特征视图之间的差距大幅缩小。访问层面的区别依然存在，但数据层面的区别已被消除。
这就是为什么一旦构建了共享的、持久化的流式基座，类特征存储的用例就会自然涌现。Fluss 并非以特征存储起步，但它从架构上消除了特征存储不得不作为独立系统存在的根本原因。
译者注：很有意思的共同点，不仅在海外，在国内多家大厂内部，Fluss已经被用作ML团队的特征存储。
从特征存储到上下文存储
传统特征存储聚焦于模型输入——结构化的、衍生的属性，设计目标是稳定且可预测。这种定位对许多 ML 管道来说效果很好，但它只捕捉了实时智能系统真正需要的一部分。
实际上，这些系统，尤其是AI Agent系统依赖的是上下文（Context），而不仅仅是特征。上下文包括结构化特征，但也包括最新的实体状态、近期事件序列、用于重建的历史数据，以及越来越多用于语义理解的嵌入向量。
因此，上下文存储（Context Store）的应用范畴比特征存储更加广泛。它提供对同一底层数据的多种视角，取决于系统是在训练模型、做实时决策，还是在调试历史行为。
Apache Fluss 天然契合这一模型，因为它可以在同一持久化流式数据集上暴露多种视图。同一份数据可以作为特征表、状态存储、事件日志或历史归档使用——视图取决于用户的访问方式。
这种灵活性至关重要，因为实时智能系统很少在特征和上下文之间划出清晰界限。它们将两者融合，而Data Infra需要支持这种融合，而非强制人为分离。
多模态数据和统一访问模式
现代智能系统处理的远不止表中的行。它们将结构化记录、半结构化事件、非结构化内容以及从这些内容衍生的向量表示结合在一起。
一个实时决策可能同时依赖于：用户的最新画像、近期行为、刚刚提交的文本，以及代表查询和历史消费内容的向量嵌入。在许多架构中，这些元素分散在不同的系统中。
Fluss 的目标是让这一切感觉像一个统一、连贯的基座——通过在同一数据上支持多种访问模式。这些模式与智能系统实际消费信息的方式保持一致：
• 行式访问（Row-oriented Access）：根据特定键检索最新状态，是实时决策的基础 • 列式访问（Column-oriented Access）：跨多个实体扫描属性，支撑分析和模型训练 • 向量访问（Vector Access）：实现语义相似性搜索与检索
通过在共享基座上融合行式、列式和向量访问，Apache Fluss 减少了系统膨胀和概念开销。智能仍然存在于模型和应用中，但它们所依赖的数据终于汇聚在同一个地方。
虚拟表：决策追踪和审计
实时智能系统最被低估的需求之一是可审计性（Auditability）。当系统持续自动做出决策时，仅仅知道"发生了什么"已经不够——你需要理解"为什么发生"以及"系统当时知道什么"。
实际上，这意味着需要能够回答以下问题：做出了什么决策？那一刻系统的状态是什么样的？哪些信号影响了结果？在决策之前状态是如何演变的？这些问题对于调试、建立信任至关重要，而且出于监管和合规原因，其重要性正在与日俱增。
这正是变更日志（Changelog）和虚拟表（Virtual Table）成为基础需求的地方。它们不再将状态视为隐藏在运行系统内部的东西，而是让状态变迁显式化、持久化。每一次更新都成为可查询、可重放、可检视的数据。
基于变更日志构建的Fluss虚拟表，允许系统将决策和状态演变视为一等公民。系统不仅记录最终结果，还记录随着数据变化，它是如何一步步到达那里的。
对于实时智能系统，这将可审计性从传统的事后补救转变为架构的内置特性。
变更日志实战：追踪AI 决策的演变
设想一个实时系统，负责决定是否批准或拒绝交易。对于每个用户，它维护一个持续更新的决策上下文，包含风险评分、近期活动频率、总消费额和账户状态等字段。
应用计算这些上下文并将其作为变更日志表（Changelog Table）输出，其中每次更新都表达为语义变更，而非完整覆盖。变更日志事件遵循简单模型：插入（Insert）、更新（表达为撤回加新值）和删除。
例如，假设 user_id = 123 的用户有以下变更日志序列：
+I user_id=123, risk_score=0.12, velocity_10m=1, total_spend_24h=35-U user_id=123, risk_score=0.12, velocity_10m=1, total_spend_24h=35+U user_id=123, risk_score=0.47, velocity_10m=5, total_spend_24h=120-U user_id=123, risk_score=0.47, velocity_10m=5, total_spend_24h=120+U user_id=123, risk_score=0.83, velocity_10m=9, total_spend_24h=240每次更新都捕捉了用户风险画像随新事件到来而演变的过程，而非将这些变迁隐藏在单独的一行可变数据背后。
重建决策现场
在某个时刻，系统评估一笔交易并做出决策。由于变更日志被持久化存储，这个决策不再是黑盒。你可以精确重建决策时刻系统的状态，并追溯它是如何通过之前的更新到达该状态的。
这使得回答具体问题成为可能：哪些信号推高了风险评分？何时跨越了阈值？在变化的条件下，决策逻辑是否按预期运作？
重要的是，这种重建不依赖于日志或临时埋点，而是自然地从数据模型本身产生。
变更日志作为审计追踪
一旦变更日志被视为不可变的、只追加的记录，它们就成为强大的审计追踪（Audit Trail）。每一次变更都被捕获、打上时间戳，并与其更新语义和血缘关联起来。
同样的方法可以应用到决策状态之外。团队可以使用相同的底层机制追踪训练数据版本、模型预测、特征定义和用户画像演变的变化。
不再需要问"系统为什么这样做？"然后祈祷日志还存在——答案就在数据中。什么变了、何时变的、如何变的、哪个作业或模型产生了这次更新——全部被保留。
对于大规模运行的实时智能系统，这种透明度不仅是良好的工程实践，更正在迅速成为基本要求。
未来方向
Apache Fluss 最初作为面向实时分析的流式存储而诞生，专注于让持续变化的数据在到达时即可查询。这一基础塑造了系统围绕新鲜度、持久性以及与流处理引擎紧密集成的核心假设。
过去一年，我们的投入将 Fluss 扩展到了分析之外，同时没有放弃最初的核心定位。无状态计算和外置化状态改变了系统的伸缩与恢复方式；对复杂数据类型和零拷贝 Schema Evolution的支持，使数据模型能够持续增长而无需反复重写；向量支持和 Lance 集成则将非结构化与语义数据纳入同一Data Infra。
与此同时，整个行业的方向也日益清晰。智能系统依赖于共享的实时上下文——涵盖特征、状态、历史和向量。类特征存储（Feature Store）的能力不再是小众需求——它正在成为持续运行、随时间自适应的系统的核心构建模块。
这些脉络汇聚成我们正在坚定推进的方向：Apache Fluss 作为以流为中心的Data Infra，支持实时分析、特征与上下文访问、多模态数据、决策追踪和可解释性。所有这些都构建在无状态、高弹性的流式应用之上，能够在不动摇系统稳定性的前提下持续演进。
这就是 Apache Fluss 在"AI"上下文中的含义：
——不是模型平台，也不是框架，而是实时智能系统赖以可靠、透明、大规模运行的数据与状态的Data Infra。
参考文档:
[1] https://www.ververica.com/blog/introducing-the-era-of-zero-state-streaming-joins
[2] https://lancedb.com/blog/fluss-integration/
欢迎 star 🌟 和加入 Apache Fluss 贡献：
https://github.com/apache/fluss/
欢迎加入“Fluss 社区交流群”群的钉钉群号： 109135004351
Flink Forward Asia 2026 将于 6 月 26 至 27 日在深圳举行，现面向全球征集议题。活动聚焦实时计算与 AI 的融合，欢迎开发者与 AI 从业者提交创新思路与实践经验。议题将经过专业评选委员会审核，提交截止日期为 5 月 29 日。参会嘉宾可免费报名，获取技术前沿与行业动态。期待您的参与，期待您的参与，共同探索实时 AI 的未来！
PC 端：https://asia.flink-forward.org/shenzhen-2026
打开 FFA 2026 官网，点击「议题征集」或者「参会」
移动端：扫描下方二维码或点击文末「阅读原文」
 （扫描二维码，提交议题） |
（扫码即刻抢占席位） |
点击「阅读原文」跳转 FFA 2026官网提交议题或报名 ～
