一、本章知识框架
大数据处理系统分析与设计
├── 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 |
| 组成模块 | 数据采集、数据存储、数据处理、数据输出 | 数据流 + 运算符 | 兼具批、流两种能力 |
| 优点 | 处理大规模数据,吞吐量高、稳定性好、充分利用计算资源 | 低延迟、实时反馈、快速响应、适应数据快速变化 | 兼顾历史数据与实时数据,快速响应 |
| 缺点 | 实时性差,无法满足实时分析 | 无法处理历史数据、可能漏数据、需考虑并发与一致性 | 需权衡、管理和维护成本更高 |
批处理架构详解 :任务通常在离线模式 下执行,吞吐量高、实时性低。四个核心模块:
- 数据采集:把原始数据从不同来源收集到集中式存储(文件传输、日志收集、数据接口)。
- 数据存储:存原始数据、中间结果、最终结果(关系型数据库、分布式文件系统、NoSQL 数据库)。
- 数据处理(核心):对原始数据加工分析,用 MapReduce、Spark 等分布式计算。
- 数据输出:结果输出到存储或数据仓库。
批处理触发时机可用预定时间间隔 (如每 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% 时间。
- 五步骤 :
- 数据分析------前提和基础,人工或程序检测原始数据质量问题;
- 定义数据清洗的策略和规则------按数据源个数和「脏」数据程度定策略、选算法;
- 搜寻并确定错误实例 ------自动检测属性错误(方法:基于统计的方法、聚类方法、关联规则方法 )+检测重复记录(基本字段匹配算法、递归字段匹配算法);
- 纠正发现的错误 ------执行清洗转换步骤;先备份原始数据源;含属性分离、确认改正拼写错误(字典查询)、标准化(统一格式);
- 干净数据回流------干净数据替代「脏」数据,避免重复清洗。
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. 部署原则(五类隔离)
- 生产环境和测试环境的隔离(物理隔离,独立运行互不干扰);
- 不同集群的隔离(同集群节点分散部署到不同机架,避免机架断电丢数据,每集群独立 HDFS);
- 在线应用和离线应用的隔离(重点在线应用单独规划 HBase 集群,独立 HDFS);
- 不同在线应用的隔离(重点在线应用独立 HDFS 物理隔离;一般在线应用可和离线应用同集群);
- 不同应用数据的隔离(同集群内用不同 HDFS 目录 + 目录权限配置隔离)。
3. 部署环境
- 操作系统主要在 UNIX(如 Linux) 上部署;Windows 一般只用于开发测试。
- 应用服务器需解决问题:集群规划 (主从模式)、网络配置 、安全配置 (SELinux、iptables/firewalld)、时间同步 (NTP 网络时间协议)、SSH 登录(Secure Shell,应用层安全协议)。
4. 版本控制
- 优点:确保发布内容正确一致、控制跟踪变更、检验正确版本对应、失败可快速回滚、有变更历史容错强。
- 工具:Git、SVN,以及大数据新提出的 DAGsHub、DVC、Pachyderm、lakeFS。
4 大数据处理系统测试
19.4.1 测试特点(五大挑战)
- 分布式环境(并行处理、数据分片、数据复制、分布式调度);
- 多样化的数据类型和格式(结构/半结构/非结构化);
- 实时和批处理(分别测试,关注数据流与处理管道正确性效率);
- 高性能和可扩展性(高负载、并发访问、横向扩展能力);
- 复杂的数据处理逻辑(清洗、转换、聚合、查询、机器学习)。
4.2 测试过程(三阶段)
- 测试需求分析(大数据量大、价值密度低,前期需求/数据分析极重要,否则选错数据源直接影响结果,需大量评审讨论);
- 测试计划和方案(划分测试重点与优先级,对重要数据优先测试);
- 测试用例分析和设计 (关注提取/处理/存储/迁移过程;尤为关注有效数据设计------「100 条无效数据不如一条有效数据」)。
4.3 功能测试
| 测试项 | 要点 |
|---|---|
| 数据提取测试 | 查询过滤、数据分区分片、聚合统计、排序分组、多表关联 |
| 数据处理测试 | 数据清洗预处理、数据转换格式化、数据聚合汇总、数据分析挖掘 |
| 数据存储测试 | 存储容量扩展性、写入读取、数据冗余备份、一致性完整性、压缩优化 |
| 数据迁移测试 | 导出导入、格式兼容性、迁移速度性能、一致性完整性、监控日志、回滚恢复 |
| 其他 | 任务调度和控制、用户界面和交互 |
4.4 性能测试
主要目标:数据规模和负载、吞吐量和响应时间、扩展性和负载均衡、并行处理和分布式计算、高可用性和容错性。
- 负载测试工具:Apache JMeter、Gatling;监控诊断:Hadoop 监控工具、日志分析工具及第三方工具。
4.5 可靠性和容错性测试
- 可能故障:计算节点故障、网络故障、存储故障。
- 可靠性测试目标:验证正常/异常下数据完整性和一致性(备份恢复、故障检测修复、一致性验证)。
- 容错性测试目标:验证故障时自动恢复能力。
- 六种方法策略:故障注入测试、容错恢复测试、故障切换测试、数据一致性测试、容量和负载测试、自动化监控和恢复测试。
4.6 安全性测试
八大方面:
- 访问控制测试(用户认证、授权、权限管理、特权访问、角色组管理、多因素认证、会话管理、安全审计);
- 数据保护测试(数据加密 SSL/TLS、数据脱敏、备份恢复、访问控制、传输安全、完整性、销毁、第三方组件);
- 漏洞扫描和渗透测试(漏洞扫描 → 渗透测试计划 → 渗透测试);
- 弱密码测试(密码猜测、字典攻击、弱密码策略、默认密码、账户锁定、加固建议);
- 防火墙和网络安全测试;
- 安全日志和监控测试(安全日志、日志分析、实时监控、事件响应、异常检测、监控数据保护、安全审计);
- 安全策略和合规性测试(如 GDPR、HIPAA);
- 社会工程学测试(模拟钓鱼、欺骗、社交工程)。
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 通过上游重放统一批流」的理解加深一层。