第8章
数据仓库
业务数据回答“发生了什么”，仓库数据回答“为什么”
本章导航：从记账到参谋
七个部分、四十七页：先立数据仓库的定义与四大特征，再分清 OLTP 与 OLAP，然后学多维模型与星型建模，动手做 OLAP 五操作，最后看体系结构、ETL 与三种部署模型。点击任意站点可直接跳转。
导入：问题从查一笔变成看三年
🧾 业务系统能回答的
订单 20260311-001 现在到哪了？仓库 A 的 SKU 库存还剩多少？——单笔、当前、精确。这是采购、销售、库存、财务各系统每天在干的事。
📈 管理层真正想问的
过去三年各区域、各品类的投递量如何变化？哪个承运商准时率在下滑？——跨系统、跨年度、多角度汇总。分散的业务系统答不了：在事务库上硬跑还会拖慢正常业务，口径还各说各话。
演进：系统越建越多，问题越来越大
定义：Inmon 的四词定义
20 世纪 90 年代初，“数据仓库之父” W. H. Inmon 在《Building the Data Warehouse》中给出经典定义：数据仓库是一个集成的、面向主题的、反映历史变化的、相对稳定的数据集合，用于支持管理决策过程。
🔗 集成性 Integrated
多源异构数据先清洗统一，才准进仓。
🎯 面向主题 Subject-Oriented
按分析主题（商品、客户、供应商）而非业务流程组织。
🕰️ 反映历史变化 Time-Variant
每个结构都带时间，保存 5—10 年历史快照。
🧊 相对稳定 Nonvolatile
只批量载入与查询，不做事务性增删改。
集成性：进仓之前，先过三道统一
🏷️ 统一命名
同一概念不同名：客户编号在 A 系统叫 CustID、B 系统叫 CustomerNo——进仓统一为一个名。
🔢 统一编码
同一属性不同码：性别在三系统里分别是“男/女”“1/0”“M/F”——进仓转成统一编码。
⚖️ 统一度量
同一量不同单位：国内仓以千克计重、国际航运以磅计重——进仓换算为统一标准。
🌊 水情数仓案例
防汛决策要同时看五路数据：水文站的水位流量降雨、气象部门的预报与台风路径、水利工程的大堤能力与水库蓄水、应急部门的人员部署、物资部门的储备调配。格式与频率各异——集成之后，指挥层才有一张统一、全面的视图。
面向主题：从按流程摆到按问题摆
原样：商场事务数据库按业务流程组织
这套组织忠实于业务活动，但数据与应用没有真正分离、抽象层次也不够：想回答“某类商品在各供应商处的成本与销量”，数据得跨四个子系统东拼西凑。
🎯 主题重组
按管理者的分析关注点定主题：商品、供应商、顾客——把散在各子系统里与同一主题相关的数据抽取、加工、汇总到一起。主题是“用户做决策时关注的核心对象”，先定问题、再摆数据。
反映历史变化：旧值不覆盖，快照追加
💴 一次调价的两种命运
商品价格 50 元 → 60 元：操作型库直接改成 60，旧值 50 永远消失；数据仓库保留两条——50 元（2024 年 1—6 月有效）、60 元（2024 年 7 月起有效），价格变动史完整可溯。
| 对比维度 | 操作型数据库 | 数据仓库 |
|---|---|---|
| 时间范围 | 当前数据，通常 60—90 天 | 长期历史，通常 5—10 年甚至更久 |
| 时间元素 | 关键结构中可能不含时间 | 每个关键结构都隐式或显式含时间 |
| 数据更新 | 新值覆盖旧值，历史状态丢失 | 按时间快照保存，变更追加为新记录 |
相对稳定：仓里只发生两件事
🚫 不做的事
- 源系统的 INSERT、UPDATE、DELETE 不直接出现在仓库环境
- 不需要事务处理、故障恢复、并发控制等复杂机制
- 数据与源系统物理分离保存
✅ 只做的事
- 数据的批量载入（ETL 定期搬入）
- 数据的查询访问（分析与报表）
正因如此，仓库可以放心为查询深度优化：大量索引、物化视图随便建，不必担心拖慢事务。
四特征收官表：与操作型库逐项对照
| 特征 | 核心要义 | 操作型数据库 |
|---|---|---|
| 集成 | 统一清洗多源异构数据，消除不一致 | 各源系统独立运行，编码标准各异 |
| 面向主题 | 围绕分析主题组织数据 | 围绕业务应用组织数据 |
| 反映历史变化 | 保留时间维度，支持时序分析与趋势发现 | 通常只存当前值，更新即覆盖 |
| 相对稳定 | 只载入和查询，不做事务性更新 | 频繁执行增删改 |
两种范式：办业务的与看业务的
🧾 OLTP 联机事务处理
对数据库的日常联机操作：一笔或一组记录的查询与修改。场景：购买下单、库存扣减、银行转账、工资发放、注册登记、记账核算。核心要求：响应快、安全与完整性严、事务吞吐高。它是传统 DBMS 的主业，服务日常运营。
📊 OLAP 联机分析处理
对海量历史数据的查询与分析：以不同形式展示数据，服务不同用户的分析需要。核心要求：能处理大数据量、执行复杂查询与多维分析。它是数据仓库的主业，服务分析决策。
十一维对比：处处相反的一对系统
| 维度（习题 2） | OLTP | OLAP |
|---|---|---|
| 面向性 | 面向顾客（事务操作） | 面向市场（分析决策） |
| 数据内容 | 当前的、详细的数据 | 历史的、汇总的数据 |
| 数据库设计 | E-R 模型、面向应用 | 星型/雪花模型、面向主题 |
| 访问模式 | 事务操作，读写并重 | 只读查询，但复杂度高 |
| 任务单位 | 简短事务，毫秒级 | 复杂查询，秒至分钟级 |
| 访问数据量 | 每次涉及数十至数百条 | 每次可能扫描数百万条 |
| 并发用户 | 数千至数万 | 数十至数百 |
| 数据库规模 | 100 MB 至数 GB | 100 GB 至数 TB |
| 度量指标 | 事务吞吐量 TPS | 查询吞吐量与响应时间 |
为什么必须分家（一）：性能上互相伤害
📄 行式存储为事务而生
DBMS 按 OLTP 优化：行式存储把一条记录的所有字段连续存放——插入、更新整条记录最快；索引、并发控制、恢复机制全都围着事务转。
📊 列式存储为分析而生
OLAP 要的是对单个字段的大规模聚合：列式存储把同一字段的值连续存放，算一列的总和/平均只读一列，效率天差地别。
为什么必须分家（二）：数据本身不是一份
🕰️ 历史
决策要长期历史做趋势与预测；操作型库为保事务效率，只留当前周期数据。
🧮 汇总
决策要多源数据的聚集与汇总；操作型库存的是细粒度原始数据，粒度对不上。
🧹 质量
多源系统的表示、编码、格式互不一致：先转换集成，分析才有效——正是特征一“集成性”的工作。
多维模型三件套：维、事实、度量
🧭 维（Dimension）
组织想记录的视角：时间（日期、月份、季度、年）、地点（街道、城市、省、国家）、商品（名称、品牌、类型、供应商类型）、分支机构。每个维配一张维表存描述信息。
🎯 事实（Fact）
围绕中心主题的业务事件，用事实表表示：每行一个事件，列是各维表的外键＋度量。
📏 度量（Measure）
事实的数字指标，是分析计算的对象：销售数量 units_sold、销售金额 dollars_sold、平均销售额 avg_sales。
数据立方体：一摞交叉表
方体：每少一维，就汇总一层
| 方体类型 | 维度数 | 说明 |
|---|---|---|
| 顶点方体 Apex | 0-D | 最高层汇总：全局总计（只有一个数） |
| 1-D 方体 | 1 维 | 按单一维度汇总，如按时间、按商品 |
| 2-D 方体 | 2 维 | 按两维组合汇总，如时间×商品 |
| 基本方体 Base | n-D | 最底层、最详细的汇总数据 |
概念分层：给每个维装粒度阶梯
🪜 它的作用（习题 5）
概念分层把低层细粒度概念映射到高层粗粒度概念，让用户能在各种抽象级别审查数据：沿阶梯上行＝上卷、下行＝下钻（§8.5 的两大操作）。维表里的属性列（day/month/quarter/year）就是分层的物化——第 22 页见真表。
星型模式：一颗事实表，众星捧月
⭐ 结构
一个事实表居中，若干维表环绕，各维表以主键被事实表外键引用——辐射状如星，故名。它是数仓建模最基本、最常用的模式。
🧭 读法
任何分析问题都翻译成：以事实表为中心，沿某几个维表筛选、分组，汇总度量。第 7 章的 E-R 图在这里退化成“中心—辐射”的固定形态。
事实表：每行一个业务事件
| Sales 事实表的列 | 类别 | 说明 |
|---|---|---|
| time_key | 维度外键 | 何时——引用时间维表 |
| item_key | 维度外键 | 何物——引用商品维表 |
| branch_key | 维度外键 | 何机构——引用分支维表 |
| location_key | 维度外键 | 何地——引用地点维表 |
| units_sold | 度量 | 销售数量（可加） |
| dollars_sold | 度量 | 销售金额（可加） |
| avg_sales | 度量 | 平均销售额（不可加） |
度量三型：能不能加是大事
✅ 可加度量
可沿所有维度求和：销售金额、销售数量。怎么汇总都不出错心。
⚠️ 半可加度量
只能沿部分维度求和，不能沿时间求和：库存余额、账户余额——把 12 个月的库存加起来毫无意义。
🚫 不可加度量
不能沿任何维度直接求和：利润率、平均单价。汇总时必须回到分子分母重新算（总利润÷总销售额）。
维表：又宽又浅的上下文库
| 维表 | 列（主键＋描述属性） | 内含分层 |
|---|---|---|
| time | time_key、day、day_of_the_week、month、quarter、year | 日→月→季→年 |
| location | location_key、street、city、state_or_province、country | 街道→城市→省→国家 |
| item | item_key、item_name、brand、type、supplier_type | 商品→类型/品牌 |
| branch | branch_key、branch_name、branch_type | — |
星型的取舍：故意不规范化
⭐ 四个优点
- 查询简单：以事实表为中心的星形连接，SQL 结构清晰
- 性能优越：维表扁平、连接层数少，优化器可做星形连接优化
- 易于理解：业务人员不懂规范化也能看懂模型
- 工具兼容：Tableau、Power BI 等 BI 工具原生支持
🧱 一个局限
维表有冗余：location 表每行都重复其城市所属的省和国家——按第 7 章眼光是传递依赖。但数仓里数据只批量载入、极少逐条更新，更新异常的风险被场景消解，换得的是查询的简单与快。第 7 章小结说的“有意识的反规范化”，原型就是这里。
落到物流：运输绩效星型模型
| 表类型 | 表名 | 包含内容 |
|---|---|---|
| 事实表 | Fact_Shipment | 维度外键 ＋ 运输里程、运输费用、在途天数、是否准时 |
| 维表 | Dim_Time | 年、季、月、日、节假日标识 |
| 维表 | Dim_Route | 起点城市、终点城市、线路编号、距离等级 |
| 维表 | Dim_Carrier | 承运商名称、类型、资质等级 |
| 维表 | Dim_Product | 货物名称、品类、重量等级、温控要求 |
雪花模式：星型的规范化变种
做法：把维表按层级拆开（以商品维为例）
维表拆出层级分支、形状像雪花——本质就是第 7 章的规范化搬进数仓。
✅ 得
维表冗余最小、省存储；维护规范：改一个品类名只需改一处。
❌ 失
查询要多做几层连接，性能下降；结构复杂，业务人员理解成本上升。
事实星座：多个星型共享维表
🔑 一致性维度
多个主题共享维度时的铁律：被共享的维表在所有事实表中定义与标识必须完全一致——同一商品在 Sales 与 Shipping 中都用 item_key＝1001。若销售与采购对同一商品各编一套号，那就不是星座、是两个数据孤岛，跨部门关联分析无从谈起。星座又称星系模式，大型企业常见。
三模式收官表（习题 6）
| 比较维度 | 星型模式 | 雪花模式 | 事实星座模式 |
|---|---|---|---|
| 结构复杂度 | 低 | 中 | 高 |
| 维表规范化 | 否（扁平宽表） | 是（多级拆分） | 部分规范化 |
| 查询性能 | 高（连接少） | 中（连接多） | 取决于具体查询 |
| 存储冗余 | 维表有冗余 | 冗余最小 | 视具体设计 |
| 适用场景 | 单一分析主题 | 维度数据量大且变化频繁 | 多主题共享维度 |
| 企业常见程度 | 最常见 | 较少使用 | 大型企业常见 |
上卷 Roll-Up：从细看到粗
🪜 方式一：沿概念分层攀升
地点维上把城市汇总到省份：南京、苏州、无锡……各市投递量相加，得江苏省总量。粒度变粗、数字变大、行数变少。
🧹 方式二：删去一个维度
直接移除某个维再汇总：如从“时间×地点×商品”中去掉商品维，得到按时间与地点的总盘。
下钻 Drill-Down：从总账翻到明细账
🌰 教材例：江苏省的 568 万件
管理者看到“2024 Q1 江苏省投递总量 568 万件”后想知道构成：在地点维上从省份下钻到城市，南京、苏州、无锡各市的分布立刻展开。上卷的逆操作——沿概念分层向下，或引入新维度。
➕ 方式二：加维度
在“时间×地点”之外引入承运商维：分析从二维变三维，各承运商在各地区的绩效被拆开来看——细节不是变出来的，是换一个切法露出来的。
切片 Slice：一个维度钉死一个值
🔪 定义与示例
在一个维度上选定一个特定值，把 n 维立方体切成 (n−1) 维子方体。例：在时间×地点×商品的销售立方体上选定时间＝2024 Q2，得到只含第二季度的二维切面——所有地点与商品在这一季的销售全景。本质：在该维上加一个等值过滤条件。
切块 Dice：多维同时圈范围
🎲 定义与示例
在两个或更多维度上同时选择（各选一个值范围或多个值），定义出一个子方体。例：时间∈{2024 Q1, Q2}、地点∈{北京， 上海}、商品∈{商品A, 商品B}——切出一个小立方体单独审视。本质：多维同时加范围/IN 过滤条件。
转轴 Pivot：数据不动，视角旋转
转轴前：时间为行
| 商品A | 商品B | 商品C | |
|---|---|---|---|
| 2024 Q1 | 3,450 | 2,400 | 5,500 |
| 2024 Q2 | 3,700 | 2,530 | 5,550 |
| 2024 Q3 | 4,100 | 2,680 | 6,200 |
转轴后：商品为行
| 2024 Q1 | 2024 Q2 | 2024 Q3 | |
|---|---|---|---|
| 商品A | 3,450 | 3,700 | 4,100 |
| 商品B | 2,400 | 2,530 | 2,680 |
| 商品C | 5,500 | 5,550 | 6,200 |
动手切：销售立方体的四种玩法
数据就是上一页的销售表（时间×商品，值为销售额）。依次点四种操作，看表格怎么变——注意每次变化对应哪条定义。
操作解读
当前是时间×商品的二维方体（基本方体的一个切面）：行是季度、列是商品，格中为销售额。
动画：《OLAP 多维操作》（1 分 53 秒）
扩展操作：跨表、穿透、算指标
🌉 钻过 Drill-Across
跨多个事实表查询（星座模式专用）：如“各商品销售额与运输成本之比”——销售额在 Sales 表、运输成本在 Shipping 表，靠共享的 item 与 time 维关联（第 26 页的一致性维度在此兑现）。
🔍 钻透 Drill-Through
穿透聚合层、用 SQL 直达底层明细记录：某月某线路运输成本异常偏高，钻透看该月该线路的每一笔运输单据找原因。下钻看汇总、钻透看单据，别混。
🏆 排序与计算
Top-N/Bottom-N：销售额前 10 的产品、准时率最低的 5 条线路。计算型操作：移动平均（过去 12 周平均周投递量）、增长率（仓储成本月环比）、占比（各区域运输成本占全国比）、累计汇总（年初至今累计销售额）。
三层架构：存储、引擎、工具
OLAP 引擎三型：关系、多维、混合
| 类型 | 实现方式 | 特点 |
|---|---|---|
| ROLAP | 在关系数据库之上用 SQL 扩展实现多维操作 | 可扩展性强、适合大数据量；性能受限于 SQL 引擎 |
| MOLAP | 专用多维引擎，数据以多维数组存储（预计算方体） | 查询响应快；数据量受内存与预计算规模限制（2ⁿ 方体问题，第 17 页） |
| HOLAP | 细粒度数据存关系库、聚合数据存多维库 | 兼顾存储容量与查询性能 |
前端层：用户摸到的四类工具
🔎 查询工具
支持用户自定义的即席查询（Ad-hoc Query）：想到什么查什么，分析探索的起点。
📰 报表工具
生成标准与定制报表，支持定时推送——管理层每天早晨收到的经营日报出自这里。
📊 分析工具
多维分析、统计分析与可视化展示——§8.5 的五种操作都在这里发生。
⛏️ 数据挖掘工具
用机器学习与统计算法发现隐含模式——这正是下一章的主角，数仓是它的粮仓。
ETL：数仓的进货通道（习题 8）
转换六活：清洗是重头戏
🖼️ 数据画像 Profiling
先给数据源“体检”：统计分布直方图与摘要表，摸清质量底数再设计清洗规则。
✅ 质量管理 QM
对照主数据值、业务规则与约束自动测试：不满足质量标准的数据不许进仓。
元数据：关于数据的数据
🛠️ 技术元数据
表结构、字段类型、索引、ETL 转换规则、源映射关系、加载时间表。
💼 业务元数据
业务术语定义、指标计算口径、数据所有者、数据质量标准。
📋 操作元数据
ETL 运行日志、加载记录、错误报告、性能监控数据。
企业数据仓库：全组织的统一平台
🏛️ 画像
- 收集跨越整个组织的所有主题信息
- 体量通常数百 GB 至 PB 级
- 建设周期长：数月至数年（全面规划与协调）
🎯 适用
大型企业的全局决策支持，尤其需要跨部门、跨业务线综合分析的场景：大型零售、金融机构、电信运营商的企业级数据平台是典型代表。
数据集市：先开分店的两种开法
🏪 独立数据集市
直连操作型数据源、独立构建（如市场营销、财务分析、物流运营各自建）。快、便宜、灵活；但缺乏统一标准，易成数据孤岛，各市之间口径可能不一致。
🏬 从属数据集市
从企业数据仓库中抽取子集构建：慢工出细活，数据标准与口径天然与总仓一致——一致性高，代价是依赖总仓先建成。
虚拟数据仓库：只建视图，不搬数据
🪟 做法与优点
不存独立副本，在操作型库之上建一系列视图呈现给分析用户。成本三者最低：无单独硬件、无 ETL 流程；最适合资源有限的小组织、快速原型验证、临时分析。
🧱 三条局限
- 分析查询会拖慢源系统的事务处理（第 13 页的冲突原样回归）
- 不支持历史数据（源库只存当前值）
- 查询功能受限于源库能力
部署收官表（习题 9）
| 比较维度 | 企业数据仓库 | 数据集市 | 虚拟数据仓库 |
|---|---|---|---|
| 建设成本 | 高 | 中至低 | 低 |
| 建设周期 | 长 | 较短 | 最短 |
| 数据覆盖 | 全企业 | 部门/主题域 | 视图可定义范围 |
| 数据一致性 | 高 | 独立型低、从属型高 | 依赖源系统 |
| 查询性能 | 高（专门优化） | 较高 | 低（影响源系统） |
| 历史数据 | 完善 | 受限 | 不支持 |
| 灵活性 | 扩展性强 | 灵活但可能碎片化 | 最灵活但功能受限 |
把本章走一遍：运输绩效模型设计
一句话带走本章：为分析而分家、按主题而重组、沿维度而探索
📌 本章带走的六件事
- 数仓四特征：集成、面向主题、反映历史变化、相对稳定——Inmon 定义默写级
- OLTP 管事务、OLAP 管分析：目标相反，必须分家（性能与数据双理由）
- 多维模型：维是角度、事实是事件、度量是数值；方体共 2ⁿ 个
- 建模先星型：事实表窄而深、维表宽而浅；多主题共享维走星座，守一致性维度
- OLAP 五操作：上卷下钻沿分层、切片单值、切块多选、转轴换视角；外加钻过钻透
- 落地三件套：三层架构、ETL 搬运与清洗、元数据管口径；部署在总仓/集市/虚拟间选
✍️ 课后思考
- 习题 4：三维方体总数为什么是 8？把 8 个方体逐个写出维度组合
- 习题 7：给切片与切块各写一个三维销售立方体的查询条件
- 习题 10：给你们学校或一家快递企业设计运输绩效模型，度量至少含一个半可加的
下一章预告：第 9 章 数据挖掘 —— 仓库备好了粮，接下来学怎么从粮里酿出规律。