Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoArquitectura medallion, calidad y modelado
Diseña capas y contratos desde las necesidades de consumo, trazabilidad y reejecución.
01Modelo mentalMedallion como patrón, no dogma
Medallion separa responsabilidades de datos, no obliga a copiar cada fila tres veces.
+
Medallion como patrón, no dogma
Medallion separa responsabilidades de datos, no obliga a copiar cada fila tres veces.
Bronze conserva fidelidad y trazabilidad; Silver aplica contratos y conformado; Gold publica modelos orientados a consumo.
Cada frontera debe tener propietario, regla de calidad y estrategia de reejecución. Una capa solo se justifica si cambia garantías o consumidores.
CREATE TABLE main.silver.orders_clean AS
SELECT * FROM main.bronze.orders WHERE order_id IS NOT NULL;En producción añade tipos, deduplicación y métricas de rechazados.
¿Dónde debe conservarse el dato original reproducible?
Profundiza
Medallion es una separación de responsabilidades y niveles de confianza, no una obligación de triplicar físicamente todos los datos. Bronze conserva una representación fiel y reproducible de la llegada; Silver aplica contratos, deduplicación y conformidad; Gold publica modelos orientados a consumidores. Algunas fuentes o resultados pueden saltar una materialización si la trazabilidad, SLA y recuperación se mantienen. Cada frontera debe responder qué garantías se añaden, quién es owner y cómo se repara. Una capa nombrada Silver que solo copia columnas no aporta valor. El diseño se evalúa por capacidad de replay, aislamiento de cambios de origen y claridad del contrato, no por el número de carpetas de colores.
Capa de ingestión que conserva datos de origen y contexto suficiente para replay y auditoría.
Aísla cambios de fuente y evita depender de una reextracción imposible.Capa de entidades o eventos conformados que cumplen tipos, claves y reglas de calidad definidos.
Proporciona una base reutilizable y confiable para distintos productos.Capa de productos de datos optimizados para preguntas y consumidores concretos.
Traduce entidades confiables a métricas y modelos con SLA de consumo.Resumen
Puntos clave
- Bronze prioriza replay
- Silver conforma
- Gold sirve casos de uso
Evita
- Tratar medallion como obligación física
- Limpiar Bronze hasta perder el original
02ImplementaciónBronze y trazabilidad de origen
Silver convierte datos de origen en entidades confiables mediante contratos medibles.
+
Bronze y trazabilidad de origen
Silver convierte datos de origen en entidades confiables mediante contratos medibles.
Normaliza tipos, claves y zonas horarias; deduplica con reglas deterministas y separa registros que incumplen el contrato.
Calidad no equivale a descartar: observa, cuarentena o falla según impacto y posibilidad de reparación.
SELECT * FROM main.bronze.orders
WHERE order_id IS NOT NULL AND amount >= 0;Publica también el motivo y la fila rechazada en una tabla de cuarentena.
¿Qué debe acompañar una cuarentena?
Profundiza
Silver convierte registros de una fuente en entidades y eventos con significado compartido. El proceso comienza declarando grain y clave, después tipos, zonas horarias, deduplicación, referencias y reglas de calidad. Conformar no significa borrar toda anomalía: significa decidir qué es válido, qué puede corregirse y qué se cuarentena, conservando evidencia. Una tabla Silver reutilizable evita que cada equipo interprete de forma distinta customer_id o revenue. Su contrato necesita owner, SLA y estrategia de cambios. Las reglas deben ser medibles por lote y temporalmente, porque un 99% de validez puede ocultar deterioro concentrado en un país o una fuente.
Proceso de convertir representaciones heterogéneas a claves, tipos y semántica compartidos.
Hace comparables datos de varias fuentes y reutilizables los modelos posteriores.Condición medible con ámbito, umbral y acción acordada ante incumplimiento.
Convierte una suposición de datos en un control operativo.Comprobación cuantitativa de que entradas, salidas y descartes explican el procesamiento completo.
Detecta pérdidas o multiplicaciones silenciosas durante transformación.Resumen
Puntos clave
- Contrato explícito
- Cuarentena trazable
- Métricas por regla
Evita
- Descartar sin contar
- Mezclar reglas técnicas y de negocio
03OperaciónSilver, conformado y calidad
Gold puede publicar tablas, vistas, materialized views, streaming tables o una capa semántica de metric views según frescura, reutilización y coste.
+
Silver, conformado y calidad
Gold puede publicar tablas, vistas, materialized views, streaming tables o una capa semántica de metric views según frescura, reutilización y coste.
Una vista calcula al consultar; una materialized view conserva resultados y refresca; una streaming table procesa entradas incrementales; una tabla se mantiene mediante una carga explícita. Una metric view de Unity Catalog centraliza dimensiones y medidas gobernadas para que distintas herramientas evalúen la misma semántica mediante MEASURE().
La elección depende de latencia, patrón de cambios y coste de recomputación. Una metric view no corrige un grain físico defectuoso ni sustituye una materialización cara: se apoya en fuentes bien modeladas y evita que cada dashboard redefina ingresos, margen o clientes activos.
CREATE OR REFRESH MATERIALIZED VIEW main.gold.daily_sales AS
SELECT order_date, sum(amount) revenue
FROM main.silver.orders GROUP BY order_date;Si varias herramientas necesitan la misma definición de revenue, publícala además como medida gobernada en una metric view.
¿Qué añade una metric view sobre una vista o tabla Gold?
Profundiza
Gold es una interfaz de datos para una decisión o aplicación. Puede ser tabla, vista, materialized view o streaming table; la elección equilibra frescura, coste de recomputación, complejidad y capacidad de recuperación. Una vista calcula al consultar y conserva máxima actualidad, pero traslada coste y variabilidad al consumidor. Una materialized view mantiene físicamente resultados y Databricks gestiona su actualización según capacidades. Una tabla creada por Job ofrece control explícito. Una streaming table representa ingestión o transformación incremental continua. Antes de elegir se define métrica, grain, dimensiones, SLA y patrón de consulta. Gold no es simplemente la última sentencia SELECT de Silver.
Consulta cuyo resultado se almacena y mantiene mediante una actualización gestionada.
Reduce coste de lectura para transformaciones repetidas y puede aprovechar mantenimiento incremental.Edad del dato publicado respecto al evento o corte esperado por el consumidor.
Determina si schedule, actualización incremental y alertas cumplen el producto.Dataset con consumidor, semántica, owner, calidad y SLA explícitos.
Obliga a diseñar Gold como contrato de uso y no como residuo técnico.Resumen
Puntos clave
- MV materializa y refresca
- Metric view gobierna medidas y dimensiones
- El grain físico sigue siendo autoritativo
Evita
- Usar vista para agregación costosa muy consultada
- Crear una métrica distinta en cada dashboard pese a compartir definición
04DiagnósticoGold, hechos y dimensiones
Un modelo dimensional separa medidas de eventos y contexto descriptivo.
+
Gold, hechos y dimensiones
Un modelo dimensional separa medidas de eventos y contexto descriptivo.
La tabla de hechos fija un grain inequívoco y contiene claves y medidas; dimensiones describen cliente, producto o tiempo.
El grain se define antes de columnas. Mezclar una fila por pedido con una por línea duplica importes y rompe agregaciones.
SELECT order_id, line_id, customer_key, product_key, quantity, net_amount
FROM main.silver.order_lines;Declara que cada fila representa exactamente una línea de pedido.
¿Qué se define primero en una tabla de hechos?
Profundiza
El modelado dimensional organiza hechos medibles alrededor de contexto descriptivo. Una tabla de hechos declara un grain y contiene medidas y claves hacia dimensiones; una dimensión describe entidades como cliente, producto o fecha. El esquema estrella favorece consultas comprensibles y evita unir cadenas normalizadas innecesarias para BI. La decisión central es el grain: una fila por línea de pedido no es una fila por pedido ni por día. Mezclar medidas de granos distintos produce doble conteo. Las dimensiones lentamente cambiantes determinan si una consulta debe ver atributos actuales o los vigentes cuando ocurrió el hecho. Claves sustitutas y rangos temporales hacen explícita esa historia.
Evento o nivel exacto que representa una fila de la tabla de hechos.
Es la base para interpretar medidas y evitar doble conteo.Dimensión que conserva versiones con intervalos de vigencia para representar cambios históricos.
Permite analizar hechos con el contexto que era válido cuando ocurrieron.Identificador interno estable asignado a una versión dimensional, separado de la clave fuente.
Resuelve múltiples fuentes y versiones sin depender de identificadores operacionales mutables.Resumen
Puntos clave
- Define grain primero
- Hechos contienen medidas
- Dimensiones aportan contexto
Evita
- No declarar grain
- Sumar importe de pedido repetido por línea
05Decisión de diseñoContratos, SLOs y ownership
Un contrato de datos une esquema, semántica, calidad, SLA y ownership.
+
Contratos, SLOs y ownership
Un contrato de datos une esquema, semántica, calidad, SLA y ownership.
Checks de unicidad, completitud, validez y frescura deben tener umbral y acción, no solo una consulta booleana.
Los SLO permiten detectar degradación y decidir si bloquear publicación. El contrato se versiona cuando cambia la expectativa del consumidor.
SELECT avg(CASE WHEN customer_id IS NOT NULL THEN 1 ELSE 0 END) AS completeness
FROM main.silver.orders;Compara con un umbral, por ejemplo 0.995, y registra la decisión.
¿Qué diferencia un check de un contrato operativo?
Profundiza
Un contrato de datos reúne lo que productor y consumidores pueden asumir: esquema, significado, grain, claves, calidad, frescura, retención, ownership y política de cambios. Un DDL captura solo una parte. El contrato debe ser verificable mediante pruebas y observabilidad, y cada incumplimiento necesita acción y responsable. La evolución compatible se juzga desde consumidores: añadir una columna nullable puede ser sintácticamente segura, pero romper SELECT * o una serialización rígida. Versionar contratos no implica duplicar siempre tablas; implica comunicar, probar y controlar la transición. Sin ownership, una alerta solo describe un problema. Sin SLA medido, la promesa de datos frescos no es operable.
Acuerdo verificable sobre estructura, semántica, operación y evolución de un producto de datos.
Reduce interpretaciones implícitas y coordina cambios entre equipos.Modificación que los consumidores soportados pueden adoptar sin alterar su comportamiento esperado.
Debe demostrarse con pruebas, no asumirse por ser aditiva.Responsabilidad explícita de decidir, operar y responder por un dataset o contrato.
Convierte alertas y solicitudes de cambio en acciones con autoridad.Resumen
Puntos clave
- Cada regla tiene umbral
- SLO mide servicio
- Ownership habilita respuesta
Evita
- Check sin acción
- SLA sin propietario