大数据测试总结

总结测试要点：
参考产品文档，技术文档梳理以下内容

需求来源

业务方应用场景

数据源，数据格转，数据产出，数据呈现方式（数据消亡史），数据量级（增量，全量），更新频率，数据产出时效

数据流转方式（http接口，GRPC接口，中间表，宽表等）

数据多样性（不同类型维度的处理数据，例如被标识的维度数据以用户为例: 客户，客服，用户，玩家等）

使用数据的频次频率（相对应的查询服务数据库的压力，接口服务器的压力，评测是否需压测及调优）

游戏BI报表的测试需以数据准确为核心，结合业务规则验证、性能压测、安全审计，并关注用户体验。通过自动化工具减少重复工作量，最终确保报表成为业务决策的可靠依据。

针对游戏业务的数据BI报表（如用户活跃、付费分析、留存率等），测试需覆盖数据准确性、实时性、多维度分析能力及用户体验。以下是核心测试重点：

一、数据准确性验证

源数据完整性验证数据采集是否完整（如日志埋点是否覆盖所有关键事件：登录、付费、任务完成等）。测试方法：比对原始日志（Kafka/RabbitMQ）与数据仓库（Hive/DW）的记录数、字段值是否一致。

ETL逻辑正确性确保清洗、转换规则正确（如去重、异常值处理、时区转换）。示例测试：验证“付费金额”是否按汇率转换为统一货币（如USD），过滤测试环境脏数据。

计算指标正确性核心指标公式验证（如DAU、ARPU、LTV）：sql复制-- DAU（日活跃用户） SELECT COUNT(DISTINCT user_id) FROM user_login WHERE dt='2023-10-01'; -- ARPU（平均每用户收入） SELECT SUM(revenue)/COUNT(DISTINCT user_id) FROM payment WHERE dt='2023-10-01'; 测试方法：用小规模测试数据集手工计算，比对BI工具输出结果。

跨表关联一致性验证多表JOIN的正确性（如用户表+付费表+行为表）。典型问题：用户ID映射错误导致数据错位。

二、实时性测试

数据延迟验证T+1报表的截止时间（如当日凌晨2点生成昨日数据），实时看板延迟是否≤1分钟。测试工具：注入带时间戳的测试事件，监控Kafka→Flink→BI的端到端延迟。

增量更新机制验证新增数据是否实时刷新（如玩家付费后，看板GMV是否立即更新）。测试场景：模拟玩家在整点前完成付费，检查整点统计是否包含该订单。

三、多维度分析能力

维度组合正确性测试按时间（日/周/月）、渠道（iOS/Android）、地区、用户分层（VIP/普通）等维度的下钻/上卷结果。示例问题：按“渠道+地区”筛选时，数据聚合错误导致iOS用户数被重复计算。

过滤条件覆盖性验证复杂过滤条件（如“付费金额>100且等级≥30的用户”），结果是否精确。边界测试：空值（NULL）、极值（0付费用户）的处理是否符合预期。

时间窗口灵活性支持自定义时间段（如近7天、自然周、活动周期），验证跨天数据是否连续。典型错误：跨自然周查询时，周累计数据未正确拼接。

四、性能与稳定性

查询响应时间设定性能基线（如简单查询≤3秒，复杂多表JOIN≤30秒），压测高并发场景（100用户同时查询）。优化方向：检查数据仓库索引、Presto/Spark资源分配。

大数据量承载能力模拟亿级用户数据，验证报表加载不超时、不崩溃。测试工具：使用JMeter生成大规模查询请求。

容错与恢复断网或服务宕机后，验证数据补刷机制是否正常（如补跑Flink作业修复缺失分区）。日志监控：确保ETL失败时告警及时触发（如集成Prometheus+Alertmanager）。

五、安全与权限控制

数据权限隔离验证不同角色（运营、策划、客服）仅能访问授权数据（如分区限制、字段脱敏）。测试案例：客服账号查询报表时，隐藏“用户手机号”等敏感字段。

SQL注入防护模拟恶意输入（如' OR 1=1 --），验证BI前端是否过滤异常参数。

六、用户体验与展示

可视化准确性图表与数据表的数值一致性（如折线图峰值对应表格中的最大值）。常见问题：前端四舍五入导致总计数值与明细求和不等。

