Retención de datos en Databricks: cómo Oportun anonimiza la PII

Cómo la anonimización irreversible de datos y la actualización controlada de Bronze a Gold cumplen los requisitos de retención de Oportun relacionados con la FTC.
Este es un caso de estudio de Databricks que explica cómo anonimizamos de forma irreversible información de identificación personal (o PII por sus siglas en inglés) relacionada con requisitos, asociada con clientes potenciales, solicitantes y miembros, y conservamos solo las características de datos aprobadas que se requieren para el análisis.
La misma información puede servir a diferentes propósitos en un ecosistema de datos. Como parte de nuestro proceso de retención relacionado con la FTC, eliminamos la PII calificadora de las bases de datos operativas. En el lakehouse (una arquitectura que combina las bondades de un data lake y un data warehouse), eliminar un registro completo también removería características y relaciones aprobadas que siguen siendo útiles para el análisis estadístico. Necesitábamos reemplazar los valores originales que identifican a una persona en las tablas en estado activo de Databricks, conservar únicamente la estructura analítica aprobada y, más adelante, eliminar archivos obsoletos elegibles mediante mantenimiento.
Abordamos ese desafío combinando nuestro servicio de Sanitización de Datos con un flujo de trabajo controlado de Delta Live Tables. Delta Live Tables, o DLT, ahora se denomina Lakeflow pipelines. El diseño transforma la PII calificadora en Bronze para generar resultados anonimizados irreversibles; vuelve a construir Silver y Gold a partir de ese estado transformado y usa el mantenimiento de DLT para eliminar los archivos obsoletos elegibles después de que se cumplan las condiciones de retención configuradas.

Esto es lo que vamos a cubrir

• Por qué la retención de datos pasa a ser en un reto de ingeniería para un lakehouse
• Por qué los cambios históricos en Bronze requieren un recálculo controlado
• El flujo de trabajo exacto de producción en cuatro pasos
• Cómo la Sanitización de Datos de Oportun realiza una anonimización irreversible
• Cómo el estado transformado llega a Silver y Gold
• Qué aprendimos al llevar el diseño a producción
• Preguntas frecuentes

Puntos clave

• Eliminamos la PII calificadora de las bases de datos operativas y anonimizamos de manera irreversible la PII correspondiente en Bronze, conservando únicamente las características analíticas aprobadas.
• El flujo de trabajo de producción detiene DLT, anonimiza Bronze, realiza una actualización completa de Silver y Gold, y espera el mantenimiento automático de VACUUM (limpieza de datos).
• El etiquetado basado en configuración aplica una transformación consistente en Bronze, y el recomputo posterior lleva consigo ese estado a Silver y Gold.

Por qué la retención de datos pasa a ser un reto de ingeniería para un lakehouse

Los sistemas operativos y los sistemas analíticos no usan los registros de la misma manera. Las bases de datos operativas respaldan clientes activos y procesos comerciales. El lakehouse respalda análisis estadísticos aprobados y características posteriores del flujo.
Nuestro proceso de retención identifica la PII calificadora asociada a clientes potenciales, solicitantes y miembros. Las reglas de elegibilidad específicas se rigen por políticas y procedimientos operativos, por lo que la arquitectura pública no codifica el umbral ni la frecuencia de ejecución.
Para los registros calificadores, el resultado operativo es eliminar la PII de las bases de datos de origen. El resultado analítico es distinto. Remover el registro completo del lakehouse también eliminaría atributos, características y relaciones no identificables que siguen aprobados para el análisis.
Por lo tanto, el objetivo de ingeniería fue preciso: reemplazar los valores originales que identifican a una persona en las tablas de Databricks en estado activo, conservar solo la estructura analítica aprobada, propagar ese estado a cada capa posterior del lakehouse y, más adelante, eliminar los archivos obsoletos elegibles mediante mantenimiento.
Este es un problema de anonimización, no un problema de control de acceso. Para este flujo, nuestro servicio de Sanitización de Datos devuelve resultados transformados irreversibles. La PII original no puede reconstruirse a partir de esos resultados.

Por qué los cambios históricos en Bronze requieren una recalculo controlado

Organizamos los datos del lakehouse en las capas Bronze, Silver y Gold. Bronze contiene la representación Delta que utiliza el procesamiento posterior. Silver transforma los eventos de Bronze en conjuntos de datos refinados y combinados. Gold proporciona datos y características curados y aprobados para el consumo.
El procesamiento incremental normal maneja la información nueva de forma eficiente. El flujo de trabajo de retención es diferente, porque cambia registros que las tablas posteriores ya procesaron.
En esta implementación, las actualizaciones de los registros de Bronze procesados previamente entraban en conflicto con el comportamiento de las tablas de transmisión posteriores de Silver. Cambiar un valor histórico en Bronze no reconstruía por sí solo todos los resultados de Silver o Gold que se habían derivado del valor anterior.
La solución fue hacer que el estado transformado de Bronze fuera la fuente autorizada para las capas posteriores del lakehouse y, después, la reconstrucción deliberada del estado derivado. Anonimizamos la PII aplicable una sola vez en Bronze y usamos una actualización completa controlada para propagar esos valores a Silver y Gold.

El flujo de trabajo exacto de producción en cuatro pasos

El orden es importante porque cada paso establece el estado que requiere el siguiente.

1. Detener el flujo de DLT
   El flujo se detiene antes de modificar los registros históricos de Bronze. Esto crea un límite controlado entre el procesamiento incremental normal y la operación de retención.
2. Anonimizar la PII de las tablas Bronze
   Identificamos los registros elegibles de Bronze y los filtramos en un DataFrame de Spark. Pasamos el DataFrame a nuestro servicio de Sanitización de Datos, que devuelve valores anonimizados irreversibles. Luego escribimos esos valores transformados de vuelta en Bronze.
