1. Lakehouse 架构总览：它到底是什么？
大家好，我是老赵。做数据平台运维十几年了，从最早的传统数仓，到后来的 Hadoop 数据湖，再到现在的 Lakehouse，我算是都经历过。今天咱们聊聊 Lakehouse 架构。
说白了，Lakehouse 就是想把数据湖的灵活性和数据仓库的可靠性结合起来。你想想看，数据湖能存各种格式的数据，成本低，但管理起来像菜市场。数据仓库呢，规规矩矩，性能好，但贵得要命，而且对非结构化数据支持很差。
Lakehouse 的出现，就是为了解决这个矛盾。它直接在廉价的对象存储（比如 S3、OSS、HDFS）上，构建了一层类似数据仓库的 ACID 事务、Schema 强制和高效查询能力。嗯，这里要注意，它不是简单的“湖上加个壳”，而是从底层存储到上层计算，都做了深度改造。
1.1 它跟数据仓库、数据湖到底有啥区别？
我经常被问到这个问题。咱们直接看个对比表，一目了然。
| 维度 | 传统数据仓库 | 数据湖 | Lakehouse |
|---|---|---|---|
| 存储格式 | 结构化表（行存/列存） | 原始文件（CSV, JSON, Parquet等） | 开放文件格式（Parquet, ORC）+ 表格式（Delta/Iceberg/Hudi） |
| 事务支持 | 强 ACID | 无（最终一致性） | ACID（通过表格式实现） |
| Schema | 写时强制（Schema-on-Write） | 读时定义（Schema-on-Read） | 写时强制 + 读时灵活（Schema-on-Write + Evolution） |
| 数据治理 | 成熟（血缘、质量、权限） | 弱（需要额外工具） | 原生支持（通过元数据层） |
| 查询性能 | 高（索引、物化视图） | 低（全表扫描） | 高（文件统计信息、缓存、向量化） |
| 典型场景 | BI报表、固定报表 | 数据探索、机器学习 | BI + ML + 流处理 + 数据科学 |
我记得有一次，一个团队用纯数据湖做实时报表，结果每次查询都要扫描几 TB 的数据，慢得让人抓狂。后来迁移到 Lakehouse，利用 Delta Lake 的统计信息做文件裁剪，查询速度提升了 10 倍以上。这就是区别。
1.2 核心组件拆解：四个关键层
一个生产级的 Lakehouse，我习惯把它拆成四层。每一层都有它的职责，缺一不可。
1.2.1 存储层：地基要稳
存储层是所有数据的家。它必须是廉价的、弹性的、高可用的。我个人习惯用对象存储，比如 AWS S3 或者阿里云 OSS。
- 核心要求： 低成本、高持久性、无限扩展。
- 文件格式： 强烈推荐 Parquet 或 ORC。列式存储，压缩率高，查询时能只读需要的列。
- 避坑指南： 我曾经遇到过因为小文件太多，导致 NameNode（HDFS）内存爆掉的情况。所以，一定要做小文件合并（Compaction）。
1.2.2 计算层：引擎要快
计算层负责跑查询、做ETL、训练模型。它需要跟存储层解耦，这样才能做到弹性伸缩。
- 主流引擎： Apache Spark（批处理、ETL）、Presto/Trino（交互式查询）、Flink（流处理）。
- 关键能力： 向量化查询执行、CBO（基于成本的优化器）、数据本地性感知。
- 我的经验： 别迷信“一个引擎打天下”。我见过很多团队用 Spark 跑所有查询，结果小查询延迟很高。建议混合使用：Spark 做重ETL，Trino 做轻量查询。
1.2.3 元数据层：大脑要灵
这是 Lakehouse 区别于数据湖最核心的一层。它负责管理“数据的数据”。
- 表格式（Table Format）： 这是灵魂。Delta Lake、Apache Iceberg、Apache Hudi 是三大主流。它们提供了 ACID 事务、时间旅行、Schema 演化等能力。
- Catalog： 比如 Hive Metastore、AWS Glue Catalog、Unity Catalog。它记录了表名、列名、分区信息、文件路径等。
- 为什么重要？ 没有元数据层，你的数据湖就是一堆文件。有了它，你才能像操作数据库一样操作文件。
1.2.4 管理层：管家要细
管理层是运维人员的核心战场。它负责让整个系统健康运行。
- 权限管理： 谁可以读？谁可以写？谁可以建表？通过 Ranger 或 Unity Catalog 实现。
- 数据质量： 自动校验数据完整性、唯一性、非空性。我习惯用 Great Expectations 或 Deequ。
- 生命周期管理： 冷热数据分层、过期数据自动清理。比如，30天前的数据自动归档到冷存储。
- 监控告警： 查询延迟、存储使用量、任务失败率。这些指标必须实时可见。
1.3 一张图看懂 Lakehouse 架构
下面这张图，是我自己画的。它把上面说的四层关系串起来了。你仔细看看，就能明白数据是怎么流转的。
你看，数据从上层应用进来，先经过管理层的权限校验，然后计算层根据元数据层的信息，去存储层读取或写入文件。整个过程是闭环的。
1.4 为什么运维人员要理解这些？
你可能会问：“我就是个运维，知道这些概念有什么用？” 我告诉你，太有用了。
- 排查问题： 查询慢，是存储层小文件太多？还是计算层资源不够？还是元数据层统计信息过期了？你得能快速定位。
- 容量规划： 存储层快满了，是加节点还是清理冷数据？计算层资源不够，是扩容还是优化SQL？
- 故障恢复： 元数据层挂了，怎么快速恢复？数据文件损坏了，怎么利用时间旅行回滚？