Structured Streaming en el lakehouse de AWS: triggers, checkpoints, foreachBatch y exactly-once

Una consulta de streaming en Databricks es una tabla no acotada y un plan al estilo batch que el motor vuelve a ejecutar sobre el siguiente trozo de entrada. Ese modelo es la razón por la que «convertir jobs de batch existentes en jobs de streaming exige cambios mínimos de código» (blog de Databricks, 2026-04-20), y también es la razón por la que cada incidente de producción en este espacio vuelve a cuatro objetos: el trigger que decide cuándo se ejecuta un micro-batch, el checkpoint que recuerda qué se leyó y qué se confirmó, el contrato del sink que decide si un batch reproducido duplica filas, y el watermark que decide cuándo se puede descartar el estado. Acierta esos cuatro y el lakehouse se rellena solo casi en tiempo real; falla en uno y reprocesas una semana, duplicas una tabla silver o ves crecer el estado hasta que el cluster muere.

Esta lección es la mitad de streaming del curso. La lección 05 te enseñó cómo llegan los datos (Auto Loader, autenticación de MSK, eventos de archivos); esta lección enseña cómo siguen llegando correctamente: triggers y su física de coste en AWS, higiene de checkpoints sobre volumes respaldados por S3, foreachBatch MERGE con txnAppId/txnVersion, fan-out de change data feed, estado acotado por watermark, exactly-once de extremo a extremo y la postura de producción (Lakeflow Jobs, no clusters all-purpose) que Databricks documenta hoy.

Cada dato de abajo procede de la documentación de Databricks sobre AWS, los triggers (pie de página 2026-10-08), checkpoints (2026-09-11), foreach, Delta streaming (ambos 2026-08-24), CDF, Kafka (2026-09-11), api-options (2026-10-05), stream-monitoring (2026-09-23), watermarks (2026-09-11), stateful-streaming (2026-10-09), production, schema-evolution (2026-08-05) y las páginas de streaming/dashboards de Databricks SQL, más blogs fechados de Databricks, todos consultados o fechados en octubre de 2026. El alcance de la plataforma es Databricks on AWS: Amazon MSK, S3, Kinesis y los volumes de Unity Catalog son el sustrato; Azure Event Hubs no existe aquí y queda fuera de alcance.

En esta lección:

• configurar todos los triggers soportados y defender la elección frente a la latencia, el coste y las restricciones de serverless: incluyendo por qué el trigger continuous de OSS está muerto en Databricks y cuáles de las tres funciones distintas llamadas «continuous» se confunden;
• diseccionar un checkpoint (offsets, commits, estado, metadata), colocarlo en una ruta de volume de Unity Catalog sobre S3 y recitar la matriz de cambios en el reinicio: qué puedes alterar en una consulta viva frente a lo que fuerza en silencio un inicio desde cero;
• escribir el job de streaming protagonista: Amazon MSK → parseo → watermark + dropDuplicatesWithinWatermark → foreachBatch MERGE en una tabla silver de Delta con txnAppId/txnVersion, más una ruta de dead-letter;
• llevar change data feed a gold: readChangeFeed=true, semántica de _change_type, startingVersion y el replay batch de table_changes() para backfill y auditoría;
• acotar la agregación con estado con watermarks: append frente a update frente a complete, el watermark obligatorio en los outer joins, la política global con mínimo para los múltiples watermarks, y el modo de fallo por inflación del estado con su remedio en RocksDB;
• observar un stream como un operador: campos de progreso (numInputRows, batchDuration, stateOperators), la pestaña Streaming de la Spark UI, StreamingQueryListener y df.observe;
• construir con honestidad el stack de dashboards casi en tiempo real: streaming tables de DBSQL en pipelines serverless y por qué una caché de Lakeview de hasta 24 horas no es «tiempo real»;
• estudiar tres historias nombradas de streaming de clientes de AWS (Burberry, Shell, Asurion), leer el recuadro de actualizaciones de 2026 y practicar con 14 preguntas de estilo examen más cuatro comprobaciones interactivas.

1. El modelo de micro-batch y el menú de triggers

