テスト結果
変更を提案
PDF
TeraGenベンチマークツールでTeraSortおよびTeraValidateスクリプトを使用して、E5760、E5724、およびAFF-A800構成でのSparkのパフォーマンス検証を測定しました。さらに、SparkのNLPパイプラインとTensorFlow分散トレーニング、Horovod分散トレーニング、Kerasを使用したディープFMでのCTR予測を利用した複数ワーカーのディープラーニングという、3つの主なユースケースをテストしました。
EシリーズとStorageGRID の検証には、Hadoopレプリケーションファクタ2を使用しました。AFF の検証に使用したデータソースは1つだけです。
次の表に、Sparkのパフォーマンス検証のハードウェア構成を示します。
| タイプ | Hadoopワーカーノード | ドライブタイプ | ノードあたりのドライブ数 | ストレージコントローラ |
|---|---|---|---|---|
SG6060 |
4 |
SAS |
12 |
単一のハイアベイラビリティ（HA）ペア |
E5760 |
4 |
SAS |
60 |
単一のHAペア |
E5724 |
4 |
SAS |
24 |
単一のHAペア |
AFF800 |
4 |
SSD |
6 |
単一のHAペア |
次の表に、ソフトウェア要件を示します。
| ソフトウェア | バージョン |
|---|---|
RHEL |
7.9 |
OpenJDKランタイム環境 |
1.8.0 |
OpenJDK 64ビットのServer VM |
25.302 |
Git |
2.24.1 |
GCC/G++ |
11.2.1 |
火花 |
3.2.1 |
PySpark |
3.1.2 |
SparkNLPです |
3.4.2 |
TensorFlowです |
2.9.0 |
クラス |
2.9.0 |
ホロボド |
0.24.3 |
財務心理分析
ネットアップが公開した"TR-4910 ：『 NetApp AI と顧客コミュニケーションを組み合わせた感情分析』"レポートでは、AFFストレージとNVIDIA DGXシステムを使用して、エンドツーエンドの会話型AIパイプラインを構築し "NetApp DataOps ツールキット"ました。パイプラインは、DataOps Toolkit、およびを "Taoフレームワーク"活用して、バッチオーディオ信号処理、自動音声認識（ASR）、転送学習、感情分析を実行します "NVIDIA Riva SDKを参照してください"。金融サービス業界へのセンチメント分析のユースケースの拡大、SparkNLPワークフローの構築、特定事業体の認識など、さまざまなNLPタスクに対する3つのBERTモデルのロード、NASDAQ Top 10 Companiesの四半期収益コールに関するセンテンスレベルのセンチメントの取得。
次のスクリプトで `sentiment_analysis_spark. py`は、FinBERTモデルを使用してHDFS内のトランスクリプトを処理し、ポジティブ、ニュートラル、ネガティブの感情カウントを生成します。次の表を参照してください。
-bash-4.2$ time ~/anaconda3/bin/spark-submit --packages com.johnsnowlabs.nlp:spark-nlp_2.12:3.4.3 --master yarn --executor-memory 5g --executor-cores 1 --num-executors 160 --conf spark.driver.extraJavaOptions="-Xss10m -XX:MaxPermSize=1024M" --conf spark.executor.extraJavaOptions="-Xss10m -XX:MaxPermSize=512M" /sparkusecase/tr-4570-nlp/sentiment_analysis_spark.py hdfs:///data1/Transcripts/ > ./sentiment_analysis_hdfs.log 2>&1 real13m14.300s user557m11.319s sys4m47.676s
次の表に、2016年から2020年までのNASDAQトップ10企業の収益/コール、センテンスレベルの感情分析を示します。
| センチメントの数値と割合 | 10社すべて | AAPL | AMD | AMZN | CSCO | GOOGL | INTC | マイクロソフト | NVDA |
|---|---|---|---|---|---|---|---|---|---|
正の数 |
7447 |
1567 |
743 |
290 |
682 |
826 |
824 |
904 |
417 |
ニュートラルカウント |
64067 |
6856 |
7596 |
5086 |
6650 |
5914 |
6099 |
5715 |
6189 |
負の数 |
1787 |
253 |
213 |
84 |
189 |
97 |
282 |
202 |
89 |
分類なしのカウント |
196 |
0 |
0 |
76 |
0 |
0 |
0 |
1 |
0 |
（合計数） |
73497 |
8676 |
8552 |
5536 |
7521 |
6837 |
7205 |
6822 |
6695 |
割合の点では、CEOとCFOが話している文のほとんどは事実上であり、中立的な感情を持っています。決算発表時に、アナリストは肯定的または否定的な感情を伝える可能性のある質問をします。また、マイナスやプラスの心理が株価に与える影響についても、取引日の同日または翌日に定量的に調査することもできます。
次の表に、NASDAQトップ10企業の文章レベルの感情分析をパーセントで示します。
| センチメントの割合 | 10社すべて | AAPL | AMD | AMZN | CSCO | GOOGL | INTC | マイクロソフト | NVDA |
|---|---|---|---|---|---|---|---|---|---|
肯定的 |
10.13% |
18.06% |
8.69% |
5.24% |
9.07% |
12.08% |
11.44% |
13.25% |
6.23% |
ニュートラル |
87.17% |
79.02% |
88.82% |
91.87% |
88.42% |
86.50% |
84.65% |
83.77% |
92.44% |
負 |
2.43% |
2.92% |
2.49% |
1.52% |
2.51% |
1.42% |
3.91% |
2.96% |
1.33% |
分類なし |
0.27% |
0% |
0% |
1.37% |
0% |
0% |
0% |
0.01% |
0% |
ワークフローの実行時間に関しては、HDFSのモードから分散環境への移行が4.78倍に大幅に改善し、NFSの活用によってさらに0.14%も改善し `local`ました。
-bash-4.2$ time ~/anaconda3/bin/spark-submit --packages com.johnsnowlabs.nlp:spark-nlp_2.12:3.4.3 --master yarn --executor-memory 5g --executor-cores 1 --num-executors 160 --conf spark.driver.extraJavaOptions="-Xss10m -XX:MaxPermSize=1024M" --conf spark.executor.extraJavaOptions="-Xss10m -XX:MaxPermSize=512M" /sparkusecase/tr-4570-nlp/sentiment_analysis_spark.py file:///sparkdemo/sparknlp/Transcripts/ > ./sentiment_analysis_nfs.log 2>&1 real13m13.149s user537m50.148s sys4m46.173s
次の図に示すように、データとモデルの並列処理によって、データ処理と分散TensorFlowモデルの推論速度が向上しています。NFSのデータの場所では、トレーニング済みのモデルがワークフローのボトルネックになっているため、ランタイムが若干向上しました。Transcriptデータセットのサイズを増やすと、NFSの方が明らかになります。
Horovodのパフォーマンスを使用した分散トレーニング
次のコマンドは、それぞれ1つのコアを持つ160個のExecutorを持つ単一のノードを使用して、Sparkクラスタにランタイム情報とログファイルを生成しまし `master`た。実行者メモリはメモリ不足エラーを回避するために5GBに制限されていました。のData Processing、モデルトレーニング、およびモデル精度計算の詳細については、の `keras_spark_horovod_rossmann_estimator.py`項を参照してください"「主要な各ユースケース用のPythonスクリプト」"。
(base) [root@n138 horovod]# time spark-submit --master local --executor-memory 5g --executor-cores 1 --num-executors 160 /sparkusecase/horovod/keras_spark_horovod_rossmann_estimator.py --epochs 10 --data-dir file:///sparkusecase/horovod --local-submission-csv /tmp/submission_0.csv --local-checkpoint-file /tmp/checkpoint/ > /tmp/keras_spark_horovod_rossmann_estimator_local. log 2>&1
トレーニング期間が10回の場合の結果、次のようになりました。
real43m34.608s user12m22.057s sys2m30.127s
入力データの処理、DNNモデルのトレーニング、精度の計算、TensorFlowチェックポイントと予測結果のCSVファイルの作成に43分以上かかりました。トレーニング期間を10に制限しました。実際には100に設定されていることが多く、モデルの精度が十分であることを確認しています。トレーニング時間は通常、エポックの数に比例して拡大します。
次に、クラスタで使用可能な4つのワーカーノードを使用し、HDFSのデータを使用してモードで同じスクリプトを実行しまし `yarn`た。
(base) [root@n138 horovod]# time spark-submit --master yarn --executor-memory 5g --executor-cores 1 --num-executors 160 /sparkusecase/horovod/keras_spark_horovod_rossmann_estimator.py --epochs 10 --data-dir hdfs:///user/hdfs/tr-4570/experiments/horovod --local-submission-csv /tmp/submission_1.csv --local-checkpoint-file /tmp/checkpoint/ > /tmp/keras_spark_horovod_rossmann_estimator_yarn.log 2>&1
結果として得られる実行時間は次のように改善されました。
real8m13.728s user7m48.421s sys1m26.063s
HorovodのモデルとSparkのデータ並列処理では local、10個のトレーニングエポックで5.29倍のランタイムの高速化が見られました yarn。次の図に、凡例と Local`を示します `HDFS。基盤となるTensorFlow DNNモデルのトレーニングを、GPUがあればさらに高速化できます。このテストを実施し、今後のテクニカルレポートに結果を公開する予定です。
次のテストでは、NFSとHDFSの入力データをランタイムで比較しました。AFF A800上のNFSボリュームは、Sparkクラスタ内の5つのノード（1つのマスターと4つのワーカー）にマウントされました /sparkdemo/horovod。前のテストと同様のコマンドを実行し、パラメータで `--data- dir`NFSマウントを指定しました。
(base) [root@n138 horovod]# time spark-submit --master yarn --executor-memory 5g --executor-cores 1 --num-executors 160 /sparkusecase/horovod/keras_spark_horovod_rossmann_estimator.py --epochs 10 --data-dir file:///sparkdemo/horovod --local-submission-csv /tmp/submission_2.csv --local-checkpoint-file /tmp/checkpoint/ > /tmp/keras_spark_horovod_rossmann_estimator_nfs.log 2>&1
NFSを使用した場合の実行時間は次のようになりました。
real 5m46.229s user 5m35.693s sys 1m5.615s
次の図に示すように、1.43倍の速度がさらに向上しました。このため、ネットアップのオールフラッシュストレージをクラスタに接続することで、Horovod Sparkワークフローの高速データ転送と配信というメリットを享受し、1つのノードで実行する場合と比べて7.55x高速化を達成できます。
CTR予測パフォーマンスのディープラーニングモデル
クリック率を最大化するように設計されたレコメンダシステムでは、低い順に数学的に計算される可能性のある、ユーザーの行動の背後にある高度な機能の相互作用を学習する必要があります。低次と高次の両方の機能の相互作用は、どちらか一方をバイアスすることなく、ディープラーニングモデルにとっても同様に重要です。新しいニューラルネットワークアーキテクチャでの機能学習に向けて、界面活性化機械ベースのニューラルネットワークであるDeep Factorization Machine（DeepFM）は、界面活性化装置を組み合わせた推奨製品です。
従来の三角分解機械は、機能間の潜伏ベクトルの内側としてのペアワイズ機能の相互作用をモデル化しますが、理論的には高次情報をキャプチャすることができます。実際には、機械学習の実践では、一般的に、計算と保管の複雑さが高いため、二次フィーチャーの相互作用しか使用しませ一方、Googleのようなディープニューラルネットワークの変種は "ワイド"、線形ワイドモデルとディープモデルを組み合わせることで、ハイブリッドネットワーク構造における高度な機能の相互作用を学習します。
このワイド・ディープ・モデルには2つの入力があります。1つは基本的なワイド・モデル用で、もう1つはディープのためです。後者の部分では、エキスパートフィーチャー・エンジニアリングが必要です。このため、この手法は他のドメインには一般的にできません。ワイド・ディープ・モデルとは異なり、DeepFMはフィーチャー・エンジニアリングなしでRAW機能を使用して効率的にトレーニングできます。ワイド・パートとディープ・パートは同じ入力と埋め込みベクトルを共有するためです。
最初にCriteo (11GB)ファイルをNFSマウントに格納された /sparkdemo/tr-4570-data`CSVファイルに `ctr_train.csv`処理しまし `train.txt run_classification_criteo_spark.py`た。このスクリプト内のセクションから、"「主なユースケースごとにPythonスクリプトを用意しています。」"関数は `process_input_file`いくつかの文字列メソッドを実行してタブを削除し、区切り文字および改行として `‘\n’`挿入します `‘,’。コードブロックがコメントとして表示されるように、元のコードを1回だけ処理する必要があることに注意して `train.txt`ください。
さまざまなDLモデルの次のテストでは、入力ファイルとしてを使用しまし ctr_train.csv`た。その後のテスト実行では、入力CSVファイルがSpark DataFrameに読み込まれ、フィールド、整数密度フィーチャー `['I1', 'I2', 'I3', …, 'I13']、およびスパースフィーチャーを `['C1', 'C2', 'C3', …, 'C26']`含むスキーマが含まれてい `‘label’`ます。次の `spark-submit`コマンドは、入力CSVを取り込み、20%分割してクロスバリデーションを行うDeepFMモデルをトレーニングし、10回のトレーニングエポック後に最適なモデルを選択してテストセットの予測精度を計算します。
(base) [root@n138 ~]# time spark-submit --master yarn --executor-memory 5g --executor-cores 1 --num-executors 160 /sparkusecase/DeepCTR/examples/run_classification_criteo_spark.py --data-dir file:///sparkdemo/tr-4570-data > /tmp/run_classification_criteo_spark_local.log 2>&1
データファイルは11GBを超えるため、 ctr_train.csv`エラーを回避するためにデータセットサイズよりも十分に大きい値を設定する必要があります `spark.driver.maxResultSize。
spark = SparkSession.builder \
.master("yarn") \
.appName("deep_ctr_classification") \
.config("spark.jars.packages", "io.github.ravwojdyla:spark-schema-utils_2.12:0.1.0") \
.config("spark.executor.cores", "1") \
.config('spark.executor.memory', '5gb') \
.config('spark.executor.memoryOverhead', '1500') \
.config('spark.driver.memoryOverhead', '1500') \
.config("spark.sql.shuffle.partitions", "480") \
.config("spark.sql.execution.arrow.enabled", "true") \
.config("spark.driver.maxResultSize", "50gb") \
.getOrCreate()
上記の構成では SparkSession.builder、メソッドを使用 "Apache Arrowの"してSpark DataFrameをPandas DataFrameに変換します df.toPandas()。
22/06/17 15:56:21 INFO scheduler.DAGScheduler: Job 2 finished: toPandas at /sparkusecase/DeepCTR/examples/run_classification_criteo_spark.py:96, took 627.126487 s Obtained Spark DF and transformed to Pandas DF using Arrow.
ランダムにスプリットした後、トレーニングデータセットに3、6M行以上、テストセットに9、000サンプル以上が存在します。
Training dataset size = 36672493 Testing dataset size = 9168124
このテクニカルレポートでは、GPUを使用せずにCPUテストに焦点を当てているため、適切なコンパイラフラグを使用してTensorFlowを構築することが重要です。これにより、GPUアクセラレーションライブラリの呼び出しを回避し、TensorFlowのAdvanced Vector Extensions（AVX）およびAVX2命令を最大限に活用できます。これらの機能は、ベクトル化された加算、フィードフォワード内の行列乗算、またはバック伝播DNNトレーニングなどの線形代数計算用に設計されています。256ビット浮動小数点(FP)レジスタを使用したAVX2で使用可能なFMA (fMultiply Add)命令は、整数コードとデータ型に最適で、最大2倍の速度を実現します。FPコードとデータ型の場合、AVX2はAVXと比較して8%の高速化を実現します。
2022-06-18 07:19:20.101478: I tensorflow/core/platform/cpu_feature_guard.cc:151] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations: AVX2 FMA To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
ソースからTensorFlowを構築するにはNetApp、を使用することをお勧めします "バザー"。この環境では、シェルプロンプトで、、 dnf-plugins、およびBazelをインストールするために次のコマンドを実行しまし `dnf`た。
yum install dnf dnf install 'dnf-command(copr)' dnf copr enable vbatts/bazel dnf install bazel5
ビルドプロセス中にC++ 17の機能を使用するには、GCC 5以降を有効にする必要があります。この機能は、RHELがソフトウェアコレクションライブラリ(SCL)とともに提供します。次のコマンドは、RHEL 7.9クラスタにとGCC 11.2.1をインストールし `devtoolset`ます。
subscription-manager repos --enable rhel-server-rhscl-7-rpms yum install devtoolset-11-toolchain yum install devtoolset-11-gcc-c++ yum update scl enable devtoolset-11 bash . /opt/rh/devtoolset-11/enable
最後の2つのコマンドは、（GCC 11.2.1）を使用して /opt/rh/devtoolset-11/root/usr/bin/gcc`イネーブルになっていることに注意してください `devtoolset-11。また、バージョンが1.8.3よりも大きいことを確認して `git`ください（RHEL 7.9に付属しています）。2.24.1へのアップデートについては `git`こちらを参照して "記事"ください。
最新のTensorFlowマスターリポジトリもすでにクローニング済みであるとします。次に、AVX、AVX2、およびFMAを使用してソースからTensorFlowを構築するためのファイルを含むディレクトリを WORKSPACE`作成し `workspace`ます。ファイルを実行し `configure、正しいPythonバイナリの場所を指定します。 "CUDA （ CUDA"はGPUを使用していないため、テストでは無効になっています。 .bazelrc`設定に従ってファイルが生成されます。さらに、ファイルを編集し、HDFSサポートを有効にするようにを設定しまし `build --define=no_hdfs_support=false`た。設定とフラグの完全なリストについては、セクションの"「主なユースケースごとにPythonスクリプトを用意しています。」"を参照してください `.bazelrc。
./configure bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=-mfpmath=both -k //tensorflow/tools/pip_package:build_pip_package
適切なフラグを使用してTensorFlowを構築したら、次のスクリプトを実行してCritoディスプレイ広告データセットを処理し、DeepFMモデルをトレーニングし、予測スコアからReceiver Operating Characteristic Curve（ROC AUC）の下の領域を計算します。
(base) [root@n138 examples]# ~/anaconda3/bin/spark-submit --master yarn --executor-memory 15g --executor-cores 1 --num-executors 160 /sparkusecase/DeepCTR/examples/run_classification_criteo_spark.py --data-dir file:///sparkdemo/tr-4570-data > . /run_classification_criteo_spark_nfs.log 2>&1
トレーニング期間が10回終了したら、テストデータセットのAUCスコアを取得しました。
Epoch 1/10 125/125 - 7s - loss: 0.4976 - binary_crossentropy: 0.4974 - val_loss: 0.4629 - val_binary_crossentropy: 0.4624 Epoch 2/10 125/125 - 1s - loss: 0.3281 - binary_crossentropy: 0.3271 - val_loss: 0.5146 - val_binary_crossentropy: 0.5130 Epoch 3/10 125/125 - 1s - loss: 0.1948 - binary_crossentropy: 0.1928 - val_loss: 0.6166 - val_binary_crossentropy: 0.6144 Epoch 4/10 125/125 - 1s - loss: 0.1408 - binary_crossentropy: 0.1383 - val_loss: 0.7261 - val_binary_crossentropy: 0.7235 Epoch 5/10 125/125 - 1s - loss: 0.1129 - binary_crossentropy: 0.1102 - val_loss: 0.7961 - val_binary_crossentropy: 0.7934 Epoch 6/10 125/125 - 1s - loss: 0.0949 - binary_crossentropy: 0.0921 - val_loss: 0.9502 - val_binary_crossentropy: 0.9474 Epoch 7/10 125/125 - 1s - loss: 0.0778 - binary_crossentropy: 0.0750 - val_loss: 1.1329 - val_binary_crossentropy: 1.1301 Epoch 8/10 125/125 - 1s - loss: 0.0651 - binary_crossentropy: 0.0622 - val_loss: 1.3794 - val_binary_crossentropy: 1.3766 Epoch 9/10 125/125 - 1s - loss: 0.0555 - binary_crossentropy: 0.0527 - val_loss: 1.6115 - val_binary_crossentropy: 1.6087 Epoch 10/10 125/125 - 1s - loss: 0.0470 - binary_crossentropy: 0.0442 - val_loss: 1.6768 - val_binary_crossentropy: 1.6740 test AUC 0.6337
以前のユースケースと同様に、Sparkワークフローランタイムを異なる場所にあるデータと比較しました。次の図は、SparkワークフローランタイムのディープラーニングのCTR予測の比較を示しています。
