日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

テスト結果

寄稿者

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 と顧客コミュニケーションを組み合わせた感情分析』"を使用して、エンドツーエンドの会話型AIパイプラインを構築しました "NetApp DataOps ツールキット"、AFF ストレージ、NVIDIA DGXシステムパイプラインは、DataOpsツールキットを活用して、バッチオーディオ信号処理、Automatic Speech Recognition(ASR)、転送学習、感情分析を実行します。 "NVIDIA Riva SDKを参照してください"および "Taoフレームワーク"。金融サービス業界へのセンチメント分析のユースケースの拡大、SparkNLPワークフローの構築、特定事業体の認識など、さまざまなNLPタスクに対する3つのBERTモデルのロード、NASDAQ Top 10 Companiesの四半期収益コールに関するセンテンスレベルのセンチメントの取得。

次のスクリプト「センチメント_アナリシス_スパーク」。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%

ワークフローの実行時間に関しては’local’モードからHDFSの分散環境に至るまで4.78倍の大幅な改善が見られましたまた’NFSを活用することで’さらに0.14%の向上が見られました

-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の方が明らかになります。

SparkのNLP感情分析のエンドツーエンドワークフローランタイム。

Horovodのパフォーマンスを使用した分散トレーニング

次のコマンドでは、1つのコアを持つ160個の実行者を持つ単一の「マスター」ノードを使用して、Sparkクラスタ内にランタイム情報とログファイルを生成しました。実行者メモリはメモリ不足エラーを回避するために5GBに制限されていました。を参照してください "「主要な各ユースケース用のPythonスクリプト」" データ処理、モデル・トレーニング、およびモデル精度計算の詳細については、「kers_spark_horovod_Rossmann _dimator.py」を参照してください。

(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のデータの並列化により、「yarn」と「local」モードを比較したランタイムが5.29x短縮され、トレーニング期間が10時間に短縮されました。次の図に、凡例に「hdfs」と「Local」を示します。基盤となる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高速化を達成できます。

Horovod Sparkのワークフローランタイム。

CTR予測パフォーマンスのディープラーニングモデル

クリック率を最大化するように設計されたレコメンダシステムでは、低い順に数学的に計算される可能性のある、ユーザーの行動の背後にある高度な機能の相互作用を学習する必要があります。低次と高次の両方の機能の相互作用は、どちらか一方をバイアスすることなく、ディープラーニングモデルにとっても同様に重要です。新しいニューラルネットワークアーキテクチャでの機能学習に向けて、界面活性化機械ベースのニューラルネットワークであるDeep Factorization Machine(DeepFM)は、界面活性化装置を組み合わせた推奨製品です。

従来の三角分解機械は、機能間の潜伏ベクトルの内側としてのペアワイズ機能の相互作用をモデル化しますが、理論的には高次情報をキャプチャすることができます。実際には、機械学習の実践では、一般的に、計算と保管の複雑さが高いため、二次フィーチャーの相互作用しか使用しませGoogleなどのディープニューラルネットワークのバリエーション "ワイド・モデルとディープ・モデル" 一方、リニアワイドモデルとディープモデルを組み合わせて、ハイブリッドネットワーク構造で高度な機能の相互作用を学習します。

このワイド・ディープ・モデルには2つの入力があります。1つは基本的なワイド・モデル用で、もう1つはディープのためです。後者の部分では、エキスパートフィーチャー・エンジニアリングが必要です。このため、この手法は他のドメインには一般的にできません。ワイド・ディープ・モデルとは異なり、DeepFMはフィーチャー・エンジニアリングなしでRAW機能を使用して効率的にトレーニングできます。ワイド・パートとディープ・パートは同じ入力と埋め込みベクトルを共有するためです。

私たちはまず’セクションのrun_classification_Crito_spark.pyを使用して’ctr_trine.csv’という名前のCSVファイルにCrito’trine.csv’をNFSマウント'/sparkdemo/tr-4570-data’に格納しました "「主なユースケースごとにPythonスクリプトを用意しています。」" このスクリプト内で’関数process_input_file’は’タブを削除し’区切り文字として''を’改行として''を挿入するための複数の文字列メソッドを実行しますコードブロックがコメントとして表示されるように、元の「train .txt」を1回だけ処理する必要があることに注意してください。

以下の異なるDLモデルのテストでは、「ctr_train .csv」を入力ファイルとして使用しました。その後のテスト実行では、入力CSVファイルがSpark DataFrameに読み込まれ、スキーマに「label」のフィールド、整数の高密度フィーチャー「I1」、「I2」、「I3」、…、「I13」が含まれています。 また’希薄な機能は''C1'、'C2'、'C3'、…、'C26']`です次の「spark-smSubmit」コマンドは、入力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

データファイル「ctr_train .csv」は11 GBを超えるため、エラーを回避するには、データセットサイズよりも十分な「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を「df.toPandas ()」メソッドを使用してPandas DataFrameに変換します。

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を構築する場合は、を使用することを推奨します "バザー"。今回の環境では、シェルプロンプトで以下のコマンドを実行して、「リタイア」、「リタイヤ」、「バザール」をインストールしました。

yum install dnf
dnf install 'dnf-command(copr)'
dnf copr enable vbatts/bazel
dnf install bazel5

ビルドプロセス中にC++ 17の機能を使用するには、GCC 5以降を有効にする必要があります。この機能は、RHELがソフトウェアコレクションライブラリ(SCL)とともに提供します。次のコマンドは’devtoolset’とGCC 11.2.1をRHEL 7.9クラスタにインストールします

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つのコマンドは’devtoolsets-11’を有効にしますこれには'/opt/r/devtoolset11-root//usr/bin/gcc`(GCC 11.2.1)が使用されますまた’gitのバージョンが1.8.3よりも大きいことを確認してください(RHEL 7.9に付属しています)これを参照してください "記事" 「git」を2.24.1に更新します。

最新のTensorFlowマスターリポジトリもすでにクローニング済みであるとします。次に’workspace’ファイルを使用して’workspace’ディレクトリを作成し’AVX、AVX2、FMAを使用してソースからTensorFlowを構築しますconfigureファイルを実行し、正しいPythonバイナリの場所を指定します。 "CUDA ( CUDA" はGPUを使用していないため、テストでは無効になっています。設定に応じて'`. bazelrc’ファイルが生成されますさらに、ファイルを編集し、HDFSのサポートを有効にするために「build—​define=no_hdfs_support=false」を設定しました。セクションの「. bazelrc」を参照してください "「主なユースケースごとにPythonスクリプトを用意しています。」" 設定とフラグの完全なリストについては、を参照してください。

./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予測の比較を示しています。

SparkワークフローランタイムのディープラーニングのCTR予測の比較。