Ihr eigenes Identity-Resolution-System aufbauen

Der Aufbau von Tilores hat ein Entwicklungsteam – vier Entwickler, einen Product Manager, einen QA-Engineer – rund drei Jahre gekostet. Dieser Artikel schildert, was wir darüber gelernt haben, was es tatsächlich braucht, um ein Identity-Resolution-System auf Produktionsniveau zu bauen.

Das hier ist kein Tutorial. Es ist eine Erdung.

Was Identity Resolution wirklich verlangt

Im Kern beantwortet Identity Resolution eine einfache Frage: „Beziehen sich diese beiden Datensätze auf dieselbe reale Person?” Die Antwort ist nie binär – sie ist probabilistisch, kontextabhängig und hängt von einer Datenqualität ab, die zwischen Quellsystemen enorm schwankt.

Ein produktives Identity-Resolution-System muss mindestens diese Komponenten abdecken:

Datenaufnahme – Datensätze aus mehreren Quellen in unterschiedlichen Formaten entgegennehmen
Datentransformation – Datensätze vor dem Abgleich normalisieren, bereinigen und anreichern
Matching – Datensätze mit unscharfen Algorithmen vergleichen, um Duplikate zu finden
Entitätsbildung – übereinstimmende Datensätze zu einheitlichen Entitäten gruppieren
Speicherung – den Entitätsgraphen und die Verknüpfung zu den Quelldatensätzen vorhalten
Abfrage-API – aufgelöste Entitäten auf Anforderung ausliefern
Echtzeit-Aktualisierungen – neue Datensätze verarbeiten, ohne alles neu zu berechnen

Jeder dieser Punkte ist für sich eine Engineering-Herausforderung. Zusammen ergeben sie ein System, das deutlich schwerer zu bauen ist, als es aussieht.

Das Problem der Datentransformation

Bevor Sie Datensätze abgleichen können, müssen Sie sie normalisieren. Das klingt einfach, bis Sie auf echte Daten treffen:

„Jon” sollte zu „Jonathan” passen, aber nicht zu „Jonas”
„Müller” sollte zu „Mueller” und „Muller” passen
„Hauptstraße 14” sollte zu „Hauptstr. 14” und „Hauptstrasse 14” passen
„+49 30 12345678” sollte zu „030-12345678” und „004930 12345678” passen
„sarah@gmail.com” ist womöglich dieselbe Person wie „sarah@googlemail.com” – aber nicht zwingend

Jeder Attributtyp (Name, Adresse, Telefon, E-Mail, Geburtsdatum) braucht seine eigene Transformationslogik. Und diese Transformationen sind sprachraumspezifisch – die Normalisierung deutscher Namen funktioniert anders als die japanischer oder arabischer Namen.

Allein für die Transformationsschicht haben wir rund sechs Monate gebraucht.

Die Herausforderung beim Matching

Matching-Algorithmen müssen Precision (falsche Treffer vermeiden) und Recall (echte Treffer nicht übersehen) ausbalancieren. Der naive Ansatz – jeden Datensatz mit jedem anderen zu vergleichen – hat eine Komplexität von O(n²) und ist im großen Maßstab unbrauchbar.

Bei 150 Millionen Datensätzen bedeutet O(n²) 22,5 Billiarden Vergleiche. Selbst bei einer Million Vergleichen pro Sekunde würde das 713 Jahre dauern.

Produktive Matching-Engines nutzen Blocking-Strategien, um den Vergleichsraum zu verkleinern: Datensätze werden nach gemeinsamen Attributen gruppiert (etwa gleiche ersten drei Buchstaben des Nachnamens, gleiche Postleitzahl) und nur innerhalb dieser Blöcke verglichen. Die richtige Blocking-Strategie ist entscheidend: Ist sie zu weit gefasst, übersehen Sie Treffer; ist sie zu eng, leidet die Performance.

