Un utilisateur demande la suppression de ses données. Comment satisfaites-vous cette demande sur un data lake et un entrepôt ?

Il faut savoir où vivent les données personnelles avant de pouvoir les supprimer : commencez donc par la classification et le lignage. Préférez une conception qui évite le problème : pseudonymisez à l'ingestion et gardez la table de correspondance des identifiants dans un seul magasin restreint, si bien que supprimer cette correspondance rend le reste non identifiant. Là où les données brutes doivent être supprimées, utilisez un format de table qui gère les suppressions au niveau ligne et suivez la demande jusqu'à son achèvement, sauvegardes comprises.

La première réponse honnête, c'est qu'on ne peut pas supprimer ce qu'on n'a pas catalogué : tout dépend donc du fait que la classification et le lignage soient déjà en place. La conception que je défends, c'est la pseudonymisation à l'ingestion : l'identifiant brut est remplacé par un jeton de substitution à la frontière, et la correspondance vit dans un seul magasin restreint. Une demande de suppression revient alors surtout à supprimer une ligne dans ce magasin, après quoi tout ce qui est en aval n'est plus rattaché à une personne. C'est bien moins coûteux que de réécrire des années de Parquet. Là où une suppression réelle est exigée, un format de table comme Iceberg ou Delta vous donne des suppressions au niveau ligne sans réécrire manuellement des partitions entières. Les parties qu'on oublie sont les plus ingrates : les snapshots et l'historique de voyage dans le temps, les sauvegardes avec leur propre rétention, l'extraction CSV que quelqu'un a envoyée par e-mail, et tout outil d'analytique tiers qui détient une copie. Je définirais la fenêtre de rétention des snapshots pour que les suppressions y deviennent définitives, je le documenterais, et je garderais une trace auditable de chaque demande et de son achèvement.