网站建设品牌公司,建购物网站要多少钱,百度下载安装免费版,国内精自视频品线一区原文参考#xff1a;Apache Fluss 官方博客《Fluss Iceberg (Part 1): Why Your Lakehouse Isn’t a Streamhouse Yet》 本文为中文整理与改写版#xff0c;面向 CSDN 技术博客读者#xff0c;保留核心观点#xff0c;并对结构、表述和部分案例说明做了适配优化。未来实时…原文参考Apache Fluss 官方博客《Fluss × Iceberg (Part 1): Why Your Lakehouse Isn’t a Streamhouse Yet》本文为中文整理与改写版面向 CSDN 技术博客读者保留核心观点并对结构、表述和部分案例说明做了适配优化。未来实时湖仓方向值得参考iceberg 国内可用 paimon 替代 , 好文共享。图 1Fluss × Iceberg 整体架构示意。Fluss 负责实时热数据层Iceberg 负责历史冷数据层对外通过统一表能力服务不同查询引擎。前言这些年Apache Iceberg 几乎已经成为现代数据湖分析场景里的“基础设施”支持 ACID 事务支持 Time Travel支持 Schema Evolution能很好地承载大规模离线分析但问题在于当我们希望把 Lakehouse 进一步推向“实时”时Iceberg 本身就开始显得力不从心了。比如下面这些场景亚秒级实时报表高频 CDC 更新主键表实时查询实时特征供给 AI / 推荐系统需要当前状态的 Agentic AI 应用这时候你会发现传统 Lakehouse 的能力边界其实很明显它很擅长“冷数据分析”却不擅长“热数据实时服务”。于是Apache Fluss 给出了一个新的方向让 Iceberg 继续专注冷数据分析而让 Fluss 负责热数据实时层。这并不是简单地把“流”和“湖”拼在一起而是试图构建一种新的统一架构Streamhouse。一、为什么“实时 Lakehouse”会变得越来越重要1.1 业务越来越无法容忍延迟很多企业过去还能接受 T1 天后来逐渐接受 T1 小时但现在越来越多业务需要的是秒级甚至亚秒级响应。典型例子包括实时定价库存变更风控与反欺诈配送调度在线客服决策这些业务不是“第二天知道结果”就行而是要求系统在事件发生后立即做出判断。1.2 AI / 推荐系统依赖最新数据如今很多 AI 系统并不只是在离线训练时依赖数据它们在在线推理时也需要持续读取最新特征。例如个性化推荐实时内容排序动态广告投放风险评分如果底层数据平台只能提供分钟级甚至小时级的新鲜度那么上层 AI 效果一定会打折扣。1.3 Agentic AI 更依赖“当前状态”相比传统 BIAgent 类应用更强调“感知当下并立即决策”。无论是智能交易代理、路径规划代理还是自动客服系统如果读取到的还是几分钟前的数据那很多决策都会偏离真实状态。图 2推动实时 Lakehouse 的四股力量业务速度、即时决策、AI/ML 新鲜数据需求以及 Agentic AI 的实时上下文需求。二、数据新鲜度的演进从 T1 到秒级从产业演进角度看数据平台大致经历了这样几个阶段2.1 传统批处理时代T1 天典型代表是基于 Hive 的数仓体系夜间 ETL次日出报表适合经营分析不适合实时运营2.2 Lakehouse 时代T1 小时有了 Iceberg、Delta Lake、Hudi 之后数据湖开始具备事务和表格式能力可做小时级微批处理能支持更灵活的分析适合近实时看板但依然离真正实时还有明显距离。2.3 Streaming Lakehouse 时代T1 分钟一些系统开始把流式写入和湖格式结合起来把数据新鲜度推进到分钟级。这一步已经很有价值但依旧存在一个关键缺口很多关键业务真正需要的是秒级甚至亚秒级而不是分钟级。问题并不在于某个实现“做得不够好”而是因为文件提交有开销元数据管理有开销对象存储访问有开销Snapshot 可见性有开销也就是说基于文件系统的 Lakehouse天然很难把秒级延迟做成常态能力。图 3数据平台演进时间线从 Hive 的 T1 天到 Iceberg/Delta 的 T1 小时再到 Paimon 的 T1 分钟以及 Fluss × Iceberg 面向的 T1 秒。三、Fluss × Iceberg 到底是什么3.1 核心思路热冷分层但对外统一Fluss × Iceberg 的核心思想可以概括为一句话把实时热数据放在 Fluss把历史冷数据放在 Iceberg对查询引擎暴露成一张统一逻辑表。这套架构里热层Hot Tier—— Fluss负责最近一段时间的实时数据特点是毫秒级写入与读取延迟面向流式消费支持主键索引支持高频更新使用 Arrow 列式格式可基于 RocksDB 做主键状态访问冷层Cold Tier—— Iceberg负责更长时间范围的历史数据特点是存储在 S3 / HDFS 等对象存储使用 Parquet 等分析友好格式支持 ACID 事务适合大规模分析扫描成本更低换句话说Fluss 解决“最后一小时”的问题Iceberg 解决“历史分析”的问题3.2 它和传统架构最大的不同是什么传统做法通常是这样的Kafka / Kinesis 负责流数据Iceberg 负责湖仓分析中间用 Flink / Spark / ETL 管道做搬运应用往往要双写两个系统这会带来一堆经典问题双写一致性难题链路复杂运维系统多热数据和冷数据查询口径容易不一致而 Fluss × Iceberg 的思路是应用只写一次先写入 Fluss然后通过 Tiering Service 自动把数据分层到 Iceberg。查询引擎面对的是一张统一表而不是两套割裂系统。图 4左侧是传统 Lambda 架构需要双写与同步链路右侧是 Fluss × Iceberg 的 Kappa/Streamhouse 思路单写入路径自动分层统一查询。四、为什么单靠 Iceberg很难成为真正的“实时底座”原文总结了 Iceberg 在实时场景下的四个关键短板我觉得非常典型。4.1 问题一元数据开销限制高频写入Iceberg 的提交模型本质上是围绕快照和元数据演进构建的。每次 commit都会牵涉到metadata.json更新manifest list 更新snapshot 元数据推进在分析场景里如果 5 分钟或者 15 分钟提交一次这几乎不是问题。但一旦进入实时场景例如每秒 100 条事件希望每秒提交一次那么元数据压力会迅速放大。随着时间推移就会出现manifest 数量激增metadata.json体积膨胀提交延迟不断上升如果再叠加分区表、多 bucket、多 writer这种压力只会更明显。结论Iceberg 的元数据机制很适合批量提交不适合把高频流式写入直接“硬顶上去”。4.2 问题二基于轮询的读取会把延迟放大Iceberg 并不是一个 push-based 的系统。也就是说读者通常需要靠轮询发现新的 snapshot写入端提交 snapshot元数据落到对象存储读取端按固定周期轮询发现新 snapshot 后再拉取数据文件这条链路的问题在于延迟会被层层累计对象存储可见性延迟轮询间隔文件读取延迟最终很容易把端到端延迟推到 5 秒、10 秒甚至更高。对下面这些业务来说这个延迟基本不可接受实时报表实时风控运营调度秒级推荐4.3 问题三主键支持更像“声明”而不是“约束”Iceberg V2 虽然可以在 DDL 里声明 Primary Key但这更多是语义提示并不是强约束。也就是说它并不会天然帮你完成唯一性校验内建去重主键索引查找这会直接导致一个现实问题CDC 去重和状态合并最终还是得靠上游流处理引擎自己做。一旦数据规模上来Flink state 会变得非常庞大运维和成本压力都很高。4.4 问题四高频更新会带来严重写放大Iceberg 支持更新但主要依赖 MORMerge-On-Read delete file 的方式实现。这在高频 CDC 场景中会面临两个麻烦Equality Delete更新一条记录时可能需要先把旧值以 delete 的形式写出来再写入新值。如果表很宽列很多写放大会非常明显。Position Delete虽然更高效但它依赖文件级位置映射。在高频分散更新的场景下delete file 数量会快速增长。再叠加流式写入天然容易产生小文件最终就会出现小文件海量堆积查询变慢compaction 压力巨大这也是很多团队在生产环境里经常踩到的坑。五、Fluss 是怎么补上这些缺口的5.1 方案一日志索引式存储 Push 实时读取Fluss 的一个核心思路是把高频实时写入留在流式存储层解决而不是直接把高频提交压力扔给 Iceberg。它的做法大致是高频写入先进入 FlussFluss 采用追加日志段不做全局元数据频繁协调Tiering Service 再按分钟级 freshness 把数据批量整理后写入 Iceberg于是Fluss 负责高频写Iceberg 负责低频、规范化、适合分析的批量提交这就把“实时复杂度”和“分析存储复杂度”拆开了。更关键的是Fluss 的消费模型是push-based的新数据来了消费者可以快速感知不需要依赖长轮询发现新 snapshot实时读取可做到毫秒级到亚秒级这对实时场景是本质性的改善。5.2 方案二原生主键表 Upsert 能力Fluss 不是只做 append-only 流它还提供了一等公民级别的主键表能力。其核心实现可以理解为一份当前状态存储例如 RocksDB一份变更日志changelog / WAL写入主键表时Fluss 会先读当前值判断是插入、更新还是删除生成对应 changelog写入复制日志刷新状态再对客户端确认这种设计带来的直接收益是主键唯一性真正被执行主键点查可以走索引CDC 在写入时就完成预去重下游不需要再维护超大状态做二次去重这点对下面场景尤其重要维表服务实时库存用户画像状态订单状态流转也就是说Fluss 想做的不是“另一个消息队列”而是一个既能存实时流又能承载主键状态表的统一实时层。5.3 方案三自动分层写入 IcebergFluss 并不是把数据永远留在热层而是通过 Tiering Service 自动把数据同步到 Iceberg。这个组件的作用包括自动创建对应的湖表自动做 schema 映射自动把 Arrow 批数据转成 Parquet自动按 freshness 策略分层可选做小文件压缩和整理你可以把它理解成一个把 Fluss 热数据“规整落湖”的自动化桥梁。而且它不是单点而是可扩展的多个 Flink Job 可以注册到协调器协调器把不同表分配给不同任务处理失败不会阻塞所有表可以弹性扩缩容对于工程落地来说这样的设计比“每张表单独配一条同步链路”省心得多。图 5Lake Tiering Service 负责把 Fluss 表自动同步到对应 Iceberg 湖表完成表创建、Schema 映射、Arrow→Parquet 转换以及基于 freshness 的分层。5.4 方案四Union Read把冷热层拼成一张逻辑表这一点是整套架构最关键、也最有意思的地方。如果热层和冷层是分开的那么用户查询时就会面临一个经典问题我到底该查谁怎么保证没有重复、没有遗漏Fluss × Iceberg 的解法是Union Read。它的基本思路是Iceberg 负责某个 snapshot 之前的数据Fluss 负责 snapshot 之后的实时增量查询时按 offset 边界做拼接最终给出统一视图这样系统就能保证没有重叠边界前的数据只从 Iceberg 读没有空洞边界后的数据只从 Fluss 读顺序可控按 bucket / offset 协调读取对用户来说体验上就是默认查统一表自动看到“历史 实时”如果只想查历史湖数据可以显式查$lake例如在 Flink SQL 里-- 默认统一读取冷热数据SELECT*FROMordersWHEREevent_timeNOW()-INTERVAL1HOUR;-- 只查 Iceberg 历史层SELECT*FROMorders$lakeWHEREorder_dateCURRENT_DATE;这其实是在查询层把“流”和“湖”真正统一起来了。图 6Union Read 通过 offset 边界协调读取 Iceberg 历史数据与 Fluss 实时增量数据再进行合并去重最终呈现统一结果。六、这套架构到底解决了什么问题如果从工程价值上看我觉得 Fluss × Iceberg 主要解决了下面几件事。6.1 单写入路径消灭双写一致性问题应用只需要写 Fluss 一次后续冷热分层由系统自动完成。这意味着不需要同时写消息系统和湖表不需要补偿双写失败不需要维护复杂同步作业6.2 兼顾实时性与低成本历史分析热数据放在高性能实时层冷数据放在低成本对象存储分析层。这让系统同时具备秒级甚至亚秒级实时访问能力长周期历史分析能力更好的整体成本控制图 7历史分析侧更看重 Parquet 压缩、S3 吞吐、回溯处理与过滤下推能力Iceberg 等湖表格式在这里非常适合。6.3 主键表能力内建不再把状态压力全部压给 Flink很多团队的问题其实不是“没有流处理”而是CDC 去重状态太大维表服务得依赖 Redis / KV 系统主键语义散落在多个系统里Fluss 的主键表设计本质上是在底座层就把这些能力统一承接下来。6.4 自动化治理小文件和冷热生命周期传统湖仓一个非常烦的问题是流式写入带来大量小文件后面还要单独跑 compaction作业多、运维复杂、调参成本高Fluss 的 Tiering Service 在落湖时就能结合自动维护策略处理这些问题整体链路会更闭环。图 8实时分析侧强调 Union Read、Arrow 原生交换以及对 Flink、Spark、StarRocks 等引擎的无缝衔接。七、什么场景下你应该认真考虑 Fluss如果你的系统出现了下面这些信号那就说明单纯依赖传统 Lakehouse 可能已经不够了7.1 你需要亚秒级实时查询例如实时推荐实时风控实时运营大盘秒级告警7.2 你有高频 CDC 更新如果同一个 key 每秒都会被多次更新那么单靠文件湖格式处理 update / delete 的成本会非常高。7.3 你需要真正可用的主键语义例如主键点查实时维表 Join在线状态表实时库存 / 账户余额 / 用户画像7.4 你的 Flink 状态已经大到难以维护当去重、合并、维表等逻辑把状态规模推到 10TB 甚至更高时把部分能力外移到底层存储往往是更现实的方向。7.5 你厌倦了“两套系统两套口径两套运维”这可能是最真实的原因。很多架构问题并不是“技术上不能做”而是“工程上太折腾”。如果一套方案可以做到单写入冷热统一查询统一自动分层那它就很值得认真评估。八、我的理解Lakehouse 之后下一步可能真的是 Streamhouse我觉得这篇文章最值得关注的不只是 Fluss 和 Iceberg 的集成方式而是它提出了一个很清晰的判断Lakehouse 并不天然等于实时。过去大家容易把“支持流式写入”误认为“天然适合实时系统”但实际上两者差距很大。真正的实时底座除了能写入还得同时解决高频提交实时通知主键状态Upsert / Delete小文件治理冷热统一查询而 Iceberg 本身的设计目标更多还是面向历史数据分析存储。所以与其强行把 Iceberg 改造成一个实时系统不如承认分工Iceberg 做它最擅长的冷数据分析层Fluss 做实时热数据层两者通过统一表抽象衔接起来这或许才是更现实的工程路径。九、总结一句话总结本文Fluss × Iceberg 想解决的不是“流数据怎么进湖”这么简单而是“如何让 Lakehouse 真正具备实时能力”。它的答案是用 Fluss 承担热层与实时读写用 Iceberg 承担冷层与历史分析用自动 Tiering 解决冷热数据流转用 Union Read 对外暴露统一逻辑表这样一来你得到的是一套更接近“Streamhouse”的架构而不只是一个会流式写入的 Lakehouse。如果你正在做下面这些方向实时数仓实时推荐 / 风控CDC 平台AI 特征供给流批一体的数据基础设施那么 Fluss 的这条路线值得重点关注。参考链接原文Fluss × Iceberg (Part 1): Why Your Lakehouse Isn’t a Streamhouse Yet官方站点Apache FlussQuickstartFluss Lakehouse QuickstartApache FlussApache IcebergLakehouseStreaming Lakehouse实时数仓CDCFlink数据架构