speedrun19｜第19章 大数据架构设计理论与实践

ONEPSOFT | 软考学习知识库

---

speedrun19｜第19章 大数据架构设计理论与实践

第 19 章 大数据架构设计理论与实践 — 知识点速通

一、章节定位

一句话概括：本章讲传统数据处理系统的瓶颈、大数据 4V 特征、Lambda 与 Kappa 两大批流处理架构及其实现（HDFS/MapReduce/Storm/Spark vs Kafka/Flink）、以及两者的对比与设计选择，属于综合知识 + 案例 + 论文重点区。

• 题型覆盖：综合知识【✓】 ｜ 案例分析【✓】 ｜ 论文【✓】
• 重要性等级：【4 星】——大数据是架构师热门方向，选择/案例/论文均可能出现
• 教材出处：第 19 章 大数据架构设计理论与实践（19.1–19.5，含 19.6 案例）

二、本章在讲什么（系统性阐述）

大数据架构要解决的核心矛盾是：传统 " 应用直连数据库 " 的架构，在数据量和访问速度爆炸后彻底扛不住——加队列缓冲只是扬汤止沸，水平分区也只是权宜之计。于是出现了两套 " 治本 " 的批流处理架构：Lambda 用 " 批处理层（算全量、保精确）+ 速度层（算增量、保实时）" 双轨并行，服务层合并两者视图；Kappa 则 " 一切皆流 "，只用一套 Kafka+Flink 系统，靠重播历史消息来应对全量重算。两者的取舍在于：要历史批处理能力就选 Lambda（维护两套系统、成本高），要简单低成本就选 Kappa（一套系统、流为主）。批流融合则是二者之间的折中演进。

对土木工程背景同学，大数据架构就像工程全量监测数据湖：Lambda 是 " 定期对全线传感器做全量精算（批处理）+ 实时盯报警（速度层）" 双轨，Kappa 是 " 所有监测数据一律进实时流管道、需要时回放历史 "。

三、教材原文精摘（原封不动，逐子章节全覆盖）

下列段落直接摘自官方教材《系统架构设计师教程（第二版）》，未做任何改写，是本章各子章节最核心的原文。请先读原文，再结合下方讲解理解。

【19.1 传统数据处理系统存在的问题 原文】：" 随着信息时代互联网技术爆炸式的发展，人们对于网络的依赖程度日渐加深，在业务中需要处理的数据量快速增加，逐渐飙升到了一个惊人的数量级。并且数据产生的速度随着采集与处理技术的更新仍在加快。"

" 数据量从兆字节 (MB)、吉字节 (GB) 的级别到现在的太字节 (TB)、拍字节 (PB) 级别，数据量的变化促使数据管理系统 (DBMS) 和数据仓库 (Data Warehouse,DW) 系统也在悄然地变化着。"

" 传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。"

" 在 Web 服务器和数据库中间加入一层异步处理的队列，缓解数据库的读写压力。这相当于在两者之间建立了一个缓冲。但是，这一方案并没有从本质上解决数据库过载 (Overload) 的问题……一个解决办法是对数据库进行分区 (Horizontal Partitioning)。分区的方式通常以 Hash 值 作为 key。"

【19.2.2 大数据处理系统架构特征（4V） 原文】："IBM 认为大数据横跨三个层面：数量，速度和品种。IBM 将大数据概括为三个 V,即大规模 (Volume) 、 高速度 (Velocity) 和多样化 (Variety),这些特点也反映了大数据所潜藏的价值 (Value, 第四个 "V")。因此大数据的特征可以整体概括为：" 海量 + 多样化 + 快速处理 + 价值 "。"

【19.2.1 大数据处理系统面临挑战 原文】：（教材以 " 粗糙知识度量、数据异构性与决策异构性 " 等科研问题展开，未提供可摘录短句原句；参考大纲/常见考点：大数据挑战集中在数据规模大、速度快、类型杂、价值密度低，以及存储、计算、传输开销与异构融合）

【19.3.3 Lambda 架构介绍 原文】：" 如图 19-4 所示，Lambda 架构可分解为三层，即批处理层、加速层和服务层。"

"(1) 批处理层 (Batch Layer): 存储数据集，Batch Layer 在数据集上预先计算查询函数，并构建查询所对应的 View。"

" 我们把针对查询预先计算并保存的结果称为 View, View 是 Lambda 架构的一个核心概念，它是针对查询的优化，通过 View 即可以快速得到查询结果。"

