Concepts avancés d'Apache Spark expliqués avec des exemples pratiques

Introduction

Apache Spark est devenu le moteur de traitement de facto pour les charges de travail de données à grande échelle, mais dépasser les transformations DataFrame de base nécessite une compréhension approfondie de ses mécanismes internes. Ce guide explique les concepts avancés d'Apache Spark avec des exemples pratiques pour aider les opérateurs et les développeurs à passer de l'observation d'un problème à la mise en œuvre d'une solution vérifiée.

Cet article s'adresse aux ingénieurs de données, aux consultants DevOps et aux équipes techniques de startups qui doivent exécuter Spark de manière fiable en production. Il relie les internes d'Apache Spark, son architecture, ses mécanismes détaillés et des exemples concrets aux commandes, sorties attendues, signaux de défaillance et décisions de récupération pertinents pour votre environnement.

La philosophie opérationnelle tout au long de ce guide est la sécurité d'abord : observer avant de changer, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier les résultats et documenter les chemins de récupération. Vous apprendrez à appliquer ces principes à la gestion de la configuration, au diagnostic et à la récupération après défaillance dans des déploiements Spark réels.

Inventaire de la version et de l'environnement

Avant d'apporter toute modification à un cluster ou à une application Spark, vous devez comprendre exactement ce que vous exécutez. Un inventaire de version et d'environnement fournit la base de référence pour toutes les décisions ultérieures.

Identifiez la version installée et la topologie de déploiement à l'aide de commandes en lecture seule. Pour une installation Spark, commencez par vérifier la version sur le nœud pilote :

spark-submit --version

La sortie attendue inclut la version de Spark, la version de Scala et les informations de build. Par exemple :

Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 3.5.0
      /_/

Using Scala version 2.12.18, OpenJDK 64-Bit Server VM, 1.8.0_392

Si vous utilisez un service géré comme Databricks ou Amazon EMR, utilisez l'interface utilisateur du cluster ou l'interface en ligne de commande pour obtenir la version du runtime. Pour Databricks, la version du Runtime est affichée dans la configuration du cluster. Pour EMR, vous pouvez lister les applications installées :

aws emr describe-cluster --cluster-id <cluster-id> --query 'Cluster.Applications'

La sortie attendue liste Spark avec sa version, par exemple Spark 3.5.0.

Ensuite, capturez la topologie de déploiement. Exécutez-vous Spark en mode autonome, sur YARN, Kubernetes ou un service géré ? Le mode de déploiement affecte l'allocation des ressources, les emplacements de configuration et le dépannage.

Pour un cluster autonome, vérifiez l'URL du maître et l'état des travailleurs à l'aide de l'interface Web Spark (port par défaut 8080) ou de l'API REST :

curl http://<nœud-maître>:8080/json/

La sortie JSON attendue inclut aliveworkers, cores, memory et status. Si le maître n'est pas joignable, c'est votre premier signal de diagnostic.

Pour YARN, confirmez que Spark soumet correctement les tâches :

yarn application -list -appStates RUNNING

Pour Kubernetes, listez les pods Spark :

kubectl get pods -n spark-namespace

Les prérequis pour tout inventaire d'environnement incluent :

• Accès SSH au nœud pilote (si auto-géré)
• Permissions appropriées pour interroger les gestionnaires de cluster
• Accès en lecture seule aux fichiers de configuration tels que spark-defaults.conf, spark-env.sh et aux répertoires de journaux
• Pour les services gérés dans le cloud, des rôles IAM avec des permissions de description

Rayon d'impact : Toutes les commandes de cette section sont en lecture seule. Elles ne modifient pas l'état.

Vérification : Après avoir collecté les informations de version et de topologie, documentez-les dans un runbook partagé. Cet inventaire sera référencé dans les sections suivantes pour décider quels paramètres de configuration s'appliquent.

Chemin de configuration sécurisé

Modifier la configuration Spark sans approche systématique est une cause fréquente d'incidents en production. Cette section décrit un chemin de configuration sécurisé qui minimise les risques et permet un retour en arrière.

Étape 1 : Observer la configuration actuelle

Avant de changer un paramètre, capturez les valeurs de configuration actuelles. Pour une application Spark soumise via spark-submit, vous pouvez voir la configuration effective en examinant l'onglet Environnement de l'interface Spark ou en utilisant l'API REST :

