[案例分析]#8. 大数据架构设计

大数据处理系统架构分析

一、大数据带来的三大挑战

1. 非结构化/半结构化数据处理挑战

挑战描述：如何利用信息技术等手段处理非结构化和半结构化数据

解析与举例：

• 非结构化数据：如图片、视频、音频、社交媒体帖子等
• 半结构化数据：如 JSON、XML 文档、日志文件等
• 实际案例：某电商平台需要分析用户评论（文本）和产品图片，传统关系型数据库难以有效处理

2. 复杂性与不确定性建模挑战

挑战描述：如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模

解析与举例：

• 复杂性体现：数据维度高、规模大、变化快
• 不确定性：数据质量参差不齐，存在噪声和缺失值
• 举例：金融风控系统中，需要建立能够处理海量交易数据且能适应新型欺诈模式的智能模型

3. 异构性对决策的影响挑战

挑战描述：数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

解析与举例：

• 数据异构性：数据来源多样、格式不一（如传感器数据、业务数据、外部数据）

• 决策异构性：不同部门基于同一数据可能得出不同决策结论

• 案例：制造业企业需要整合生产线传感器数据、供应链数据和市场数据，支撑智能化决策

  graph TD A[大数据三大挑战] --> B[非结构化数据处理] A --> C[复杂性建模] A --> D[异构性影响] B --> B1[文本/图像/视频处理] B --> B2[多格式数据整合] C --> C1[高维度数据分析] C --> C2[不确定性建模] D --> D1[多源数据融合] D --> D2[统一决策支持]

二、大数据处理系统架构特征

1. 鲁棒性和容错性

特征描述：可靠性，出错恢复

解析与举例：

• 技术实现：HDFS 的副本机制（默认 3 副本）
• 案例：某银行系统在单个节点故障时仍能正常提供服务

2. 低延迟读取和更新能力

特征描述：数据量庞大而延迟高

解析与举例：

• 挑战：PB 级数据下实现秒级响应
• 解决方案：内存计算（Spark）、缓存技术（Redis）
• 案例：实时推荐系统需要在 100ms 内返回个性化推荐结果

3. 横向扩容

特征描述：通过增加节点扩展系统能力

解析与举例：

• 优势：线性扩展，成本可控
• 案例：双十一期间，电商平台通过快速增加计算节点应对流量峰值

4. 通用性

特征描述：支持多种数据类型和处理模式

解析与举例：

• 支持：批处理、流处理、图计算、机器学习等
• 案例：Spark 生态系统提供统一的数据处理平台

5. 延展性

特征描述：系统能力可随需求增长而扩展

解析与举例：

• 体现：计算能力、存储容量、连接数等可平滑扩展
• 案例：云服务提供商按需提供资源弹性伸缩

6. 即席查询能力

特征描述：

• 响应用户查询需求
• 实时展播平台

解析与举例：

• 即席查询：用户可随意组合查询条件，无需预定义查询路径
• 案例：业务人员通过拖拽方式自主分析销售数据，实时生成报表

7. 最少维护能力

特征描述：少维护，架构设计好

解析与举例：

• 设计原则：自动化运维、自愈能力、监控告警
• 案例：Kubernetes 实现的自动扩缩容和故障自恢复

8. 可调试性

特征描述：提供完善的调试和监控能力

解析与举例：

• 工具支持：日志系统、性能监控、链路追踪
• 案例：通过 ELK 栈实现分布式系统的问题定位和性能分析

三、Lambda 架构

1. 架构设计目标

核心目标：提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等

设计原则：

• 整合离线计算与实时计算
• 融合不可变性、读写分离和复杂性隔离原则
• 同时处理离线和实时数据的可容错、可扩展分布式系统
• 具备强鲁棒性，提供低延迟和持续更新

关键特性：既包含离线计算又包含实时计算

2. 应用场景

• 机器学习：模型训练（离线）+ 实时预测（在线）
• 物联网：历史数据分析 + 实时设备监控
• 流处理：实时数据处理 + 批量数据回溯

3. 三层架构详解

3.1 批处理层（Batch Layer）

功能描述：处理离线数据（历史数据，本地的数据）

技术特点：

• 使用 MapReduce 进行大量数据处理
• 处理产生批处理结果视图
• 结果认为是精准且全量的数据处理
• 时延很高（通常小时级或天级）

