数仓架构
→ 返回 数据库
数据仓库（Data Warehouse）是面向分析的主题化、集成化、历史性数据存储，为商业智能（BI）和决策支持提供基础。
OLTP vs OLAP
| 维度 | OLTP（在线事务处理） | OLAP（在线分析处理） |
|---|---|---|
| 场景 | 业务系统（订单、支付、用户） | 报表、分析、BI |
| 操作 | INSERT / UPDATE / DELETE | SELECT（聚合为主） |
| 数据量 | 当前数据，GB 级 | 历史数据，TB ~ PB 级 |
| 查询模式 | 按主键精确查找 | 全表扫描 + 多维聚合 |
| 并发 | 高并发写 | 低并发大查询 |
| 代表产品 | MySQL / PostgreSQL | ClickHouse / Hive / BigQuery / Snowflake |
数仓分层架构
主流企业数仓采用 4 层分层，将原始数据逐步转化为可分析的指标体系：
业务系统（MySQL / Oracle / MongoDB / 埋点日志）
│ ETL / CDC
▼
┌─────────────────────────────────────────────────┐
│ ODS（Operational Data Store，操作数据层） │
│ ← 贴源层，数据与源系统保持一致，几乎不做转换 │
│ 保留全量历史，是数仓最底层的"原始存档" │
└──────────────────────┬──────────────────────────┘
│ 清洗、统一编码、去重
▼
┌─────────────────────────────────────────────────┐
│ DWD（Data Warehouse Detail，明细数据层） │
│ ← 明细事实数据，经过规范化清洗 │
│ 业务过程建模（订单事实、行为事实） │
└──────────────────────┬──────────────────────────┘
│ 汇总、关联维表
▼
┌─────────────────────────────────────────────────┐
│ DWS（Data Warehouse Summary，汇总数据层） │
│ ← 按主题聚合的宽表（用户日活、商品销售汇总） │
│ 通常按天/周/月粒度预聚合 │
└──────────────────────┬──────────────────────────┘
│ 指标加工
▼
┌─────────────────────────────────────────────────┐
│ ADS（Application Data Store，应用数据层） │
│ ← 直接服务 BI 报表、大屏、API 的成品数据 │
│ GMV、DAU、留存率、漏斗转化等业务指标 │
└─────────────────────────────────────────────────┘
│
▼
BI 工具（Superset / Metabase / Tableau / Grafana）
维度层（DIM）
公共维度表，供各层共用（用户维、商品维、时间维、地区维）：
DIM（Dimension，公共维度层）
├── dim_user 用户维度（用户 ID、年龄、城市、注册时间）
├── dim_product 商品维度（SKU、品类、品牌、价格区间）
├── dim_date 时间维度（年、月、日、周、节假日）
└── dim_region 地区维度（省、市、区、商圈）
维度建模
Ralph Kimball 提出的维度建模是数仓设计的主流方法，以事实表 + 维表组织数据。
事实表 vs 维表
| 事实表（Fact Table） | 维表（Dimension Table） | |
|---|---|---|
| 内容 | 业务过程的度量（数量、金额、时长） | 业务实体的属性（姓名、品类、城市） |
| 行数 | 极多（亿~百亿） | 较少（万~千万） |
| 更新 | 追加为主 | 缓慢变化 |
| 示例 | 订单事实表（order_id, user_id, product_id, amount, dt） | 用户维表（user_id, name, age, city） |
星型模型（Star Schema）
dim_user
│
dim_product ──── fact_order ──── dim_date
│
dim_region
事实表居中，维表向外辐射，像星星形状。
JOIN 路径短，查询性能好，BI 工具友好。
雪花模型（Snowflake Schema）
dim_category
│
dim_product ──── fact_order ──── dim_date
│
dim_user ──── dim_city ──── dim_province
维表再规范化，减少冗余但 JOIN 更深。
适合维度层级复杂的场景，但性能通常不如星型。
星座模型（Fact Constellation）
多个事实表共享维表，适合多业务域并存的企业数仓：
dim_user ──── fact_order ──── dim_date
│
└──────── fact_browse ──── dim_date
缓慢变化维（SCD）
维度属性会随时间变化（如用户迁城市、商品改品类），需要策略决定是否保留历史：
| 类型 | 策略 | 说明 | 适用场景 |
|---|---|---|---|
| SCD Type 0 | 不变 | 属性永远不更新 | 出生日期、注册时间 |
| SCD Type 1 | 覆写 | 直接更新，不保留历史 | 手机号、邮箱（当前值够用） |
| SCD Type 2 | 新增行 | 新增一行记录旧值，用 start_dt/end_dt/is_current 标记有效性 | 用户城市、商品品类（需分析历史值） |
| SCD Type 3 | 新增列 | 增加”旧值”列保留上一次值 | 只需对比当前与上一次状态 |
SCD Type 2 示例：
-- 用户维表（SCD Type 2）
user_id | name | city | start_dt | end_dt | is_current
----------------------------------------------------------------------
1001 | Alice | 北京 | 2020-01-01 | 2023-06-30 | 0
1001 | Alice | 上海 | 2023-07-01 | 9999-12-31 | 1 ← 当前记录
-- 分析 2022 年 Alice 的订单时，关联 is_current=0 的北京记录ETL vs ELT 在数仓中的应用
| 方式 | 流程 | 典型场景 |
|---|---|---|
| ETL | 在中间层清洗完再入库 | 目标库计算能力弱（Hive/传统数仓），Kettle/DataX 转换 |
| ELT | 先入 ODS，在 DWD/DWS 用 SQL 转换 | 目标库计算强（ClickHouse/Snowflake/BigQuery），dbt/Spark SQL |
现代云数仓趋势是 ELT：数据直接落 ODS，用 SQL（dbt）在仓库内完成 DWD→DWS→ADS 的层间转换。
数据分层调度
各层数据通常按计划窗口加工，形成 DAG 依赖链：
每日凌晨 00:30（源系统跑完）
↓
ODS 加载（DataX / Flink CDC 全量/增量）约 01:00
↓
DWD 加工（SQL 清洗、关联）约 02:00
↓
DWS 汇总（按主题聚合）约 03:00
↓
ADS 指标（业务指标计算）约 04:00
↓
报表刷新（06:00 运营上班看数据）
调度工具：Airflow / DolphinScheduler / XXL-Job
Lambda vs Kappa 架构
| 架构 | 组成 | 说明 |
|---|---|---|
| Lambda | 批处理层（T+1）+ 速度层（实时）+ 服务层 | 历史数据用批，最近数据用流，合并对外服务；维护两套代码复杂 |
| Kappa | 只有流处理层 | 所有数据都走实时流（Flink），历史数据重放流 |
| 湖仓一体（Lakehouse） | 数据湖 + 数仓特性（ACID、索引） | Delta Lake / Iceberg / Hudi，流批统一，开放格式 |
主流数仓产品
| 产品 | 类型 | 特点 |
|---|---|---|
| ClickHouse | 本地部署 OLAP | 列式存储，亿级查询秒级响应，见 ClickHouse |
| Apache Hive | Hadoop 生态 | SQL on HDFS，稳定但慢，适合海量离线 |
| Apache Doris / StarRocks | 实时 OLAP | MPP 架构，支持实时写入和秒级查询 |
| Snowflake | 云数仓（SaaS） | 存算分离，按用量计费，无运维 |
| BigQuery | Google 云数仓 | Serverless，超大规模，按扫描量计费 |
| Delta Lake / Iceberg | 湖仓一体 | 在 S3/HDFS 上加 ACID 事务，开放格式 |
数据集市（Data Mart）
数据集市是数仓的子集，面向特定业务域或部门：
企业数仓
├── 销售数据集市（Sales Mart）
│ └── 面向销售团队，只含订单/商机/业绩数据
├── 用户行为数据集市
│ └── 面向产品团队，用户注册/活跃/留存
└── 财务数据集市
└── 面向财务，收入/成本/利润
典型数仓建设流程
1. 需求调研
├── 收集分析需求（报表、指标、维度）
└── 确认数据来源和质量
2. 数据调研
├── 梳理源系统表结构
└── 评估数据量、质量、更新频率
3. 主题域划分（交易域、用户域、商品域、日志域）
4. 维度建模
├── 定义事实表（业务过程）
├── 定义维表（业务实体）
└── 选择星型/雪花模型
5. ETL/ELT 开发
├── ODS 接入（全量 + 增量）
├── DWD 明细加工（数据清洗、关联维表）
├── DWS 汇总（聚合公共指标）
└── ADS 应用层（业务指标）
6. 调度配置（DAG 依赖）
7. 数据质量监控（行数、空值率、异常值告警）
8. BI 接入（Superset / Metabase）
相关
- 数据传输 — ETL 工具、DataX、全量+增量迁移流程
- CDC — 实时增量捕获，ODS 层实时更新
- ClickHouse — 典型 OLAP 数仓存储引擎
- Flink — 实时数仓流处理引擎
- Kettle — 可视化 ETL 工具，适合 ODS→DWD 层离线加工
- Spring Batch — Java 批处理框架，可用于数仓 ETL 作业