22-大数据架构设计实践

Mon, 01 Jan 2024 00:00:00 +0000

22-大数据架构设计实践（第22小时）

软考-系统架构设计师 | 第4篇架构设计实践知识出题形式：下午案例分析题（必出 25 分）+ 上午选择题 + 论文题 分值占比：约 25-30 分（重点！必出案例）

0. 考点分析

大数据 4 大特点：体量大、时效性强、类型多样、价值
传统数据处理 5 种解决方法：异步队列/分区/分片/读写分离/分库分表
Lambda 架构 3 层：批处理层 + 加速层 + 服务层
Kappa 架构 2 层：实时层 + 服务层
Lambda vs Kappa 对比：4 维度
4 大实践案例：视频网络、广告平台、证券智能决策、电商智能决策
大数据 4 个处理过程：采集、清洗、统计、挖掘

1. 核心架构知识

1.1 传统数据处理系统的问题

1.1.1 数据过载问题

传统应用数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的负载，出现超时的错误。

5 种常用解决方法：

增加异步处理队列：通过工作处理层批量处理异步处理队列中的数据修改请求
建立数据库水平分区：通常建立 Key 分区，以主键/唯一键 Hash 值作为 Key
建立数据库分片或重新分片：通常专门编写脚本来自动完成，且要进行充分测试
引入读写分离技术：主数据库处理写请求，通过复制机制分发至从数据库
引入分库分表技术：按照业务上下文边界拆分数据组织结构，拆分单数据库压力

1.1.2 大数据特点

大数据具有体量大、时效性强的特点，并非构造单调，而是类型多样。处理大数据时，传统数据处理系统因数据过载、来源复杂、类型多样等诸多原因性能低下，需要采用以新式计算架构和智能算法为代表的新技术。

大数据的应用重在发掘数据间的相关性，而非传统逻辑上的因果关系。

大数据的目的和价值：发现新的知识，洞悉并进行科学决策。

现代大数据处理技术：

基于分布式文件系统 Hadoop
使用 Map/Reduce 或 Spark 数据处理技术
使用 Kafka 数据传输消息队列及 Avro 二进制格式

1.1.3 大数据利用过程

4 个过程：采集 → 清洗 → 统计 → 挖掘

1.2 大数据处理系统架构分析

1.2.1 面临的挑战

如何利用信息技术等手段处理非结构化和半结构化数据
如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模
数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

1.2.2 大数据处理系统应具有的属性和特征

鲁棒性和容错性
低延迟
横向扩展（通过增强机器性能扩展）
通用
可扩展
即席查询（用户按照自己的要求进行查询）
最少维护和可调试

1.3 典型的大数据架构（重点！）

1.3.1 Lambda 架构

定义：Lambda 架构是一种用于同时处理离线和实时数据的、可容错的、可扩展的分布式系统。

3 层结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


┌─────────────────────────────────────────┐
│ 服务层（Serving Layer） │
│ 响应用户请求，合并批视图和实时视图 │
├─────────────────────────────────────────┤
│ 加速层（Speed Layer） │
│ 处理增量实时数据，生成实时视图 │
├─────────────────────────────────────────┤
│ 批处理层（Batch Layer） │
│ 存储主数据集，周期执行批处理，生成批视图 │
└─────────────────────────────────────────┘

层	核心功能	架构实现
批处理层	存储主数据集（原始、不可变、真实），周期性转储增量数据并执行批处理，生成批视图	HDFS/HBase 存储主数据集，Spark/MapReduce 周期批处理，MapReduce 创建批视图
加速层	处理增量实时数据，生成实时视图，快速执行即席查询	HDFS/HBase 存储实时数据，Spark/Storm 实时处理
服务层	响应用户请求，合并批视图和实时视图中的结果数据集得到最终数据集	HBase/Cassandra 作为服务层，Hive 创建可查询视图

Lambda 架构优缺点：

优点：容错性好，查询灵活度高，弹性伸缩，易于扩展
缺点：编码量大，持续处理成本高，重新部署和迁移成本高

与 Lambda 架构相似的模式：事件溯源模式、命令查询职责分离模式（CQRS）

1.3.2 Kappa 架构

定义：Kappa 架构是在 Lambda 架构的基础上进行了优化，删除了 Batch Layer，将数据通道以消息队列进行替代。

2 层结构：

1
2
3
4
5
6
7
8
9


┌─────────────────────────────────────────┐
│ 服务层（Serving Layer） │
│ 使用实时视图中的结果数据集响应用户请求 │
│ 实践中使用数据湖中的存储作为服务层 │
├─────────────────────────────────────────┤
│ 实时层 │
│ 处理输入数据，生成实时视图 │
│ Kafka 回访 + Flink/Spark Streaming │
└─────────────────────────────────────────┘

层	核心功能	架构实现
实时层	处理输入数据，生成实时视图；流式处理引擎逐条处理输入数据	Apache Kafka 回访数据 + Flink/Spark Streaming
服务层	使用实时视图响应用户请求	数据湖中的存储

Kappa 架构本质：通过改进 Lambda 架构中的加速层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。

