从 Excel 到湖仓一体:一个 DBA 眼中的大数据架构 20 年演变史

如果把企业的数据比作水，那数据架构就是引水、蓄水、用水的工程。从 Excel 里的一潭死水，到今天湖仓一体的汪洋大海，这 20 年我们究竟经历了什么？

第一章：蛮荒时代（1990s-2000s）—— Excel 里的天下

业务背景：小企业，小数据

想象一下这个场景：

2000 年，某城市的连锁超市刚刚开业，每天营业额几万块钱。老板坐在办公室，打开 Excel，把 5 家门店的销售数据复制粘贴到一个表格里。月底了，用 SUMIF 和 VLOOKUP 做一张报表，发给总部。搞定。

这就是最原始的数据管理形态。数据量：百万级行。处理能力：一台电脑。分析深度：汇总统计 + 简单图表。

Excel 的三板斧

痛点来了

当这家超市从 5 家扩张到 50 家，Excel 开始报警：

• 文件打不开：50 个门店的数据汇总到一张表，Excel 直接卡死
• 数据不一致：A 同事改了数据没保存，B 同事还在用旧版本
• 没法多人协作：小张，你表格锁了吗？我打不开了！

结论：当数据量突破百万行、多用户需要并发访问时，Excel 这台自行车已经蹬不动了。

第二章：数据库时代（2000s-2010s）—— Oracle、MySQL 登场

业务背景：业务爆发，数据量迈入千万级

超市变成了连锁集团，门店扩张到 500 家，每天产生数十万笔交易。Excel 彻底不行了，怎么办？

答案：上数据库。

关系型数据库的崛起

数据库解决了什么？

-- 以前用 Excel 做 3 分钟的查询，现在 SQL 毫秒出结果
SELECT
    store_name,
SUM(amount) AS total_sales,
COUNT(*) AS order_count
FROM sales s
JOIN stores st ON s.store_id = st.store_id
WHERE sale_date >= '2005-01-01'
GROUP BY store_name
ORDER BY total_sales DESC;

数据库带来的变革：

• 数据集中存储：不再散落在 50 个 Excel 文件里
• 事务保证：ACID（原子性、一致性、隔离性、持久性），钱不会算错
• 并发访问：100 个员工同时查数据，系统稳如狗
• 数据安全：权限控制、备份恢复、审计日志

新痛点：报表慢得像蜗牛

数据库解决了存和查的问题，但老板要看报表时——

-- 老板要的季度汇总报表（千万级数据）
SELECT region, product_category, MONTH(sale_date), SUM(revenue)
FROM sales
WHERE YEAR(sale_date) = 2008
GROUP BY region, product_category, MONTH(sale_date);
-- 执行时间：10 分钟...老板已经走了

为什么慢？ 因为数据库是为交易设计的（OLTP），不是为分析设计的。老板要的是分析，数据库给的是查询。

第三章：数据仓库时代（2000s-2010s）—— 为分析而生的系统

业务背景：从存数据到用数据

2008 年金融危机后，企业开始意识到：数据不仅是记录，更是资产。谁分析得快、分析得准，谁就能在危机中活下来。

于是，专门用于分析的系统——**数据仓库（Data Warehouse）**诞生了。

数据仓库 vs 数据库

经典技术栈：Kimball vs Inmon

Ralph Kimball 的维度建模和 Bill Inmon 的企业信息工厂，两种流派争霸江湖：

-- 星型模型示例（Kimball 流派）
-- 事实表 + 维度表，查询性能飞起
SELECT
    d.calendar_year,
    p.product_name,
    c.customer_region,
SUM(s.sales_amount) AS revenue
FROM fact_sales s
JOIN dim_date d ON s.date_key = d.date_key
JOIN dim_product p ON s.product_key = p.product_key
JOIN dim_customer c ON s.customer_key = c.customer_key
WHERE d.calendar_year = 2009
GROUP BY d.calendar_year, p.product_name, c.customer_region;

商业数据仓库产品

ETL：数据仓库的流水线

数据仓库不是魔法，数据要从各个业务系统搬运过来，这个过程叫 ETL（Extract-Transform-Load）。

业务数据库 A --+
业务数据库 B --+-- ETL 工具 -- 数据仓库 -- BI 报表
业务数据库 C --+

经典 ETL 工具：Informatica、IBM DataStage、Microsoft SSIS、Pentaho Kettle（开源）。

数据仓库的局限

当企业的数据量从 TB 级增长到 PB 级，当数据来源从结构化表格扩展到日志、图片、视频，数据仓库开始力不从心：