交互友好性测试筛选、排序、导出功能是否正常，页面加载无卡顿。移动端适配：报表在手机/Pad上的显示效果（如表格自适应、图表可缩放）。

什么是hive

Hive的核心特点，比如使用HQL，底层是MapReduce或Tez，数据存储在HDFS。还要提到Hive的优缺点，比如适合批处理，延迟高，不适合实时查询。

Hive 的核心特点

基于Hadoop数据存储在HDFS（Hadoop分布式文件系统）中，计算依赖MapReduce、Tez或Spark引擎。适合处理批量数据（如日志、历史记录），但延迟较高（分钟级响应），不适用于实时场景。

类SQL接口（HiveQL）支持SELECT、JOIN、GROUP BY等SQL操作，但对复杂事务支持有限（如不支持行级更新）。示例HQL语句：sql复制CREATE TABLE user_behavior ( user_id INT, action STRING, timestamp BIGINT ) STORED AS ORC;

元数据管理使用Metastore（通常基于MySQL或PostgreSQL）存储表结构、分区等信息，与数据文件分离。

数据存储优化支持分区（按日期、地区等分割数据）和分桶（哈希分桶加速查询），提升查询效率。文件格式优化：如ORC（列式存储）、Parquet（高效压缩）。

Hive 的架构

用户接口Hive CLI、Beeline（JDBC客户端）、Hue（Web UI）。

驱动引擎解析HQL为MapReduce/Tez/Spark任务，提交到Hadoop集群执行。

元存储（Metastore）存储表结构、字段类型、分区信息等元数据。

执行引擎默认使用MapReduce，可替换为Tez（DAG优化）或Spark（内存计算）提升性能。

Hive 的应用场景

离线数据分析如日志分析、用户行为统计（例如：统计每日活跃用户数）。

ETL（数据清洗转换）将原始数据转换为结构化数据，供下游BI工具（如Tableau）使用。

数据仓库构建企业级数据仓库（如分层存储：ODS层→DWD层→DWS层）。

Hive vs 传统关系型数据库

特性	Hive	传统数据库（如MySQL）
数据规模	PB级	TB级以下
延迟	高（分钟~小时级）	低（毫秒~秒级）
事务支持	有限（Hive 3.0后支持ACID）	完整支持
存储与计算	分离（数据在HDFS，计算在集群）	紧耦合（本地存储+计算）
适用场景	批处理、历史数据分析	实时事务、高频更新

什么是Spark

一、Spark 任务的核心概念

任务（Task）定义：一个 Task 对应一个数据分区的计算逻辑（例如 map、filter、reduce 等操作）。并行度：任务数量由数据的分区数决定。例如，一个 RDD 有 100 个分区，则会生成 100 个 Task。执行位置：由 Executor 进程在集群节点上运行。

任务层级关系Application：用户编写的完整 Spark 程序（如一个 ETL 作业）。Job：一个 Action 操作触发一个 Job（例如 collect()、saveAsTextFile()）。Stage：Job 按 Shuffle 依赖划分为多个 Stage（例如 Stage 0 和 Stage 1）。Task：Stage 内的并行计算单元，每个 Stage 对应一组 Task。复制Application → Jobs → Stages → Tasks

二、Spark 任务的生命周期

任务生成Driver 程序根据 RDD 的血缘关系（Lineage）生成逻辑执行计划。DAGScheduler 将逻辑计划按 Shuffle 边界切分为 Stage，并为每个 Stage 生成 TaskSet。

任务调度TaskScheduler 将 Task 分配到 Executor 的空闲核心（Core）上。本地性优先：优先将 Task 调度到数据所在的节点（HDFS 数据本地性）。

任务执行Executor 加载 Task 代码（闭包序列化）并处理数据分区。结果返回 Driver 或写入存储系统（如 HDFS、S3）。

容错机制失败 Task 自动重试（默认重试 4 次）。Stage 重算：若某个 Task 失败且重试无效，则重新计算整个 Stage。

三、任务的关键特性

内存计算Task 优先在内存中处理数据，减少磁盘 I/O（相比 MapReduce 快 10~100 倍）。

闭包序列化Task 的代码和变量会被序列化后发送到 Executor（需确保闭包中的对象可序列化）。

