Apache Iceberg

Databricks通过其开源项目Delta Lake实现了数据湖仓（Lakehouse）架构

Lakebase 是 Databricks 生态中提出的一种新型数据库形态，其核心理念是将 Postgres 兼容的事务型数据库能力构建在数据湖仓架构之上

Apache Iceberg和Apache Hudi与Delta Lake合称湖仓一体时代的三大开放格式

Lakehouse通过在对象存储上构建事务元数据层（如Delta Lake、Apache Iceberg、Apache Hudi）解决数据湖缺乏ACID事务与数仓厂商锁定的矛盾

团队在使用原生支持时仍需关注：流式写入频率与索引更新策略需匹配业务新鲜度要求；物化视图的刷新周期会影响查询结果的实时性；Iceberg 表的元数据管理在表数量增长时可能带来额外开销。

Iceberg 通过元数据层管理表状态，使多个计算引擎（如 Spark、Trino、Flink、Presto）可以并发、安全地读写同一张表。

Delta Lake、Iceberg 和 Hudi 是目前主流的三种开放表格式实现。

Delta Lake 使用事务日志（_delta_log），Apache Iceberg 使用清单文件与元数据树，Apache Hudi 使用时间线（Timeline）作为元数据层实现机制。

Iceberg 提供 Puffin 等索引格式来补充 Bloom filter 或更细粒度的统计，以提升查询裁剪效果。

Iceberg 的 manifest file 是 Avro 文件，每个条目包含文件路径、所属分区、记录数、文件大小以及每列的上下界、空值计数等统计信息，查询规划时用这些统计与分区信息裁剪数据文件。

Iceberg 每次写入产生一个新 snapshot，提交原子性通过重命名元数据文件或外部 catalog 的条件更新实现，把并发控制从页级锁简化为元数据级乐观并发。

S3 等对象存储只保证单对象 PUT 的原子性，没有跨对象的 rename 或事务，因此 Iceberg 在对象存储上的原子提交依赖重命名、Hive Metastore 数据库事务或 REST catalog 的 CAS 等机制。

Iceberg 把分区信息从物理目录中剥离，分区作为元数据里的变换表达式存在，schema 演进不需要重写历史数据。

InnoDB 擅长高频小事务和低延迟点查，Iceberg 擅长海量数据批量写入、分析型扫描和 schema 演进。

InnoDB 的复杂度来自‘就地更新’前提，Iceberg 的简洁来自‘文件不可变’前提；选存储方案时应先确定写入模式和存储介质再决定元数据形态。

把在线业务从 InnoDB 迁移到 Iceberg 不只是更换连接串，而是需要重新定义一致性、延迟和成本之间的权衡。

Iceberg 是面向数据湖的开放表格式，其元数据分层为：table metadata JSON → manifest list → manifest file → 数据文件，每个 manifest file 记录数据文件路径、分区、列级统计和文件级统计。

Iceberg由Netflix发起并贡献给Apache基金会，强调多引擎兼容性（Spark、Trino、Flink、Hive均可访问）

湖仓一体架构基于开放的存储格式（如Parquet）和开放的表格式（如Delta Lake、Iceberg、Hudi），在廉价的对象存储之上提供事务、版本管理和schema演进等能力

Delta Lake、Iceberg和Hudi三者都支持ACID事务、time travel（历史版本查询）、schema演进和分区裁剪