Lakehouse 2021 — 把数据湖和数仓合成一套开放平台

待复核

是什么

Lakehouse 是一种把数据湖的便宜开放存储，和数据仓库的可靠查询能力，放进同一套平台的架构。日常类比：以前家里有一个大仓库放所有原材料，又有一个精装修厨房只做少数菜；Lakehouse 想把两者打通，让原材料仍然放在便宜仓库里，但厨房可以直接安全、高效地取用。

这篇论文的核心不是发明一个新文件格式，而是给一个正在成形的系统设计取名：数据放在对象存储和 Parquet/ORC 这类开放格式里，上面加一层元数据，让它具备事务、版本、审计、索引、缓存和查询优化。

换句话说，Lakehouse 的目标是：不要为了 BI、机器学习、数据科学各复制一份数据。同一份开放数据，既能被 SQL 引擎查，也能被 Spark、TensorFlow、PyTorch 这类工具直接读。

为什么重要

不理解 Lakehouse，下面这些事都很难解释：

为什么很多公司明明有数据湖，还要把一部分数据再搬进数仓，最后 ETL 越堆越多。
为什么机器学习团队常抱怨数仓数据不好直接用，BI 团队又抱怨数据湖不可靠。
为什么 Delta Lake、Iceberg、Hudi 这类“表格式数据湖”会变成现代数据平台的核心组件。
为什么开放格式和对象存储不是“低配版数仓”，而可能变成下一代分析平台的底座。

核心要点

Lakehouse 可以拆成 三层能力：

开放存储：底层仍是便宜、可直接访问的对象存储和 Parquet/ORC 文件。类比：食材还在大仓库，不锁进某一家厨房的专用盒子里。
元数据层：在文件上方记录“哪些文件属于当前表版本”。类比：仓库有一本台账，写清楚今天这道菜能用哪些食材，哪些已经作废。
性能与治理能力：缓存热数据、保存统计信息、调整文件布局，让 SQL 和 ML 都跑得动。类比：常用食材放近一点，标签贴清楚，厨师不用每次翻完整个仓库。

这三层合起来，才是论文说的 Lakehouse；只有便宜文件存储，不算完整 Lakehouse。

实践案例

案例 1：旧式两层架构为什么慢

-- 先把原始数据进湖
COPY raw_orders TO 's3://lake/raw_orders/';

-- 再清洗一遍搬进数仓
INSERT INTO warehouse.orders
SELECT user_id, amount, created_at
FROM lake.raw_orders
WHERE amount IS NOT NULL;

逐部分解释：

第一行把数据放进数据湖，优点是便宜、格式开放、能装很多类型的数据。
第二段又把同一批数据复制进数仓，优点是 BI 查询快，缺点是多了一条管道。
论文指出，复制越多，数据越容易变旧；管道越多，失败和口径不一致的机会越多。

案例 2：元数据层怎样让“文件堆”变成“表”

{"version": 7, "add": "s3://lake/orders/part-007.parquet"}
{"version": 8, "remove": "s3://lake/orders/part-003.parquet"}
{"version": 8, "add": "s3://lake/orders/part-008.parquet"}

逐部分解释：

数据文件仍然是普通 Parquet，别的计算引擎可以直接读。
日志告诉系统：第 8 版表包含哪些文件，不包含哪些文件。
有了这个台账，系统才能做事务、回滚、时间旅行和并发控制。

案例 3：机器学习为什么也能受益

orders = spark.read.format("delta").load("/lake/orders")
vip = orders.where("country = 'CN'").select("user_id", "amount")
features = vip.groupBy("user_id").sum("amount")

逐部分解释：

代码看起来像普通 DataFrame 操作，但它不是马上逐行执行。
Spark 会先把过滤、选列、聚合变成计划，再交给 Lakehouse 的数据源层。
数据源层可以利用缓存、统计信息和数据布局，只读必要文件，减少机器学习前处理的等待。

