901-020_系统分析师基础知识-大数据处理系统分析与设计


一、本章知识框架

大数据处理系统分析与设计

├── 1 大数据处理系统概述(定义 + 应用领域)

├── 2 大数据处理系统架构

│ ├── 2.1 架构原则(六大原则)

│ │ ├── 1. 可扩展(分布式环境 + 模块化设计)

│ │ ├── 2. 可管理(自动化管理 / 统一平台 / 可视化界面)

│ │ ├── 3. 数据安全(加密 / 访问控制 / 备份恢复 / 审计日志 / 持续监控)

│ │ ├── 4. 高性能(数据分区 / 分布式计算 / 并行处理 / 内存计算)

│ │ ├── 5. 高可用(数据冗余 / 自动故障转移 / 负载均衡)

│ │ └── 6. 稳定性(监控预警 / 性能调优 / 故障排除 / 升级维护)

│ ├── 2.2 架构类型(按数据处理方式)

│ │ ├── 批处理架构(数据采集 / 存储 / 处理 / 输出 四模块)

│ │ ├── 流处理架构(数据流 + 运算符)

│ │ └── 混合架构(批流兼顾,如 Spark)

│ └── 2.3 架构模式(三大经典模式)

│ ├── Lambda 架构(批处理层 / 加速层 / 服务层)

│ ├── Kappa 架构(流处理层 / 在线服务层)

│ └── IOTA 架构(通用数据模型 + 边缘计算)

├── 3 大数据处理系统开发

│ ├── 3.1 数据存储(采集 → 清洗 → 转换 → 存储)

│ │ ├── 数据采集(离线 / 实时 / 互联网采集)

│ │ ├── 数据清洗(五步骤)

│ │ ├── 数据转换(六步骤,属 ETL 一部分)

│ │ └── 数据存储(行存储 vs 列存储)

│ ├── 3.2 数据管理(元数据管理 / 数据关系图谱 / 数据安全 / 资源监控)

│ ├── 3.3 数据处理(数据类型 + 实时计算 / 离线计算 / 图计算)

│ ├── 3.4 数据分析(机器学习 / 搜索推荐 / 数据可视化)

│ └── 3.5 系统部署(部署分析 / 部署原则 / 部署环境 / 版本控制)

└── 4 大数据处理系统测试

├── 4.1 测试特点(五大挑战)

├── 4.2 测试过程(需求分析 → 计划方案 → 用例设计)

├── 4.3 功能测试(数据提取 / 处理 / 存储 / 迁移)

├── 4.4 性能测试(吞吐量 / 响应时间 / 扩展性)

├── 4.5 可靠性和容错性测试(故障注入 / 容错恢复 / 故障切换)

├── 4.6 安全性测试(访问控制 / 数据保护 / 漏洞扫描 / 弱密码 / 合规)

└── 4.7 兼容性测试(硬件 / 操作系统 / 数据库 / 第三方组件 / 文件格式 / API / 平台)


二、知识点详解

1 大数据处理系统概述

定义 :大数据处理系统是一种用于处理大规模数据集 的软件工具,能够利用分布式计算,从各种来源(传感器、社交媒体、移动设备、日志文件等)收集和存储大量数据,并以高效方式处理这些数据,使用户从中获取有价值的信息,帮助组织快速决策。

内涵要点:

  • 大数据分析系统不仅包括处理数据 ,还包括分类、分析、可视化 以及处理过程中的安全性保障等方面。
  • 核心能力链路:分布式存储 → 多源自动收集 → 预处理/清洗/去重/转换/压缩 → 可视化 → 检索查询 → 数据挖掘与分析 → 决策支持。

应用领域:商业智能、金融风险分析、市场营销、医疗保健、社交媒体分析等。

本章四个主线:架构、开发框架、开发过程、系统测试。概述是总起,答题时用于引出「系统分析设计」的视角。


2 大数据处理系统架构

2.1 大数据处理系统架构原则

大数据具有「4V 」特性:Volume(数据量大)、Variety(数据类型多样)、Velocity(产生与处理速度快)、Value(价值高)。架构设计须围绕 4V 特性展开,以下是六大通用设计原则:

原则 核心含义 实现要点 / 支撑技术
可扩展 轻松容纳不断增长的数据量与处理能力 ①分布式环境(横向扩展、负载均衡)②模块化设计
可管理 大数据环境下的高效管理与监控 自动化管理、统一管理平台、可视化管理界面
数据安全 保障数据安全与隐私(数据量巨大,需高度重视) ①数据加密 ②访问控制 ③备份恢复 ④审计日志 ⑤持续监控
高性能 提高性能与吞吐量,快速高效处理大量数据 ①数据分区 ②分布式计算 ③并行处理 ④内存计算
高可用 面对故障/异常时继续保持可用 ①数据冗余 ②自动故障转移 ③负载均衡
稳定性 长时间运行、高负载下保持稳定可靠 ①监控预警 ②性能调优 ③故障排除 ④升级维护