• 成本高：Teradata 一年 license 费用够买套房
• 扩展性差：Scale-up（纵向扩展）到顶了，加钱都没用
• 不支持非结构化数据：图片、日志、JSON？臣妾做不到啊
• 实时性不足：T+1 的报表，老板要的是现在的数据

结论：当数据量迈入 PB 级，当大数据三个字开始在技术圈刷屏，一个新的时代来临了。

第四章：大数据时代（2010s）—— Hadoop 的三驾马车

业务背景：互联网爆发，数据量呈指数级增长

2010 年，全球数据量达到 ZB 级别。Facebook 每天处理 500TB 新数据，Twitter 每秒产生数万条推文，YouTube 每分钟上传 100 小时视频。

传统数据库和数据仓库的 Scale-up 模式走到头了——你买不到能装下全世界数据的超级服务器。

Hadoop：穷人的超级计算机

2006 年，Doug Cutting 受 Google 论文启发，创造了 Hadoop。

核心理念：用一堆廉价的 PC 组成集群，把大数据切成小块分布存储和处理。Scale-out（横向扩展），而不是 Scale-up。

存储层:  HDFS (Hadoop Distributed File System)
计算层:  MapReduce
数据库:  HBase (NoSQL)
查询层:  Hive, Pig
协调层:  ZooKeeper
调度层:  YARN

Hadoop 三驾马车

代码示例：MapReduce 统计词频

// 经典的 WordCount，大数据界的 Hello World
public class WordCount {
public static class TokenizerMapper extends Mapper<Object, Text, Text, IntWritable> {
private final static IntWritable one = new IntWritable(1);
private Text word = new Text();

public void map(Object key, Text value, Context context) {
StringTokenizer itr = new StringTokenizer(value.toString());
while (itr.hasMoreTokens()) {
                word.set(itr.nextToken());
                context.write(word, one);
            }
        }
    }

public static class IntSumReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
public void reduce(Text key, Iterable<IntWritable> values, Context context) {
int sum = 0;
for (IntWritable val : values) {
                sum += val.get();
            }
            context.write(key, new IntWritable(sum));
        }
    }
}

Hadoop 时代的百花齐放

Spark：Hadoop 的继任者

2014 年，Apache Spark 横空出世。它保留了 Hadoop 的分布式基因，但用内存计算替代了磁盘读写，速度提升了一个数量级。

# PySpark：用 Python 处理 PB 级数据
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("BigDataAnalysis").getOrCreate()

# 读取 TB 级数据
df = spark.read.csv("hdfs://cluster/data/sales/200tb_data.csv", header=True)

# SQL 查询，分布式执行
result = df.groupBy("region").agg({"sales": "sum"})
result.show()

大数据时代的烦恼

Hadoop 生态很强大，但也很复杂：

• 技术栈太杂：Hive、Pig、Spark、Flink、Storm...学不完，根本学不完
• 数据孤岛：数据散落在 HDFS、Hive、HBase、MySQL 里，像一个个孤岛
• 元数据管理混乱：这张表存在哪？字段含义是什么？谁能访问？一问三不知
• 实时性不足：Spark Streaming 是准实时，真正的实时还得靠 Flink

第五章：数据湖时代（2010s-2020s）—— 原始数据的汪洋大海

业务背景：数据类型大爆发

2015 年，企业不仅要有交易数据，还要有：

• 日志数据：服务器日志、用户行为日志、IoT 传感器数据
• 图片数据：商品图片、用户上传照片、监控视频截图
• 视频数据：直播回放、短视频、监控录像
• 音频数据：客服录音、语音助手交互
• 文档数据：PDF、Word、邮件、聊天记录

这些非结构化数据，传统数据仓库根本放不了。

数据湖的诞生

**数据湖（Data Lake）**的理念很简单：

把所有原始数据，以原始格式，原封不动地扔进一个大池子里。什么时候用，什么时候再处理。

数据湖 (Data Lake)
  结构化数据    │  关系型表、CSV、JSON
  半结构化数据  │  XML、日志、NoSQL 文档
  非结构化数据  │  图片、音频、视频、PDF
              ↓
        按需处理和分析

数据湖 vs 数据仓库

数据湖的三驾马车

数据湖的黑暗面

数据湖一不小心就变成了数据沼泽（Data Swamp）。

结论：数据湖虽然便宜、灵活，但缺少事务保证和性能优化。企业开始思考：能不能把数据仓库的严谨和数据湖的灵活结合起来？

第六章：湖仓一体（Lakehouse，2020s）—— 鱼和熊掌兼得

业务背景：企业不想做选择题

2020 年，企业面临一个经典困境：

