Gold es una ubicación, no una garantía

La arquitectura medallion ordena el lakehouse en tres capas y cualquiera sabe leerlas sin que se las expliquen: bronze es lo que llegó, silver lo que ya está limpio, gold lo que se puede usar.

Y entonces dos equipos consultan la misma tabla de gold y reportan cifras distintas. O alguien descubre, en mitad de un incidente, que nadie sabe quién aprueba un cambio ahí.

La capa dice dónde está el dato. No dice qué promete.

Lo que la documentación promete, y lo que no

Conviene leer la fuente antes de discutir con ella. La documentación de Databricks es explícita sobre el estatus del patrón: seguirlo es “a recommended best practice but not a requirement”. Una convención de organización, no un mecanismo.

Sobre las garantías, esa misma página afirma que “this architecture guarantees atomicity, consistency, isolation, and durability”. Y ahí hay algo que merece detenerse.

ACID no lo da la disposición en capas. Lo da el formato de tabla que hay debajo, que es una pieza distinta y sustituible. Nombrar tres carpetas no aporta atomicidad, ni aislamiento, ni durabilidad. La frase atribuye a la arquitectura una propiedad que provee otra cosa, y la página no dice cuál.

Es el mismo desplazamiento que el resto del post va a describir, cometido en la documentación oficial. Y aun concediéndolo entero, ACID no habla de que el número sea correcto, de que el grano sea el que crees, ni de que alguien responda por él.

La validación sí aparece, pero repartida: bronze se describe con validación mínima, y es en silver donde entran la aplicación de esquema, la deduplicación y las comprobaciones de calidad. De gold, esa página dice que representa vistas muy refinadas que alimentan análisis, dashboards y aplicaciones. Refinar no es certificar.

La confianza se infiere de la ruta

El problema no está en las capas. Está en lo que el nombre provoca en quien lee, y el salto entero cabe en cuatro pasos.

flowchart LR
    Q{"Can I trust<br/>this GOLD table?"} --> A["It sits in GOLD"]
    A --> U["Which checks ran?<br/>Who owns it?<br/>What grain?"]
    U --> N["Unstated"]

Nadie defiende ese razonamiento en voz alta; simplemente ocurre, porque una palabra como gold hace un trabajo retórico que la documentación nunca le pidió. Ananth Packkildurai, que escribe sobre plataformas de datos en Data Engineering Weekly, lo dice sin rodeos: “data architecture is not a medal competition.”

Y como la confianza se infiere en vez de declararse, no hay nada que falle cuando deja de ser cierta. Una tabla de gold que ya no cumple lo que alguien supuso sigue estando en gold.

Una garantía se declara, no se ubica

La alternativa no es otra capa. Es escribir lo que la tabla promete, en un sitio donde una máquina pueda leerlo.

Eso es un contrato de datos. Bitol, el estándar en incubación en la Linux Foundation, lo define como un acuerdo entre quien produce el dato y quienes lo consumen, que declara las reglas de calidad que debe cumplir, los niveles de servicio, los roles y la propiedad. La diferencia con la capa es que aquí hay un sujeto: alguien se compromete a algo concreto.

El mismo movimiento existe al nivel de la aserción. Great Expectations formaliza las expectativas como afirmaciones verificables sobre un dataset — literalmente “unit tests for your data”. Una expectativa se cumple o no se cumple, y eso es exactamente lo que una carpeta no puede hacer.

Conviene no repetir aquí el error que se critica. Un contrato declara, y su cumplimiento depende de las herramientas que lo ejecuten. El archivo YAML no es la garantía.

Pero una promesa escrita y comprobable es una categoría distinta de una promesa inferida de una ruta.

Esa distinción es todo el argumento. Es la misma tensión que discutí en la ontología de la capa semántica: lo visible no es lo que sostiene el peso.

Gunnar Morling, que trabajó en Debezium, desarrolla la idea desde el lado del productor.

El productor no expone su esquema interno esperando que nadie se apoye en él: decide qué promete y mantiene esa promesa estable aunque cambie por dentro.

Promover en vez de depositar

Hay un patrón que convierte esa promesa en un paso del pipeline. La documentación de Apache Iceberg especifica write-audit-publish: las escrituras van a una rama de auditoría aislada del historial principal, un flujo de validación comprueba ese estado, y solo entonces se promueve.

flowchart LR
    W["Write to audit branch"] --> V{"Run declared<br/>expectations"}
    V -- pass --> P["Publish to main"]
    V -- fail --> D["Discard branch"]
    P --> R["Consumer reads<br/>a checked promise"]

El verbo es lo que cambia. El dato no se deposita en un sitio de confianza: se gana el derecho a estar ahí. La garantía es el paso de validación, no el destino.

Modos de fallo que conviene nombrar

El patrón es el mismo en las siete: alguien confía en una promesa que nadie está comprobando.

Por dónde empezar

No migres nada. Toma la tabla de gold que más gente consulta y escribe, en un archivo junto a ella, tres frases: qué significa una fila, qué garantiza sobre frescura, y quién responde cuando deja de cumplirse.

Luego convierte una de las tres en una comprobación que se ejecute con cada carga. Cuál elijas importa menos que el hecho de que pueda fallar sola: hasta que algo falle, sigues teniendo una ubicación con buen nombre.