1.什么是数据湖

数据湖（Data Lake）这个概念最开始是由 James Dixon 提出的。他当时是开源商业智能（BI）公司 Pentaho 的首席技术官（CTO），在2010年10月纽约Hadoop World大会上提出来的。当时Pentaho刚刚发布了Hadoop的第一个版本。在这样的一个大背景下，可以合理的猜测，当时James Dixon提出数据湖的概念，是为了推广自家的Pentaho产品以及Hadoop的。

在当时，企业主要使用数据集市（Data Mart，数据仓库的子集）来进行数据分析。James Dixon 为了解释 Hadoop 等大数据技术带来的新架构模式，使用了一个非常生动的比喻来对比数据集市和数据湖：

• 数据集市（Data Mart）就像是一瓶瓶装水：瓶装水是经过清洗、包装、结构化处理的，专门为了某种特定的消费目的（比如直接饮用）而存在。

• 数据湖（Data Lake）就像是一个自然状态下的大湖：各种源头的溪流（数据）未经处理地流入湖中。不同的消费者（数据科学家、分析师、业务人员）可以来到湖边，根据自己不同的需求，以不同的方式（取水、钓鱼、甚至划船）来使用这些未经加工的原始数据。

因此他关于数据湖的核心思想是：不要在数据存入之前就强制对其进行清洗、聚合和结构化（即传统数据仓库的写时模式Schema-on-Write），而是先将所有原始数据原封不动地存储起来，等需要使用时再根据具体需求去处理和赋予结构（即读时模式Schema-on-Read）。这也奠定了现代数据湖“先存储，后处理”的核心哲学理念。

那么到底什么是数据湖呢？数据湖是现代大数据架构中的核心基础设施。简单来说，它是一个集中式的数据存储库，允许以原生格式（往往是未处理的原始状态）存储任意规模的结构化、半结构化和非结构化数据。

随着大数据主要是Hadoop热潮的兴起出现，在云服务商提供自己版本的“云上大数据平台”过程中炒热。所以关于数据湖的定义就有很多版本，基本上都声称有以下几个特性：

1. 数据湖不是数据仓库。

2. 数据湖存储容量极大，足以保存一个企业/组织中的所有数据。

3. 数据湖中可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。也就是保存的是原始数据，这些数据保持了它们在业务系统中原本的样子。

4. 数据湖具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习。

简单地说，狭义的数据湖指的是数据湖存储最好是存储在 HDFS 或者云上的对象存储系统上，就是一个原始数据保存区。广义的数据湖除了数据湖存储，还包括数据湖的管理和分析，即提供一整套工具，提供数据目录（Data Catalog）服务以及统一的数据访问。有些厂商甚至把数据处理任务的调度和管理也当作数据湖的组成部分。如下图就是目前相对来说比较完整的数据湖的架构体系。

数据湖的四大核心特征：作为大数据团队的基础设施，数据湖在架构设计上具备以下鲜明特点：

1. 存算分离架构 (Decoupled Storage and Compute)

数据湖通常建立在廉价的对象存储（如 AWS S3, 阿里云 OSS）或分布式文件系统（如 HDFS）之上。计算引擎（如 Spark, Flink, Trino）根据任务需求弹性扩缩容，不再像传统 MPP 数据库那样将计算资源和存储资源强绑定，极大降低了海量历史数据的存储成本。

1. 多模态数据支持 (Multi-modal Data)

不仅能存储关系型数据库同步过来的结构化数据（如 MySQL 的 Binlog），还能存储应用日志、JSON、CSV 等半结构化数据，甚至是图片、音频、视频等非结构化数据，保留了数据最原始的粒度。

1. 读时模式 (Schema-on-Read)

数据入湖时不强制校验 Schema，极大提升了高吞吐量数据（如实时埋点流、IoT 传感器数据）的写入速度。Schema 仅在下游应用或分析工具读取数据时才被应用，为数据探索和机器学习提供了极高的灵活性。

1. 统一的数据底座 (Single Source of Truth)

作为企业所有原始数据的最终归宿，它可以同时支撑批处理（离线报表、T+1 计算）、流计算（实时风控、大屏看板）以及机器学习模型训练。

感兴趣的同学可以看看这篇论文：https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