（主数据集属性，同节）：" 该层负责管理主数据集。主数据集中的数据必须具有以下三个属性：(1) 数据是原始的。(2) 数据是不可变的。(3) 数据永远是真实的。"

【19.3.6 Lambda 与其他架构模式对比（读写分离） 原文】：" 在 Lambda 架构中，对数据进行查询时，实际上是通过读取 View 直接得到结果，读出所需的内容。这实际上是一种形式的读写分离……在大数据系统中经常处理海量数据，进行读写分离重要性不言而喻。"

【19.4.2 Kappa 架构介绍 原文】："Kappa 架构的复杂度相对低很多，只需要开发并维护一套系统。因为 Kafka 对于流式计算有良好支持，易于编程，故一般使用 Kafka 作为消息中间件，将数据保存在消息队列中。流式计算系统一般使用 Flink 实现，其作为新兴的流处理框架，以数据并行和流水线方式执行任意流数据程序，且同时支持批处理和流处理。"

【19.4.5 常见 Kappa 架构变形 原文】："Kappa+ 是 Uber 提出流式数据处理架构，它的核心思想是让流计算框架直接读 HDFS 里的数据仓库数据，一并实现实时计算和历史数据 backfill 计算……Uber 开发了 Apache hudi 框架来存储数据仓库数据。"

" 在基于使用 Kafka+Flink 构建 Kappa 流计算数据架构，针对 Kappa 架构分析能力不足的问题，再利用 Kafka 对接组合 Elastic-Search 实时分析引擎，部分弥补其数据分析能力。"

【19.5.1 Lambda 架构与 Kappa 架构的特性对比 原文】：" 复杂度与开发、维护成本：因为需要开发并维护两套系统，Lambda 架构的复杂度相对更高……Kappa 架构的复杂度相对低很多，只需要开发并维护一套系统……开发维护成本相对较低。"

" 历史数据处理能力：有些情况下，项目会频繁接触海量数据集进行分析，比如过往十年内的地区降水数据等，这种数据适合批处理系统进行分析，应该选择 Lambda 架构。如果始终使用小规模数据集，流处理系统完全可以使用，则应该选择 Kappa 架构。"

【19.5.2 Lambda 架构与 Kappa 架构的设计选择 原文】："1.业务需求与技术要求：用户需要根据自己的业务需求来选择架构，如果业务对于 Hadoop、Spark、Strom 等关键技术有强制性依赖，选择 Lambda 架构可能较为合适：如果处理数据偏好于流式计算，又依赖 Flink 计算引擎，那么选择 Kappa 架构可能更为合适。……3.开发维护成本：Lambda 架构需要有一定程度的开发维护成本……适合有足够经济、技术和人力资源的开发者。而 Kappa 架构只需要维护一套系统，适合不希望在开发维护上投入过多成本的开发者。"

【批流融合 原文】：（教材未直接使用 " 批流融合 " 四字词组；参考大纲/常见考点：批流融合指在同一架构中统一批处理与流处理，使同一套代码/引擎既算历史全量也算实时增量。其思想贯穿 Lambda 的双轨、Kappa 的 " 流为主 + 历史重播 "，以及 Kappa+（流框架直接读数仓 backfill）、Kappa+ES 混合分析等折中方案）

逐段讲解（紧贴上面原文，一段一解）：

• 针对 19.1：传统直连 DB 在量与速爆炸后崩溃；加队列只是缓冲，分区 (Hash key) 只是缓解——引出必须换架构。
• 针对 19.2.2（4V）：Volume（量大）、Velocity（速度快）、Variety（类型杂）、Value（价值密度低），是大数据的身份证，必考。
• 针对 19.2.1：挑战是规模/速度/异构/价值密度，与 4V 对应。
• 针对 19.3.3（Lambda）：三层——批处理层（存主数据集、预计算 View、保精确）、加速/速度层（算实时增量）、服务层（合批视与实时视应答）。View 是核心概念（预计算查询结果）。主数据集三属性：原始、不可变、永远真实——这是 Lambda 能重算、可溯源的根基。
• 针对 19.3.6：Lambda 用 " 读写分离 "（写进批/速两层，读直接取 View）应对海量，是重要设计思想。
• 针对 19.4.2（Kappa）：一套 Kafka（消息队列/存储）+ Flink（流批一体）搞定，复杂度低、成本低，但历史批处理能力弱。
• 针对 19.4.5：Kappa+ 让流框架直接读 HDFS 数仓做 backfill（Uber/hudi）；Kappa+ES 补分析能力——都是批流融合的折中。
• 针对 19.5.1/19.5.2（对比选择）：Lambda=两套系统、成本高、历史批处理强；Kappa=一套系统、成本低、流强。选 Lambda 当强依赖 Hadoop/Spark/Storm 或需频繁历史批处理；选 Kappa 当偏流、依赖 Flink、不希望高维护成本。

