Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 07 · Associate + Professional

Modelado

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Associate + Professional

Arquitectura medallion, calidad y modelado

Diseña capas y contratos desde las necesidades de consumo, trazabilidad y reejecución.

Lectura pública
Al terminar podrás
  • Asignar responsabilidades a bronze, silver y gold
  • Diseñar hechos, dimensiones y SCD
  • Definir controles de calidad por frontera
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate + Professional
Ruta relacionada
core
Dominios blueprint
Data Modelling · Data Quality
Estado
Revisión editorial interna
Fuentes principales
Medallion architecture · Materialized views
Reportar un error
01
Modelo mental

Medallion como patrón, no dogma

Medallion separa responsabilidades de datos, no obliga a copiar cada fila tres veces.

Objetivo
Medallion separa responsabilidades de datos, no obliga a copiar cada fila tres veces.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m06
Reportar un error en esta lección

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.

Modelo mental

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.

Bronze

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.
Silver

Capa de entidades o eventos conformados que cumplen tipos, claves y reglas de calidad definidos.

Proporciona una base reutilizable y confiable para distintos productos.
Gold

Capa de productos de datos optimizados para preguntas y consumidores concretos.

Traduce entidades confiables a métricas y modelos con SLA de consumo.
SQLResponsabilidades explícitas
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.

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

Recuerdo activo

¿Dónde debe conservarse el dato original reproducible?

Borrador privado · solo en este navegador
02
Implementación

Bronze y trazabilidad de origen

Silver convierte datos de origen en entidades confiables mediante contratos medibles.

Objetivo
Silver convierte datos de origen en entidades confiables mediante contratos medibles.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m06
Reportar un error en esta lección

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.

Modelo mental

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.

Conformidad

Proceso de convertir representaciones heterogéneas a claves, tipos y semántica compartidos.

Hace comparables datos de varias fuentes y reutilizables los modelos posteriores.
Regla de calidad

Condición medible con ámbito, umbral y acción acordada ante incumplimiento.

Convierte una suposición de datos en un control operativo.
Reconciliación

Comprobación cuantitativa de que entradas, salidas y descartes explican el procesamiento completo.

Detecta pérdidas o multiplicaciones silenciosas durante transformación.
SQLSeparar válidos
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.

Puntos clave

  • Contrato explícito
  • Cuarentena trazable
  • Métricas por regla

Evita

  • Descartar sin contar
  • Mezclar reglas técnicas y de negocio

Recuerdo activo

¿Qué debe acompañar una cuarentena?

Borrador privado · solo en este navegador
03
Operación

Silver, conformado y calidad

Gold puede publicar tablas, vistas, materialized views o streaming tables según frescura y coste.

Objetivo
Gold puede publicar tablas, vistas, materialized views o streaming tables según frescura y coste.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m06
Reportar un error en esta lección

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.

La elección depende de latencia, patrón de cambios y coste de recomputación, no de que Gold signifique siempre tabla física.

Modelo mental

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.

Materialized view

Consulta cuyo resultado se almacena y mantiene mediante una actualización gestionada.

Reduce coste de lectura para transformaciones repetidas y puede aprovechar mantenimiento incremental.
Freshness

Edad del dato publicado respecto al evento o corte esperado por el consumidor.

Determina si schedule, actualización incremental y alertas cumplen el producto.
Producto de datos

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.
SQLObjeto Gold materializado
CREATE OR REFRESH MATERIALIZED VIEW main.gold.daily_sales AS
SELECT order_date, sum(amount) revenue
FROM main.silver.orders GROUP BY order_date;

Valida soporte y política de refresh del entorno.

Puntos clave

  • Vista calcula en lectura
  • MV materializa y refresca
  • Streaming table procesa incrementalmente

Evita

  • Usar vista para agregación costosa muy consultada
  • Elegir streaming sin requisito de frescura

Recuerdo activo

¿Qué diferencia una MV de una view?

Borrador privado · solo en este navegador
04
Diagnóstico

Gold, hechos y dimensiones

Un modelo dimensional separa medidas de eventos y contexto descriptivo.

Objetivo
Un modelo dimensional separa medidas de eventos y contexto descriptivo.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m06
Reportar un error en esta lección

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.

Modelo mental

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.

Grain de hecho

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 SCD tipo 2

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.
Clave sustituta

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.
SQLHecho a grain de línea
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.

Puntos clave

  • Define grain primero
  • Hechos contienen medidas
  • Dimensiones aportan contexto

Evita

  • No declarar grain
  • Sumar importe de pedido repetido por línea

Recuerdo activo

¿Qué se define primero en una tabla de hechos?

Borrador privado · solo en este navegador
05
Decisión de diseño

Contratos, SLOs y ownership

Un contrato de datos une esquema, semántica, calidad, SLA y ownership.

Objetivo
Un contrato de datos une esquema, semántica, calidad, SLA y ownership.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m06
Reportar un error en esta lección

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.

Modelo mental

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.

Contrato de datos

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.
Cambio compatible

Modificación que los consumidores soportados pueden adoptar sin alterar su comportamiento esperado.

Debe demostrarse con pruebas, no asumirse por ser aditiva.
Ownership

Responsabilidad explícita de decidir, operar y responder por un dataset o contrato.

Convierte alertas y solicitudes de cambio en acciones con autoridad.
SQLMétrica de completitud
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.

Puntos clave

  • Cada regla tiene umbral
  • SLO mide servicio
  • Ownership habilita respuesta

Evita

  • Check sin acción
  • SLA sin propietario

Recuerdo activo

¿Qué diferencia un check de un contrato operativo?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Startup ERP Data Lakehouse

Startup ERP Data Lakehouse · commit ba6c71b

notebooks/01_bronze_generate_startup_erp_data.py