以及Databricks的知名博客：https://www.databricks.com/blog/2021/05/19/evolution-to-the-data-lakehouse.html

2.为什么现在企业中越来越多使用数据湖

企业越来越多地转向数据湖架构，本质上是因为传统数据仓库在面对海量、多源、实时的数据交互需求时，遇到了难以逾越的成本天花板和架构瓶颈。

现代企业（尤其是互联网、金融和电商领域）推动数据湖落地的核心驱动力可以归结为以下五个维度：

1.存算分离打破成本与扩展性瓶颈

传统 MPP 数仓（如 Teradata 或早期的离线数仓）通常是存算强绑定的，当业务日志或埋点数据激增时，为了增加存储空间，不得不购买昂贵的计算节点。数据湖建立在低成本的对象存储（OSS/S3）或 HDFS 之上。这种架构允许团队在双十一或大促等算力高峰期弹性扩容计算资源（如 Spark 节点），而在平时仅保留海量历史数据的低成本存储，整体基础设施 TCO（总拥有成本）显著下降。

2.一套底层数据，多计算引擎复用（打破数据孤岛）

在传统架构中，实时流计算、离线批处理和交互式分析往往需要三套不同的存储系统，数据在不同系统间来回同步，不仅容易出错，还造成了巨大的冗余。数据湖格式标准化了底层数据。现在，企业可以实现一份数据，多引擎消费：

• 使用 Flink 将 MySQL CDC 数据或上游消息队列数据实时写入。

• 使用 Spark 读取同一份数据进行重度 ETL 清洗、多表复杂 Join 和历史数据跑批。

• 将数据湖直接挂载到 Apache Doris 或 Trino 等 OLAP 引擎，为 BI 报表和数据分析师提供毫秒级的即席查询。

3.保留原始数据粒度，支撑 AI 与高阶分析

传统数仓的强 Schema 限制意味着数据在入库前必须经过高度清洗和聚合，这导致大量原始信息丢失。但在构建精准的用户画像系统或实时风控模型时，算法工程师和数据科学家（通常使用 Python/Pandas）需要的是最原始的、未被裁剪的行为轨迹数据和特征。数据湖“先存储、后处理”的特性，完美契合了机器学习对高保真原始数据的渴求。

4.Schema-on-Read 带来极致的业务敏捷性

业务迭代速度越来越快，如果每次新增上游字段或接入新的 API 数据源，都需要 DBA 重新设计数仓表结构并修改 ETL 脚本，开发周期将被严重拉长。数据湖允许将 JSON、日志等半结构化数据直接“倒”入湖中，由下游分析师在写 SQL 查询时再根据业务逻辑去提取需要的字段（Schema-on-Read），极大缩短了数据从产生到产生价值的链路（Time-to-Value）。

5.“湖仓一体”补齐了最后的短板

早期数据湖最大的问题是“易进难出”，缺乏事务支持，最终容易变成数据沼泽（Data Swamp，只进不出的单项湖）。但随着 Iceberg、Paimon 等湖仓一体格式的成熟，数据湖拥有了 ACID 事务、细粒度的数据 Update/Delete 能力以及时间旅行（Time Travel）功能。这使得数据湖能够直接承载过去只有数仓才能承担的核心 ODS和 DWD业务，彻底打通了架构演进的最后一步。

补充说明：

虽然原生数据湖解决了存储成本和灵活性问题，但它也存在明显的痛点：缺乏 ACID 事务支持、数据更新/删除困难、小文件灾难（如流式写入时产生大量小文件导致 NameNode 压力或查询变慢）。为了解决这些问题，现代大数据架构已经演进到了湖仓一体（Data Lakehouse）。通过引入开放的数据湖表格式（如Iceberg、Hudi、Delta Lake、Paimon），在底层对象存储之上构建了一层元数据管理层：

• 支持 ACID 事务：允许并发的读写操作，支持行级别的 Update 和 Delete（解决 CDC 数据实时入湖问题）。

• 时间旅行 (Time Travel)：支持查询历史快照，方便回溯数据。

• 索引与小文件合并：引擎层面支持 Z-Order 排序和自动的小文件合并（Compaction），提升查询性能。