curl http://<nœud-pilote>:4040/api/v1/applications/<app-id>/environment/

Pour spark-defaults.conf, affichez simplement le fichier :

cat $SPARK_HOME/conf/spark-defaults.conf

Pour Databricks, utilisez la page de configuration du cluster ou l'API pour voir la configuration Spark.

Étape 2 : Identifier le plus petit changement justifié

Évitez les changements en masse. Par exemple, si vous soupçonnez que les partitions de shuffle causent des problèmes de performance, changez uniquement spark.sql.shuffle.partitions au lieu de réécrire toute la configuration.

Étape 3 : Utiliser des espaces réservés explicites et protéger les secrets

Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans des fichiers de configuration ou des scripts susceptibles d'être versionnés. Utilisez des variables d'environnement ou des systèmes de gestion des secrets.

Exemple de configuration d'un mot de passe JDBC dans spark-submit à l'aide d'une variable d'environnement :

export DB_PASSWORD=<votre-mot-de-passe>  # Définir dans un environnement sécurisé
spark-submit \
  --conf "spark.jars=/chemin/vers/pilote/jdbc.jar" \
  --conf "spark.datasource.jdbc.password=${DB_PASSWORD}" \
  --class com.example.MyApp \
  myapp.jar

En production, utilisez un gestionnaire de secrets comme HashiCorp Vault, AWS Secrets Manager ou Kubernetes Secrets.

Étape 4 : Appliquer le changement de manière limitée

Pour les applications Spark, vous pouvez définir la configuration spécifiquement pour un seul travail à l'aide des options --conf. Cela limite le rayon d'impact à ce travail. Pour les changements au niveau du cluster, modifiez spark-defaults.conf seulement après avoir testé sur un environnement de préproduction.

Exemple : augmenter les partitions de shuffle pour un gros travail d'agrégation :

spark-submit \
  --conf "spark.sql.shuffle.partitions=2000" \
  --class com.example.AggregationJob \
  myapp.jar

Étape 5 : Vérifier le résultat

Après avoir appliqué le changement, vérifiez l'interface Spark ou les journaux pour confirmer que la valeur est effective. Pour l'exemple ci-dessus, dans l'interface Spark, sous l'onglet SQL, le nombre de partitions de shuffle doit être 2000 dans le plan de requête.

Chemin de récupération : Si le changement cause des problèmes, revenez à la valeur précédente. Comme le changement était limité à un seul travail ou fichier de configuration, le retour en arrière est simple. Pour spark-defaults.conf, conservez une copie de sauvegarde avant de modifier :

cp spark-defaults.conf spark-defaults.conf.bak

Puis restaurez si nécessaire.

Vérification et diagnostics

Un diagnostic efficace dans Spark nécessite de comprendre comment interroger l'état d'exécution et interpréter les métriques clés. Cette section couvre les techniques de vérification et les commandes de diagnostic.

1. Interface Web Spark

L'interface Web Spark est l'outil de diagnostic principal. Elle est disponible à <nœud-pilote>:4040 pour les applications en cours et sur le port 8080 pour le gestionnaire de cluster autonome.

Onglets clés :

• Jobs : Affiche les chronologies des travaux, les étapes et les détails des tâches.
• Stages : Affiche les métriques telles que la taille d'entrée, la lecture/écriture de shuffle et les durées des tâches.
• Storage : Montre les RDD et DataFrames mis en cache.
• Environment : Liste toutes les propriétés de configuration.
• Executors : Affiche l'utilisation des ressources des exécuteurs.

2. Journal des événements Spark

Pour une analyse post-mortem, activez la journalisation des événements pour écrire les événements Spark dans un emplacement persistant :

spark-submit ... --conf spark.eventLog.enabled=true --conf spark.eventLog.dir=hdfs:///spark-logs ...

Utilisez ensuite le serveur d'historique Spark pour consulter les journaux après la fin de l'application.

3. Commandes de diagnostic

Vérifiez l'état du cluster à l'aide de l'API REST :

curl http://<nœud-maître>:8080/api/v1/applications

La sortie attendue inclut toutes les applications en cours et terminées avec leur état.

