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

---

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

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

想象一下这个场景：

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

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

Excel 的三板斧

功能	用法	局限
VLOOKUP	跨表关联查询	百万行就卡死
数据透视表	多维度汇总分析	数据源一变全乱套
宏（VBA）	自动化处理	代码难维护，容易炸表

痛点来了

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

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

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

---

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

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

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

答案：上数据库。

关系型数据库的崛起

数据库	定位	经典场景
Oracle	企业级巨无霸	银行、电信、大型制造
SQL Server	微软生态利器	中小企业、政务系统
MySQL	互联网开源首选	互联网公司、Web 应用
PostgreSQL	开源高级功能	GIS、金融、科研

数据库解决了什么？

-- 以前用 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 数据库

特性	数据库 (OLTP)	数据仓库 (OLAP)
设计目的	业务交易	决策分析
数据模型	规范化 (3NF)	星型/雪花模型
查询模式	点查、小范围查询	全表扫描、聚合计算
数据量	GB 级	TB 级
更新频率	实时	每日/每周批量
典型产品	Oracle, MySQL	Teradata, Oracle Exadata

经典技术栈：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;

商业数据仓库产品

产品	厂商	特点	适用场景
Teradata	NCR	MPP 架构，海量并行处理	全球顶级金融、电信
Oracle Exadata	Oracle	软硬一体，极致性能	大型企业核心分析
IBM Netezza	IBM	数据仓库一体机先驱	中型企业快速部署
Greenplum	Pivotal/VMware	开源 MPP 数据库	互联网、云计算
Vertica	HP	列式存储，高压缩比	实时分析、日志分析

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 三驾马车

组件	作用	类比
HDFS	分布式文件存储	把数据切成块，存到几百台机器上
MapReduce	分布式计算框架	把计算任务拆成小块，并行处理
YARN	资源调度管理	集群的交通警察，谁用多少资源它说了算

代码示例：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 时代的百花齐放

技术	类型	解决的问题
Hive	数据仓库工具	用类 SQL 语法查询 HDFS 数据
Pig	数据流语言	更灵活的数据处理脚本
HBase	NoSQL 数据库	海量数据的实时读写
Spark	内存计算框架	MapReduce 太慢，内存计算快 100 倍
Kafka	消息队列	海量实时数据流处理
Storm	实时计算	毫秒级流处理

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 数据仓库

特性	数据仓库	数据湖
数据类型	结构化数据	结构化 + 半结构化 + 非结构化
存储格式	规范化表结构	原始格式保留
Schema	写入时定义（Schema-on-Write）	读取时定义（Schema-on-Read）
成本	高（专用硬件 + 商业软件）	低（廉价存储如 S3、HDFS）
用户	业务分析师（SQL）	数据科学家（Python、R、Spark）
代表产品	Teradata、Exadata	AWS S3 + Athena、Azure Data Lake

数据湖的三驾马车

技术	厂商	作用
AWS S3	Amazon	对象存储，数据湖的底座
Delta Lake	Databricks	在数据湖上实现 ACID 事务
Apache Iceberg	Netflix/Apache	开放式表格式，数据湖表管理

数据湖的黑暗面

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

问题	表现
数据质量差	垃圾进，垃圾出。没人知道湖里的数据对不对
元数据缺失	这张表从哪来？代表什么？谁能用？没人知道
查询性能差	原始数据直接查？性能慢到怀疑人生
数据治理难	GDPR、数据隐私？湖里的数据根本理不清
安全管控弱	权限粒度粗，敏感数据泄露风险高

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

---

第六章：湖仓一体（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 开源的项目，核心特性：

特性	说明	价值
ACID 事务	数据湖支持原子性写入	不再担心写入一半崩溃
时间旅行	记录所有版本，可以回滚	SELECT * FROM table VERSION AS OF 3
Schema 演化	表结构自动兼容变化	加字段不用删表重建
Z-Ordering	智能数据布局优化	查询性能提升 10-100 倍
统一流批	同一套代码处理流和批	开发效率翻倍

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
""")

主流湖仓一体平台

平台	厂商	技术栈	特点
Databricks	Databricks	Delta Lake + Spark	湖仓一体概念提出者
Snowflake	Snowflake	原生架构	纯 SaaS，零运维
BigQuery	Google	云原生	与 GCP 深度集成
Redshift Spectrum	AWS	Redshift + S3	数仓查询数据湖
StarRocks	开源/镜舟	MPP + 湖仓	国产高性能
Apache Doris	开源/百度	MPP	实时分析利器

---

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

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

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

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

这导致：

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

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

数据中台的核心理念

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

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

数据中台的四大能力

能力	说明	举例
数据汇聚	把散落在各处的数据统一接入	统一数据湖/仓库
数据治理	保证数据质量、安全、合规	数据标准、血缘分析
数据服务	把数据封装成 API，供业务调用	用户画像 API、风控 API
数据资产	盘点企业有哪些数据资产	数据目录、资产地图

数据中台 vs 数据仓库

维度	数据仓库	数据中台
定位	数据存储和分析工具	企业级数据能力平台
目标用户	数据分析师	全公司所有员工
技术重点	ETL + OLAP	数据治理 + 数据服务
组织影响	IT 部门项目	需要业务部门配合
衡量标准	查询速度、报表准确性	数据复用率、业务赋能

数据中台的坑

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

坑	原因	避坑建议
做成了数据垃圾堆	只建平台，不治理数据	配套数据治理流程
IT 部门闭门造车	不了解业务需求	让业务部门深度参与
技术选型追新	什么火用什么	选成熟的，不选最炫的
期望过高	以为中台万能	分阶段建设，先解决核心问题

---

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

趋势一：云原生数据架构

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

---

给你的建议

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

企业规模	数据量	推荐架构	技术栈
初创公司	< 1TB	云数据库	RDS + BI 工具
中小企业	1-10TB	云数据仓库	Snowflake/BigQuery
大型企业	10TB-1PB	湖仓一体	Databricks + Delta Lake
超大规模	> 1PB	自研 + 开源	Spark + Iceberg + 自研中台

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

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

---

相关阅读

• SQL Server Always On 可用性组完整配置教程
• 安装 Hermes 桌面版，连接阿里云百炼

关于作者

一名从 Excel 时代一路走到湖仓一体时代的数据老兵。从 VLOOKUP 到 Delta Lake，从单机到分布式，见证了中国大数据架构的每一次变革。写这篇文章，既是总结，也是致敬。