大数据之路：阿里巴巴大数据实践——大数据领域建模综述

核心痛点
- 数据冗余：不同业务重复存储相同数据（如用户基础信息），导致存储成本激增。
- 计算资源浪费：未经聚合的明细数据直接参与计算（如全表扫描），消耗大量CPU/内存资源。
- 数据一致性缺失：同一指标在不同业务线的口径差异（如"活跃用户"定义不同），引发决策冲突。
- 开发效率低下：每次分析需重新编写复杂逻辑，无法复用已有模型。
数据建模核心价值
- 性能提升：分层设计（ODS→DWD→DWS→ADS），查询响应速度提升10~100倍。
- 成本优化：数据压缩存储（列式存储）、生命周期管理（冷热数据分层）、计算资源复用（公共层下沉）。
- 质量保障：统一指标口径（OneData体系）、血缘关系追踪（元数据管理）、数据质量卡点（非空/唯一性校验）。
- 敏捷开发：标准化模型复用（如用户维度表）、可视化开发工具（DataWorks），新业务接入效率提升70%。

关键设计对比

Alibaba架构变革

数据仓库的核心改造
- 建模方法 ：放弃严格范式约束，采用 Kimball维度建模（事实表+维度表）。
- 存储优化：列式存储（ORC/Parquet）降低I/O，压缩比达5:1。
- 计算引擎：批处理（MapReduce） + 流处理（Flink）统一架构。

OLTP vs OLAP

维度	OLTP系统	OLAP系统	对建模的影响
核心目标	高并发事务处理	复杂数据分析（用户画像/预测）	OLTP：事务效率优先；OLAP：查询性能优先
数据操作	细粒度增删改	大规模聚合查询（GROUP BY/JOIN）	OLTP需避免冗余，OLAP需预聚合
数据时效	当前状态	历史快照（T+1或实时增量）	OLAP需时间维度建模
数据量级	GB~TB级（热数据）	TB~PB级（全量历史）	OLAP依赖列存储+压缩技术
典型瓶颈	写并发、锁竞争	读I/O、计算资源	建模需针对性优化瓶颈点

OLTP系统：ER模型（实体-关系）主导
- 高度规范化（3NF）：消除冗余，依赖主键，保障事务一致性。
- 通过外键维护完整性 （如订单表 user_id 关联用户表主键）。
OLAP系统：维度建模（Kimball）主导
- 星型/雪花模型：事实表（交易行为） + 维度表（用户/商品描述）。
- 主动引入冗余：维度表反规范化，减少Join次数。
- 退化维度：将常用维度属性直接存入事实表（如商品名称）。
- 缓慢变化维（SCD）：Type 2设计追踪历史变更。

分层建模体系（解决数据膨胀）

分层设计（核心骨架）
- ODS层：近源数据保留，采用增量 + 全量混合存储（如订单表按天分区）
- DWD层：
  
  事实表：事务型、周期快照、累积快照。
  
  维度表：全局统一代理键。
- DWS层：
  
  预聚合宽表：按主题域（用户、商品）构建80+ 核心宽表。
  
  CUBE：提前计算UV、GMV等300+ 核心指标。
- ADS层：高度反规范化，为BI工具、API接口优化存储格式。
模型融合创新
- Kimball星型模型：超级宽表 + 维度退化，减少Join次数90%+。
- Data Vault审计性：元数据驱动建模，通过DataWorks自动追踪血缘关系。
- 范式理论：仅核心实体（用户/商品）保持3NF，平衡冗余与一致性。
分布式环境下的维度建模
- 全局维度中心：整合200+数据源生成统一维度，SCD Type 2采用拉链表设计，历史版本存储成本降低70%。
- 事实表分桶优化：按user_id分1000桶，使Join操作本地化计算，冷热数据分离：热数据存SSD，冷数据转OSS归档。

实时离线一体化模型