数据湖仓一体（Lakehouse）教程

为什么需要湖仓一体

过去十年，绝大多数企业同时供养着两套数据平台：一套是以 Oracle、Greenplum、Hive 数仓为代表的数据仓库，服务报表与经营分析；一套是以 HDFS 为核心的数据湖，堆积埋点日志与原始文件，供算法工程师自由探索。两套平台并行，看似分工明确，实则暗藏系统性痛点：

• 存储翻倍：同一份数据在湖与仓各存一份，成本双倍，同步链路也双倍，任何一次 schema 变更都要上下游同时改造。
• 时效撕裂：仓内数据 T+1 更新，湖内数据准实时但无人敢信，同一个指标两个口径，业务部门被迫在「准的慢」和「快的糙」之间二选一。
• 湖无事务：数据湖本质是文件目录，没有 ACID 能力，无法优雅地更新、删除、修正迟到数据，并发读写更是险象环生。
• Schema 失控：读时模式（schema-on-read）意味着结构漂移只有读到时才暴露，脏数据在湖里静默发酵数月是常态。
• 治理割裂：权限、血缘、数据质量标准分属两套体系，治理团队疲于在湖和仓之间「打补丁」。

湖仓一体（Lakehouse）正是对这些问题的系统性回应：在廉价对象存储之上，用开放表格式（如 Iceberg）把数据库级别的事务、Schema 治理与并发控制能力「下沉」到存储层，让一份数据同时支撑报表、实时、AI 与检索等全部场景。三者对比如下：

湖仓一体最迷人的特性是一份数据、多引擎共享：Spark、Flink、Trino 等引擎通过统一的元数据服务读写同一张表，数据不再来回搬运。下图与示例可以直观感受这一点：

-- 同一张 Iceberg 表 lakehouse.dws_trade_city，三个引擎直接访问，数据零搬运

-- ① Trino：BI 看板即席查询，秒级返回（分析师视角）
SELECT city, SUM(pay_amount) AS gmv, COUNT(1) AS order_cnt
FROM lakehouse.dws_trade_city
WHERE dt BETWEEN '2026-10-30' AND '2026-11-04'
GROUP BY city
ORDER BY gmv DESC
LIMIT 20;

-- ② Spark：每日离线回刷，覆盖式重写分区（快照隔离，读写互不阻塞）
INSERT OVERWRITE lakehouse.dws_trade_city PARTITION (dt = '2026-11-04')
SELECT city, SUM(pay_amount) AS gmv, COUNT(1) AS order_cnt
FROM lakehouse.ods_trade_orders
WHERE dt = '2026-11-04'
GROUP BY city;

-- ③ Flink CDC：业务库变更实时 upsert 写入同一张表，分钟级可查
--    （动态表聚合后以 upsert 模式提交，需在建表时声明主键 dt + city）
INSERT INTO lakehouse.dws_trade_city
SELECT DATE_FORMAT(order_time, 'yyyy-MM-dd') AS dt,
       city, SUM(pay_amount) AS gmv, COUNT(1) AS order_cnt
FROM kafka_binlog_orders
GROUP BY DATE_FORMAT(order_time, 'yyyy-MM-dd'), city;

把上述痛点反过来，就是本教程要带你抵达的目标平台画像：一份存储承载全场景、一次入湖即可查、一套 Schema 贯穿批流、一套治理覆盖湖上湖下。后续每一章，都是在为这个画像补齐一块拼图：

• 成本维度：对象存储 + Parquet 高压缩比，冷热分层后单位成本再降一档（存储层）。
• 时效维度：CDC 流式入湖 + 分钟级快照可见，实时与离线不再二选一（数据集成）。
• 性能维度：隐藏分区、分区裁剪与小文件治理，让秒级交互查询成为常态（性能调优）。
• 可信维度：血缘、质量、权限三位一体，湖上数据敢直接进经营报表（数据治理）。

技术栈全景

本站把湖仓一体拆解为六层技术栈，自下而上逐层展开。每一层独立成章，既可按学习路线顺序精读，也可作为速查手册按需检索。每一层中的核心组件如下：

如果你习惯「先看问题再选章节」，下面这张速查表列出每一章回答的核心问题与建议阅读顺序：

学习路线

湖仓一体知识点庞杂，最大的学习风险是「碎片化收藏、从未系统打通」。下面是一条经过实践检验的四阶段进阶路线，每个阶段都有明确的产出检验，避免「看过等于会了」：

先吃透 HDFS / S3-MinIO 的存储语义与 Parquet 的列存布局，再深入 Iceberg 的快照机制、元数据树（metadata.json → manifest list → manifest）、隐藏分区与 compaction。存储是湖仓一切能力的源头：引擎可以换，调度可以换，唯独表格式一旦选错，迁移成本极高。本阶段结束后，你应能独立回答「一次 UPDATE 在 Iceberg 里到底发生了什么」。建议 2~3 周

• 对应章节：存储层
• 产出检验：用 MinIO + Iceberg 从零建库建表，并演示快照回滚与并发读写隔离。

计算与查询是湖仓的「两驾马车」：Spark 解决大规模离线加工与资源模型，Flink 解决实时计算与流式入湖；Trino 提供交互式联邦查询，Doris 与 ClickHouse 提供实时 OLAP 与日志时序场景的极致性能。本阶段的关键不是背 API，而是理解每个引擎的资源模型与适用边界——什么时候用 Spark、什么时候 Trino 一条 SQL 就够。建议 3~4 周

• 对应章节：计算层、查询层
• 产出检验：用 Spark 跑通 T+1 分层加工，用 Flink CDC 实现分钟级入湖，用 Trino 完成看板查询。

数据进得来、任务跑得稳、故障看得见，平台才算「生产可用」。集成层解决数据如何实时可靠地入湖；调度层解决任务依赖、补数与多租户资源配额；可观测层用 Prometheus + Grafana + EFK 建立指标、日志、告警的闭环。本阶段是从「写 Demo」到「值生产班」的分水岭。建议 2~3 周

• 对应章节：数据集成、调度资源、可观测
• 产出检验：设计一条带依赖、失败重试、告警规则的完整 DAG，并接入监控大盘。

从「跑通」走向「跑好」：建立元数据、血缘、质量与安全体系；掌握分区裁剪、小文件治理、join 策略、内存调优等性能手段；最后把底座能力组合成情报研判、AI 检索、时空分析等高阶场景，并对照「数据湖仓一体架构师」的岗位要求查漏补缺。建议 3~4 周

• 对应章节：数据治理、性能调优、场景实战、岗位进阶
• 产出检验：输出一份完整的平台架构设计文档，含容量估算、选型理由与容量水位监控方案。

四阶段环环相扣：底座决定你能走多稳，引擎决定你能跑多快，运行体系决定你敢不敢上生产，治理与实战决定你能拿多高的职级报价。任何时候中断学习后回头，请先重读当前阶段对应的「产出检验」，用能否复现检验结果来判断从哪里续上，而不是从目录第一页重来。

治理与实战

完成四层基础学习后，以下四章帮你完成从「会用」到「能扛」的跨越，它们也是架构师面试与生产评审中最常被追问的主题：

适合谁读

本站内容按「数据湖仓一体架构师」的能力模型组织，以下三类读者都能各取所需：