细节展开(易出选择题):

  • 可扩展 两个关键要点:分布式环境 (在不同计算节点间分配任务、管理数据/网络/内存资源,实现负载均衡;支持横向扩展,数据增大时按需快速扩展算力和存储)+模块化设计(把系统拆分为独立模块,功能职责明确,需要时添加新模块或扩展现有模块)。
  • 数据安全 五方面:数据加密 (对称加密用于数据传输、非对称加密保护数据存储)、访问控制 (用户名密码 / 访问令牌 / 生物识别;给管理员、数据分析师、数据科学家分配不同权限)、数据备份和恢复 、审计日志 (记录每个用户操作,用于审计追踪、满足监管合规)、持续监控(日志、访问模式、异常行为监控)。
  • 高性能 四手段:数据分区 (大数据集分成小块分配给不同计算单元,提高并行度和可扩展性)、分布式计算 (任务分布到多节点,独立完成再合并)、并行处理 (一个任务拆多个子任务同时执行)、内存计算(数据存内存计算,避免磁盘 I/O 和网络传输延迟)。
  • 高可用 三手段:数据冗余 (数据复制到多节点/设备)、自动故障转移 (工具如 ZooKeeper、Keepalived、Pacemaker )、负载均衡 (工具如 Haproxy、Nginx、LVS)。

记忆技巧:六大原则可归纳为「扩、管、安、能、用、稳」,其中「高性能=4 个『计算/分区』手段」「高可用=3 个『冗余/转移/均衡』手段」,可用「高性能→分区算并行内存」「高可用→冗余转负载」顺口记忆。

2.2 大数据处理系统架构类型(按数据处理方式)

维度 批处理架构 流处理架构 混合架构
处理方式 离线批量、按固定时间间隔或触发条件 连续、无限制地流式处理(每条到达即处理) 批流结合,可按需切换
典型技术 MapReduce、Spark Apache Flink、Apache Storm Apache Spark
组成模块 数据采集、数据存储、数据处理、数据输出 数据流 + 运算符 兼具批、流两种能力
优点 处理大规模数据,吞吐量高、稳定性好、充分利用计算资源 低延迟、实时反馈、快速响应、适应数据快速变化 兼顾历史数据与实时数据,快速响应
缺点 实时性差,无法满足实时分析 无法处理历史数据、可能漏数据、需考虑并发与一致性 需权衡、管理和维护成本更高

批处理架构详解 :任务通常在离线模式 下执行,吞吐量高、实时性低。四个核心模块:

  1. 数据采集:把原始数据从不同来源收集到集中式存储(文件传输、日志收集、数据接口)。
  2. 数据存储:存原始数据、中间结果、最终结果(关系型数据库、分布式文件系统、NoSQL 数据库)。
  3. 数据处理(核心):对原始数据加工分析,用 MapReduce、Spark 等分布式计算。
  4. 数据输出:结果输出到存储或数据仓库。

批处理触发时机可用预定时间间隔 (如每 5min 处理一次)或触发条件(如满 5 个数据元素或超 1MB 数据)。

流处理架构详解 :框架由两个主要组件组成------数据流 (表示无限制的数据集合)和运算符(用于处理数据流),二者通过流处理引擎管理协调。典型场景:实时数据分析、实时监控、实时推荐。

2.3 大数据处理系统架构模式(三大模式)

1. Lambda 架构

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

分为三个层次:

层次 职责 支撑技术 特点
批处理层(batch layer) 负责所有批处理操作,存储整个数据集、计算批处理视图 Hive、Spark-SQL、MapReduce 数据只能追加不可改变;查询低延迟但计算耗时
加速层(speed layer) 用流式计算实时处理当前数据 Storm、Spark Streaming、Flink 只处理「最后一批视图完成以来」的新数据(热数据),弥补批处理高延迟
服务层(serving layer) 以批处理结果为基础,对外提供低延时查询和 ad-hoc(即席)查询 Kylin、Presto、Impala、Druid(或关系型数据库) 批处理层本质是「预计算」,服务层接手提供实时查询

优点 :同时支持批处理 + 实时流处理,高吞吐量、处理多样化数据源、实时性较好。

缺点 :需维护多层数据存储和复杂数据整合,系统复杂、维护成本高;数据同时存于批处理层和速度层导致数据冗余、存储成本增加;实时性有限,无法应对实时性要求极高的场景。

2. Kappa 架构

由 LinkedIn 的 Jay Kreps 针对 Lambda 的不足提出,核心思想:通过改进流计算系统解决数据全量处理问题,使实时计算和批处理过程使用同一套代码 。只有在必要时才对历史数据重复计算,方式是通过上游重放 (从数据源拉取数据重新计算)。本质是「基于流来处理所有数据」,通过加大流计算并发性、加大流式数据的「时间窗口」来统一批处理与流处理。

分为两个层次:

  • 流处理层 :负责对实时流数据处理计算,结果存到实时数据库或分布式文件系统。采用无状态流处理算法(不保存中间结果)。
  • 在线服务层:存储流处理后的实时数据与计算结果,既存实时数据也可存历史数据。

优点 :简化架构、降低维护成本、提高实时性与可伸缩性,适合实时性要求高的场景。

