Apache Spark—Lightning fast on GraalVM Enterprise

原文はこちら。
The original article was written by Shaun Smith and Aleksander Prokopec.
https://blogs.oracle.com/graalvm/apache-spark%e2%80%94lightning-fast-on-graalvm-enterprise

【訳注】
原文ではGraalVM Enterprise EditionをGraalVM Enterpriseと表現しています。GraalVMのサイトやOracleのサイトで表現が統一されていませんが、原文を尊重してGraalVM Enterpriseという表記を使っています。

Apache Spark and Oracle GraalVM Enterprise

Apache Sparkは、JavaやScalaで記述された大規模データ処理や機械学習、ストリーミング、グラフ処理のためのオープンソースの統合分析エンジンで、PythonやR、SQLを含む、数多くの他のプログラミング言語とのバインディングを提供しています。

Apache Spark
https://spark.apache.org/

Oracle GraalVM Enterpriseはアプリケーションパフォーマンスや効率の面で大幅に向上させるハイパフォーマンスなランタイムです。Oracle Java SE上に構築されており、JavaやScala、Groovy、Kotlin、ClojureといったJVMベースの言語、JavaScript、Python、Ruby、R、CやC++などのLLVMベースの言語で書かれたアプリケーションを実行できます。

Oracle GraalVM Enterprise
http://www.oracle.com/graalvm

Apache Sparkは大量のデータ処理を得意としているため、パフォーマンスは絶対的に重要です。Apache Sparkには多くの洗練されたパフォーマンスチューニングオプションやテクニックが用意されていますが、全体的なパフォーマンスを向上させる最も簡単な方法の1つは、GraalVM Enterprise上でApache Sparkを実行することです。RenaissanceベンチマークスイートのApache Sparkのベンチマークでは、ワークロードの実行時間が平均1.6倍に短縮され、ベンチマークによっては5倍高速に実行されています。ここでは、GraalVM Enterprise上でApache Sparkを実行した場合にどのような高速化が期待できるか見てみましょう。

Renaissance Suite, a benchmark suite for the JVM
http://renaissance.dev/

Benefits of running Apache Spark on GraalVM Enterprise

GraalVM Enterprise上でApache Sparkを実行すると、実行時間が大幅に短縮されます。その理由は以下の通りです。

  1. GraalVM Enterpriseの高度なコンパイラは、Scalaに見られる抽象度の高さにより、多くの最適化を実行できる。具体的には、パス複製[1]、最適化駆動型(optimization-driven)インライン化[2]、高度な推測[3]などの最適化のおかげで、GraalVM EnterpriseのJITコンパイラは、Apache Sparkアプリケーションのピークパフォーマンスを向上させ、実行時間を短縮する。
  2. GraalVM Enterpriseの最適化コンパイラは、GCのオーバーヘッドを削減する。部分エスケープ解析[4]のような最適化により、アプリケーションに割り当てられるオブジェクトの数を大幅に削減でき、それによってアプリケーションのメモリフットプリントとGCで発生するCPU負荷の両方を削減しする。典型的なビッグデータのワークロードは、大量のオブジェクトを割り当てる傾向があるため、これはApache Sparkにとって重要である。
  3. GraalVM Enterpriseは複数の言語を実行できるが、PythonとJavaのような、異なる2個の言語が通常お互いの関数を呼び出す場合に支払う言語間の呼び出しコストがない。Apache SparkはScalaで実装されており、多くの有用なデータ処理ユーティリティはPythonやRといった分析言語で実装されているため、この特長は特にApache Sparkやデータ処理の文脈でメリットがある。

Performance Comparison

OpenJDKとGraalVM Enterpriseを使用した場合のApache SparkのパフォーマンスをRenaissance suite [5]の8つのベンチマーク(als、chi-square、dec-tree、gauss-mix、log-regression、movie-lens、naive-bayes、page-rank)で比較してみましょう。これらのベンチマークは、典型的なビッグデータ処理と機械学習アルゴリズムを表しており、Apache SparkのReliable Distributed Datasets (RDDs) とその機械学習ライブラリ(MLLib) を使用しています。

Peak Performance

JVMのウォームアップが完了し、JITコンパイラがアプリケーション用に生成したマシンコードが完全に最適化された後のパフォーマンスとしてピークパフォーマンスを定義します。以下のグラフは、OpenJDK 8とGraalVM Enterpriseのピークパフォーマンスを比較したものです。ここでは、OpenJDK 8 をベースラインとし、y 軸は正規化された実行時間を示しています。そのため、低いほどパフォーマンスがよいことを示します。

Figure 1: Apache Spark benchmarks—GraalVM Enterprise (JDK 8) vs. OpenJDK 8

