Identitäten auflösen, während Events passieren: Entity Resolution in Streaming-Pipelines

Kurzfassung: Streaming Entity Resolution konsumiert neue und geänderte Datensätze aus einer eventgetriebenen Pipeline, löst jeden Datensatz bei der Aufnahme auf, baut die Entität zusammen und stellt sie Anwendungen über GraphQL bereit. Kafka oder Kinesis transportiert die Events; die Identitätsschicht pflegt den Entitätszustand; die Abfrage ruft diesen Zustand ab, statt ihn neu zu berechnen.

Entwerfen Sie den Identitätsschritt in Ihrer eventgetriebenen Architektur. Demo buchen oder Tilores Studio kostenlos testen.

Eventgetriebene Systeme sind gut darin, Veränderung zu transportieren. Ein Kunde registriert sich, ändert eine Adresse, startet eine Transaktion, eröffnet einen Support-Fall oder wechselt die Rolle im Unternehmen. Kafka oder Amazon Kinesis erfasst das Event und lässt mehrere Konsumenten darauf reagieren.

Transport ist noch keine Identität. Wenn jeder Konsument nur den neuen Datensatz sieht, muss er trotzdem wissen, zu welcher Person oder welchem Unternehmen das Event gehört. Eine stabile Quelldatensatz-ID hilft beim Replay, verknüpft aber keine Datensätze aus verschiedenen Systemen. Eine gemeinsame E-Mail-Adresse findet Kandidaten, beweist aber nicht, dass es dieselbe Person ist.

Streaming Entity Resolution schließt diese Lücke. Sie verwandelt einen Fluss von Quelldatensätzen in einen fortlaufend gepflegten Entitätsgraphen, den nachgelagerte Anwendungen abfragen können.

Was ist Streaming Entity Resolution?

Streaming Entity Resolution ist der fortlaufende Abgleich und Zusammenbau von Datensätzen, während neue Events in die Identitätsschicht einlaufen.

Event-Bus und Identitätsschicht haben getrennte Aufgaben. Apache Kafka oder Amazon Kinesis Data Streams erfasst geordnete Datensätze und liefert sie an Konsumenten aus. Der Identitäts-Konsument bildet jedes Quell-Event auf das konfigurierte Tilores-Schema ab und übergibt es über GraphQL. Tilores wendet bei der Aufnahme deterministische Regeln, Fuzzy Matching und probabilistisches Scoring an und legt Entitäten anschließend nach Bedarf an, aktualisiert, führt sie zusammen oder trennt sie auf.

Anwendungen fragen die resultierende Entität über die Entity-ID, die Quelldatensatz-ID oder freigegebene Suchparameter ab. Sie verlangen vom Abfragedienst nicht, jeden Rohdatensatz erneut zu vergleichen. Der aktuelle aufgelöste Kontext existiert bereits.

Diese Abgrenzung ist der Kern der Architektur:

Schicht	Hauptaufgabe	Was sie nicht verantworten sollte
Quellanwendung	Eine dauerhafte fachliche Änderung mit stabiler Quelldatensatz-ID ausgeben	Systemübergreifenden Identitätsabgleich
Kafka oder Kinesis	Events transportieren, vorhalten, partitionieren und erneut abspielen	Den Zusammenbau von Entitäten
Identitäts-Adapter	Den Quelldatensatz validieren, abbilden und über GraphQL übergeben	Fachliche Entscheidungen
Tilores	Entitäten bei der Aufnahme auflösen und zusammenbauen	MDM-Governance, KYC-Fälle oder Anwendungs-Workflows
Konsumierender Dienst	Den aktuellen aufgelösten Kontext abfragen und nach eigener Policy handeln	Identität in jeder Anfrage neu aufzubauen

Wo gehört Entity Resolution in eine Kafka- oder Kinesis-Pipeline?

Entity Resolution gehört hinter einen eigenen Konsumenten oder Adapter, der Quell-Events in GraphQL-Übergaben einzelner Datensätze verwandelt.

Ein typischer Ablauf sieht so aus:

