[論文レビュー] Architectural Impact on Performance of In-memory Data Analytics: Apache Spark Case Study

Ahsan Javed Awan, Mats Brorsson+2 more|arXiv (Cornell University)|Apr 28, 2016

Cloud Computing and Resource Management参考文献 25被引用数 7

ひとこと要約

この論文は、ハードウェアパフォーマンスカウンターを用いて、現代のスケールアップサーバー上でのApache Sparkワークロード（バッチ、ストリーミング、機械学習）のマイクロアーキテクチャ的パフォーマンスを調査している。主な結論として、DRAM待機時間が主なボトルネックであることが判明し、L1-D次ラインプリフェッチャーの無効化、複数の小さなエグゼキューターの使用、Hyper-Threadingの有効化といった設定の最適化により、最大36％のパフォーマンス向上が達成可能であると提言している。

ABSTRACT

While cluster computing frameworks are continuously evolving to provide real-time data analysis capabilities, Apache Spark has managed to be at the forefront of big data analytics for being a unified framework for both, batch and stream data processing. However, recent studies on micro-architectural characterization of in-memory data analytics are limited to only batch processing workloads. We compare micro-architectural performance of batch processing and stream processing workloads in Apache Spark using hardware performance counters on a dual socket server. In our evaluation experiments, we have found that batch processing are stream processing workloads have similar micro-architectural characteristics and are bounded by the latency of frequent data access to DRAM. For data accesses we have found that simultaneous multi-threading is effective in hiding the data latencies. We have also observed that (i) data locality on NUMA nodes can improve the performance by 10% on average and(ii) disabling next-line L1-D prefetchers can reduce the execution time by up-to 14\% and (iii) multiple small executors can provide up-to 36\% speedup over single large executor.

研究の動機と目的

• 現代のスケールアップサーバー上でのApache Sparkにおけるメモリ内データ分析ワークロードのマイクロアーキテクチャ的パフォーマンス特性を理解すること。
• NUMAメモリアクセス、Hyper-Threading、ハードウェアプリフェッチャーの影響を定量的に評価すること。
• データ速度がSpark Streamingワークロードに与える影響を評価し、パフォーマンスボトルネックを同定すること。
• ハイブリッドメモリキューブのような高帯域幅メモリ技術がSparkワークロードに与える可能性を評価すること。
• スケールアップシステム上でパフォーマンスを最大化するための、Apache Sparkおよび下位層のハードウェアの設定に関する実行可能な提言を提供すること。

提案手法

• デュアルソケットのIvy Bridgeサーバーを用いて、ハードウェアパフォーマンスカウンターを用いたマイクロアーキテクチャ的分析を実施。
• DRAMバインドスタール、L1/L2キャッシュミスの影響、命令レティリーレートといった主要パフォーマンス指標を測定。
• メモリアクセス待機時間の影響を定量化するために、LocalDRAMBoundおよびRemoteDRAMBoundを計算するための式を用いた。
• 観測された単一スレッドパフォーマンスと理論的パフォーマンスに基づいた導出式を用いて、HTの有効性を評価。
• Spark Core、MLlib、SQL、GraphX、Streamingの各ワークロードに対して、さまざまな設定でベンチマークを実施。
• エグゼキューターのサイズ、メモリローカリティ、DDR3速度、プリフェッチャー設定を系統立てて変更し、パフォーマンスへの影響を分離して評価。

実験結果

リサーチクエスチョン

• RQ1 Apache Sparkにおけるバッチ処理とストリーミング処理ワークロードは、マイクロアーキテクチャ的特性においてどのように異なるか？
• RQ2 NUMAノード上のデータローカリティは、スケールアップサーバー上でのSparkパフォーマンスをどの程度向上させるか？
• RQ3 Hyper-Threadingは、SparkワークロードにおけるDRAMアクセス待機時間を効果的に隠せるか？
• RQ4 L1-DおよびL2ハードウェアプリフェッチャーを無効化した場合、Sparkワークロードにどのようなパフォーマンス影響が生じるか？
• RQ5 ハイブリッドメモリキューブのような高帯域幅メモリ技術は、Sparkパフォーマンスを顕著に向上させることができるか？

主な発見

• バッチ処理とストリーミング処理ワークロードは、両者ともDRAMアクセス待機時間によって制限されており、パフォーマンスボトルネックに顕著なアーキテクチャ的差異は認められない。
• NUMAノード上のデータローカリティは、平均して10％のパフォーマンス向上をもたらし、バックエンドバインドスタールを19％削減し、命令レティリーレートを9％向上させる。
• 次ラインL1-Dプリフェッチャーを無効化すると、実行時間が最大14％短縮され、隣接キャッシュラインL2プリフェッチャーを無効化すると最大4％短縮される。
• 1つの大きなエグゼキューターではなく、複数の小さなエグゼキューター（1エグゼキューターあたり≤32GB）を用いることで、最大36％のスループット向上が達成可能である。
• Hyper-Threadingは、DRAMバインドスタールを50％削減し、HT有効性が1.0に達する。これは、この文脈においてほぼ完全なスケーリングが実現していることを示している。
• DDR3速度を1866 MT/sから1333 MT/sに低下させることでパフォーマンスが向上する。これは、メモリ帯域幅が制限要因ではなく、低周波数にすることで電力と待機時間のオーバーヘッドが削減される可能性を示唆している。