缺点 :无法支持批处理和离线分析;只有一个流处理层,数据存储成本可能较高。

3. IOTA 架构

IOTA 架构强调数据流的连续性和一致性 ,满足对数据一致性要求更高的场景。整体思路:设定标准数据模型,通过边缘计算技术把所有计算过程分散在数据产生、计算和查询过程中,以统一数据模型贯穿始终,可用各种即时查询(Ad-hoc Query)查询底层数据。

七大技术组成部分:

组成部分 作用
① 通用数据模型(Common Data Model) 贯穿业务始终的核心模型,使 SDK、cache、历史数据、查询引擎保持一致;可用「主---谓---宾」或「对象---事件」模型(如「X 用户---事件1---A 页面(时间)」),协议如 protobuf
② 边缘开发环境和边缘服务器(Edge SDKs & Edge Servers) 数据采集端,在设备端就转化为统一数据模型(如智能 Wi-Fi 采集 MAC、摄像头 Edge AI Server 采集 Face 特征)
③ 实时数据缓存区(Real Time Data) 存最近几分钟/几秒钟数据,用 Kudu、HBase 实现,由 Dumper 合并到历史数据
④ 历史数据沉浸区(Historical Data) 存大量历史数据,自动建索引实现秒级复杂查询百亿条数据,如用 HDFS
⑤ 数据导入组件(Dumper) 把实时数据按汇聚规则、建索引后写入历史存储(MapReduce、C、Scala 编写)
⑥ 查询引擎(Query Engine) 统一对外查询接口(SQL/JDBC),合并实时+历史数据查询(Presto、Impala、Clickhouse)
⑦ Realtime model feedback 通过边缘计算在边缘端交互控制 SDK(如降低上传频次、语音反馈、规则触发)

三大特点 :去 ETL 化 (通用数据模型从 SDK 端即计算,中央只做采集、建索引和查询)、即时查询 (事件发生即可查询,无需等 ETL/Streaming 处理)、边缘计算(计算分散到数据产生、存储、查询端,实时反馈)。

缺点:需对实时流和历史数据分别处理,增加复杂度和开发难度;两者结果可能存在不一致,需额外数据同步/一致性保证机制;高并发高吞吐场景硬件和管理成本高。

三大模式对比记忆:Lambda = 批 + 流 + 服务(三层);Kappa = 只流(两层,去批);IOTA = 统一模型 + 边缘计算(去 ETL)。


3 大数据处理系统开发

开发即「通过大数据技术构建大数据处理系统的过程」,核心是「选择实现技术」,基本原则是从内容、表示、功能分开考虑 ,并考虑分布式及与其他系统的交互、细粒度增量部署。与传统软件相比,最大特性来自强大的数据管理能力 。以下按数据存储、数据管理、数据处理、数据分析、系统部署展开。

3.1 数据存储

数据存储流程分四部分:数据采集 → 数据清洗 → 数据转换 → 数据存储。

1. 数据采集

  • 常用方法:系统日志采集、利用 ETL 工具采集、网络爬虫。
  • Web 服务器日志三种格式:公用日志文件格式、扩展日志格式、IIS 日志格式。
  • ETL = 数据抽取(Extract)、转换(Transform)、加载(Load)。
  • 网络爬虫四类:通用、聚焦、增量式、分布式网络爬虫。
  • 三种采集模式:
    • 离线采集:数据仓库语境下 ETL 是主要方式(非法数据监测过滤、格式转换规范化、数据替换、保证完整性)。
    • 实时采集 :用于流处理场景(网络监控流量管理、金融股票记账、Web 用户访问行为);数据采集成为 Kafka 的消费者 ,像水坝拦截上游数据,做去重/去噪/中间计算后写入存储,是流式 ETL;分布式架构,每秒可采集传输数百 MB 日志。
    • 互联网采集 :Scribe 是 Facebook 开发的数据(日志)收集系统(又称网页蜘蛛/网络机器人);网络流量采集可用 DPI / DFI 带宽管理技术。

2. 数据清洗

  • 数据清洗结果质量直接关系模型效果与最终结论 ,通常占据分析过程的 50%~80% 时间。
  • 五步骤 :
    1. 数据分析------前提和基础,人工或程序检测原始数据质量问题;
    2. 定义数据清洗的策略和规则------按数据源个数和「脏」数据程度定策略、选算法;
    3. 搜寻并确定错误实例 ------自动检测属性错误(方法:基于统计的方法、聚类方法、关联规则方法 )+检测重复记录(基本字段匹配算法、递归字段匹配算法);
    4. 纠正发现的错误 ------执行清洗转换步骤;先备份原始数据源;含属性分离、确认改正拼写错误(字典查询)、标准化(统一格式);
    5. 干净数据回流------干净数据替代「脏」数据,避免重复清洗。

3. 数据转换

  • 目的是把数据转换为可用格式,本质是 ETL 过程的一部分(映射到维度和度量,如维度=时间/地点/产品,度量=销售额/利润)。
  • 六步骤 :数据发现 → 数据映射(最耗时、最昂贵)→ 数据提取 → 代码生成(Python、R、SQL)→ 代码执行 → 数据审查。