Ein operativer Dienst schreibt eine Kunden- oder Unternehmensänderung in ein Topic oder einen Stream.
Das Event trägt eine stabile Quelldatensatz-ID, den Quellnamen, den Eventzeitpunkt, die Schemaversion und die zulässigen Identitätsfelder.
Ein Identitäts-Adapter konsumiert das Event, prüft dessen Struktur und bildet die Quellfelder auf das Tilores-Schema ab.
Der Adapter übergibt den Datensatz über die Tilores-GraphQL-API.
Tilores löst die Entität bei der Aufnahme auf und baut sie zusammen.
Nachgelagerte Dienste fragen den aktuellen Entitätskontext ab, wenn eine Entscheidung oder Interaktion ihn braucht.

Kafka-Topics haben mehrere Produzenten und mehrere Abonnenten. Kinesis trennt Produzenten und Konsumenten auf ähnliche Weise. So kann sich der Identitäts-Adapter weiterentwickeln, ohne dass Checkout-, Policy-, CRM- oder Support-System auf jeden anderen Konsumenten warten müssen. Und Teams können eine begrenzte Menge Events erneut abspielen, wenn sich die Abbildungslogik ändert.

Der Adapter ist eine Integrationskomponente, kein zweiter Matcher. Er sollte vor dem Aufruf von Tilores keine eigenen verborgenen Fuzzy-Regeln aufbauen. Seine Aufgabe ist es, die Bedeutung der Quelldaten zu bewahren, vereinbarte Transformationen anzuwenden und den Datensatz konsistent zu übergeben.

Was sollte jedes Identitäts-Event enthalten?

Jedes Identitäts-Event sollte genug Metadaten enthalten, um einen Quelldatensatz zu verarbeiten, erneut abzuspielen und nachzuverfolgen – ohne so zu tun, als wäre das Event selbst schon eine aufgelöste Entität.

Event-Feld	Zweck	Hinweis zum Entwurf
Quelldatensatz-ID	Identifiziert den Datensatz innerhalb seines Ursprungs	Über Wiederholungen und Aktualisierungen hinweg stabil halten
Quellsystem	Bewahrt die Herkunft	Namensräume verschiedener Systeme nicht zusammenführen
Event-Typ	Unterscheidet Anlegen, Aktualisieren oder Löschabsicht	Jeden Typ auf eine explizite GraphQL-Operation abbilden
Eventzeitpunkt	Hält fest, wann die Quelländerung eintrat	Getrennt von der Verarbeitungszeit führen
Schemaversion	Erlaubt Konsumenten die richtige Abbildung	Unbekannte Versionen ablehnen oder in Quarantäne stellen
Identitätsfelder	Liefert die freigegebenen Namens-, Kontakt-, Adress- und Identifikatorwerte	Felder minimieren und der Datenrichtlinie folgen
Trace-ID	Verbindet Logs aus Quelle, Stream, Aufnahme und Abfrage	Für den Betrieb nutzen, nicht als Match-Schlüssel

Packen Sie nicht mehrere unabhängige Datensätze in eine einzige GraphQL-submit-Mutation, nur weil der Stream-Konsument ein Bündel erhalten hat. Tilores akzeptiert zwar ein Array von Datensätzen, aber gemeinsam übergebene Datensätze werden automatisch über eine statische Kante verbunden. Für die normale Event-Aufnahme übergeben Sie jeweils einen Quelldatensatz, sofern diese feste Verbindung nicht ausdrücklich gewollt ist.

Das ist ein feiner, aber wichtiger Unterschied zwischen Transport-Batching und Identitätssemantik. Ein Kafka-Konsument oder eine Lambda-Funktion kann mehrere Events in einem Poll erhalten. Der Adapter kann dennoch für jedes Event eine eigene Datensatzübergabe absetzen.

Wie aktualisiert eine GraphQL-Übergabe die Entität?

Eine GraphQL-submit-Mutation fügt den Quelldatensatz hinzu; Tilores wendet dann während der Aufnahme die konfigurierten Match- und Konsistenzregeln an.

Eine minimale, illustrative Übergabe sieht so aus:

mutation {
  submit(input: {
    records: [{
      id: "crm:customer:123"
      email: "example@example.com"
      mobile: "+441234567890"
    }]
  }) {
    recordsAdded
  }
}

