- \n
- Por qu\u00e9 la retenci\u00f3n de datos pasa a ser en un reto de ingenier\u00eda para un lakehouse<\/li>\n
- Por qu\u00e9 los cambios hist\u00f3ricos en Bronze requieren un rec\u00e1lculo controlado<\/li>\n
- El flujo de trabajo exacto de producci\u00f3n en cuatro pasos<\/li>\n
- C\u00f3mo la Sanitizaci\u00f3n de Datos de Oportun realiza una anonimizaci\u00f3n irreversible<\/li>\n
- C\u00f3mo el estado transformado llega a Silver y Gold<\/li>\n
- Qu\u00e9 aprendimos al llevar el dise\u00f1o a producci\u00f3n<\/li>\n
- Preguntas frecuentes<\/li>\n<\/ul>\n
Puntos clave<\/strong><\/p>\n
- \n
- Eliminamos la PII calificadora de las bases de datos operativas y anonimizamos de manera irreversible la PII correspondiente en Bronze, conservando \u00fanicamente las caracter\u00edsticas anal\u00edticas aprobadas.<\/li>\n
- El flujo de trabajo de producci\u00f3n detiene DLT, anonimiza Bronze, realiza una actualizaci\u00f3n completa de Silver y Gold, y espera el mantenimiento autom\u00e1tico de VACUUM (limpieza de datos).<\/li>\n
- El etiquetado basado en configuraci\u00f3n aplica una transformaci\u00f3n consistente en Bronze, y el recomputo posterior lleva consigo ese estado a Silver y Gold.<\/li>\n<\/ul>\n
Por qu\u00e9 la retenci\u00f3n de datos pasa a ser un reto de ingenier\u00eda para un lakehouse<\/h2>\n
Los sistemas operativos y los sistemas anal\u00edticos no usan los registros de la misma manera. Las bases de datos operativas respaldan clientes activos y procesos comerciales. El lakehouse respalda an\u00e1lisis estad\u00edsticos aprobados y caracter\u00edsticas posteriores del flujo.
\nNuestro proceso de retenci\u00f3n identifica la PII calificadora asociada a clientes potenciales, solicitantes y miembros. Las reglas de elegibilidad espec\u00edficas se rigen por pol\u00edticas y procedimientos operativos, por lo que la arquitectura p\u00fablica no codifica el umbral ni la frecuencia de ejecuci\u00f3n.
\nPara los registros calificadores, el resultado operativo es eliminar la PII de las bases de datos de origen. El resultado anal\u00edtico es distinto. Remover el registro completo del lakehouse tambi\u00e9n eliminar\u00eda atributos, caracter\u00edsticas y relaciones no identificables que siguen aprobados para el an\u00e1lisis.
\nPor lo tanto, el objetivo de ingenier\u00eda fue preciso: reemplazar los valores originales que identifican a una persona en las tablas de Databricks en estado activo, conservar solo la estructura anal\u00edtica aprobada, propagar ese estado a cada capa posterior del lakehouse y, m\u00e1s adelante, eliminar los archivos obsoletos elegibles mediante mantenimiento.
\nEste es un problema de anonimizaci\u00f3n, no un problema de control de acceso. Para este flujo, nuestro servicio de Sanitizaci\u00f3n de Datos devuelve resultados transformados irreversibles. La PII original no puede reconstruirse a partir de esos resultados.<\/p>\nPor qu\u00e9 los cambios hist\u00f3ricos en Bronze requieren una recalculo controlado<\/h2>\n
Organizamos los datos del lakehouse en las capas Bronze, Silver y Gold. Bronze contiene la representaci\u00f3n Delta que utiliza el procesamiento posterior. Silver transforma los eventos de Bronze en conjuntos de datos refinados y combinados. Gold proporciona datos y caracter\u00edsticas curados y aprobados para el consumo.
\nEl procesamiento incremental normal maneja la informaci\u00f3n nueva de forma eficiente. El flujo de trabajo de retenci\u00f3n es diferente, porque cambia registros que las tablas posteriores ya procesaron.
\nEn esta implementaci\u00f3n, las actualizaciones de los registros de Bronze procesados previamente entraban en conflicto con el comportamiento de las tablas de transmisi\u00f3n posteriores de Silver. Cambiar un valor hist\u00f3rico en Bronze no reconstru\u00eda por s\u00ed solo todos los resultados de Silver o Gold que se hab\u00edan derivado del valor anterior.
\nLa soluci\u00f3n fue hacer que el estado transformado de Bronze fuera la fuente autorizada para las capas posteriores del lakehouse y, despu\u00e9s, la reconstrucci\u00f3n deliberada del estado derivado. Anonimizamos la PII aplicable una sola vez en Bronze y usamos una actualizaci\u00f3n completa controlada para propagar esos valores a Silver y Gold.<\/p>\nEl flujo de trabajo exacto de producci\u00f3n en cuatro pasos<\/h2>\n
El orden es importante porque cada paso establece el estado que requiere el siguiente.<\/p>\n
- \n
- Detener el flujo de DLT<\/strong>
\nEl flujo se detiene antes de modificar los registros hist\u00f3ricos de Bronze. Esto crea un l\u00edmite controlado entre el procesamiento incremental normal y la operaci\u00f3n de retenci\u00f3n.<\/li>\n- Anonimizar la PII de las tablas Bronze<\/strong>
\nIdentificamos los registros elegibles de Bronze y los filtramos en un DataFrame de Spark. Pasamos el DataFrame a nuestro servicio de Sanitizaci\u00f3n de Datos, que devuelve valores anonimizados irreversibles. Luego escribimos esos valores transformados de vuelta en Bronze.<\/li>\n- Iniciar el flujo en modo de actualizaci\u00f3n completa y esperar a que los datos anonimizados se propaguen a Silver y Gold<\/strong>
\nEl flujo se reinicia en modo de actualizaci\u00f3n completa para que Silver se reconstruya a partir del estado transformado de Bronze y el resultado contin\u00fae hacia Gold. Bronze est\u00e1 configurado conpipeline.reset.allow = false<\/code>, lo que lo protege de un rec\u00e1lculo completo mientras se actualizan las capas posteriores.<\/li>\n- Esperar a que VACUUM se ejecute autom\u00e1ticamente como parte del mantenimiento de DLT<\/strong>
\nEl mantenimiento de DLT ejecuta VACUUM autom\u00e1ticamente. Los archivos obsoletos elegibles se eliminan despu\u00e9s de que se cumplan las condiciones de retenci\u00f3n configuradas. Actualizar el estado activo de una tabla Delta y eliminar archivos f\u00edsicos reemplazados son partes distintas del ciclo de vida.<\/li>\n<\/ol>\nFlujo de trabajo de Oportun en cuatro pasos: detener DLT, anonimizar de forma irreversible la PII aplicable en Bronze, realizar una actualizaci\u00f3n completa de Silver y Gold, y esperar el mantenimiento autom\u00e1tico de VACUUM.<\/p>\n
![\"\"](\"https:\/\/oportun.com\/wp-content\/uploads\/2026\/09\/Oportun_DLT_Engineering_blog_graphic_ES.png\")
<\/p>\nFlujo de trabajo controlado de Oportun para la anonimizaci\u00f3n irreversible de PII y el recomputo posterior en Bronze, Silver y Gold.<\/p>\n
Dentro de la Sanitizaci\u00f3n de Datos de Oportun<\/h2>\n
La Sanitizaci\u00f3n de Datos es el elemento central de nuestra adaptaci\u00f3n. Su funci\u00f3n en el Paso 2 puede entenderse como cuatro operaciones: filtrar los registros aplicables de Bronze, llamar a Sanitizaci\u00f3n de Datos, recibir resultados anonimizados irreversibles y actualizar Bronze.
\nComenzamos filtrando los registros elegibles en un DataFrame de Spark. Pasamos ese DataFrame a Sanitizaci\u00f3n de Datos junto con el esquema y la configuraci\u00f3n 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.
\nEl servicio est\u00e1 basado en la configuraci\u00f3n. Un esquema describe la estructura de los datos de entrada y los propietarios etiquetan las rutas de los campos sensibles. Las etiquetas est\u00e1ndar definen c\u00f3mo se transforman las categor\u00edas de PII compatibles. Cuando se incorporan campos compatibles, los equipos pueden ampliar la configuraci\u00f3n de etiquetas sin integrar una l\u00f3gica de transformaci\u00f3n espec\u00edfica para cada campo en el flujo de trabajo.<\/p>\nEl objetivo es conservar solo lo que el procesamiento posterior leg\u00edtimamente necesita. Eso puede incluir la estructura de datos aprobada, las caracter\u00edsticas compatibles y las relaciones requeridas entre registros. No incluye una forma de volver a la PII original.<\/p>\n
C\u00f3mo el estado transformado llega a Silver y Gold<\/h2>\n
Despu\u00e9s de actualizar Bronze, la actualizaci\u00f3n 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\u00f3n de retenci\u00f3n.
\nLuego, Gold se vuelve a calcular a partir del estado posterior actualizado. Esto permite que los datos transformados est\u00e9n disponibles para los an\u00e1lisis aprobados y los flujos de caracter\u00edsticas, sin retener la PII original en el estado activo del lakehouse.
\nLa configuraci\u00f3n pipeline.reset.allow = false establece un l\u00edmite importante. Bronze no se restablece como parte de la actualizaci\u00f3n completa. Permanece como la fuente transformada para el procesamiento posterior del lakehouse, mientras se reconstruyen las tablas Silver y las vistas Gold.
\nEsta divisi\u00f3n del trabajo facilita el razonamiento del dise\u00f1o. La Sanitizaci\u00f3n de Datos realiza la transformaci\u00f3n irreversible. La actualizaci\u00f3n completa propaga el estado l\u00f3gico transformado. El mantenimiento de DLT se encarga de los archivos obsoletos elegibles posteriormente.<\/p>\nQu\u00e9 aprendimos al llevar el dise\u00f1o a producci\u00f3n<\/h2>\n
Aplicar la anonimizaci\u00f3n irreversible en la fuente posterior al lakehouse<\/strong>
\nTransformar Bronze una sola vez proporciona un estado autorizado para Silver y Gold. Modificar cada capa por separado duplicar\u00eda la l\u00f3gica y aumentar\u00eda la posibilidad de un tratamiento inconsistente.<\/p>\nRecomponer el estado derivado cuando los cambios hist\u00f3ricos entran en conflicto con el comportamiento de la transmisi\u00f3n<\/strong>
\nEl procesamiento incremental es eficiente para los eventos nuevos. Una modificaci\u00f3n hist\u00f3rica cambia un registro que las tablas posteriores pueden haber consumido previamente. Una actualizaci\u00f3n completa y controlada permite reconstruir esas capas a partir del estado de origen corregido.<\/p>\nConservar la utilidad anal\u00edtica aprobada, no la identidad<\/strong>
\nUna transformaci\u00f3n de retenci\u00f3n debe conservar \u00fanicamente la estructura de datos, las caracter\u00edsticas y las relaciones aprobadas para el an\u00e1lisis. No debe conservar la PII original ni una representaci\u00f3n reversible de ella.<\/p>\nTratar las actualizaciones l\u00f3gicas y la limpieza f\u00edsica como etapas separadas<\/strong>
\nEscribir valores anonimizados cambia el estado activo de la tabla. M\u00e1s tarde, VACUUM elimina los archivos obsoletos elegibles despu\u00e9s de que se cumplan las condiciones de retenci\u00f3n configuradas. Ambas etapas son importantes al explicar el ciclo de vida completo de los datos.<\/p>\nConclusi\u00f3n: un patr\u00f3n repetible de retenci\u00f3n de datos en Databricks<\/h2>\n
El resultado m\u00e1s importante no fue una funci\u00f3n de anonimizaci\u00f3n ni una configuraci\u00f3n de flujo. Fue un patr\u00f3n operativo repetible para la retenci\u00f3n de datos en el lakehouse.
\nIdentificamos los registros cubiertos por nuestros criterios de retenci\u00f3n 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\u00f3n completa y controlada reconstruye Silver y Gold a partir de ese estado transformado. Despu\u00e9s, el mantenimiento de DLT elimina los archivos obsoletos elegibles una vez que se cumplen las condiciones de retenci\u00f3n configuradas.
\nEste dise\u00f1o respalda nuestros requisitos de retenci\u00f3n y conserva \u00fanicamente las caracter\u00edsticas anal\u00edticas aprobadas que el lakehouse a\u00fan necesita proporcionar. Tambi\u00e9n establece una clara separaci\u00f3n de responsabilidades entre la selecci\u00f3n basada en pol\u00edticas, la anonimizaci\u00f3n irreversible, el recomputo posterior y el mantenimiento de archivos f\u00edsicos.<\/p>\nPreguntas frecuentes<\/h2>\n
\n\n
\n\n\n\n \u00bfQu\u00e9 problema resuelve este flujo de trabajo de Databricks? <\/div>\n\n<\/oportun-icon>\n <\/span>\n\n \nNos ayuda a aplicar de manera consistente un requisito de retenci\u00f3n relacionado con la FTC en los datos operativos y anal\u00edticos. La PII calificadora se elimina de las bases de datos de origen y se transforma de manera irreversible en Databricks, mientras se conservan solo las caracter\u00edsticas anal\u00edticas aprobadas.<\/p>\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n <\/p>\n
\n\n\n \u00bfPor qu\u00e9 no eliminar el registro completo de Databricks? <\/div>\n\n<\/oportun-icon>\n <\/span>\n\n \nEliminar el registro completo tambi\u00e9n remover\u00eda las caracter\u00edsticas y relaciones no identificables requeridas para el an\u00e1lisis estad\u00edstico aprobado. El flujo de trabajo elimina los valores originales que identifican a un individuo y conserva solo las caracter\u00edsticas de datos que siguen aprobadas. <\/p>\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n
\n\n\n\n \u00bfPor qu\u00e9 se necesita una actualizaci\u00f3n completa despu\u00e9s de anonimizar Bronze? <\/div>\n\n<\/oportun-icon>\n <\/span>\n\n \nSilver y Gold pueden contener un estado derivado de los valores anteriores de Bronze. La actualizaci\u00f3n completa reconstruye esas capas posteriores a partir del estado transformado de Bronze para que la arquitectura medallion vuelva a ser coherente. <\/p>\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n
\n\n\n\n \u00bfSe puede recuperar la PII original a partir de los resultados de Sanitizaci\u00f3n de Datos? <\/div>\n\n<\/oportun-icon>\n <\/span>\n\n \nNo. Para este flujo de trabajo, la Sanitizaci\u00f3n de Datos de Oportun devuelve resultados transformados irreversibles. La PII original no puede reconstruirse a partir de esos resultados. <\/p>\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n
\n\n\n\n \u00bfQu\u00e9 hace pipeline.reset.allow = false? <\/div>\n\n<\/oportun-icon>\n <\/span>\n\n \nEvita que Bronze se restablezca durante la actualizaci\u00f3n completa posterior. Bronze permanece como la fuente transformada para el procesamiento posterior del lakehouse mientras Silver y Gold se reconstruyen. <\/p>\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n
\n <\/div>\n <\/div>\n \n","protected":false},"excerpt":{"rendered":"C\u00f3mo la anonimizaci\u00f3n irreversible de datos y la actualizaci\u00f3n controlada de Bronze a Gold cumplen los requisitos de retenci\u00f3n de Oportun relacionados con la FTC. Este es un caso de estudio de Databricks que explica c\u00f3mo anonimizamos de forma irreversible informaci\u00f3n de identificaci\u00f3n personal (o PII por sus siglas en ingl\u00e9s) relacionada con requisitos, asociada […]<\/p>\n","protected":false},"author":25,"featured_media":0,"template":"","meta":{"_acf_changed":false,"footnotes":""},"engineering_category":[],"engineering_post_tag":[],"class_list":["post-2789683","engineering_blog","type-engineering_blog","status-publish","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_blog\/2789683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_blog"}],"about":[{"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/types\/engineering_blog"}],"author":[{"embeddable":true,"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/users\/25"}],"version-history":[{"count":3,"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_blog\/2789683\/revisions"}],"predecessor-version":[{"id":2789689,"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_blog\/2789683\/revisions\/2789689"}],"wp:attachment":[{"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/media?parent=2789683"}],"wp:term":[{"taxonomy":"engineering_category","embeddable":true,"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_category?post=2789683"},{"taxonomy":"engineering_post_tag","embeddable":true,"href":"https:\/\/oportun.com\/es\/wp-json\/wp\/v2\/engineering_post_tag?post=2789683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Anonimizar la PII de las tablas Bronze<\/strong>
- Detener el flujo de DLT<\/strong>