Condividi tramite


Ottimizzare le applicazioni Apache Spark in HDInsight

Questo articolo offre una panoramica delle strategie per ottimizzare le applicazioni Apache Spark in Azure HDInsight.

Panoramica

È possibile riscontrare i seguenti scenari comuni

  • Lo stesso processo Spark è più lento rispetto a prima nello stesso cluster HDInsight
  • Il processo Spark è più lento nel cluster HDInsight rispetto a quello locale o di un altro provider di servizi di terze parti
  • Il processo Spark è più lento in un cluster HDI rispetto a un altro cluster HDI

Le prestazioni dei processi di Apache Spark sono influenzate da più fattori. Questi fattori di prestazioni includono:

  • Modalità di archiviazione dei dati
  • Configurazione del cluster
  • Operazioni utilizzate durante l'elaborazione dei dati.
  • Servizio Yarn non integro
  • Vincoli di memoria dovuti a executor con dimensioni non corrette e OutOfMemoryError
  • Troppe attività o troppe attività
  • L'asimmetria dei dati ha causato alcune attività pesanti o attività lente
  • Attività più lente nei nodi non valido

Passaggio 1: controllare se il servizio Yarn è integro

  1. Passare all'interfaccia utente di Ambari:
  • Controllare se gli avvisi di ResourceManager o NodeManager
  • Controllare lo stato di ResourceManager e NodeManager in YARN > SUMMARY:All NodeManager should be in Started and only Active ResourceManager should be in Started (Tutti i NodeManager devono essere avviati) e solo Active ResourceManager (Avvio)
  1. Controllare se l'interfaccia utente di Yarn è accessibile tramite https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster

  2. Controllare se si verificano eccezioni o errori nell'accesso di ResourceManager /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Per altre informazioni, vedere Problemi comuni di Yarn

Passaggio 2: Confrontare le nuove risorse dell'applicazione con le risorse disponibili yarn

  1. Passare a RIEPILOGO YARN > dell'interfaccia utente > di Ambari, controllare MEMORIA CLUSTER in ServiceMetrics

  2. Controllare le metriche della coda yarn nei dettagli:

  • Passare all'interfaccia utente di Yarn, controllare le metriche dell'utilità di pianificazione yarn tramite https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • In alternativa, è possibile controllare le metriche dell'utilità di pianificazione yarn tramite l'API REST yarn. Ad esempio: curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Per ESP, è consigliabile usare l'utente amministratore di dominio.
  1. Calcolare le risorse totali per la nuova applicazione
  • Tutte le risorse executor: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Per altre informazioni, vedere la configurazione degli executor Spark
  • ApplicationMaster
    • In modalità cluster usare spark.driver.memory e spark.driver.cores
    • In modalità client, usare spark.yarn.am.memory+spark.yarn.am.memoryOverhead e spark.yarn.am.cores

Nota

yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb

  1. Confrontare le nuove risorse totali dell'applicazione con le risorse disponibili yarn nella coda specificata

Passaggio 3: Tenere traccia dell'applicazione Spark

  1. Monitorare l'applicazione Spark in esecuzione tramite l'interfaccia utente di Spark

  2. Monitorare l'applicazione Spark completa o incompleta tramite l'interfaccia utente del server cronologia Spark

È necessario identificare i sintomi seguenti tramite l'interfaccia utente di Spark o l'interfaccia utente della cronologia Spark:

  • Quale fase è lenta
  • Sono total executor CPU v-core completamente utilizzati nella scheda Sequenza temporale eventi nella scheda Fase
  • Se si usa spark sql, qual è il piano fisico nella scheda SQL
  • DAG troppo lungo in una fase
  • Osservare le metriche delle attività(dimensioni di input, dimensioni scrittura casuale, tempo GC) nella scheda Fase

Per altre informazioni, vedere Monitoraggio delle applicazioni Spark

Passaggio 4: Ottimizzare l'applicazione Spark

Esistono molte ottimizzazioni che consentono di superare queste sfide, ad esempio la memorizzazione nella cache e l'asimmetria dei dati.

In ognuno degli articoli seguenti è possibile trovare informazioni su diversi aspetti dell'ottimizzazione di Spark.

Ottimizzare le partizioni SPARK SQL

  • spark.sql.shuffle.partitions è 200 per impostazione predefinita. È possibile modificare in base alle esigenze aziendali quando si esegue la shuffling dei dati per join o aggregazioni.
  • spark.sql.files.maxPartitionBytes è 1G per impostazione predefinita in HDI. Numero massimo di byte da comprimere in una singola partizione durante la lettura dei file. Questa configurazione è efficace solo quando si usano origini basate su file, ad esempio Parquet, JSON e ORC.
  • AQE in Spark 3.0. Vedere Esecuzione di query adattive

Passaggi successivi