Welche Felder verfügbar sind, hängt vom Schema der Instanz ab. Ein produktiver Adapter sollte prüfen, dass die Datensatz-ID eine Zeichenkette ist, Feldtypen absichern, unbekannte Schemaversionen ablehnen und Zugangsdaten außerhalb der Event-Payload halten. Außerdem sollte er das Ergebnis explizit behandeln, statt anzunehmen, dass eine Transportbestätigung bereits bedeutet, dass der Entitätszusammenbau erfolgreich war.

Während der Aufnahme kann der Datensatz eine neue Entität anlegen, eine bestehende aktualisieren oder dazu führen, dass bestehende Entitäten zusammengeführt werden. Eine spätere Korrektur oder Löschung kann Entitätszustand auftrennen oder entfernen. Tilores pflegt den Entitätsgraphen über all diese Änderungen hinweg. Die Abfrage ruft anschließend das aktuelle Ergebnis ab.

Teams, die eine erste historische Ladung vorbereiten, sollten diese Arbeit vom Livestream trennen. Der Leitfaden zum Laden riesiger Datenmengen in eine GraphQL-API erklärt, warum Massenladung, Wiederholungen und Durchsatztests einen eigenen Pfad brauchen. Sobald die Historie geladen ist, hält der Stream neue und geänderte Datensätze aktuell.

Wie sollte die Pipeline mit Wiederholungen und Replay umgehen?

Die Pipeline sollte Wiederholungen sicher machen, indem sie Quelldatensatz-IDs stabil hält, den Verarbeitungszustand nachverfolgt und festlegt, wie sich Aktualisierungen und Löschungen verhalten.

Event-Systeme können erneut zustellen. Konsumenten können ausfallen, nachdem eine Anfrage erfolgreich war, aber bevor sie die Bestätigung gespeichert haben. Betreiber können ein Topic von einem früheren Offset an erneut abspielen. Der Adapter braucht deshalb eine eindeutige Datensatzidentität und einen beobachtbaren Zustandsübergang für jedes Event.

Protokollieren Sie mindestens die Topic- oder Stream-Position, die Quelldatensatz-ID, die Schemaversion, die GraphQL-Operation, das Verarbeitungsergebnis und die Trace-ID. Leiten Sie fehlerhafte Datensätze mit dem exakten Validierungsfehler in einen Quarantänepfad. Alarmieren Sie bei anhaltendem Lag, wiederholten Fehlern und unerwarteten Änderungen im Volumen von Anlegen, Aktualisieren, Zusammenführen, Auftrennen oder Löschen.

Auch die Reihenfolge verdient eine Regel. Kafka garantiert die Reihenfolge innerhalb einer Topic-Partition, Kinesis bewahrt sie innerhalb eines Shards. Die Wahl von Schlüssel oder Partition sollte Änderungen desselben Quelldatensatzes nach Möglichkeit zusammenhalten. Quellenübergreifende Entitätsänderungen müssen dennoch damit umgehen können, dass Events zu unterschiedlichen Zeiten eintreffen – getrennte Systeme teilen sich keine gemeinsame Uhr.

Replay sollte vor der Produktion getestet werden. Laden Sie eine kurze Eventfolge, notieren Sie die aufgelöste Entität, spielen Sie dieselbe Quellhistorie unter dem vorgesehenen Verfahren erneut ein und prüfen Sie, dass der resultierende Kontext korrekt bleibt.

Wie erfahren nachgelagerte Dienste, dass sich eine Entität geändert hat?

Nachgelagerte Dienste können über AWS SQS oder AWS Kinesis auf Tilores-Entitäts-Events reagieren – oder die aktuelle Entität abfragen, wenn ihr Workflow läuft.

Unser Entitäts-Event-Stream veröffentlicht die Events CREATE, UPDATE, MERGE, SPLIT und DELETE. Das Deployment kann diesen Stream über AWS SQS oder AWS Kinesis bereitstellen. Über diese Events können nachgelagerte Caches, Suchindizes, Warehouses und Workflow-Dienste aktualisiert werden, sobald sich der Entitätszustand ändert.

Damit hat die Architektur zwei getrennte Streams:

