大数据理论与实践总结课程总结 - 从数据仓库到湖仓一体

GrissomFI2025年12月20日约 3 分钟

本课程聚焦从传统数据仓库到数据湖、再到湖仓一体（Lakehouse）的演进路径，强调原理讲解与架构思维训练，帮助学习者从工程实践和系统设计两个维度理解现代数据平台的整体图景。

本节课程与前续章节（HDFS 文件系统、MapReduce/Spark 计算、Hive 数仓、Parquet 列存、ETL 与流式计算等）形成闭环：前面的课程回答“如何存、如何算、如何流”，本课程回答“整体架构应该长成什么样，以及为什么会这样长”。

通过本课程的学习，读者将能够：

系统回顾从传统数据仓库到数据湖、再到湖仓一体的演进脉络与驱动力。
理解数据湖常见问题（数据沼泽、元数据失控）的根源与工程症状。
掌握 Lakehouse 的核心技术基石——Table Format（表格式） 的设计思想与实现原理。
建立现代数据栈中存储、计算、格式、编排等组件之间的角色分工与协同关系。
能够基于典型业务场景，对比分析 Data Warehouse / Data Lake / Lakehouse 的架构优劣与适用边界。

本章在流计算“跨行转账对账”案例的基础上，沿着同一组业务场景，依次走过数据仓库 - 数据湖 - 湖仓一体三个阶段。通过对“同一家商业银行同一类业务”的持续追踪，读者可以更直观地看到：架构并不是凭空设计出来的，而是被业务需求和成本压力一点一点“推”出来的。

在后续章节中，凡是提到“数据仓库”，都可以先粗略地理解为：围绕分析和决策场景构建的、以主题为中心的历史数据集合，用统一口径为报表和分析服务，而不是面向在线交易的业务数据库。

从业务演进与技术演进的双重视角来看，本章重点围绕三个问题展开：

在只有 T+1 数据仓库时，哪些监管报表 / 历史分析类诉求已经被很好满足，哪些实时风控 / 数据科学类诉求开始显得吃力？
为了引入更多数据类型、降低长期存储成本，银行为什么会选择建设数据湖，而不是简单“再堆一套数仓”或“继续扩容现有数仓”？
当数据湖逐渐“沼泽化”之后，银行为什么又不得不在其之上重建类似数据库的管理能力，走向 Lakehouse，用一套架构同时支撑批处理与流式更新？

大数据技术的发展并非一蹴而就，而是随着业务需求（从 T+1 到实时）、数据类型（从结构化到非结构化）和成本考量而不断演进的。本章通过典型应用场景和架构拆解，梳理这一演变过程。在第 1 章中，我们以某商业银行的跨行转账对账业务为主线，观察了同一业务在“数据仓库—数据湖—湖仓一体”三个阶段中的演进；本章则从更普遍的行业实践出发，对这三代数据架构的典型形态和共性特征进行抽象与对比。

Lakehouse 之所以能成立，核心在于引入了 Table Format（表格式） 这一中间层。它不是一个具体的计算引擎，而是一套“如何在文件之上管理表”的协议与实现。在第 2 章中，我们从架构视角分析了三代数据架构以及 Lakehouse 的整体形态，本章将聚焦于支撑 Lakehouse 的核心技术机制——Table Format。

本章聚焦 Lakehouse 在工程实现层面的“关键内功”，围绕 Iceberg 表格式的内部机制进行拆解。与第 1 章的银行案例和第 2 章的三代架构抽象相呼应，本章将依次回答三个问题：第一，Iceberg 如何通过多层元数据结构在对象存储之上重建表级视图与版本管理；第二，它是如何在不可变文件系统上实现 Copy-On-Write 写入、快照隔离与时间旅行，从而提供接近数据库的 ACID 语义；第三，它又如何通过隐藏分区、Data Skipping、快照保留与垃圾回收等机制，在保证实时性与一致性的同时控制查询开销与存储成本。