Détection d'anomalies ultra-rapide avec le mode temps réel d'Apache Spark

Cet article présente un modèle réutilisable pour les charges de travail opérationnelles qui font vraiment la différence : détection de la fraude, surveillance des capteurs IoT, personnalisation en temps réel, traitement des signaux de sécurité — tout scénario où une réponse immédiate aux événements est essentielle pour les résultats de l'entreprise.

L'objectif principal : lorsqu'un événement semble suspect ou non valide, signalez-le immédiatement et orientez-le vers l'action appropriée en aval.

Dans ce blog, nous présentons une démonstration de détection d'anomalies sur les transactions de la blockchain Ethereum. Nous analysons les données de la blockchain Ethereum et signalons les transactions présentant des schémas non valides en temps réel. Plus précisément, nous détectons :

1. Violations de la qualité des données : les blocs où gas_used > gas_limit sont physiquement impossibles selon le protocole Ethereum, ce qui indique une corruption des données, des bugs du producteur ou des échecs d'analyse de schéma
2. Violations de l'hygiène de la charge utile : le champ extra_data contenant des modèles identifiables de PII ou d'identifiants (adresses e-mail, jetons JWT, clés d'accès AWS) signale une fuite de données ou des producteurs mal configurés

Bien que nous utilisions les données Ethereum pour cette démonstration, cette classification « suspect ou non valide » s'applique à de nombreux cas d'usage à forte valeur ajoutée :

• Détection de la fraude : une transaction présente des schémas anormaux → déclenchement des processus d'investigation en aval
• Surveillance IoT : la lecture d'un capteur dépasse les paramètres physiquement possibles → déclenchement d'une réponse automatisée
• Opérations de sécurité : la charge utile contient des secrets ou des modèles de PII → mise en quarantaine en temps réel avec une gouvernance unifiée
• Moteurs de personnalisation : répondre à des événements comportementaux spécifiques par des offres contextuelles immédiates

La même logique de détection s'applique directement à n'importe quel domaine : transactions financières contenant des PII inattendues, charges utiles IoT avec des relevés de capteurs hors plage, ou journaux d'événements API contenant des secrets qui auraient dû être masqués. Le flux Ethereum fournit un ensemble de données propre et reproductible pour illustrer ce modèle à grande échelle.

À propos du mode Real-Time de Spark

Le mode Real-Time (RTM) est un nouveau type de déclencheur pour Apache Spark™ Structured Streaming qui offre une latence de l'ordre de la milliseconde aux API Spark — sans nécessiter de moteur spécialisé distinct comme Apache Flink.

Alors que le mode micro-batch par défaut de Structured Streaming fonctionne comme une navette d'aéroport qui attend de se remplir avant de partir, le RTM fonctionne comme un trottoir roulant à grande vitesse, traitant chaque événement à mesure qu'il arrive. Il y parvient grâce à trois innovations architecturales : le flux de données continu (les événements sont traités à mesure qu'ils arrivent, et non par blocs distincts), la planification de pipeline (toutes les étapes de la requête s'exécutent simultanément, sans blocage) et le streaming shuffle (les données sont transmises immédiatement en mémoire entre les tâches, en évitant le disque).

Le RTM est conçu spécifiquement pour les charges de travail opérationnelles où la latence a un impact direct sur les résultats de l'entreprise — détection de la fraude, personnalisation en temps réel, calcul de caractéristiques ML et surveillance IoT. Pour les charges de travail qui peuvent tolérer 1 à 2 secondes de latence, le micro-batch traditionnel reste le choix le plus rentable.

Pourquoi le RTM change la donne

1. Ultra-rapide : une latence inférieure à la seconde désormais possible

Le mode Real-Time change fondamentalement la donne avec Apache Spark. Les latences de bout en bout allant de ~5 ms à ~300 ms, selon la complexité de la charge de travail, propulsent Spark sur le terrain auparavant dominé par les moteurs de traitement de flux spécialisés. Le micro-batch traditionnel offre une latence de 1 à 2 secondes ; le mode Real-Time atteint ~5 ms à ~300 ms.
L'architecture y parvient grâce à des pipelines d'exécution pré-alloués et à un checkpointing asynchrone, éliminant la surcharge de planification qui limitait traditionnellement le traitement par micro-batch. Pour les charges de travail opérationnelles où chaque milliseconde compte — détection de la fraude, surveillance IoT, offres en temps réel — ce niveau de performance est transformateur.

2. Stack simplifiée : aucune technologie distincte requise

Les entreprises sont souvent confrontées à une idée reçue coûteuse : « Spark n'est pas assez performant pour les cas d'usage en temps réel, nous avons donc besoin d'une stack entièrement distincte pour ce besoin spécifique. »

Pour les charges de travail tolérant 1 à 2 secondes de latence, le micro-batch de Spark transfère de manière fiable les données dans Delta Lake avec d'excellentes performances à un coût optimisé. Pour les charges de travail opérationnelles exigeant des temps de réponse inférieurs à la seconde, le mode Real-Time élimine complètement le besoin de technologies distinctes — comme l'ont validé les équipes de Coinbase, DraftKings et MakeMyTrip, qui ont regroupé leurs activités sur une seule stack basée sur Spark pour leurs charges de travail analytiques et opérationnelles.

Avec le mode Real-Time, Spark gère à la fois les charges de travail analytiques (de l'ordre de la seconde) et opérationnelles (de l'ordre de la milliseconde) au sein d'une plateforme unique et unifiée. Cela permet de réduire :

• La complexité opérationnelle : une seule stack technologique à gérer, surveiller et dépanner
• Les coûts de formation : l'expertise Spark existante se transpose directement aux cas d'usage en temps réel
• Les frictions d'intégration : pas de transferts complexes entre des moteurs de streaming distincts
• Le coût total de possession : la consolidation réduit les coûts d'infrastructure, de licence et d'exploitation

3. Convivial pour les développeurs : un simple changement de déclencheur, pas de réécriture de code

L'aspect le plus séduisant du mode Real-Time est sans doute sa remarquable simplicité pour les développeurs déjà familiers avec Structured Streaming. L'activation de cette puissante fonctionnalité ne nécessite aucune migration complexe ni restructuration fondamentale du code.

Les entreprises peuvent débloquer une latence de l'ordre de la milliseconde en modifiant simplement la configuration du déclencheur :

C'est tout. La même API Structured Streaming familière. La même gestion des checkpoints. La même sémantique de livraison au moins une fois. Juste un changement de configuration pour activer une intelligence opérationnelle inférieure à la seconde.

Remarque sur les garanties de livraison : le RTM avec un récepteur Kafka fournit des garanties de livraison au moins une fois. Les consommateurs en aval doivent gérer les doublons potentiels via des écritures idempotentes ou une logique de déduplication.

Cette intégration transparente représente un avantage crucial. Les équipes peuvent prototyper et mettre en production des charges de travail opérationnelles sans la lourde charge d'apprentissage, de déploiement et de gestion de stacks technologiques entièrement distinctes. Cette approche accélère considérablement l'innovation tout en réduisant les risques traditionnellement associés à l'adoption de nouvelles capacités en temps réel.

Après avoir établi l'importance du mode Real-Time, examinons comment mettre en œuvre ce modèle en pratique. Les sections suivantes présentent un pipeline de garde-fous prêt pour la production — le modèle opérationnel qui transforme ces capacités en valeur commerciale.

Présentation de l'architecture : création d'un flux de garde-fous opérationnels

Chaque événement entrant fait l'objet d'une évaluation immédiate, produisant un événement enrichi en aval contenant :

• Décision : ALLOW par rapport à QUARANTINE
• Motifs : explication détaillée de tous les drapeaux déclenchés (violations de la qualité des données, problèmes d'hygiène de la charge utile)

Ce modèle opérationnel sert de source unique de vérité pour la prise de décision en temps réel :

• Cet événement doit-il être mis en quarantaine pour investigation ?
• Comment enrichir les événements pour que les systèmes en aval puissent réagir instantanément ?

Bien que notre démonstration utilise des données de blocs Ethereum, ce modèle s'applique universellement : transactions financières, relevés de capteurs, journaux d'authentification, appels API — l'architecture reste cohérente.

Validation à grande échelle

Fidèles à notre engagement de fournir des solutions de qualité production, nous avons validé ce modèle à grande échelle. La chaîne Ethereum complète — environ 95 GB répartis sur 4 partitions, représentant environ 23 millions de messages — a été chargée dans Kafka pour les tests.

Définir des règles de validation pour la classification des événements

Nous implémentons des règles de validation intentionnellement simples et à fort signal :

Règle 1 : Validation de l'hygiène des charges utiles (payloads)

Analysez le champ extra_data à la recherche de motifs qui indiquent clairement des données qui ne devraient pas être présentes dans les flux de production. Les exemples de code illustrent une détection de motifs de base (adresses e-mail, jetons JWT, formats de clés AWS).

Les organisations doivent les remplacer par des règles spécifiques à leurs exigences de conformité — motifs PII, identifiants internes, identifiants API et autres données sensibles similaires.

L'élément clé : Les garde-fous en temps réel doivent être intégrés au pipeline dans le cadre d'une gouvernance unifiée, et non découverts lors de l'analyse post-incident.

Règle 2 : Validation de la qualité des données

gas_used > gas_limit

Cette condition ne devrait jamais se produire dans des données valides. Lorsqu'elle est détectée, elle indique l'un des problèmes suivants :

• Corruption des données lors de la transmission
• Erreurs de génération de données côté producteur
• Incohérences d'analyse de schéma
• Défaillances du système en amont

D'un point de vue opérationnel, c'est précisément le type d'anomalie que nous voulons signaler immédiatement — permettant une réponse rapide avant que les systèmes en aval ne soient affectés.

Une fois notre logique de validation établie, nous passons à la configuration du streaming qui permet une exécution en moins d'une seconde.

Mode Real-Time : Configuration essentielle

Le mode Real-Time est activé via le déclencheur (trigger) temps réel et fonctionne en mode update. En PySpark, vous spécifiez un paramètre d'intervalle (par exemple, "5 minutes").

Deux exigences de configuration critiques :

1. Configuration du cluster : La documentation Databricks spécifie les paramètres de cluster de tâches requis et le drapeau (flag) d'activation du RTM
2. Mode de sortie (Output mode) : Doit utiliser le mode update avec les déclencheurs (triggers) RTM

Configuration utilisée dans cette démo :

• Runtime : Databricks Runtime 16.4 LTS ou version ultérieure
• Calcul (Compute) : Cluster dédié (mono-utilisateur) avec un nombre fixe de workers (mise à l'échelle automatique/autoscaling désactivée)
• Photon : Désactivé (non pris en charge avec le RTM)
• Workers : 4 workers pour cette charge de travail
• Mode de sortie : update (requis pour le RTM)

Consultez le dépôt associé pour obtenir le fichier cluster_config.template.json complet.

Implémentation : Pipeline de garde-fous en temps réel

Ce pipeline à passage unique démontre une intégration transparente entre Kafka et le mode Spark Real-Time :

1. Se connecter à la source Kafka
2. Analyser les charges utiles (payloads) JSON entrantes
3. Calculer la décision et les motifs
4. Réécrire le JSON enrichi dans Kafka

Vous pouvez lire le code ici.

Résultats : Performance à grande échelle

Nous avons validé les performances du mode Real-Time en traitant les données de la blockchain Ethereum — environ 23 millions de messages répartis sur 4 partitions Kafka en mode streaming continu.

Performances de débit

Le pipeline a présenté des caractéristiques de débit impressionnantes :

• Taux d'entrée : 65 592 lignes/seconde
• Taux de traitement : 69 713 lignes/seconde (soutenu)
• Total des enregistrements traités : environ 23 213 628 messages
• Configuration du cluster : DBR 16.4 LTS, 4 workers (i3.xlarge), mode mono-utilisateur dédié, Photon désactivé

Mesures de latence

Les journaux du pilote (driver logs) capturent des mesures de latence détaillées via l'événement spark.streaming.madeProgress. Le mode Real-Time signale processingLatencyMs, qui mesure le temps écoulé entre le moment où la requête lit un enregistrement et celui où elle l'écrit dans le récepteur (sink) en aval.

Pour ce pipeline de validation sans état (stateless) traitant environ 23 millions d'enregistrements, nous avons observé :

• P0, P50, P90, P95 : 1 milliseconde (arrondi à 0 dans les mesures) P99 : 1 milliseconde Taux de traitement : 69 713 lignes/seconde soutenu
• Comprendre processingLatencyMs : Cette mesure évalue le temps écoulé entre la lecture d'un enregistrement par le RTM et son écriture dans le récepteur (sink) en aval. Elle est mesurée par tâche et signalée dans la section rtmMetrics.processingLatencyMs de StreamingQueryProgress avec des percentiles (P0, P50, P90, P95, P99). Pour un pipeline Kafka-to-Kafka à étape unique comme celui-ci, elle représente concrètement la latence de bout en bout par enregistrement.
• Ce que cela signifie : La grande majorité des enregistrements (95e percentile) ont été traités en moins d'une demi-milliseconde, et même le 1 % le plus lent s'est terminé en moins d'une milliseconde. Les valeurs affichant « 0 » pour P0-P95 indiquent des latences inférieures à 0,5 ms (arrondies à l'inférieur par le système de mesures).

Remarque : Ces résultats représentent les performances sur un pipeline de validation sans état (stateless). Des opérations avec état (stateful) plus complexes (agrégations, fenêtrage) peuvent présenter des latences plus élevées, de l'ordre de ~5 ms à ~300 ms pour le RTM, selon la complexité de la charge de travail.

Principaux enseignements sur les performances

• Interprétation : 99 % de tous les enregistrements ont été traités en moins d'une milliseconde, seul le 1 % le plus lent atteignant 1 milliseconde. Cela démontre des performances à faible latence exceptionnellement constantes.
• Débit : Le pipeline a maintenu un débit de 69 713 lignes/seconde tout en traitant environ 23 millions d'enregistrements, démontrant des performances stables sous une charge continue.

Ces mesures valident que le mode Real-Time offre une latence inférieure à la milliseconde de qualité production (P95 0,5 ms, P99 = 1 ms) tout en traitant des flux à haut volume à près de 70 000 lignes/seconde — éliminant ainsi le compromis traditionnel entre plateformes unifiées et exigences de faible latence.

Conclusion

Le mode Real-Time étend Apache Spark™ Structured Streaming à une nouvelle classe de charges de travail — des applications opérationnelles et sensibles à la latence qui exigent une réponse immédiate aux données en streaming. En apportant une latence inférieure à la seconde aux API Spark que votre équipe utilise déjà, il élimine le besoin d'exploiter un moteur spécialisé distinct pour vos pipelines les plus critiques en termes de temps.

La proposition de valeur est convaincante :

• Une plateforme unifiée gère à la fois les charges de travail analytiques (de l'ordre de la seconde) et opérationnelles (de l'ordre de la milliseconde)
• L'expertise Spark existante se transfère directement — aucune spécialisation distincte n'est requise
• Risque de migration minimal — un simple changement de configuration du déclencheur (trigger) débloque des capacités en temps réel
• Performances validées en production — latences P99 de 1 ms avec un P95 inférieur à 0,5 ms lors du traitement de millions d'événements

Que vous construisiez des pipelines de détection des fraudes, des moteurs de personnalisation ou des systèmes de calcul de caractéristiques (features) ML, le mode Real-Time offre la latence requise par votre application tout en préservant la simplicité et la richesse de l'écosystème de Spark.

Prise en main

Clonez le dépôt associé pour exécuter ce pipeline de garde-fous de bout en bout — il comprend l'implémentation complète, la configuration du cluster et le guide de déploiement.

Pour aller plus loin, consultez la documentation du mode Real-Time pour connaître les options de configuration et les sources/récepteurs (sinks) pris en charge, ou regardez la présentation technique approfondie du mode Real-Time pour découvrir l'architecture complète.

Ressources

• Plongée technique au cœur du mode temps réel : comment nous avons intégré le streaming inférieur à 300 millisecondes dans Apache Spark™
• Garantir une latence inférieure à la seconde pour les charges de travail opérationnelles sur Databricks
• Documentation du mode temps réel Databricks
• Dépôt de code associé - Démo des garde-fous du mode temps réel - Implémentation prête pour la production avec suite de tests complète, configuration de cluster et guide de déploiement

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original