Shuffle 机制Stage 之间的数据交换（如 groupByKey、join）会触发 Shuffle，产生磁盘和网络开销。

四、Spark 任务的调度机制

调度模式FIFO（默认）：先进先出，适合批处理。FAIR：公平调度，支持多任务资源均衡。

资源分配每个 Task 占用一个 Core，内存由 spark.executor.memory 和 spark.memory.fraction 配置。

动态分配启用 spark.dynamicAllocation.enabled 后，根据任务负载自动增减 Executor。

五、测试工程师的关注点

任务正确性验证数据断言：验证 Task 处理后的数据是否符合预期（例如：使用 assert(df.count() == 1000)）。血缘关系检查：确认 RDD/DataFrame 的血缘关系是否合理（避免冗余计算）。

任务性能测试执行时间：监控单个 Task 的耗时（通过 Spark UI 的 Task Duration 指标）。数据倾斜检测：识别某些 Task 处理时间远高于其他 Task（例如：某 Task 处理 90% 的数据）。scala复制// 查看各分区数据量 df.rdd.mapPartitionsWithIndex{ case (i, rows) => Iterator((i, rows.size)) }.collect()

容错性测试模拟故障：强制终止 Executor 进程，观察 Task 是否自动重新调度。重试策略验证：修改 spark.task.maxFailures 参数，测试重试机制是否生效。

资源利用监控内存溢出：检查是否因 Executor 内存不足导致 Task 失败（OutOfMemoryError）。GC 调优：通过 -XX:+UseG1GC 优化垃圾回收，减少 Task 暂停时间。

任务依赖测试窄依赖 vs 宽依赖：验证 Stage 划分是否符合预期（宽依赖会触发 Shuffle）。

六、实战示例

场景：测试一个 Spark 聚合任务

任务描述输入：用户行为日志（1 亿条数据，100 个分区）。处理：按用户 ID 分组统计点击次数。输出：写入 HDFS。

测试步骤步骤 1：数据正确性用小数据集（如 1000 条）运行任务，比对结果与手工计算结果。步骤 2：性能基准测试记录任务总耗时，监控各 Stage 的 Task 执行时间分布。步骤 3：数据倾斜注入插入一个超级用户（占 50% 数据量），观察 Task 执行时间是否显著增加。步骤 4：容错测试手动 Kill 一个 Executor，验证任务是否自动恢复并完成。

七、总结

Spark 任务是分布式计算的基石，理解其生成、调度和执行机制是优化和测试的关键。

测试重点：数据正确性、性能（尤其是倾斜问题）、容错性、资源利用率。

工具辅助：利用 Spark UI、History Server 和日志分析任务行为，结合 JVM Profiler 进行深度调优。

什么是presto引擎

Presto 是一款 开源的分布式 SQL 查询引擎，由 Facebook（现 Meta）开发并开源，专为交互式分析和跨数据源查询设计。它能够高效查询从 GB 到 PB 级的数据，支持多种数据源（如 Hive、MySQL、Kafka、S3 等），且不依赖 MapReduce，直接通过内存计算实现快速响应（秒级到分钟级）。以下是 Presto 的详细解析：

一、Presto 的核心特性

分布式 MPP 架构基于 Massively Parallel Processing（大规模并行处理） 架构，将查询拆分为多个任务在集群节点中并行执行。适合低延迟的交互式查询（如 BI 工具直接连接 Presto）。

多数据源联邦查询通过 Connector 机制支持异构数据源（如同时 JOIN Hive 表和 MySQL 表）。示例：从 Hive 查询用户行为日志，从 MySQL 拉取用户画像，直接进行关联分析。

内存计算与流水线执行数据在处理时通过流水线（Pipeline）在内存中传递，减少磁盘 I/O。相比 Hive（依赖 MapReduce 的磁盘读写），性能提升 5~10 倍。

ANSI SQL 兼容支持标准 SQL 语法和复杂查询（窗口函数、CTE、子查询等），学习成本低。

弹性扩展可动态增加或减少 Worker 节点，适应查询负载变化。

二、Presto 的架构

Coordinator（协调节点）负责接收 SQL 请求，解析查询，生成执行计划，调度任务到 Worker。维护元数据（通过 Connector 获取数据源的表结构）。

