数据湖对比（hudi,iceberg,paimon,Delta）
Delta
| 数据湖 | Delta |
| 更新原理 | update/delete/merge 实现均基于spark的join功能。 |
| 定位 | 做基于spark做流批一体的数据处理 |
| 缺点 | 本质为批处理。强绑定spark引擎。整体性能相较其他数据湖比较差 |
hudi
| 数据湖 | hudi |
| 更新原理 | 通过hudi自定义的主键索引hoodiekey + 布隆过滤器 + 文件join合并实现更新 |
| 定位 | 面向spark，为了解决在hadoop体系内数据更新和增量查询的问题。定位是实现数仓+数据库的功能。 |
| 缺点 | 本质为批处理 整体架构耦合性强，系统设计复杂，各个引擎之间的兼容性较差，参数众多。 趋势在不断的在完善面向批处理的架构细节改造，对spark友好，无法彻底适配流处理更新能力。 |
iceberg
| 数据湖 | iceberg |
| 更新原理 | 写入时数据分为delete 和 insert 文件，查询时通过序列号定位文件生成先后 + join 得到最后结果 |
| 定位 | 官方定位是面向海量数据分析场景，底层设计抽象，通用标准设计。不依赖任何计算引擎。 |
| 缺点 | 本质为批处理，主打离线数据湖和扩展性 在国外的应用场景主要是离线取代 Hive，虽然扩展性强，也导致计算引擎有较多优化空间，后续发展难以迅速，需要涉及众多对接引擎。 |
paimon
| 数据湖 | paimon |
| 更新原理 | 通过内存 + 磁盘实现lsm数据结构 |
| 定位 | |
| 优点 |
|
总结：
个人更倾向于paimon的数据湖能力，可以为用户提供高吞吐、低延迟的数据摄入、流式订阅以及实时查询能力。总结一句话就是真正面向实时更新而设计的数据湖格式。