Traitement de pistes en flux continu : pipelines à état pour la fusion en temps réel

La fusion de pistes en temps réel est, fondamentalement, un problème à état. Un retour radar, une interception SIGINT ou une détection UAV arrivant sur le réseau ne signifie rien isolément — sa valeur provient entièrement de sa mise en correspondance avec l'historique accumulé de chaque objet que le système croit déjà exister. Décider si une observation prolonge une piste existante ou en crée une nouvelle exige que le moteur se souvienne de tout ce qu'il a vu. Cette exigence unique — mémoire durable, mutable et par piste mise à jour à la cadence des capteurs — est ce qui sépare le traitement de pistes en flux des simples transformations sans état dont la plupart des pipelines de données sont construits. Cet article examine comment le traitement de flux à état est conçu pour la fusion en temps réel : le modèle d'état, le fenêtrage sur le temps d'événement, la sémantique exactly-once, le partitionnement pour la mise à l'échelle, et les modes de défaillance opérationnels qui font tomber ces pipelines.

Pourquoi la fusion de pistes est intrinsèquement à état

Un pipeline sans état applique une fonction pure à chaque événement et l'oublie. Ce modèle fonctionne pour l'enrichissement, la conversion de format ou le filtrage, mais il ne peut pas fusionner des pistes. La question de fusion — « cette observation appartient-elle à une piste que je maintiens déjà ? » — n'est répondable qu'en référence à l'état : l'estimation actuelle de position et de vitesse de chaque piste active, son incertitude (covariance), son dernier temps de mise à jour, et son historique d'association.

Concrètement, le moteur maintient un enregistrement par piste, indexé par un identifiant de piste stable. Cet enregistrement contient l'état du filtre de Kalman (ou à particules), l'horodatage de la dernière observation appliquée, un court historique des rapports de capteurs contribuants, et la classification et la confiance de la piste. Quand une nouvelle observation arrive, le moteur lit les états de pistes candidates, décide à quelle piste (le cas échéant) l'observation appartient en utilisant un algorithme de corrélation de pistes, mute l'état du filtre de la piste correspondante en place, et émet une mise à jour. Le magasin d'état est lu et écrit sur le chemin critique de chaque observation — c'est pourquoi sa conception domine les performances et la fiabilité de l'ensemble du système.

Le magasin d'état : où vit la mémoire des pistes

Dans un moteur de flux en production, l'état des pistes n'est pas conservé en mémoire applicative ordinaire. Il réside dans un magasin d'état géré et tolérant aux pannes que le framework peut mettre en point de contrôle et restaurer. Apache Flink soutient l'état indexé avec une instance RocksDB embarquée par tâche ; Kafka Streams matérialise l'état dans des magasins RocksDB locaux soutenus par un topic de changelog compacté qui permet une reconstruction complète après un crash. Dans les deux cas, le contrat est le même : le moteur vous fournit une table indexée — identifiant de piste vers état de piste — qui est locale, rapide et durable après redémarrage.

Les décisions de conception clés pour le magasin d'état sont la taille et le schéma d'accès. L'état de piste doit être compact : un vecteur moyen de filtre, une matrice de covariance, quelques champs de métadonnées, et un tampon circulaire borné de références d'observations récentes — pas l'historique complet des observations. L'historique non borné par piste est la cause la plus courante de débordement de l'état. L'accès est massivement lecture-modification-écriture sur une seule clé par observation, de sorte que le magasin est optimisé pour les recherches ponctuelles et les mises à jour en place plutôt que pour les balayages. Les balayages de plage, lorsqu'ils sont nécessaires pour le filtrage spatial, sont maintenus hors du chemin critique en conservant un index spatial secondaire mis à jour de manière asynchrone.

La sérialisation de l'état mérite une attention explicite. Parce que le framework écrit et lit l'état des pistes sur disque à chaque point de contrôle et reprise, le sérialiseur de la classe d'état de piste est un composant sur le chemin critique, pas un détail. Un sérialiseur réflexif et à schéma à la lecture qui parcourt les graphes d'objets par enregistrement dominera le CPU à des taux d'observation élevés ; un sérialiseur écrit à la main ou généré par code qui dispose l'état de filtre de taille fixe comme un tampon d'octets plat est souvent un ordre de grandeur plus rapide. La même discipline paie en taille de point de contrôle — les encodages d'état compacts à largeur fixe réduisent les instantanés et raccourcissent la fenêtre de récupération après une défaillance de nœud.

Borner la croissance de l'état