4. 数据存储(重点:行存储 vs 列存储)

  • 关系数据库已不适应大数据存储计算要求,基本淘汰。已知软件中:Hadoop 的 HBase 采用列存储,MongoDB 是文档型行存储,Lexst 是二进制型行存储。
  • 列存储把存储对象「旋转 90 度」(同一列数据放一起),好处:①批量访问列数据时读取远快于行存储 (快 50~100 倍);②提高压缩比(同类数据相关性强,利于行程压缩等高效压缩)。
比较对象 行存储方式 列存储方式
优点 写入效率高,保证数据完整性 读取无冗余,适合数据定长的大数据计算
缺点 数据读取有冗余,影响计算速度 缺乏数据完整性保证,写入效率低
改进 优化存储格式,内存中快速删除冗余数据 多磁盘多线程并行读写(增加运营成本、改软件)
适用 MySQL 行存储适合 OLTP 列存储适合 OLAP
  • 行存储以「一行记录」为单位,列存储以「列数据集合(列族 Column Family)」为单位;列存储写入需把一行拆成多列,写入次数多、磁头移动耗时,故行存储写入占优。
  • HBase 采用列族方式平衡 OLTP 和 OLAP ,支持水平扩展;ES(Elasticsearch)默认对所有字段建索引,适合复杂检索或全文检索。

3.2 数据管理

数据管理是非功能模块 ,负责数据整体的稳定性和安全性,分四部分:元数据管理、数据关系图谱、数据安全、资源监控。

1. 元数据管理

  • 元数据 = 描述数据的数据,为数据提供上下文环境。
  • 分两类:技术元数据 (存储数据仓库技术细节,支持数据血缘追溯和影响分析)+业务元数据(描述业务含义、业务规则)。
  • 七种管理方式:数据源元数据、ETL 规则元数据、数据仓库元数据、报表元数据、接口文件格式元数据、商业元数据、其他元数据(数据访问日志、数据装载日志)。

2. 数据关系图谱

  • 记录数据之间的关联关系 和血缘关系。
  • 数据血缘:数据产生的链路,即数据怎么来的、经过哪些过程阶段。技术上「数据 a 通过 ETL 生成数据 b,则 a 与 b 有血缘关系」。
  • 血缘关系四个基本特征 :归属性 (数据归属特定组织/个人)、多源性 (一个数据可有多个来源)、可追溯性 (体现数据生命周期)、层次性(描述信息又形成新数据,形成层次)。
  • 数据挖掘(Data Mining) :从大量、不完全、有噪声、模糊、随机的数据中提取隐含的、事先不知道的、但潜在有用的信息和知识的过程。挖掘对象含关系数据库、面向对象数据库、数据仓库、文本数据源、多媒体数据库、空间数据库、时态数据库、异质数据库及 Internet。

3. 数据安全

  • 数据安全 = 认证 + 授权 。
    • 认证:对用户身份确认(账户密码、Kerberos 认证框架)。
    • 授权:定义用户可访问的资源(如张三不能访问 ods 层,可访问 dwd、dws 层;Java 的 RBAC 基于角色权限控制;大数据中 Sentry、Ranger 授权框架)。
  • 数据安全流程六环节:产生(分级打标签)→ 存储(加密存储)→ 使用(独立权限控制系统)→ 传输(专用 API + 高强度加密)→ 展示(按安全等级展示)→ 销毁(物理删除同步清理,仅 HDFS 逻辑删除不够)。
  • 数据仓库分层开放:对外一般开放 ads 层 ,可申请 dwd 层 ,但 ods 层原始数据不开放。
  • 表安全四等级:S4 (非核心表,删除无影响)→ S3 (非核心表,删除有影响)→ S2 (业务核心表,仅限本部门)→ S1(业务核心表,删除对其他部门有影响)。等级由低到高 S4→S1。

4. 资源监控

  • 大数据监控运维监控维度(表 19-2)七个:底层基础监控、服务状态监控、组件性能监控、Runtime 监控、集群指标监控、任务状态监控、趋势预测监控。
  • 总体分资源监控 和性能监控两方面;监控方式分三类:读取状态设阈值触发告警(CPU/内存)、时序聚合统计(HDFS 增量斜率过高触发)、多监控联动(同时满足条件触发)。

3.3 数据处理

数据类型三类 :结构化数据 (关系数据库数据,固定模式)、半结构化数据 (有一定结构但模式不固定,如 JSON、XML、HTML、日志文件)、非结构化数据(图片、视频、文本、语音)。

处理方式两类 :离线数据处理 (离线同步工具定时任务,全量/增量同步到 Hive)+实时数据处理(埋点、日志、binlog、nsq 消息同步到 Kafka)。

1. 实时计算处理

  • 用于处理流式数据,四个特点:数据源源不断到来;需尽快处理不积压;处理后数据量仍巨大(TB/PB 级);结果能尽快展现。归纳为「收集 → 传输 → 处理 → 展现」,处理与展现需秒级/毫秒级响应。
  • 经典技术架构:Flume + Kafka + Storm/Spark + HBase/Redis。
  • 流处理任务(Java/Python 编写)需 7×24h 不中断;流数据是「无界」的。

