Entity Resolution neben dem Lakehouse: Wo die Engine wirklich laufen sollte

Kurzfassung: Platzieren Sie Entity Resolution neben dem Lakehouse – nicht in einer Kette analytischer Transformationen und nicht in jeder konsumierenden Anwendung. Das Lakehouse bleibt das System für dauerhafte analytische Daten. Eine separate operative Engine löst Datensätze auf, sobald sie eintreffen, gibt jeder Zeile eine stabile Entitäts-ID und stellt die aktuelle Entität über GraphQL bereit.

Platzieren Sie Identität dort, wo Ihre Anwendungen sie nutzen können. Besprechen Sie die Architektur mit unserem Team oder testen Sie die Engine lokal, bevor Sie sich für einen Produktivperimeter entscheiden. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

Wo sollte Entity Resolution liegen?
Warum veraltet eine Auflösung allein im Warehouse?
Was braucht die Engine?
Was ändert sich mit einer Entitäts-ID?
Wie bleibt die Sicht aktuell?
Welches Deployment-Modell passt?
Häufig gestellte Fragen

Ein Lakehouse kann jeden Kundendatensatz speichern, den eine Organisation je gesehen hat – und einer Anwendung trotzdem nicht sagen, welche Datensätze jetzt zum selben Kunden gehören. Speicherung und Identität hängen zusammen, sind aber nicht dieselbe Aufgabe.

Die Entscheidung über die Platzierung ist wichtig, weil Identity Resolution an der Grenze zwischen analytischer und operativer Arbeit sitzt. Steckt sie zu tief in den Warehouse-Transformationen, wartet jeder neue Datensatz auf einen Ladelauf und einen Modelldurchlauf. Steckt sie in jeder einzelnen Anwendung, entstehen mehrere unvereinbare Kundensichten. Liegt sie zu weit vom Datenperimeter entfernt, erzeugt die Architektur Datenbewegungen, die Governance-Teams so nicht vorgesehen hatten.

Das sinnvolle Muster ist, eine dedizierte Entity-Resolution-Engine neben dem Warehouse oder Lakehouse zu betreiben. Sie konsumiert die für Identität nötigen Datensätze, gibt eine stabile Entitäts-ID an die analytischen Zeilen zurück und stellt die aktuelle aufgelöste Entität autorisierten Anwendungen zur Verfügung.

Wo sollte Entity Resolution im Verhältnis zu Ihrem Warehouse oder Lakehouse liegen?

Entity Resolution sollte als gemeinsam genutzter operativer Dienst neben dem Lakehouse liegen. Das Lakehouse bleibt zuständig für dauerhafte Speicherung, Transformation, analytische Modelle und historische Abfragen. Die Auflösungs-Engine ist dafür zuständig zu entscheiden, welche Quelldatensätze dieselbe reale Entität beschreiben, und diese Entität aktuell zu halten, während sich Datensätze ändern.

Diese Grenze vermeidet zwei verbreitete Extreme. Das erste ist, ausschließlich in SQL- oder Spark-Jobs aufzulösen. Für periodische Analysen kann das funktionieren, doch die aufgelöste Sicht ist nur so aktuell wie der letzte erfolgreiche Lauf. Das zweite ist, Matching-Logik in ein CRM, eine Support-Anwendung oder einen KI-Dienst einzubetten. Das liefert eine lokale Antwort, aber andere Systeme können sich nicht auf dieselbe Identität verlassen.

Im benachbarten Muster wird jeder Quelldatensatz an die Auflösungs-Engine geschickt, sobald er verfügbar ist. Die Engine wendet deterministisches, unscharfes und probabilistisches Matching an, aktualisiert die Entität und gibt eine Entitäts-ID zurück oder stellt sie bereit. Die Ingestion-Pipeline schreibt diese ID zusammen mit der Quellzeile ins Lakehouse. Analytische Modelle können die Historie dann nach einer dauerhaften Identität gruppieren, ohne die Match-Logik selbst zu besitzen.

Operative Anwendungen fragen die aktuelle Entität über GraphQL ab. Sie warten nicht auf einen Reverse-ETL-Zyklus, um zu erfahren, dass sich eine Adresse oder Telefonnummer geändert hat. Die aktuelle Sicht antwortet im Managed-Pfad in etwa 150 ms und selbst gehostet in etwa 1 ms, abhängig von Netzwerk und Last.

