El problema
Abrís cualquier presentación de arquitectura de datos y aparece el mismo diagrama: tres capas con nombres elegantes. Bronce, plata, oro. Raw, staging, consumo. Landing, curated, analytics. El patrón se llama "medallion" y está en todos lados.
El problema es que muchos equipos copian el diagrama sin definir qué significa cada capa en su contexto. Tienen tres carpetas, tres schemas, tres colores en el PowerPoint. Pero si les preguntás por qué un dato está en raw y no en staging, la respuesta es vaga o circular: "porque todavía no lo procesamos".
La idea central
Los nombres de las capas importan menos que los criterios que definen qué vive en cada una. Podés llamarlas como quieras: bronce/plata/oro, raw/staging/consumo, landing/curated/analytics. Lo que importa es que si vas a plantear capas, cada capa tenga definido exactamente qué hay ahí y cuál es el criterio para que algo esté en una y no en otra.
Sin esa definición explícita, las capas son solo una convención de nombres. Y las convenciones sin semántica no resuelven nada.
Qué define una capa
Una capa no es simplemente un lugar donde "ponés datos", sino un contrato implícito sobre:
- Nivel de transformación: ¿el dato está tal cual vino del origen o ya pasó por alguna lógica?
- Responsabilidad de calidad: ¿quién responde si el dato está mal? ¿el origen o vos?
- Audiencia: ¿quién puede consumir de esta capa? ¿solo pipelines internos o también analistas?
- Política de retención: ¿cuánto tiempo vive el dato acá? ¿se puede borrar?
Si no podés responder estas preguntas para cada capa, no tenés capas. Tenés carpetas.
La capa cruda como ejemplo
La capa cruda (raw, bronce, landing) es donde más se nota la diferencia entre tener criterio y no tenerlo.
El criterio más útil para esta capa es: guardar lo más fiel posible a la fuente, sin transformaciones. No porque sea lindo, sino porque sirve para algo concreto: trazabilidad.
Cuando alguien dice "este número está mal", necesitás poder responder si el problema vino del origen o lo introdujiste vos al integrar. Si tenés exactamente lo que trajiste de la fuente en ese momento, podés hacer esa traza hacia atrás. Si ya lo transformaste, perdiste la evidencia.
Esto no significa acumular datos sin sentido. Guardar historia está bueno para ciertos casos de uso, pero el valor principal de la capa cruda es tener una traza completa del ciclo de vida del dato. Acumular datos "por las dudas", sin un uso claro, genera más problemas de los que resuelve.
Por qué importa en la práctica
Cuando las capas tienen criterios claros, varias cosas se simplifican:
Debugging: si algo falla, sabés dónde buscar. Si el dato está mal en raw, el problema es del origen. Si está bien en raw pero mal en staging, el problema es tu transformación.
Gobierno: podés definir permisos por capa. Raw puede tener datos sensibles que no todos deberían ver. Consumo puede estar abierto a analistas. Sin criterios, los permisos son arbitrarios.
Comunicación: cuando alguien pregunta "¿de dónde sale este dato?", podés explicar el flujo sin ambigüedad. "Viene del origen, pasa por raw sin cambios, se transforma en staging, se agrega en consumo."
Reproceso: si necesitás recalcular algo, sabés desde qué punto podés partir. Si raw está intacto, podés reprocesar todo el pipeline sin volver a extraer del origen.
Trade-offs y consideraciones
El patrón de capas tiene costos. Cada capa adicional implica:
- Más almacenamiento (aunque el almacenamiento sea barato, no es cero).
- Más complejidad operativa (más jobs, más dependencias, más puntos de falla).
- Más latencia (el dato tiene que pasar por más etapas antes de estar disponible).
La pregunta no es "¿cuántas capas debería tener?" sino "¿qué problema resuelve cada capa que agrego?". Si no podés responder eso, probablemente no necesitás esa capa.
También hay que tener cuidado con el dogma. No todo dato necesita pasar por todas las capas. Un archivo de configuración estático no necesita el mismo tratamiento que una tabla transaccional de millones de registros. El criterio debería adaptarse al tipo de dato y al caso de uso, no ser una regla universal.
En resumen
Medallion es un patrón útil, pero copiarlo sin entenderlo es peor que no usarlo. Las capas funcionan cuando tienen criterios explícitos de qué vive en cada una y por qué, no por el nombre ni el diagrama.
Si vas a implementar capas, empezá por definir esos criterios. Si ya tenés capas pero no podés explicar qué las diferencia, tenés un problema de diseño disfrazado de arquitectura.