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 通过上游重放统一批流」的理解加深一层。
相关推荐
佛祖让我来巡山1 天前
系统架构师基础知识点概览汇总
软考高级·软考·系统架构师
无心水5 天前
22、数学与经济管理(运筹学) 核心考点与学习笔记
人工智能·笔记·学习·架构师·软考·软考架构师·软考系统架构师
无心水9 天前
15、云原生架构设计理论与实践 核心考点与学习笔记
笔记·学习·云原生·架构师·软考·系统架构设计师·软考系统架构设计师
无心水11 天前
6、软件工程 核心考点与学习笔记
笔记·学习·软件工程·软考高级·架构师·软考·软考系统架构设计师
无心水11 天前
5、信息安全技术基础知识 核心学习笔
人工智能·学习·软考高级·架构师·软考·高级架构师·软考架构师
无心水11 天前
8、系统架构设计基础知识 核心考点与学习笔记
笔记·学习·系统架构·架构师·软考·软考架构师·软考高级架构师
Misnearch13 天前
第7章 面向对象技术
java·开发语言·软考
鱼头研学社18 天前
在职备考高项报班避坑:“客服说加微信发报价“到“官网自助下单“,中间差了啥
项目管理·软考·高项·备考
zlp19921 个月前
软考(系统架构师)-案例分析之大模型ReAct与Plan-and-Execute
软考高级·软考·系统架构师·软考备考
抓到一只狗1 个月前
系统分析师——统一建模语言
软件工程·uml·类图·用例图·系统分析师·顺序图·高级软考