Chaque piste créée mais jamais expirée occupe de l'état indéfiniment. Un pipeline sans expiration disciplinée verra son magasin d'état croître de façon monotone jusqu'à ce que les points de contrôle ralentissent et que le moteur prenne du retard sur le temps réel. Trois mécanismes d'expiration fonctionnent ensemble : time-to-live (supprimer une piste qui n'a reçu aucune observation pendant N secondes), limites de comptage de manques (supprimer une piste qui a été prédite mais non mise à jour pendant M fenêtres attendues consécutives), et suppression hors zone d'intérêt (supprimer les pistes qui quittent la région opérationnelle). L'expiration n'est pas un ménage qui peut être différé — c'est une exigence de correction et de stabilité, et elle doit s'exécuter sur la même horloge de temps d'événement que le reste du pipeline afin de se comporter de manière identique lors du traitement en direct et du rejeu.

Temps d'événement, filigranes et fenêtrage

Les flux de capteurs n'arrivent pas dans l'ordre, et ils n'arrivent pas à temps. Un plot radar observé à 09:47:03.120 peut atteindre le moteur de fusion 400 ms plus tard qu'une interception SIGINT du même objet observée à 09:47:03.080, simplement parce que les deux flux traversent différents réseaux et étapes de traitement. Si le moteur corrélait par le temps d'arrivée des événements (temps de traitement), il échouerait régulièrement à associer des observations qui décrivent véritablement le même objet au même instant.

La fusion en flux s'indexe donc sur le temps d'événement — l'horodatage auquel le capteur a observé l'objet — et utilise des filigranes pour raisonner sur la complétude. Un filigrane est l'estimation du moteur selon laquelle aucun autre événement avec un temps d'événement antérieur au filigrane n'arrivera. Les fenêtres de corrélation se ferment quand le filigrane dépasse leur fin, plus une période de latence autorisée configurée qui maintient la fenêtre ouverte juste assez longtemps pour les retardataires. Les observations plus tardives que la période de grâce ne sont pas silencieusement supprimées ; elles sont routées vers une sortie secondaire afin que les analystes puissent auditer la quantité de données ayant manqué leur fenêtre et ajuster la période de grâce en conséquence.

Le choix de la période de grâce est un arbitrage direct entre latence et complétude. Une période de grâce plus longue capture davantage de rapports tardifs et produit une corrélation plus complète, mais chaque mise à jour de piste hérite de ce délai avant d'atteindre l'opérateur. Pour les pistes terrestres tactiques, une période de grâce de quelques secondes est typique ; pour les pistes aériennes où une latence inférieure à la seconde est obligatoire, la période de grâce se réduit à des dizaines ou quelques centaines de millisecondes, acceptant que certains rapports tardifs soient traités comme des corrections de piste plutôt que comme des corrélations dans la fenêtre.

Sémantique exactly-once pour l'intégrité des pistes

Dans un pipeline de fusion, la sémantique de livraison n'est pas une préoccupation académique — elle détermine si le tableau de situation est correct. Considérons la livraison au-moins-une-fois, où une défaillance peut provoquer le rejeu d'une observation. Si le même retour radar est appliqué deux fois à un filtre de Kalman, le filtre le traite comme deux mesures indépendantes et devient artificiellement confiant, réduisant sa covariance et biaisant l'estimation vers une seule lecture bruitée. La piste semble plus certaine tout en étant plus erronée — le pire mode de défaillance possible pour un système sur lequel les commandants agissent.

La sémantique exactly-once élimine cela en garantissant que chaque observation affecte l'état de piste exactement une fois, même après des crashes et des redémarrages. Le mécanisme est la mise en point de contrôle atomique : le moteur fait périodiquement un instantané du magasin d'état et des décalages d'entrée qu'il a consommés, en les validant ensemble. À la reprise, il restaure l'instantané et reprend la consommation depuis les décalages validés, de sorte que les observations déjà intégrées dans l'état ne sont jamais réappliquées. Flink implémente cela avec ses barrières de point de contrôle distribuées ; Kafka Streams utilise des écritures transactionnelles qui lient les mises à jour du changelog du magasin d'état et les décalages du topic de sortie dans une seule transaction.

L'exactly-once n'est pas gratuit. Les points de contrôle doivent se terminer plus vite que l'intervalle qui les sépare, sinon le pipeline accumule un état non mis en point de contrôle et finit par se bloquer. La durée du point de contrôle évolue avec la taille de l'état — ce qui est la deuxième raison pour laquelle l'expiration agressive des pistes est importante. Un pipeline qui maintient 50 000 pistes périmées effectue des points de contrôle lentement ; le même pipeline ne maintenant que les quelques milliers de pistes véritablement actives effectue des points de contrôle en millisecondes. Borner l'état est ce qui rend l'exactly-once abordable au rythme opérationnel. Pour les pipelines qui ont également besoin d'un enregistrement rejouable et infalsifiable de chaque changement d'état, le journal mis en point de contrôle se couple naturellement avec une piste d'audit basée sur l'event sourcing.

Partitionnement et mise à l'échelle des opérateurs à état

Une seule tâche ne peut pas fusionner l'ensemble du champ de bataille à des taux de capteurs élevés, de sorte que le flux est partitionné et traité en parallèle. La contrainte déterminante de la fusion à état est que deux observations du même objet physique doivent être routées vers la même partition — sinon elles atterrissent dans des magasins d'état séparés, ne se rencontrent jamais, et l'objet engendre des pistes parallèles qu'aucun opérateur ne peut réconcilier.

La clé de partition doit donc préserver la localité de corrélation. L'indexation par identifiant de capteur échoue immédiatement, car l'objectif même est de corréler à travers les capteurs. L'indexation par une cellule géographique grossière fonctionne bien : toutes les observations dans une région atterrissent sur une tâche qui maintient l'état des objets dans cette région. Le défi est la gestion des frontières — un objet traversant une frontière de cellule doit être transféré entre partitions sans perdre ni dupliquer sa piste. Les systèmes pratiques utilisent des cellules qui se chevauchent ou une étape de réconciliation de frontières dédiée pour gérer le transfert, et dimensionnent les cellules de sorte qu'aucune cellule unique ne devienne un point chaud qui submerge une tâche pendant que les autres restent inactives.

Parce que l'état est local à une partition, la remise à l'échelle d'un pipeline à état n'est pas aussi simple qu'ajouter des travailleurs. Le moteur doit redistribuer l'état indexé lorsqu'il rééquilibre les partitions entre les nœuds — Flink le fait en lisant l'état mis en point de contrôle et en réassignant des groupes de clés ; Kafka Streams rejoue les topics de changelog pour reconstruire les magasins locaux sur la nouvelle instance. Les deux sont bornés par la taille de l'état, qui est, une fois de plus, la raison pour laquelle un budget d'état discipliné sous-tend toutes les autres propriétés du système. La même dorsale de journal partitionné qui achemine les observations dans le moteur de fusion est décrite plus en détail dans notre note sur l'architecture de file de messages pour les pipelines de données de défense.

Des deltas de pistes au tableau de situation

Le moteur de fusion doit publier le changement, pas l'état. Chaque fois qu'une piste est créée, mise à jour ou supprimée, le moteur émet un événement delta sur un topic en aval auquel le tableau de situation commun et les autres consommateurs s'abonnent. Publier des deltas plutôt que des instantanés d'état complets maintient l'affichage réactif même quand le nombre de pistes actives atteint des dizaines de milliers, car le consommateur applique de petits changements incrémentaux plutôt que de re-rendre le monde à chaque tick.

Chaque delta porte un numéro de version monotoniquement croissant par piste afin que les consommateurs puissent détecter et corriger les livraisons hors ordre — appliquer une mise à jour plus ancienne après une plus récente téléporterait une piste en arrière. Le schéma d'événement est le contrat formel entre la fusion et ses consommateurs ; le geler et le versionner permet au tableau de situation, aux outils analytiques et aux archives d'évoluer indépendamment du cœur de fusion. De bout en bout, un pipeline à état bien réglé maintient la latence observation-capteur-vers-tableau-de-situation dans les secondes à un chiffre pour les pistes terrestres et sous la seconde pour les pistes aériennes, la variable dominante étant la période de grâce du filigrane plutôt que le calcul dans l'opérateur.

Une propriété opérationnelle mérite d'être énoncée clairement : un moteur de flux à état n'est aussi fiable que son comportement de rejeu. Parce que les décisions d'association et l'expiration s'exécutent toutes deux sur l'horloge de temps d'événement, une session de capteur enregistrée peut être réinjectée à travers le pipeline identique pour reproduire le tableau de pistes exact qu'un opérateur a vu — à condition que chaque opérateur (association, fenêtrage, expiration) soit déterministe étant donné son état et son entrée. Ce déterminisme est ce qui rend le système testable et accréditable : un ingénieur peut changer un seuil d'association, rejouer un scénario connu, et comparer les pistes résultantes par rapport à une référence plutôt que d'attendre que le comportement se reproduise sur le terrain. Traitez le non-déterminisme — lectures d'horloge murale, itération de table non ordonnée, réductions à virgule flottante dont l'ordre dépend de l'ordonnancement des threads — comme des défauts, car chacun brise le rejeu et, avec lui, la capacité à vérifier que le moteur de fusion se comporte de la même façon deux fois.