Surveillez l'utilisation des ressources de l'application via le point de terminaison des métriques :

curl http://<nœud-pilote>:4040/metrics/json/

Cela renvoie du JSON avec des métriques comme jvm.heap.used, executor.totalInputBytes et executor.totalShuffleReadBytes.

4. Analyse des journaux

Les journaux Spark sont essentiels. Pour le mode autonome, les journaux se trouvent généralement sous $SPARK_HOME/logs/. Pour YARN, utilisez :

yarn logs -applicationId <app-id>

Pour Kubernetes, obtenez les journaux du pilote :

kubectl logs <nom-du-pod-pilote> -n spark-namespace

Recherchez les erreurs courantes :

• OutOfMemoryError : Mémoire de l'exécuteur ou du pilote trop faible.
• ShuffleFetchFailedException : Problèmes de réseau ou défaillances des exécuteurs.
• FileNotFoundException : Données d'entrée manquantes ou conditions de course.

5. Plans de requête Spark SQL

Pour diagnostiquer les problèmes de performance dans Spark SQL, utilisez EXPLAIN ou .explain() sur un DataFrame :

df = spark.read.parquet("chemin/vers/données")
df.filter("value > 10").groupBy("key").count().explain("extended")

La sortie attendue montre les plans analysé, optimisé et physique. Inspectez les opérations coûteuses comme les shuffles complets ou les jointures cartésiennes.

6. Observer avant de changer

Toutes les commandes de diagnostic de cette section sont en lecture seule. Elles vous aident à formuler des hypothèses avant d'apporter des modifications. Enregistrez toujours l'état actuel et l'horodatage avant toute intervention.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants de Spark et les stratégies de récupération est crucial pour maintenir des systèmes en production. Cette section décrit plusieurs scénarios de défaillance, leurs signaux et les étapes de récupération.

Défaillance 1 : Mémoire insuffisante de l'exécuteur (OOM)

Signal : Les journaux de l'exécuteur affichent java.lang.OutOfMemoryError: Java heap space ou OutOfMemoryError: GC overhead limit exceeded. Les échecs de tâches se produisent par intermittence.

Cause : Mémoire de l'exécuteur trop petite pour les données traitées, ou asymétrie des données amenant certaines tâches à charger plus de données que d'autres.

