Checklist d'exploitation Apache Spark en production avec exemples pratiques

Introduction

Exécuter Apache Spark en production est bien plus simple lorsqu'on standardise les étapes essentielles: bases de configuration, supervision, fiabilité, stockage, sécurité, tuning, maintenance et mises à niveau. Cette checklist pragmatique aide développeurs, consultants DevOps et équipes startup à réduire les incidents, raccourcir les temps de reprise et maîtriser les coûts, tout en respectant les SLA pour des traitements batch et streaming sur Kafka, HDFS, stockage objet et des ordonnanceurs comme Apache Airflow ou NiFi.

Vue d'ensemble du workflow

Suivez ce flux de bout en bout pour des opérations Spark fiables:

Planifier

Définir des SLOs: latence de job, retard de données, seuils de qualité et cibles de coûts.
Cartographier les dépendances: sources (Kafka, HDFS, S3), cibles (Parquet, Delta, JDBC), catalogues et ordonnanceurs.

Configurer

Définir des valeurs par défaut (cluster et Spark) et ne déroger que par exception.
Normaliser le nommage, les logs et les répertoires de checkpoint.

Déployer et valider

Dry-run sur échantillon, puis exécution « ombre » en lecture seule.
Promouvoir uniquement si les métriques clés et le budget d'erreurs sont respectés.

Superviser et alerter

Instrumenter métriques, journaux d'événements et logs. Câbler des alertes sur des indicateurs avancés.

Maintenir et sauvegarder

Faire tourner/compacter les données, nettoyer les checkpoints et sauvegarder les catalogues.

Mettre à niveau en sécurité

Tester sur un staging réaliste, prévoir un rollback et garder un diff de config.

Bases de configuration

Figez un profil par défaut sûr avant de monter en charge ou d'embarquer d'autres équipes.

Exemple de spark-defaults.conf (à adapter à votre volumétrie):

# Exécution
spark.serializer=org.apache.spark.serializer.KryoSerializer
spark.sql.shuffle.partitions=400                # selon la taille des données
spark.sql.adaptive.enabled=true                 # AQE
spark.sql.adaptive.coalescePartitions.enabled=true
spark.sql.adaptive.skewJoin.enabled=true

# Élasticité des ressources
spark.dynamicAllocation.enabled=true
spark.shuffle.service.enabled=true
spark.dynamicAllocation.minExecutors=2
spark.dynamicAllocation.maxExecutors=100        # cap selon budget et SLA
spark.dynamicAllocation.initialExecutors=4

# Mémoire et CPU (à ajuster)
spark.executor.instances=10
spark.executor.cores=4
spark.executor.memory=8g
spark.driver.memory=4g
spark.memory.fraction=0.6

# Fiabilité et timeouts
spark.network.timeout=600s
spark.sql.broadcastTimeout=300
spark.task.maxFailures=4
spark.speculation=true                          # rattraper les tasks lentes

# I/O et compression
spark.sql.parquet.compression.codec=zstd
spark.sql.parquet.filterPushdown=true
spark.sql.files.maxPartitionBytes=134217728     # 128 MB

Astuces Hadoop / stockage objet (dans spark-defaults ou core-site.xml):

# S3A (si stockage compatible S3)
spark.hadoop.fs.s3a.fast.upload=true
spark.hadoop.fs.s3a.connection.maximum=200
spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2

Conventions évitant les erreurs:

Répertoires de checkpoint et de staging distincts par application.
Noms d'applications (spark.app.name) incluant propriétaire, usage et env.
Versions des connecteurs verrouillées et compatibles avec Spark/Scala.

Supervision et alerting

Une télémétrie minimale mais efficace = métriques, journaux d'événements et logs.

Métriques

Activez le système de métriques Spark et exposez un sink récupérable (ex. Prometheus via JMX/servlet). Suivez:
Durée des jobs, stages échoués, retries de tasks
Nombre d'exécuteurs, exécuteurs perdus, temps de GC, heap JVM
Shuffle read/write, spill disque, mémoire de stockage
Streaming structuré: lignes en entrée/traitées, offsets, métriques du state store

Exemple metrics.properties:

