数据湖与湖仓 — 在对象存储上长出一个数据库Data Lake & Lakehouse: Open Table Formats, Metadata, Unified Batch/Stream

问题场景 + 需求约束

设计一个 PB 级分析平台：每天摄入 100TB 行为日志 + 上游 OLTP 库的 CDC 变更，要同时喂三类消费者——BI 报表（要求分钟级新鲜度）、ML 特征/训练（要全历史、可回放任意时间点）、数据分析师 ad-hoc SQL（扫描几十 TB 也得几秒返回）。

老路子是 数据湖（S3 一堆 Parquet）+ 数仓（Snowflake/Redshift） 并存：湖便宜能存原始数据但没事务、改一行要重写整个分区；仓查询快但贵，数据还要 ETL 搬一遍，新鲜度永远落后几小时。两套系统、两份数据、两倍成本，还对不齐。

• 规模：数据总量 ~10PB，单表最大 ~500TB / 万亿行；写入峰值 ~2GB/s。
• 新鲜度 SLO：CDC 入湖到可查 < 5 分钟；BI 报表 P95 < 3s。
• 正确性：要 ACID——并发写不能互相覆盖、读不能看到半截写入（脏读）；要能按时间点回放（time travel）做审计和模型复现。
• 成本：存储用对象存储（S3/GCS，$0.023/GB·月），算力按需起停，避免数仓那种『存算绑定』的常驻账单。

本期讲四件事：湖/仓/湖仓怎么选、开放表格式怎么在 S3 上做 ACID、元数据层怎么让查询又快又能时间旅行、批流怎么一套搞定。

高层架构（湖仓分层）