踩过的坑

把 Lakehouse 理解成“湖加仓的营销词”：原因是它真正新增的是开放文件上的事务元数据和优化层，不只是换个名字。
以为有 Parquet 就等于 Lakehouse：原因是 Parquet 只解决存储格式，不能自动解决事务、版本、质量约束和索引。
以为它能免掉所有数据治理工作：原因是 Lakehouse 减少复制和失败点，但清洗逻辑、权限、质量规则仍然要人设计。
只看 SQL 性能，不看 ML 访问方式：原因是论文的关键诉求之一就是让非 SQL 的高级分析也能直接读同一份数据。

适用 vs 不适用场景

适用：

公司已经有大量数据放在 S3、ADLS、GCS 或 HDFS 这类存储里。
同一批数据既要给 BI 报表用，也要给机器学习和数据科学用。
团队想减少湖到仓、仓到特征工程之间的重复 ETL。
数据平台需要开放格式，避免所有数据被锁进某个封闭存储格式。

不适用：

数据量很小，直接用单机数据库或普通 PostgreSQL 就够。
业务只需要强事务 OLTP，比如订单扣库存，而不是分析查询。
团队没有数据治理能力，只想靠架构名词自动解决脏数据。
查询完全依赖某个专有数仓的深度优化，且不需要开放访问。

历史小故事（可跳过）

第一代：企业把业务数据库里的数据抽到集中式数仓，主要服务 BI 和报表。
Hadoop 时代：数据湖兴起，大家把原始数据放进便宜文件系统，但治理能力变弱。
2015 年后：云对象存储普及，S3、ADLS、GCS 让湖更便宜、更耐用，但湖和仓的双层架构更复杂。
2020 年前后：Delta Lake、Iceberg、Hudi 这类元数据层成熟，开始把事务和版本带回数据湖。
2021 年：这篇 CIDR 论文把趋势总结为 Lakehouse，并用 TPC-DS 结果说明开放格式上也能做到接近云数仓的 SQL 性能。

学到什么

架构创新有时不是新算法，而是重新划边界：Lakehouse 把“存储格式是否开放”变成平台设计的核心问题。
开放性和性能不是绝对冲突：缓存、辅助统计、数据布局可以弥补开放文件格式带来的部分限制。
元数据是数据平台的方向盘：没有元数据层，数据湖只是文件堆；有了版本和事务，文件堆才像表。
现代数据平台要同时服务 SQL 和非 SQL：机器学习、数据科学、特征工程都需要直接访问大规模数据。

关联

codd-1970 —— 关系模型让“表”成为分析系统的基本抽象，Lakehouse 仍在服务表查询。
cstore-2005 —— Lakehouse 的 SQL 性能问题，很大一部分来自列式存储和布局优化传统。
snowflake-2016 —— 同样是云原生分析平台，但更偏封闭数仓，适合作对照。
mapreduce —— 数据湖早期受 Hadoop 生态影响很深，MapReduce 是那条路线的入口。
bigtable-2006 —— 云端大规模存储系统的代表，帮助理解存储和计算分离的背景。
greenplum-db —— MPP 数仓路线的工程代表，可对比 Lakehouse 为什么要减少数据复制。
delta-lake-2020 —— Lakehouse 论文中反复依赖的元数据层实例。

反向链接

data-lake-management-2019 —— Data Lake Management 2019 — 数据湖从文件堆变成可治理资产
databend —— Databend — Rust 写的存算分离云数仓

Lakehouse 2021 — 把数据湖和数仓合成一套开放平台

是什么

为什么重要

核心要点

实践案例

案例 1：旧式两层架构为什么慢

案例 2：元数据层怎样让“文件堆”变成“表”

案例 3：机器学习为什么也能受益

踩过的坑

适用 vs 不适用场景

历史小故事（可跳过）

学到什么

延伸阅读

关联

反向链接