1. 数据湖仓一体概述
大家好，我是老张。做数据平台十几年了，从最早的传统数仓，到后来的数据湖，再到现在的湖仓一体，这条路我算是踩坑踩过来的。今天咱们聊聊第一章——数据湖仓一体到底是个啥，它解决了什么问题。
1.1 数据湖与数据仓库的区别
先问个问题：你手头的数据，到底该放哪？
我刚开始做项目时，客户总问：你们用数据仓库还是数据湖？其实这两者压根不是替代关系，而是不同场景下的产物。
| 维度 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据格式 | 结构化，Schema on Write | 结构化/半结构化/非结构化，Schema on Read |
| 存储成本 | 高（ETL清洗后存储） | 低（原始数据直接存） |
| 写入模式 | 批量写入，严格约束 | 流式/批量均可，灵活 |
| 典型用户 | BI分析师、报表用户 | 数据科学家、机器学习工程师 |
| 数据质量 | 高（经过治理） | 低（原始数据，需自行清洗） |
| 典型场景 | 固定报表、KPI监控 | 探索性分析、模型训练 |
说白了，数据仓库是「先想清楚再存」，数据湖是「先存了再说」。我在2018年帮一家电商公司搭数据平台时，他们硬要把所有日志都塞进数仓，结果ETL跑一次要6小时，业务等不及。后来改成数据湖存原始日志，数仓只存聚合结果，问题才解决。
核心区别一句话：数据仓库为「已知问题」设计，数据湖为「未知探索」设计。两者不是二选一，而是互补。
1.2 湖仓一体的定义与价值
那湖仓一体又是什么？
我个人的理解是：把数据湖的灵活存储和数据仓库的事务能力结合起来。你想想看，数据湖能存任意格式，但没法做ACID；数据仓库能保证一致性，但存不了非结构化数据。湖仓一体就是「我全都要」。
它的核心价值有三点：
- 统一存储：一份数据，同时支持BI分析和机器学习，不用来回拷贝。
- 事务支持：在数据湖上实现ACID，保证读写一致性。我遇到过最头疼的事——数据湖里两个任务同时写同一个分区，结果数据乱套了。湖仓一体用乐观锁解决了这个问题。
- 开放格式：基于Parquet/ORC等开放格式，不会被厂商锁定。嗯，这里要注意，有些所谓的湖仓一体方案其实是闭源的，选型时要擦亮眼。
我的建议：如果你的团队既有BI需求，又有机器学习需求，而且数据量在TB级以上，湖仓一体是值得考虑的。小规模项目用传统数仓就够了，别为了技术而技术。
1.3 Lambda架构与Kappa架构对比
聊完存储，咱们说说处理架构。Lambda和Kappa是两种经典的数据处理模式。
Lambda架构：批处理层 + 流处理层 + 服务层。批处理保证全量准确性，流处理保证低延迟。听起来很完美对吧？但我在实际项目中吃过亏——维护两套代码，批处理和流处理的逻辑稍微不一致，结果对不上账。排查了整整两天，最后发现是窗口函数定义不同。
Kappa架构：只用流处理，所有数据都走实时管道。批处理只是流处理的一个特例（重放历史数据）。好处是只有一套代码，维护成本低。但坏处也很明显——流处理引擎的容错和状态管理必须足够强。
下面这张图能帮你直观理解两者的区别：
那怎么选？我个人的经验是：
- 选Lambda：业务对实时性要求高，但历史数据也需要精确回溯。比如金融交易系统，既要实时风控，又要月底对账。
- 选Kappa：数据源本身是流式的，且流处理引擎足够成熟（比如Flink）。比如物联网设备数据，所有数据都是时间序列，没必要分两套。
避坑指南：我曾经在一个项目中强行用Kappa架构处理离线报表，结果流处理引擎的状态后端撑爆了内存。后来才意识到，Kappa不是万能的，批处理场景下Lambda反而更稳。选型时一定要评估数据特征和团队能力。