详细解析：

批处理层负责处理全体历史数据，通过批量计算生成准确的数据视图。由于处理的是完整数据集，结果具有高准确性，但延迟较大。

举例：电商平台每日凌晨计算前一日所有用户的购物车数据，生成商品推荐模型

3.2 加速层/实时层（Speed Layer）

功能描述：处理实时数据，实时计算

技术特点：

• 只处理最近产生的实时数据
• 产生流处理结果视图
• 流处理层的数据可能不是准确的，也不是全量的
• 数据处理时延很低（秒级或毫秒级）

详细解析：

实时层专注于最新数据的处理，通过流计算技术实现低延迟响应。虽然可能牺牲部分准确性，但能满足实时性要求。

举例：实时监控系统检测用户当前浏览行为，即时调整推荐结果

3.3 服务层（Serving Layer）

功能描述：整合批处理与实时处理结果

功能详解：

• 用于合并 Batch View 和 Real-time View 中的结果数据集到最终数据集
• 用于响应用户的查询请求
• 提供统一的数据访问接口

4. 技术实现方案

4.1 Hadoop HDFS

技术描述：被设计成适合运行在通用硬件上的分布式文件系统

特性分析：

• HDFS 是一个具有高度容错性的系统能提供高吞吐量的数据访问
• 非常适合大规模数据集上的应用
• HDFS 放宽了一些约束，以达到流式读取文件系统数据的目的

实际应用：作为批处理层的数据存储基础

4.2 Apache Spark

技术描述：专为大规模数据处理而设计的快速通用的计算引擎

核心优势：

• Spark 中间输出结果可以保存在内存中，从而不再需要读写 HDFS
• 能更好地适用于数据挖掘与机器学习等需要迭代的 MapReduce 算法

应用场景：既可用于批处理层的批量计算，也可用于实时层的流处理

4.3 HBase

技术描述：Hadoop Database，高可靠性、高性能、面向列、可伸缩的分布式存储系统

特点：

• 利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群
• 适合作为服务层的数据存储

5. 优缺点分析

优点：

• 容错性好：通过数据副本和重算机制保证系统可靠性
• 查询灵活度高：支持历史数据查询和实时数据查询
• 易伸缩：水平扩展能力强
• 易扩展：组件化设计，便于功能扩展

缺点：

• 全场景覆盖带来的编码开销：需要维护两套处理逻辑
• 针对具体场景重新离线训练一遍益处不大：模型更新成本高
• 重新部署和迁移成本很高：系统复杂，迁移困难

6. 系统对比

6.1 事件溯源（Event Sourcing）与 Lambda 架构

事件溯源核心观点：

1. 整个系统以事件为驱动，所有业务都由事件驱动来完成
2. 事件是核心，系统的数据以事件为基础，事件要保存在某种存储上
3. 业务数据只是一些由事件产生的视图，不一定要保存到数据库中

与 Lambda 架构关系：

• Lambda 架构中数据集的存储使用的概念与 Event Sourcing 中的思想完全一致
• 二者都是在使用统一的数据模型对数据处理事件本身进行定义
• 发生错误时能够通过模型找到原因，重新计算以恢复系统状态
• 以此实现系统的容错性

实际案例：银行交易系统，每笔交易作为事件存储，支持事中审计和事后回溯

6.2 CQRS 与 Lambda 架构

CQRS 架构特点：

• 分离对于数据进行的读操作（查询）和写（修改）操作
• 将能够改变数据模型状态的命令和对于模型状态的查询操作实现分离
• 是领域驱动设计的架构模式，主要用来解决数据库报表的输出处理方式

与 Lambda 架构关系：

• Lambda 架构中，数据的修改通过批处理和流处理实现
• 通过写操作将数据转换成查询时所对应的 View
• 查询时直接读取 View 得到结果，实现形式的读写分离

应用价值：提升系统性能，优化读写负载

四、Kappa 架构

1. 架构原理

核心思想：在 Lambda 的基础上进行优化，删除 Batch Layer 的架构，将数据通道以消息队列进行替代

工作流程：

