Streaming trackverwerking: stateful pipelines voor realtime fusie

Realtime trackfusie is in de kern een stateful probleem. Een radarecho, een SIGINT-interceptie of een UAV-detectie die via het netwerk binnenkomt, heeft op zichzelf geen betekenis — de waarde ervan ligt volledig in het koppelen aan de opgebouwde geschiedenis van elk object dat het systeem al aanwezig acht. Om te beslissen of een waarneming een bestaand track verlengt of een nieuw track aanmaakt, moet de engine alles onthouden wat het al heeft gezien. Juist die ene vereiste — duurzaam, veranderlijk, per-track geheugen dat wordt bijgewerkt in het tempo waarmee sensoren data produceren — is wat streaming trackverwerking onderscheidt van de eenvoudige stateless transformaties waarop de meeste datapipelines zijn gebouwd. Dit artikel onderzoekt hoe stateful streamverwerking wordt gebouwd voor realtime fusie: het toestandsmodel, event-time windowing, exactly-once semantics, partitionering voor schaalbaarheid en de operationele storingsoorzaken die deze pipelines doen neerkomen.

Waarom trackfusie inherent stateful is

Een stateless pipeline past een pure functie toe op elke gebeurtenis en vergeet die daarna. Dat model werkt voor verrijking, formaatconversie of filtering, maar het kan geen tracks fuseren. De fusiebeslissing — "behoort deze waarneming tot een track die ik al bijhoud?" — is alleen te beantwoorden met verwijzing naar status: de huidige positie- en snelheidsschatting van elk actief track, de onzekerheid (covariantie), de tijd van de laatste update en de associatiegeschiedenis.

Concreet onderhoudt de engine één record per track, gesleuteld op een stabiele track-ID. Dat record bevat de Kalman- (of deeltjes-) filterstatus, de tijdstempel van de laatste toegepaste waarneming, een korte geschiedenis van bijdragende sensorrapporten en de classificatie en het vertrouwen van het track. Wanneer een nieuwe waarneming binnenkomt, leest de engine de kandidaattrackstatussen, beslist welk track (als dat er is) de waarneming bij hoort met behulp van een trackcorrelatie-algoritme, muteert de filterstatus van het gekoppelde track ter plekke en geeft een update uit. De toestandsopslag wordt gelezen en geschreven op het kritieke pad van elke afzonderlijke waarneming — en daarom bepaalt het ontwerp ervan de prestaties en betrouwbaarheid van het gehele systeem.

De toestandsopslag: waar trackgeheugen leeft

In een productie-streamingengine wordt trackstatus niet in gewoon applicatiegeheugen bewaard. Deze leeft in een beheerde, fouttolerante toestandsopslag die het framework kan bewaren als controlepunt en herstellen. Apache Flink ondersteunt gesleutelde status met een ingebedde RocksDB-instantie per taak; Kafka Streams materialiseert status in lokale RocksDB-opslag ondersteund door een gecompacteerd changelogtopic dat volledige reconstructie na een crash mogelijk maakt. Hoe dan ook is het contract hetzelfde: de engine geeft je een gesleutelde map — track-ID naar trackstatus — die lokaal, snel en duurzaam is bij herstarts.

De belangrijkste ontwerpbeslissingen voor de toestandsopslag zijn omvang en toegangspatroon. Trackstatus moet compact zijn: een filtermiddelvektor, een covariantiematrix, een handvol metadatavelden en een begrensde ringbuffer van recente waarnemingsverwijzingen — niet de volledige waarnemingsgeschiedenis. Onbegrensde per-track-geschiedenis is de meest voorkomende oorzaak van statusexplosie. Toegang is overweldigend lees-wijzig-schrijf op één sleutel per waarneming, dus de opslag is afgestemd op puntopzoekingen en in-place updates in plaats van scans. Bereiksscans, wanneer nodig voor ruimtelijke selectie, worden buiten het kritieke pad gehouden door een secundaire ruimtelijke index bij te houden die asynchroon wordt bijgewerkt.

Statusserialisatie verdient expliciete aandacht. Omdat het framework trackstatus schrijft naar en leest van schijf bij elk controlepunt en herstel, is de serializer voor de trackstatusklasse een component op het kritieke pad, geen detail. Een reflectieve, schema-on-read serializer die objectgrafieken per record doorloopt, domineert de CPU bij hoge waarnemingssnelheden; een handgeschreven of codegegenereerde serializer die de vaste-grootte filterstatus als een platte bytebuffer uitlegt, is vaak een orde van grootte sneller. Dezelfde discipline loont ook in de controlepuntomvang — compacte, breedte-vaste statusencodings verkleinen snapshots en verkorten het herstelvenster na een knooppuntfout.

Statusgroei begrenzen

