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

MERGE e idempotencia

Contenido abierto

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

Lección 4 de 5

MERGE e idempotencia

Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.

Duración
17 min aprox.
Objetivo
Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Delta Lake: ACID, esquema, historial y DML

Usa el transaction log para construir tablas fiables, auditables e idempotentes.

Al terminar podrás
  • Explicar snapshots y concurrencia optimista
  • Aplicar MERGE, UPDATE y DELETE correctamente
  • Diferenciar tipos de tabla, conversión, schema evolution y time travel
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate + Professional
Ruta relacionada
core
Dominios blueprint
Delta Lake · Data management
Estado
Revisión editorial interna
Fuentes principales
Delta Lake · Convertir a managed con SET MANAGED
Reportar un error
04
Diagnóstico

MERGE e idempotencia

Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.

Mostrar prerrequisitos
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

Enforcement evita escribir columnas o tipos incompatibles con el contrato. Evolution puede añadir columnas durante append o merge cuando se habilita por operación o configuración soportada.

Aceptar columnas nuevas no significa aceptar cualquier cambio de tipo o semántica. Bronze puede ser más tolerante; Silver debe controlar contrato, nulos y consumidores.

Modelo mental

Schema enforcement protege la tabla frente a escrituras incompatibles; schema evolution modifica el contrato bajo una autorización explícita. Enforcement compara nombres, tipos y estructura con el esquema de destino y evita aceptar silenciosamente datos imposibles. Evolution puede añadir columnas o realizar cambios soportados cuando se habilita en la operación adecuada. No es una licencia para que una columna cambie de significado o para activar autoMerge global sin revisión. Bronze puede tolerar atributos nuevos para no perder ingestión; Silver debe decidir si son válidos, cómo se rellenan históricamente y qué consumidores se rompen. El esquema es sintaxis, mientras el contrato incluye semántica y calidad.

Schema enforcement

Validación en escritura que rechaza datos que no cumplen el esquema admitido por la tabla.

Evita corrupción silenciosa y hace visibles los cambios de productor.
Schema evolution

Cambio controlado del esquema de destino durante operaciones compatibles.

Permite adaptar columnas sin desactivar la protección general.
Column mapping

Funcionalidad Delta que identifica columnas más allá de su nombre físico y habilita ciertos cambios de metadatos.

Afecta renombres, drops y compatibilidad de clientes.
PySparkEvolución controlada
(incoming.write
  .format("delta")
  .mode("append")
  .option("mergeSchema", "true")
  .saveAsTable("main.bronze.orders"))

Registra columnas nuevas y prueba consumidores antes de propagarlas a Silver.

Puntos clave

  • Enforcement protege el contrato
  • Evolution es opt-in
  • Cambio sintáctico no garantiza compatibilidad semántica

Evita

  • Activar autoMerge global sin gobernanza
  • Cambiar STRING a INT suponiendo evolución automática

Recuerdo activo

¿mergeSchema convierte cualquier tipo incompatible?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

01_quickstart.ipynb

Delta Lake examples · commit 82ed214

notebooks/pyspark/01_quickstart.ipynb