1. 数据湖仓概述：数据湖与数据仓库的区别、湖仓一体架构演进、历史数据查询的挑战与价值
各位同学好，我是老周。今天咱们开始第一讲，聊聊数据湖仓的来龙去脉。说实话，这个领域我摸爬滚打了快十年，踩过的坑不少，积累的经验也还算扎实。这一章我会把最核心的概念掰开揉碎了讲给你听。
1.1 数据仓库 vs 数据湖：两个时代的产物
先问个问题：你手头有一堆业务数据，想做个报表，第一反应是什么？大部分人会说「丢进数仓」。没错，数据仓库（Data Warehouse）这个概念从上世纪90年代就开始火了。它的核心逻辑是——先定义好模型，再往里灌数据。
但后来大家发现，业务变化太快了。今天要分析用户行为日志，明天要接入IoT传感器数据，后天又来了非结构化的图片和视频。数据仓库那套「先建模后入库」的玩法，根本跟不上节奏。于是数据湖（Data Lake）应运而生。
我个人习惯用一张表来对比两者的差异，这样更直观：
| 维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据形态 | 结构化数据为主 | 结构化、半结构化、非结构化全支持 |
| 存储格式 | 行式存储（如Oracle、SQL Server） | 列式存储（如Parquet、ORC）或对象存储 |
| 写入模式 | Schema-on-Write（写时定义模式） | Schema-on-Read（读时定义模式） |
| 数据质量 | 高，经过ETL清洗 | 低，原始数据直接存储 |
| 典型场景 | BI报表、固定维度分析 | 数据探索、机器学习、实时流处理 |
| 成本 | 高（专用硬件+商业许可） | 低（廉价对象存储+开源引擎） |
你看，数据仓库像是一个精装修的房子——住进去舒服，但改格局很难。数据湖则像一块毛坯地——什么都能放，但想住得舒服得自己动手。我在项目中遇到过不少团队，一开始图省事全用数据湖，结果数据越堆越多，最后变成了「数据沼泽」——数据都在，但谁也找不到、用不了。
1.2 湖仓一体架构演进：从「两套系统」到「一套架构」
既然数据仓库和数据湖各有优劣，那能不能把两者的优点结合起来？这就是湖仓一体（Lakehouse）架构的出发点。说白了，就是让数据湖拥有数据仓库的ACID事务能力、数据治理能力和高性能查询能力。
我画了一张架构演进图，帮你理清脉络：
你想想看，从传统数仓到数据湖，再到Lambda架构（批流分离），最后到湖仓一体，本质上是在解决一个核心矛盾：数据的一致性和灵活性如何兼得。
我记得2019年刚接触Delta Lake时，第一反应是「这不就是给数据湖加了个事务日志吗？」后来深入用才发现，事情没那么简单。湖仓一体在底层做了三件大事：
- 元数据层独立：把文件列表、分区信息、事务日志抽出来单独管理，不再依赖Hive Metastore那种笨重的方式。
- 乐观并发控制：多个任务同时写同一张表时，通过版本号冲突检测来保证数据不坏。我见过不少团队在这上面翻车，后面会专门讲。
- 文件级索引：像Iceberg的Manifest文件、Hudi的Bloom Filter，都是为了在查询时快速跳过不相关的数据文件。
1.3 历史数据查询的挑战与价值
好，前面铺垫了这么多，终于到咱们课程的核心了——历史数据查询。为什么单独拿出来讲？因为在实际业务中，这恰恰是最容易被忽视、却又最让人头疼的问题。
先说说挑战，我总结了四个字：大、慢、贵、乱。
- 大：历史数据动辄PB级，全量扫描一次要几个小时。我在一个金融客户那里见过，他们的交易流水表存了7年，单表超过5PB。
- 慢：传统Hive查询，一个简单的按天聚合跑半小时是常事。业务方催得急，你这边还在等MapReduce任务调度。
- 贵：全量扫描意味着大量的计算资源消耗。云上按量付费的话，一个查询跑下来可能几百块就没了。
- 乱：数据格式不统一，有的用Parquet，有的用Avro，还有一堆CSV。分区策略也五花八门，有的按天分，有的按小时分，有的干脆没分区。
但反过来看，历史数据查询的价值同样巨大：
| 场景 | 价值 | 典型查询 |
|---|---|---|
| 监管合规 | 金融、医疗行业必须保留7年以上交易记录，随时接受审计 | 查询某笔交易3年前的全部操作日志 |
| 趋势分析 | 对比今年与去年同期的用户行为，发现增长或衰退信号 | 按月份聚合过去5年的GMV数据 |
| 模型训练 | 机器学习模型需要大量历史数据做训练集 | 提取过去3年所有用户的点击序列 |
| 数据回滚 | 修复因程序Bug导致的错误数据，恢复到某个时间点 | 将某张表回滚到昨天凌晨2点的状态 |
| 离线计算 | 批量生成报表、特征工程、数据清洗 | 对全量历史数据重新计算用户标签 |
说白了，历史数据查询不是「要不要做」的问题，而是「怎么做才高效」的问题。湖仓一体架构在这方面有天然优势——它把数据湖的存储弹性、低成本，和数据仓库的查询性能、事务能力结合在了一起。
我举个例子你就明白了。假设你有一个10TB的用户行为表，按天分区，存了3年。你想查去年双十一当天某个用户的全部行为。在传统Hive里，即使有分区过滤，也可能需要扫描当天全量数据（假设当天100GB）。但在湖仓一体架构下，Iceberg的Manifest文件会记录每个数据文件的最小/最大user_id范围，查询引擎可以直接跳过不包含该用户的数据文件，实际扫描量可能只有几百MB。这就是文件级剪枝的威力。