一、数据仓库建模模型

1. 星型模型 (Star Schema)

   • 结构：1个事实表 + N个维度表（直接连接）
   • 特点：维度表非规范化（含冗余字段），查询高效
   • 示例：销售事实表 + 产品/时间/门店维度表

2. 雪花模型 (Snowflake Schema)

   • 结构：维度表进一步拆分为子维度表（层级化）
   • 特点：维度表规范化（减少冗余），存储节省但查询复杂
   • 示例：产品维度表 → 拆分为产品类目表、供应商表

3. 星座模型 (Galaxy Schema/Fact Constellation)

   • 结构：多个事实表共享维度表
   • 特点：支持跨业务分析（如销售与库存联合分析）
   • 示例：销售事实表 + 库存事实表 → 共享时间/产品维度表

---

二、数据处理架构

对比项	OLTP (Online Transaction Processing)	OLAP (Online Analytical Processing)
目标	实时事务处理（增删改查）	复杂数据分析（聚合、统计）
数据量	高频率小数据量	低频大批量数据
数据库设计	规范化（3NF）	星型/雪花模型
典型场景	电商下单、银行转账	销售报表、用户行为分析
代表系统	MySQL, PostgreSQL	Hive, ClickHouse, Snowflake

---

三、流批处理架构演进

1. Lambda 架构

   • 分层：批处理层（全量准确）+ 速度层（实时近似）+ 服务层（合并结果）
   • 痛点：代码维护双份，数据一致性难保障

2. Kappa 架构

   • 核心：仅用流处理，通过消息队列（如Kafka）存储历史数据
   • 流程：实时流处理 + 重播历史数据生成批视图
   • 优势：一套代码维护，简化架构

---

理解流批处理架构演进的关键在于抓住一个核心矛盾：如何同时满足大数据处理的准确性（批处理）和实时性（流处理）？下面用最直白的语言和场景帮你拆解：

---

为什么需要流批融合？

• 批处理（如Hive）：今天凌晨计算昨天的销售总额 → 结果准确但延迟高
• 流处理（如Flink）：实时计算此刻的销售金额 → 结果及时但可能不精确（如网络延迟导致漏数据）
  👉 业务既要看实时大盘又要对账准确报表 → 催生了混合架构

---

1. Lambda 架构（双引擎护航）

graph TD
A[新数据] --> B1[Kafka消息队列]
B1 --> C1[批处理层：Hadoop/Hive] 
B1 --> C2[速度层：Flink/Storm]
C1 --> D[批处理视图：HBase]
C2 --> E[实时视图：Redis]
D & E --> F[服务层：合并结果给用户]

• 核心思想：用两条独立流水线分别处理
  • 批处理层：夜间跑全量数据 → 生成100%准确的结果（比如昨日最终销售额）
  • 速度层：实时处理最新数据 → 生成近似结果（比如当前分钟销售额）
• 痛点：
  • ❌ 同一套业务逻辑要写两遍代码（批处理+流处理）
  • ❌ 凌晨批处理覆盖实时结果时，用户可能看到数据跳变

场景类比：
你同时用计算器（批处理）和心算（流处理）做同一道数学题，最后把两个结果拼在一起报告老师。

---

2. Kappa 架构（流处理一统江湖）

graph LR
A[新数据] --> B[Kafka（存储历史+实时数据）]
B --> C[流处理引擎：Flink]
C --> D{需要历史数据？}
D -->|是| E[重播旧数据生成新视图]
D -->|否| F[直接输出实时结果]

• 核心思想：所有数据都当流处理
  • 用Kafka等消息队列永久保存原始数据（相当于存储了历史库）
  • 需要修正历史结果时，重播数据流重新计算（如：发现昨天漏了100条数据，就从Kafka重新拉取昨天的数据再算一次）
• 优势：
  • ✅ 只需维护一套流处理代码
  • ✅ 避免批流结果不一致

场景类比：
全程用录音笔（Kafka）记录老师讲题过程。如果发现某处算错了，就倒带重听那段录音（重播数据流）重新计算。

---

关键概念对照表

概念	Lambda架构	Kappa架构	解决什么问题
数据存储	批存HDFS，流存Kafka	全量存Kafka	历史数据可回溯
计算逻辑	批+流两套代码	仅流处理一套代码	开发维护成本高
数据一致性	难保证	通过重播保证	凌晨报表跳变
适用场景	早期大数据系统	云原生实时数仓	实时风控/监控大屏

---

实际案例理解

• Lambda架构（电商双十一）

  • 实时大屏：Flink每秒更新成交额（可能少算了未支付订单）
  • 次日清晨：Hive跑出精确成交额（覆盖实时大屏结果）
  • ⚠️ 问题：凌晨0:05管理员看到销售额突然从120亿→119亿

• Kappa架构（银行风控）

  • 实时流：Flink检测当前转账是否欺诈
  • 发现规则漏洞：重播过去7天数据，重新计算风险评分
  • ✅ 过程：无需停服，动态修正历史结果

---

演进趋势

1. 批流一体引擎兴起（如Flink、Spark Structured Streaming）
   → 同一段代码可切换批/流执行模式
2. 存储层升级（如Kafka长期存储 + 云对象存储）
   → 支持低成本保存全量历史数据

简单来说：Kappa是Lambda的简化升级版，用“数据重播”技术干掉冗余的批处理层。但注意：重播大量历史数据需要高性能流引擎，否则可能把系统压垮！

四、数据存储体系

概念	数据仓库 (Data Warehouse)	数据湖 (Data Lake)
数据状态	清洗后的结构化数据	原始多态数据（文本/图片/日志等）
Schema	写入前定义（Schema-on-Write）	使用时定义（Schema-on-Read）
用户	数据分析师	数据科学家/工程师
代表技术	Redshift, BigQuery	Hadoop HDFS, Delta Lake

✅ 现代趋势：湖仓一体 (Lakehouse)
融合数据湖的低成本存储与数据仓库的管理能力（如Databricks、Iceberg）。

---

五、ETL 核心流程

• Extract：从业务系统（ERP/CRM）抽取原始数据
• Transform：清洗脏数据、转换格式、关联维度
• Load：写入目标库（数据仓库/数据湖）

现代变体：ELT（先加载原始数据到湖仓，再转换）

---

六、应用场景对标

模型/架构	适用场景	案例
星型模型	快速查询的报表系统	电商每日销售大盘
雪花模型	需要节省存储的规范化场景	金融合规审计
Kappa架构	实时风控或监控	银行反欺诈系统
数据湖	机器学习原始数据存储	用户行为日志分析