【FFA 2026】Agentic Lake 1 流存储 Fluss 让数据湖学会流动让 AI 秒级感知世界

演讲人晟柏阿里云Flink&Fluss产品离线系统：存储层清晰演进Greenplum/Redshift/Teradata等自带专属存储引擎，计算与存储紧耦合HadoopHadoop时代HDFS成为统一的分布式存储底座，MR/Hive/Spark共用一套存储LakehouseLakehouse时代对象存储+Hudi/Iceberg/Paimon，存储格式持续进化，走向湖仓融合实时流处理：一直缺少真正的"存储"离线已进化到湖格式，实时还在用10年前的方案实时流处理需要一个真正面向分析设计的流存储——不是消息队列的升级版，而是从零设计的、面向实时数据分析的存储系统。计算引擎从Storm→Flink离线已进化到湖格式，实时还在用10年前的方案实时流处理需要一个真正面向分析设计的流存储——不是消息队列的升级版，而是从零设计的、面向实时数据分析的存储系统。KafkaKafka计算接入StarRocksRedismysql业务流业务流1业务流nKafkaKafka业务流业务流1业务流n业务数据库系统日志点击流多个Flink作业消费，kafka集群IO不够，又要扩•物流表的状态需要被持续更新，以便能快速展示最新的数据，那我只能在Flink里维持一个长周期的状态了•业务说这个数据的指标不符合预期，怀疑是数据层面有问题，这几个Topic的数据我又要导出到其他系统来分析了•业务修改了统计口径，需要我从7天前开始重新统计口径，我又要从离线库里重新把数据导入Kafka计算了×去重算子承担更新工作×去重算子承担更新工作×去重算子成本高昂×Kafka数据无法复用×难以修正数据KafkaTopicChaKafkaTopicChangelog去重Join/AggState无需额外成本生成changelog，数据数据轻松修正Recover&MaterializeKVTabletLogTabletGenerateChangelogsDumpDumptoOLAPsystemsdumpKafka×成本高支持主键点查实时维表JoinLookupJoin维表dumpKafkaTopic×组件太多dumpKafka×成本高KafkaTopic×FullscanKafka×大规模不可用Kafka×查询耗时长DumptoOLAPsystemsNetworkingCost列2列3列4平均只使用了49%的列行存列1列2列3列4××列存列1列2列3列4IPCStreamingFormat文件存储基于读写毫秒级延迟，服务端列裁剪，10倍性能提升，节省大量网络成本双流JoinKafkaTopicKafkaTopicKafkaTopicLargeStateFLIP-486双流JoinKafkaTopicKafkaTopicKafkaTopicLargeStateKvTabletKvTablet2索引点查DeltaDeltajoinKvTabletNoStateJoinState->NoState，大规模Join更稳定Flink资源减低10倍，JoinState->NoState，大规模Join更稳定Flink资源减低10倍，2300CU→200CU状态与作业解耦，提升灵活性和开发效率，中间数据可探查03020302全链路秒级•支持更新和全链路秒级•支持更新和binlog订阅流查询下推•基于ApacheArrow列存储•支持分区下推、条件下推、聚合下推•支持部分列更新，且更新后仍能生成binlog。•支持基于主键的多流实时拼接•独有deltajoin能力，避免大状态造成Flink作业高成本和稳定性问题。100TB大数据架构演进与行业痛点Lakehouse架构特点湖仓融合，在对象存储上实现仓Lakehouse架构特点湖仓融合，在对象存储上实现仓代表技术：Hudi/Iceberg/Paimon痛点：只能近实时•基于对象存储，写入延迟天然在分钟级，无法满足秒级实时场景•要做秒级实时就得前面再接一层Kafka，又回到两套系统、两份存储Kappa架构特点一切皆流，流处理统一批和实代表技术：Kafka+Flink痛点：只统一了计算•Kafka不具备长期存储能力，无法查询、无法支持更新、无法列裁剪•分析要外挂ClickHouse，维表要组件越堆越多Lambda架构特点代表技术：Hadoop+Storm痛点：一个需求干两遍•两套代码逻辑、两套执行引擎•两条链路的结果需要在Serving层合并，数据口径经常对不上•同一个需求要写两遍，上线要部署两套，排查问题要看两条链路拼图缺失：一个能原生连接"流"与"湖"的存储层。业界探索："打补丁"还是"重新设计"？ConfluentKafkaTableFlowRedpandaIcebergTopicAutoMQTableTopicStreamNativeUrsa核心洞察：在已有系统上修补行不通。真正的答案是从零设计一个同时理解"流"和"湖"的存储系统。解决方案解决方案原有方案业务数据KafkaTopicKafkaTopic实时数据层历史数据层原有方案业务数据KafkaTopicKafkaTopic实时数据层历史数据层当前方案实时数据层-FlussClusterTieringService历史数据层-DLF（Paimon）UnionReadLakehouseAnalytics多：一份数据服务多个场景实时大屏、流计算、离线分析、Ad-多：一份数据服务多个场景实时大屏、流计算、离线分析、Ad-hoc查询，同一份数据无需复制多份，流和湖共享一条链路快：毫秒级写入，亚秒级可查数据写入即可见，TieringService快：毫秒级写入，亚秒级可查数据写入即可见，TieringService自动归档到湖，端到端延迟从分钟级降至秒级DataLakeReadsDataLakeReads(PaimonAPI)(Paimon)-AnalyticalqueriesCOUNT(*),MAX(t),SUM(amount)FROMorders$lakeFlussClusterFlussClusterFlussClusterUnionReads(Streaming/Batch)AI系统的瓶颈已从模型能力转向数据时效性现状过期知识=幻觉LLM基于昨天的数据生成回答用户画像批量计算推荐"昨天的你"Agent决策基于过时上下文训练数据攒批ConceptDrift持续衰减模型精度随时间下降目标4知识秒级同步变更到达即更新知识库LLM实时消除幻觉4感知用户此刻上下文多维信号实时汇聚推荐/风控基于当下流式数据驱动模型进化增量训练持续更新模型效果跟随数据实时优化实时性要求秒级毫秒级分钟级AIAI需要一个能同时支撑毫秒级写入+实时消费+批量训练的数据底座02/07做到了·存储统一（事务+分析共享Delta）·消除做到了·存储统一（事务+分析共享Delta）·消除ETL管道·没做到（Fluss的机会）流式增量触发（数据到达无法立即驱动下游）·多流实时融合（无PartialUpdate）/毫秒级写入可见Lakebase（Postgreson对象存储）Lakebase（Postgreson对象存储）+Lakehouse共享DeltaLakehouse//RTReyden引擎，10ms响应，12000QPS消除独立servinglayerDatabricks让"分析更快"存储统一+Databricks让"分析更快"存储统一+查询加速让"数据更鲜"数据新鲜度数据新鲜度是AI时代更稀缺的能力—Fluss补全Databricks的流式短板03/07从存储引擎层原生融合流与湖，一份数据服务AI全链路PartialUpdatePartialUpdate多流各写各列不互阻塞热+冷统一查询到达即触发下游JSON直写零门槛接入列式存储(Arrow)DeltaJoinState卸载至存储增量更新/实时点查TieringService热数据自动入湖实时用户上下文多流融合→Agent点查/DeltaJoin模型持续进化StreamingRAGPaimon/IcebergKafka/MQ对象存储数据底座04/07实时更新LLM知识库—价格/库存/政策变化→过期知识=错误回答FlinkEmbedding成本降90%+数据源变更价格/FlinkEmbedding成本降90%+数据源变更价格/库存/政策向量检索引擎T=0~5ms写入可见增量，仅处理delta端到端秒级Upsert变更Chunk主键去重+增量追踪CDCCDC增量消费（仅delta）全量重建：小时~天→StreamingRAG(Fluss)增量更新：秒级Embedding成本降90%+FlussFlussCDC让知识库从"定期重建"变成"秒级增量更新"，成本降一个数量级05/07一份数据服务全链路Agent决策依赖"此刻"而非"昨天"—一份数据服务全链路行为流AIAgent点查P99<5ms客服Agent/推荐Agent对话流PartialUpdate行为流AIAgent点查P99<5ms客服Agent/推荐Agent对话流PartialUpdate位置流FlinkDeltaJoin实时推荐/风控State卸载至Fluss零开销交易流usercontext行为+对话+位置+交易多维信号实时聚合~5ms写入可见PartialPartialUpdate让多维信号实时汇聚，毫秒级点查让Agent感知用户"此刻"06/07ConceptDrift导致模型衰减—同一张表流批统一，增量+全量训练共用一份数据模型持续微调，跟随数据演进列式Arrow存储，训练IO降5–10xUnionRead热+冷数据统一查询，完整评估training_samples特征Upsert标签PartialUpdate延迟回填实时业务数据Flink特征工程用户反馈HTTPGateway07/07KafkaDatabricksLTAP/RTKafka知识库增量更新知识库增量更新无多流优化多流上下文融合无多流优化多流上下文融合训练数据流式获取批量读Delta训练数据流式获取批量读Delta事务级热/冷分离毫秒级写入可见毫秒级写入可见流+湖统一查询Kafka流+湖统一查询KafkaDatabricks客户案例c随着新能源汽车市场竞争加剧，车辆安全性越来越成为消费者考虑的重要因素。同c随着新能源汽车市场竞争加剧，车辆安全性越来越成为消费者考虑的重要因素。同2.存量上百条业务监控规则，每条规则对应一个Flink作业，传统消息队列需要为每个Flink作业准备全量读取带宽，成本极高技术需求•实时计算引擎提供作业运行观测和企业级监控告警能力，支持算子级别的资源精细化分配，提升大规模作业资源利用率•实时计算引擎支持亚秒级数据的端到端实时分析能力•Fluss仅以计算和存储计费，无带宽、流量等费用•流存储中数据支持分层存储，支持湖流一体，自动化将沉降方案架构方案架构Flink…Flink实时告警模型Spark离线数据清洗Flink信号解析消息队列Fluss（Paimon）Flink+流存储Fluss实时告警模型列裁剪核心成果：核心成果：故障建模耗时降低50%故障主动感知率>50%