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

对应大纲：科目 1-18 大数据架构设计理论与实践｜教材 P676–P701｜优先级 ★★★★｜综合知识估分 2～4 分
读法：本章只有一条主线——批处理与流处理如何拼成一个系统。先把 Lambda 三层背成肌肉记忆，再用五维表把 Kappa 压进去，最后记 6 条选型判据。选择题只考「谁负责什么」，案例题只考「选哪个、为什么」，论文只考「你怎么落地」。

一、知识框架#

大数据架构设计理论与实践
├─ 19.1 传统数据处理系统存在的问题
│   ├─ 扩展：纵向扩展有天花板
│   ├─ 数据：只擅长结构化，Schema-on-write
│   ├─ 时效：只能批处理，T+1
│   └─ 成本与容错：高端设备、扩容即停机
├─ 19.2 大数据处理系统架构分析
│   ├─ 5V：Volume｜Variety｜Velocity｜Veracity｜Value
│   ├─ 面临挑战：规模｜类型｜时效｜质量｜成本
│   └─ 架构特征：分布式、水平扩展、数据不可变、批流并存
├─ 19.3 Lambda 架构
│   ├─ 三层：Batch Layer｜Speed Layer｜Serving Layer
│   ├─ 两条基石：数据不可变 + 可重算
│   ├─ 实现：HDFS/Spark + Kafka/Flink + HBase/Redis
│   └─ 优缺点与横向对比
├─ 19.4 Kappa 架构
│   ├─ 一条链路：全部数据进 Kafka，只用流处理
│   ├─ 一个动作：重放（replay）代替重算
│   ├─ 实现与常见变形（流批一体、Kappa+）
│   └─ 优缺点
├─ 19.5 Lambda 与 Kappa 的对比和设计选择
│   ├─ 五维对比：实时性｜复杂度｜运维成本｜一致性｜场景
│   └─ 六条选型判据
└─ 19.6 案例分析
    ├─ 案例一：零售全渠道数据平台（选 Lambda）
    ├─ 案例二：银行实时反欺诈（选 Kappa）
    └─ 案例答题四步与论文用法

二、必背要点#

19.1 传统数据处理系统存在的问题#

传统数据仓库的典型链路：业务库 → ETL → ODS → 数据仓库 → 数据集市 → BI 报表。它建立在关系数据库与小型机之上，设计前提是「数据量可控、结构固定、按天出结果」。数据规模一大，这些前提逐条失效。

一句话总结：传统系统是「先定模式、纵向堆硬件、按天出结果」；大数据系统要「先存原始数据、横向加机器、秒级出结果」。

19.2 大数据处理系统架构分析#

5V 特征（4V 为经典四要素，5V 增加真实性）

四类挑战：规模挑战（存储与计算如何扩展）、类型挑战（如何容纳多模数据）、时效挑战（批与流如何共存）、成本与质量挑战（如何在可接受成本下保证可信）。

大数据系统架构的六个特征

技术栈分层（背这一张就够）

19.3 Lambda 架构#

基本理解

Lambda 架构由 Nathan Marz 提出，出发点是一个函数式观点：

查询结果 = 对「全部历史数据」应用「某个函数」

只要原始数据永不修改（只追加），那么任何时候都能用新函数把历史重算一遍，得到正确结果。这一条「数据不可变 + 可重算」是 Lambda 的全部地基，也是它容错能力的来源：程序有 bug 不可怕，改完重算即可。

三层结构

数据源 ──► Batch Layer（HDFS 主数据集 + Spark/MapReduce）
       │        └─ 周期性全量重算 ──► Batch View（批视图）
       └──► Speed Layer（Kafka + Flink/Storm）
                └─ 只算增量 ──► Realtime View（实时视图）
                                      │
                        Serving Layer ◄┘
                   （合并批视图 + 实时视图，对外查询）

查询合成公式

最终结果 = 批视图（截至上次批处理） + 实时视图（此后的增量）

批视图是「最终正确」的，实时视图是「临时补齐」的。当下一轮批处理完成，实时视图对应区间被批视图覆盖，实时视图即可丢弃重建——这就是 Lambda 的自我修正机制。

实现要点

优点

• 准确性有兜底：批层全量重算可修正流层近似与错误，结果最终正确。
• 容错强：数据不可变，出错重跑即可，不需要复杂的事务回滚。
• 实时与离线兼得：既满足 T+1 的精确报表，也满足秒级的大屏与告警。
• 技术成熟：每一层都有大量成熟组件，团队易招聘、易运维。

缺点

• 两套代码：同一业务口径要在批、流两个引擎各写一遍，逻辑漂移导致「大屏和报表对不上」。
• 运维复杂：HDFS、Kafka、两套计算引擎、服务层数据库，组件多、链路长。
• 准确性有时延：流层结果在被批层覆盖前只是近似值。
• 资源开销大：周期全量重算消耗大量算力与存储。

19.4 Kappa 架构#

基本理解

Kappa 架构由 Jay Kreps（Kafka 作者之一）提出，核心质疑是：既然流处理引擎可以处理无界数据，为什么还要维护一套批处理？ 他的答案是——不要批层，只保留一条流处理链路；需要重算时，不重新跑批任务，而是把数据重放一遍。