Die Entitäts-ID sollte als kontrollierte Referenz behandelt werden, nicht als Ersatz für Quellschlüssel. Behalten Sie Quellsystem, Quelldatensatz-ID und Ingestion-Zeitstempel bei. Diese Herkunftsinformation erlaubt es Entwicklerinnen und Entwicklern nachzuvollziehen, wie eine Zeile in eine Entität gelangt ist, und lässt eine Löschung oder Korrektur zum richtigen Datensatz zurückwandern.

Warum stößt die Auflösung im Warehouse bei Ingestion-Geschwindigkeit an Grenzen?

Warehouse-native Auflösung ist nicht grundsätzlich unbrauchbar. Sie wird ungeeignet, sobald die geforderte Aktualität kürzer ist als der Transformationszyklus oder sobald operative Anwendungen zwischen den Ladeläufen eine aktuelle Entität benötigen.

Dieser Unterschied zeigt sich in den Plattformen selbst. Snowflake Dynamic Tables drücken Aktualität als angestrebte Verzögerung aus und nicht als Garantie, dass jede operative Änderung sofort aufgelöst wird. Databricks-Lakeflow-Pipelines koordinieren Streaming-Tabellen und materialisierte Sichten, bleiben aber Konstrukte einer Datenpipeline. Beide können Identitätsein- und -ausgaben gut bewegen. Keines nimmt die Entscheidung ab, wo die aktuelle operative Entität gepflegt wird.

Für ereignisgetriebene Ingestion macht die Design-Dokumentation von Apache Kafka den ergänzenden Punkt: Dauerhafte, geordnete Logs erlauben es Konsumenten, Änderungen unabhängig zu verarbeiten. Die Identitäts-Engine kann diesen Änderungsstrom konsumieren, ohne den Transformationsgraphen des Warehouse für die aktuelle Entität verantwortlich zu machen.

Stellen Sie sich eine Support-Mitarbeiterin vor, die eine Kontoübernahme bearbeitet. Um 10:03 trifft über das CRM eine neue Telefonnummer ein. Das Warehouse lädt um 10:30, das Entitätsmodell ist um 10:50 fertig. Bis dahin sieht ein Kundenservice-Werkzeug, das aus dem Warehouse liest, das alte Profil. Zwanzig Minuten Verzögerung mögen für ein Monatsreporting harmlos sein – für eine Interaktion, die gerade jetzt stattfindet, sind sie es nicht.

Dieselbe Lücke zeigt sich in ereignisgetriebenen Systemen. Ein Zahlungsereignis, ein Gerätesignal oder eine Aktualisierung aus dem Sanktionsscreening muss die operative Entität möglicherweise sofort verändern. Wird die Auflösung als Abfolge analytischer Joins ausgedrückt, muss das Team entweder für jedes Ereignis eine teure Neuberechnung anstoßen oder eine veraltete Antwort akzeptieren.

Hinzu kommt ein Modellierungsproblem. Eine Warehouse-Transformation liest normalerweise einen abgegrenzten Snapshot und schreibt eine neue Tabelle. Entity Resolution dagegen hat Zustand. Ein neuer Datensatz kann sich einer bestehenden Entität anschließen, ein bisheriges Cluster nach einer Korrektur aufspalten oder das Profil nach dem Löschen eines Datensatzes neu ordnen. Wird die gesamte Population neu aufgebaut, verschwimmt, welche Entscheidung sich warum geändert hat.

Nichts davon bedeutet, dass Warehouse-Werkzeuge aus dem Ablauf verschwinden sollten. Snowflake und Databricks bleiben starke Orte, um Quelldaten aufzubereiten, Fehlermuster zu analysieren und die nachgelagerte Wirkung der Auflösung zu messen. Splink und Zingg können wertvoll sein, wenn die Aufgabe explorativ oder batchorientiert ist. AWS Entity Resolution kann zu Teams passen, deren Umfang und Datenfluss zu diesem Managed-Modell passen. Die Frage ist, ob die produktive Anwendung einen operativen Identitätsdienst oder ein analytisches Ergebnis braucht.