graph TD
    SRC["数据源
OLTP CDC · 日志 · 事件流"]
    ING["摄入层
Spark / Flink / Kafka Connect"]
    subgraph LH["Lakehouse 存储（对象存储 S3/GCS）"]
      META["表格式元数据层
Iceberg / Delta / Hudi"]
      DATA["数据文件
Parquet / ORC 列存"]
    end
    CAT["Catalog
表→当前快照指针"]
    ENG["查询/计算引擎
Spark · Trino · Flink · DuckDB"]
    BI["BI 报表"]
    ML["ML 训练/特征"]
    AD["Ad-hoc SQL"]

    SRC --> ING --> META
    META -.指向.-> DATA
    CAT -.原子切换当前快照.-> META
    ENG -->|读元数据→剪枝→只读相关文件| META
    ENG --> BI & ML & AD

    classDef src fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef store fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    classDef eng fill:#0e2030,stroke:#5eead4,color:#e8eef5
    class SRC,ING src
    class META,DATA,CAT store
    class ENG,BI,ML,AD eng

核心洞察：存储仍是对象存储里的开放列存文件，但上面盖一层事务性元数据，让多引擎像操作数据库一样操作它

关键技术点

1. 湖 vs 仓 vs 湖仓：为什么要把数据库拆成『文件 + 元数据』

原理：传统数仓是 schema-on-write、存算耦合的封闭系统——先建模、私有格式，查得快但贵且锁定。数据湖是 schema-on-read——原始文件直接堆 S3，便宜、开放、ML 友好，但没事务、没索引、没 schema 演进保证，改一行要重写整个分区目录，并发写互相覆盖。湖仓的本质是：保留湖的开放列存文件（Parquet），在其上加一层事务性元数据，于是同一份数据既有湖的成本/开放性，又有仓的 ACID/性能。Databricks 在 CIDR 2021 的 Lakehouse 论文系统论证了这个架构。

2. 开放表格式：在 S3 上做 ACID 的三种流派

原理：对象存储只保证单个对象 PUT 的原子性，没有跨文件事务、没有 rename 原子性（S3 的 rename = copy+delete）。表格式的做法是：所有数据文件只追加不修改（immutable），每次写产生新文件，再原子地切换一个『当前快照』指针——读者要么看到旧快照全集、要么看到新快照全集，绝不看到半截。这就是快照隔离（snapshot isolation）。三大格式（Iceberg / Delta / Hudi）思路同源，区别在元数据组织和写优化方向。

# 乐观并发控制（OCC）提交，三格式通用思路
def commit(table, new_files):
    while True:
        base = catalog.current_snapshot(table)      # 读当前快照
        snap = base.add(new_files)                   # 生成新快照（指向旧+新文件）
        # 原子 CAS：仅当 current 仍等于 base 才切指针
        if catalog.compare_and_swap(table,
                                    expected=base,
                                    new=snap):
            return                                   # 提交成功
        # 否则有人抢先提交 → 校验是否冲突 → 重试/失败
        if conflicts(base, snap): raise ConflictError

3. 元数据管理：分层清单让查询剪枝 + 时间旅行

原理：表格式把元数据组织成多级清单树。以 Iceberg 为例：metadata file（表 schema、分区规范、所有快照列表）→ manifest list（一个快照包含哪些 manifest，带分区值范围）→ manifest file（每个数据文件的路径 + 列级统计：min/max、null 数、行数）。查询时引擎自顶向下读元数据：用分区值范围和列 min/max 做剪枝（pruning），跳过绝大多数文件，只真正打开相关 Parquet。不需要扫目录、不需要 LIST S3（Hive 表的老瓶颈）。每次提交生成新快照、旧快照保留，time travel 就是读历史快照指针。

-- Iceberg 时间旅行：审计 / 模型复现 / 误删恢复
SELECT * FROM events
  FOR SYSTEM_TIME AS OF '2026-06-29 00:00:00';   -- 按时间
SELECT * FROM events FOR SYSTEM_VERSION AS OF 4912;  -- 按快照ID

-- 文件剪枝示意：WHERE 命中分区/统计 → 只读 3 个文件而非 80000 个
-- manifest 记录 file_a: dt∈[06-28,06-28], user_id min=10 max=99
-- 查 dt='06-30' AND user_id=5  → min/max 不相交 → 整文件跳过

4. 批流一体：一张表同时接住流写与批读（COW vs MoR）

原理：传统 Lambda 架构要维护批层 + 速度层两套代码两套结果再合并，复杂且对不齐。湖仓让流和批写同一张表：Flink/Spark Streaming 持续 append 提交快照，批作业读同一张表的快照——Kappa 化。关键工程权衡是更新怎么落盘：Copy-on-Write（COW）写时就把改动合进新数据文件（读快、写放大大）；Merge-on-Read（MoR）写时只追加 delta 日志、读时再合并（写快、读时多一次 merge）。CDC 高频 upsert 选 MoR，分析为主选 COW。

# Hudi 增量读：只拉某 commit 之后的变更（增量 ETL 核心）
df = (spark.read.format("hudi")
      .option("hoodie.datasource.query.type", "incremental")
      .option("hoodie.read.begin.instanttime", last_commit)  # 上次水位
      .load(table_path))
# 只对 delta 跑业务逻辑，再 upsert 到下游表 → 算力随『变更量』而非『全量』

扩展与优化（增长后怎么办）

• Catalog 成瓶颈：所有提交都要 CAS 同一张表指针，热表写并发高会频繁冲突重试。上 REST Catalog（如 Iceberg REST、Polaris、Unity）做服务化提交，或按子分区拆表降低写冲突域。
• 查询加速：加 排序/聚簇（Z-order / clustering）让相关数据物理相邻，提升 min/max 剪枝效果；列存本身已做谓词下推与字典编码。
• compaction 治理：自动化『小文件合并 + 过期快照清理 + 孤儿文件回收』成常驻作业，监控『平均文件大小』『每查询打开文件数』。
• 多引擎一致：同一张表被 Spark 写、Trino 读、Flink 流写，靠 catalog 统一快照语义，避免各引擎私有缓存读到旧元数据。
• 分区演进：业务增长后分区粒度要变（按天→按小时），Iceberg 支持不重写历史地演进分区，老数据按旧规则、新数据按新规则。

常见陷阱 + 面试问题

深入资源

• 《Lakehouse: A New Generation of Open Platforms》（Armbrust, Ghodsi, Xin, Zaharia，CIDR 2021）：湖仓架构的奠基论文，论证存算分离 + 开放格式 + 元数据层。
• Apache Iceberg 官方文档 / 表规范（spec）：metadata→manifest list→manifest 三级结构、隐藏分区、分区演进的权威定义。
• Uber Engineering：《Uber's Lakehouse Architecture》/ Hudi 博客：CDC 增量 ETL、COW/MoR、trillion-record 规模的实战。
• 《Designing Data-Intensive Applications》（Kleppmann）：列存、批处理与流处理、Lambda/Kappa 的底层原理（相关章节）。

深入思考（点击展开答案）