Elk track dat wordt aangemaakt maar nooit verloopt, bezet voor altijd status. Een pipeline zonder gedisciplineerd verloop ziet zijn toestandsopslag monotoon groeien totdat controlepunten vertragen en de engine achterloopt op realtime. Drie verloopmechanismen werken samen: time-to-live (verwijder een track dat binnen N seconden geen waarneming heeft ontvangen), miss-count-limieten (verwijder een track dat door M opeenvolgende verwachte vensters is voorspeld-maar-niet-bijgewerkt) en culling op interessegebied (verwijder tracks die het operationele gebied verlaten). Verloop is geen huishoudelijk werk dat kan worden uitgesteld — het is een correctheids- en stabiliteitsvereiste, en het moet draaien op dezelfde event-time-klok als de rest van de pipeline zodat het identiek gedraagt tijdens live verwerking en herspeling.

Event time, watermarks en windowing

Sensorfeeds komen niet in volgorde aan, en ze komen ook niet op tijd aan. Een radarplot waargenomen om 09:47:03.120 kan 400 ms later de fusie-engine bereiken dan een SIGINT-interceptie van hetzelfde object waargenomen om 09:47:03.080, simpelweg omdat de twee feeds verschillende netwerken en verwerkingsstadia doorlopen. Als de engine zou correleren op de aankomsttijd van gebeurtenissen (verwerkingstijd), zou het regelmatig nalaten om waarnemingen te associëren die werkelijk hetzelfde object op hetzelfde moment beschrijven.

Streaming fusie gebruikt daarom event time — het tijdstempel waarop de sensor het object waarnam — als sleutel, en maakt gebruik van watermarks om over volledigheid te redeneren. Een watermark is de schatting van de engine dat er geen verdere gebeurtenissen met een event time eerder dan het watermark zullen aankomen. Correlatievensters sluiten wanneer het watermark hun einde passeert, plus een geconfigureerde toegestane-laatheid respijtperiode die het venster net lang genoeg open houdt voor achterblijvers. Waarnemingen die later zijn dan de respijtperiode worden niet stilzwijgend verwijderd; ze worden doorgestuurd naar een zijuitvoer zodat analisten kunnen controleren hoeveel data zijn venster heeft gemist en de respijtperiode dienovereenkomstig kunnen afstemmen.

Het kiezen van de respijtperiode is een directe afweging tussen latentie en volledigheid. Een langere respijtperiode vangt meer late rapporten op en produceert een completere correlatie, maar elke trackupdate erft die vertraging voordat deze de operator bereikt. Voor tactische grondtracks is een respijtperiode van enkele seconden gebruikelijk; voor luchtracks waarbij sub-seconde latentie verplicht is, krimpt de respijtperiode naar tientallen of lage honderden milliseconden, waarbij wordt aanvaard dat sommige late rapporten als trackcorrecties worden verwerkt in plaats van als in-venster correlaties.

Exactly-once semantics voor trackintegriteit

In een fusiepipeline zijn leveringssemantics geen academisch vraagstuk — ze bepalen of het operatiebeeld correct is. Beschouw at-least-once levering, waarbij een storing een waarneming kan veroorzaken die opnieuw wordt afgespeeld. Als dezelfde radarecho tweemaal op een Kalmanfilter wordt toegepast, behandelt het filter dit als twee onafhankelijke metingen en wordt het kunstmatig zeker, waardoor de covariantie krimpt en de schatting wordt vertekend naar één ruis-rijke meting. Het track lijkt zekerder terwijl het meer fout is — het slechtst mogelijke falen voor een systeem waarop commandanten handelen.

Exactly-once semantics elimineren dit door te garanderen dat elke waarneming de trackstatus precies één keer beïnvloedt, zelfs bij crashes en herstarts. Het mechanisme is atomair controlepunten: de engine maakt periodiek een momentopname van de toestandsopslag en de verwerkte invoeroffsets, en committeert beide samen. Bij herstel wordt de momentopname hersteld en worden waarnemingen hervat vanaf de gecommitteerde offsets, zodat waarnemingen die al in de status zijn gevouwen nooit opnieuw worden toegepast. Flink implementeert dit met zijn gedistribueerde controlepuntbarrières; Kafka Streams gebruikt transactionele schrijfoperaties die statusopslagchangelogupdates en uitvoertopicoffsets koppelen in één transactie.

Exactly-once is niet gratis. Controlepunten moeten sneller voltooien dan het interval ertussen, anders accumuleert de pipeline niet-gecontroleerde status en loopt uiteindelijk vast. Duur van controlepunten schaalt met statusomvang — wat de tweede reden is waarom agressief trackverloop belangrijk is. Een pipeline met 50.000 verouderde tracks maakt traag een controlepunt; dezelfde pipeline met slechts de enkele duizenden werkelijk actieve tracks maakt in milliseconden een controlepunt. Status begrenzen is wat exactly-once betaalbaar houdt op operationeel tempo. Voor pipelines die ook een herspeculeerbaar, manipulatiebestendig overzicht van elke statuswijziging nodig hebben, werkt het gecontroleerde log goed samen met een event-sourced controlelogboek.

