大データテストの概要#
大データテストは通常、大データ技術を使用したシステムまたはアプリケーションのテストを指します。大データテストは 2 つの次元に分けられます：
- 1 つの次元はデータテストです。
- もう 1 つの次元は大データシステムテストと大データアプリケーション製品テストです。
本記事では主にデータテストについて紹介します。
テストの核心内容#
データ品質テスト#
- 完全性：データに欠損がないか（フィールドが空、レコードが失われているか）を検証します。
- 一貫性：異なるシステムやストレージにおけるデータの形式と論理が一致しているかを確認します。
- 正確性：データ値が現実世界と一致していることを保証します（数値範囲、形式が正しいかなど）。
- ユニーク性：重複データを検出します（主キーの衝突など）。
- タイムリー性：データが期待される時間に更新または同期されているかを検証します。
データ処理ロジックテスト#
- MapReduce/Spark ジョブ検証：分散計算タスクの論理的正確性をテストします（集約、フィルタリング、結合操作など）。
- ETL（抽出 - 変換 - ロード）テスト：データがソースからターゲットシステムへの変換ルールが正確であるかを検証します。
- データパーティションとシャーディングテスト：データがルールに従って正しく異なるノードに分配されているかを確認します。
パフォーマンステスト#
- スループット：システムが単位時間内に処理するデータ量をテストします（毎秒処理するレコード数など）。
- レイテンシ：データ処理の応答時間を検証します（クエリの所要時間など）。
- 拡張性：ノードの拡張後のシステムのパフォーマンス向上能力を評価します。
- フォールトトレランス：ノードの故障をシミュレートし、システムの回復能力をテストします。
システム統合テスト#
- コンポーネントの互換性：Hadoop、Spark、Kafka、Hive などのコンポーネントの協調動作を検証します。
- インターフェイステスト：API やメッセージキュー（Kafka など）のデータ転送の正確性を確認します。
セキュリティテスト#
- アクセス制御：ユーザー / ロールのデータへのアクセス権限を検証します（HDFS ACL、Kerberos 認証など）。
- データ暗号化：転送中および保存中のデータが暗号化されているかをテストします（SSL/TLS、静的暗号化など）。
- 監査ログ：操作ログが完全に記録されているかを確認します。
テストの主要ステップ#
要件分析とテスト計画#
- ビジネス要件を明確にします（データ処理ルール、パフォーマンス指標など）。
- テスト戦略を策定します（ツール選定、環境設定、データ規模など）。
テスト環境の構築#
- Hadoop クラスター、Spark、データベースなどのインフラを展開します。
- テストデータ生成ツールを設定します（Apache NiFi、カスタムスクリプトなど）。
テストデータの準備#
- データ生成：ツールを使用して（DBMonster、Mockaroo など）構造化 / 非構造化データを作成します。
- データ注入：データを HDFS、Kafka などのストレージまたはメッセージキューにロードします。
テストケース設計#
- 正常シナリオ（正常なデータ処理）と異常シナリオ（ノードのダウン、データの偏り）をカバーします。
- パフォーマンステストシナリオを設計します（高い同時クエリ、大規模データの書き込みなど）。
テスト実行と監視#
- テストケースを実行し、結果を記録します。
- 監視ツールを使用して（Ganglia、Prometheus など）リソース使用率（CPU、メモリ、ディスク I/O）を追跡します。
結果分析と報告#
- 失敗したケースを分析し、問題の根本原因を特定します（コードの論理エラー、設定の問題など）。
- テスト報告書を生成し、合格率、パフォーマンス指標、欠陥リストを含めます。
回帰テストと最適化#
- 欠陥を修正した後、再テストを行い、問題が解決され、新たな問題が発生していないことを確認します。
- パフォーマンステストの結果に基づいてシステム設定を最適化します（JVM パラメータの調整、Shuffle プロセスの最適化など）。
よく使われるテスト方法#
機能テスト方法#
- サンプリング検証：大データセットのサブセットに対して全量チェックを行います。
- エンドツーエンドテスト：完全なビジネスプロセスをシミュレートし、データの入力から出力までの正確性を検証します。
- ゴールドデータセット比較：処理結果を事前に生成された正しいデータセットと比較します。
パフォーマンステスト方法#
- ベンチマークテスト：標準データセットを使用して（ TPC-DS）システムのパフォーマンスを評価します。
- ストレステスト：負荷を段階的に増加させ、システムがクラッシュするまでのボトルネックを特定します。
- 安定性テスト：長時間タスクを実行し、メモリリークやリソース枯渇の問題を検出します。
自動化テスト#
- ツール選定：
- データ品質：Great Expectations、Deequ
- パフォーマンステスト：JMeter、Gatling、YCSB（NoSQL ベンチマークツール）
- ETL テスト：QuerySurge、Talend
- フレームワーク統合：テストスクリプトを CI/CD パイプラインに統合します（Jenkins、GitLab CI など）。
カオスエンジニアリング#
- 分散環境での故障をシミュレートし（ネットワーク分断、ディスク故障など）、システムのフォールトトレランス能力を検証します。
テストケースの例#
データ品質テスト#
シナリオ：Kafka からリアルタイムで収集された注文データが完全で重複がないかを検証します。
テストケース設計：
| テストケース ID | DQ-001 |
|---|---|
| テスト目標 | 注文データの完全性とユニーク性を検証します。 |
| 前提条件 | 1. Kafka トピックに 10 万件の模擬注文データが注入されています（order_id、user_id、amount などのフィールドを含む）。 2. データは消費され、HDFS の /user/ordersパスに保存されています。 |
| テストステップ | 1. Hive を使用して HDFS のデータ総量をクエリします：SELECT COUNT(*) FROM orders;2. 重要なフィールドの空値率を確認します： SELECT COUNT(*) FROM orders WHERE order_id IS NULL OR user_id IS NULL;3. 重複した注文 ID を検出します： SELECT order_id, COUNT(*) AS cnt FROM orders GROUP BY order_id HAVING cnt > 1; |
| 期待結果 | データ総量が Kafka の注入量と一致します（10 万件）。 重要なフィールド（order_id、user_id）の空値率は 0% です。 重複する order_id の記録はありません。 |
ツールサポート：
Great Expectationsを使用してデータ分布と制約を自動的に検証します。
ETL テスト#
シナリオ：ユーザーデータが MySQL から Hive への ETL プロセスが正確であるかを検証します。
テストケース設計：
| テストケース ID | ETL-002 |
|---|---|
| テスト目標 | ユーザーの年齢フィールドの変換ロジック（MySQL の birth_date を Hive の age に変換）を検証します。 |
| 前提条件 | 1. MySQL のuserテーブルにはフィールド：id, name, birth_date（DATE 型）が含まれています。2. ETL ジョブは birth_date を Hive テーブルの age（INT 型、年単位で計算）に変換します。 |
| テストステップ | 1. MySQL にテストデータを挿入します：INSERT INTO user (id, name, birth_date) VALUES (1, 'Alice', '1990-05-20'), (2, 'Bob', '2005-11-15');2. ETL ジョブを実行し、データを Hive テーブル user_hiveに同期します。3. Hive テーブルの age フィールドをクエリします： SELECT name, age FROM user_hive WHERE id IN (1, 2); |
| 期待結果 | Alice の age は現在の年 - 1990（2023 年の場合は 33）です。 Bob の age は現在の年 - 2005（2023 年の場合は 18）です。 |
パフォーマンステスト#
シナリオ：Hive が 100 の同時クエリの下での応答時間とリソース使用率をテストします。
テストケース設計：
| テストケース ID | PERF-003 |
|---|---|
| テスト目標 | Hive が同時クエリの下での安定性を検証します。 |
| 前提条件 | 1. Hive テーブルには 1 億件の販売記録がロードされています。 2. テストクラスターの構成：10 ノード（8 コア CPU、32GB メモリ）。 |
| テストステップ | 1. JMeter を使用して 100 のスレッドを作成し、各スレッドが以下のクエリを実行します：SELECT product_category, SUM(amount) FROM sales WHERE sale_date BETWEEN '2022-01-01' AND '2022-12-31' GROUP BY product_category;2. HiveServer2 の CPU、メモリ、GC の状況を監視します（Ganglia または Prometheus を通じて）。 3. 各クエリの応答時間を記録し、90% ラインを統計します。 |
| 期待結果 | すべてのクエリが成功裏に実行され、タイムアウトや OOM エラーがありません。 平均応答時間は 15 秒以下、90% ラインは 20 秒以下です。 CPU 使用率のピークは 80% 以下、メモリは持続的に増加しません。 |
フォールトトレランステスト#
シナリオ：Spark Streaming ジョブが Worker ノードのダウン時に自動的に回復できるかを検証します。
テストケース設計：
| テストケース ID | FT-004 |
|---|---|
| テスト目標 | Spark ジョブのフォールトトレランス能力をテストします。 |
| 前提条件 | 1. Spark クラスターには 3 つの Worker ノードがあります。 2. リアルタイムの単語頻度統計ジョブが実行中で、Kafka からデータを読み取っています。ウィンドウ間隔は 1 分です。 |
| テストステップ | 1. Kafka にデータを継続的に送信します（毎秒 100 件）。 2. ジョブを 5 分間実行した後、手動で 1 つの Worker ノードを終了します。 3. 観察します： Driver ログにタスクの再スケジューリングが表示されるか。 新しい Worker がクラスターに自動的に参加するか（動的リソース割り当てが有効な場合）。 ウィンドウ結果が完全であるか（故障前後の総単語数を比較）。 |
| 期待結果 | ジョブは 30 秒以内に処理を回復し、データの損失はありません。 最終的な単語頻度統計結果は送信データの総量と一致します。 |
ツールサポート：
Chaos Monkey を使用してノードの故障をシミュレートします。
セキュリティテスト#
シナリオ：HDFS ディレクトリの ACL 権限制御が機能しているかを検証します。
テストケース設計：
| テストケース ID | SEC-005 |
|---|---|
| テスト目標 | 敏感なディレクトリ（例：/finance）が認可されたユーザーのみアクセスできることを確認します。 |
| 前提条件 | 1. HDFS ディレクトリ/financeの権限が 750 に設定されています（ユーザーグループは finance_team）。2. ユーザー alice は finance_team に属し、ユーザー bob はそのグループに属していません。 |
| テストステップ | 1. alice として実行します：hdfs dfs -ls /finance（成功するはずです）hdfs dfs -put report.csv /finance（成功するはずです）2. bob として実行します： hdfs dfs -ls /finance（"Permission denied" が返されるはずです）hdfs dfs -rm /finance/report.csv（失敗するはずです） |
| 期待結果 | 認可されたユーザー（alice）はディレクトリを読み書きでき、非認可ユーザー（bob）はアクセスが拒否されます。 |
自動化検証：
# Shellスクリプトを使用して自動化テスト
if hdfs dfs -ls /finance >/dev/null 2>&1; then
echo "Test FAILED: Unauthorized access allowed."
else
echo "Test PASSED."
fi