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

At-least-once y exactly-once práctico

Contenido abierto

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

Lección 4 de 5

At-least-once y exactly-once práctico

Kafka, checkpoint y Delta pueden ofrecer procesamiento exactamente una vez, pero cualquier sink externo vuelve a exigir idempotencia end-to-end.

Duración
17 min aprox.
Objetivo
Kafka, checkpoint y Delta pueden ofrecer procesamiento exactamente una vez, pero cualquier sink externo vuelve a exigir idempotencia end-to-end.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Kafka, buses de eventos y garantías de entrega

Integra sistemas de eventos sin confundir offsets, claves, orden y garantías end-to-end.

Al terminar podrás
  • Configurar lectura Kafka con seguridad
  • Interpretar particiones y offsets
  • Diseñar idempotencia entre source y sink
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
streaming
Dominios blueprint
Message buses · Streaming ingestion
Estado
Revisión editorial interna
Fuentes principales
Kafka connector for Structured Streaming · Databricks · Spark API options reference · Databricks
Reportar un error
04
Diagnóstico

At-least-once y exactly-once práctico

Kafka, checkpoint y Delta pueden ofrecer procesamiento exactamente una vez, pero cualquier sink externo vuelve a exigir idempotencia end-to-end.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m14
Reportar un error en esta lección

Spark registra rangos de offsets en el checkpoint y Delta confirma cada microbatch de manera transaccional. Un fallo puede hacer que el motor vuelva a calcular el lote, pero el protocolo del sink evita materializarlo dos veces. Esto no deduplica dos mensajes distintos que el productor publicó con el mismo `order_id`.

Cuando el destino es una API, una base no transaccional o varios sistemas, `foreachBatch` ofrece semántica at-least-once a menos que la función sea idempotente. Un outbox del productor, identificadores de evento estables y `MERGE` en silver resuelven capas distintas del problema.

Modelo mental

El recorrido Kafka–Spark–Delta puede acercarse a exactamente una vez porque cada componente ofrece una identidad durable: offsets por partición, commits por microbatch y transacciones Delta. Sin embargo, esa composición depende de no introducir una frontera que desconozca el protocolo. El checkpoint hace que Spark vuelva a leer un rango cuando no quedó confirmado; Delta puede hacer que la repetición converja al mismo resultado si se usa el sink integrado o un `MERGE` determinista. Una API externa, otra base o dos tablas escritas secuencialmente pueden observar intentos parciales. Por eso se diseña una salida canónica única y se derivan efectos posteriores con consumidores independientes. También se distingue duplicado de origen —dos registros Kafka con el mismo evento— de reintento técnico —el mismo rango ejecutado otra vez—: el primero requiere clave de negocio, el segundo coordinación o idempotencia del sink.

Identidad técnica

Coordenada del transporte, como topic-partition-offset o batch id, que identifica un intento dentro de una ejecución.

Permite rastrear reintentos, pero no sustituye una identidad de negocio entre reconstrucciones.
Outbox

Tabla transaccional de efectos pendientes escrita junto con el estado canónico y consumida de forma independiente.

Evita intentar una transacción distribuida con APIs externas y hace reparables las publicaciones parciales.
Convergencia

Propiedad por la que reejecutar datos conduce al mismo estado final pese a intentos repetidos o desordenados.

Es una formulación práctica y comprobable de corrección para pipelines recuperables.
SQLUpsert de eventos Kafka deduplicados
MERGE INTO main.silver.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
WHEN MATCHED AND source.event_ts > target.event_ts THEN
  UPDATE SET *
WHEN NOT MATCHED THEN
  INSERT *;

Antes del `MERGE`, conserva una sola fila ganadora por `order_id` dentro del microbatch para evitar múltiples matches.

Puntos clave

  • Exactly-once de procesamiento no elimina duplicados creados por el productor.
  • Un checkpoint no puede deshacer un efecto externo ya confirmado fuera de Spark.
  • La clave `event_id` permite deduplicación de negocio además de coordinación técnica de offsets.

Evita

  • Prometer exactly-once porque Kafka usa offsets, aunque el sink sea una API sin clave idempotente.
  • Confundir reejecución del mismo offset con dos mensajes distintos enviados por el productor.

Recuerdo activo

¿Puede el checkpoint eliminar un cargo duplicado ya creado en una API externa?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Structured Streaming with Event Hubs or Kafka

Azure Databricks Hands-on · commit a91650b

HandsOn.dbc

Archivo importable

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Tsuyoshi Matsuzaki
Licencia
No verificada
Formato
dbc
Abrir / descargar .dbc