Structured Streaming planifica tus transformaciones de DataFrame una sola vez y las ejecuta de forma incremental. En el motor de micro-batch por defecto, el driver pregunta repetidamente a la fuente «¿qué hay de nuevo desde el último offset?», planifica un batch, lo ejecuta en el cluster, confirma el offset y la escritura del sink, y deja constancia del progreso en el checkpoint. El modo real-time es la ruta de ejecución separada y soportada de baja latencia de Databricks: no el experimento de procesamiento continuo de OSS. Batch y streaming comparten una sola superficie de API; solo cambian el lector, el trigger y el checkpoint. Esa es la lección de unificación que la lección 05 usó para ejecutar el mismo código bronze como job nocturno y como stream de baja latencia.

1.1 La tabla verificada de triggers (docs, pie de página 2026-10-08)

1.2 Ejemplo resuelto E1: elegir un trigger, con la factura de AWS de por medio

Escenario: una zona de aterrizaje en S3 recibe archivos en ráfagas; la especificación del producto dice «casi en tiempo real, con minutos de sobra». Tres configuraciones candidatas, valoradas en dos ejes: cómputo (job cluster) y coste de peticiones de S3 (el multiplicador oculto del trigger por defecto).

Boceto de cómputo (nuestro, sobre la semántica documentada): la ejecución horaria de availableNow vacía en 20 minutos sobre un job cluster de 4 nodos: 12 DBU/h × 0,33 h = 4 DBU/ejecución; con Jobs Compute a $0.15/DBU (forma de lista Premium de AWS a oct 2026, la misma base documental que el E7 de la lección 05: revisa siempre system.billing.list_prices en tu cuenta) eso son $0.60/ejecución → $14.40/mes. Un stream con processingTime='10 seconds' en el mismo cluster corre de forma continua: 720 h/mes × 12 DBU = 8,640 DBU ≈ $1,296/mes, lleguen o no datos. El trigger por defecto (consulta «cada pocos milisegundos») multiplica el volumen de LIST/GET de S3 contra la misma tarifa de $0.005 por cada 1.000 LIST que la lección 05 calculó: sobre un prefijo de 2M de archivos, el modo de listado de directorios con triggers de nivel de segundo cuesta $2,592 to $25,920/mes solo en LIST frente a $28.80 con un availableNow de 15 minutos. El trigger es una decisión de coste, no una preferencia de latencia.

• 📚 ¿Sabías que…? Trigger.Once está obsoleto desde DBR 11.3 LTS, «Usa Trigger.AvailableNow para todas las cargas de trabajo de procesamiento por lotes incrementales» (triggers, 2026-10-08), pero Once sigue apareciendo en la frase de soporte de serverless porque los notebooks antiguos todavía lo llaman. AvailableNow es la mejora estricta: la misma semántica de vaciar y salir, más limitación de tasa entre micro-batches (maxFilesPerTrigger, maxOffsetsPerTrigger), algo que Once no tenía. Cualquier tutorial que enseñe Once como vigente está enseñando una API de 2022.

2. Checkpoints: la memoria de la consulta, en S3

2.1 Anatomía

«A checkpoint directory contains Offsets, Commits, State, and Metadata» (checkpoints, 2026-09-11):

En AWS el checkpoint vive en almacenamiento duradero: el ejemplo documentado escribe checkpointLocation bajo una ruta de volume de Unity Catalog (/Volumes/catalog/schema/volume/path), que aterriza en S3 a través de tu storage credential. «Give each query its own checkpoint directory in durable cloud storage» (página de producción). Nunca DBFS local /tmp, nunca el prefijo de aterrizaje, nunca una ruta con política de ciclo de vida.

2.2 La matriz de cambios en el reinicio

No todo cambio de código es seguro ante un reinicio sobre un checkpoint existente. Las reglas de la página de checkpoints, comprimidas:

3. Fuentes en AWS: Kafka/MSK en profundidad, Delta CDF dentro

La lección 05 cubrió Auto Loader de extremo a extremo; esta sección añade lo que necesita un operador de streaming: los controles de tasa de Kafka, la tabla Delta como fuente y el CDF como ruta de cambios recomendada.

3.1 Kafka / Amazon MSK: las cuatro opciones que deciden tu semana