Worker（工作节点）执行 Coordinator 分配的任务（如数据扫描、过滤、聚合）。每个 Worker 处理数据的一个分片（Split）。

Connector（连接器）对接不同数据源（如 Hive Connector 读取 HDFS，JDBC Connector 连接 MySQL）。关键接口：getSplits()（定义数据分片）、getPageSource()（读取数据）。

Discovery Service（服务发现）Worker 节点启动时向 Discovery Service 注册，Coordinator 通过它感知 Worker 状态。

三、Presto 的应用场景

交互式 BI 分析连接 Tableau、Superset 等工具，支持实时数据探索。示例：分析师直接查询 PB 级数据湖（如 AWS S3）生成报表。

跨数据源联合查询无需数据迁移，直接 JOIN 不同存储系统的数据（如 Hive + Kafka + PostgreSQL）。

数据湖查询引擎查询存储在 HDFS/S3 上的开放格式数据（Parquet、ORC、JSON）。

实时数仓补充对 ClickHouse/Druid 等实时引擎无法处理的复杂 SQL 进行补充查询。

四、Presto 与其他引擎的对比

特性	Presto	Hive	Spark SQL
计算模型	MPP（内存优先）	MapReduce（磁盘优先）	微批处理（内存+磁盘）
延迟	秒级~分钟级	分钟级~小时级	秒级~小时级（依赖场景）
数据源支持	多数据源联邦查询	主要 HDFS/Hive	多数据源，但需通过 DataFrame API
适用场景	交互式分析、即席查询	离线批处理	ETL、批处理、流处理（Structured Streaming）

五、测试工程师的关注点

查询正确性验证比对 Presto 与其他引擎（如 Hive、Spark SQL）的查询结果是否一致。验证跨数据源 JOIN 的数据准确性（如 Hive 表与 MySQL 表关联结果）。

性能测试并发查询能力：模拟多用户同时发起查询，监控吞吐量和延迟。大表 JOIN 优化：测试是否因数据倾斜导致某些 Worker 负载过高。资源监控：观察 CPU/内存使用率，避免 OOM（通过 presto-memory 配置堆外内存）。

容错性测试模拟 Worker 节点宕机，验证查询是否自动重试或失败处理。测试查询超时（query.max-run-time）和重试策略。

多数据源兼容性验证不同 Connector 的兼容性（如 Hive 分区表、Kafka 实时 Topic）。测试权限控制（如 Kerberos 认证的 Hive 数据源访问）。

SQL 语法覆盖覆盖复杂 SQL 场景（如窗口函数、嵌套子查询、JSON 解析）。

六、实战示例

场景：测试 Presto 跨数据源查询

数据准备Hive 表：user_behavior（用户行为日志，存储在 HDFS）。MySQL 表：user_profile（用户画像数据，含性别、年龄）。

查询语句sql复制SELECT p.gender, COUNT(b.user_id) AS click_count FROM hive.test.user_behavior b JOIN mysql.profile.user_profile p ON b.user_id = p.user_id GROUP BY p.gender;

测试步骤正确性测试：比对 Presto 结果与 Hive+MySQL 手动 JOIN 的结果。性能测试：监控查询耗时，检查是否因数据倾斜导致个别 Worker 处理缓慢。故障注入：在查询过程中关闭一个 Worker 节点，观察查询是否自动恢复。

七、总结

Presto 是 交互式分析的核心工具，适合需要快速响应和跨数据源查询的场景。

测试重点：正确性（尤其跨源查询）、性能优化（内存/并发控制）、容错性。

工具推荐：使用 Presto Web UI 监控查询执行详情，结合 JMeter 模拟并发负载。

什么是Flink

一、Flink 的核心作用

实时数据处理毫秒级延迟：处理无界数据流（如 IoT 传感器数据、用户点击事件），支持事件时间（Event Time）和乱序数据处理。典型场景：实时监控、实时推荐、欺诈检测。

复杂事件处理（CEP）通过 CEP Library 检测数据流中的模式（如连续登录失败触发告警）。

批流一体统一 API 处理批数据和流数据（DataStream API 和 DataSet API 融合为 Table API/SQL）。

