Saltar al contenido

Modelado

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 5 de 5

Contratos, SLOs y ownership

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

17 min aprox.

Detalles

Arquitectura medallion, calidad y modelado

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

Reto observable

Diseña un producto bronze-silver-gold con grain, contratos y objeto de consumo explícitos, y reconcilia conteos e importes entre capas.

Al terminar podrás
  • Asignar responsabilidades a bronze, silver y gold
  • Diseñar hechos, dimensiones y SCD
  • Definir controles de calidad por frontera
Prerrequisitos
m06
Última revisión
25 ago 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
05
Decisión de diseño

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.

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.

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

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

Puntos clave

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

Evita

  • Check sin acción
  • SLA sin propietario

Vista de lectura · sin ejecución

Startup ERP Data Lakehouse

Startup ERP Data Lakehouse · commit ba6c71b

notebooks/01_bronze_generate_startup_erp_data.py

Módulo 07

Contenido del módulo