deepread13｜案例+大数据处理系统详解

ONEPSOFT | 软考学习知识库

---

deepread13｜案例+大数据处理系统详解

知识点深度解读：大数据处理系统（批处理 / 流处理 / Lambda 架构）

一、知识点定位

• 主要教材出处：第 19 章 大数据处理系统分析与设计之 19.2.2 大数据处理系统架构类型（批处理架构、流处理架构、混合架构）、19.2.3 大数据处理系统架构模式（Lambda 架构），并衔接 19.3.1 批处理离线模式。
• 在考试中的角色：案例分析科目 " 大数据处理系统分析与设计 " 重点（大纲案例 3.3）。综合知识也会考批/流/Lambda 的适用场景对比。
• 与备考关联：这三种架构本质是在 " 算得全/算得准 " 和 " 算得快/算得实时 " 之间做取舍。" 运维服务 " 里讲的数据一致性、可用性，在这里就是 " 批处理最终一致 vs 流处理实时一致 " 的源头。

一句话先讲透：大数据处理系统就三种主流玩法——批处理=攒一大堆再算（慢但全）、流处理=来一条算一条（快但只看当下）、Lambda=两套都留着（批处理保全，实时层补漏，服务层给快速答案）。

二、教材原文精摘（原封不动，跨章节全覆盖）

【第 19 章 · 19.2.2 批处理架构】原文：

批处理架构是一种数据处理系统架构类型，它主要用于处理大规模数据的批量处理任务，该任务通常在离线模式下执行，具有较高的吞吐量和较低的实时性。批处理架构通常包括数据采集、数据存储、数据处理和数据输出等四个核心模块。

在批处理架构中，数据采集模块主要负责将原始数据从不同来源收集到集中式存储中，常见的采集方式包括文件传输、日志收集和数据接口等。数据存储模块则是存储批处理任务所需的数据，包括原始数据、中间结果和最终结果等。数据处理模块是批处理架构的核心，它主要负责对原始数据进行加工、分析和处理，通常采用分布式计算技术，如 MapReduce、Spark 等。

批处理架构的优点在于能够处理大规模数据，具有较高的吞吐量和稳定性……缺点在于实时性较差，无法满足对数据的实时分析和处理需求。

【第 19 章 · 19.2.2 流处理架构】原文：

流处理架构是指数据以连续的、无限制的方式流式处理，即每条新数据都会在到达时进行处理，而不是像批处理架构一样按照固定的时间间隔来处理。

流处理架构通常使用类似 Apache Flink、Apache Storm 等开源流处理引擎来实现。在流处理架构中，数据可以被连续地读取、处理和输出……流处理框架通常由两个主要组件组成：数据流和运算符。数据流表示无限制的数据集合，而运算符用于处理数据流。

流处理架构的典型应用场景包括实时数据分析、实时监控和实时推荐等。流处理架构的优点在于其能够实时处理数据，快速响应用户请求……但是，流处理架构也有其局限性。例如，无法对历史数据进行处理……而且流式处理还需要考虑并发性和一致性等问题。

【第 19 章 · 19.2.3 Lambda 架构】原文：

Lambda 架构是一种将批处理和流处理结合起来的大数据处理系统架构模式，它旨在解决传统批处理架构的延迟问题和流处理架构的准确性问题。Lambda 架构是大数据平台里最成熟、最稳定的架构，它的核心思想是：将批处理作业和实时流处理作业分离，各自独立运行，资源互相隔离。

Lambda 架构将数据流分为三个层次：批处理层（batch layer）、加速层（speed layer）和服务层（serving layer），这些层次各自具有不同的特性和用途。

(1) 批处理层。批处理层主要负责所有的批处理操作……批处理层既可以存储整个数据集，又能够计算出批处理的视图。由于此处的存储数据集不可被改变，因此只能被追加。

(2) 加速层。加速层使用流式计算技术实时处理当前数据……加速层仅关心从最后一批视图完成以来到达的数据。也就是说，加速层通过处理那些批处理视图尚未计入的最新数据查询，来弥补计算视图时的高延迟。

(3) 服务层。以批处理层处理的结果数据为基础，对外提供低延时的数据查询和 ad-hoc 查询（即席查询）服务……因为批处理本身是比较慢的，无法支撑实时的查询请求……服务层既可以使用包括关系型数据库在内的传统技术，也可以使用 Kylin、Presto、Impala 或 Druid 等大数据 OLAP 产品。

Lambda 架构的优点在于能够同时支持批量处理和实时流处理……但 Lambda 架构也存在一些缺点，如需要维护多个层次的数据存储和复杂的数据整合，增加了系统复杂性和维护成本。此外……会造成数据冗余和增加存储成本。同时，Lambda 架构的实时性有限，无法应对对实时性要求极高的处理场景。

【第 19 章 · 19.3.1 批处理离线模式（呼应）原文：

批处理任务通常在离线模式下执行，可以充分利用计算资源，提高计算效率。