La lectura mínima es spark.readStream.format("kafka") con kafka.bootstrap.servers y subscribe, y después las opciones que importan (api-options, 2026-10-05; doc de Kafka, 2026-09-11):

El lector devuelve key y value como binario, haz siempre cast/from_json/from_avro de forma explícita. Autenticación en AWS, en el orden recomendado por Databricks: service credentials de Unity Catalog (databricks.serviceCredential, DBR 16.1+, preferido para clusters compartidos y serverless, no configures también sasl.* tú mismo), después MSK IAM por instance profile (AWS_MSK_IAM + clases enmascaradas shadedmskiam.*, SASL_SSL, puerto 9098), después JAAS basado en roles (awsRoleArn=), después SASL/PLAIN/SCRAM y por último mTLS con el material en un volume de UC y las contraseñas en un secret scope. Los security groups de MSK deben permitir el SG del cómputo de Databricks en 9092 (PLAINTEXT) / 9094 (SASL/SSL) / 9098 (IAM); VPC peering o PrivateLink une las dos VPC.

3.2 Ejemplo resuelto E2: MSK → Delta bronze, con límite de tasa y deduplicación

Dos trampas documentadas viven en esas veinte líneas. startingOffsets=latest es el valor por defecto de streaming, con un checkpoint de nueva planta la consulta se salta en silencio todo lo que ya hay en el topic; pon earliest en la primera ejecución y después confía en el checkpoint para siempre. Y en DBR 17.1+ los offsets más recientes de Kafka se obtienen después de que cada micro-batch termine, así que las métricas de backlog (avgOffsetsBehindLatest y demás) «may show small, persistent non-zero values. This is expected behavior», no despiertes a nadie a las 03:00 por un «lag» de 12 offsets.

3.3 Delta como fuente, y CDF como ruta de cambios recomendada

«Structured Streaming only accepts append inputs and throws an exception if any modifications occur on the source Delta Lake table» (docs.../structured-streaming/delta-lake, 2026-08-24), y por eso «Databricks recommends streaming from the CDC feed of a Delta Lake table rather than directly from the table whenever possible». El change data feed automático «uses the same table_changes() and readChangeFeed APIs as legacy change data feed and works with batch queries, Structured Streaming…» (página de CDF). Actívalo al crear la tabla (delta.enableChangeDataFeed=true), nada se captura antes de ese momento. La sección 5 construye el fan-out completo.

• 📚 ¿Sabías que…? El proyecto «Spark Streaming» de la era de las DStreams «ahora es un proyecto heredado, y las nuevas aplicaciones de streaming deberían usar Structured Streaming en su lugar» (blog de Databricks, 2026-04-20). Si tu CV o tu runbook todavía dicen «Spark Streaming» o Dstream, estás anunciando una tecnología que su propio creador retiró. El blog de Structured Streaming de la misma fecha señala que la API «became production-ready in Spark 2.2»: el modelo que estás aprendiendo aquí lleva siendo el valor por defecto durante la mayor parte de una década.

4. foreachBatch y la historia del exactly-once

4.1 El contrato

«Debes usar foreachBatch para las operaciones de merge de Delta Lake en Structured Streaming»: MERGE es una operación de batch, así que un upsert desde un stream solo puede ocurrir dentro del callback del micro-batch (docs.../structured-streaming/foreach, 2026-08-24). La misma página fija la garantía: «foreachBatch() solo proporciona garantías de escritura at-least-once. Sin embargo, puedes usar el batchId entregado a la función para deduplicar la salida y obtener una garantía exactly-once.» En DBR 14.0+ la ruta de Delta exige la API explícita de idempotencia: «Debes usar las opciones de escritura txnAppId y txnVersion, vinculando txnVersion a batchId», y «No captures ni reintentes las excepciones localmente»; deja que los errores se propaguen para que el orquestador reintente el micro-batch completo de forma limpia. Para destinos personalizados o externos (BD OLTP, cola, API HTTP): «Implement your own idempotency»: si el batchId es el mismo, tu efecto secundario tiene que ser el mismo.

Tres corolarios que las docs enuncian y que los ingenieros junior incumplen constantemente:

