【FFA 2026】Agentic Lake 4 Fluss + Flink：构建下一代实时数仓

构建下一代实时数仓钟旭阳ApacheFlinkCommitter演讲人实时数仓经典架构的问题表语义、数据持久化、计算状态被切在三个互不理解的系统里计算引擎扛下全部计算逻辑背负TB级State状态传输管道只搬运字节流不持久化·不理解表OLAP服务层理解表结构与查询但不参与流计算痛点核心资源消耗大内存/本地盘吃紧CP反压超时Checkpoint难完成重启时间长State恢复慢数据不可探查State是黑盒Query修改代价高资源消耗大内存/本地盘吃紧CP反压超时Checkpoint难完成重启时间长State恢复慢数据不可探查State是黑盒Query修改代价高改逻辑即丢状态状态难复用任务间无法共享SLA不可控故障恢复不确定Flinkstorageco-processorFlink在用内部State充当冗余的私有索引每个有状态算子，都在重新维护一份「记住历史」的数据——而它真正需要的，往往只是一次查询记住各流的部分列记住各流的部分列按Key对齐多流拼接完整行记住对侧全量数据记住每个Key的聚合中间结果按Key累积更新一个值FlinkSQL算子Stream-StreamJoin分组聚合多流Join成宽表真正需要什么核心核心洞察Flink专注计算，Fluss承担存储、索引、合并与演进—各司其职，深度融合针对这三个问题，针对这三个问题，Co-processor提供三项对应能力：共享索引Fluss在存储层统一维护索引，多个Flink作业共享同一份索引，不需要各自在State里重建。多作业共享State不重建写时合并Flink只管写，合并逻辑（聚合、拼接、去重）由Fluss在存储层自动完成，计算侧无需维护合并状态。存储层自动聚合·拼接·去重Flink只写Evolution能力Schema变更零拷贝生效+流批一体回刷历史，改Query不需要重建State，演进无中断。Schema零拷贝改Query不重建StateFlink·计算引擎专注计算：SQL/流处理卸载offload存储·索引·合并·演进共享读取shareFluss·FlinkCo-processor在存储层承担四类协处理职责存储索引合并演进多表Join——共享索引①①两表Join传统双流Join：每侧维护对侧全量状态→级联放大→TB级②②接入第三张表③③接入第四张表物化全量·State落盘基线核心问题全量数据来建索引改表或改Join逻辑→无状态重启对用户透明—不改SQL，优化器自动改写（FLIP-486）DeltaDeltaJoinFLıP-486✓点查下推Fluss，复用共享索引✓Join算子stateless，无状态膨胀✓改Query不影响状态，随改随生效StreamingJoin传统×每侧维护对侧全量State×状态随数据持续增长，无上限×改Query＝State不兼容，需重建•OUTERJOIN•Strongconsistency双流Join状态消除•CascadedJoin秒级Checkpoint速度作业恢复速度提升x成本降低FLIP-486能力演进实测收益VS索引支持：主键/前缀/通用二级索引（WIP,v1.0）Fluss读侧凭什么扛住高频Lookup？——一条端到端的异步Lookup链路加速点加速点·缓存热Key直接命中缓存，跳过整条链路加速点·索引RocksDBiteratorseek，前缀定位批量Lookup批量Lookup·prefixseek一次往返取多KeyAsyncJoin产生大量并发Lookup请求异步合流单线程I/O单线程I/O128并发在途请求攒批缓冲Batch128/100msFlink计算侧Fluss服务存储/索引关键指标/加速点PrefixSeekseek+顺序读承接两类写入侧的冗余状态 引导问题同PK的多行/多流，如何在写入时自动合并成一行？Aggregation·实时聚合TBAggregation·实时聚合TB级AggState每个Key都要维护一份聚合中间状态同PKu01的多行写入→累加合并↓SUM合并每个Key维护聚合中间状态→这是一份冗余状态↓按PK拼接宽表拼接·多流Join又一份冗余状态部分列分散在多流缓存→又一份冗余状态两流各写部分列→按PK拼成一行读侧能卸载，读侧能卸载，写入侧同理——各靠PK表的一个能力来承接下一页下一页·存储层如何承接↓Flink无状态写入→合并由Fluss存储层完成行级Merge保留哪一整行字段级字段级AggMerge每个非PK列独立配置聚合函数SUMMINMAXLAST_VALUEFIRST_VALUELISTAGGBOOL_ANDBOOL_ORRBM32RBM64LAST_NOT_NULLFIRST_NOT_NULLPRODUCTLast-Write-WinsZooKeeper段分配10万ID/批→长标识映射为密集IntID→配合rbm32/rbm64实现实时精确去重VersionedVersion-BasedFirst-Write-WinsRoaringBitmapUV·实时精确去重多流各写一部分列（带主键Fluss存储层按PK增量拼接成完整行BitSet命中位=本次更新的目标列；非目标列保留旧值，不会被覆盖为空。Fluss存储层按主键u01增量合并·BitSet追踪目标列nameagescore只写score、level两列nameagescore——95完整行PKu01两流的部分列在存储层自动补齐为一整行StreamAPKu01只写name、age两列StreamBnameageAlice28scorelevelnameAlicescore95levelAlevelAage不再需要Join攒宽表——各流独立写入部分列，存储层自动拼接成AIAgent把瓶颈推到了数据迭代瓶颈不在推理，而在数据层缺AI-readydata的项目将被放弃Pinterest专建backfill基建提速模型部署后随时间退化agenticAI卡在数据准备Agent的工作循环：每一轮都要动数据每一次特征迭代，都要完整跑通这条数据管道——慢的不是推理，是数据↻↻迭代·每轮重复为什么慢Agent秒级生成假设，部署却要小时到天级瓶颈在数据层，不是推理速度数据源加特征评估指标对比/折线训练当前基础设施难以跟上Agent的迭代速度传统Stateful架构下，Agent每次演进都要同时付出这四笔成本——叠加起来要数小时到天级历史算子状态无法复用+作业中断，从零拉起+重放全量、回追时间窗小时到天级逻辑一变，执行图被重写+一次Agent演进，传统Stateful架构vsDelta化Stateless的代价对比旧状态旧状态✗作废，从头重建历史回追✗重放全量+重建S维度传统架构·State在FlinkStateless·State在Co-processor分钟～小时级小时～天级L1–L4四级演进·成本由低到高·90%的Agent操作落在L1–L3L1–L3覆盖90%+场景成本低AGENT行为成本低AGENT行为成本AGENT行为例如：裁剪输出列成本中AGENT行为例如：加特征列/改逻辑成本高AGENT行为维持现状批Bootstrap快速回追历史→到切换位点→流续跑增量，迁移与冷启动收敛成一次性Batch连续输出·Exactly-Once直读远程从offset热层/实时冷层/历史高效扫读直接读取远程文件长周期历史回追解锁超长回溯场景直读远程存储，不干扰Fluss集群更大带宽高效扫读直接读取远程文件长周期历史回追解锁超长回溯场景直读远程存储，不干扰Fluss集群更大带宽Agent改schema、回刷历史、再训练，持续迭代ValueDecoderValueDecoder生成新特征假设Zero-CopySchemaEvolutionADDCOLUMN毫秒生效v3+cityv2+score训练+评估保留/丢弃/迭代ADDCOLUMNLAST仅追加尾列·毫秒生效v1旧行不迁移零数据迁移批作业回刷历史Summary传统架构vsWithCo-processor——冗余状态消除·演进零拷贝·Agent迭代闭环提速TB级冗余状态TB级冗余状态·Join状态级联放大共享索引·stateless·消除冗余状态TB级状态卸载多表Join秒级生成假设、小时级～天级部署验证闭环缩短到分钟～小时级AIAgent迭代传统架构WithCo-processor能力持续演进，欢迎参与共建v1.0v1.0v0.8v0.7v0.7GitHub:/apache/fluss|Slack:#fluss|邮件列表:dev@AIAgent湖仓分析与运维闭环演讲人DLFDLF全托管湖仓：PaimonAgen.cLake的底座统一元数据|存储优化|安全治理|开放30%存储成本降低2湖仓运维的关键缺口：看见不等于诊断Compaction延迟|CommitFailed|小文件膨胀|成本攀升成本攀升成本攀升Compaction延迟3Monitoring→Observability→AIOps→AutoRemediation→AutonomousOps行业对标4没有实时指标的AI没有实时指标的AIAgent无法感知Compaction进度和SortedRun堆积不知道写入延迟是10秒还是10分钟无法区分“暂时抖动”和“持续退化”根因分析=基于静态信息的“合理猜测”有实时指标的AIAgent实时感知表健康度、写入延迟、Compaction状态实时追踪SortedRun数量、文件大小分布毫秒级感知Commit成功/失败/冲突类型根因分析=基于实时证据的“精准诊断”→结果：correctandactionable（准确可行动）MetricsasSensors：实时指标是AIAgent的感知器官，也是自治湖仓的“数字神经系统”5 6两步架构把运行态指标变成自治决策STEP2智能分析中枢STEP2智能分析中枢Supervisor编排Compaction延迟指标(≥600s告警）7让Agent读到实时运行态8指标管道把运行态沉淀为可查询数据从运行态到Paimon指标表p关键设计决策p关键设计决策9多维度告警分级自治用可审计边界建立信任L2可逆操作自主L3“帮我看看dws_order表最近为什么查询越来越慢，有没有成本风险？”经验教训：指标即数据、专家分工、证据可审计“AI可互换，知识库不可”治理与安全DLF全托管vs开源自建：Agen.cLake的底座对比无先感知，再诊断，最后自治让AI感知湖仓“心跳”行动号召用Supervisor+专家Agent构建分析中枢——让AI“可信赖”分级自治，渐进信任——让运维“可进化”DLF全托管+开源贡献——让方案“可复制”扫码加入DLF钉钉交流群群号：106575000021交流DLF、Paimon与全模态湖仓实践魏子珺 不只是搜索、开箱即用的企业能力、Agent入口背景痛点、索引构建、Elasticsearch在线查询支撑LakeSearch的关键特性 云原生内核、向量引擎、存算分离、多租不只是搜索、开箱即用的企业能力、Agent入口一站式数据检索平台：丰富索引结构、检索分析能力与高性能向量引擎多形态数据统一建模多形态数据统一建模->实时索引构建->全文/过滤/向量混合检索->聚合分析->AI搜索高性能自研内核、认证授权、TLS、快照、生命周期、冷热分层与监控治理AgentBuilder组织流程，AgentMemory形成长期上下文。横向流程关键词、向量、语义精排与权限过滤，沉淀可召回上下文。contextretrievalcorestructureddatagroundedchunks为什么数据湖需要新的检索入口多模态数据沉淀在湖里，AI应用需要低延迟、可治理、可复用的召回入口•开放格式与离线加工>LakeSearch检索入口•filter/rerank/fetchsou•权限与引用边界>•groundedanswer•memory/tools/citations•可治理的上下文LakeSearch把湖表转化为标准、低延迟、可治理的AI上下文检索入口湖表原始数据Elas0csearch在线查询入口湖表原始数据Elas0csearch在线查询入口离线构建索引不是再同步一份数据到不是再同步一份数据到Elas'csearch，而是让湖上索引随PaimonGlobalIndex管理痛点二：两份数据/两套状态湖里有原始数据，Elasticsearch里有索引副本，数据一致性难保证痛点四：存储与计算成本重复原始数据和索引数据分开存，重建和扩容成痛点二：两份数据/两套状态湖里有原始数据，Elasticsearch里有索引副本，数据一致性难保证痛点四：存储与计算成本重复原始数据和索引数据分开存，重建和扩容成本高痛点一：历史建索引压力全量导入在线Elasticsearch，写入、merge、向量建图冲击查询资源痛点三：增量边界不清楚难判断哪些datafile/rowIdrange已被索引覆盖索引成为湖表资产失败构建不可见索引成为湖表资产失败构建不可见构建、存储、查询分离索引资产可复用多引擎加速Paimon承载原始数据保留snapshot边界用snapshot作为入口，看schema、manifest、datafile与indexfile如何串起来；框内说明每类文件存什么、是什么格式两条入口不同，但都打开Paimon表、切rowIdshard、流式读indexColumn+_ROW_ID、finish产出ResultEntry并commit索引用于召回排序，Paimon原文只在sourcehydration阶段读取离线在线一体化Flink/Spark构建，ESmount在线查询索引用于召回排序，Paimon原文只在sourcehydration阶段读取离线在线一体化Flink/Spark构建，ESmount在线查询丰富索引优势倒排、keyword、numeric、docvalues、vector统一表达相比直接扫原始数据，HNSW/BBQ/DiskBBQ面向低延迟召回按需回源把湖上索引统一成把湖上索引统一成DSL、召回、过滤、重排和回源的一条在线链路Elasticsearch统一检索入口混合检索统一相比多个索引分离查询，ESDSL内组合全文、向量、过滤、重排LakeSearchLakeSearch的特色来自Elasticsearch成熟检索能力与Paimon一致索引资产的结合。云原生内核SIMD/批次化执行兼容ES查询语义高性能向量引擎云原生内核SIMD/批次化执行兼容ES查询语义高性能向量引擎湖上Embedding召回存储计算分离archive留在湖表多引擎reader复用海量多租引擎tenant/dataset建模权限过滤与资源治理知识库规模化复用无需迁移，即可享受数倍性能提升/核心价Embedding接入：多模态向量生成、索引一体化高速召回：HNSW在线低延迟，flatkNN精确评分磁盘型算法：bbq_disk分区检索，承载海量向量升最终质量ES查询链路内完成召回、过滤、量化与重排；湖上向量索引可在线mount，也可被多引擎复用在线路径：Elasticsearchmount检索；离线路径：多引擎reader查询加速算节点快速扩缩容。保证数据秒级可见。租户隔离、权限过滤与资源复用进入同一条知识库检索链路基于ForStDB存储引擎的演讲人演讲人夏瑞阿里云技术专家演讲人演讲人方盛凯阿里云技术专家计算模型02通用增量计算的算子实现03通用增量计算的存储后端04不同计算延迟下的计算成本计算范式什么是增量计算增量计算的核心：根据用户声明的freshness攒批计算预处理StateRead/WritePerRecordStreamingPerRecordStreamingMini-batchMini-batchwithmulti-get/batch-writePerBatchAAAState但multi-get能接受的delta数据是有限制的，从Mini-BatchOp到Sort-MergeOpSortedDeltaBAAIterateChangelogBAAIterate…UpdateBeforeUpdateAfterEmitASeekMergeFunctionUpdateBeforeUpdateAfterEmitASeekMergeFunction…HistoryStateWriteBatch顺序IO，磁盘友好SortSortSortSortMergeMergeMergeMergeSortSortSortSortMergeMergeMergeMergefreshnessfreshnessfreshnesstimeline三大支柱全局协调Merge计算时机增量算子两阶段计算模式——Sort&&MergeAutopilot按需伸缩资源LeftStreamRightStreamADADBAProcessOrderBProcessOrderBCDHistoryDelta顺序遍历所有的顺序遍历所有的delta/history数据Skip对应Key的history数据StreamingJoinRightStream+(A,_)OutputStreamLookupRightStream+(A,_)OutputStreamLookupUpdate-(A)+(A)-(A,A)+(A,A)-(A,_)LeftStateA性能瓶颈:右侧更都会导致左侧所有匹配数据的更新引入NumberOfAssociation表示左侧和右侧关联次数！控制反转流模式Read/UpdateA1E1E1-(B)ΔRLRead/UpdateA1E1E1-(B)增量模式Read/UpdateRead/UpdateA1-(B)-(B)IncrementalJoin 右侧增量触发计算左侧增量触发计算无需同时处理两侧总结跨Key访问流模式StateStateState逐条更新增量模式AStateStateState攒批更新增量计算的存储后端查询类型查询类型更新类型数据类型数据新鲜度增量与流存储兼容面向“通用”的计算场景源表更新频率和量通用计算逻辑问题一：计算语义的通用定义规则增量计算如何定义State？MapStateMapStateValueStateJava对象Java对象JavaJava对象Java对象Java序列化器算子计算逻辑BinaryKVJava序列化器BinaryKVJava序列化器计算语义下推存储后端Flink存储后端FlinkState依赖Java序列化器RustRustDBStateTable:计算语义的通用定义接口商品类别金额商品类别金额20260618U00169920260626U001食品U0011099StateTable定义20260618U00169920260626U001食品U0