HDInsight で Apache Spark アプリケーションを最適化する
この記事では、Azure HDInsight で Apache Spark アプリケーションを最適化するための戦略を概説します。
概要
次の一般的なシナリオに直面する可能性があります
- 同じ HDInsight クラスターで同じ Spark ジョブが以前よりも遅い
- HDInsight クラスターの Spark ジョブが、オンプレミスまたは他のサード パーティのサービス プロバイダーよりも遅い
- 1 つの HDI クラスターの Spark ジョブが別の HDI クラスターよりも遅い
Apache Spark ジョブのパフォーマンスは、複数の要因によって決まります。 これらのパフォーマンス要因は次のとおりです。
- データの保存方法
- クラスターの構成方法
- データの処理時に使用される操作
- 異常な YARN サービス
- 不適切なサイズの Executor と OutOfMemoryError によるメモリ制約
- タスクが多すぎるか、タスクが少なすぎる
- データ スキューによって、いくつかの負荷の高いタスクまたは低速なタスクが発生した
- 不適切なノードでのタスクの速度の低下
手順 1: YARN サービスが正常かどうかを確認する
- Ambari UI に移動します。
- ResourceManager または NodeManager アラートの有無を確認します
- YARN > SUMMARY で ResourceManager と NodeManager の状態を確認します。すべての NodeManager が [Started](開始済み) になっているか、アクティブな ResourceManager のみが [Started](開始済み) になっている必要があります。
以下を介して Yarn UI にアクセスできるかどうかを確認します。
https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster以下で ResourceManager のログに例外またはエラーがあるかどうかを確認します。
/var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log
詳細については、YARN の一般的な問題に関するページを参照してください。
手順 2: 新しいアプリケーション リソースと使用可能な YARN リソースを比較する
Ambari UI > YARN > SUMMARY に移動し、ServiceMetrics の CLUSTER MEMORY を確認します。
YARN キューのメトリックを詳細に確認します。
- 次を介して YARN UI に移動し、YARN スケジューラのメトリックを確認します。
https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler - または、YARN Rest API を使用して、YARN スケジューラのメトリックを確認することもできます。 たとえば、「
curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler"」のように入力します。 ESP の場合は、ドメイン管理者ユーザーを使用する必要があります。
- 新しいアプリケーションのリソースの合計を計算します
- すべての Executor リソース:
spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. 詳細については、Spark Executor の構成に関するページを参照してください。 - ApplicationMaster
- クラスター モードでは、
spark.driver.memoryとspark.driver.coresを使用します - クライアント モードでは、
spark.yarn.am.memory+spark.yarn.am.memoryOverheadとspark.yarn.am.coresを使用します
- クラスター モードでは、
Note
yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb
- 新しいアプリケーションの合計リソースと、指定したキューで使用可能な YARN リソースを比較します
手順 3: Spark アプリケーションを追跡する
Spark UI または Spark History UI を使用して、以下の現象を特定する必要があります。
- どのステージが遅いか
- [Stage](ステージ) タブの Event-Timeline で完全に使用されている Executor CPU v コアの合計数はいくつか
- Spark SQL を使用している場合、[SQL] タブの物理的プランは何か
- 1 つのステージでの DAG が長すぎないか
- [Stage](ステージ) タブでタスクのメトリック (入力サイズ、シャッフル書き込みサイズ、GC 時間) を確認する
詳細については、Spark アプリケーションの監視に関するページを参照してください。
手順 4: Spark アプリケーションを最適化する
キャッシュ、データ スキューの許可など、これらの課題を克服するのに役立つ多くの最適化があります。
次の各記事では、Spark の最適化のさまざまな側面に関する情報を確認できます。
- Apache Spark 用にデータ ストレージを最適化する
- Apache Spark のデータ処理を最適化する
- Apache Spark 用にメモリ使用量を最適化する
- Apache Spark の HDInsight クラスター構成を最適化する
Spark SQL パーティションを最適化する
-
spark.sql.shuffle.paritionsは既定で 200 です。 結合または集計のデータをシャッフルする場合は、ビジネス ニーズに基づいて調整できます。 -
spark.sql.files.maxPartitionBytesは HDI では既定で 1G です。 ファイルの読み取り時に 1 つのパーティションに取り込める最大バイト数です。 この構成は、Parquet、JSON、ORC などのファイル ベースのソースを使用する場合にのみ有効です。 - Spark 3.0 の AQE。 「アダプティブ クエリの実行」を参照してください。