ビッグ データ テスト チュートリアル: Hadoop とは何か、戦略、テスト方法
プラフラ・ラナディヴ
ビッグデータのテスト
ビッグデータのテスト ビッグ データ アプリケーションのすべての機能が期待どおりに動作することを確認するための、ビッグ データ アプリケーションのテスト プロセスです。 ビッグ データ テストの目標は、パフォーマンスとセキュリティを維持しながら、ビッグ データ システムがスムーズにエラーなく動作することを確認することです。
ビッグ データは、従来のコンピューティング技術では処理できない大規模なデータセットの集合です。 テスト これらのデータセットには、処理するためのさまざまなツール、技術、フレームワークが含まれます。 ビッグデータは、量、多様性、速度の点で顕著なデータの作成、保存、取得、分析に関連しています。 ビッグデータ、Hadoop、MapReduce について詳しく学ぶことができます。 こちら
ビッグデータのテスト戦略とは何ですか?
ビッグ データ アプリケーションのテストは、ソフトウェア製品の個々の機能をテストするというよりも、そのデータ処理を検証することになります。 ビッグデータのテストに関して言えば、 パフォーマンスと機能のテスト が鍵です。
ビッグデータテスト戦略では、QAエンジニアはコモディティクラスタやその他のサポートコンポーネントを使用してテラバイトのデータが正常に処理されていることを確認します。処理が非常に高速であるため、高度なテストスキルが求められます。処理には3つのタイプがあります。
これに加えて、データ品質も Hadoop テストの重要な要素です。 アプリケーションをテストする前に、データの品質をチェックする必要があり、データベース テストの一部として考慮する必要があります。 これには、適合性、正確性、重複、一貫性、有効性、データの完全性などのさまざまな特性のチェックが含まれます。 次に、この Hadoop テスト チュートリアルでは、Hadoop アプリケーションをテストする方法を学びます。
Hadoop アプリケーションをテストする方法
次の図は、ビッグデータアプリケーションのテストの段階の概要を示しています。
ビッグデータテストやHadoopテストは大きくXNUMXつのステップに分かれます
ステップ 1: データステージングの検証
このビッグ データ テスト チュートリアルの最初のステップは、Hadoop 前段階と呼ばれ、プロセスの検証が含まれます。
- さまざまなソースからのデータ RDBMS、ウェブログ、ソーシャル メディアなどは、正しいデータがシステムに取り込まれていることを確認するために検証する必要があります。
- ソース データと Hadoop システムにプッシュされたデータを比較して、それらが一致していることを確認する
- 正しいデータが抽出され、正しい HDFS の場所にロードされていることを確認します。
のようなツール タレンド, データメール, データステージングの検証に使用できます
ステップ 2: 「MapReduce」の検証
XNUMX 番目のステップは、「MapReduce」の検証です。 この段階では、ビッグ データ テスターはすべてのノードでビジネス ロジックの検証を検証し、複数のノードに対して実行した後に検証して、
- Map Reduce プロセスが正しく動作する
- データの集計ルールまたは分離ルールがデータに実装されている
- キーと値のペアが生成される
- Map-Reduce プロセス後のデータの検証
ステップ 3: 出力検証フェーズ
Hadoop テストの最終段階または第 XNUMX 段階は、出力検証プロセスです。 出力データ ファイルが生成され、要件に基づいて EDW (エンタープライズ データ ウェアハウス) またはその他のシステムに移動できるようになります。
第 XNUMX 段階の活動には以下が含まれます。
- 変換ルールが正しく適用されていることを確認するには
- データの整合性とターゲット システムへのデータのロードが成功したかどうかを確認するには
- 対象データとHDFSファイルシステムのデータを比較し、データ破損が無いことを確認するには
Archi構造試験
Hadoop は膨大な量のデータを処理し、リソースを大量に消費します。そのため、ビッグデータ プロジェクトの成功を確実にするためには、アーキテクチャ テストが不可欠です。設計が不十分または不適切であるシステムはパフォーマンスの低下を招き、システムが要件を満たせなくなる可能性があります。少なくとも、 パフォーマンスとフェイルオーバーのテスト サービスは Hadoop 環境で実行する必要があります。
パフォーマンステスト ジョブの完了時間、メモリ使用率、データ スループット、および同様のシステム メトリックのテストが含まれます。 フェイルオーバー テスト サービスの目的は、データ ノードに障害が発生した場合にデータ処理がシームレスに行われることを検証することです。
性能試験
ビッグデータのパフォーマンス テストには XNUMX つの主要なアクションが含まれます
- データの取り込みと全体: この段階では、ビッグ データ テスターは、高速システムがさまざまなデータ ソースからデータをどのように消費できるかを検証します。 テストには、キューが特定の時間枠内で処理できる別のメッセージを識別することが含まれます。 また、Mongo への挿入速度など、基礎となるデータ ストアにデータを挿入できる速度も含まれます。 Cassandra データベース.
パフォーマンス テストのアプローチ
ビッグ データ アプリケーションのパフォーマンス テストには、膨大な量の構造化データと非構造化データのテストが含まれ、そのような大量のデータをテストするには、特定のテスト アプローチが必要です。
パフォーマンステストはこの順序で実行されます
- プロセスは、パフォーマンスをテストするビッグデータクラスタの設定から始まります。
- 対応するワークロードを特定して設計する
- 個別クライアントの準備（カスタムスクリプトが作成されます）
- テストを実行し、結果を分析します（目的が満たされない場合は、コンポーネントを調整して再実行します）
- 最適な構成
パフォーマンステストのパラメータ
性能テストで検証するさまざまなパラメータは次のとおりです。
- データストレージ: さまざまなノードにデータがどのように保存されるか
- コミット ログ: コミット ログの増大を許容するサイズ
- 同時実行性: 書き込みと読み取り操作を実行できるスレッドの数
- キャッシュ: キャッシュ設定「行キャッシュ」と「キー キャッシュ」を調整します。
- タイムアウト: 接続タイムアウト、クエリタイムアウトなどの値。
- JVM パラメータ: ヒープ サイズ、GC コレクション アルゴリズムなど。
- マップによるパフォーマンスの低下: ソート、マージなど。
- メッセージキュー: メッセージレート、サイズなど。
テスト環境のニーズ
テスト環境は、テストするアプリケーションの種類に依存する必要があります。 ビッグデータ ソフトウェア テストの場合、テスト環境には次のものが含まれる必要があります。
- 大量のデータを保存し、処理するための十分なスペースが必要です
- 分散ノードとデータを持つクラスターが必要です
- ビッグデータのパフォーマンスをテストするには、パフォーマンスを高く維持するために CPU とメモリの使用率を最小限にする必要があります。
ビッグデータのテストと従来のデータベースのテスト
| プロパティ | 従来のデータベーステスト | ビッグデータのテスト |
|---|---|---|
| Rescale データ | テスターは構造化データを操作します | テスターは構造化データと非構造化データの両方を処理します |
| テストのアプローチ | テストアプローチは明確に定義されており、長年の実績がある | テストアプローチには集中的な研究開発努力が必要です |
| テスト戦略 | テスターには、手動で行う「サンプリング」戦略または自動化ツールによる「徹底的な検証」戦略のオプションがあります。 | ビッグデータにおける「サンプリング」戦略は課題です |
| インフラ | ファイルサイズが制限されているため、特別なテスト環境は必要ありません。 | データ サイズとファイル (HDFS) が大きいため、特別なテスト環境が必要です |
| 検証ツール | テスターは Excel ベースのいずれかを使用します マクロ または UI ベースの自動化ツール | 定義されたツールはなく、MapReduce から HIVEQL などのプログラミング ツールまで広範囲に及びます |
| テストツール | テスト ツールは、基本的な操作知識と少ないトレーニングで使用できます。 | テスト ツールを操作するには、特定のスキルとトレーニングが必要です。また、ツールはまだ初期段階にあり、時間の経過とともに新しい機能が追加される可能性があります。 |
ビッグデータのシナリオで使用されるツール
| ビッグデータ Cluster | ビッグデータ ツール |
|---|---|
| NoSQL： | CouchDB、データベース MongoDB, Cassandra、Redis、ZooKeeper、HBase |
| MapReduce： | Hadoop、Hive、Pig、カスケード、Oozie、Kafka、S4、MapR、Flume |
| ストレージ： | S3、HDFS (Hadoop 分散ファイル システム) |
| サーバー： | 弾性、 Heroku、エラスティック、Google App Engine、EC2 |
| 処理 | R、ヤフー！ パイプ、Mechanical Turk、BigSheets、Datameer |
ビッグデータテストの課題
- オートメーション
自動化テスト ビッグデータの場合、技術的な専門知識を持つ人が必要です。 また、自動化ツールには、テスト中に発生する予期せぬ問題に対処する機能が備わっていません。
- 仮想環境
これはテストに不可欠なフェーズの XNUMX つです。 仮想マシンの遅延により、リアルタイムのビッグ データ パフォーマンス テストでタイミングの問題が発生します。 ビッグデータ内の画像の管理も面倒です。
- 大規模なデータセット
- より多くのデータを検証する必要があり、それをより迅速に行う必要がある
- テスト作業を自動化する必要がある
- 異なるプラットフォーム間でテストできる必要がある
パフォーマンステストの課題
- 多様なテクノロジー群: 各サブコンポーネントは異なるテクノロジーに属しており、個別にテストする必要があります。
- 特定のツールが利用できない: 単一のツールではエンドツーエンドのテストを実行できません。 例えば、 NoSQL メッセージキューに適合しない可能性があります
- テストスクリプト作成: テスト シナリオとテスト ケースを設計するには高度なスクリプト作成が必要です
- テスト環境：データサイズが大きいため、特別なテスト環境が必要です
- 監視ソリューション: 環境全体を監視できるソリューションは限られています
- 診断ソリューション: パフォーマンスのボトルネック領域をドリルダウンするには、カスタム ソリューションを開発する必要があります。
まとめ
- データ エンジニアリングとデータ分析が次のレベルに進むにつれて、ビッグデータのテストは避けられません。
- ビッグデータ処理はバッチ、リアルタイム、またはインタラクティブにすることができます
- ビッグ データ アプリケーションのテストの 3 つの段階は、データ ステージング検証、「MapReduce」検証、出力検証フェーズです。
- Archi設計が不十分なシステムは前例のないエラーやパフォーマンスの低下につながる可能性があるため、テストはビッグデータ テストの重要な段階です。
- ビッグ データのパフォーマンス テストには、データ スループット、データ処理、サブコンポーネントのパフォーマンスの検証が含まれます
- ビッグデータ テストは、データ、インフラストラクチャ、検証ツールの点で従来のデータ テストとは大きく異なります。
- ビッグ データ テストの課題には、仮想化、テストの自動化、大規模なデータセットの処理などがあります。 ビッグデータ アプリケーションのパフォーマンス テストも問題です。