三、系统解读（逐段讲透）

• 针对【批处理架构】：这是最 " 老派 " 也最稳的做法——把数据先攒起来（采集进集中存储），再统一加工（MapReduce/Spark 分布式算），最后输出结果。好处是吞吐大、稳定、算得全；坏处是慢，等数据攒一批才能算，实时性不行。教材点名的四个模块（采集→存储→处理→输出）就是一条离线流水线。
• 针对【流处理架构】：和批处理正好相反，数据是 " 无限流动的河 "，来一条就处理一条（Flink/Storm 引擎驱动），所以延迟极低、能实时响应。但代价是 " 只盯着当下 "，历史数据它不管，还要操心并发和一致性。适合实时监控、实时推荐这类 " 现在就要结果 " 的场景。
• 针对【Lambda 架构核心思想】：教材一句话点破——" 批处理和流处理分离、各自独立、资源隔离"。它不是二选一，而是两套系统并行：批处理保 " 全而准 "，实时层补 " 快而新 "，互不打架。
• 针对【Lambda 三层】：记住这三层是分工的——批处理层存全量、算批视图（只能追加不改，像一本只增不删的总账）；加速层只算 " 批视图还没来得及计入的最新数据 "（热数据），专门补批处理的延迟短板；服务层基于批结果提供低延时查询（Kylin/Presto/Druid 这类 OLAP），本质是 " 批处理先预计算，服务层接手做实时查询 "。
• 针对【Lambda 优缺点】：优点是 " 既要又要 "——批量和实时都支持；缺点是贵且复杂——多层存储、数据冗余、整合麻烦，而且实时性仍有限（毕竟实时层只是补丁，不是纯实时）。
• 针对【19.3.1 离线呼应】：批处理在 " 离线模式 " 跑最划算，这和前面移动应用 (第 17 章) 的 " 离线批处理 " 是同一思想——断网/空闲时把重活攒着算。

核心一句话总结：批处理=攒批算（全而慢）、流处理=来条算条（快而窄）、Lambda=批层保底 + 加速层补漏 + 服务层给答案（兼顾但要付出复杂度和冗余代价）。选哪种，看你要的是 " 算全 " 还是 " 算快 "。

四、工程实践举例（土木工程类比）

你的背景是土木工程，咱们用 " 工程项目月度核算 + 现场实时监测 " 来套：

1. 批处理 = 月底集中算工程量报表。项目部的原始数据（考勤、材料单、计量单）先收集进台账（采集 + 存储），月末用造价软件统一加工出进度款报表（MapReduce/Spark 分布式算），最后输出给甲方（数据输出）。慢是慢点，但算得全、算得准——这就是批处理 " 高吞吐、低实时 "。
2. 流处理 = 现场传感器实时报警。基坑位移、应力、沉降这些监测数据像河水一样不停流进来，来一条就判断一条，超标立刻响警铃（Flink/Storm 实时处理）。但它只管 " 当下这条 "，不会回头翻上个月的历史——对应流处理 " 快但不管历史、要考虑并发与一致 "。
3. Lambda = 既留月度总账、又盯实时指标。批处理层就是那本只增不删的 " 全项目总账 "（存全量、算批视图）；加速层是 " 本月还没进总账的最新签证/变更 "（热数据），实时补总账的延迟；服务层是项目经理随时打开的 " 实时看板 "（低延时查询）。两套并行，既不怕漏算历史，又能秒看当前。
4. 代价意识：Lambda 的麻烦在于 " 两套系统都要养 "——总账和实时看板数据会重复存（数据冗余）、对账麻烦（整合复杂）。工程上就是 " 养两套台账的成本 "，对应教材 " 复杂性、维护成本、存储冗余 " 的缺点。

这里正好补上 " 数据一致性/可用性 " 的认知：批处理最终一致、流处理实时一致、Lambda 用分层隔离换 " 兼顾 "，就是分布式系统里 " 一致性 vs 可用性 vs 实时性 " 权衡的鲜活教材。

知识点 ↔ 工程实践 对照表

教材知识点要素	你的实践场景对应	映射说明
批处理架构（离线、高吞吐低实时）	月底集中算工程量总账	都是 " 攒一批再算，慢但全而准 "
流处理架构（来条算条、低延迟）	现场监测实时报警	都是 " 来一条处理一条，快但只看当下 "
Lambda 核心思想（批 + 流分离隔离）	总账与实时看板并行、互不干扰	都是 " 两套系统分工，各管一摊 "
批处理层（存全量、只能追加）	只增不删的项目总账	都是 " 历史全留、不可篡改 "
加速层（只算最新热数据补延迟）	本月未入账的最新签证/变更	都是 " 补主账的延迟短板 "
服务层（低延时查询 OLAP）	项目经理实时看板	都是 " 基于批结果做快速查询 "
Lambda 缺点（冗余/复杂/存储贵）	养两套台账的对账与存储成本	都是 " 兼顾的代价 "