ビッグデータテストチュートリアル：ビッグデータとは何か、戦略、テスト方法
プラフラ・ラナディヴ
⚡ スマートサマリー
ビッグデータテストは、分散型Hadoopクラスタ全体にわたるデータステージング検証、MapReduce検証、出力検証とアーキテクチャおよびパフォーマンスチェックを組み合わせることで、ビッグデータアプリケーションがテラバイト規模のデータを正しく、迅速かつ安全に処理することを検証します。
ビッグデータテストとは何ですか？
ビッグデータテストとは、ビッグデータアプリケーションのすべての機能が期待どおりに動作することを確認するためのテストプロセスです。ビッグデータテストの目的は、パフォーマンスとセキュリティを維持しながら、ビッグデータシステムがスムーズかつエラーなく動作することを保証することです。
ビッグデータとは、従来のコンピューティング技術では処理できない大規模なデータセットの集合です。これらのデータセットのテストには、さまざまなツール、技術、フレームワークが用いられます。ビッグデータは、量、種類、速度の点で驚異的なデータの作成、保存、検索、分析に関連しています。詳細については、 ビッグデータ, Hadoopの (NAIST) と MapReduce テストを開始する前に。
ビッグデータのテスト戦略とは何ですか?
ビッグデータアプリケーションのテストは、ソフトウェア製品の個々の機能をテストするよりも、データ処理能力の検証に重点が置かれます。ビッグデータテストにおいては、パフォーマンスと機能のテストが鍵となります。
ビッグデータテスト戦略では、QAエンジニアは汎用クラスタやその他のサポートコンポーネントを使用してテラバイト規模のデータの処理が成功したことを検証します。処理速度が非常に速いため、高度なテストスキルが求められます。処理には次の3種類があります。
- バッチ処理： 保存されたデータはスケジュールに基づいて処理されるため、テストはジョブの完了と正確性を対象とします。
- リアルタイム処理: 記録は到着時に処理されるため、テストは遅延とデータ損失を対象とします。
- 対話型処理: アナリストは直接クエリを実行するため、テストではアドホッククエリの応答時間を対象とする。
下の図は、その戦略をまとめたものです。
これに加えて、データ品質もHadoopテストにおいて重要な要素です。アプリケーションをテストする前に、データの品質を確認する必要があり、これはデータベーステストの一部として考慮されるべきです。これには、適合性、正確性、重複、一貫性、妥当性、データの完全性など、さまざまな特性の確認が含まれます。このHadoopテストチュートリアルでは、次にHadoopアプリケーションのテスト方法について学びます。
Hadoopアプリケーションのテスト方法
次の図は、ビッグデータアプリケーションのテストにおける各段階の概要を示しています。
ビッグデータテスト、またはHadoopテストは、大きく3つのステップに分けられます。
ステップ 1: データステージングの検証
このビッグデータテストチュートリアルの最初のステップは、Hadoop導入前の段階と呼ばれ、プロセス検証が含まれます。
- RDBMS、ウェブログ、ソーシャルメディアなど、さまざまなソースからのデータは、正しいデータがシステムに取り込まれていることを確認するために検証する必要があります。
- ソース データと Hadoop システムにプッシュされたデータを比較して、それらが一致していることを確認する
- 正しいデータが使用されていることを確認してくださいtracテッドして正しい場所にロードしました HDFS 場所
のようなツール タレンド また、Datameerはデータステージングの検証に使用できます。
ステップ 2: 「MapReduce」の検証
第2段階は「MapReduce」の検証です。この段階では、ビッグデータテスターは各ノードでビジネスロジックの検証を行い、その後複数のノードに対して実行した後に検証を行い、以下の点を確認します。
- MapReduceプロセスは正しく動作します
- データの集計ルールまたは分離ルールがデータに実装されている
- キーと値のペアが生成される
- MapReduce処理後のデータの検証
ステップ 3: 出力検証フェーズ
Hadoop テストの最終段階または第 XNUMX 段階は、出力検証プロセスです。 出力データ ファイルが生成され、要件に基づいて EDW (エンタープライズ データ ウェアハウス) またはその他のシステムに移動できるようになります。
第3段階の活動内容は以下のとおりです。
- 変換ルールが正しく適用されていることを確認するには
- データの整合性とターゲット システムへのデータのロードが成功したかどうかを確認するには
- 対象データとHDFSファイルシステムのデータを比較し、データ破損が無いことを確認するには
Archi構造試験
今度は、データそのものから、データを格納するクラスターへと注目が移る。
Hadoop は非常に大量のデータを処理し、リソースを大量に消費します。そのため、ビッグデータ プロジェクトの成功を確実にするには、アーキテクチャ テストが不可欠です。設計が不十分または不適切なシステムは、パフォーマンスの低下につながり、システムが要件を満たせない可能性があります。最低限、 パフォーマンス また、フェイルオーバーテストサービスはHadoop環境で実行する必要があります。
パフォーマンス テストには、ジョブ完了時間、メモリ使用率、データ スループット、および同様のシステム メトリックのテストが含まれます。フェイルオーバー テスト サービスの目的は、データ ノードの障害発生時にデータ処理がシームレスに行われることを検証することです。
性能試験
ビッグデータのパフォーマンステストは、主に3つの分野を対象としています。
- データ取り込みとスループット： この段階では、ビッグデータテスターは、システムがさまざまなデータソースからデータをどれだけ速く消費できるかを検証します。テストには、キューが一定時間内に処理できるメッセージ数を特定することが含まれます。また、基盤となるデータストアにデータがどれだけ速く挿入できるか、たとえば、データストアへの挿入速度も含まれます。 MongoDB (NAIST) と Cassandra データベース。
- 情報処理： これには、クエリやMapReduceジョブの実行速度を検証することが含まれます。また、基盤となるデータストアにデータセットが格納された状態で、データ処理を単独でテストすることも含まれます。例えば、基盤となるHDFS上でMapReduceジョブを実行する場合などです。
- サブコンポーネントのパフォーマンス： これらのシステムは複数のコンポーネントで構成されており、各コンポーネントを個別にテストすることが不可欠です。例えば、メッセージのインデックス作成と処理速度、MapReduceジョブ、クエリパフォーマンス、検索などです。
パフォーマンス テストのアプローチ
ビッグデータアプリケーションのパフォーマンステストでは、膨大な量の構造化データと非構造化データのテストが必要となり、そのような大規模なデータをテストするには、特別なテスト手法が求められます。
以下のワークフローは、パフォーマンス テストがたどる一連の流れを示しています。
パフォーマンス テストは以下の順序で実行されます。
- このプロセスは、パフォーマンスをテストするビッグデータクラスタのセットアップから始まります。
- 対応するワークロードを特定して設計する
- 個々のクライアントを準備する（カスタムスクリプトを作成する）
- テストを実行し、結果を分析します（目標が達成されない場合は、コンポーネントを調整して再実行します）。
- 最適な構成
パフォーマンステストのパラメータ
性能テストで検証すべき様々なパラメータは以下のとおりです。
- データストレージ： 異なるノードでデータがどのように保存されるか
- コミットログ: コミットログのサイズはどの程度まで許容されるか
- 同時実行性: 書き込み操作と読み取り操作を実行できるスレッド数はいくつですか？
- キャッシング： キャッシュ設定の「行キャッシュ」と「キーキャッシュ」を調整してください。
- タイムアウト: 接続タイムアウト、クエリタイムアウトなどの値。
- JVMパラメータ： ヒープサイズ、GC収集アルゴリズムなど
- MapReduceのパフォーマンス： ソート、マージなど
- メッセージキュー: メッセージ送信速度、サイズなど
テスト環境のニーズ
テスト環境の要件は、テスト対象のアプリケーションの種類によって異なります。ビッグデータソフトウェアのテストの場合、テスト環境には以下の要素が含まれる必要があります。
- 大量のデータを保存および処理するのに十分なスペースが必要です。
- 分散ノードとデータを持つクラスターが必要です
- ビッグデータのパフォーマンスをテストするには、パフォーマンスを高く維持するために CPU とメモリの使用率を最小限にする必要があります。
ビッグデータテストと従来型データベーステストの比較
以下の表は、2つの分野を物件ごとに比較したものです。
| 特性 | 従来のデータベーステスト | ビッグデータのテスト |
|---|---|---|
| Rescale データ | テスターは構造化データを扱います | テスターは構造化データと非構造化データの両方を処理します |
| テストのアプローチ | テストアプローチは明確に定義されており、長年の実績がある | テストアプローチには集中的な研究開発努力が必要です |
| テスト戦略 | テスターは、手動で行う「サンプリング」戦略、または自動化ツールによる「網羅的検証」戦略のいずれかを選択できます。 | ビッグデータにおける「サンプリング」戦略は課題である |
| インフラ | ファイルサイズが制限されているため、特別なテスト環境は必要ありません。 | データ サイズとファイル (HDFS) が大きいため、特別なテスト環境が必要です |
| 検証ツール | テスターは、ExcelベースのマクロまたはUIベースの自動化ツールのいずれかを使用する。 | 特定のツールは定義されておらず、MapReduceのようなプログラミングツールからHiveQLまで、その範囲は広範である。 |
| テストツール | テストツールは基本的な操作知識と少ないトレーニングで使用できます | テストツールを操作するには、特定のスキルとトレーニングが必要です。また、これらのツールはまだ開発初期段階にあり、今後新たな機能が追加される可能性があります。 |
ビッグデータシナリオで使用されるツール
以下の表は、一般的なツールをクラスタ層別に分類したものです。
| ビッグデータ Cluster | ビッグデータ ツール |
|---|---|
| NoSQL： | CouchDB、データベース MongoDB, Cassandra、Redis、ZooKeeper、HBase |
| MapReduce： | ハドゥープ、 ハイブ、Pig、Cascading、Oozie、Kafka、S4、MapR、 用水路 |
| ストレージ： | S3、HDFS（Hadoop分散ファイルシステム） |
| サーバー： | 弾性、 Heroku, Google App Engine、EC2 |
| 処理： | R、ヤフー！ パイプ、Mechanical Turk、BigSheets、Datameer |
ビッグデータテストの課題
ほぼすべてのビッグデータプロジェクトにおいて、3つの実際的な障害が繰り返し発生する。
- オートメーション： 自動化テスト ビッグデータを扱うには、技術的な専門知識を持つ人材が必要です。また、自動化ツールは、テスト中に発生する予期せぬ問題に対処するようには設計されていません。
- 仮想化： これはテストの重要な段階の一つです。仮想マシンのレイテンシは、リアルタイムのビッグデータ性能テストにおいてタイミングの問題を引き起こします。また、ビッグデータにおけるイメージの管理も煩雑です。
- 大規模データセット: 音量には3つの圧力が伴う。
- より多くのデータを検証する必要があり、それをより迅速に行う必要がある
- テスト作業を自動化する必要がある
- さまざまなプラットフォームでテストできる必要がある
パフォーマンステストの課題
- 多様な技術群： 各サブコンポーネントは異なる技術に属しており、個別にテストする必要がある。
- 特定のツールが利用できない： 単一のツールでエンドツーエンドのテストを実行できるものはありません。例えば、NoSQLはメッセージキューには適さないかもしれません。
- テストスクリプト： テストシナリオとテストケースを設計するには、高度なスクリプト作成能力が必要となる。
- テスト環境： データサイズが大きいため、特別なテスト環境が必要です。
- 監視ソリューション： 環境全体を監視できるソリューションは限られている。
- 診断ソリューション： パフォーマンスのボトルネック領域を詳細に分析するには、カスタムソリューションが必要です。