Partitionering en schalen van stateful operators

Eén taak kan niet het volledige slagveld fuseren bij hoge sensorsnelheden, dus de stream wordt gepartitioneerd en parallel verwerkt. De bepalende beperking van stateful fusie is dat twee waarnemingen van hetzelfde fysieke object naar dezelfde partitie moeten worden gerouteerd — anders landen ze in afzonderlijke toestandsopslagen, ontmoeten ze elkaar nooit en spawnt het object parallelle tracks die geen operator kan samenvoegen.

De partitiesleutel moet daarom correlatielocaliteit bewaren. Sleutelen op sensor-ID mislukt onmiddellijk, omdat het hele punt is om over sensoren heen te correleren. Sleutelen op een grof geografische cel werkt goed: alle waarnemingen binnen een regio landen bij één taak die de status voor objecten in die regio bewaart. De uitdaging is grensbeheer — een object dat een celgrens overschrijdt, moet worden overgedragen tussen partities zonder zijn track te verliezen of te dupliceren. Praktische systemen gebruiken overlappende cellen of een aparte grensafstemmingsfase om overdracht te beheren, en ze dimensioneren cellen zodanig dat geen enkele cel een knelpunt wordt dat één taak overweldigt terwijl anderen niets te doen hebben.

Omdat status lokaal is voor een partitie, is het herschalen van een stateful pipeline niet zo eenvoudig als workers toevoegen. De engine moet gesleutelde status herverdelen wanneer het partities herverdeelt over knooppunten — Flink doet dit door gecontroleerde status te lezen en sleutelgroepen opnieuw toe te wijzen; Kafka Streams herspeculeert changelogtopics om lokale opslag op de nieuwe instantie opnieuw op te bouwen. Beide zijn begrensd door statusomvang, wat nog eens aangeeft waarom een gedisciplineerd statusbudget elke andere eigenschap van het systeem ondersteunt. De dezelfde gepartitioneerde logbackbone die waarnemingen in de fusie-engine voert, wordt nader beschreven in onze notitie over berichtenwachtrij-architectuur voor defensie-datapipelines.

Van trackdeltas naar het operatiebeeld

De fusie-engine moet wijzigingen publiceren, geen status. Elke keer dat een track wordt aangemaakt, bijgewerkt of verwijderd, geeft de engine een delta-gebeurtenis uit op een downstream-topic waarop het gemeenschappelijk operatiebeeld en andere afnemers zijn geabonneerd. Het publiceren van deltas in plaats van volledige statusmomentopnames houdt de weergave responsief zelfs wanneer het actieve trackantal tienduizenden bereikt, omdat de afnemer kleine incrementele wijzigingen toepast in plaats van de wereld bij elke tik opnieuw te renderen.

Elke delta draagt een monotoon stijgende versie per track zodat afnemers buiten-volgorde-levering kunnen detecteren en corrigeren — een oudere update na een nieuwere toepassen zou een track terugverplaatsen. Het gebeurtenisschema is het formele contract tussen fusie en zijn afnemers; het bevriezen en versiebeheer ervan laat het COP, analysetools en archieven onafhankelijk van de fusiekern evolueren. Van begin tot eind houdt een goed afgestemde stateful pipeline de latentie van sensorwaarneming tot COP in de enkele-digit seconden voor grondtracks en onder een seconde voor luchtracks, waarbij de dominante variabele de watermark-respijtperiode is in plaats van de berekening binnen de operator.

Eén operationele eigenschap is het waard om expliciet te vermelden: een stateful streaming-engine is slechts zo betrouwbaar als zijn herspeculatiegedrag. Omdat associatiebeslissingen en verloop beide op de event-time-klok draaien, kan een opgenomen sessie van sensoren worden teruggespeeld door de identieke pipeline om het exacte trackbeeld te reproduceren dat een operator zag — mits elke operator (associatie, windowing, verloop) deterministisch is gegeven zijn status en invoer. Dat determinisme is wat het systeem testbaar en accrediteerbaar maakt: een ingenieur kan een associatiedrempel wijzigen, een bekend scenario opnieuw afspelen en de resulterende tracks vergelijken met een basislijn in plaats van te wachten totdat het gedrag zich in het veld herhaalt. Behandel niet-determinisme — kloklesingen van de muurklok, ongeordende map-iteratie, floating-point reductie waarvan de volgorde afhankelijk is van thread-scheduling — als defecten, want elk daarvan verbreekt herspeculatie en daarmee de mogelijkheid om te verifiëren dat de fusie-engine zich twee keer op dezelfde manier gedraagt.