Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 07 · Lección

Contratos, SLOs y ownership

Contenido abierto

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

Lección 5 de 5

Contratos, SLOs y ownership

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

Duración
17 min aprox.
Objetivo
Un contrato de datos une esquema, semántica, calidad, SLA y ownership.
Siguiente paso
Continuar con el laboratorio
Ver detalles del módulo

Arquitectura medallion, calidad y modelado

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

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
05
Decisión de diseño

Contratos, SLOs y ownership

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

Mostrar prerrequisitos
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