Was braucht die Engine von Ihrer Plattform?

Tilores braucht drei Infrastruktur-Primitive: einen Key-Value-Store, eine Queue und Dateispeicher. Auf AWS nutzt die Referenzimplementierung DynamoDB, SQS und S3.

Der Key-Value-Store hält den aktuellen Zustand vor, der nötig ist, um Entitäten zu finden und zu aktualisieren. Die Queue puffert und ordnet die Ingestion-Arbeit. Der Dateispeicher unterstützt Importe, Exporte und andere dauerhafte Objekte. Die Engine bringt keinen vierten Pflicht-Datenspeicher, kein eigenes Suchcluster und keine separate Graphdatenbank in die Plattform.

Dieser kleine Satz an Primitiven macht die benachbarte Platzierung portabel. Managed Cloud auf AWS ist für die meisten Teams das Standardmodell im Produktivbetrieb. Dieselbe Engine kann in Ihrem eigenen AWS-Konto laufen, wenn Infrastrukturkontrolle oder Datenperimeter das erfordern. Eine andere Cloud und On-Premise sind die verbleibenden Deployment-Modelle. Der Anwendungsvertrag bleibt über alle vier Modelle hinweg GraphQL.

Das Plattformteam muss mehr liefern als Infrastruktur. Es muss Quellverantwortung, Änderungserfassung und Löschung definieren. Halten Sie für jede Quelle fest:

welche Felder zum Matching beitragen dürfen;
ob ein Wert vertrauenswürdig, beobachtet oder vom Nutzer angegeben ist;
wie Korrekturen und Löschungen abgebildet werden;
welches System für den Originaldatensatz maßgeblich bleibt;
wer die aufgelöste Entität abfragen darf;
wo die zurückgegebene Entitäts-ID gespeichert wird.

Normalisierung gehört an eine bewusst gesetzte Grenze. Tilores normalisiert und speichert die von der Engine genutzten Werte und behält die Originale bei. Quellspezifische Bereinigung, die fachliche Semantik abbildet, kann vor der Ingestion stattfinden. Der generische Identitätsvergleich sollte in der Auflösungskonfiguration bleiben, wo er sichtbar und testbar ist.

Was ändert sich, wenn jede Zeile eine Entitäts-ID trägt?

Eine Entitäts-ID verwandelt systemübergreifende Analysen von einer stets wiederholten Matching-Übung in einen gewöhnlichen Join. Sie macht nicht jeden Datensatz korrekt, aber sie gibt jeder autorisierten Zeile eine konsistente Referenz auf dasselbe aufgelöste Subjekt.

Am einfachsten lässt sich der Effekt in einer Platzierungstabelle zeigen.

Schicht	Wofür sie zuständig ist	Was sie erhält	Was sie nicht annehmen darf
Quellsystem	Originaldatensatz und Geschäftsprozess	Optional die aufgelöste Entitäts-ID	Dass lokale Duplikate verschwunden sind
Ingestion und Streaming	Änderungserfassung, Mapping und Zustellung	Entitäts-ID oder Entitätsaktualisierung	Dass Wiederholungsversuche neue Identitäten anlegen dürfen
Entity Resolution	Matching, aktuelle Entität, Herkunft und Entitäts-ID	Quelldatensätze und Korrekturen	Dass sie über das Matching hinaus für Einwilligung oder fachliche Wahrheit zuständig ist
Lakehouse	Historie, Modelle, Analytics und Feature-Daten	Stabile Entitäts-ID in jeder relevanten Zeile	Dass der jüngste analytische Ladelauf das aktuelle operative Profil ist
Reverse ETL und Aktivierung	Bewegung zu Zielsystemen	Kontrollierte, nach Entität geschlüsselte Segmente	Dass jedes Zielsystem jedes Quellattribut sehen darf
Operative Anwendung	Kundeninteraktion und Entscheidung	Aktuelle autorisierte Entität über GraphQL	Dass eine aufgelöste Verknüpfung die Erlaubnis erteilt, alle verknüpften Daten zu nutzen

Analystinnen und Analysten können den Kundenwert über Commerce- und Support-Datensätze hinweg berechnen, ohne Namens- und Adressähnlichkeit in jedes Modell einzubauen. Produktteams können Features gegen eine stabile Entität definieren. KI-Teams können einen autorisierten Kundenkontext abrufen, statt ein Modell die Identität aus Dokumentfragmenten erschließen zu lassen.

Das hat Folgen für die Governance. Eine Entitäts-ID kann zu einem mächtigen Join-Schlüssel werden, deshalb sollte der Zugriff eingegrenzt sein. Dass zwei Datensätze zur selben Person aufgelöst werden, heißt nicht, dass jeder Geschäftsbereich oder jede Anwendung beide sehen darf. Setzen Sie Berechtigungen auf Attribut- und Quellenebene in der Abfrage- und Konsumschicht durch.

Entitäts-IDs brauchen außerdem Lebenszyklusregeln. Nachgelagerte Tabellen sollten damit umgehen können, dass sich eine Entität nach einer Korrektur ändert. Führen Sie eine Zuordnung oder eine Ereignishistorie, damit ein Team nachvollziehen kann, ob zwei IDs zusammengeführt wurden, eine Entität aufgespalten wurde oder ein Datensatz gewandert ist. Überschreiben Sie die Historie nicht so, dass sich der Bericht von gestern nicht mehr reproduzieren lässt.

Wie halten Sie die aufgelöste Sicht zwischen den Ladeläufen aktuell?

Nutzen Sie die Datensatzänderung als Auslöser. Wenn eine Quelle einen relevanten Datensatz anlegt, ändert oder löscht, veröffentlichen Sie dieses Ereignis über den Ingestion-Pfad. Die Queue gibt der Engine eine verlässliche Arbeitseinheit. Die Auflösung aktualisiert die operative Entität, und nachgelagerte Konsumenten können die neue Entitäts-ID erhalten oder die aktuelle Sicht abfragen.

Für reine Batch-Quellen verwenden Sie inkrementelle Extrakte und explizite Wasserzeichen. Eine tägliche Quelle kann neben Echtzeitquellen bestehen, aber die zugesagte Aktualität muss sichtbar sein. Ein Profil sollte ausweisen, dass sich das CRM vor Sekunden geändert hat, während eine alte Abrechnungsquelle zuletzt über Nacht aktualisiert wurde.

Idempotenz ist unverzichtbar. Ein erneut zugestelltes Ereignis muss denselben Quelldatensatz aktualisieren, statt ein Duplikat zu erzeugen. Verwenden Sie Quellname und Quelldatensatz-ID als dauerhafte Identität für die Ingestion. Halten Sie Ereigniszeit und Verarbeitungszeit getrennt fest, damit verspätete Ereignisse verständlich bleiben.

Die Abstimmung gehört weiterhin ins Lakehouse. Vergleichen Sie regelmäßig erwartete Quellmengen, eingelesene Datensätze und aufgelöste Ergebnisse. Prüfen Sie Entitäten, die ungewöhnlich schnell wachsen, und Datensätze, die unverknüpft bleiben. Die analytische Umgebung eignet sich für dieses Monitoring gut, auch wenn sie nicht die operative Matching-Engine ist.

Korrekturen und Löschungen brauchen einen erstklassigen Pfad. Zieht eine Quelle eine Telefonnummer zurück oder entfernt eine freigegebene Aufbewahrungsregel einen Datensatz, muss die Engine die Entität neu ordnen, statt eine veraltete Verknüpfung stehen zu lassen. Tilores unterstützt Aufbewahrungsregeln je Quelle und protokolliert Abfragen, Exporte und Löschungen. Der Verantwortliche entscheidet weiterhin, was aufbewahrt oder gelöscht werden muss.

Welches Deployment-Modell passt zu einem Lakehouse-Team?

Beginnen Sie beim Datenperimeter und beim Betriebsmodell und wählen Sie dann der Reihe nach aus den vier Deployment-Optionen.

Managed Cloud auf AWS passt zu Teams, die den schnellsten unterstützten Weg in den Produktivbetrieb wollen und die zugrunde liegenden Primitive nicht selbst betreiben müssen. Für die meisten Organisationen ist das die Standardantwort – auch dann, wenn das Lakehouse anderswo liegt, sofern freigegebene Daten diese Grenze überschreiten dürfen.

Ihr eigenes AWS-Konto passt zu Teams, die Engine und Daten innerhalb des eigenen AWS-Perimeters brauchen und dabei die AWS-Referenzarchitektur beibehalten wollen. Das Plattformteam verantwortet mehr von den Kontosteuerungen und der Integrationsfläche.

Eine andere Cloud passt zu Organisationen, deren freigegebener Perimeter in einer anderen Cloud liegt. Dieselben drei Kategorien von Primitiven werden auf diese Umgebung abgebildet. Der GraphQL-Vertrag und das Matching-Verhalten bleiben gleich.

On-Premise passt zu einem Perimeter, der kein Cloud-Deployment nutzen kann. Es ist eine unterstützte Kontrolloption, nicht die Standardempfehlung und auch kein Kürzel für mehr Sicherheit.

Entscheidungskriterium	Bestes Ausgangsmodell	Platzierung neben dem Lakehouse
Das Team will den geringsten Betriebsaufwand	Managed Cloud auf AWS	Identitätsfelder per Stream oder Batch an den Managed Service senden und Entitäts-IDs zurückerhalten
Daten und Kontrollen müssen im AWS-Konto des Kunden bleiben	Eigenes AWS-Konto	Die Engine in derselben freigegebenen Kontogrenze wie die Lakehouse-Integrationen betreiben
Der freigegebene Datenperimeter liegt in einer anderen Cloud	Andere Cloud	Die Primitive nahe am Lakehouse platzieren, ohne eine anbieterspezifische Architektur festzuschreiben
Das Netzwerk ist von Cloud-Diensten isoliert	On-Premise	Die Engine innerhalb des isolierten Perimeters betreiben und nur freigegebene Ergebnisse austauschen

Die richtige Antwort ist nicht automatisch die Umgebung, in der zufällig das Warehouse läuft. Es ist das Modell, das unnötige Datenbewegung minimiert und zugleich jedem autorisierten Konsumenten eine einzige operative Identität zur Verfügung stellt. Die Deployment-Optionen erlauben es, die Engine an diesen Perimeter zu bringen, statt die Datenlandschaft in einen neuen zu zwingen.

Platzieren Sie die Auflösung neben dem Lakehouse, und die Arbeitsteilung wird klar. Das Lakehouse erinnert sich daran, was geschehen ist. Die Entitäts-Engine entscheidet, welche Datensätze jetzt zusammengehören. Die Entitäts-ID verbindet beides, ohne von einem der Systeme zu verlangen, das andere zu werden.

Häufig gestellte Fragen

Sollte Entity Resolution innerhalb von Snowflake oder Databricks laufen?

Entity Resolution sollte in der Regel neben Snowflake oder Databricks laufen, wenn Anwendungen zwischen den analytischen Aktualisierungen eine aktuelle Identität benötigen. Das Lakehouse verwahrt Historie und Analyse; die benachbarte Engine hält die operative Entität aktuell.

Welche Daten sollten nach der Entity Resolution ins Lakehouse zurückfließen?

Das Lakehouse sollte eine stabile Entitäts-ID, die Quellherkunft und alle für die Analyse benötigten, kontrollierten Auflösungsereignisse erhalten. Es sollte die Matching-Logik nicht in jedem Modell nachbilden müssen.

Wie fragen Anwendungen den aktuell aufgelösten Kunden ab?

Anwendungen fragen die aktuelle Tilores-Entität über GraphQL ab. Sie können ausschließlich die für den jeweiligen Workflow autorisierten Felder und verknüpften Datensätze anfordern.

Kann die Engine im selben Perimeter wie das Lakehouse laufen?

Tilores kann als Managed Cloud auf AWS, im AWS-Konto des Kunden, in einer anderen freigegebenen Cloud oder on-premise laufen. Wählen Sie das erste Modell, das Datenperimeter und Betriebsverantwortung erfüllt.

Gewährt eine Entitäts-ID Zugriff auf jedes verknüpfte Attribut?

Eine Entitäts-ID gewährt keinen Zugriff auf jedes Attribut. Sie ist eine kontrollierte Referenz; Berechtigungen auf Quellen- und Attributebene bestimmen weiterhin, was jeder Konsument abrufen darf.