四、核心知识树

第 19 章 大数据架构设计

├── 问题背景

│ ├── 传统直连 DB 瓶颈

│ └── 4V 特征

├── Lambda 架构

│ ├── 批处理层 (主数据集)

│ ├── 加速/速度层

│ └── 服务层 (View)

├── Kappa 架构

│ ├── Kafka 消息队列

│ ├── Flink 流批一体

│ └── Kappa+/混合变形

└── 对比与选择

├── 复杂度/成本

├── 历史批处理能力

└── 业务技术依赖

五、知识脑图总结

思维导图（结构化呈现）

• 第19章 大数据架构
  • 问题背景
    • 传统DB瓶颈
    • 4V特征
  • Lambda
    • 批处理层主数据集
    • 速度层实时
    • 服务层View
  • Kappa
    • Kafka队列
    • Flink流批
    • Kappa加变形
  • 对比选择
    • 两套vs一套
    • 历史批处理强
    • 业务依赖选

六、关键概念速解

概念	教材定义（原文关键词）	大白话速解	考试怎么考
4V	"Volume、Velocity、Variety、Value：海量 + 多样化 + 快速处理 + 价值 "	大、快、杂、值低	选择/案例
主数据集	" 数据是原始的、不可变的、永远真实的 "	Lambda 的 " 原始真值库 "	选择
View	" 针对查询预先计算并保存的结果 "	预算好的查询答案	选择
Lambda	" 批处理层、加速层和服务层 " 三层	批 + 速双轨并行	案例/论文
Kappa	" 一套系统；Kafka 消息中间件 + Flink"	一切皆流、一套搞定	案例/论文
批流融合	（参考）统一批与流的架构	一套引擎算历史 + 实时	选择
Kappa+	" 流框架直接读 HDFS 数仓做 backfill"	Kappa 增强历史回算	选择

七、记忆口诀 & 类比

• 口诀：「4V 量大快杂值低；Lambda 批速服三层，主数据集原始不可变；Kappa 一套 Kafka+Flink；历史强选 Lambda，流强选 Kappa」→ 对应特征 + 两大架构 + 选型。
• 类比：
• 大数据架构 ≈ 工程全量监测数据湖：传感器数据（PB 级、秒级产生、类型杂=4V）汇入数据湖。
• Lambda ≈ 对全线传感器 " 定期全量精算（批处理层，存原始监测真值）+ 实时盯超限报警（速度层）" 双轨，调度中心（服务层）合并两者出报告（View）。主数据集=原始监测档案，不可篡改可追溯。
• Kappa ≈ 所有监测数据一律进实时流管道（Kafka），Flink 实时算；要复查历史就 " 回放消息流 "，只用一套系统，简单便宜但长期历史深挖弱。

八、易混淆点对比

易混项 A	易混项 B	核心区别
Lambda	Kappa	Lambda 批 + 速双轨、两套系统、历史批处理强、成本高；Kappa 单一流、一套系统、成本低、历史弱
批处理层	速度层	批处理层算全量/精确、主数据集；速度层算实时增量、低延迟
主数据集	View	主数据集是原始不可变真值；View 是预计算查询结果
Kappa	Kappa+	Kappa 纯流；Kappa+ 让流框架直接读数仓做历史 backfill，补历史能力

九、与其他章节的关联

• 上游/前置：第 2 章分布式与存储、第 4 章架构风格（管道 - 过滤器风格用于流处理）、第 9 章可靠性。
• 下游/依赖：云原生架构（数据平台）、数据中台、AI/机器学习的数据底座。
• 联动考点：Lambda/Kappa 常与 " 质量属性（性能/可扩展性）"" 架构评估 " 合并考；论文常见 " 论大数据系统架构设计 " 方向。

十、考试出题方式

• 选择题：4V 含义、Lambda 三层与主数据集三属性、Kappa 技术栈（Kafka/Flink）、批流融合概念、Lambda vs Kappa 对比项。
• 案例分析：给业务场景（如海量日志/物联网监测）判断选 Lambda 还是 Kappa，说明理由，画出分层架构。
• 论文：" 论大数据处理系统架构设计 "" 论批流融合架构 " 等为常见方向，需结合项目写 Lambda/Kappa 实践与选型权衡。