• 数据仓库：性能好、事务强，但贵、扩展性差、不支持非结构化数据
• 数据湖：便宜、灵活，但性能差、数据质量没保障

Databricks 提出了一个概念：Lakehouse（湖仓一体）。 简单说就是：在数据湖之上，用数据仓库的技术，实现两者的优点。

湖仓一体的核心思想

湖仓一体 (Lakehouse)

BI 报表    │  数据科学    │  机器学习    │  实时分析
-------------------------------------------------
SQL 查询层  │  DataFrame API  │  流处理 (Streaming)
-------------------------------------------------
Delta Lake / Apache Iceberg / Apache Hudi
（ACID 事务 + 时间旅行 + Schema 演化）
-------------------------------------------------
对象存储层 (S3 / ADLS / GCS / HDFS)

Delta Lake：让数据湖拥有数据库的心脏

Delta Lake 是 Databricks 开源的项目，核心特性：

PySpark + Delta Lake 示例

from pyspark.sql import SparkSession

spark = SparkSession.builder     .appName("LakehouseDemo")     .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")     .getOrCreate()

# 写入 Delta Lake（支持 ACID）
df.write.format("delta").mode("overwrite").save("/lake/sales_delta")

# 读取历史版本（时间旅行）
spark.read.format("delta")     .option("versionAsOf", 0)     .load("/lake/sales_delta")     .show()

# 更新数据（事务保证）
spark.sql("""
    UPDATE delta.\`/lake/sales_delta\`
    SET status = 'completed'
    WHERE order_id = 12345
""")

主流湖仓一体平台

第七章：数据中台（2015s-至今）—— 从工具到资产

业务背景：数据多，但用不起来

2015 年，阿里巴巴面临一个世界级难题：

淘宝、天猫、支付宝、菜鸟...每个业务都有自己的数据系统。同样的用户，在淘宝叫 user，在支付宝叫 account，在菜鸟叫 customer。同一个客户，有 10 个不同的 ID。

这导致：

• 做用户画像？数据对不上号
• 做精准营销？不知道这是同一个人
• 做数据分析？每个部门各干各的，重复建设

阿里巴巴的解决方案：数据中台。

数据中台的核心理念

        数据中台 (Data Middle Platform)

  用户中心  │  商品中心
  (One ID) │  (One SKU)
       |
  数据服务层
       |
淘宝 │ 天猫 │ 支付宝 │ 菜鸟

数据中台 = 数据 + 技术 + 组织

数据中台的四大能力

数据中台 vs 数据仓库

数据中台的坑

数据中台理念很好，但实践中也遇到过不少坑：

第八章：展望未来 —— 数据架构的下一站

趋势一：云原生数据架构

Serverless + 云原生 = 用多少付多少，不用管机器。

Snowflake 模式：存储与计算分离

存储层 (S3/GCS)     计算层 (Warehouse)
      |                    |
      +---------+----------+
                |
           按需弹性伸缩

趋势二：Data Fabric（数据编织）

不用把所有数据都搬到一个地方，而是用 AI 和元数据自动发现、连接、整合分布在各地的数据。

趋势三：AI 原生数据架构

大模型时代，数据架构要为 AI 服务：

• 向量数据库：存储 Embedding，支撑 RAG
• 知识图谱：结构化知识，让 AI 更聪明
• DataOps + MLOps：数据流水线自动化

总结：一张图看懂 20 年演变

数据量
  │
PB|--------------------- 湖仓一体 (Lakehouse)
  |                          Delta Lake, Snowflake
  |                          Apache Iceberg, StarRocks
  |
TB|----------- 数据湖 (Data Lake)
  |            AWS S3, Azure Data Lake, HDFS
  |
GB|------ 大数据 (Big Data)
  |        Hadoop, Spark, Hive, Kafka, Flink
  |
MB|-- 数据仓库 (Data Warehouse)
  |    Teradata, Oracle Exadata, Hive, Greenplum
  |
KB| 数据库 (RDBMS)
  |  Oracle, SQL Server, MySQL, PostgreSQL
  |
  └------------------------------------ 时间
      2000   2005   2010   2015   2020   2025

给你的建议

不同规模企业的数据架构选型

作为 DBA，你应该关注什么？

1. SQL 不会过时：无论架构怎么变，SQL 依然是数据分析的通用语言
2. 了解云原生：Snowflake、BigQuery、Databricks 这些云数仓是趋势
3. 拥抱开源：Spark、Flink、Iceberg、Doris 这些开源项目正在重塑行业
4. 学习数据治理：数据中台的灵魂是治理，技术只是手段
5. 关注 AI 场景：向量数据库、知识图谱、RAG，数据为 AI 服务

相关阅读