Origen mutable
La API solo conserva el estado vigente de cada solicitud y no ofrece una línea temporal completa.
Caso 03 · Ingeniería de datos · Educación
De una API sin histórico a un Lakehouse gobernado.
Una plataforma de datos en Microsoft Fabric que captura cambios operativos, construye trazabilidad desde su puesta en producción y entrega un modelo estrella preparado para analizar el recorrido completo de admisión.
Caso profesional desarrollado end-to-end por Mario Yepes · Nombres, entidades y ejemplos anonimizados · Sin datos personales ni código interno
El reto
El negocio necesitaba una historia que el sistema origen no conservaba.
La fuente mostraba la fotografía actual. La plataforma debía empezar a registrar la película completa sin convertir cada ejecución en una carga total.
Proceso cambiante
Los registros pueden avanzar, retroceder o modificarse durante distintos periodos académicos.
Consumo dependiente
Otros procesos necesitan saber si la actualización diaria terminó correctamente antes de comenzar.
Objetivo de diseñoCapturar cada cambio una vez, conservar su trazabilidad y entregar una versión fiable para analizar.
Arquitectura medallón
Cinco etapas con responsabilidades y contratos claros.
La separación por capas permite evolucionar la lógica de negocio sin comprometer la evidencia recibida desde el origen.
- 01
Admissions CRM API
Siete recursos configurados en origen con una ventana móvil de siete días.
- 02
Bronze
Estado actual, versiones observadas y control operativo en dbo, hst y control.
- 03
Silver
Estandarización, deduplicación, claves deterministas y reglas del proceso de admisión.
- 04
Gold
Cinco hechos, trece dimensiones y un contrato analítico preparado para BI.
- 05
Consumo
El equipo de BI conecta el endpoint Gold y publica el modelo semántico en su workspace.
Dos conceptos de historia
Trazabilidad técnica y recorrido de negocio no son lo mismo.
Separarlos permite responder tanto qué valor recibió la plataforma como qué etapa atravesó una solicitud.
Histórico técnico
Conserva las versiones observadas de cada registro desde la puesta en producción.
- Se recibe un registro modificado
- dbo conserva el estado vigente
- hst incorpora la versión observada
- control registra el resultado
Histórico funcional
Representa el viaje de la solicitud por el proceso de admisión y sus hitos.
InicioSolicitudAdmisiónMatrícula
Las etapas obligatorias solo se reconstruyen cuando existe evidencia funcional posterior. La matrícula nunca se infiere.Incrementalidad por diseño
Cinco mecanismos para procesar cambios con seguridad.
Solapamiento
La API entrega nuevamente los últimos siete días para capturar modificaciones tardías.
Watermark
Cada capa conserva hasta qué instante procesó correctamente cada entidad.
ChangeHash
Un hash de contenido evita actualizar filas cuyo valor de negocio no ha cambiado.
Delta MERGE
Las claves de negocio permiten insertar o actualizar de forma repetible e idempotente.
Rollback
Si una entidad falla, las tablas procesadas vuelven a su última versión estable.
Silver · De dato a significado
La complejidad funcional se resuelve antes de llegar al informe.
Silver crea entidades conformadas, aplica reglas de admisión y deja una capa reutilizable que no depende de una visualización concreta.
Estandarización
Nombres UpperCamelCase, tipos consistentes, auditoría UTC y contratos homogéneos.
Identidad estable
UUID5 genera las mismas claves para el mismo valor en cualquier ejecución y entorno.
Estado de admisión
Se normalizan estados operativos y se excluyen flujos que pertenecen a otros procesos.
Funnel reconstruido
Etapas obligatorias ausentes se infieren solo cuando una etapa posterior demuestra que debieron ocurrir.
Becas concedidas
El recorrido de concesión se modela de forma separada al funnel principal de admisiones.
Geografía comercial
Una correspondencia auxiliar de países completa región comercial y unidad de negocio.
Gold · Contrato analítico
Un modelo estrella preparado para consumo, no una copia del origen.
Cinco procesos medibles comparten dimensiones conformadas y claves deterministas.
13 dimensionesDimCandidateDimLocationDimAdmissionCycleDimAcademicProgramDimApplicationStatusDimApplicationTypeDimEducationHistoryDimPriorityDimStudyRateDimAcquisitionChannelDimAdmissionDecisionDimTuitionPlanDimScholarship
5 tablas de hechosFactApplicationsFactApplicationJourneyFactApplicationStatusHistoryFactScholarshipAwardsFactScholarshipAwardJourney
Contrato Gold
UUID5Claves reproducibles
SCD1Estado conformado
UTCAuditoría consistente
SQLEndpoint de consumo
Operación y entrega
Una solución preparada para ejecutarse, desplegarse y ser consumida por otros equipos.
La ingeniería termina cuando el dato fiable queda disponible para el siguiente consumidor, no cuando acaba un notebook.
06:00
Ingesta BronzeAPI · historia · control
→Transformación Silvercalidad · reglas · funnel
→Modelo Goldhechos · dimensiones
→Notificaciónresultado de la ejecución
Desarrollo
Los cambios se construyen y validan en un workspace aislado.
Git
Fabric sincroniza notebooks, Lakehouses, pipeline y configuración con la rama de desarrollo.
Despliegue
Una canalización promueve los elementos validados de DEV a PRO.
Producción
PRO se sincroniza con su rama y ejecuta la pipeline diariamente a las 06:00.
Límite de responsabilidadGold Lakehouse
El equipo de BI recibe acceso al workspace productivo, conecta el endpoint Gold y publica el modelo semántico y los informes en un área de consumo independiente.
Qué demuestra este caso
Arquitectura, desarrollo y operación trabajando como una sola solución.
El diseño y el desarrollo end-to-end —ingesta, transformación, modelado, orquestación, control y ciclo DEV/PRO— fueron realizados por Mario Yepes. La solución integra un componente reutilizable del equipo para el seguimiento de ejecuciones.