1. Checkpoint nuevo ⇒ txnAppId nuevo. «Si borras el checkpoint de streaming y reinicias la consulta con un checkpoint nuevo, debes proporcionar un txnAppId diferente.» Los checkpoints nuevos empiezan en el batch ID 0; con el appId antiguo, Delta trata el replay como duplicado y lo descarta.
2. Una escritura de streaming por sink. «Databricks recommends configuring a separate streaming write for each sink you want to update instead of using foreachBatch. Writes to multiple sinks in foreachBatch reduces parallelization and increases overall latency because writes to multiple tables are serialized.»
3. MERGE idempotente. «Verifica que tu sentencia merge dentro de foreachBatch sea idempotente. De lo contrario, los reinicios de la consulta de streaming pueden aplicar la operación sobre el mismo lote de datos varias veces.» Estrecha la cláusula ON a las claves del batch.

4.2 Ejemplo resuelto E3, el job protagonista: MSK → MERGE en silver con ruta de dead-letter

4.3 El árbol de decisión del exactly-once

5. Change data feed hacia fuera: el fan-out a gold

5.1 El patrón

Crea la tabla silver con el CDF activado; cada consumidor aguas abajo que necesite cambios hace streaming del feed CDC en lugar de releer la tabla. Cada registro de CDF lleva _change_type ∈ insert / update_preimage / update_postimage / delete. El replay batch usa table_changes('tbl', v1, v2) para backfill y auditoría: la misma mecánica que el propio blog de CDF de Databricks (2021-06-09) usó para construir el patrón de CDC con medallion.

5.2 Ejemplo resuelto E4: stream de CDF a gold más un replay batch

«Debes usar Structured Streaming para que Databricks rastree automáticamente las versiones del change data feed de tu tabla», el seguimiento de versiones es un comportamiento del consumidor de streaming, y por eso emparejar el CDF con availableNow en una programación es el patrón de replay determinista documentado. Los pipelines de Lakeflow añaden AUTO CDC (el Applier) para DB→Delta y Delta→Delta sin MERGE escrito a mano, cubierto en la lección 07; esta sección es la versión de notebook sin procesar que ahora entiendes desde dentro.

6. Watermarks, estado y el modo de fallo por inflación

6.1 Para qué sirve un watermark

«Watermarks automatically remove old state data to prevent memory errors and increased processing latency» (watermarks, 2026-09-11). Tú afirmas una puntualidad máxima, withWatermark("event_time", "10 minutes"), y el motor avanza un watermark global más allá de max(event_time) − delay. «Queries always process records that arrive within the threshold. Queries might still process records that arrive outside the threshold, but this isn't guaranteed.» El modo de salida cambia lo que ves:

Los joins stream-stream «only support append mode»; «For outer joins, watermarking is mandatory»; para inner joins se recomienda encarecidamente. Con múltiples watermarks «Structured Streaming uses the minimum as the global watermark» por defecto; spark.sql.streaming.multipleWatermarkPolicy=max baja la latencia pero «descarta datos de los streams más lentos… úsalo con precaución». Las duraciones de ventana van «de microsegundos hasta días. Las duraciones de un mes o mayores no están soportadas.»

6.2 Ejemplo resuelto E5: agregación por ventanas con las matemáticas del estado a la vista

Lógica de dimensionado (nuestra, sobre la semántica documentada): claves vivas ≈ anuncios × ventanas dentro del watermark = 5.000 anuncios × 3 ventanas (watermark de 10 min ÷ ventana de 5 min) ≈ 15.000 filas de estado, trivial. Quita el watermark y el estado retiene cada (window, ad_id) para siempre; añade el modo complete y cada fila histórica se vuelve a emitir en cada trigger. La variante de dedup importa igual: un dropDuplicates(["event_id"]) simple retiene estado de cada clave para siempre; dropDuplicatesWithinWatermark(["event_id"]) (DBR 13.3 LTS+, requiere un watermark) solo retiene las claves dentro de la ventana de puntualidad, «the correct default for idempotent event ingestion when duplicates arrive close in event time».

6.3 Ejemplo resuelto E6: valores por defecto del estado en producción y estado personalizado