Der eingehende Fachstream trägt Änderungen an Quelldatensätzen in den Identitäts-Adapter.
Der ausgehende Entitätsstream trägt Änderungen aufgelöster Entitäten zu berechtigten Konsumenten.

Behandeln Sie das ausgehende Event nicht standardmäßig als vollständigen Kundendatensatz. Ein kleines Event mit Entity-IDs und betroffenen Quelldatensatz-IDs kann einen Konsumenten dazu veranlassen, genau die Felder abzufragen, die er verwenden darf. Das reduziert doppelt gehaltene personenbezogene Daten und hält die Feldberechtigung in der GraphQL-Schicht.

Tilores kann daher neben MDM-, CDP-, KYC- und AML-Systemen, Warehouses und operativen Datenspeichern stehen. Diese Systeme bleiben für ihre eigene Governance und ihre eigenen Workflows verantwortlich. Entitäts-Events teilen ihnen mit, dass sich der Auflösungszustand geändert hat.

Was fragt die Anwendung ab, nachdem ein Event aufgelöst wurde?

Die Anwendung fragt den aktuellen Entitätskontext über GraphQL ab, nachdem der Aufnahmepfad ihn aktualisiert hat.

Kennt die Anwendung die Entity-ID bereits, kann sie die Abfrage entity nutzen. Kennt sie eine Quelldatensatz-ID, kann sie entityByRecord nutzen. Verfügt sie über freigegebene Suchparameter, kann sie search nutzen und die zurückgegebenen Treffer sowie den Hit Score auswerten. Die Antwort kann die Entity-ID, Datensätze, Kanten, Duplikatinformationen, Treffer und einen Entity Score enthalten.

Der Artikel zum Abfragen eines einheitlichen Kundenprofils in Echtzeit zeigt, wie dieser Auslieferungspfad funktioniert. Die Abfrage ruft den aktuellen aufgelösten Kontext ab. Sie führt innerhalb der Anfrage keinen neuen Entitätszusammenbau aus.

Diese Unterscheidung hält die Live-Anwendung einfacher. Ein Support-Mitarbeiter, eine Betrugsprüfung, ein KI-Assistent oder ein Policy-Dienst kann die benötigte Entität anfordern, ohne Matching-Logik neu zu implementieren. Die Identitätsregeln bleiben in einer Schicht und können sich weiterentwickeln, ohne dass jeder Konsument angepasst werden muss.

Reicht ein Kafka-Konsument, um Batch-Entity-Resolution in Echtzeit zu verwandeln?

Nein. Einen Batch-Matcher hinter einen Stream zu hängen macht den Identitätszustand nicht fortlaufend.

Wenn der Konsument Events lediglich an eine Datei anhängt und auf einen geplanten Deduplizierungslauf wartet, sieht der Auslieferungspfad weiterhin eine Momentaufnahme. Vergleicht er den neuen Datensatz nur mit einem begrenzten Cache, kann er ältere oder quellenübergreifende Belege übersehen. Baut er die Entität erst bei der Abfrage auf, erbt der Abfragepfad schwankenden Matching-Aufwand und uneinheitliche Quellabdeckung.

Echtzeit-Entity-Resolution bedeutet, dass der Datensatz als Teil der Aufnahme aufgelöst und zusammengebaut wird und die aktualisierte Entität für eine spätere Abfrage bereitsteht, ohne auf einen separaten Matching-Lauf zu warten. Batch behält seine Berechtigung für historische Nachladungen, Abstimmungen und Offline-Analysen.

Der Leitfaden zu Echtzeit- vs. Batch-Entity-Resolution gibt Teams einen klaren Test an die Hand: Echtzeit, wenn eine Live-Anwendung auf Basis des aktuellen aufgelösten Datensatzes handeln muss, und Batch, wenn Daten und Entscheidung warten können.

Was sollten Teams vor der Produktion testen?

Teams sollten Eventsemantik, Identitätsgenauigkeit, Fehlerbehebung, Korrekturbehandlung und Abfrageaktualität als getrennte Themen testen.