Figure 1ではJDK 8のピークパフォーマンスを示しています。概してGraalVM EnterpriseはOpenJDK 8に比べて全てのベンチマークにおいて高いピークパフォーマンスを示しています。GraalVM Enterpriseによるパフォーマンスの改善は通常10%から50%ほどで、平均して1.6倍の改善が見られます。naive-bayesのようなケースではGraalVM EnterpriseのパフォーマンスがOpenJDK 8のおよそ5倍に達しています。

Figure 2: Apache Spark benchmarks—GraalVM Enterprise (JDK 11) vs. OpenJDK 11

Figure 2は同じベンチマークでJava 11とのパフォーマンスを比較していますが、こちらもGraalVM EnterpriseがOpenJDK 11に比べてパフォーマンスが大きく改善している(平均1.5倍)ことが分かります。

Memory consumption and ergonomics

部分エスケープ解析やスカラー置換[4] のような、高度なメモリアロケーションの最適化により、GraalVM Enterpriseはより多くのオブジェクト割り当てを最適化できます。その結果、GraalVM Enterpriseで稼働するアプリケーションは自動メモリ管理やガベージコレクション実行時間が少なくてすみます。実用的な観点からは、これはつまりGraalVM Enterpriseで稼働するアプリケーションはより少ないメモリでよいパフォーマンスを達成できるということで、これは特にクラウド環境では重要です。

Figure 3: Performance at different memory levels on naive-bayes (JDK 8)

このことを説明するため、Figure 3を考えてみましょう。これは様々なJVMメモリサイズ(-Xmxオプションで制御)でのJDK 8におけるnaive-bayesベンチマークのパフォーマンスを比較しています。Y軸は実行時間(単位はミリ秒、低いほどよい)です。このベンチマークでは、利用可能なメモリに関係なく、GraalVM EnterpriseでのパフォーマンスはOpenJDKのそれよりもよく、例えばGraalVM EnterpriseではOpenJDK 8が4GBメモリで達成しているパフォーマンスをたった0.75GBで達成しています。

Figure 4ではOpenJDK 11とGraalVM Enterpriseでの種々のメモリサイズにおけるアプリケーション実行時間を比較しています。JDK 11におけるデフォルトGCはG1GC [6]で、これは一般にJDK 8におけるParallel GC [7]に比べてより多くのメモリを必要とします。JDK 11とG1GCにおいて同様の効果を観察できます。具体的には、OpenJDK 11で10GBのメモリを使用した場合と同じ性能を、GraalVM Enterpriseでは6GBのメモリで達成できます。

Figure 4: Performance at different memory levels on naive-bayes (JDK 11)

chi-squareベンチマーク(Figure 5)、log-regressionベンチマーク(Figure 6)でも、同様の効果を確認できます。GraalVM Enterpriseは一貫してより少ないメモリ消費量で同じパフォーマンスを達成できます。

Figure 5: Performance at different memory levels on chi-square (JDK 8)
Figure 6: Performance at different memory levels on log-regression (JDK 8)

Conclusion

ご覧のように、様々なベンチマークにおいて、Apache SparkはOpenJDKよりもGraalVM Enterpriseの方がメモリ消費量が少なく、高速に動作します。本番環境でApache Sparkを実行していて、より少ないコンピュートリソースを使用しながらスループットを向上させたいのであれば、GraalVM Enterpriseに切り替えてください。GraalVM Enterpriseをインストールし、JAVA_HOMEを設定するだけでOKです。GraalVM Enterpriseのダウンロードは以下からどうぞ。

GraalVM Enterprise
http://oracle.com/graalvm

将来のエントリでは、RやPythonといったデータ分析言語のメソッドをSparkのデータ処理命令の中から呼び出すことができる、GraalVM Enterpriseの多言語サポートについて取り上げる予定です。

References

[1] Dominance-based duplication simulation (DBDS): code duplication to enable compiler optimizations
David Leopoldseder, Lukas Stadler, Thomas Würthinger, Josef Eisl, Doug Simon, Hanspeter Mössenböck
http://ssw.jku.at/General/Staff/Leopoldseder/DBDS_CGO18_Preprint.pdf
[2] An Optimization-Driven Incremental Inline Substitution Algorithm for Just-in-Time Compilers
Aleksandar Prokopec, Gilles Duboscq, David Leopoldseder, Thomas Würthinger
http://aleksandar-prokopec.com/resources/docs/prio-inliner-final.pdf
[3] Speculation without regret: reducing deoptimization meta-data in the Graal compiler
Gilles Duboscq, Thomas Würthinger, Hanspeter Mössenböck
http://ssw.jku.at/General/Staff/GD/PPPJ-2014-duboscq-29.pdf
[4] Partial Escape Analysis and Scalar Replacement for Java
Lukas Stadler, Thomas Würthinger, Hanspeter Mössenböck
http://www.ssw.uni-linz.ac.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf
[5] Renaissance Benchmark Suite
renaissance.dev
[6] Getting Started with the G1 Garbage Collector
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
[7] The Parallel Collector
https://docs.oracle.com/javase/9/gctuning/parallel-collector1.htm

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中