Kappa 优缺点：

优点：将离线和实时处理代码进行了统一，方便维护
缺点：消息中间件有性能瓶颈、数据关联时处理开销大、抛弃了离线计算的可靠性

Kappa 常见变形：Kappa+ 架构、混合分析系统 Kappa 架构

1.3.3 Lambda vs Kappa 架构对比

对比内容	Lambda 架构	Kappa 架构
复杂度与开发维护成本	维护两套系统（引擎），复杂度高，成本高	维护一套系统（引擎），复杂度低，成本低
计算开销	周期性批处理计算，持续实时计算，计算开销大	必要时进行全量计算，计算开销相对较小
实时性	满足实时性	满足实时性
历史数据处理能力	批式全量处理，吞吐量大，历史数据处理能力强；批视图与实时视图存在冲突可能	流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱

1.3.4 Lambda 与 Kappa 架构选择（4 维度）

设计考虑	选择 Lambda	选择 Kappa
业务需求与技术要求	依赖 Hadoop、Spark、Storm 技术	依赖 Flink 计算引擎，偏流式计算
复杂度	实时处理和离线处理结果可能不一致	频繁修改算法模型参数
开发维护成本	成本预算充足	成本预算有限
历史数据处理能力	频繁使用海量历史数据	仅使用小规模数据集

1.4 大数据架构的实践（4 大案例）

1.4.1 案例 1：大规模视频网络（Lambda 架构）

某网采用 Lambda 架构搭建的大数据平台处理里约奥运会大规模视频网络观看数据。

平台架构（4 层）：

数据采集层：PC 端 + App 端 + TV 端 → Nginx → Kafka
数据集成层：实时数据（Flume + Kafka）+ 离线数据（Flume + Sqoop + HDFS + ETL）
数据存储层：MemSQL + HBase + HDFS
数据计算层：离线计算（Spark/MapReduce）+ 实时计算（Spark Streaming）+ 合并计算（Impala/Hive）
数据展现层：当日概览、赛事回顾

数据计算层 3 个部分：

离线计算：存储持续增长的批量离线数据，周期性地使用 Spark 和 Map/Reduce 批处理，批视图写入 HDFS
实时计算：采用 Spark Streaming，处理实时增量数据，更新实时视图
合并计算：合并批视图和实时视图，生成最终数据集，写入 HBase 用于响应查询

1.4.2 案例 2：广告平台（Lambda 架构）

层	实现
批处理层	每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS，将 HDFS 中数据解析为 Hive 表，使用 HQL 或 Spark SQL 计算分区统计结果 Hive 表，转储到 MySQL 中作为批视图
加速层	使用 Spark Streaming 实时监听 Kafka 下单、付款等消息，计算每个追踪链接维度的实时数据，存储在 Redis 中作为实时视图
服务层	采用 Java Web 服务，对外提供 HTTP 接口，Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表

1.4.3 案例 3：证券智能决策（Kappa 架构）

某证券公司智能决策大数据系统是一个基于 Kappa 架构的实时日志分析平台。

实时处理过程：

日志采集：用统一的数据处理引擎 Filebeat 实时采集日志并推送给 Kafka 缓存
日志清洗解析：利用基于大数据计算集群的 Flink 计算框架实时读取 Kafka 消息并进行清洗，解析日志文本转换成指标
日志存储：日志转储到 ElasticSearch 日志库，指标转储到 OpenTSDB 指标库
日志监控：单独设置告警消息队列，保持监控消息时序管理和实时推送

1.4.4 案例 4：电商智能决策（Kappa 架构）

该智能决策大数据平台基于 Kappa 架构，使用统一的数据处理引擎 Flink 可实时处理流数据，并将其存储到数据仓库工具 Hive 与分布式缓存 Tair 中。

实时处理过程：

数据采集：B 端实时采集用户点击、下单、广告曝光、出价等数据然后推送给 Kafka 缓存
数据清洗聚合：由 Flink 实时读取 Kafka 消息，按需过滤参与业务需求的指标，将聚合时间段的数据转换成指标
数据存储：Flink 将计算结果转储至 Hive 日志库，将模型需要的参数转储至实时计算数据库 Tair 缓存，后续决策服务从 Tair 中获取数据进行模型训练

1.5 实践案例总结

架构选型决策树：

1
2
3
4
5


Q1: 是否需要频繁修改算法模型参数？
 ├─ 是 → Kappa
 └─ 否 → Q2: 是否有海量历史数据？
 ├─ 是 → Lambda
 └─ 否 → Kappa

2. 关键概念速查

