Ein Nutzer verlangt die Löschung seiner Daten. Wie erfüllst du das über einen Data Lake und ein Warehouse hinweg?

Du musst wissen, wo personenbezogene Daten liegen, bevor du sie löschen kannst, also fang bei Klassifizierung und Lineage an. Bevorzug ein Design, das das Problem vermeidet: pseudonymisier beim Ingest und halt das Mapping der Kennungen in einem einzigen zugriffsbeschränkten Store, sodass das Löschen dieses Mappings den Rest nicht mehr personenbeziehbar macht. Wo Rohdaten wirklich gelöscht werden müssen, nutz ein Tabellenformat mit Deletes auf Zeilenebene und verfolg die Anfrage bis zum Abschluss, inklusive Backups.

Die ehrliche erste Antwort ist, dass du nicht löschen kannst, was du nicht katalogisiert hast, das hängt also vollständig daran, dass Klassifizierung und Lineage vorher existieren. Das Design, für das ich plädiere, ist Pseudonymisierung beim Ingest: die rohe Kennung wird an der Grenze durch ein Surrogat-Token ersetzt und das Mapping lebt in einem einzigen zugriffsbeschränkten Store. Eine Löschanfrage ist dann größtenteils das Löschen einer Zeile in diesem Store, danach ist nichts stromabwärts mehr mit einer Person verknüpft. Das ist viel billiger, als Jahre von Parquet neu zu schreiben. Wo echtes Löschen verlangt ist, gibt dir ein Tabellenformat wie Iceberg oder Delta Deletes auf Zeilenebene, ohne ganze Partitionen von Hand neu zu schreiben. Vergessen werden immer die unbequemen Teile: Snapshots und Time-Travel-Historie, Backups mit eigener Aufbewahrung, CSV-Exporte, die jemand per Mail verschickt hat, und jedes Drittanbieter-Analytics-Tool mit einer Kopie. Ich würde das Aufbewahrungsfenster für Snapshots so definieren, dass Löschungen darin endgültig werden, das dokumentieren und einen prüfbaren Nachweis pro Anfrage und Abschluss führen.