Optimiser les applications Apache Spark dans HDInsight

  • Article

Cet article présente un aperçu des stratégies d'optimisation des applications Apache Spark sur Azure HDInsight.

Vue d’ensemble

Vous pouvez faire face aux scénarios courants ci-dessous

  • Le même travail Spark est plus lent qu’auparavant dans le même cluster HDInsight
  • Le travail Spark est plus lent dans le cluster HDInsight que le fournisseur de services local ou tiers
  • Le travail Spark est plus lent dans un cluster HDI qu’un autre cluster HDI

Les performances de vos tâches Apache Spark dépendent de plusieurs facteurs. Ces facteurs de performance comprennent :

  • Comment vos données sont stockées
  • Comment le cluster est configuré
  • Opérations utilisées lors du traitement des données.
  • Service yarn non sain
  • Contraintes de mémoire dues à des exécuteurs de taille incorrecte et à OutOfMemoryError
  • Trop de tâches ou trop peu de tâches
  • L’asymétrie des données a provoqué quelques tâches lourdes ou des tâches lentes
  • Les tâches sont plus lentes dans les nœuds incorrects

Étape 1 : Vérifier si votre service yarn est sain

  1. Accédez à l'interface utilisateur Ambari :
  • Vérifier si Les alertes ResourceManager ou NodeManager
  • Vérifier l’état ResourceManager et NodeManager dans YARN > SUMMARY : Tous les NodeManager doivent être démarrés et seuls Les ResourceManager actifs doivent être démarrés

  1. Vérifier si l’interface utilisateur Yarn est accessible via https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster

  2. Vérifier si des exceptions ou des erreurs dans le journal ResourceManager se connectent /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Voir plus d’informations dans Yarn Common Issues

Étape 2 : Comparer vos nouvelles ressources d’application avec les ressources disponibles yarn

  1. Accédez au RÉSUMÉ YARN > de l’interface utilisateur > Ambari, vérifiez CLUSTER MEMORY dans ServiceMetrics

  2. Vérifiez les métriques de file d’attente yarn en détail :

  • Accédez à l’interface utilisateur Yarn, vérifiez les métriques du planificateur Yarn via https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • Vous pouvez également vérifier les métriques du planificateur yarn via l’API Rest Yarn. Par exemple : curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Pour ESP, vous devez utiliser l’utilisateur administrateur de domaine.
  1. Calculer le nombre total de ressources pour votre nouvelle application
  • Toutes les ressources d’exécuteurs : spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Voir plus d’informations dans la configuration des exécuteurs Spark
  • ApplicationMaster
    • En mode cluster, utilisez spark.driver.memory et spark.driver.cores
    • En mode client, utilisez spark.yarn.am.memory+spark.yarn.am.memoryOverhead et spark.yarn.am.cores

Notes

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

  1. Comparer les ressources totales de votre nouvelle application avec les ressources disponibles yarn dans votre file d’attente spécifiée

Étape 3 : Suivre votre application Spark

  1. Surveiller votre application Spark en cours d’exécution via l’interface utilisateur Spark

  2. Surveiller votre application Spark complète ou incomplète via l’interface utilisateur du serveur d’historique Spark

Nous devons identifier les symptômes ci-dessous via l’interface utilisateur Spark ou l’interface utilisateur de l’historique Spark :

  • Quelle étape est lente
  • Nombre total d’exécuteurs processeur v-cores entièrement utilisés dans Event-Timeline dans l’onglet Étape
  • Si vous utilisez spark sql, quel est le plan physique dans l’onglet SQL
  • DAG est trop long dans une phase
  • Observer les métriques de tâches (taille d’entrée, taille d’écriture aléatoire, heure GC) sous l’onglet Phase

Voir plus d’informations dans Suivre votre application Spark

Étape 4 : Optimiser votre application Spark

Il existe de nombreuses optimisations qui peuvent vous aider à surmonter ces difficultés, telles que la mise en cache et la prise en compte de l'asymétrie des données.

Dans chacun des articles suivants, vous trouverez des informations sur les différents aspects de l’optimisation de Spark.

Optimiser les partitions Spark SQL

  • spark.sql.shuffle.paritions est 200 par défaut. Nous pouvons ajuster en fonction des besoins métier lors de la redistribution des données pour les jointures ou les agrégations.
  • spark.sql.files.maxPartitionBytes est 1G par défaut dans HDI. Le nombre maximal d'octets à compresser dans une seule partition lors de la lecture de fichiers. Cette configuration est effective uniquement lors de l’utilisation de sources basées sur des fichiers telles que Parquet, JSON et ORC.
  • AQE dans Spark 3.0. Voir Exécution de requête adaptative.

Étapes suivantes