【FFA 2026】Agentic Lake 3 基于Postgres CDC 和Apache Fluss 构建亚秒级湖仓方案

构建亚秒级湖仓方案场景与挑战传统实时链路的Schema变更之痛真实业务场景中的Schema变更之痛化率、库存预警跨境电商现状订单表在Postgres,分析在RedShift/BigQuery,中间隔着小时级跨境电商PostgresPostgresXPaymentXPaymentInventoryUpdated!!!(RedShift/BigQuery)真实业务场景中的Schema变更之痛产品快速迭代意味着频繁加字段（新增埋点维度每次都要同步修改Postgresuser_eventab_assignments(RedShift/BigQuery)！！！查询引擎查询引擎StreamingLakehouse架构一份数据，一条管道，同时服务实时和离线两条链路TieringServiceAnalyticsStreamingFlinkCDC是一款用于处理流批数据的分布式数据集成工具，通过YAML格式描述数据传递和转换过程以简化数据集成工作。化读取的流式数据集成框架，是实现StreamingLakehouse的关键技术。ServerServerRemoteRemoteStorage(S3/OSS/HDFS)FlussClusterServerServerLakeTieringServiceFlussClusterServerServerLakehouseStorageLakehouseStorage(Paimon/Iceberg*)ApacheFluss是一个开源的、原生支持Lakehouse的流存储系统。它将消息队列、在线KV存储、流处理状态后端以及Lakehouse冷存储整合为统一的数据底座，让Lakehouse真正实流批一体增量快照Replication流批一体增量快照ReplicationSlot管理毫秒级流读流写流批一体架构数据统一存储整库同步统一数据治理改Paimon验证数据改FlussPostgreSQLPostgreSQLPaimon零人工干预零停服Schema变更秒级到达下游可查询02机制深入解读PostgresLogicalReplication机制publicationfilterlogicalprocessrecordbufferslotoutputpublicationfilterlogicalprocessrecordbufferslotoutputplugin(Write-AheadLog)SubscriberPostgres如何管理ReplicationSlot?Phase1:全量快照阶段Phase2:增量同步阶段StreamReaderCheckpoint时推进confirmed_flush_StreamReaderCheckpoint时推进confirmed_flush_lsn，GlobalReplicationSlotstreamsplitReader1Reader1Reader2Tempslot1Tempslot2Chunk1Chunk2Chunk3Chunk41.创建临时split,读取snapshot和前后的low_watermark和high_warkmark2.Backfill:读取[low_watermark,high_watermark)区间的WAL变更并合并Trade-Off•Trade-Off•若PostgreSQL的slot数量或磁盘空间受限，应适当降低全量阶段的并发度，但会牺牲全量读取速度•若下游支持幂等写入，可以skipbackfill,全量阶段不再创建临时slot读取WAL.PostgresSchemaInferenceBeforeSchemaid(intBeforeSchemaid(int)bname(text)email(text)Postgres逻辑复制不同步DDL,且DML消息中不包含schema消息推导2朴素方案：每条消息推导2朴素方案：每条每条消息都重新推导每条消息都重新推导schema,代价比较大—33Pgoutput：RelationMessage表结构变更时，pgoutput在第一个新消息之前发送RelationMessage,包含schema4解法4解法:LazySchemaInference仅当收到RelationMessage时，推导schema变更事件(appendonly)(appendonly)AfterSchemaid(int)bfull_name(int)new_email(varchar)i\ji\j012303443243211432233210PathALTERTYPEnew_emailtext>vatchar(cost1)5.5.Client读取原始数据[1,Alice]按照目前schema输出[1,Alice,null}与业界方案对比vsKafka:Kafka无内置SchemaEvolution,依赖外部SchemaRegistry;Fluss原生支持，读取时自动适配vs传统数据库:传统DB需要锁表重写;Fluss零停机、零迁移vsApacheIceberg:设计理念一致(Schema版本化+读取时适配),Fluss通过LakeFirst策略与Iceberg/Paimon无缝集成AdminClient1.请求CoordinatorServer2.正确性验证:确保Fluss和Lakehouse的schema对齐3.1.LakeFirstLakehouse(Iceberg/Paimon)lakecatalog.alterTable()Zookeeper./schemas/1->[idINT,nameSTRING]./schemas/2->[idINT,nameSTRING,ageINT]4.更新TabletServerMetadata4.UpdateMetadataTabletServer3ServermetadatacacheTabletServer2ServermetadatacacheTabletServer1ServermetadatacacheLogScannerBatchB(schemaId=2)eg:[b,“Bob”,20]BatchA(schemaId=1)eg:[1,Alice]数据存储(LogSegment)3.2持久化03Postgres->Fluss->PaimonSchema同步测试背景：电商运营临时给商品表加category/weight维度，DBA直接在PostgreSQL上A