大数据架构
论文/案例近年高频出题点,必背:Lambda、Kappa、5V、Hadoop 生态
一、大数据"5V" 特征 ⭐⭐⭐
Volume大量(数据量大,PB 级)
Velocity高速(产生与处理速度快,实时)
Variety多样(结构化/半结构化/非结构化)
Veracity真实性(数据质量、准确度)
Value价值(密度低,需深挖)
口诀:"量 · 速 · 杂 · 准 · 值" 5V
二、Lambda 架构 ⭐⭐⭐
┌── 批处理层 (Batch Layer) ──→ 离线视图
数据源 ──┤
└── 速度层 (Speed Layer) ────→ 实时视图
↓
[服务层] 合并 → 对外查询
三层结构
- 批处理层:全量数据 + 高准确度;Hadoop MapReduce / Spark Batch
- 速度层:增量数据 + 低延迟;Storm / Spark Streaming / Flink
- 服务层:合并批 + 速度结果对外提供查询
优点
- 同时满足实时与精确
- 容错性强(批层修正速度层错误)
- 架构成熟、组件可选丰富
缺点
- 系统复杂,两套代码维护
- 开发难度高、运维成本高
- 批与流的语义可能不一致
三、Kappa 架构 ⭐⭐⭐
数据源 ─→ [消息队列(Kafka)] ─→ 流处理引擎 (Flink) ─→ 视图层 / 数据库
核心思想
只保留流处理,所有数据 ── 包括历史回放 ── 都走流式处理。需要重算时,从 Kafka 重新消费历史数据即可。
优点
- 只有一套代码,架构简单
- 语义一致
- 实时性好
缺点
- 历史数据存储成本高
- 重算依赖 Kafka 容量
- 对流引擎要求高
Lambda vs Kappa 一句话区别
Lambda 批 + 流双路;Kappa 只流单路,以流代批。
四、Hadoop 生态(必识)
| 组件 | 作用 |
|---|---|
| HDFS | 分布式文件系统(存储) |
| YARN | 资源调度 |
| MapReduce | 批处理计算模型 |
| HBase | 列式 NoSQL,基于 HDFS |
| Hive | SQL on Hadoop(数据仓库) |
| Pig | 脚本语言数据处理 |
| Sqoop | RDBMS ↔ HDFS 同步 |
| Flume | 日志采集 |
| Kafka | 消息队列、日志总线 |
| Spark | 内存计算 + 批/流/ML/图 |
| Flink | 真正的流处理引擎 |
| ZooKeeper | 分布式协调 |
五、数据湖 vs 数据仓库
| 对比 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据类型 | 结构化为主 | 结构/半/非结构化全收 |
| 处理时机 | 写时建模 Schema-on-write | 读时建模 Schema-on-read |
| 使用者 | 分析师、BI | 数据科学家、ML |
| 典型 | Hive、Greenplum、Snowflake | HDFS、对象存储(S3)、Iceberg |
六、数据中台 / 湖仓一体
- 数据中台:统一沉淀企业数据资产,服务业务前台(标签、指标、API)
- 湖仓一体 Lakehouse:在数据湖之上构建仓库能力(ACID、Schema),典型 Delta Lake / Iceberg / Hudi
七、典型考点 · 答题模板
题型:某系统既要实时报警又要离线统计,应选哪种架构?
"应选 Lambda 架构:
① 批处理层 用 Spark/Hadoop 处理全量数据,保证准确性,产出离线统计;
② 速度层 用 Flink 处理 Kafka 实时数据,毫秒级出报警;
③ 服务层 合并两路结果对外查询。
若流处理引擎成熟(Flink 状态可用、Kafka 容量足),也可改用 Kappa 架构,只维护一套流代码。"
📘 常考补充 · 大数据 完