北京时间 2024 年 4 月 16日，开源软件基金会 Apache Software Foundation（以下简称 ASF）正式宣布 Apache Paimon 毕业成为 Apache 顶级项目(TLP, Top Level Project)。经过社区的共同努力和持续创新，Apache Paimon 在构建实时数据湖与流批处理技术领域取得了重大突破，数据湖步入实时新篇章！
恭喜Paimon进入一个新的篇章，这篇文章也是我个人结合当前整个湖仓领域的发展和实践写的一个总结性质的文章。
本文对湖仓方向的核心几个框架没有做对比，Hudi、Paimon、Iceberg、Delta在各个公司都有非常成熟的应用，无丝毫拉踩之意。主要目的是透过当前的各个框架对湖仓领域的发展做一个基本的判断和预测。
湖仓框架能力模型
湖仓领域开源的几个核心框架，基本着眼点都在「同一批流一体存储服务」。那么湖仓领域的框架应该具备的能力包含：
流式读写
应该具备秒级的数据数据写入和数据增量消费能力。
并且如果湖仓的框架想要取代Kafka的部分能力，这个RPS要求在千万级别，但是明显目前是达不到的。在高RPS的业务场景中，湖仓架构不是一个很好的选择，因为性能瓶颈明显，什么都想做的结果就是什么都不能做到极致，
批式读写
在批读和批写方面应该完全涵盖Hive的能力，并且提供分区并发更新、主键更新等额外能力，绝大多数情况下吞吐量应该持平Hive。
此外，湖仓领域的框架需要探索例如部分列更新、维度表等能力，这些能力也是湖仓的框架明显优于传统数据方向框架的标志，目前在各个框架都有在推进中，十分期待。
多引擎集成
湖仓的框架要考虑跟Spark、Flink、Presto等引擎进行高度的集成，不能厚此薄彼。
其他
集中在一些额外的扩展能力，这些能力在传统的数仓框架中不具备/较弱的能力，例如Changelog的聚合、外表挂载等等。
解决的主要问题
首先需要明确的是，湖仓是解决特定场景下问题的能力，基于传统数据仓库的不足而产生的，不存在完全替代xx，只是在特定领域解决特定问题的更优的解决方案。
在湖仓领域，通常我们解决的问题有传统链路不能解决或者成本较高的部分。
我们随便举几个例子：
我们可以基于Hudi/Paimon的表直接进行分析，在流读场景取代Kafka的部分能力，解决Kafka对查询分析能力的弱支持；
基于OLAP成本过高，通过挂在外部表实现存储、计算分离，链路解耦；
在批读场景解决主键更新问题，有效减少下游计算的排序去重成本等等。
这些能力是原来的离线和实时链路不具备的能力，或者支持较弱，需要额外的开发成本，从开发效率、质量和稳定性等方向综合考量的结果，是可以通过湖仓链路进行替代。
最后
湖仓领域发展趋势很好，在国内的几家大厂已经有了成熟的应用，并且在替代原有链路上在进行积极的探索。
未来大家会看到，湖仓领域框架的能力越强，传统的数据开发的理论和开发模式越容易被替代。等到湖仓框架大成的那一天，也许大家已经掌握的技能又要全部推翻重来了。
