跳转至

湖仓表格式

Reference · 速查

本章组织

本章按 5 个子组：

外部权威：docs/references/lakehouse/。对比 Apache Iceberg 官方 docs 结构（Tables → Branching/Config/Evolution/Maintenance/Performance/Reliability/Schemas/Partitioning · 与本章组织接近）。

聚焦"建在对象存储上的表"——它怎么组织元数据、怎么做 ACID、怎么支持演化与时间旅行。

和 foundations/ 的分界 · 湖表的物理底座

本节是逻辑表协议层（Snapshot / Manifest / CAS 提交 / Schema 演化 / 具体产品）。它建在物理文件之上——物理层（对象存储 + 列式文件 + 编码）归到 foundations/：

  • 对象存储 —— 湖表的地基（读写语义、CAS、Conditional PUT）
  • Parquet · ORC —— Iceberg / Paimon / Hudi / Delta 最常用的数据文件格式
  • Lance Format —— 为多模 + 向量 + ML 训练重写的列式格式（也是 LanceDB 的底座）
  • 压缩与编码 · 列式 vs 行式 —— 文件内部的组织方式

如果还没读过上面这些物理层，建议先过一遍 基础模块的主线。

建议阅读顺序

从"第一次接触湖表"到"能做选型"的分层路径

必读主线（前 6 步顺序做）——读完能做湖表选型：

  1. 湖表 —— 先理解"建在对象存储上的表"到底是什么
  2. Snapshot —— 最核心的机制；其他能力都是它的派生
  3. Manifest —— Snapshot 下一层的索引结构 · 湖表性能基石
  4. 按需读演化能力：Schema / Partition / Time Travel / Branching
  5. 上生产必读运维三件套：Delete Files → Compaction · 维护生命周期 → Streaming Upsert / CDC
  6. 对照实现选型：Iceberg / Paimon / Hudi / Delta

可选扩展（做特定场景再翻）：

核心协议 · 表格式标准化能力（稳定）

  • 湖表 —— 为什么它和传统 DB 存储引擎不是一回事
  • Snapshot —— 快照如何让"时间旅行"成为可能
  • Manifest —— 元数据的二层索引，湖表性能的基石
  • Schema Evolution —— 不重写历史就能改表结构
  • Partition Evolution —— 改分区策略也不重写历史
  • Time Travel —— 查过去某一时刻 / 版本的样子
  • Branching & Tagging —— Iceberg 原生分支 / 标签
  • Puffin —— Iceberg 的辅助索引侧车文件

运维机制 · 写后要管的事（稳定）

扩展能力 / 前沿延伸 · 非协议核心（成熟度不一）

成熟度声明

以下两页不是表格式协议的稳定核心能力： - Materialized View 主要是引擎层实现（Trino connector / Databricks 商业能力），spec 尚未标准化 - 多模湖仓 是前沿方向——向量 / 地理 / Variant / 图在湖表上的承载仍在演进

  • Materialized View —— 湖上 MV · 引擎层实现为主 · Feature Store 雏形
  • 多模湖仓 —— 前沿 · 向量 / 地理 / Variant / 图 的湖表承载

主流实现

横向对比

团队决策

常用参考