Un usuario solicita el borrado de sus datos. ¿Cómo lo satisfaces en un data lake y un warehouse?

Necesitas saber dónde viven los datos personales antes de poder borrarlos, así que empieza por la clasificación y el linaje. Prefiere un diseño que evite el problema: seudonimiza en la ingesta y guarda el mapeo de identificadores en un único almacén restringido, de modo que borrar ese mapeo deje el resto sin capacidad de identificar. Donde haya que borrar el dato crudo, usa un formato de tabla que soporte borrados a nivel de fila y sigue la solicitud hasta el final, incluyendo los backups.

La primera respuesta honesta es que no puedes borrar lo que no has catalogado, así que esto depende por completo de que la clasificación y el linaje ya estuvieran en su sitio. El diseño que defiendo es la seudonimización en la ingesta: el identificador crudo se sustituye por un token subrogado en la frontera y el mapeo vive en un único almacén restringido. Entonces una solicitud de borrado es sobre todo borrar una fila en ese almacén, tras lo cual nada de lo que hay aguas abajo sigue vinculado a una persona. Eso es mucho más barato que reescribir años de Parquet. Donde hace falta el borrado real, un formato de tabla como Iceberg o Delta te da borrados a nivel de fila sin reescribir particiones enteras a mano. Las partes que la gente olvida son las incómodas: los snapshots y el histórico de viaje en el tiempo, los backups con su propia retención, el CSV que alguien mandó por correo y cualquier herramienta de analítica de terceros que guarde una copia. Yo definiría la ventana de retención de snapshots para que los borrados sean permanentes dentro de ella, lo documentaría, y guardaría un registro auditable de cada solicitud y de cuándo se completó.