【数据治理】数据仓库
一、基础概念
1.定义
数据仓库是一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。
- 面向主题：主题简单来说就是与业务相关的数据的类别，每个主题对应一个宏观的分析领域。（例如，一个公司需要分析销售数据，建立一个专注于销售的数据仓库，使用这个数据仓库，可以会打类似于”去年谁是我们这款产品的最佳用户“这样的问题。)
- 集成：假设公司有多条产品线和多种产品销售渠道，而每个产品线都有自己独立的销售数据库。此时从公司层面分析销售数据，必须将多个分散的数据源统一成一致的、无歧义的数据格式后，再放置到数据仓库中。当完成数据整合工作后，该数据仓库就可成为是集成的。
- 非易失：数据写入后一般不删除、不修改，主要做追加
- 随时间变化：持续不断新增历史数据，可以分析不同时间段情况
随时间变化的特性表明数据仓库是
2.一些术语
- 全量表：每日同步该实体所有数据，覆盖昨日全部记录（适合客户、商品等基础信息）
- 增量表：只同步当天新增 / 变更的数据（适合流水日志）
- 快照表：每日保存一份完整数据快照，可以查询任意一天的历史状态
- 分区（Hive 常用，dt = 日期）
数据按日期分区存放；治理常见问题：分区缺失、分区为空、分区数据延迟 - 数据粒度：数据细化程度
例：明细粒度（每一条订单）；汇总粒度（用户每日总订单） - 宽表：把多张表字段合并到一张大表，减少多表 JOIN
3.OLTP vs OLAP
| 类型 | 全称 | 代表系统 | 用途 | 特点 |
|---|---|---|---|---|
| OLTP | 联机事务处理 | MySQL、Oracle 业务库 | 日常业务操作（下单、注册） | 增删改频繁，面向单笔交易，数据量较小 |
| OLAP | 联机分析处理 | Hive、ClickHouse、数仓 | 统计分析、报表、指标计算 | 几乎不修改历史数据，大量查询，用于决策分析 |
二、标准数仓分层
1. ODS 原始数据层
- 数据：原样同步业务库，几乎不做清洗，结构和源库保持一致
- 数据形态：增量 / 全量同步日志
- 治理关注点：数据同步及时性、数据生命周期、原始数据备份、脏数据源头留存
特点：不修改数据，保留业务系统原貌，方便追溯源头问题
数据同步工具：Flink CDC
2. DWD 明细数据层（数据清洗层）
- 数据：ODS 数据清洗后的最细粒度明细，不聚合
- 处理动作：过滤无效数据、统一编码、脱敏、剔除重复垃圾数据
- 治理关注点：基础数据质量、字段标准落地、统一代码字典
使用专门的**ETL（Extract→Transform→Load）**工具。
Extract抽取方式：全量抽取、增量抽取、CDC 变更捕获。Transform：清洗、标准化、字段衍生、维度补全、格式转换。**Load 😗*将处理完成的干净数据写入目标（Hive、数据库、数据仓库）
ETL VS ELT:
| ETL | ELT | |
|---|---|---|
| 流程 | 抽取 → 转换 → 加载 | 抽取 → 加载 → 转换 |
| 转换时机 | 入库之前清洗 | 原始数据先入库（ODS），入库后再清洗 |
| 典型架构 | 传统小型数据库数仓 | Hive/Spark 大数据数仓（企业主流） |
| 和分层对应 | 不适合标准五层数仓 | ODS（原始入库）→ SQL 加工得到 DWD |
3. DIM 维度层
存放维度表：描述业务实体属性（用户、门店、产品、组织、地区）
关键知识点：缓慢变化维 SCD
- SCD1：直接覆盖旧数据（不保存历史）
- SCD2：新增一条记录，保留历史快照（最常用，可追踪历史属性）
- SCD3：增加拓展字段保存少量历史
治理关注点：维度一致性、主数据对齐、编码统一
4. DWS 汇总层（宽表层）
按照维度提前聚合汇总，形成宽表。例：每日用户汇总、每日商品订单汇总粒度高于明细，减少报表重复计算
治理关注点：指标口径统一、消灭重复指标、冗余字段梳理
5. DM 数据集市 / 应用层
面向部门业务、报表、大屏、分析取数，按需组装数据
治理关注点：数据资产盘点、对外数据权限管控、报表血缘梳理
简易数据流链路（梳理血缘标准路径）
业务数据库 → ODS → DWD → DWS/DIM → DM → 报表 / 可视化
三、维度建模
1. 两大核心表
① 事实表（DWD/DWS）
记录业务发生的事件、度量值。
特点：每条记录代表一次业务事件（下单、支付、退款、浏览）；外键关联各个维度表ID；包含度量指标（金额、数量、时长），可以求和；数量远大于维度表。
核心字段：维度外键 + 度量指标（金额、数量）
粒度：一条记录代表一件什么事（非常重要，指标统计失真大多是粒度混乱）
| order_id (明细主键) | user_id (维度外键) | goods_id (维度外键) | order_time | buy_num (度量) | amount (度量) | pay_status |
|---|---|---|---|---|---|---|
| OD20260711001 | 10001 | G001 | 2026-07-11 08:20 | 1 | 399.00 | 已支付 |
| OD20260711002 | 10002 | G002 | 2026-07-11 09:15 | 2 | 168.00 | 未支付 |
② 维度表（DIM层存放）
描述实体属性信息，用来过滤、分组统计。例子：用户表、商品表、区域表
| user_id (主键) | user_name | gender | phone | region | register_date | user_level |
|---|---|---|---|---|---|---|
| 10001 | 张三 | 男 | 131****1111 | 新疆 | 2025-01-05 | VIP |
| 10002 | 李四 | 女 | 132****2222 | 上海 | 2025-02-10 | 普通 |
2. 两种模型
1.星型模型
事实表居中，直接关联所有维度表；查询简单，数仓最常用
dim_user（用户维度） ↑ dim_goods ← dwd_order_detail → dim_shop （商品维度） 【事实表】 （门店维度）2.雪花模型
维度表继续拆分子维度；冗余低，但关联层级多、查询性能差
dim_region(省市维度) ↑ dim_user(用户维度) ↑ dim_goods ← dwd_order_detail → dim_shop四、数仓常见数据问题
- 源头多系统同含义字段命名不一致（客户 ID /cust_id/user_no）→【数据标准治理】
- 同一指标多处口径不一样（营收是否包含退款）→【指标标准治理】
- 维度编码不统一（性别 1/0、男 / 女混用）→【数据质量 + 数据元】
- 明细表重复数据、空值过多 →【数据质量规则】
- 一张报表来源多层表，没人知道计算逻辑 →【元数据、数据血缘】