*.sink.jmx.class=org.apache.spark.metrics.sink.JmxSink
master.sources.jvm.class=org.apache.spark.metrics.source.JvmSource
worker.sources.jvm.class=org.apache.spark.metrics.source.JvmSource
driver.sources.jvm.class=org.apache.spark.metrics.source.JvmSource
executor.sources.jvm.class=org.apache.spark.metrics.source.JvmSource

Journaux d'événements et UI

Activez la journalisation d'événements vers un stockage durable pour les post-mortems.
Définissez une politique de rétention et indexez-les pour la recherche.

Logs

INFO en production; DEBUG seulement pour un diagnostic ciblé.
Rédigez les secrets et PII dans les logs.

Idées d'alertes

Batch: p95 de durée > SLO; taux de retry de stage > N%; ratio de spill en hausse.
Streaming: lag d'entrée qui grandit pendant M minutes; erreurs d'écriture de checkpoint; pics de temps de traitement.
Infra: exécuteurs perdus > seuil; GC du driver > 20%; disque plein sur volumes de shuffle.

Fiabilité des jobs et ordonnancement

Rendez les jobs redémarrables et idempotents.

Batch

Partitionnement d'entrée: bornes stables (date, heure, intervals d'IDs).
Écritures idempotentes: overwrite par partition ou merge.
Retries: autoriser les retries de tasks, mais les borner pour éviter les tempêtes de retries.

Streaming structuré

Toujours définir un checkpointLocation durable.
Préférer des sinks exactly-once; sinon, at-least-once avec déduplication.
Contrôler la charge via trigger intervals et backpressure.

Exemple: Kafka → Parquet avec checkpointing (Scala):

val df = spark.readStream
  .format("kafka")
  .option("kafka.bootstrap.servers", "broker:9092")
  .option("subscribe", "events")
  .option("startingOffsets", "latest")
  .load()
  .selectExpr("CAST(value AS STRING) as json")

val parsed = spark.read.json(df.select("json").as[String])

parsed.writeStream
  .format("parquet")
  .option("path", "/data/events_parquet")
  .option("checkpointLocation", "/chk/events_parquet")
  .outputMode("append")
  .start()

Intégration d'ordonnancement (concept Airflow Spark submit):

Définir des retries exponentiels.
Émettre des métriques et alerter en cas d'échec.
Appliquer des SLA par tâche de DAG et les exposer sur des tableaux de bord.

Stockage des données et I/O

Formats et partitionnement

Utilisez Parquet (colonnaire) avec projection et predicate pushdown.
Partitionnez par colonnes à faible cardinalité et haute sélectivité (date, heure, pays).
Évitez la sur-partition: ciblez des fichiers de sortie de 128 à 512 Mo.

Petits fichiers

En batch: écrire moins de fichiers plus gros via coalesce ou coalescing AQE.
Tâche de compactage périodique: relire et réécrire à la taille cible.

Shuffle et jointures

Réduire le shuffle en filtrant/sélectionnant tôt.
Diffuser (broadcast) les petites tables de dimension; régler le seuil:

spark.sql.autoBroadcastJoinThreshold=104857600   # 100 MB

Débit

Augmenter le parallélisme via les splits et partitions d'entrée.
Pour S3-like, augmenter prudemment connexions et taille multipart.

Sécurité et gouvernance

Réseau/transport: activer TLS pour l'UI Spark, RPC et shuffle si supportés.
AuthN/AuthZ: Kerberos ou rôles IAM; éviter les clés statiques sur disque.
Secrets: monter via des fournisseurs sécurisés; ne jamais les journaliser.
Données: chiffrement au repos; restreindre les buckets/HDFS par rôle.
Audit: collecter les logs d'accès des données et du metastore.
Rédaction des logs: masquer tokens, emails et identifiants.

Coûts et optimisation des performances

Taille des exécuteurs

Démarrer avec 4 cœurs et 6-8 Go; ajuster selon spill et GC.
Garder assez de parallélisme pour saturer sans thrash.

Adaptive Query Execution (AQE)

spark.sql.adaptive.enabled=true
spark.sql.adaptive.skewJoin.enabled=true

Laisse Spark coalescer les partitions et atténuer le skew à l'exécution.

Comptes de partitions

Règle empirique: 1-3 tâches par cœur CPU; valider via les timelines de stages.

Mitigation du skew

Saler les clés biaisées ou utiliser l'AQE skew join; vérifier via la heatmap de temps des tasks dans l'UI.

