Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
key, value, headers y timestamps
Las opciones de suscripción y offsets solo fijan el inicio de una consulta nueva; al reanudar, el checkpoint gobierna la posición.
- Duración
- 17 min aprox.
- Objetivo
- Las opciones de suscripción y offsets solo fijan el inicio de una consulta nueva; al reanudar, el checkpoint gobierna la posición.
- 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.
- Configurar lectura Kafka con seguridad
- Interpretar particiones y offsets
- Diseñar idempotencia entre source y sink
02Implementaciónkey, value, headers y timestamps
Las opciones de suscripción y offsets solo fijan el inicio de una consulta nueva; al reanudar, el checkpoint gobierna la posición.
+
key, value, headers y timestamps
Las opciones de suscripción y offsets solo fijan el inicio de una consulta nueva; al reanudar, el checkpoint gobierna la posición.
`subscribe` elige topics concretos, `subscribePattern` usa una expresión regular y `assign` fija particiones. Debe configurarse exactamente uno. En streaming, `startingOffsets` es `latest` por defecto y solo se consulta si no existe progreso previo; cambiarlo después no rebobina una consulta con checkpoint.
Para un backfill se usa un checkpoint y destino separados o una lectura batch con rangos explícitos, no se modifica a ciegas una consulta productiva. `failOnDataLoss=false` permite continuar cuando offsets ya no existen, pero acepta una posible pérdida y debe acompañarse de reconciliación; no es una solución genérica para errores.
Modelo mental
La posición inicial de Kafka se decide una vez, cuando nace una consulta sin checkpoint. Después, el checkpoint es la autoridad sobre offsets; cambiar `startingOffsets` no rebobina una consulta existente. Esta distinción evita dos errores frecuentes: creer que `latest` salta datos en cada reinicio o intentar un backfill modificando opciones mientras se reutiliza el mismo estado. `subscribe` sigue topics explícitos, `assign` fija particiones concretas y `subscribePattern` descubre topics que coinciden con un patrón; cada opción cambia la topología y debe gobernarse. `earliest` procesa lo aún retenido, no una historia ilimitada. Si Kafka ha eliminado offsets que el checkpoint necesita, la decisión entre fallar, saltar o reconstruir afecta completitud y no debe ocultarse. Un replay fiable usa una consulta y destino separados con límites de offsets, dejando intacta la continuidad de producción.
Posición usada para inicializar cada partición únicamente cuando no existe progreso restaurable en un checkpoint.
Aclara por qué cambiar `earliest` o `latest` no modifica una consulta ya iniciada.Regla que determina qué topics y particiones forman la fuente, mediante subscribe, patrón o asignación explícita.
Forma parte de la identidad de la consulta y condiciona descubrimiento, permisos y compatibilidad de recuperación.Política por la que el broker elimina segmentos antiguos independientemente del progreso del consumidor.
Define la ventana máxima para recuperar backlog o hacer replay directamente desde Kafka.orders = (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", bootstrap_servers)
.option("subscribe", "orders.v1")
.option("startingOffsets", "earliest")
.option("failOnDataLoss", "true")
.option("maxOffsetsPerTrigger", 500000)
.load()
)Tras el primer commit, `startingOffsets` deja de decidir la posición; el checkpoint continúa desde los offsets confirmados.
Puntos clave
- Una consulta reanudada toma offsets del checkpoint, no de `startingOffsets`.
- `earliest` en una consulta nueva puede consumir toda la retención y generar un backlog considerable.
- `failOnDataLoss=false` cambia una garantía de integridad y exige una decisión operativa explícita.
Evita
- Cambiar `startingOffsets` a `earliest` esperando que un stream existente relea su historia.
- Desactivar `failOnDataLoss` para silenciar una retención insuficiente sin medir el hueco perdido.
Recuerdo activo