• 依旧以流处理为主，数据在数据湖层面进行存储
• 需要进行离线分析或再次计算时，将数据湖的数据再次经过消息队列重播
• 输入数据直接由实时层的实时数据处理引擎处理
• 服务层提供上层业务查询
• 中间结果数据统一存储在存储介质中

批处理实现：将数据库里面存的所有数据，重新塞回消息队列重新进行计算

2. 与 Lambda 架构的区别

主要区别：

1. 架构定位：Kappa 不是 Lambda 的替代架构，而是其简化版本
2. 批处理支持：Kappa 放弃对批处理的支持，更擅长增量数据写入场景
3. 历史数据处理：Lambda 直接支持批处理，更适合历史数据分析查询场景

适用场景对比：

• Kappa：实时性要求高，数据以增量为主的场景
• Lambda：需要强一致性历史数据查询的场景

3. 优缺点分析

优点：

• 代码统一：将实时和离线代码统一起来，方便维护
• 数据口径统一：避免了 Lambda 架构中离线数据合并的问题
• 历史查询简便：查询历史数据时只需重放存储的历史数据

缺点：

3.1 消息中间件性能问题

问题描述：消息中间件缓存的数据量和回溯数据有性能瓶颈

具体挑战：

• 算法需要过去 180 天的数据时，存储压力巨大
• 一次性回溯订正 180 天级别数据，资源消耗非常大

解决方案举例：采用分层存储，热数据放在消息队列，冷数据归档到对象存储

3.2 实时流关联问题

问题描述：不同的实时流关联，依赖计算能力

具体挑战：

• 大量不同实时流进行关联时，依赖实时计算系统能力
• 可能因数据流先后顺序问题，导致数据丢失

解决方案：使用事件时间处理和水印机制保证数据完整性

3.3 离线计算稳定性

问题描述：Kappa 抛弃离线数据处理模块时，同时抛弃了离线计算的稳定性

对比分析：

• Lambda：保证离线计算稳定性，但双系统维护成本高
• Kappa：单系统维护，但需要保证流处理的准确性

4. 衍生架构

4.1 Kappa+ 架构

核心思想：让流计算框架直接读 HDFS 里的数据仓库数据，一并实现实时计算和历史数据回溯计算

技术特点：

• 不需要为回溯作业长期保存日志或把数据拷贝回消息队列
• 开发 Apache Hudi 框架来存储数据仓库数据
• Hudi 支持更新、删除已有 parquet 数据，支持增量消费数据更新部分

数据流程：

数据源 → Kafka → Hadoop(Hudi) → Spark → 查询接口
    ↓
日志数据、键值数据、关系数据统一接入

4.2 混合分析系统的 Kappa 架构

产生背景：Lambda 和 Kappa 架构都存在展示层的困难点，结果视图如何支持热点数据查询分析

解决方案：在 Kappa 基础上衍生数据分析流程

技术实现：

• 使用 Kafka + Flink 构建 Kappa 流计算数据架构
• 利用 Kafka 对接组合 Elasticsearch 实时分析引擎
• 部分弥补 Kappa 架构分析能力不足的问题

局限性：

• Elasticsearch 只适合合理数据量级的热点数据索引
• 无法覆盖所有批处理相关的分析需求
• 属于 Kappa 和 Lambda 间的折中方案

五、Lambda 架构与 Kappa 架构的对比和设计选择

1. 选择考虑因素

主要因素：

• 业务需求
• 技术要求
• 系统复杂度
• 开发维护成本
• 历史数据处理能力

次要因素：计算开销（相差不大，不作为主要考虑因素）

2. 详细选择标准

2.1 业务需求与技术要求

• 选择 Lambda：业务对 Hadoop、Spark、Strom 等关键技术有强制性依赖
• 选择 Kappa：处理数据偏好流式计算，又依赖 Flink 计算引擎

2.2 复杂度考虑

• 选择 Kappa：需要频繁修改算法模型参数（Lambda 需修改两套代码）
• 选择 Kappa：算法模型支持同时执行批处理和流式计算
• 选择 Kappa：希望用一份代码进行数据处理

2.3 开发维护成本

• Lambda 架构：需要两套系统开发、部署、测试维护，适合有足够资源的团队
• Kappa 架构：只需要维护一套系统，适合资源有限的团队

2.4 历史数据处理能力