一条链路

数据源 ──► Kafka（唯一数据源；多分区、多副本、长期保留）
                │
                ├─► 流处理作业（Flink，一套代码）
                │        └─► Serving（Redis/ClickHouse/HBase）
                │
                └─► 需要重算：重置 offset 从头重放
                         └─► 新结果表 ──► 校验 ──► 切换

Kafka 在 Kappa 中的四个作用（必背）

重放（Replay）

改完逻辑后：停作业 → 记录当前 offset → 重置到起点（或指定时间点）→ 用新逻辑重跑 → 结果写入新表/新版本 → 与旧结果比对无误 → 切换读流量。要点是旁路重算、验证后切换，不能直接覆盖线上结果。

优点

• 一套代码：批流统一，口径天然一致，不存在「报表与大屏对不上」。
• 架构简单：只有 Kafka + 流引擎 + 服务层，组件少、运维成本低。
• 实时性最好：全链路流式，端到端秒级。
• 可重放：靠 Kafka 保留期实现「重算」，逻辑变更成本低。

缺点

• 强依赖 Kafka 保留期：要能重放历史，就得长期保留原始数据，存储成本高。
• 重放代价大：PB 级历史重放耗时可能超过业务可接受窗口。
• 复杂分析能力弱：大规模多表 join、全量排序、机器学习特征工程仍不如批处理。
• 对流引擎要求高：状态管理、精确一次、反压处理都要靠引擎能力兜底。

常见变形

19.5 Lambda 与 Kappa 的对比和设计选择#

五维对比（必背表）

六条选型判据（按顺序问自己）

1. 要不要大规模历史全量重算？ 要，且数据到 PB 级、重放不现实 → Lambda。
2. 实时性要求是秒级还是分钟/小时级？ 秒级且是主诉求 → Kappa 优先。
3. 业务逻辑变更后能否承受全量重放？ 能（数据量可控、保留期够）→ Kappa；不能 → Lambda。
4. 分析是否以复杂多表关联、全量聚合、特征工程为主？ 是 → Lambda 的批层更合适。
5. 团队有几个人维护大数据平台？ 1～3 人 → Kappa；有专职平台团队 → Lambda。
6. 是否有合规要求长期留存原始数据、可回溯审计？ 有 → 两者都要做不可变存储，Kappa 需把归档层补齐。

一句话结论：Lambda 用复杂度换准确性与分析能力，Kappa 用存储与重放成本换架构简洁与实时一致性。 新项目若无沉重历史包袱，优先 Kappa 或流批一体；已有成熟离线数仓、又要加实时能力的，优先 Lambda。

19.6 案例分析#

案例一：某零售集团全渠道数据平台（选 Lambda）

案例二：某银行实时反欺诈（选 Kappa）

案例答题四步

1. 定性：先判断题目要批流并存（Lambda）还是单一实时链路（Kappa），一句话给结论。
2. 画层：按「采集 → 存储 → 计算 → 服务」写出每层组件与职责，Lambda 必须写清三层。
3. 说理：用五维表中的 2～3 维给判据，必须扣住题目的数据量、延迟、团队规模。
4. 补短板：主动写一条缺点与应对（如「Kappa 历史重放成本高，我们将冷数据归档对象存储」）。

论文可用句式

「平台日均接入埋点 20 亿条，历史数据 3 PB。若采用纯流式架构，一次全量重放需 40 小时，无法满足财务 T+1 出表要求，因此我们选择 Lambda 架构：批处理层用 Spark 每日全量重算保证准确性，加速层用 Flink 计算 5 分钟增量，服务层合并两视图对外提供查询，最终大屏延迟控制在 3 秒、报表准确率达到 100%。」

三、易混淆概念对比#

四、常见考法与出题角度#

五、速记与自测#

速记

• 大数据 5V：量、类、速、真、值
• 传统四病：扩不动、只能批、写定模、类型窄
• 架构六特征：分布、横扩、不变、读模、批流、算移
• Lambda 三层：批、速、服（Batch、Speed、Serving）
• Lambda 两基石：不可变、可重算
• Kappa 三件套：Kafka 唯一源、流处理一套码、offset 重放
• Kafka 四机制：分区、副本、位点、保留
• 选型口诀：历史重、分析杂 → Lambda；实时主、逻辑稳 → Kappa

自测

1. Lambda 架构的三层分别叫什么？各层的输入与输出是什么？
2. 为什么说「数据不可变」是 Lambda 容错能力的基础？
3. Kappa 架构如何实现「重算」？它最大的成本在哪里？
4. 某系统日均 500 万笔交易、要求 200 毫秒风控、规则每月迭代、无离线报表需求，应选哪种架构？

答案：1. 批处理层（全部历史→批视图）、加速层（增量数据→实时视图）、服务层（两视图→查询结果）；2. 原始数据只追加不修改，任何时刻都能用新逻辑重跑全量，出错只需重算而不需回滚；3. 重置 Kafka 消费 offset 从头重放日志；最大成本是长期保留原始数据的存储与重放耗时；4. Kappa，纯实时、逻辑常变、可靠重放验证，无离线分析诉求。