Nutzen Sie eine Abfolge, die eine Person anlegt, eine E-Mail-Adresse ändert, einen Datensatz aus einer anderen Quelle ergänzt, einen schwierigen Nicht-Treffer einstreut, eine fälschlich gesetzte Verknüpfung korrigiert und einen Quelldatensatz löscht. Prüfen Sie nach jedem Event die erwartete Entität. Halten Sie danach den Konsumenten an, lassen Sie Lag entstehen, starten Sie ihn neu und verifizieren Sie die Wiederherstellung.

Testen Sie fehlerhafte Events, unbekannte Schemaversionen, doppelte Zustellung, quellenübergreifend vertauschte Reihenfolgen und ein Replay von einem früheren Offset. Prüfen Sie, dass ein Transport-Batch keine versehentlichen statischen Verknüpfungen erzeugt. Stellen Sie sicher, dass Merge- und Split-Events nachgelagerte Konsumenten erreichen und dass jeder Konsument den neuen Entitätszustand abfragen kann.

Messen Sie schließlich die Bestandteile unabhängig voneinander: Stream-Lag, Verarbeitungszeit des Adapters, Abschluss der Aufnahme, Match-Qualität, Verhalten der GraphQL-Abfrage und Aktualisierungszeit nachgelagerter Systeme. Ein schneller Event-Bus kann schwache Identitätsregeln nicht ausgleichen, und ein guter Matcher kann keinen unzuverlässigen Adapter ausgleichen.

FAQ

Was ist Streaming Entity Resolution?

Streaming Entity Resolution gleicht Datensätze ab und baut Entitäten zusammen, während neue Events aufgenommen werden. Der Entitätskontext bleibt dadurch für aktuelle GraphQL-Abfragen und nachgelagerte Aktualisierungen verfügbar.

Löst Tilores Identitäten auf, wenn die Anwendung sie abfragt?

Nein. Tilores löst Entitäten bei der Aufnahme auf und baut sie dort zusammen. Die Abfrage der Anwendung ruft den aktuellen aufgelösten Kontext ab, den die Identitätsschicht bereits pflegt.

Kann Kafka Datensätze an Tilores senden?

Ja, über einen von der Anwendung betriebenen Konsumenten oder Adapter, der Kafka-Events auf das konfigurierte Tilores-Schema abbildet und über GraphQL übergibt. Das beschreibt ein Integrationsmuster und nicht die Behauptung, Kafka selbst führe Entity Resolution durch.

Passt Amazon Kinesis in dasselbe Muster?

Ja. Ein Kinesis-Konsument kann Quelldatensätze validieren und über GraphQL übergeben. Tilores kann Änderungsereignisse aufgelöster Entitäten je nach Deployment ebenfalls über AWS Kinesis oder AWS SQS veröffentlichen.

Sollte ein Konsument alle gepollten Events in einem GraphQL-Array übergeben?

Bei gewöhnlichen, voneinander unabhängigen Datensätzen nicht. Datensätze, die gemeinsam in einer Tilores-submit-Mutation übergeben werden, erhalten eine statische Verbindung. Verarbeiten Sie jeden Quelldatensatz einzeln, sofern diese feste Verknüpfung nicht beabsichtigt ist.

Wie sollte die Pipeline mit doppelten Events umgehen?

Halten Sie Quelldatensatz-IDs stabil, protokollieren Sie Stream-Positionen und Verarbeitungsergebnisse und testen Sie das Replay. Der Adapter sollte die Semantik von Aktualisierung und Löschung festlegen und den resultierenden Entitätszustand nach einer erneuten Zustellung überprüfen.

Ersetzt Streaming Entity Resolution ein MDM oder ein Data Warehouse?

Nein. Sie steht neben MDM-, CDP-, KYC- und AML-Systemen, Warehouses und operativen Datenspeichern. Diese Systeme behalten ihre Rollen in Governance, Analytics und Workflow und erhalten zusätzlich aufgelösten Entitätskontext.

Wann ist Batch-Entity-Resolution weiterhin sinnvoll?

Batch ist sinnvoll für historische Ladungen, periodische Abstimmungen, die Vorbereitung von Warehouses und Offline-Analysen, bei denen keine Live-Entscheidung wartet. Streaming ist der bessere Auslieferungspfad, wenn jedes neue Event ändern kann, was eine Anwendung jetzt tun sollte.