2. 离线计算处理(与实时对比,重点)

  • 核心区分标准:数据是否有界------有界即离线处理,无界即实时处理。
  • 批处理:数据先整体过第一阶段,得最终结果后再进下一阶段,任意时刻观察「所有数据同时处在某一阶段」;流处理像流水线工人,各阶段同时有数据。
  • 离线处理四个特点:数据量巨大且保存时间长;在大量数据上复杂批量运算;数据计算前已完全到位不变化;方便查询批量结果。
  • 常用离线同步工具:sqoop、datax ;同步工具抽象为 source → channel → sink 结构(channel 分内存、文件两种,起缓冲持久化作用)。
  • 离线处理技术:HDFS 存储 + MapReduce 批量计算 + Hive 数据仓库 。优点:可持续性(存储后可断网)、处理有界数据。

3. 图计算处理

  • 图的「图(Graph)」指表现事物关联关系的网络结构,非图片(Image)。
  • 应用:公安(打击犯罪团伙)、银行金融(金融欺诈、信用卡盗刷)、社交网络、理财推荐。
  • 图基本概念:
    • 基本组成 = 顶点 + 边 ;边有方向分有向图/无向图。
    • 无向图顶点边数 = 度 ;有向图出发边数 = 出度 ,汇集边数 = 入度。
    • 边构成闭合环 = 有环图 ,否则无环图(有环图算法需考虑终止条件)。
    • 两顶点间多条平行边 = 多重图 ;存在自环(指向自己)= 伪图(GraphX 的图都是伪图)。
    • 顶点/边含属性 = 属性图(GraphX 的图都是属性图),否则非属性图。
    • 顶点分两子集、边跨子集 = 二分图。
    • GraphX 用顶点属性表 VertexRDD + 边属性表 EdgeRDD 联合表示图。
  • 图算法三类:路径搜索算法 (DFS&BFS、最短路径、最小生成树、随机游走)、中心算法 (DegreeCentrality、ClosenessCentrality、BetweennessCentrality、PageRank)、社群发现算法(LabelPropagation、LouvainModularity 等)。
  • Spark 图计算由 Spark GraphX 提供。

3.4 数据分析

1. 机器学习

传统机器学习三类:

  • 监督学习:给算法数据集并给定正确答案,机器学习正确答案的计算方法。
  • 非监督学习(无监督学习):数据集无「正确答案」,任务是从数据集中挖掘潜在结构。
  • 强化学习:由**智能体(Agent)、环境(Environment)、状态(State)、动作(Action)、奖励(Reward)**组成;智能体执行动作 → 环境转换新状态并给奖励信号(正/负)→ 智能体按策略执行新动作,循环交互。

2. 搜索推荐(三大组件)

组件 定位与特点
Elasticsearch 基于 Lucene 的开源、分布式、RESTful 搜索引擎,支持 HTTP+JSON 索引;结合 Kibana、Logstash、Beats 构成 ELK(elastic stack);提供倒排索引 API,擅长海量搜索、分析、计算
Apache Solr 基于 Lucene 的 Java 全文搜索服务器,独立企业搜索应用服务器;以 Document 为对象存储,每个文档由 Field 构成,唯一标识默认字段名 id
Nutch Apache 旗下 Java 开源索引引擎项目,从中诞生 Hadoop、TIKA、GORA;开源透明、无排序黑箱

3. 数据可视化(四工具)

  • Silk:互动式表格/地图,比 Tableau 简单,可多人协作。
  • Tableau:侧重商业智能,制作散点图/柱状图/地图,无需编程。
  • Datawrapper:开源,几分钟创建嵌入式图形,有出色图形库。
  • Chartio:可视化查询语言,无需懂 SQL,可调度 PDF 报告,常不需要数据仓库。

3.5 系统部署

1. 部署分析(四个环节)

  • 需求分析 :了解上层业务特点;业务分离线业务(MapReduce)与在线业务(HBase);了解已有/增量数据量、保存时间。
  • 模型设计 :设计存储计算模型------目标数据离散、只需存储 → 单纯用 HDFS ;有外部查询、实时性高 → 用 HBase。
  • 硬件规划 :IP 规划、单节点性能;计算要求高则 CPU/内存高配、计算节点独立;存储要求高则加磁盘、多 DataNode 分担读写;磁盘按性能选 SAS / SATA / SSD ,用 RAID 提性能与可靠性;网络建议万兆网。
  • 软件规划:规划组件满足功能、实现高可用高可扩展;注意服务间依赖(如 HDFS 的 QJM 方式 HA 依赖 ZooKeeper)。

2. 部署原则(五类隔离)

  1. 生产环境和测试环境的隔离(物理隔离,独立运行互不干扰);
  2. 不同集群的隔离(同集群节点分散部署到不同机架,避免机架断电丢数据,每集群独立 HDFS);
  3. 在线应用和离线应用的隔离(重点在线应用单独规划 HBase 集群,独立 HDFS);
  4. 不同在线应用的隔离(重点在线应用独立 HDFS 物理隔离;一般在线应用可和离线应用同集群);
  5. 不同应用数据的隔离(同集群内用不同 HDFS 目录 + 目录权限配置隔离)。

