Reto de punta a punta
Modelar datos para analítica
Elegí una fuente que tenga al menos un atributo que cambie con el tiempo (puede ser catalog/tools.yaml del repo de DE Radar, en github.com/JeanArdila711/data-engineering, que es público) y modelala como SCD Tipo 2: una tabla de hechos con grano explícito y una dimensión que guarde el historial de esos cambios, no solo el valor actual. Corré una transformación por capas y verificá con una consulta que el histórico sigue disponible después de que la fuente cambió.
Sabés que lo lograste si…
Podés declarar en una frase el grano de tu tabla de hechos, y detectar que un reporte duplica importes porque cruzó dos hechos de granos distintos.
Podés responder con una consulta qué valor tenía un atributo en una fecha pasada, sin depender de un backup.
Podés borrar entera una capa derivada y regenerarla desde la anterior sin volver a la fuente y sin perder un solo hecho verificado.
Tenés un test que falla a propósito cuando le metés un dato malo, y sabés dónde queda ese dato después de fallar.
Esto es lo que se rompe
dim_tool usa una surrogate key autoincremental. Con un solo escritor secuencial funciona, pero deja de ser determinista en cuanto haya dos procesos cargando, y reconstruir la dimensión desde cero daría claves distintas a las de hoy. Quedó anotado como deuda y no se cambió: ahora mismo no es un bug y tocarlo sería riesgo en producción sin beneficio. Con un hash determinista sobre la clave natural no habría existido la discusión.
dim_tool estaba implementada como SCD Tipo 2 —vigencias, is_current, todo— y el mart la joineaba por is_current. O sea: se pagó el costo del historial y después se consultaba siempre la foto de hoy, que es justo lo que el Tipo 2 existe para no hacer. Se corrigió con un join por rango sobre published_at. En el mismo arreglo apareció el otro lado: sync_catalog nunca cerraba la fila de una herramienta retirada del catálogo, así que quedaba vigente para siempre.
Ver el commitEl texto generado por el LLM vive en su propia capa, aislado de los hechos. Cuando la traducción al español empezó a meter comentarios del modelo dentro del resumen, se arregló la generación y se decidió no reprocesar lo ya guardado: el sitio se corrige solo a medida que entran artículos nuevos. La deuda todavía se ve en artículos viejos. Poder aceptarla salió gratis porque el resumen no comparte tabla con el hecho; si la compartiera, la misma decisión habría sido una migración con riesgo sobre datos verificados.
Ver el commitEl validador de anclaje se probó con citas inventadas a propósito, porque un validador que nunca rechaza nada no está validando. La otra mitad la encontró una auditoría posterior: stg_article_mentions y stg_summaries no tenían un solo test y el grano compuesto no estaba cubierto en ningún lado, así que la suite estaba en verde sobre modelos que nadie chequeaba. El complemento es la cuarentena: lo que no valida se guarda con su error, porque descartarlo en silencio pierde el dato y también la señal de que la fuente cambió.
Ver el commit
No hay una solución que comparar. Tu fuente, tu storage y tu forma de resolverlo van a ser distintos a los de cualquier otra persona — eso es real, no un hueco del sitio. Un pipeline se valida corriendo, no contra una plantilla. Usá el checklist como tu propio code review: si podés marcar cada punto de verdad, lo lograste.
Acá no hay nadie revisando tu resultado. Si querés que otra persona lo mire, este no es el lugar.