• 选择 Lambda：需要频繁接触海量数据集进行分析
• 选择 Kappa：始终使用小规模数据集，流处理系统完全可用

3. 架构对比总览

对比表格：

六、大数据架构设计案例分析

1. Lambda 架构在某网奥运中的大数据应用

应用场景分析

实时处理需求：采用增量计算实时数据的方式，在集群规模不变前提下，秒级分析出当日概览信息

批处理需求：赛事回顾模块需要展现历史统计数据

• 自定义时间段内的历史最高在线人数
• 逐日播放走势分析
• 直播最高在线人数统计
• 点播视频排行等海量数据统计

架构适配性分析

数据特性：奥运期间产生数据通常不需要经常索引、更新

存储要求：采用不可变方式存储所有历史数据，保证数据准确性

Lambda 优势：批处理层采用不可变存储模型不断追加新数据，满足奥运数据的大规模统计分析要求

2. Lambda 架构在某网广告平台的应用与演进

数据指标分类

曝光类指标：

• 曝光数、点击数、点击单价、花费
• 数据来源：流量方接口提供（如腾讯广点通平台）

转化类指标：

• 转化下单数、转化下单金额、转化付款数、转化付款金额
• 数据来源：某网特有数据，通过买家浏览、下单、付款日志计算

第一版架构（典型 Lambda 架构）

数据处理流程

批处理层流程：

1. 每天凌晨将 Kafka 中的浏览、下单消息同步到 HDFS
2. 将 HDFS 中的日志数据解析成 Hive 表
3. 用 Hive SQL/Spark SQL 计算分区统计结果 Hive 表
4. 最终导出到 MySQL 供服务层读取

外部数据处理：

• 曝光、点击、花费等指标通过定时任务调用第三方 API
• 每天定时写入另一张 MySQL 表

实时处理层：

• 用 Spark Streaming 程序监听 Kafka 中的下单、付款消息
• 计算每个追踪链接维度的转化数据
• 存储在 Redis 中

服务层：

• Java 服务提供 HTTP 接口
• 读取两张 MySQL 表和一个 Redis 库的数据

第一版问题分析

1. 性能瓶颈：数据处理层简单，性能瓶颈在 Java 服务层
2. 查询复杂：服务层需要关联两张 MySQL 表，查询过程复杂
3. 数据源局限：实时数据只对接内部 Kafka 消息，缺少第三方实时数据

第二版架构改进

改进措施

实时层增强：增加常驻后台 Python 脚本

• 不断调用第三方 API 的小时报表
• 更新当日曝光数据表

改进效果

1. 计算压力下降：Java 服务计算压力明显下降
2. 瓶颈转移：性能瓶颈转移到查询 Redis 数据

遗留问题分析

Redis 查询瓶颈：

• Redis 中实时数据业务无关，仅统计追踪链接维度聚合数据
• 查询流程复杂：MySQL 查询关系 → 找出跟踪链接 → 统计数据聚合

离线计算问题：

• 涉及多次 MySQL 和 Hive 间导表操作

• 离线任务依赖链较长，出错恢复时间久

  graph TD A[广告平台架构演进] --> B[第一版Lambda架构] A --> C[第二版优化架构] B --> B1[批处理层: HDFS+Hive] B --> B2[实时层: Spark Streaming] B --> B3[服务层: Java服务] B --> B4[问题: 服务层瓶颈] C --> C1[增加Python实时脚本] C --> C2[优化数据流] C --> C3[瓶颈转移至Redis] C --> C4[遗留问题: 数据关联复杂]

七、架构图与可视化说明

由于文本形式限制，此处描述各架构图应包含的关键组件和数据流方向。实际架构图应展示以下内容：

Lambda 架构图要素

1. 数据源：显示实时数据流和批量数据源
2. 批处理层：HDFS 存储、MapReduce/Spark 计算引擎
3. 加速层：流处理平台（Storm/Spark Streaming）
4. 服务层：数据库（HBase/Cassandra）、查询接口
5. 数据流向：清晰标注批处理路径和实时处理路径

Kappa 架构图要素

1. 统一数据流：所有数据通过消息队列接入
2. 流处理引擎：实时处理核心组件
3. 数据湖存储：历史数据存储体系
4. 重播机制：数据回溯处理流程
5. 服务接口：统一数据查询服务