3. 部署环境

  • 操作系统主要在 UNIX(如 Linux) 上部署;Windows 一般只用于开发测试。
  • 应用服务器需解决问题:集群规划 (主从模式)、网络配置 、安全配置 (SELinux、iptables/firewalld)、时间同步 (NTP 网络时间协议)、SSH 登录(Secure Shell,应用层安全协议)。

4. 版本控制

  • 优点:确保发布内容正确一致、控制跟踪变更、检验正确版本对应、失败可快速回滚、有变更历史容错强。
  • 工具:Git、SVN,以及大数据新提出的 DAGsHub、DVC、Pachyderm、lakeFS。

4 大数据处理系统测试

19.4.1 测试特点(五大挑战)

  1. 分布式环境(并行处理、数据分片、数据复制、分布式调度);
  2. 多样化的数据类型和格式(结构/半结构/非结构化);
  3. 实时和批处理(分别测试,关注数据流与处理管道正确性效率);
  4. 高性能和可扩展性(高负载、并发访问、横向扩展能力);
  5. 复杂的数据处理逻辑(清洗、转换、聚合、查询、机器学习)。

4.2 测试过程(三阶段)

  1. 测试需求分析(大数据量大、价值密度低,前期需求/数据分析极重要,否则选错数据源直接影响结果,需大量评审讨论);
  2. 测试计划和方案(划分测试重点与优先级,对重要数据优先测试);
  3. 测试用例分析和设计 (关注提取/处理/存储/迁移过程;尤为关注有效数据设计------「100 条无效数据不如一条有效数据」)。

4.3 功能测试

测试项 要点
数据提取测试 查询过滤、数据分区分片、聚合统计、排序分组、多表关联
数据处理测试 数据清洗预处理、数据转换格式化、数据聚合汇总、数据分析挖掘
数据存储测试 存储容量扩展性、写入读取、数据冗余备份、一致性完整性、压缩优化
数据迁移测试 导出导入、格式兼容性、迁移速度性能、一致性完整性、监控日志、回滚恢复
其他 任务调度和控制、用户界面和交互

4.4 性能测试

主要目标:数据规模和负载、吞吐量和响应时间、扩展性和负载均衡、并行处理和分布式计算、高可用性和容错性。

  • 负载测试工具:Apache JMeter、Gatling;监控诊断:Hadoop 监控工具、日志分析工具及第三方工具。

4.5 可靠性和容错性测试

  • 可能故障:计算节点故障、网络故障、存储故障。
  • 可靠性测试目标:验证正常/异常下数据完整性和一致性(备份恢复、故障检测修复、一致性验证)。
  • 容错性测试目标:验证故障时自动恢复能力。
  • 六种方法策略:故障注入测试、容错恢复测试、故障切换测试、数据一致性测试、容量和负载测试、自动化监控和恢复测试。

4.6 安全性测试

八大方面:

  1. 访问控制测试(用户认证、授权、权限管理、特权访问、角色组管理、多因素认证、会话管理、安全审计);
  2. 数据保护测试(数据加密 SSL/TLS、数据脱敏、备份恢复、访问控制、传输安全、完整性、销毁、第三方组件);
  3. 漏洞扫描和渗透测试(漏洞扫描 → 渗透测试计划 → 渗透测试);
  4. 弱密码测试(密码猜测、字典攻击、弱密码策略、默认密码、账户锁定、加固建议);
  5. 防火墙和网络安全测试;
  6. 安全日志和监控测试(安全日志、日志分析、实时监控、事件响应、异常检测、监控数据保护、安全审计);
  7. 安全策略和合规性测试(如 GDPR、HIPAA);
  8. 社会工程学测试(模拟钓鱼、欺骗、社交工程)。

4.7 兼容性测试

验证系统与不同硬件、软件、环境组件的集成互操作性,关注七方面:硬件兼容性、操作系统兼容性、数据库兼容性、第三方组件兼容性、文件格式兼容性(CSV、JSON、Parquet)、API 兼容性、平台兼容性(AWS/Azure 云、Docker/Kubernetes 容器)。


三、常考点(按考察频率从高到低)

1. 大数据的 4V 特性 ★★★

选择题高频。考察 4V 各自的英文与中文对应(Volume 数据量大、Variety 数据类型多样、Velocity 产生与处理速度快、Value 价值高)。答题要点:注意区分「Velocity=速度」「Variety=多样」「Volume=量大」「Value=价值」,勿混淆。

2. Lambda / Kappa / IOTA 三种架构 ★★★

选择题、案例分析均可能出。考察各自层次组成、支撑技术、优缺点。答题要点:Lambda 三层(批处理/加速/服务)+技术(Hive/Spark、Storm/Flink、Kylin/Presto);Kappa 两层(流处理/在线服务)、去批处理;IOTA 统一数据模型+边缘计算、去 ETL。牢记「谁提出 Kappa(Jay Kreps)」「Lambda 解决什么问题」。

