E197 - Arquitectura Batch versus Real-Time en Machine Learning

Resumen

El episodio 197 compara las arquitecturas batch y real-time para poner modelos de machine learning en producción, usando como ejemplo hipotético a una aerolínea (TAM Airlines) en Google Cloud Platform. El caso batch es una predicción diaria de ocupación de vuelos para dashboards internos. El caso real-time es una predicción de atraso de vuelos dentro de la app, con latencia menor a 100 ms y alta concurrencia. También se define streaming como flujo continuo de eventos. Se repasan herramientas (Airflow, Kubeflow Pipelines, Vertex AI, Pub/Sub, Kubernetes, Cloud Run), problemas típicos con sus soluciones (latencia, cold start, throttling, backpressure, timeouts) y estrategias de deployment (shadow, rolling, blue/green, canary). Conclusiones: la mayoría de los problemas en las empresas son batch, que es más simple y barato; real-time es más caro y complejo, y conviene partir por batch. La arquitectura de fondo es muy similar en ambos casos.

Capítulos

• 00:00
  IntroSe presenta el episodio sobre modelos en producción, batch vs real-time, con un ejemplo en GCP. Se mencionan los problemas y soluciones típicas que se tratarán.
• 00:27
  Diferencia entre batch y real-timeBatch procesa bloques grandes cada cierto tiempo (mes, semana, día); real-time tiene periodicidad mucho menor. No hay una línea divisoria: lo que importa es qué tan rápido se necesita la predicción. Real-time implica latencia de milisegundos; batch implica datos enormes que pueden agotar la RAM. Real-time es más caro porque requiere un servidor prendido siempre, y las fallas son más difíciles de reejecutar. Se recomienda partir con batch y pasar luego a real-time. Se anticipan herramientas (Airflow, Kubeflow, Vertex AI, Pub/Sub, Kubernetes) y estrategias de deployment (canary, blue-green).
• 07:37
  Caso de ejemplo batch y real-timeCaso batch: predicción diaria de ocupación de vuelos a 90 días para un dashboard interno. Caso real-time: predicción de atraso de vuelos consultada desde la app, con latencia menor a 100 ms y miles de requests simultáneos.
• 09:43
  StreamingStreaming es tiempo real pero continuo, como un flujo constante de datos (por ejemplo, la transmisión en Twitch y YouTube). Si se pierden datos, a veces se acepta el vacío para no quedar atrás.
• 11:15
  Arquitectura general comúnSe parte de datos para entrenar un modelo que sirve para inferencia (predicción, clusterización, etc.), ejecutable en batch o en tiempo real.
• 11:45
  Características de proceso batchProcesa bloques con alto throughput. La latencia puede ser de minutos, horas o días. Es de bajo costo porque el servidor se prende solo al ejecutar. Es ideal para reportes y planificación.
• 13:27
  Características de real-timeProcesa por request, con baja latencia (milisegundos) y bajo throughput. Se puede mezclar con batch agrupando unas 10 o 20 requests para aprovechar las operaciones matriciales. Se define el SLA (service level agreement). Tiene mayor costo por disponibilidad constante.
• 16:17
  Características de streamingEs un proceso por eventos constantes, con latencia relativamente baja. Si algo falla, hay que reprocesar, a veces con copias del servidor. Ejemplo: cámaras en el aeropuerto que cuentan personas y escriben en una base de datos.
• 18:10
  Consumo de cómputo y memoria en distintos casosBatch necesita más RAM; real-time necesita más velocidad de CPU o GPU. Se explican el escalamiento vertical (más capacidad por servidor) y el horizontal (más copias), con sus límites. El horizontal agrega complejidad y costo de separar y juntar los datos.
• 22:35
  ComparaciónLatencia alta en batch y baja en real-time. Batch tiene complejidad baja (incluso un cron) y real-time y streaming mayor. Batch se usa para BI y reportes; real-time para APIs y apps de cliente; streaming para eventos y sensores.
