Analítica para el Service National Universel: Creación de un Pipeline para Generar Bases de Datos de Eventos desde Datos de Producción

Contexto

Teníamos una base de datos compuesta por colecciones MongoDB que representaban a jóvenes inscribiéndose en un programa gubernamental (el Service National Universel, una especie de campamento de verano operado por el estado), y posteriormente realizando misiones de interés público en organizaciones por todo el país. Para ambas fases, las solicitudes debían pasar por un proceso de múltiples etapas—incluyendo creación de usuario, finalización, validación administrativa y posibles solicitudes de rechazo o corrección. Todo se registraba en campos de "estado". Aunque registrábamos la fecha de la última actualización, no manteníamos un registro de cada cambio de estado directamente en los datos del usuario.

Durante el tercer año del proyecto, el cliente (el Ministerio de Educación) recibió una solicitud de un organismo regulador para obtener estadísticas detalladas sobre la evolución del grupo de solicitantes. Esto requería presentar claramente cifras diarias de solicitudes creadas, completadas, procesadas, validadas y rechazadas, junto con proyecciones y comparaciones contra objetivos anuales.

Para satisfacer esta necesidad de la manera más rápida y simple posible, elegimos crear nuestro propio pipeline desde cero, utilizando las herramientas que ya estaban desplegadas en el proyecto (una instancia de Nodejs y bases de datos, todo gestionado por el servicio CleverCloud).

Ingesta

Afortunadamente, ya existía un sistema para la generación automática de datos de eventos: cada actualización en la colección de usuarios generaba un documento en la colección de "parches", registrando el ID del documento actualizado y los valores de los campos modificados. Esta colección servía para propósitos de seguridad (seguimiento de cambios y su origen) y permitía la reversión de datos en caso de errores o fallos humanos. Ahora también se aprovecharía para nuestro incipiente servicio de análisis.

Sin embargo, estos parches no cumplían completamente con los requisitos del cliente. Para proporcionar una base de datos adecuada para referencias cruzadas y generar informes detallados anonimizados—como el número de solicitudes creadas y validadas por género, edad o región del solicitante—era necesaria la transformación de datos. En consecuencia, se configuró un trabajo automatizado para ejecutarse cada noche para el procesamiento.

Transformación

La necesidad:

• Datos completos: necesitábamos reconstruir el estado del usuario antes y después de cada evento registrado.

• Datos estructurados: los registros tenían que ser convertidos de nuestro almacén de documentos a una base de datos relacional para facilitar el uso en la herramienta de visualización de datos elegida (Metabase).

• Datos anonimizados: no se podía registrar información identificativa en esta base de datos, que iba a ser accedida por personas fuera del equipo del cliente y en estricta observancia de las reglas GDPR.

Desarrollamos scripts JavaScript para poblar una base de datos PostgreSQL externa. Para cada evento (por ejemplo, creación de solicitud, validación, finalización del proceso), se generaba una nueva entrada en la tabla de análisis. Cada entrada incluía el nombre del evento y los datos del usuario reconstruidos, tanto pre como post cambio. Esta reconstrucción utilizaba información de eventos de la colección de parches y el documento de usuario más reciente, con todos los detalles identificativos eliminados. Estos perfiles de usuario reconstruidos se almacenaban en columnas JSONB, y los campos clave se duplicaban en columnas separadas para agilizar las consultas posteriores.

Además, estos scripts necesitaban soportar la ejecución manual, en caso de fallo del servidor o mala configuración, sin generar entradas duplicadas en la tabla de eventos.

Compartición de Datos

Con estos eventos ordenadamente registrados en una base de datos relacional, el departamento de datos pudo crear hermosos dashboards y PDFs, respondiendo a la mayoría de las preguntas que tenía la administración y así mostrando el papel de todo el programa.