3. 批处理 vs 流处理(及离线 vs 实时)★ ★★

选择题、案例分析高频。核心区分「有界=离线=批处理,无界=实时=流处理」。答题要点:批处理四模块、吞吐量高实时性低;流处理低延迟但无法处理历史数据;混合架构用 Spark 兼顾。务必能举例对应技术(MapReduce/Spark vs Flink/Storm)。

4. 行存储 vs 列存储 ★★★

选择题高频。考察优缺点、适用场景、代表产品(HBase 列存储、MongoDB 文档型行存储、Lexst 二进制型行存储、MySQL 行存储适合 OLTP、列存储适合 OLAP)。答题要点:行存储写入快、保完整性;列存储读取无冗余、适合定长大数据计算、压缩比高。

5. ETL 与数据清洗、数据转换流程 ★★

选择题、案例分析。考察 ETL 三词(Extract/Transform/Load)、数据清洗五步骤、数据转换六步骤、数据清洗占 50%--80% 时间。答题要点:记住顺序,区分「数据清洗五步」与「数据转换六步」是两套不同流程。

6. 大数据架构六大设计原则 ★★★

选择题高频。考察「可扩展、可管理、数据安全、高性能、高可用、稳定性」及各自实现手段(如自动故障转移用 ZooKeeper/Keepalived/Pacemaker、负载均衡用 Haproxy/Nginx/LVS)。答题要点:逐条对应实现要点,勿张冠李戴。

7. 数据安全与数据血缘 ★★

选择题、案例分析。考察「数据安全=认证+授权」、认证(Kerberos)与授权(Sentry/Ranger、RBAC)区别、数据血缘四特征(归属性/多源性/可追溯性/层次性)。答题要点:认证管「你是谁」,授权管「你能访问什么」。

8. 数据采集三模式与数据类型 ★★

选择题。考察离线/实时/互联网采集(Kafka 消费者、Scribe)、结构化/半结构化/非结构化数据分类(JSON/XML/日志属半结构化)。答题要点:半结构化「有结构但模式不固定」。

9. 图计算基本概念 ★★

选择题。考察图基本组成、有向/无向、度/出度/入度、属性图、GraphX 用 VertexRDD+EdgeRDD。答题要点:区分「出度=出发边数、入度=汇集边数」。

10. 大数据测试的类型与要点 ★★

选择题、案例分析。考察测试特点(分布式、多样化类型、实时批处理)、功能测试四块(提取/处理/存储/迁移)、性能测试指标、可靠性容错性测试方法(故障注入等)。答题要点:区分性能测试(吞吐量/响应时间)与可靠性测试(容错/恢复)。


四、易混点(概念对对比)

1. 批处理(离线) vs 流处理(实时)

维度 批处理(离线处理) 流处理(实时处理)
定义 数据按固定时间间隔/触发条件批量处理 数据连续、无限制地流式处理,每条到达即处理
数据特征 有界(数据已完全到位不变化) 无界(源源不断产生)
实时性 实时性差、延迟高 低延迟、实时反馈
吞吐量 吞吐量高、稳定 快速响应但可能漏数据
典型技术 MapReduce、Spark、Hive、HDFS Flink、Storm、Spark Streaming、Kafka
典型场景 数据仓库、搜索检索、图计算、数据分析 实时数仓、实时监控、实时推荐、流上机器学习

联系 :二者是同一系统按「数据是否有界」划分的两种处理方式;混合架构(Spark)同时支持两者。

记忆口诀 :「有界批,无界流;离线算仓库,实时看监控」。

2. Lambda 架构 vs Kappa 架构

维度 Lambda 架构 Kappa 架构
层次 三层:批处理层 + 加速层 + 服务层 两层:流处理层 + 在线服务层
核心思想 批流分离、各自独立、资源隔离 批流同一套代码,基于流处理所有数据
对历史数据的处理 批处理层存全量数据、预计算视图 需要时通过上游重放重复计算
优点 同时支持批+流,最成熟稳定、吞吐高 简化架构、维护成本低、实时性可伸缩性好
缺点 多层存储、复杂、数据冗余、成本高 无法支持批处理/离线分析
提出者 --- LinkedIn 的 Jay Kreps

联系 :Kappa 是针对 Lambda 的不足 提出的改进,二者都是主流大数据架构模式。

记忆口诀 :「Lambda 三明治(批+流+服务),Kappa 单流(只流不批)」。

3. 认证 vs 授权(数据安全 = 认证 + 授权)

维度 认证(Authentication) 授权(Authorization)
定义 对用户身份的确认 定义用户可访问的资源
回答的问题 「你是谁」 「你能访问什么」
典型实现 账户+密码、Kerberos RBAC 基于角色、Sentry、Ranger
示例 登录 MySQL 需用户名密码 张三不能访问 ods 层,可访问 dwd/dws 层

联系 :认证在前、授权在后,二者共同构成数据安全体系(数据安全 = 认证 + 授权)。