• 24:54
  Arquitectura batch y herramientas útilesFlujo con tabla en BigQuery, Airflow como orquestador de DAGs, feature engineering, entrenamiento y model registry. El entrenamiento se rehace cuando el modelo se degrada; la predicción corre aparte y guarda su output. Herramientas: Cloud Storage, Airflow/Cloud Composer, Kubeflow Pipelines (componentes en Docker), Vertex AI Pipelines, Vertex Model Registry y MLflow. Se puede simplificar según el objetivo.
• 32:20
  Problemas típicos de batchReejecutar tras una falla cuando hay dependencia entre días. Dependencias entre DAGs de otras áreas, que se resuelven validando los datos de entrada antes de ejecutar. Datos desactualizados y costo de recomputación. La latencia importa según el margen de reintentos: un proceso de 11 horas diario tiene pocos intentos.
• 36:03
  Buenas prácticas en batchIdempotencia y reproducibilidad. Particionar datos por mes o en archivos Parquet. Reintentos automáticos y orquestación declarativa con DAGs. Versionar datasets de entrada y modelos. Probar mecanismos de alerta en desarrollo y staging antes de producción.
• 46:03
  MemesSe comentan memes: la cadena de mando que termina en un agente de IA, el uso de Claude para resumir una carpeta de archivos y generar diagramas Mermaid, y una foto de los CEOs de OpenAI y Anthropic sin tomarse las manos en una cumbre. También el meme del modelo con 99% de precisión según el junior versus el senior.
• 53:24
  Arquitectura real-time y herramientas útilesFlujo: app, API Gateway, servidor en Cloud Run o GKE (Kubernetes), endpoint de Vertex, predicción y logs. Kubernetes es overkill para batch. El API Gateway es una capa de seguridad y control de acceso. Se discute el model promotion (champion/challenger), el shadow deployment, CI/CD con GitHub Actions y las spot instances para batch.
• 01:12:49
  LatenciaLa latencia total se descompone en red, balanceador, código de la API, modelo, postproceso y respuesta. Se puede reducir con servidores en distintas regiones, un CDN (CloudFront) y modelos más simples. Se discuten las regiones de AWS y que no todos los servicios están en todas.
• 01:25:18
  Otros problemas comunesCold start (se mitiga con warm start, más caro), serialización lenta, modelos pesados (cuantización), colapso de red y logging excesivo.
• 01:28:24
  Técnicas para optimizar procesamiento en tiempo realSerialización rápida con protobuf, arranque rápido de máquinas, cacheo de features y batching de requests como mezcla de batch y real-time.
• 01:29:35
  Throttling, rate limiting y backpressureThrottling limita las requests del sistema completo; rate limiting impone reglas por usuario (ejemplo: bloqueos en scraping); backpressure envía señales hacia atrás para detener el procesamiento hasta liberar capacidad.
• 01:34:04
  Más problemas típicos y solucionesAPI saturada, latencia creciente y timeouts en cascada; se responde "servicio no disponible" de inmediato (circuit breaker). Pub/Sub desacopla publicadores y suscriptores por tópico. Load balancing inteligente y autoscaling horizontal (no sirve ante picos). Kubernetes mantiene el número de pods deseado.
• 01:39:46
  Estrategias de deploymentShadow (duplica el tráfico, caro), rolling (reemplazo progresivo), blue/green (cambio de 100% del tráfico) y canary (1%, 10%, 20%, 50%, 80%, 100% para limitar el blast radius).
• 01:42:20
  Otros temas relevantesObservabilidad: métricas, traces y monitoreo de drift para alertar y reentrenar.
• 01:42:40
  CierreLa arquitectura real-time es similar a la anterior, con componentes extra para la ejecución del modelo. Se debate si el HTML presentado cuenta como slides y se anuncia que el próximo episodio es la parte 4 de arquitectura de software. Se invita al Discord.

Palabras clave