Récupération (avec précaution, rayon d'impact limité) :

• Augmentez la mémoire de l'exécuteur : --executor-memory 8g (ou plus, selon les ressources du cluster).
• Augmentez la surcharge mémoire de l'exécuteur : --conf spark.executor.memoryOverhead=2g.
• Pour l'asymétrie des données, envisagez de saler les clés ou d'utiliser l'exécution adaptative des requêtes (AQE) : --conf spark.sql.adaptive.enabled=true.

Vérifiez : Après ajustement, vérifiez l'interface Spark pour l'utilisation mémoire des tâches et assurez-vous qu'il n'y a pas d'erreurs OOM. Surveillez le temps de GC ; il doit être inférieur à 10 %.

Défaillance 2 : Échecs de récupération de shuffle

Signal : org.apache.spark.shuffle.MetadataFetchFailedException ou FetchFailedException dans les journaux. Nouvelles tentatives d'étapes et échecs de travaux.

Cause : Perte d'exécuteur pendant le shuffle, instabilité du réseau ou trop de demandes de shuffle simultanées.

Récupération :

• Augmentez les nouvelles tentatives de shuffle : --conf spark.shuffle.io.maxRetries=10.
• Augmentez le délai entre nouvelles tentatives : --conf spark.shuffle.io.retryWait=30s.
• Si la perte d'exécuteur est due à une OOM, traitez les problèmes de mémoire (voir ci-dessus).
• Vérifiez la bande passante réseau et envisagez de réduire les partitions de shuffle si elles sont trop volumineuses.

Vérifiez : Relancez le travail et observez les métriques de lecture/écriture de shuffle ; les échecs doivent être éliminés.

Défaillance 3 : Plantage du pilote ou blocage de l'application

Signal : La JVM du pilote se termine de manière inattendue, ou l'application ne répond plus. En mode client YARN, le processus client meurt.

Cause : Mémoire du pilote insuffisante, blocage du code ou défaillance d'une dépendance externe.

Récupération :

• Augmentez la mémoire du pilote : --driver-memory 4g.
• Pour les applications de longue durée, activez le point de contrôle pour permettre la récupération à partir d'un instantané.
• Utilisez spark-submit --deploy-mode cluster pour exécuter le pilote sur le cluster et améliorer la résilience.

Vérifiez : Surveillez les journaux du pilote et assurez-vous que l'application se termine ou continue comme prévu.

Défaillance 4 : Corruption de données ou fichiers manquants

Signal : FileNotFoundException ou IOException lors de la lecture de données.

Cause : Chemin d'entrée modifié, fichier supprimé ou problème de permissions.

Récupération :

• Vérifiez que le chemin des données existe et est accessible.
• Vérifiez les permissions du système de fichiers.
• Pour HDFS, exécutez hdfs fsck <chemin> -files -blocks -locations pour vérifier la santé des fichiers.

Vérifiez : Après correction, essayez de lire les données avec un travail Spark simple.

Principes généraux de récupération :

• Conservez des sauvegardes des configurations critiques.
• Utilisez le contrôle de version pour le code applicatif.
• Testez les procédures de récupération en préproduction avant la production.
• Documentez les modes de défaillance connus et leurs correctifs.

Liste de contrôle des opérations

Pour exécuter Apache Spark de manière fiable, utilisez cette liste de contrôle des opérations pour la vérification de routine et la gestion des changements.

Contrôles de santé de routine (quotidiens ou hebdomadaires)

1. Disponibilité des ressources du cluster :

   curl -s http://<nœud-maître>:8080/json/ | jq '.aliveworkers, .cores, .memory'

Attendu : le nombre de travailleurs actifs correspond aux nœuds attendus ; les cœurs et la mémoire sont dans les limites de capacité.

1. Applications en cours :

   spark-submit --status <app-id>  # Pour le mode autonome
   yarn application -status <app-id>  # Pour YARN

Utilisez l'interface du serveur d'historique ou interrogez l'API REST pour les applications terminées avec un état d'échec.

1. Vérifiez les travaux échoués au cours de la période passée :

Configurez des alertes pour OutOfMemoryError, FetchFailedException et Task not serializable dans les journaux d'application.

1. Surveillance des journaux :

Liste de contrôle avant changement

• [ ] Enregistrez la configuration et les métriques actuelles.
• [ ] Identifiez le plus petit changement pour atteindre l'objectif.
• [ ] Estimez le rayon d'impact : quelles applications ou utilisateurs sont affectés ?
• [ ] Préparez un plan de retour en arrière.
• [ ] Testez le changement en préproduction si possible.

Vérification après changement

• [ ] Appliquez le changement.
• [ ] Surveillez immédiatement la santé de l'application.
• [ ] Comparez les métriques avant/après (par exemple, durée du travail, taille du shuffle).
• [ ] Si des problèmes surviennent, exécutez le retour en arrière.

Documentation

Maintenez un runbook avec :

• La topologie du cluster et l'inventaire des versions.
• Les modes de défaillance courants et les étapes de récupération.
• L'historique des changements de configuration.
• Les coordonnées du support d'astreinte.

Conclusion

Les concepts avancés d'Apache Spark s'apprennent mieux par l'application pratique. Ce guide a fourni un cadre pour des opérations sûres, incluant l'inventaire des versions, la gestion de la configuration, les diagnostics et la récupération après défaillance. En suivant ces pratiques, vous pouvez réduire les risques et améliorer la fiabilité de vos déploiements Spark.

Points clés à retenir :

• Observez toujours l'état actuel avant d'apporter des modifications.
• Utilisez des commandes en lecture seule pour le diagnostic.
• Limitez la portée des changements et utilisez des espaces réservés pour les secrets.
• Vérifiez chaque changement et ayez un plan de retour en arrière.
• Surveillez les modes de défaillance connus et réagissez rapidement.

Comme prochaine étape, choisissez une tâche de vérification à faible risque de cet article, comme la vérification de votre version Spark et de votre environnement, et documentez les résultats. Ensuite, appliquez le chemin de configuration sécurisé à un seul paramètre et observez l'impact. À partir de là, développez un playbook opérationnel complet pour votre équipe.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.