一篇笔记。
以Hudi、Iceberg、Paimon这几个框架为例，它们支持高效的数据流/批读写、数据回溯以及数据更新。具备一些传统的实时和离线数仓不具备的特性，主要有几个方面：
这些存储引擎是天然统一的批流一体存储。既支持批式访问完整Table数据，也支持先全量处理Table数据，然后对Changelog进行增量的流式处理;
支持UPSERT流，这个很重要;文件组织形式也更高效(LSM);
支持TimeTravel,理论上可以从任意时间点就行批或者流处理;
还有一些其他的离线数仓的操作
如果我们基于湖框架构建出了新的数仓体系Streaming Warehouse，这样我们所有的开发都会面向Table，纯SQL操作。
这样的架构解决了核心问题：
如果性能足够，可以达到媲美实时链路的延迟;
天然的批流一体，口径一致，计算语义天然对齐，保证数据一致性;
中间结果落地可查，这是相比当前非常火的实时数仓的极大的优势；
很方便的进行历史数据修复；
开发、存储成本低
这也是很多文章中提到的：实现批流一体计算和存储，同时支持流、批以及OLAP处理，实现了以 "Table"的形式进行数据处理。
目前可以替代的一些场景：例如可以接受端到端延迟在分钟级别，数据逻辑复杂希望离线、实时强一致，传统的以数据库为核心通过创建物化视图、存储过程等在线Serving场景等。
但是我们必须得说，上面都是未来的理想设想，当前阶段很多问题没有解决，例如端到端延迟相比纯实时场景要大很多，取决于CheckPoint的时间间隔等。
不过随着这些框架的不断迭代和发展，未来可能会不一样。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
2022年全网首发|大数据专家级技能模型与学习指南(胜天半子篇)
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点