Unsere Matching-Engine arbeitet mehrstufig mit sukzessive lockereren Blocking-Kriterien, kombiniert mit attributspezifischen Ähnlichkeitsfunktionen (Jaro-Winkler für Namen, Levenshtein für Adressen, phonetisches Matching für Transliterationen).

Das Echtzeit-Problem

Batch-Entity-Resolution – also die Verarbeitung aller Datensätze auf einmal – ist gut verstanden. Entity Resolution in Echtzeit – einen einzelnen neuen Datensatz binnen Millisekunden gegen alle bestehenden Entitäten aufzulösen – ist eine grundlegend andere Engineering-Aufgabe.

Trifft ein neuer Datensatz ein, muss das System:

ihn transformieren und normalisieren (< 1 ms)
mithilfe von Blocking-Schlüsseln in Frage kommende Entitäten identifizieren (< 2 ms)
die Ähnlichkeit zu allen Kandidatendatensätzen bewerten (< 5 ms)
entscheiden, ob eine neue Entität entsteht oder in eine bestehende eingefügt wird (< 1 ms)
den Entitätsgraphen aktualisieren (< 1 ms)

All das muss in unter 10 Millisekunden geschehen, jedes Mal, in jedem Maßstab. Hier zahlt sich unsere serverlose Architektur aus – die Rechenleistung skaliert automatisch mit der Last, und um Connection Pooling oder Thread-Verwaltung muss sich niemand kümmern.

Das Skalierungsproblem

Identity Resolution im großen Maßstab bringt Herausforderungen mit sich, die es bei kleineren Mengen nicht gibt:

Entitätsketten – Datensatz A passt zu B, B passt zu C, aber A passt nicht direkt zu C. Wie behandeln Sie transitive Übereinstimmungen, ohne dass Entitäten ausufern?
Aufspalten und Zusammenführen – Neue Daten können zeigen, dass das, was wie eine Entität aussah, tatsächlich zwei Personen sind – oder umgekehrt. Das System muss beide Richtungen beherrschen.
Konsistenz bei gleichzeitigen Schreibvorgängen – Mehrere Datensätze zur selben Entität können zeitgleich aus verschiedenen Quellen eintreffen.
Wachstum des Speicherbedarfs – Der Entitätsgraph wächst nicht linear mit dem Datenvolumen.

Was wir heute anders machen würden

Würden wir heute noch einmal anfangen, würden wir eines grundlegend ändern: mit der Abfrage-API beginnen, nicht mit der Matching-Engine. Technisch ist die Matching-Engine der schwerste Teil, doch über den Product-Market-Fit entscheidet die API. Bauen Sie eine minimale Matching-Engine, veröffentlichen Sie die API, holen Sie echte Nutzer an Bord und verbessern Sie die Match-Qualität anhand realer Datenmuster.

Sollten Sie es selbst bauen?

Wahrscheinlich nicht. Hier ein schneller Entscheidungsrahmen:

Bauen Sie es selbst, wenn: Entity Resolution Ihr Kernprodukt ist (Sie also buchstäblich damit Ihr Geld verdienen), Sie über drei Jahre und ein eigenes Team verfügen und Ihre Matching-Anforderungen tatsächlich einzigartig sind
Nutzen Sie Tilores, wenn: Entity Resolution eine Fähigkeit ist, die Sie brauchen, aber nicht Ihr Kerngeschäft, wenn Sie in Tagen oder Wochen statt in Jahren in Produktion gehen müssen und wenn Sie Ihre Entwicklungszeit lieber in Ihr eigentliches Produkt stecken

Wir haben drei Jahre in Tilores investiert, damit Sie es nicht tun müssen.

Bereit, die drei Jahre Eigenbau zu überspringen? Demo buchen →, um Identity Resolution in Echtzeit auf Ihren eigenen Daten zu sehen – oder holen Sie sich den Evaluation Build, um es zunächst lokal zu testen.