Un equipo arranca un proyecto de datos. Hay presión por mostrar resultados. Se conectan las fuentes, se arman los primeros pipelines, se cargan tablas en un data lake. En pocas semanas hay datos fluyendo. El problema es que nadie definió qué preguntas de negocio hay que responder.
Seis meses después, el equipo tiene un playground con decenas de tablas que nadie entiende. Cada analista hace sus propios joins. Las métricas no coinciden entre reportes. Y cuando alguien pregunta "¿cuál es la fuente de verdad?", la respuesta es un silencio incómodo.
Este escenario es más común de lo que parece. Y la causa suele ser la misma: se resolvieron los pipelines antes de pensar el modelo.
El orden importa
Hay una secuencia que parece lógica: primero traer los datos, después transformarlos, después modelarlos. El problema es que esa secuencia invierte las prioridades.
Cuando arrancás por los pipelines, las decisiones de ingesta condicionan lo que podés hacer después. Si trajiste los datos en un formato particular, si los particionaste de cierta manera, si descartaste columnas que parecían irrelevantes, esas decisiones ya están tomadas. Y cuando llegás a la etapa de modelado, descubrís que el modelo que necesitás no encaja con lo que tenés.
La alternativa es empezar por el modelo. Definir primero qué preguntas de negocio hay que responder. Identificar qué dimensiones describen esas preguntas (quién, qué, cuándo, dónde). Identificar qué hechos las miden (cuánto, cuántos). Recién después, diseñar los pipelines que materializan ese modelo.
La transformación existe para darle vida a un modelo ya pensado. Si hacés las cosas al revés, terminás modelando las transformaciones en lugar del negocio.
Qué significa "modelo primero"
Pensar el modelo primero no significa diseñar todo en papel antes de escribir una línea de código. Significa tener claridad sobre tres cosas antes de construir pipelines:
Qué preguntas de negocio hay que responder. No "qué datos tenemos disponibles", sino "qué necesita saber el negocio". La diferencia es sutil pero importante. Los datos disponibles son un insumo; las preguntas de negocio son el objetivo.
Qué entidades participan en esas preguntas. Si el negocio necesita saber "cuántos contenidos creó cada tipo de suscripción el mes pasado", las entidades son claras: contenidos, suscripciones, tiempo. Esas son las dimensiones candidatas.
Qué se mide en cada evento. Si el evento es "creación de contenido", las métricas pueden ser cantidad, duración, tipo. Eso define el grano del hecho.
Con esas tres cosas claras, el modelo empieza a tomar forma antes de que exista un solo pipeline. Y los pipelines se diseñan para alimentar ese modelo, no al revés.
El costo de invertir el orden
Cuando el modelo se define después de los pipelines, pasan varias cosas.
Primero, las transformaciones acumulan lógica de negocio que debería estar en el modelo. Un pipeline que calcula una métrica compleja termina siendo la única fuente de esa métrica. Si alguien necesita la misma métrica con un corte distinto, tiene que duplicar la lógica o modificar el pipeline existente.
Segundo, las definiciones se dispersan. "Cliente activo" se calcula de una forma en un pipeline, de otra forma en un reporte, de otra forma en un dashboard. Cuando los números no coinciden, nadie sabe cuál es el correcto porque no hay una definición canónica.
Tercero, el modelo termina reflejando la estructura de los pipelines en lugar de la estructura del negocio. Las tablas se llaman como las fuentes de origen, no como los conceptos que representan. Los joins son complicados porque las relaciones no están explícitas.
El resultado es un sistema que técnicamente funciona pero que nadie puede mantener ni extender. Cada cambio requiere entender la historia de cómo se llegó a ese estado. Y esa historia suele estar en la cabeza de una sola persona.
El modelo como contrato
Un modelo dimensional bien diseñado funciona como un contrato entre el equipo de datos y el resto de la organización.
El contrato dice: "cliente activo significa esto, y se calcula así". El contrato dice: "el grano de la tabla de ventas es una línea por transacción". El contrato dice: "la dimensión de producto tiene estos atributos y se actualiza con esta frecuencia".
Cuando el modelo es el norte, las transformaciones son implementaciones de ese contrato. Si el contrato cambia, las transformaciones se ajustan. Pero el contrato es explícito, está documentado, y cualquiera puede consultarlo.
Cuando los pipelines son el norte, no hay contrato. Hay código que hace cosas. Y entender qué hace ese código requiere leerlo, ejecutarlo, y confiar en que quien lo escribió sabía lo que estaba haciendo.
Cómo se ve esto en la práctica
Un equipo que pone el modelo primero hace cosas distintas.
Antes de conectar una fuente, pregunta: "¿qué preguntas de negocio vamos a poder responder con estos datos?". Si la respuesta no es clara, la conexión puede esperar.
Antes de escribir una transformación, pregunta: "¿a qué tabla del modelo alimenta esto?". Si la transformación no tiene un destino claro en el modelo, probablemente no debería existir.
Antes de agregar una métrica, pregunta: "¿es coherente con el grano de la tabla donde va a vivir?". Si la métrica mezcla granularidades, hay un problema de diseño.
Estas preguntas parecen obvias, pero en la práctica se saltan constantemente. La presión por entregar resultados empuja a construir primero y pensar después. Y el costo de esa decisión se paga meses más tarde, cuando el sistema es un laberinto que nadie quiere tocar.
El modelo no es estático
Pensar el modelo primero no significa que el modelo no pueda cambiar. Los requerimientos evolucionan, las preguntas de negocio cambian, aparecen nuevas fuentes de datos.
La diferencia es cómo se gestionan esos cambios. Si el modelo es el norte, un cambio en los requerimientos se traduce primero en un cambio en el modelo, y después en cambios en las transformaciones que lo alimentan. El flujo es claro: el modelo cambia, los pipelines se adaptan.
Si los pipelines son el norte, un cambio en los requerimientos se traduce en parches sobre parches. Se agrega una columna acá, se modifica un cálculo allá, se crea una tabla nueva que duplica parte de otra. El modelo, si es que existe, queda desactualizado.
En resumen
El modelo de datos es el norte. La transformación le da vida.
Esto no es una frase motivacional: tiene consecuencias concretas en cómo se construye y mantiene un sistema de datos.
Si primero pensás el modelo, los pipelines tienen un propósito claro. Las definiciones están en un solo lugar. Los cambios se gestionan de forma ordenada.
Si primero construís los pipelines, terminás modelando las transformaciones en lugar del negocio. Y al año, cuando agarrás las cosas, no sabés dónde está nada. No hay argumentos. No hay modelo. No hay nada.