Caching

Mettre en cache seulement en cas de réutilisation multiple et mémoire suffisante. En streaming, préférer le checkpoint pour les longues lignées.

Allocation dynamique

Régler min, max et timeouts d'inactivité selon SLA et coûts.

Instances spot/préemptibles (si applicable)

Utiliser avec allocation dynamique; tester la perte d'exécuteurs et s'assurer des progrès checkpointés.

Maintenance et sauvegardes

État et logs

Checkpoints: ne pas supprimer des checkpoints actifs; nettoyer après reset complet uniquement.
Journaux d'événements: rotation et archivage avec politiques de cycle de vie.
Disques de shuffle: surveiller l'espace et l'usure; alerter bien avant saturation.

Catalogue et métadonnées

Sauvegarder le Hive metastore ou le catalogue cloud selon un planning.
Versionner et sauvegarder spark-defaults.conf, configs de logs et définitions de jobs.

Hygiène des données

Compactage: jobs réguliers pour fusionner les petits fichiers.
Vacuum: retirer d'anciens snapshots si le format de table le permet.

Préparation aux sinistres

Documenter les runbooks de reprise. Tester des restaurations trimestrielles.

Mises à niveau et retours arrière

Avant mise à niveau

Vérifier matrice de compatibilité: Spark, Scala, Java, connecteurs, libs Hadoop.
Revoir les changements de comportement SQL et de valeurs par défaut.
Recompiler les UDFs si des binaires/ABIs ont changé.

Déploiement progressif

Lancer des canaries avec données proches de la production.
Comparer aux baselines: durée, spill, shuffle, GC, coût.

Plan de rollback

Conserver images et configs précédentes.
Automatiser le rollback et le basculement des chemins de données si possible.

Pièges courants en production

Skew de données
Symptôme: quelques tasks durent beaucoup plus longtemps.
Correctif: AQE skew join, salage de clés, pré-agrégation.

Inondation de petits fichiers
Symptôme: trop de petits Parquet; lectures lentes, coût métadonnées élevé.
Correctif: coalesce à l'écriture, AQE coalesce, jobs de compactage.

Checkpoints manquants en streaming
Symptôme: doublons ou retraitements après redémarrage.
Correctif: définir checkpointLocation et utiliser des sinks idempotents.

Surcharge du driver
Symptôme: OOM driver ou longues pauses de GC.
Correctif: réduire collect() et les traitements côté driver; augmenter la mémoire driver.

Sur-usage des UDFs Python
Symptôme: lenteurs dues à la sérialisation.
Correctif: fonctions SQL natives ou pandas UDFs lorsque pertinent.

Mauvais réglage des partitions de shuffle
Symptôme: cluster sous-utilisé ou surcoûts d'overhead.
Correctif: régler spark.sql.shuffle.partitions; laisser l'AQE coalescer.

Plan pilote local

Démarrez petit, mesurable et inspectable localement avant la production.

Périmètre

Un job batch représentatif et un job streaming de courte durée.
Volume: 10-50 Go en batch; 1-5 partitions en entrée streaming.

Environnement

Exécuter Spark en mode local pour la première validation:

spark.master=local[*]

Métriques de succès

Batch: p95 dans la cible; 0 stages échoués; fichiers de sortie ~128-512 Mo.
Streaming: temps par trigger stable; lag sous le seuil; aucun échec de checkpoint pendant 24 h.

Exercices d'échec

Tuer un exécuteur ou simuler une panne réseau; vérifier retries et idempotence.
Corrompre un fichier d'entrée; vérifier l'isolation et le reporting d'erreur.

Checklist de promotion

Configs figées/versionnées; métriques et alertes actives; runbooks à jour.
Étapes de rollback testées; version précédente prête à redéployer.

Conclusion

Un environnement Apache Spark production fiable repose sur des bases de configuration claires, une supervision actionnable et des jobs redémarrables. Ajoutez des garde-fous de stockage et de sécurité, optimisez coûts et performances, entretenez vos états et métadonnées, sauvegardez régulièrement et montez de version par étapes avec un plan de rollback. Appliquez cette checklist, suivez quelques indicateurs avancés et itérez à chaque livraison pour garder vos opérations Apache Spark prévisibles et économiques.