2、数据仓库的崛起：从OLTP到OLTP，传统数据仓库的架构设计与ETL流程
说实话，我刚入行那会儿，大家还在争论“数据库能不能搞定一切分析”。那时候业务系统跑得挺欢，但一到月底出报表，DBA就愁眉苦脸——OLTP扛不住啊。
为什么会这样？因为OLTP和OLAP，根本就是两路人。
2.1 OLTP与OLAP：天生一对冤家
OLTP（联机事务处理）追求的是快——快速插入、快速更新、快速查询单条记录。你想想看，银行转账、电商下单、库存扣减，哪个不是毫秒级响应？
但OLAP（联机分析处理）追求的是广——扫描大量数据、做聚合、做钻取、做趋势分析。一张报表可能要扫几百万行，甚至上亿行。
让OLTP去干OLAP的活，就像让短跑运动员去跑马拉松——不是不能跑，是跑完就废了。
| 维度 | OLTP | OLAP |
|---|---|---|
| 典型场景 | 订单录入、库存更新 | 月度销售分析、用户画像 |
| 数据模型 | 实体关系模型（3NF） | 星型/雪花型模型 |
| 查询特点 | 短、频、快 | 长、大、复杂 |
| 索引策略 | B+树为主 | 位图索引、列式存储 |
| 并发要求 | 高并发读写 | 低并发高吞吐 |
我记得有个项目，客户非要用Oracle RAC跑BI报表。结果一到月底，业务系统就卡死，连下单都受影响。后来我们硬是把分析查询迁到了单独的数据仓库，世界才清净了。
2.2 传统数据仓库的经典架构
数据仓库不是凭空冒出来的。它要解决的核心问题就一个：把分散在各个OLTP系统中的数据，整合成一个统一的、面向分析的数据集合。
我习惯把传统数仓架构分成三层：
- 底层（数据存储层）：存放历史数据和汇总数据，通常是关系型数据库或MPP数据库。
- 中间层（数据整合层）：ETL的核心战场，负责抽取、清洗、转换、加载。
- 上层（数据访问层）：报表工具、BI工具、即席查询的入口。
嗯，这里要注意——很多人以为数仓就是“把数据倒进去就行”。其实不然。数仓的灵魂在于建模。
2.3 建模方法论：星型与雪花
传统数仓建模，绕不开两个人：Bill Inmon和Ralph Kimball。
Inmon主张“自上而下”——先建企业级3NF模型，再衍生数据集市。Kimball主张“自下而上”——直接从业务出发，建星型模型。
我个人更倾向Kimball的思路。为什么？因为快。你想想看，业务部门等不了你花半年建一个完美的企业模型。他们今天就要看昨天的销售数据。
星型模型长什么样？说白了就是一张事实表在中间，周围围着几张维度表。
雪花模型呢？就是把维度表再规范化。比如“商品维度”拆成“商品表”和“品类表”。好处是节省存储，坏处是查询要关联更多表。我一般只在维度表特别大（比如上千万行）时才用雪花。
2.4 ETL流程：数据仓库的命脉
ETL（Extract, Transform, Load）是数据仓库最苦最累的活。我做过好几个数仓项目，ETL代码占了总工作量的60%以上。
一个典型的ETL流程长这样：
- 抽取（Extract）：从源系统拉数据。全量抽取还是增量抽取？这是个问题。
- 清洗（Cleaning）：去重、补空、格式统一、异常值处理。
- 转换（Transform）：业务逻辑计算、维度退化、缓慢变化维处理。
- 加载（Load）：写入目标表。全量覆盖还是增量合并？
我曾经在一个项目中踩过大坑——源系统的订单表没有时间戳字段，导致我们只能每天全量抽取。一张2亿行的表，全量抽一次要4个小时。后来我们逼着业务方加了更新时间字段，才改成增量抽取，时间降到了15分钟。
2.5 缓慢变化维（SCD）的处理
维度数据是会变的。比如用户改了手机号，商品换了分类。怎么处理这些变化？
业界有几种常见策略：
- SCD Type 1：直接覆盖旧值。简单粗暴，但历史数据就丢了。
- SCD Type 2：新增一条记录，用生效日期和失效日期标记。保留完整历史，但表会越来越大。
- SCD Type 3：加一个“上一次值”字段。折中方案，但只能保留一次变化。
我个人的习惯是：核心维度用Type 2，非核心维度用Type 1。比如用户维度，我肯定要保留历史——哪天要分析用户流失，没有历史数据根本做不了。但商品的颜色、尺寸这类属性，直接覆盖就行，没人关心三个月前这件衣服是什么颜色。
2.6 传统数仓的瓶颈
说了这么多好处，也得说说传统数仓的痛点。毕竟，没有这些痛点，就不会有后面的数据湖、数据网格。
- 扩展性差：单机数据库撑死几十TB，MPP集群虽然能扩，但成本高得吓人。
- ETL维护成本高：几百个ETL任务，依赖关系错综复杂。一个任务挂了，下游一片红。
- 数据延迟大：T+1是常态，想做到实时？得加钱，加架构。
- 业务响应慢：业务部门要一个新指标，从需求到上线，少则两周，多则两个月。
我记得有个金融客户，他们的数仓团队有30个人，每天就干一件事——维护ETL。业务部门提的需求排到了三个月后。你说这能忍？
但话说回来，传统数仓在它那个时代，确实是革命性的。它第一次让企业有了“统一的数据视图”。没有它，后面的数据湖、数据网格都是空中楼阁。
2.7 一张图看懂传统数仓架构
下面这张图，是我当年给团队培训时画的。它概括了传统数仓的核心流程：从OLTP源系统，经过ETL，进入数仓分层，最后服务于BI报表。
这张图里，我特意把ETL流程标红了。为什么？因为它是整个数仓最脆弱、也最关键的一环。ETL挂了，下游全停。我见过太多团队在ETL上栽跟头——要么是源表结构变了没通知，要么是数据量暴增导致超时，要么是依赖链太长查不出根因。
嗯，传统数仓的故事讲到这里。它很强大，也很笨重。它解决了“数据孤岛”的问题，却带来了“ETL泥潭”的新问题。下一站，我们会看到数据湖如何试图解决这些痛点——当然，那是后话了。