Para todas las consultas con estado en los DBRs actuales, la postura documentada de Databricks es: state store de RocksDB + checkpointing de changelog (DBR 13.3 LTS+), «Databricks recommends enabling changelog checkpointing for all Structured Streaming stateful queries»; async state checkpointing y async progress tracking en la página de producción; sin autoscaling para los job clusters de Structured Streaming puro («Compute auto-scaling has limitations scaling down»); y rebalanceo de estado en el resize (activado por defecto en los pipelines de Lakeflow; config spark.sql.streaming.statefulOperator.stateRebalancing.enabled desde DBR 11.3+). Estado con clave personalizado más allá de agregación/dedup/joins: transformWithState (DBR 16.2+) sustituye al heredado mapGroupsWithState/flatMapGroupsWithState en el código nuevo. El número de particiones de shuffle queda congelado al crearse el checkpoint para los operadores con estado (la repartición bajo demanda llega en DBR 18 LTS+), una trampa silenciosa cuando alguien «solo sube la paralelidad» en una consulta existente.

• 📚 ¿Sabías que…? VACUUM «omite cualquier directorio que empiece con _», y por eso las docs de Delta streaming sugieren guardar los checkpoints «using a directory structure such as /_checkpoints». Una convención de nombres de un solo carácter separa un comando de mantenimiento rutinario de un estado de streaming borrado: combínala con una ruta de volume de UC y una política de IAM que prohíba s3:DeleteObject sobre el prefijo del checkpoint, y borrar un checkpoint deja de ser una posibilidad de las 3 de la mañana.

7. Schema evolution en streams: planes bloqueados, sinks aditivos

«A streaming query's schema is locked in during the planning phase… If the source schema changes mid-execution, the query fails, and the user must restart the streaming query» (schema-evolution, 2026-08-05), y por eso los streams de producción deben correr bajo un job con reinicio automático. En el lado del sink, Delta solo acepta cambios aditivos: .option("mergeSchema", "true") en la escritura de streaming «only supports adding new columns». Prefiere la opción por escritura (o WITH SCHEMA EVOLUTION en SQL) a spark.databricks.delta.schema.autoMerge.enabled de sesión, que es heredado. En el lado de la fuente: las columnas nuevas fluyen con mergeSchema; los renombres y borrados necesitan spark.databricks.delta.streaming.allowSourceColumnRename / …allowSourceColumnDrop; la ampliación de tipos es DBR 16.4 LTS+; «Other type changes: Not supported.» Y el dato nuclear, «Updating a table schema terminates any streams reading from that table» (update-schema, 2026-08-19). El propio bucle de evolución de Auto Loader (fallar con UnknownFieldException y después reiniciar, schemaEvolutionMode=addNewColumns / rescue) fue la serie E de la lección 05; la historia de la fuente Delta aquí es la misma disciplina dirigida por reinicios, en otra capa.

8. Observabilidad y el dashboard casi en tiempo real

8.1 Tres capas de monitorización de streams (stream-monitoring, 2026-09-23)

1. Progreso de la consulta: el StreamingQuery devuelto por el notebook, la pestaña Streaming de la Spark UI (.queryName() para desambiguar) y el JSON de progreso. Campos clave: numInputRows, inputRowsPerSecond, processedRowsPerSecond, batchId, batchDuration, el desglose de durationMs (getBatch, addBatch, commitOffsets, walCommit), eventTime.watermark y stateOperators (numRowsTotal, memoryUsedBytes, numRowsDroppedByWatermark, customMetrics de RocksDB). Las métricas de la fuente incluyen numBytesOutstanding / numFilesOutstanding de Delta/Auto Loader; reservoirId corresponde al id de DESCRIBE DETAIL <table>.
2. StreamingQueryListener (Python y Scala, DBR 11.3 LTS+; suelos por modo de acceso de UC 15.1+ dedicado, 16.1+ estándar de Scala): envío a Prometheus/Grafana/Kafka. Mantén los callbacks diminutos: «Processing latency with listeners can significantly affect query processing speeds.»
3. df.observe(name, agg…): agregados arbitrarios por epoch emitidos en observedMetrics (p. ej., una proporción de filas malformadas que alerta antes de que lo haga la frescura aguas abajo).

8.2 Dashboards: por demanda, con caché, honestos