3. Iniciar el flujo en modo de actualización completa y esperar a que los datos anonimizados se propaguen a Silver y Gold
   El flujo se reinicia en modo de actualización completa para que Silver se reconstruya a partir del estado transformado de Bronze y el resultado continúe hacia Gold. Bronze está configurado con pipeline.reset.allow = false, lo que lo protege de un recálculo completo mientras se actualizan las capas posteriores.
4. Esperar a que VACUUM se ejecute automáticamente como parte del mantenimiento de DLT
   El mantenimiento de DLT ejecuta VACUUM automáticamente. Los archivos obsoletos elegibles se eliminan después de que se cumplan las condiciones de retención configuradas. Actualizar el estado activo de una tabla Delta y eliminar archivos físicos reemplazados son partes distintas del ciclo de vida.

Flujo de trabajo de Oportun en cuatro pasos: detener DLT, anonimizar de forma irreversible la PII aplicable en Bronze, realizar una actualización completa de Silver y Gold, y esperar el mantenimiento automático de VACUUM.

Flujo de trabajo controlado de Oportun para la anonimización irreversible de PII y el recomputo posterior en Bronze, Silver y Gold.

Dentro de la Sanitización de Datos de Oportun

La Sanitización de Datos es el elemento central de nuestra adaptación. Su función en el Paso 2 puede entenderse como cuatro operaciones: filtrar los registros aplicables de Bronze, llamar a Sanitización de Datos, recibir resultados anonimizados irreversibles y actualizar Bronze.
Comenzamos filtrando los registros elegibles en un DataFrame de Spark. Pasamos ese DataFrame a Sanitización de Datos junto con el esquema y la configuración de etiquetas de PII. El servicio devuelve valores transformados a partir de los cuales no es posible recuperar la PII original. Luego escribimos esos valores en las tablas Bronze.
El servicio está basado en la configuración. Un esquema describe la estructura de los datos de entrada y los propietarios etiquetan las rutas de los campos sensibles. Las etiquetas estándar definen cómo se transforman las categorías de PII compatibles. Cuando se incorporan campos compatibles, los equipos pueden ampliar la configuración de etiquetas sin integrar una lógica de transformación específica para cada campo en el flujo de trabajo.

El objetivo es conservar solo lo que el procesamiento posterior legítimamente necesita. Eso puede incluir la estructura de datos aprobada, las características compatibles y las relaciones requeridas entre registros. No incluye una forma de volver a la PII original.

Cómo el estado transformado llega a Silver y Gold

Después de actualizar Bronze, la actualización completa posterior restablece la coherencia en todas las capas del modelo medallion. Silver se reconstruye para que su estado refinado refleje los valores anonimizados de Bronze en lugar de los valores procesados antes de la operación de retención.
Luego, Gold se vuelve a calcular a partir del estado posterior actualizado. Esto permite que los datos transformados estén disponibles para los análisis aprobados y los flujos de características, sin retener la PII original en el estado activo del lakehouse.
La configuración pipeline.reset.allow = false establece un límite importante. Bronze no se restablece como parte de la actualización completa. Permanece como la fuente transformada para el procesamiento posterior del lakehouse, mientras se reconstruyen las tablas Silver y las vistas Gold.
Esta división del trabajo facilita el razonamiento del diseño. La Sanitización de Datos realiza la transformación irreversible. La actualización completa propaga el estado lógico transformado. El mantenimiento de DLT se encarga de los archivos obsoletos elegibles posteriormente.

Qué aprendimos al llevar el diseño a producción

Aplicar la anonimización irreversible en la fuente posterior al lakehouse
Transformar Bronze una sola vez proporciona un estado autorizado para Silver y Gold. Modificar cada capa por separado duplicaría la lógica y aumentaría la posibilidad de un tratamiento inconsistente.

Recomponer el estado derivado cuando los cambios históricos entran en conflicto con el comportamiento de la transmisión
El procesamiento incremental es eficiente para los eventos nuevos. Una modificación histórica cambia un registro que las tablas posteriores pueden haber consumido previamente. Una actualización completa y controlada permite reconstruir esas capas a partir del estado de origen corregido.

Conservar la utilidad analítica aprobada, no la identidad
Una transformación de retención debe conservar únicamente la estructura de datos, las características y las relaciones aprobadas para el análisis. No debe conservar la PII original ni una representación reversible de ella.

Tratar las actualizaciones lógicas y la limpieza física como etapas separadas
Escribir valores anonimizados cambia el estado activo de la tabla. Más tarde, VACUUM elimina los archivos obsoletos elegibles después de que se cumplan las condiciones de retención configuradas. Ambas etapas son importantes al explicar el ciclo de vida completo de los datos.

Conclusión: un patrón repetible de retención de datos en Databricks

El resultado más importante no fue una función de anonimización ni una configuración de flujo. Fue un patrón operativo repetible para la retención de datos en el lakehouse.
Identificamos los registros cubiertos por nuestros criterios de retención relacionados con la FTC, eliminamos la PII calificadora de las bases de datos operativas y transformamos de forma irreversible la PII correspondiente en la fuente Bronze para el procesamiento posterior del lakehouse. Una actualización completa y controlada reconstruye Silver y Gold a partir de ese estado transformado. Después, el mantenimiento de DLT elimina los archivos obsoletos elegibles una vez que se cumplen las condiciones de retención configuradas.
Este diseño respalda nuestros requisitos de retención y conserva únicamente las características analíticas aprobadas que el lakehouse aún necesita proporcionar. También establece una clara separación de responsabilidades entre la selección basada en políticas, la anonimización irreversible, el recomputo posterior y el mantenimiento de archivos físicos.

Preguntas frecuentes