先用一句话理解数据仓库（5 分钟）

数据仓库 = 企业的数据大脑

业务系统（订单、用户、支付、车辆、设备）产生数据

→ 数据仓库把数据统一整理

→ 最终用于报表、分析、运营、风控、推荐、AI

把它想象成：

系统	类比
MySQL（业务库）	超市收银台
数据仓库（Hive/Doris）	超市总部仓库
BI 报表（Superset、PowerBI）	老板看的经营看板

核心区别：

业务库（OLTP）	数据仓库（OLAP）
处理交易	处理分析
增删改查频繁	读多写少
单条记录操作	海量数据聚合
强调事务	强调查询速度
面向用户操作	面向决策分析

记忆口诀：

OLTP 管“今天发生了什么”，OLAP 管“过去一段时间为什么会这样”

数据仓库到底解决什么问题（10 分钟）

假设你做过电商系统

业务库里有：

• 订单表

• 用户表

• 商品表

• 支付表

• 物流表

老板突然问：

• 最近 30 天销售额是多少？

• 哪些用户复购率最高？

• 上海地区退货率为什么上升？

• 618 活动带来了多少新增用户？

• 哪些商品经常一起购买？

如果直接查 MySQL：

数据量一大：

• 查询慢

• 影响线上交易

• 跨表关联复杂

• 历史数据难保存

• 口径不统一（每个人算销售额的方法不同）

于是有了数据仓库——

数据仓库做的 4 件事

• 采集数据：把 MySQL、日志、设备数据汇总过来

• 清洗数据：去重、补全、统一格式

• 建模数据：统一“销售额”“用户数”等指标口径

• 加速分析：让报表秒级返回

数据仓库最重要的架构（15 分钟）

这是你必须记住的一张图

从左到右：

业务系统 → ODS → DWD → DWS → ADS → BI 报表

ODS原样搬，DWD洗干净，DWS算好数，ADS直接看

层级	全称	核心定位	记忆口诀
ODS	Operational Data Store<br>（操作数据存储 / 贴源层）	原始数据镜像，从业务系统原样同步	"原样照搬，不做加工"
DWD	Data Warehouse Detail<br>（数据明细层）	清洗后的明细数据，最细粒度，关联维度	"明细清洗站，脏进净出，粒度不变"
DWS	Data Warehouse Service<br>（数据汇总层 / 主题宽表层）	按主题预聚合、预计算，建宽表	"预制菜工厂，直接上桌"
ADS	Application Data Store<br>（数据应用层 / 数据集市）	面向具体业务场景，直接支撑报表/BI/算法	"成品上桌，即查即用"
DIM	Dimension<br>（维度表）	描述性信息，提供分析视角（时间、地区、产品等）	"看数据的眼睛"

1. ODS（原始数据层）

全称：Operational Data Store

作用：把业务数据原样搬过来

特点：

• 几乎不加工

• 保留原始字段

• 便于追溯问题

• 相当于“数据备份区”

记忆：ODS = 原始仓库。

1. DWD（明细数据层）

全称：Data Warehouse Detail

作用：把脏数据变成标准数据

这里会：

• 去重

• 过滤无效订单

• 统一时间格式

• 统一金额精度

• 补充维度信息

记忆：DWD = 干净的明细数据

1. DWS（汇总数据层）

全称：Data Warehouse Summary

作用：提前算好常用指标

例如：

按天统计销售额，于是有了～

日期	销售额
2026/7/1	100 万
2026/7/2	120 万

以后老板查日报，就不用再扫几亿订单了。

记忆：DWS = 指标汇总层。

1. ADS（应用数据层）

全称：Application Data Service

作用：直接给报表、运营、产品使用。

特点：

• 面向具体业务场景

• 字段已经非常容易理解

• BI 工具直接查询

记忆：ADS = 给人看的数据。

维度表和事实表（10 分钟）

这是数据建模的核心

如下图就是经典的“星型模型”

暂时无法在飞书文档外展示此内容

事实表（Fact）

记录“发生了什么”

例如订单事实表：

order_id	user_id	product_id	amount	create_time
1001	1	101	299	2026/7/1

特点：

• 数据量大

• 不断增长

• 包含可统计指标（金额、数量等）

记忆：Fact = 事件。

维度表（Dimension）

描述“是谁/什么/哪里”

例如用户维度表（描述是谁）：

user_id	gender	city	age
1	男	上海	28

特点：

• 数据量小

• 变化较少

• 用于分类分析

记忆：Dimension = 标签。

为什么要分开？

因为你经常会问：

“上海的 28 岁男性用户，本月消费了多少钱？”

PS：只看事实表（订单表）是没办法知道是哪个用户下了当前的订单的，只能从用户表（维度表 -> 用户维度）中获取

工具大盘点（10 分钟）

🏭 大数据工厂全景图

工具	定位
MySQL	业务数据库（OLTP）
Kafka	实时数据通道（传输数据）
Flink	实时计算（数据边来边算的流水线）
Hive	离线数据仓库（便宜大碗的大仓库）
Spark	大规模数据计算（搬运/加工的大卡车）
Doris	高性能OLAP查询（秒级分析）
Superset	BI可视化
Airflow/DolphinScheduler	任务调度

---

逐个拆解

1️⃣ Hive = 大仓库（便宜存海量数据）

