大數據測試總結

總結測試要點：
參考產品文檔，技術文檔梳理以下內容

需求來源

業務方應用場景

數據源，數據格轉，數據產出，數據呈現方式（數據消亡史），數據量級（增量，全量），更新頻率，數據產出時效

數據流轉方式（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 使用率。