Datendeduplizierung in Snowflake mit Tilores automatisieren
Kurzfassung
- Identity Resolution steht zwischen rohen Kundentabellen und der nachgelagerten Analytik: Sie vergibt eine stabile entity_id an alle Datensätze, die denselben realen Kunden, dasselbe Unternehmen, denselben Account oder eine andere Entität beschreiben.
- In dem hier gezeigten Snowflake-Muster stößt Snowflake die Arbeit immer selbst an: Neue Zeilen werden verarbeitet, Tilores löst wahrscheinliche Übereinstimmungen auf, und die aufgelöste entity_id wird für Joins, Segmentierung und Missbrauchserkennung zurückgeschrieben.
- Nutzen Sie dieses Muster, wenn eine SQL-Deduplizierung über exakte Übereinstimmungen zu brüchig ist, weil Kunden über die Zeilen hinweg Namen, E-Mail-Domains, Schreibweisen oder Registrierungsdaten ändern.
Inhaltsverzeichnis
- Kurze Antwort
- Nächster Schritt mit Tilores
- Entscheidungshilfe
- Wo gehört Identity Resolution in einen Snowflake-Datenworkflow?
- Was ändert sich, wenn jede Kundenzeile eine entity_id hat?
- Warum unterscheidet sich das von einfacher SQL-Deduplizierung?
- Wie lässt sich das Muster über dieses eine Snowflake-Beispiel hinaus übertragen?
- Was sollten Datenteams vor dem Produktiveinsatz prüfen?
- Häufige Fragen
Kurze Antwort
Identity Resolution gehört im modernen Data Stack an die Stelle einer Anreicherungsschicht, die doppelte oder beinahe doppelte Kundenzeilen in dauerhafte Entitäts-Identifikatoren verwandelt. Snowflake oder eine Lakehouse-Plattform kann weiterhin die Rohdaten speichern und die Transformationen ausführen, während der Schritt der Identity Resolution entscheidet, welche Zeilen dieselbe reale Entität abbilden.
Für den Snowflake-Workflow dieses Artikels ist das praktische Ergebnis eine entity_id, die neben den Kundendatensätzen in einer Tabelle customers_entities abgelegt wird. Nachgelagerte Teams können dann über die entity_id joinen, statt jede leicht abweichende E-Mail-Adresse, jeden abweichenden Namen oder jede abweichende Domain als eigenen Kunden zu behandeln.
Nächster Schritt mit Tilores
Wählen Sie den nächsten Schritt, der zu Ihrem Evaluierungsstand passt.
Entscheidungshilfe
| Frage | Tilores eignet sich, wenn | Worauf zu achten ist |
|---|---|---|
| Wo im Data Stack sollte Identity Resolution sitzen? | Platzieren Sie sie, nachdem die rohen Kundendatensätze angekommen sind, und bevor nachgelagerte Analytik, Segmentierung, Betrugsprüfungen oder der Kontextabruf für KI von diesen Datensätzen abhängen. | Ersetzen Sie damit nicht das Warehouse oder Lakehouse. Snowflake, Databricks oder die gewählte Plattform bleibt das System, das die analytischen Daten speichert und verwaltet. |
| Wann reicht Deduplizierung allein im Warehouse? | Setzen Sie Tilores ein, wenn sich Datensätze in Schreibweise, Domain, Adresse, Namensreihenfolge oder Registrierungsmuster unterscheiden und trotzdem zu einer entity_id zusammenfallen sollen. | Exakte SQL-Regeln können bei offensichtlichen Duplikaten nützlich sein, übersehen aber unscharfe Duplikate oder erzeugen falsche Sicherheit, wenn sich Identifikatoren ändern. |
| Was sollte nach Snowflake zurückgeschrieben werden? | Schreiben Sie eine stabile entity_id und genügend Kontext zu den Quellzeilen zurück, damit Analystinnen und Analysten nachvollziehen können, welche Eingabezeilen gruppiert wurden. | Verstecken Sie das Matching-Ergebnis nicht in einem undurchsichtigen Prozess. Datenteams brauchen Nachvollziehbarkeit für Prüfung, Fehlersuche und das Vertrauen nachgelagerter Systeme. |
| Wie sollten Teams das Muster testen? | Beginnen Sie mit einer Kundentabelle mit Duplikaten, prüfen Sie die gruppierten Entitäts-IDs, fügen Sie dann beinahe identische Datensätze hinzu und bestätigen Sie, dass sie sich der erwarteten Entität zuordnen. | Prüfen Sie False Positives und False Negatives, bevor Sie sich für automatische Kundensperrlisten, die Erkennung von Testphasen-Missbrauch oder Marketing-Segmentierung auf die IDs verlassen. |
Wo gehört Identity Resolution in einen Snowflake-Datenworkflow?
Identity Resolution sollte zwischen Aufnahme und Nutzung sitzen: Zuerst treffen die rohen Kundenzeilen ein, dann läuft das Matching, und die aufgelöste entity_id steht bereit, bevor BI-, Marketing-, Betrugs- oder Customer-360-Workflows die Daten lesen.
Diese Platzierung belässt Orchestrierung und Speicherung bei Snowflake und gibt nachgelagerten Abfragen zugleich einen saubereren Join-Schlüssel als Namens-, E-Mail- oder Kontofelder allein.
Was ändert sich, wenn jede Kundenzeile eine entity_id hat?
Die entity_id verwandelt eine Gruppe unsauberer Zeilen in eine abfragbare Kundenidentität. Analysten können tatsächliche Kunden zählen, nach aufgelösten Entitäten segmentieren und wiederkehrende Registrierungsmuster erkennen, ohne in jedem Report erneut eine Fuzzy-Matching-Logik zu bauen.
Für die Missbrauchserkennung hilft derselbe Identifikator dabei, Fälle aufzudecken, in denen eine Person oder ein Unternehmen mit kleinen Abweichungen in den Registrierungsdaten mehrere Konten anlegt.
Warum unterscheidet sich das von einfacher SQL-Deduplizierung?
SQL-Deduplizierung ist am stärksten, wenn Datensätze exakte Schlüssel oder vorhersagbare Formate teilen. Identity Resolution wird gebraucht, wenn Duplikate nur ungefähr übereinstimmen: geänderte Domains, Tippfehler, Kurzformen von Namen, vertauschte Namensbestandteile und unvollständige Felder können Regeln für exakte Übereinstimmungen allesamt aushebeln.
Ein praxistaugliches Design des Data Stacks kann deterministische SQL-Prüfungen durchaus beibehalten, sollte sich aber nicht allein auf sie verlassen, wenn das Geschäftsproblem unscharf ist.
Wie lässt sich das Muster über dieses eine Snowflake-Beispiel hinaus übertragen?
Die wiederverwendbare Architektur ist plattformneutral: Rohdatensätze bleiben im Warehouse oder Lakehouse, Entitäten werden als Teil der Datenpipeline aufgelöst, und der aufgelöste Identifikator wird dort abgelegt, wo nachgelagerte Werkzeuge ihn abfragen können.
Die Umsetzungsdetails unterscheiden sich je nach Plattform. Deshalb bleibt die konkrete Anleitung hier bei Snowflake, während klar bleibt, dass die Rolle im Data Stack dieselbe ist: Identity Resolution liefert den Kundenschlüssel, der Rohtabellen häufig fehlt.
Was sollten Datenteams vor dem Produktiveinsatz prüfen?
Bevor Entitäts-IDs produktiv genutzt werden, sollten Teams zusammengeführte Gruppen stichprobenartig prüfen, Grenzfälle ansehen und bestätigen, dass sich die Identifikatoren sowohl bei offensichtlichen als auch bei beinahe identischen Duplikaten korrekt verhalten.
Ziel ist nicht nur, die Zeilenzahl zu senken. Ziel ist, Entscheidungen auf Kundenebene verlässlicher zu machen und dabei genügend Quellkontext zu bewahren, um die Gruppierung der Datensätze prüfen zu können.
Missbrauch kostenloser Testphasen verhindern: Identity Resolution für Ihre Snowflake-Kundendaten
Das Problem
Doppelte Kundendaten sind kaum zu vermeiden – sei es, weil Daten aus verschiedenen Quellen stammen, weil Kunden sich mehrfach registrieren oder weil bei der manuellen Erfassung Fehler passieren. Eine weitere mögliche Ursache: Kunden melden sich online mehrfach an und ändern dabei jedes Mal ihre Daten leicht, um kostenlose Testphasen oder Neukundenrabatte auszunutzen.
Das führt zu mehreren Zeilen in einer Tabelle, die denselben Kunden, dasselbe Unternehmen oder eine andere Entität abbilden. Ein klassisches Identity-Resolution-Problem. Wie lässt sich das in Snowflake lösen?
Was Sie erwartet
In diesem Leitfaden starten wir mit einer Snowflake-Tabelle, die doppelte Kundendaten enthält, und landen am Ende bei einer weiteren Tabelle mit einem neuen Feld (entity_id), das für jeden Kunden ein eindeutiger Identifikator ist.
Für alle neuen Daten, die der Tabelle hinzugefügt werden, wird die **entity_id **automatisch berechnet.
Testtabelle in Snowflake anlegen
Legen Sie ein neues Worksheet an und führen Sie Folgendes aus:
CREATE DATABASE DEMO;
USE DATABASE DEMO;
CREATE or REPLACE TABLE customers(
"id" VARCHAR,
"first_name" VARCHAR,
"last_name" VARCHAR,
"email" VARCHAR
);
ALTER TABLE customers SET CHANGE_TRACKING = TRUE;
INSERT INTO customers VALUES
('1', 'John', 'Smith', 'john.smith@example.com'),
('2', 'Jessica', 'Davis', 'jessica.davis@example.com'),
('3', 'John Robert', 'Smith', 'js@example.com'),
('4', 'Jane', 'Doe', 'jane@example.com'),
('5', 'J. Robert', 'Smith', 'js+1@example.com'),
('6', 'Jessika', 'Davis', 'jessd@example.com');
SELECT * from customers;Laden Sie das Ergebnis als CSV herunter. Wir nutzen es im nächsten Schritt, um die Matching-Regeln automatisch zu erzeugen.
Snowflake mit Tilores verbinden
Nutzen Sie statt des alten Signup-Links den aktuellen Evaluierungsweg von Tilores: Tilores Studio kostenlos testen für die lokale Evaluierung oder Demo buchen, um das aktuelle Cloud-Setup für Snowflake zu klären. Laden Sie anschließend die CSV-Datei aus dem vorherigen Schritt und folgen Sie der Einrichtungsanleitung für die Umgebung, die Sie evaluieren, bevor Sie die Snowflake-Integration anlegen.
Nun legen wir eine API-Integration an, über die Snowflake Aufrufe an Tilores senden kann.
Snowflake baut die Verbindung immer selbst auf, sendet Daten an Tilores und fordert Daten von dort an – nie umgekehrt.
Gehen Sie in der Tilores-UI zu Integration — Snowflake, kopieren Sie im Abschnitt „Where to get these values?“ die Codeblöcke und führen Sie sie in einem neuen Worksheet in Ihrem Snowflake-Workspace aus.
Das Ergebnis der letzten Abfrage sollte API_AWS_IAM_USER_ARN enthalten. Kopieren Sie den Wert und tragen Sie ihn in der Tilores-UI im Feld User ARN ein. Kopieren Sie ebenso den Wert von **API_AWS_EXTERNAL_ID **und tragen Sie ihn in der Tilores-UI unter External ID ein. Klicken Sie dann auf **UPDATE **, um die Verbindung zu aktivieren.
Es sollte folgendes Banner erscheinen:
Jetzt sind Snowflake und Tilores verbunden.
Automatische Entitätserkennung in Snowflake einrichten
Als Nächstes legen wir eine Task an, die alle neuen Daten in der eingangs erstellten Tabelle **customers **verarbeitet und in einer neuen Tabelle customers_entities eine Zeile mit einer **entity_id **erzeugt. Führen Sie Folgendes in Snowflake aus:
USE DATABASE DEMO;
ALTER TABLE customers SET CHANGE_TRACKING = TRUE;
CREATE or REPLACE TABLE customers_entities(
"entity_id" VARCHAR,
"customer_id" VARCHAR
);
CREATE OR REPLACE TABLE TILORES_CONFIG (
name varchar(255) NOT NULL,
value varchar(255) default NULL
);
INSERT INTO TILORES_CONFIG VALUES
('last_sync', CURRENT_TIMESTAMP()::string),
('fetch_on_next_run', 'true');
SELECT * FROM TILORES_CONFIG;
CREATE OR REPLACE TASK tilores_sync
SCHEDULE = '1 MINUTE'
AS
DECLARE
now STRING;
last_sync STRING;
fetch_on_next_run STRING;
BEGIN
now := (SELECT CURRENT_TIMESTAMP());
last_sync := (SELECT value FROM TILORES_CONFIG WHERE name='last_sync');
fetch_on_next_run := (SELECT value FROM TILORES_CONFIG WHERE name='fetch_on_next_run');
SELECT tilores_ingest(OBJECT_CONSTRUCT(*)) AS ingested
FROM (
SELECT * EXCLUDE(METADATA$ACTION, METADATA$ISUPDATE, METADATA$ROW_ID)
FROM customers
CHANGES(INFORMATION => DEFAULT)
AT(TIMESTAMP => to_timestamp_tz(:last_sync))
WHERE METADATA$ACTION='INSERT');
IF (fetch_on_next_run = 'true') THEN
MERGE INTO customers_entities TARGET USING (SELECT tilores_entity_by_record_id("id"):id AS "entity_id", "id" FROM customers) SOURCE
ON TARGET."customer_id" = SOURCE."id"
WHEN MATCHED THEN
UPDATE SET
TARGET."entity_id" = SOURCE."entity_id"
WHEN NOT MATCHED THEN
INSERT ("entity_id", "customer_id")
VALUES (SOURCE."entity_id", SOURCE."id");
END IF;
UPDATE TILORES_CONFIG
SET value = :now
WHERE name = 'last_sync';
UPDATE TILORES_CONFIG
SET value = (SELECT
CASE
WHEN count(*) > 0 THEN 'true'
ELSE 'false'
END AS fetch_on_next_run
FROM customers
CHANGES(INFORMATION => DEFAULT)
AT(TIMESTAMP => to_timestamp_tz(:last_sync))
WHERE METADATA$ACTION='INSERT')
WHERE name = 'fetch_on_next_run';
END;
ALTER TASK tilores_sync RESUME;
SELECT *
FROM TABLE(information_schema.task_history())
ORDER BY scheduled_time;Die Automatisierung testen
Nach zwei Minuten ist in customers_entities für jeden Kunden eine Zeile angelegt. Mit einem Join lässt sich also erkennen, welche Kundenzeilen zu welchem tatsächlichen Kunden gehören.
SELECT * EXCLUDE("customer_id")
FROM customers
LEFT JOIN customers_entities ON "id"="customer_id"
ORDER BY "id";Das sollte zu folgendem Ergebnis führen:
Anhand der Entitäts-IDs zeigt sich, dass diese Zeilen nur drei tatsächliche Kunden abbilden.
Fügen wir nun einen weiteren Kunden mit ähnlichem Namen, ein paar Schreibfehlern und einer anderen E-Mail-Domain hinzu, sollte sie dieselbe **entity_id **wie die erste Zeile erhalten.
INSERT INTO customers VALUES
('7', 'Johnn', 'Smeth', 'john.smith@otherDomain.com');Warten Sie zwei Minuten und führen Sie dann Folgendes erneut aus:
SELECT * EXCLUDE("customer_id")
FROM customers
LEFT JOIN customers_entities ON "id"="customer_id"
ORDER BY "id";Das Ergebnis sollte nun so aussehen:
In diesem Fall ist die entity_id der tatsächliche Kundenidentifikator.
Fazit – Identity Resolution in Snowflake
Indem eindeutige Entitäts-IDs für Kunden eingeführt werden, sorgt dieser Identity-Resolution-Ansatz für eine belastbare Customer-360-Sicht in Snowflake und ermöglicht eine einfache Kundensegmentierung für das Marketing. Weitere Anwendungsfälle sind das Erkennen doppelter Kontoanlagen im Zusammenhang mit dem Missbrauch kostenloser Testphasen.
Häufige Fragen
- Wie fügt sich Identity Resolution in einen modernen Data Stack mit Snowflake oder Databricks ein?
- Identity Resolution fügt sich als Anreicherungsschicht zwischen rohe Kundendaten und nachgelagerte Anwendungsfälle ein. Das Warehouse oder Lakehouse speichert und verarbeitet die Datensätze, während die Auflösungsschicht stabile Entitäts-IDs vergibt, die Analytics-, Betrugs-, Customer-360- und KI-Workflows abfragen können.
- Reicht Deduplizierung in Snowflake, um Missbrauch kostenloser Testphasen zu erkennen?
- Snowflake unterstützt exakte und regelbasierte Deduplizierung, doch beim Missbrauch kostenloser Testphasen werden Namen, E-Mail-Adressen, Domains oder andere Attribute meist leicht verändert. Identity Resolution eignet sich besser, wenn es darum geht, dieselbe reale Entität über beinahe identische Datensätze hinweg zu finden.
- Was sollte eine Snowflake-Pipeline speichern, nachdem Kundendatensätze aufgelöst wurden?
- Die Pipeline sollte eine stabile entity_id neben den relevanten Kundendatensätzen oder in einer verknüpften Entitätstabelle speichern. Außerdem sollte sie genügend Kontext zu den Quellzeilen bewahren, damit Analystinnen und Analysten prüfen können, welche Datensätze gruppiert wurden.
- Kann dieselbe entity_id Customer-360- und Betrugs-Workflows unterstützen?
- Ja. Dieselbe aufgelöste entity_id kann Customer 360, Segmentierung, Sperrlisten und Betrugsprüfungen unterstützen, denn jeder dieser Anwendungsfälle profitiert davon, den realen Kunden oder das reale Unternehmen zu sehen statt isolierter Duplikatzeilen.
Tilores mit Ihren eigenen Daten evaluieren
Wählen Sie den nächsten Schritt, der zu Ihrem Evaluierungsstand passt.
Sehen Sie, was aufgelöste Entitätsdaten für Ihr Unternehmen — und Ihre KI — leisten.