记忆口诀 :「先认证(验身份),后授权(分资源)」。

4. 技术元数据 vs 业务元数据(补充易混)

维度 技术元数据 业务元数据
定义 关于数据仓库技术细节的数据 描述数据的业务含义、业务规则
服务对象 开发人员 业务/数据应用人员
作用 明确存储结构、厘清数据关系、支持血缘追溯与影响分析 为数据应用提供更好的服务

联系 :二者都是「描述数据的数据」(元数据),共同支撑数据治理。

记忆口诀 :「技术看结构,业务看含义」。

5. 有向图「出度/入度」 vs 无向图「度」(补充易混)

概念 适用图 含义
度 无向图 一个顶点上边的数量
出度 有向图 从该顶点出发的边的数量
入度 有向图 汇集到该顶点的边的数量

记忆口诀 :「出=出去,入=进来;无向只有一个度」。


五、备考提示

1. 复习优先级建议

  • 第一优先级(必背):4V 特性;Lambda/Kappa/IOTA 三架构;批处理 vs 流处理(有界/无界);行存储 vs 列存储;六大架构原则。这五块是选择题的「送分/失分」重灾区。
  • 第二优先级(理解):数据清洗五步骤、数据转换六步骤、ETL、数据采集三模式、数据类型三类、图计算概念、数据安全=认证+授权、数据血缘四特征。
  • 第三优先级(略读带过):数据分析三大组件/四工具、部署分析四环节与部署五原则、版本控制工具、测试各类型细节。

2. 记忆技巧

  • 4V :量大(Volume)、多样(Variety)、快(Velocity)、价值(Value)------记「大、多、快、值」。
  • 六大原则 :扩、管、安、能、用、稳------「扩管安能用稳」。
  • 高性能四手段 / 高可用三手段:「高能→分算并内(分区、分布式、并行、内存)」「高用→冗转负(冗余、转移、负载)」。
  • Lambda 三层 :批、速、服------「批服速 」;Kappa 两层 :流、服------「流服」。
  • 数据血缘四特征 :归、多、追、层------「归多追层」。
  • 清洗五步 / 转换六步用「第一步分析/发现、最后回流/审查」锚定首尾,中间靠理解顺推。

3. 跨章节关联

  • 与第 8 章(系统设计)/软件架构设计关联:本章的 Lambda/Kappa/IOTA 是「架构风格/模式」在大数据场景的具体化,论文与案例分析中可与「架构权衡分析法(ATAM)」「架构设计决策」结合论述。
  • 与数据仓库、BI、OLTP/OLAP相关章节关联:行存储适合 OLTP、列存储适合 OLAP,与数据仓库分层(ods/dwd/dws/ads)可串讲。
  • 与安全性、测试相关章节关联:本章数据安全(认证+授权)、测试类型(功能/性能/可靠性/安全/兼容)与软件工程通用测试方法论衔接,论文中可引用「大数据系统的非功能性需求(安全性、可靠性、可扩展性)验证」。

4. 出题规律与趋势

  • 上午选择题 :本章是「大数据」专题的主力出题章,历年高频集中在「4V」「架构模式层次」「批流区别」「行/列存储」四处,多考概念辨析与对应关系(如「下列哪个是 Lambda 的加速层技术」)。
  • 下午案例分析 :倾向给出一个大数据业务场景(实时监控/离线分析/批流结合),要求考生选择合适架构、说明理由、指出部署或测试要点,常考「Lambda 与 Kappa 的取舍」「生产/测试环境隔离」。
  • 论文:可作为「大数据平台 / 数据中台建设 / 数据治理」类论文的技术骨架,重点引用**Lambda/Kappa 架构、批流一体、数据血缘、行/列存储选型、数据安全(认证+授权)**等素材。
  • 趋势 :随着「批流一体」「实时数仓」热度上升,Kappa 架构与实时计算(Flink) 的考察比重有上升趋势,建议对「Kappa 通过上游重放统一批流」的理解加深一层。
相关推荐
xy34538 天前
2026软考软件评测师题目记忆版
软考·软件评测师
Gyr010 天前
浅刷了一遍51CTO软考题库客观题及其解析(4)
学习·软考·知识点·信息安全工程师
夜听莺儿鸣10 天前
901-011_系统分析师基础知识-系统规划与分析
软考·系统分析·系统分析师·系统规划
Gyr010 天前
浅刷了一遍51CTO软考题库客观题及其解析(5)
学习·软考·知识点·信息安全工程师
空空潍10 天前
2026年软考中级软件设计师(二):数据结构
数据结构·软考·软件设计师·软设
妈妈炒的菜11 天前
软考-系统架构设计师
系统架构·软考·系统架构设计师·高级软考
Gyr011 天前
浅刷了一遍51CTO软考题库客观题及其解析(3)
软考·知识点·信息安全工程师·学校
夜听莺儿鸣12 天前
901-007_系统分析师基础知识-企业信息化
软考·企业信息化·系统分析师
帅次18 天前
软考中项第2章:信息技术发展,核心知识点与备考重点
项目管理·软考·系统集成项目管理工程师·软考中项