Liquidationsdaten richtig lesen: Ereignisse, Mengen und Abdeckung · 4 / 5
Liquidations-Replays entfernen, ohne echte Beobachtungen zu löschen
Ein Reconnect oder erneut ausgeführter Verarbeitungsauftrag kann einen Liquidationschart für dieselbe gespeicherte Beobachtung zweimal springen lassen. Jede Zeile mit identischem Zeitstempel, gleicher Seite, Menge und gleichem Preis zu entfernen, löst das Problem nicht vollständig: Tatsächlich verschiedene Ereignisse können dieselben Feldwerte haben. Entscheidend ist, welche Doppelzählung die vorhandenen Herkunftsnachweise belegen. Lokale Replay-Nachweise und Anbieter-Ereignisidentitäten lösen verschiedene Probleme.
Athenum8 Min.Aktualisiert:
Drei Arten von Identität trennen
Eine Transport- oder Speicherkennung kann belegen, dass dein System dieselbe gespeicherte Nachricht zweimal verarbeitet hat. Eine Anbieter-Ereigniskennung kann belegen, dass sich zwei Zustellungen auf dasselbe zugrunde liegende Ereignis beziehen, sofern ihr dokumentierter Geltungsbereich und ihre Stabilität diese Schlussfolgerung tragen. Ein Fingerabdruck gewöhnlicher Ereigniswerte belegt nur übereinstimmende Werte. Er ist nicht automatisch eine Ereigniskennung.
Die hier referenzierten öffentlichen Liquidationsschemata stellen nicht für jede Beobachtung eine allgemeine Kontokennung oder eine stabile eindeutige Ausführungskennung bereit. Erfinde keine solche Kennung aus der Abonnement-Anfrage-ID oder dem Zeitstempel. Dokumentiere die Sicherheit jeder Deduplizierungsregel, bewahre die Rohdaten auf und trenne entfernte lokale Wiederholungen von ungeklärten wertgleichen Anbieterbeobachtungen.
Den Korrekturweg erhalten
Bewahre bei einer Forschungssumme die ursprüngliche Verarbeitungsanzahl, die nachgewiesene Replay-Menge, die lokal korrigierte Summe und die ungeklärten Fälle auf. Verändert eine Heuristik die Summe, dokumentiere Regel und Wirkung. Eine sauber wirkende Einzelzahl wird nicht verlässlicher, indem ihre Unsicherheit verschwindet. Auch verspätete Updates, kumulierte Order-Snapshots und revidierte Quelldatensätze benötigen eine ausdrückliche Semantik. Sie sind nicht sämtlich identische Duplikate.
Aus zwanzig verarbeiteten Einheiten werden nach einem belegten Replay fünfzehn
In diesem fiktiven Archiv identifizieren Partition und Offset gemeinsam eine unveränderliche gespeicherte Nachricht. Nachricht P0:41 enthält zwei Zeilen mit Mengen 2 und 3; ein Worker verarbeitet dieselbe gespeicherte Nachricht zweimal. P0:42 enthält eine Zeile mit Menge 5. P0:43 enthält eine weitere Zeile mit Menge 5 und identischen öffentlichen Ereignisfeldern. Eine Anbieter-Ereigniskennung fehlt jedoch. Die beiden späteren Nachrichten sind getrennt gespeicherte Beobachtungen. Alle Mengen haben dieselbe Basiseinheit und bezeichnen in diesem Beispiel zusätzliche Ausführungen.
Eine naive Verarbeitung addiert 5 + 5 + 5 + 5 = 20 Einheiten. Der wiederholte Lesevorgang von P0:41 ist durch die lokale Archividentität belegt. Entferne daher dessen zweiten Beitrag von fünf Einheiten: Bei einmaliger lokaler Verarbeitung ergibt sich 15. Die Gleichheit von P0:42 und P0:43 belegt nicht, ob ein Ereignis zweimal zugestellt wurde oder zwei verschiedene Ereignisse vorliegen. Handelt es sich um dasselbe Ereignis, beträgt die zugrunde liegende Menge 10; sind es verschiedene Ereignisse, beträgt sie 15. Diese Alternativen beschreiben ausschließlich das abgeschlossene fiktive Protokoll, keine Grenze für den gesamten Börsenmarkt.
| Verarbeitungslauf | Gespeicherte Nachricht | Menge | Behandlung nach Beleglage |
|---|---|---|---|
| 1 | P0:41 | 2 + 3 = 5 | Erste lokale Verarbeitung behalten |
| 2 | P0:41 | 2 + 3 = 5 | Diesen nachgewiesenen Replay entfernen |
| 3 | P0:42 | 5 | Behalten; Anbieteridentität ungeklärt |
| 4 | P0:43 | 5 | Behalten; gleiche Felder beweisen keine Identität |
Diagramm vergrößern- Naive Verarbeitungssumme: 20 Basiseinheiten
- Nachgewiesener Replay-Beitrag: 5 Basiseinheiten
- Jede gespeicherte Nachricht einmal: 15 Basiseinheiten
- Falls wertgleiche Zeilen ein Ereignis teilen: 10 Basiseinheiten
Ein lokaler Offset belegt nur lokale Identität
Zwei verschiedene Offsets belegen zwei gespeicherte Datensätze, aber nicht unbedingt zwei eindeutige Börsenereignisse. Umgekehrt kann ein Inhaltshash zwei verschiedene gespeicherte Ereignisse zusammenführen, deren öffentliche Felder zufällig übereinstimmen. Bewahre genügend Kontext auf, um beide Grenzen zu erklären. Klären spätere unabhängige Belege die beiden späteren Datensätze, korrigiere die Kennzahl mit Datum, statt historische Forschungseingaben stillschweigend zu ändern.
Vor der Entscheidung
- Archividentität und Anbieter-Ereignisidentität unterscheiden.
- Nur durch die gewählte Beleglage nachgewiesene Wiederholungen entfernen.
- Rohfelder und angewandte Korrekturregel aufbewahren.
- Wertgleiche Beobachtungen bei fehlender Identität ungeklärt lassen.
- Ursprüngliche Summe, Korrektur und verbleibende Unsicherheit ausweisen.
Prüfe dein Verständnis
Ein späterer verlässlicher Anbieterabgleich bestätigt, dass P0:42 und P0:43 dasselbe Ereignis beschreiben. Wie hoch ist die endgültige Menge dieses fiktiven Protokolls? Um wie viel war die ursprüngliche Summe von 20 Einheiten überhöht?
Lösung mit Erklärung anzeigen
Die endgültige Menge beträgt 10 Einheiten: fünf aus P0:41 und fünf aus dem einen späteren Ereignis. Die ursprüngliche Verarbeitungssumme von 20 lag um 10 Einheiten darüber, also um 100 % der korrigierten Zehn-Einheiten-Summe. Damit ist nur das fiktive Protokoll geklärt. Eine vollständige Börsenabdeckung ist nicht bewiesen.