Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
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.
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.
¿Qué ocurre si se cambia `startingOffsets` en una consulta que conserva el mismo checkpoint?
Profundiza
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.Resumen
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.