Los dashboards de DBSQL/Lakeview son por demanda (pull-based): los datasets se ejecutan en un SQL warehouse y los resultados aterrizan en una caché que «puede devolver resultados de hasta 24 horas de antigüedad incluso cuando los datos subyacentes hayan cambiado», solo una programación explícita (o un fallo de caché) la refresca, y «Servir resultados desde la caché del dashboard no arranca el SQL warehouse» (dashboards caching, 2026-07-16). La forma casi en tiempo real soportada en AWS es, por tanto: el stream escribe en Delta en segundos; una streaming table independiente en Databricks SQL (CREATE OR REFRESH STREAMING TABLE … SCHEDULE EVERY … / TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES, intervalo mínimo de TRIGGER ON UPDATE de 1 minuto, corriendo en un pipeline serverless creado automáticamente) mantiene fresca la tabla; el dashboard consulta esa tabla con su propio cron. El push de dashboard por debajo de un minuto no es una función documentada de DBSQL, no lo prometas en una revisión de diseño.

9. Postura de producción: Lakeflow Jobs y los tres «continuous»

La página de producción de Databricks es inusualmente directa: «Run production Structured Streaming workloads as scheduled Lakeflow Jobs on Databricks»; «Don't run Structured Streaming workloads using all-purpose compute»; «Schedule Lakeflow Jobs using Continuous mode. This refers to the Databricks Jobs scheduling feature, not the Structured Streaming trigger interval»; «Don't enable autoscaling for compute for Structured Streaming jobs» (compensado con estado en RocksDB, async state checkpointing y async progress tracking). Y la recomendación de la plataforma: «Databricks recommends using Lakeflow pipelines for new Structured Streaming pipelines.»

La trampa de nombres que hace fracasar las revisiones de arquitectura: tres cosas distintas llamadas «continuous»:

Dos incompatibilidades más de las mismas páginas: async progress tracking «isn't compatible with the AvailableNow or Once triggers», no puedes combinar el trigger optimizado en coste con esa optimización de latencia; y «If you try to recover from a query failure with an incremental batch, a trigger interval change doesn't solve the problem», un micro-batch fallido y atascado tiene que completarse igualmente; escala hacia arriba o empieza un checkpoint nuevo.

10. Las trampas: catorce confusiones que esta lección no te deja conservar

1. El trigger por defecto como valor por defecto de producción. Latencia de 3 to 5 s con comprobaciones de almacenamiento cada pocos milisegundos: el escenario documentado de «cargos inesperados». Configura un trigger explícito; prefiere availableNow para la ingesta programada.
2. Borrar un checkpoint para «arreglar el retraso». Inicio desde cero, replay completo, watermark reiniciado, y Delta descarta en silencio el replay a menos que rotes txnAppId.
3. Compartir un checkpoint entre consultas. Prohibido explícitamente: «Cada consulta debe tener una ubicación de checkpoint diferente.»
4. El mismo txnAppId después de un checkpoint nuevo. Los batch IDs reinician en 0; Delta ignora las escrituras. Documenta el appId por stream y rótalo de forma deliberada.
5. Capturar excepciones dentro de foreachBatch. Rompe la contabilidad de at-least-once; deja que el orquestador reintente el batch completo.
6. Fan-out dentro de foreachBatch. Varios sinks se serializan; prefiere una escritura de streaming por sink.
7. Omitir persist() en foreachBatch. Lee el DataFrame del micro-batch dos veces sin él y releerás la fuente.
8. dropDuplicates sin una cota. Estado de cada clave para siempre; usa dropDuplicatesWithinWatermark (DBR 13.3 LTS+) con un watermark.
9. Modo complete en una agregación que crece. El estado nunca se descarta por diseño; «can perform poorly as data scales.»
10. La primera ejecución de Kafka con startingOffsets por defecto. latest se salta en silencio el backlog; pon earliest una vez y después confía en el checkpoint.
11. Tratar las métricas pequeñas de backlog de Kafka (DBR 17.1+) como un incidente. Un *OffsetsBehindLatest no cero persistente es esperado por diseño.
12. Los tres «continuous». Trigger de OSS no soportado ≠ modo continuous de Lakeflow ≠ programación continuous de Jobs.
13. Serverless + un trigger que no es availableNow. Solo AvailableNow/Once arrancan en serverless: planifica el cómputo por trigger.
14. «El dashboard es en tiempo real porque lo es el stream.» La caché tiene hasta 24 horas de antigüedad; es la programación, o una streaming table de DBSQL debajo, lo que la mantiene fresca.

Veredicto comparativo: notebooks sin procesar de Structured Streaming frente a pipelines declarativos de Lakeflow (a oct 2026)

• Notebooks writeStream sin procesar (el código de esta lección), la opción transparente. Control total sobre triggers, checkpoints, MERGE con foreachBatch, la disciplina de txnAppId y los límites de tasa; la herramienta didáctica correcta y la elección adecuada para jobs únicos, sinks a medida (upserts OLTP, colas, APIs) y personalización máxima. Databricks todavía los soporta por completo, cuando corren como «scheduled Lakeflow Jobs on Databricks» con reinicio automático, en cómputo de jobs y sin autoscaling. El precio de ese control es tuyo: tú posees la ubicación del checkpoint, la configuración del state store (RocksDB + changelog), el cableado de reinicio ante cambios de esquema y cada línea de código de idempotencia.
• Pipelines declarativos de Lakeflow (antes Delta Live Tables; lección 07): la ruta de producción recomendada. «Databricks recommends using Lakeflow pipelines for new Structured Streaming pipelines» (página de producción). Tú declaras fuentes, sinks y expectations; Databricks gestiona checkpoints y estado, ejecuta el modo continuo para streaming realmente continuo (incluido serverless), aplica AUTO CDC en lugar de MERGE escrito a mano, rebalancea el estado por defecto en el resize y ofrece un autoscaling mejorado que los jobs de streaming puro no deberían usar. La contrapartida: menos control fino sobre el bucle de micro-batch, un modelo de desarrollo por pipeline (no por notebook) y otro concepto que gobernar.
• La ingesta con Auto Loader (lección 05) se divide del mismo modo: «Lakeflow Spark Declarative Pipelines is the recommended way to run Auto Loader for most production ingestion… If your workload doesn't have low-latency requirements and your priority is minimizing compute cost, you can instead schedule Auto Loader as a triggered batch job that uses Trigger.AvailableNow.»
• Veredicto en una línea: pipelines de streaming nuevos → Lakeflow; sinks a medida, laboratorios didácticos y jobs por lotes con availableNow ajustado al céntimo → Structured Streaming puro sobre Lakeflow Jobs con la higiene de esta lección, y en ningún caso un cluster all-purpose.

Actualizaciones de 2026 (en octubre de 2026)

Casos Reales

