Condividi tramite

Ottimizzare le applicazioni Apache Spark in HDInsight

  • Articolo

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

Panoramica

È possibile affrontare 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 all'ambiente locale o ad altri 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 di 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: Verificare 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 (Tutto NodeManager deve essere avviato) e solo Active ResourceManager deve essere avviato

  1. Controllare se l'interfaccia utente di Yarn è accessibile tramite https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster

  2. Controllare se sono presenti 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 LA MEMORIA DEL 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 degli 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 in Event-Timeline nella scheda Stage
  • Se si usa spark sql, qual è il piano fisico nella scheda SQL
  • Il DAG è troppo lungo in una fase
  • Osservare le metriche delle attività (dimensioni di input, dimensioni di scrittura casuali, 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 spark.

Ottimizzare le partizioni di Spark SQL

  • spark.sql.shuffle.paritions è 200 per impostazione predefinita. È possibile modificare in base alle esigenze aziendali durante la sequenza casuale 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 è valida 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