维度	解释
比喻本质	像亚马逊的巨型仓库，不在乎取货速度，只在乎"能装下全世界的东西且租金便宜"
技术本质	基于 Hadoop 的数据仓库工具，用 SQL（HiveQL）操作 HDFS 上的数据
核心特点	存储成本极低（用普通硬盘）、可扩展至 PB 级、查询延迟高（分钟级甚至小时级）
为什么慢	底层把 SQL 翻译成 MapReduce/Tez 任务，像"翻仓库找货要填很多表格走流程"
典型场景	T+1 离线报表、历史数据归档、海量日志存储、数据湖底座

💡 一句话：Hive 是"存得起、查得慢"的仓库管理员，适合"明天要知道昨天卖了什么"，不适合"现在立刻要知道这一秒谁在下单"。

---

2️⃣ Spark = 大卡车（负责搬运和加工数据）

维度	解释
比喻本质	不是仓库本身，而是运输队+加工厂。它从仓库拉货，在车里加工，再送到目的地
技术本质	内存计算引擎，支持批处理（Spark SQL）和流处理（Spark Streaming）
核心特点	比 Hive 快 10-100 倍（数据放内存里算）、支持 SQL/Python/Scala 多种语言
与 Hive 关系	Spark 可以"开进 Hive 仓库"（Spark on Hive），直接读取 Hive 表做计算，也可以把结果运回 Hive
典型场景	复杂 ETL 清洗、机器学习特征工程、海量数据聚合计算、替代 MapReduce

💡 一句话：Spark 是"跑得快、力气大"的卡车，既能从 Hive 拉货加工，也能直接自己接活（比如处理 Kafka 来的数据）。

---

3️⃣ Doris = 高速查询引擎（负责秒级分析）

维度	解释
比喻本质	像超市的收银台+货架，东西不多但摆放极整齐，扫码立刻出结果
技术本质	MPP（大规模并行处理）架构的 OLAP 数据库，专为分析型查询设计
核心特点	查询毫秒级~秒级、支持高并发、自带向量化执行和智能索引
与 Hive 区别	Hive 是"仓库"（存原始数据），Doris 是"展示厅"（存加工后的结果数据，供人看）
典型场景	BI 报表、实时大屏、用户行为分析、即席查询（Ad-hoc）

💡 一句话：Doris 是"查得飞快但租金贵"的展示厅，只放加工好的精华数据，不放原始垃圾数据。

---

4️⃣ Flink = 实时流水线（数据边来边算）

维度	解释
比喻本质	像食品厂的流水线，原料（数据）从传送带进来，一边流动一边被加工包装
技术本质	真正的流处理引擎，基于事件驱动和状态计算
核心特点	低延迟（毫秒级）、精确一次（Exactly-Once）语义、支持事件时间/处理时间
与 Spark Streaming 区别	Spark Streaming 是"微批处理"（假装流处理，其实是一小批一小批算），Flink 是"真·逐条处理"
典型场景	实时风控、实时推荐、实时大屏、异常检测、IoT 数据处理

💡 一句话：Flink 是"数据不停流，计算不停歇"的流水线，适合"这一秒的数据必须这一秒出结果"。

---

5️⃣ Kafka = 数据快递站（传输数据）

维度	解释
比喻本质	像顺丰中转站，不生产数据，也不消费数据，只负责高效、可靠地中转
技术本质	分布式消息队列（MQ），基于发布-订阅模式
核心特点	高吞吐（百万级/秒）、可持久化、数据可回溯（像快递单号可追踪）
核心概念	Producer（寄件人）→ Topic（快递线路）→ Consumer（收件人）→ Partition（分拣窗口）
典型场景	系统解耦、流量削峰、日志收集、实时数据总线

💡 一句话：Kafka 是"只管传、不加工"的快递站，所有组件都通过它交换数据。

---

🔗 完整协作流程：以"电商实时+离线分析"为例

假设你是一个电商平台，用户每下一单，数据怎么在这套系统里流转？

不知道有没有小伙伴注意到，上面有两条链路：

• Kafka → Flink → Doris

• Kafka → Spark → Doris

Flink 往 Doris 写数据，Spark 也往 Doris 写数据，二者有什么不一样吗？

链路	写入 Doris 的内容	时延	数据特征	用途	写入方式
Flink → Doris	实时增量结果	毫秒~秒级	最新、轻量、高频更新	实时大屏、实时监控	流式写入（Stream Load）
Spark → Doris	离线批量结果	小时~天级	全量、厚重、低频更新	深度报表、历史分析	批量写入（Broker Load / Spark Connector）

---

💡 那么问题来了：为什么需要这么多组件？

因为大数据领域有一个不可能三角：

海量存储 + 高速查询 + 低成本 = 三者不可兼得

组合	解决了什么	牺牲了什么
Hive 单独用	海量+低成本	速度
Doris 单独用	高速+好用	存储成本（贵）+ 容量上限
Hive + Spark	海量+加工能力	实时性
Kafka + Flink + Doris	实时+高速	复杂度和成本

所以实际架构是分层协作：原始数据便宜存 Hive → 批量加工用 Spark → 实时处理用 Flink → 结果精华放 Doris 快速查询 → 全用 Kafka 串联。

搞定～撒花🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸🌸