实时数据湖架构演进

概述

数据架构经历了数仓 → 数据湖 → 湖仓一体 → 实时湖仓的演进。本文梳理从数据湖 1.0 到 Lakehouse 2.0 的变化，讲清流批一体技术趋势与主流方案。

---

一、演进脉络

演进路线：
  数仓（结构化、强治理）
  → 数据湖（全量数据、廉价存储）
  → 湖仓一体（Lakehouse，兼具两者）
  → 实时湖仓（流批一体）

  核心矛盾：
    数仓：能治理但存不下全量
    数据湖：存得下但难治理

阶段	特点	问题
数据仓库	结构化、ACID、强治理	存不下非结构化
数据湖 1.0	全量、廉价、灵活	无 ACID、难治理
Lakehouse	ACID + 湖存储 + 分析	实时性弱
实时湖仓	流批一体	复杂度高

---

二、数据湖 1.0

2.1 数据湖定义

数据湖（Data Lake）：
  存储所有原始数据（任意格式）
  低成本（对象存储/HDFS）
  按需计算（schema-on-read）

  价值：
    全量留存
    支持机器学习/探索

2.2 数据湖 1.0 的痛点

痛点	表现
无 ACID	写入冲突、数据不可信
无 Schema	读时解释、质量难控
无索引	查询慢
治理难	数据沼泽（Data Swamp）

结果：
  存了很多数据
  但无法保证质量与可用性
  → 催生湖仓一体

---

三、Lakehouse 1.0（湖仓一体）

3.1 湖仓一体核心

Lakehouse = 数据湖存储 + 数仓能力

  关键能力：
    表格式（Table Format）提供 ACID
    Schema 管理
    索引与优化
    统一存储 + 多引擎访问

3.2 三大表格式

表格式	特点
Iceberg	快照隔离、时间旅行、通用
Delta Lake	事务日志、Spark 生态
Hudi	增量处理、Copy-on-Write/Merge-on-Read

核心机制：
  元数据层记录表版本（快照）
  写入生成新快照（ACID）
  读取基于快照（隔离）
  优化：Z-Order/排序/压缩

3.3 Lakehouse 的价值

价值：
  一个存储多种用途（数仓/湖/ML）
  ACID 保证数据可信
  多引擎（Spark/Flink/Presto）统一访问
  成本低（对象存储）

---

四、实时湖仓（Lakehouse 2.0）

4.1 为什么要实时

需求：
  业务要分钟级数据（不是 T+1）
  实时报表/实时风控/实时特征

  方案演进：
    实时数仓（Kafka + Flink + OLAP）
    → 数据写实时，模型更新困难
    → 实时湖仓：实时入湖 + 流批一体

4.2 实时湖仓架构

架构：
  业务数据 → CDC → Kafka
  → Flink（实时处理）
  → Iceberg/Delta/Hudi（实时入湖）
  → 分析引擎（查询/报表）

  特征：
    湖内表可实时更新
    离线/实时同一份数据
    流批共享表格式

4.3 核心能力

能力	说明
实时写入	分钟级入湖
Upsert	主键更新
流批一体	同一份表流批共用
增量读取	消费湖表变更

---

五、流批一体技术

5.1 什么是流批一体

流批一体：
  同一套代码/表模型
  同时支持流式与批量处理
  避免"两套数据两套逻辑"

  两个层面：
    计算引擎流批一体（Flink）
    存储流批一体（表格式）

5.2 Flink 流批一体

Flink 统一 API：
  批 = 有界流
  流 = 无界流
  同一套算子/优化器

  价值：
    一套代码
    一次开发
    统一语义

5.3 表格式流批一体

表格式的流批能力：
  Iceberg：增量读取 + 流式写入
  Delta：Change Data Feed
  Hudi：增量查询 + 实时快照

  组合：
    Flink 流式写湖表
    Spark/Presto 批量读湖表
    同一份数据，两种计算

---

六、实时湖仓 vs 实时数仓

维度	实时数仓	实时湖仓
存储	消息 + OLAP	湖表为主
模型	分层建表	湖表 + 视图
数据量	有限	全量
成本	相对高	低（对象存储）
扩展	明细难留存	明细可留

趋势：
  实时数仓解决"快"
  实时湖仓解决"快 + 全 + 便宜"
  两者常共存（湖存储 + OLAP 加速）

---

七、技术选型

7.1 表格式选型

选型考量：
  生态（Spark/Flink 支持）
  实时写入能力
  并发与 ACID
  运维复杂度

  参考：
    Spark 生态 → Delta
    多引擎/通用 → Iceberg
    增量处理 → Hudi

7.2 整体方案

典型方案：
  Iceberg/Delta + Flink（实时写入）
  + Spark（离线处理）
  + Presto/Trino（即席查询）
  + Doris/CH（加速层，可选）

  落地路径：
    先做离线湖仓
    再逐步加实时入湖
    最后流批一体

7.3 常见误区

误区	说明
湖仓=数据湖	有 ACID 才是湖仓
流批一体=一套代码	还需存储与治理配合
实时越快越好	权衡成本与价值

---

八、未来趋势

趋势方向：
  湖仓与数仓融合加深
  Streaming Lakehouse（流湖仓）
  元数据治理增强
  存算分离普及
  AI 与湖仓结合（特征/训练直接读湖）

---

九、小结

实时数据湖的核心是表格式带来的 ACID + 流批一体能力。从数据湖 1.0（能存不能治）到 Lakehouse 2.0（实时可治理），解决的是"全量、可信、实时"三者的统一。落地时建议：先离线湖仓打底，再加实时入湖，最后用 Flink + 表格式实现流批一体。