StreamingWarehouse的一些思考和未来趋势

一篇笔记。

以Hudi、Iceberg、Paimon这几个框架为例，它们支持高效的数据流/批读写、数据回溯以及数据更新。具备一些传统的实时和离线数仓不具备的特性，主要有几个方面：

1. 这些存储引擎是天然统一的批流一体存储。既支持批式访问完整Table数据，也支持先全量处理Table数据，然后对Changelog进行增量的流式处理;
2. 支持UPSERT流，这个很重要;文件组织形式也更高效(LSM);
3. 支持TimeTravel,理论上可以从任意时间点就行批或者流处理;
4. 还有一些其他的离线数仓的操作

如果我们基于湖框架构建出了新的数仓体系Streaming Warehouse，这样我们所有的开发都会面向Table，纯SQL操作。

这样的架构解决了核心问题：

1. 如果性能足够，可以达到媲美实时链路的延迟;
2. 天然的批流一体，口径一致，计算语义天然对齐，保证数据一致性;
3. 中间结果落地可查，这是相比当前非常火的实时数仓的极大的优势；
4. 很方便的进行历史数据修复；
5. 开发、存储成本低

这也是很多文章中提到的：实现批流一体计算和存储，同时支持流、批以及OLAP处理，实现了以 "Table"的形式进行数据处理。

目前可以替代的一些场景：例如可以接受端到端延迟在分钟级别，数据逻辑复杂希望离线、实时强一致，传统的以数据库为核心通过创建物化视图、存储过程等在线Serving场景等。

但是我们必须得说，上面都是未来的理想设想，当前阶段很多问题没有解决，例如端到端延迟相比纯实时场景要大很多，取决于CheckPoint的时间间隔等。

不过随着这些框架的不断迭代和发展，未来可能会不一样。