所以这里我们要区别概念，我们平时说的Iceberg、Hudi、Delta Lake、Paimon都是数据湖的表格式，主要为了解决数据湖的痛点而引入的数据湖元数据管理层，其并不是数据湖，但其可以让数据湖里的数据更加有效的被组织起来。

3.数据湖是噱头还是下一代架构？

上面我们看到数据湖和数据湖表格式还是有区别的，很多人在使用的时候其实都是在“偷换概念”。数据湖的概念在业界常常被过度包装，但如果从务实的架构演进角度来剖析，核心观点非常明确：狭义的数据湖是传统数仓 ODS 层的有效延展，而广义的数据湖则是一场兜售的技术营销骗局，最终的归宿必然是回归工程理性的“湖仓一体”（Lakehouse）。可以将这个观点从以下几个维度进行深度拆解与重构：

1.狭义数据湖：让 ODS 层重见天日的微创新

在经典的数仓架构中，贴源数据层（ODS）一直存在，用于对接各种异构数据源并作为血缘管理的起点。但过去，这片区域被视为禁区，终端用户只能消费经过层层清洗、建模（DWD -> DWS -> ADS）后的数据。但是随着业务迭代节奏加快，这条长长的 ETL 链路成为了敏捷响应的瓶颈。特别是面对高度不确定的探索型需求时，业务方根本等不及漫长的数仓排期。

狭义的数据湖，本质上就是给原本封闭的 ODS 层装上了“数据目录（Data Catalog）”和“细粒度权限控制”，并向业务方和程序直接开放。它并没有颠覆数仓，而是扩展了数仓的数据供给能力，让数据分析师或算法模型能够直接绕过漫长的建模周期，去底层原始数据中淘金。

2.广义数据湖：云厂商的概念箩筐与架构倒退

当数据湖被泛化为一个涵盖采集、存储、治理、机器学习的全家桶时，它就脱离了技术本质，沦为云厂商推销 PaaS 服务的营销词汇。广义数据湖最大的迷惑性在于它宣扬的“先存储，后处理”理念。这在表面上似乎省去了复杂的前置建模工作，但实际上是将 ETL 的复杂度和计算成本，极其不负责任地转嫁给了下游的终端用户和计算引擎。

抛弃了经典方法论的广义数据湖，本质上退化成了最原始的独立型数据集市。短期内，大家拉取数据似乎很快，但当多个业务主题开始交叉时，随之而来的就是一场灾难。

3.存储一切的代价陷阱：算力爆炸与 Garbage In, Garbage Out

广义数据湖鼓励把所有结构化、半结构化的脏数据一股脑倒进去，声称存储极其廉价。但真正的陷阱隐藏在后续的计算环节：

• 计算成本的急剧反噬：存储确实便宜，但算力极贵。如果底层缺乏严谨的表结构设计、主键约束和数据清洗，当业务方试图从海量原始日志中提取价值时，每一次查询都可能触发全表扫描。试想一下，如果没有前置的模型聚合，直接在海量未清洗的数据上执行复杂的四表关联，底层 Spark 任务的 Shuffle Join Stage 数量和内存消耗将会呈指数级爆炸，直接拖垮整个集群。

• 数据沼泽化：结构复杂的非互联网企业，其核心资产往往是关系错综复杂的 CRM 或 ERP 数据，而非简单的流式日志。将这些缺乏清洗和上下文的数据直接暴露，不但不能产生洞察，反而会因为数据质量问题（Null 值、重复读取、格式混乱）导致下游分析结果彻底失真。

4.架构的最终收敛：Lakehouse 才是真正的着陆点

剥开所有营销的泡沫，大数据架构的演进依然要遵循软件工程的客观规律。最终能够真正落地、并支撑团队高效运转的，一定是 Data Lakehouse（湖仓一体）。它保留了狭义数据湖作为底层 Repository 的优势（低成本对象存储、多模态数据包容），同时在上面架设了类似 Iceberg、Paimon 等具备强 Schema 约束和事务能力的表格式。

未来的架构并不是用数据湖取代数据仓库，而是将数仓严谨的建模方法论（Inmon 或 Kimball）、完善的数据治理体系，建立在更具弹性和开放性的数据湖底座之上。在这个底座上，无论是用 Flink 进行实时数据流转，还是用 Doris 进行多维度的 OLAP 聚合查询，都能在保证数据质量的前提下，实现真正的高效流转。