一、传统数据处理系统存在的问题
-
数据库性能瓶颈
- 应用直接访问数据库，用户量激增时数据库负载过高，导致响应超时（如奥运高并发场景）。
- 临时方案：引入异步队列缓冲（如消息队列），但仅缓解写入压力，未根治性能问题。
-
分库分表的复杂性
- 通过Hash分区横向扩展数据库，但扩容时需Resharding（重分区），涉及数据迁移、客户端路由更新，运维成本高且易出错。
-
架构臃肿与维护困难
- 为提升性能叠加队列、读写分离（Master-Slave）、复制等组件，系统复杂度飙升。
- 应用需感知数据库Schema和分区逻辑，耦合度高。
-
缺乏容错设计
- 依赖备份恢复，未从架构层面预防人为错误（如误删数据），故障恢复效率低。
核心矛盾：传统架构通过"打补丁"方式优化，无法应对大数据量、高并发、实时性要求，催生新架构需求。
二、大数据处理系统架构分析
1 面临挑战
-
非结构化数据处理
- 85%数据为非结构化（社交网络、日志等），需跨学科（数学、CS、经济学）研究其表示与转换方法。
- 关键问题：如何将图像等半结构化数据转换为多维表或对象模型？
-
数据价值挖掘层级
- 一次挖掘：提取粗糙知识（潜在模式）。
- 二次挖掘：结合主观知识（经验、用户偏好）生成智能知识，实现数据到价值的质变。
-
数据不确定性
- 高维、强随机性数据（如股票流）需动态处理框架。
2 架构特征
Nathan Marz提出大数据系统8大特性（Storm之父）：
| 特性 | 说明 |
|---|---|
| 鲁棒性与容错性 | 应对机器宕机与人为错误（如Bug写入错误数据），支持快速恢复。 |
| 低延迟读写 | 毫秒级响应，满足实时分析需求（如金融交易）。 |
| 横向扩容（Scale-out） | 通过增加机器而非升级单机性能扩展系统。 |
| 通用性 | 支持金融、电商、社交等多领域应用。 |
| 延展性 | 可灵活添加新功能，支持系统迁移。 |
| 即席查询 | 允许用户按需自定义查询，提升数据价值。 |
| 最少维护 | 简化组件设计降低运维复杂度（如避免增量更新）。 |
| 可调试性 | 所有数据值可追溯来源与计算过程。 |
三、Lambda架构：批流融合的经典方案
三层核心结构
新数据 批处理层 速度层 批处理视图 实时视图 服务层合并结果
-
批处理层（Batch Layer）
- 技术栈：Hadoop + Spark
- 任务 ：全量计算历史数据，生成Batch View（高准确度但高延迟）。
-
速度层（Speed Layer）
- 技术栈：Storm/Spark Streaming
- 任务 ：处理增量数据，生成Real-time View（低延迟但可能临时性）。
-
服务层（Serving Layer）
- 技术栈：HBase + Redis
- 任务：合并批处理与实时视图，提供统一查询接口。
优缺点分析
- 优点：历史数据处理能力强（PB级），实时性与准确性平衡。
- 缺点 ：
- 维护两套系统（批处理+流处理），开发与运维成本高。
- 需保证两套代码输出结果一致性。
典型应用
某网奥运大数据平台：
- 实时层：Spark Streaming计算直播在线人数（秒级响应）。
- 批处理层：HBase存储历史赛事数据，支持回溯分析。
- 服务层：合并当日概览与赛事回顾模块。
四、Kappa架构：流处理优先的简化方案
核心思想
- 单一流处理引擎：用Flink/Kafka替代Lambda的双系统。
- 数据不可变性与重放 ：
需修正时 数据源 Kafka消息队列 流处理引擎 输出结果 数据以事件流形式持久化存储，错误修复时重新消费全量数据计算。
优缺点对比Lambda
| 维度 | Lambda架构 | Kappa架构 |
|---|---|---|
| 复杂度 | 高（两套系统+两套代码） | 低（单一流处理引擎） |
| 历史数据处理能力 | 强（批处理吞吐量大） | 弱（依赖消息队列回溯性能） |
| 计算开销 | 高（批流并行运行） | 低（仅需流处理） |
| 适用场景 | 需频繁分析海量历史数据 | 实时流为主，小规模历史数据 |
架构变形
-
Kappa+架构（Uber）
- 流引擎直接读HDFS数据仓库，避免Kafka存储历史数据压力。
- 使用Apache Hudi支持数据更新与增量消费。
-
混合分析架构
- Kafka + Flink流处理 + Elasticsearch实时分析，弥补批处理能力不足（折中方案）。
五、Lambda vs Kappa架构设计选择
| 考虑因素 | 选择Lambda | 选择Kappa |
|---|---|---|
| 业务需求 | 强依赖Hadoop/Spark批处理 | 偏好Flink流计算 |
| 算法迭代频率 | 需频繁修改两套代码 | 单代码维护，快速迭代 |
| 历史数据规模 | PB级数据分析（如十年气象数据） | 实时流为主，历史数据量小 |
| 开发资源 | 团队资源充足（经济/技术） | 成本敏感型项目 |
典型案例：某网奥运平台选Lambda（需兼顾实时观看数据与十年赛事分析）；广告点击流分析可选Kappa（实时性强，历史数据少）。
附：高频考点与典型考题
-
考题 ：Lambda架构中如何解决实时视图与批处理视图的合并？
答 ：通过满足幺半群性质的View模型（如求和、最大值），确保合并结果数学一致。 -
考题 ：Kappa架构如何修正计算结果错误？
答 ：重新启动流计算实例，从消息队列重放全量数据生成新结果覆盖旧值。 -
考题 ：大数据系统为何要求"数据不可变"？
答 ：避免人为错误覆盖原始数据，通过重新计算修复错误（如遍历丢弃错误数据后重算）。 -
架构设计题 ：设计某电商大促实时大屏系统，需支持秒级销量更新与历史同比分析。
推荐方案：Lambda架构（实时层Spark Streaming处理秒级数据；批处理层预计算历史趋势）。