1. 数据湖概念与演进：从数据仓库到数据湖的演变

大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊数据湖这个“大池子”到底是怎么来的，它跟数据仓库、数据中台这些概念到底有啥区别。我做了十几年数据架构，见过不少团队在选型上栽跟头，说白了，很多坑都是因为没搞清楚这些基础概念。

1.1 从数据仓库到数据湖的演变

先说说数据仓库。早年间，企业做数据分析，基本都靠它。数据仓库的核心思路是“先建模，后存储”。你得先把业务想清楚，设计好星型模型、雪花模型，然后才能把数据装进去。这种方式的好处是查询快、质量高，但坏处也很明显——太死板了。

我记得在2015年左右，我参与过一个零售项目。业务部门突然想分析用户点击流日志，分析用户从浏览到下单的完整路径。数据仓库团队当时就懵了，因为日志数据格式多变、量又大，根本没法按传统方式建模。折腾了两个月，最后还是把原始日志扔到HDFS上，用Hive跑分析。嗯，这其实就是数据湖的雏形。

为什么会这样？因为数据仓库解决的是“已知问题”，而企业越来越需要探索“未知问题”。数据湖的出现，说白了就是为了打破这种僵局。它允许你先把数据原样存起来，等需要的时候再想怎么用。

1.2 数据湖的定义与核心特征

数据湖到底是什么？我个人的理解是：一个以原始格式存储大量数据的集中式存储系统，支持多种数据类型（结构化、半结构化、非结构化），并且能支撑多种计算引擎（批处理、流处理、机器学习）。

它有几个核心特征，我列出来给你看看：

• 原始格式存储：数据进来是什么样，存的就是什么样。CSV、JSON、Parquet、Avro、图片、视频，统统往里扔。
• Schema-on-Read：读取数据时才定义结构。这意味着你可以灵活地探索数据，不用提前设计表结构。
• 多模态支持：能同时处理结构化数据（数据库导出）、半结构化数据（日志、JSON）和非结构化数据（图片、文档）。
• 弹性扩展：基于廉价硬件（如HDFS、对象存储），理论上可以无限扩展。
• 多计算引擎：同一个数据湖，可以跑SQL分析、Spark作业、Flink流处理，甚至训练机器学习模型。

1.3 数据湖 vs 数据仓库 vs 数据中台

这三个概念经常被混在一起说，但其实它们解决的问题完全不同。我画了一张对比图，帮你理清思路。

我再给你一个表格，从几个关键维度对比一下：

对比维度	数据湖	数据仓库	数据中台
数据形态	原始数据，不强制转换	清洗、转换后的结构化数据	业务主题域的数据服务
建模方式	Schema-on-Read	Schema-on-Write	业务模型 + 服务模型
主要用户	数据科学家、数据工程师	BI分析师、业务报表	业务应用、产品经理
典型技术	HDFS、Spark、Flink、Delta Lake	ClickHouse、Snowflake、Redshift	数据API、数据地图、指标平台
治理重点	元数据管理、数据血缘、生命周期	数据质量、一致性、安全	服务SLA、复用度、业务口径

1.4 数据湖的典型应用场景

说了这么多理论，咱们看看数据湖到底能干什么。我挑几个典型的场景，都是我在项目中实际遇到过的。

场景一：日志与点击流分析

这是数据湖最经典的应用。用户行为日志、服务器日志、IoT设备日志，数据量大、格式多变。数据湖可以原样存储，然后用Spark或Flink做实时或离线分析。我之前帮一个电商平台搭建数据湖，每天处理50亿条点击流日志，从存储到分析，延迟控制在分钟级。

场景二：机器学习特征工程

做机器学习，最头疼的就是特征工程。数据湖可以存储原始数据，数据科学家直接在上面做特征提取、数据探索。你想想看，如果每次都要等数据仓库建模，黄花菜都凉了。数据湖让数据科学家能“自助式”取数，效率提升不止一个量级。

场景三：数据归档与合规审计

很多行业有数据保留要求，比如金融行业需要保存交易日志5-7年。数据湖的低成本存储非常适合做冷数据归档。而且，因为数据湖保留了原始格式，审计时可以回溯到最原始的数据，避免数据转换带来的信息丢失。

场景四：多源数据融合

企业数据通常散落在各个系统中：MySQL、Oracle、MongoDB、API接口、文件服务器。数据湖可以作为一个统一的“数据着陆区”，先把所有数据拉进来，再慢慢做清洗、转换、融合。我习惯把这个过程叫做“先通后治”，先解决数据连通性问题，再逐步治理数据质量。