有状态计算精确管理计算状态（如窗口聚合结果），支持容错（通过 Checkpoint 和 Savepoint 机制）。

事件时间语义基于事件实际发生时间处理数据，避免因网络延迟导致结果偏差。

二、Flink 的架构设计

运行时架构JobManager：接收作业，生成执行图，调度 Task 到 TaskManager。TaskManager：执行具体 Task（包含多个 Slot，每个 Slot 运行一个线程）。高可用模式：依赖 ZooKeeper 实现 JobManager 故障切换。

数据流模型逻辑流图（DAG）：由 Source、Transformation、Sink 组成。物理执行：自动优化为并行子任务（如 Map 任务并行度为 4）。

状态管理状态类型：Keyed State（键控状态）、Operator State（算子状态）。状态后端：支持 RocksDB（磁盘+内存）、MemoryStateBackend（纯内存）等。

容错机制Checkpoint：定期将状态快照持久化到存储系统（如 HDFS、S3）。Exactly-Once 语义：通过 Barrier 对齐机制保证精确一次处理。

三、Flink 的典型应用场景

场景	说明	示例
实时数据管道	将数据从消息队列（如 Kafka）处理后写入数据库或数据湖。	Kafka → Flink（过滤/清洗） → HBase
实时指标聚合	按时间窗口统计用户行为（如每分钟 PV/UV）。	用户点击流 → 滚动窗口（1分钟） → 统计结果输出
复杂事件检测	识别连续异常事件（如 10 秒内 3 次支付失败）。	交易流 → CEP 规则匹配 → 触发风控告警
数据流与静态表关联	实时流数据与维度表（如 MySQL 中的商品信息）关联。	订单流 → JOIN 商品维表 → 实时看板
机器学习模型推理	将实时数据输入预训练模型进行预测（如用户画像实时更新）。	用户行为流 → 模型推理 → 实时推荐结果

四、Flink 与其他流处理框架的对比

特性	Flink	Spark Streaming	Kafka Streams
处理模型	原生流处理（逐事件处理）	微批处理（按时间片划分）	基于 Kafka 分区流处理
延迟	毫秒级	秒级	毫秒级
状态管理	内置强大状态管理	需结合外部存储（如 Redis）	内置状态存储（Kafka Topic）
Exactly-Once	支持（端到端）	支持（需配置）	支持
适用场景	复杂实时计算、高吞吐低延迟场景	准实时ETL、简单聚合	轻量级 Kafka 生态流处理

五、测试工程师的关注点

数据正确性验证端到端一致性：测试 Source 到 Sink 的数据是否完整（如比对 Kafka 输入与数据库输出）。事件时间处理：注入乱序数据，验证窗口结果是否符合预期（如水位线机制是否生效）。

容错性测试Checkpoint 恢复：手动触发 TaskManager 宕机，验证作业是否从最近 Checkpoint 恢复。Exactly-Once 验证：模拟故障后，检查 Sink 是否重复写入（如数据库主键冲突检测）。

性能测试吞吐量：测试单 TaskManager 每秒处理记录数（如 10万条/秒）。背压（Backpressure）：监控反压指标，调整并行度或资源分配。

状态管理测试状态膨胀：模拟长时间运行作业，检查 RocksDB 状态存储是否稳定（如磁盘占用率）。状态迁移：验证 Savepoint 的兼容性（如升级 Flink 版本后从旧 Savepoint 恢复）。

资源与监控内存泄漏：通过 Heap Dump 分析长时间运行后的内存占用。指标监控：集成 Prometheus + Grafana 监控 Flink 的吞吐、延迟、Checkpoint 耗时。

六、实战测试场景示例

场景：测试实时风控规则的准确性

需求：用户连续 3 次登录失败后触发告警。

测试步骤：步骤 1：正常逻辑验证
输入序列：失败 → 失败 → 失败，验证是否触发告警。步骤 2：乱序数据处理
输入序列（事件时间）：[t1:失败, t3:失败, t2:失败]，验证窗口是否识别为连续 3 次。步骤 3：容错测试
在第二个事件处理时 Kill TaskManager，恢复后检查告警是否正常触发。步骤 4：性能压测
模拟 10万/秒的登录事件流，监控反压和 CPU 使用率。