概念	定义/说明	常见考点
大数据	体量大、时效性强、类型多样、价值	4 大特点
Lambda 架构	离线+实时	3 层：批处理/加速/服务
Kappa 架构	仅流式处理	2 层：实时/服务
批处理层	Batch Layer	存储主数据集 + 批视图
加速层	Speed Layer	实时视图
服务层	Serving Layer	合并视图 + 响应请求
批视图	Batch View	离线计算结果
实时视图	Real-time View	实时计算结果
HDFS	Hadoop Distributed File System	分布式文件系统
HBase	Hadoop Database	分布式列存储
MapReduce	分布式计算框架	批处理
Spark	内存计算框架	比 MR 快
Storm	实时流式处理	Twitter 开源
Flink	分布式流处理	流批一体
Spark Streaming	Spark 的流处理模块	微批处理
Kafka	消息队列	高吞吐
Hive	数据仓库工具	SQL-on-Hadoop
Impala	实时查询引擎	内存计算
Avro	二进制数据格式	序列化
HQL	Hive SQL	类 SQL
Tair	分布式缓存	阿里开源
OpenTSDB	时序数据库	基于 HBase
ElasticSearch	分布式搜索	日志库
Filebeat	日志采集器	轻量级
Redis	内存数据库	缓存
Cassandra	分布式 NoSQL	高可用
Nginx	HTTP 服务器	反向代理
Flume	日志采集	海量日志
Sqoop	数据传输	RDBMS ↔ Hadoop
ETL	Extract-Transform-Load	数据抽取转换加载
CQRS	命令查询职责分离	读写分离
CAP	Consistency/Availability/Partition	分布式理论
数据湖	Data Lake	原始数据存储

3. 典型例题（案例分析题）

例题 1：选择题（陷阱题）

题目：以下关于大数据的说法中，错误的是（）。

A. 大数据拥有体量大、构造单调、时效性强等特点 B. 处理大数据需要采用新式计算架构和智能算法等新技术 C. 大数据的应用着重相关剖析，而不是因果剖析 D. 大数据的目的在于发现新的知识，洞悉并进行科学决策

参考答案：A 解析：大数据具有体量大、时效性强的特征，并非构造单调，而是类型多样。A 选项的"构造单调"是错误的。

例题 2：选择题（Lambda 架构核心）

题目：Lambda 架构分为三层：（1）批处理层（2）加速层（3）服务层

（1）的核心功能是存储主数据集。（2）的核心功能是处理增量实时数据，生成实时视图。（3）的核心功能是响应用户请求，合并批视图和实时视图。

参考答案：

（1）A. 批处理层
（2）C. 加速层
（3）C. 服务层

解析：

批处理层：核心功能是存储主数据集，主数据集具有原始、不可变、真实的特征
加速层：核心功能是处理增量实时数据，生成实时视图
服务层：核心功能是响应用户请求，合并批视图和实时视图

例题 3：综合分析题（Lambda 架构识别）

题目：某互联网公司近期为其旗下产品升级架构，架构图（描述）如下：

Collector 收集结构化数据推送给主 Kafka
主 Kafka 写入 HDFS
异构数据通过 DataX/Sqoop 写入 HDFS
HDFS 数据通过 Offline（Hive/MR/Spark）进行离线处理
HDFS 数据通过 OLAP（Kylin/Naix）进行联机分析处理
处理结果存储至由各类关系型数据库组成的结果存储
主 Kafka 通过分发机制分发给 Kafka，交给 Flink/Storm 订阅者
Flink/Storm 进行流式实时处理，结果存储至处理结果存储
OneDataAPI 通过非关系型数据库对数据平面和业务系统提供数据服务

请指出该架构采用的是什么架构，并说明该架构的层次结构。

参考答案：该架构采用的是 Lambda 架构，由以下层次组成：

数据采集层：Collector、DataX/Sqoop
数据源：HDFS
批处理层：Offline（Hive/MR/Spark），OLAP（Kylin/Naix）
加速层：Flink/Storm
服务层：结果视图存储（MongoDB、ElasticSearch、HBase、Redis…），OneDataAPI

4. 论文素材

本章是论文题出题范围，以下 3 个题目方向可以重点准备：

论 Lambda 架构在企业大数据平台中的应用
- 写作要点：批处理/加速/服务 3 层职责、HDFS/Hive/Spark 选型
- 实战案例：视频网络/广告平台
论 Kappa 架构在实时数据处理中的实践
- 写作要点：Flink + Kafka 流批一体、Kappa+ 变形
- 实战案例：证券智能决策/电商智能决策
论 Lambda 与 Kappa 架构的选型与对比
- 写作要点：4 维度选择、业务特点与架构匹配
- 实战案例：从 Lambda 迁移到 Kappa 的演进

5. 高频考点

大数据 4 特点：体量大、时效性强、类型多样、价值（注：不是"构造单调"）
Lambda 3 层：批处理层（主数据集）+ 加速层（实时视图）+ 服务层（合并响应）
Kappa 2 层：实时层 + 服务层
Lambda vs Kappa 4 维度对比：复杂度、计算开销、实时性、历史数据
4 大实践案例技术栈：
- 视频网络：Spark + HBase + HDFS + Kafka
- 广告平台：Spark Streaming + Redis + MySQL
- 证券：Filebeat + Kafka + Flink + ES + OpenTSDB
- 电商：Flink + Kafka + Hive + Tair
大数据 4 过程：采集 → 清洗 → 统计 → 挖掘
传统数据库过载 5 种解决方法：异步队列/分区/分片/读写分离/分库分表

大数据 on Liangweidong's blog