📋 Caso A: Burberry (venta minorista de lujo, cloud: AWS) El reto. Lotes diarios de clickstream que llegaban «anywhere between 2:00 and 7:00 PM GMT», y un almacén en la nube que preagregaba el detalle que Customer 360 necesitaba. Stack en AWS. Databricks Data Intelligence Platform con Snowplow Behavioral Data Platform para Customer 360 en tiempo real: la página del caso lleva la propia etiqueta Cloud: AWS de Databricks (https://www.databricks.com/customers/burberry, página sin fecha, consultada 2026-10). Resultado reportado. «99% Reduction in latency for customer clickstream data · 52x Increase in cookie duration»; «we've broken free from daily data batches and formed an accurate real-time view of our customers' digital activity» (misma URL, consultada 2026-10; origen del caso 2023). Encaja con esta lección. Secciones 1 y 9: un SLA de latencia de clickstream es un requisito de negocio; la solución de Burberry fue una ruta de lakehouse dirigida por eventos, no una ventana nocturna más grande. La elección del trigger (availableNow con la llegada de archivos, o un stream de intervalo en segundos desde un bus) es exactamente la decisión del E1, y la promesa de frescura del dashboard pertenece a la honestidad de la caché de la sección 8. ⏳ Nota temporal: una cifra con origen en 2023 que todavía se muestra en 2026: cítala como lo que Burberry reportó en su momento, no como una garantía de la plataforma.

📋 Caso B, Shell (energía, cloud: AWS, Azure, historia multicloud) El reto. Millones de tags de series temporales industriales, infraestructura heredada, crecimiento exponencial de los datos y escasez de perfiles de ingeniería de datos: ETL a escala de IoT. Stack. La plataforma de Shell.ai sobre Databricks: «Delta Live Tables» (hoy Lakeflow / Spark Declarative Pipelines), Delta Lake e ingesta de structured streaming a través del framework de código abierto RTDIP; la página del caso lista AWS y Azure, así que enseñamos la mitad de AWS como Delta respaldado por S3 más ingesta de streaming (https://www.databricks.com/customers/shell, sin fecha, consultada 2026-10). Resultado reportado. «1.3 trillion rows of sensor data processed with Delta Live Tables · Millions of dollars saved with data-driven operations» (PDF de Shell sobre DLT, agosto de 2021); «El consumo de datos en tiempo real ha aumentado 15 veces en los últimos 5 años en Shell»; RTDIP «downloaded 25,000+ times/month» (https://www.databricks.com/blog/developing-time-series-lakehouse-shell, 2023-10-09). Encaja con esta lección. Secciones 6 y 9: un estate de sensores de un billón de filas solo sobrevive con estado acotado por watermark y pipelines declarativos continuos; las habilidades de notebook sin procesar de esta lección son las que te permiten depurar el pipeline gestionado cuando se porta mal. ⏳ Nota temporal: las cifras del PDF de DLT son de 2021 bajo el nombre histórico del producto; los números de RTDIP son de 2023. La historia abarca AWS y Azure: solo el patrón de streaming es portable entre nubes.

📋 Caso C: Asurion (seguros y protección de dispositivos, cloud: AWS) El reto. 8.000 tablas, 10.000 vistas y ~600 data marts con mapeos ETL por tabla y una capa batch/speed duplicada que no podía absorber nuevas fuentes de forma barata. Stack en AWS. Spark Structured Streaming, Auto Loader y foreachBatch hacia Delta, ingiriendo «database CDC feeds, APIs and flat files to streams from Kinesis, Kafka, SNS and SQS»: un data lake de producción explícitamente «on AWS» (https://www.databricks.com/blog/2021/09/16/large-scale-etl-and-lakehouse-implementation-at-asurion.html, 2021-09-16). Resultado reportado. «The Asurion data lake executes 4,000+ streaming jobs and hosts over 4,000 tables in a production data lake on AWS» (https://www.databricks.com/blog/2021/05/10/aws-guide-to-data-ai-summit-featuring-disney-comcast-capital-one-and-mcdonalds.html, 2021-05-10). Encaja con esta lección. Secciones 4 y 10: con más de 4.000 streaming jobs, la arquitectura es un framework de foreachBatch/checkpoint parametrizado (un patrón idempotente, muchos feeds), y la lista de fuentes nativas de AWS (Kinesis, SNS, SQS, MSK) es la razón por la que este curso enseña la autenticación MSK IAM y la higiene de checkpoints en S3 como habilidades de primera clase. ⏳ Nota temporal: cifras de 2021 reportadas en su momento; revisa cualquier afirmación sobre concurrencia de ese blog contra la documentación actual antes de reutilizarla.

Preguntas de Práctica (Practice Questions)

Pasa el cursor sobre una barra: availableNow ejecuta ~20 minutos por cada programación horaria (1 en la escala, se apaga solo); un stream con processingTime='10 seconds' está activo siempre que fluyan datos (36, más o menos un mes entero de uptime frente a un job de 20 minutos); el valor por defecto sin especificar añade una comprobación del almacenamiento cada pocos milisegundos encima del cómputo continuo (60, el multiplicador documentado de llamadas a la API, que la lección 05 calculó en $2,592 to$25,920/mes solo en LIST sobre un prefijo de 2M de archivos frente a $28.80 con un availableNow de 15 minutos); el modo real-time necesita cómputo dedicado y checkpoints menos frecuentes (80, el precio de la latencia sub-segundo, y la razón por la que está reservado al fraude y a la personalización); el trigger continuo de OSS es gratis porque no puedes ejecutarlo (0, «Not supported»). La escala es un modelo didáctico de la semántica documentada, no una métrica de la plataforma, haz la aritmética de DBU con tu propia forma de cluster y system.billing.list_prices.