Los equipos de ciencia de datos ya no esperan el trabajo nocturno. Los modelos se están desplegando en flujos de producción donde una característica desactualizada equivale a una decisión incorrecta, y una decisión incorrecta cuesta dinero, confianza o, en algunos sectores, posición regulatoria. La pregunta de si construir pipelines de ciencia de datos en tiempo real sobre event streaming o seguir ejecutando procesos batch ya no es puramente académica: determina tus costes de infraestructura, tu complejidad operativa y la latencia que realmente puedes garantizar al negocio.
La respuesta no es “el streaming siempre gana”. La realidad es más matizada, y equivocarse en la arquitectura en cualquier dirección resulta caro. Aquí te explicamos cómo analizarlo con honestidad.
Qué te cuestan realmente los pipelines batch
El procesamiento batch tiene una reputación bien ganada por su simplicidad. Programas un trabajo, se ejecuta y obtienes resultados. La depuración es sencilla porque los datos son estáticos en el momento de la ejecución, y el cómputo puede programarse en ventanas de baja actividad. Para el entrenamiento de modelos sobre datos históricos, batch sigue siendo la opción predeterminada correcta.
El problema aparece cuando el negocio le pide al modelo que responda a algo que está ocurriendo ahora mismo. Un sistema de detección de fraude que puntúa las transacciones de ayer en bloque ya ha dejado pasar las fraudulentas. Un motor de recomendaciones que actualiza características cada cuatro horas sirve sugerencias basadas en quién era el usuario hace cuatro horas. La brecha entre el momento en que ocurre un evento y el momento en que tu modelo lo conoce se denomina latencia de características, y en aplicaciones en tiempo real es el principal factor de degradación del modelo en producción.
Las arquitecturas batch también acumulan costes ocultos que suelen subestimarse: grandes picos de cómputo en el momento de ejecución, almacenamiento para salidas intermedias y la carga de ingeniería de la lógica de relleno cuando los datos upstream llegan tarde. Cuando esos costes se contabilizan con honestidad, la economía del streaming resulta considerablemente más competitiva de lo que sugiere la sabiduría convencional.
Dónde justifica su complejidad la arquitectura de event streaming
El event streaming se convierte en la columna vertebral adecuada cuando el modelo necesita actuar sobre el estado actual del mundo, no sobre una instantánea reciente. Los casos de uso canónicos están bien establecidos: detección de fraude, precios dinámicos, personalización en tiempo real y monitorización operativa. En cada uno de ellos, el valor de una predicción se degrada bruscamente con la latencia. Una señal de fraude entregada en 150 milisegundos puede bloquear una transacción; la misma señal entregada en 15 minutos es una autopsia.
La ingeniería de características es donde el event streaming justifica su presupuesto de complejidad: las agregaciones por ventana temporal, el enriquecimiento de eventos con datos de entidades en vivo y las métricas derivadas calculadas de forma continua son las transformaciones que convierten eventos brutos en características listas para ML con una frescura de menos de un segundo.
Apache Kafka se ha convertido en el estándar de facto para esta capa porque ofrece almacenamiento de eventos duradero y reproducible con el rendimiento necesario para gestionar flujos de eventos de alta cardinalidad. La reproducibilidad importa específicamente para ML: necesitas reconstruir el estado exacto de las características que vio el modelo en el momento de la predicción para la depuración, el reentrenamiento y la auditoría. Un flujo que no puedes reproducir es un flujo en el que no puedes confiar en producción.
Los motores de procesamiento como Apache Flink y Spark Structured Streaming se sitúan aguas abajo del broker y gestionan transformaciones con estado: calcular el número de transacciones de un usuario en la última hora, unir un evento de clickstream con un catálogo de productos o derivar un percentil móvil. El modelo de micro-batch de Spark introduce latencias en el rango de más de 100 milisegundos, lo que es suficiente para muchos casos de uso. El procesamiento por tiempo de evento de Flink reduce esa cifra cuando se requiere genuinamente una ejecución estricta por evento. Databricks también ha introducido un modo de ejecución en tiempo real para Spark orientado a latencias consistentes de menos de un segundo sobre la misma superficie de API, algo relevante para los equipos que ya han estandarizado en Spark para el entrenamiento batch.
El problema del doble almacén en la ingeniería de características en tiempo real
Uno de los requisitos arquitectónicos menos comentados de Kafka para machine learning es el patrón de doble almacén. El entrenamiento necesita acceso histórico a las características, habitualmente como archivos Parquet o Delta Lake consultados en batch. El servicio necesita el valor actual de una característica para una entidad dada, recuperado en pocos milisegundos. Son patrones de acceso fundamentalmente distintos, y un único almacén no puede servir bien a ambos.
La solución estándar es un feature store que mantiene un almacén offline para el entrenamiento y un almacén online, habitualmente Redis, Cassandra o ScyllaDB, para el servicio. Plataformas como Feast, Tecton y Hopsworks orquestan el patrón de escritura dual: el procesador de flujo escribe en ambos almacenes simultáneamente, manteniéndolos consistentes. Wix ejecuta este patrón en producción, usando Kafka y Flink conjuntamente para impulsar la personalización en tiempo real a escala. La arquitectura funciona, pero añade superficie operativa: ahora tienes un broker, un procesador de flujo, un almacén online y un almacén offline, cada uno con sus propios modos de fallo.
Cuándo el streaming es la respuesta equivocada
Stream processing frente a batch processing no es un binario donde el streaming siempre es superior. Los sistemas continuos requieren cómputo continuo, lo que implica coste continuo. Requieren una observabilidad más sólida porque los fallos no están aislados a una ventana de trabajo: una unión de enriquecimiento rota corrompe silenciosamente las características de cada evento hasta que alguien lo detecta. La gestión de estado se convierte en una disciplina en sí misma.
Para dashboards, informes de cumplimiento, agregación de logs y entrenamiento de modelos, el micro-batching a intervalos de menos de un minuto es casi siempre suficiente y considerablemente más sencillo de operar. La regla que vale la pena aplicar: si el negocio no puede describir una decisión concreta que se degrada de forma significativa cuando la característica tiene 60 segundos de antigüedad en lugar de 60 milisegundos, probablemente no necesitas un pipeline de streaming completo. El presupuesto de complejidad debe gastarse donde la latencia importa de verdad.
La arquitectura de red y por qué importa para los pipelines en tiempo real
La ingeniería de características en tiempo real es sensible a la latencia de extremo a extremo, no solo dentro del motor de procesamiento. El viaje de ida y vuelta entre tu fuente de eventos, tu broker, tu procesador de flujo, tu almacén de características online y tu endpoint de servicio del modelo se acumula, y ese recorrido está determinado en gran medida por dónde se sitúan esos componentes entre sí y respecto a la red.
Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en todos los sitios. Para los equipos que ejecutan arquitecturas híbridas donde las cargas de trabajo de entrenamiento permanecen en un hyperscaler pero el cómputo de características y el servicio del modelo se ejecutan en infraestructura soberana de la UE, ese peering elimina los saltos de tránsito que de otro modo añadirían decenas de milisegundos a cada consulta de características. En pipelines donde la latencia de extremo a extremo es el requisito del producto, esos milisegundos no son errores de redondeo.
Ejecutar event streaming en infraestructura soberana de la UE también mantiene limpia la cuestión de la residencia de datos. Eventos que fluyen a través de un broker compatible con Kafka alojado dentro de Europa, procesados por procesadores de flujo en cómputo europeo, que escriben características en un almacén online que nunca sale de la jurisdicción europea: eso es una postura de cumplimiento materialmente más sencilla que aquella en la que el flujo de eventos transita por la región europea de un proveedor cloud con sede en Estados Unidos.
Cómo tomar la decisión arquitectónica
El marco práctico es sencillo. Comienza con el requisito de latencia: si el valor de tu modelo se degrada de forma significativa cuando las características tienen más de unos pocos segundos de antigüedad, el streaming está justificado. Si un minuto es aceptable, micro-batch. Si una hora es aceptable, batch. Luego mapea el coste de complejidad frente a la madurez operativa del equipo: un pipeline de streaming mal observado es peor que un pipeline batch que funciona de forma fiable.
Cuando el streaming es la opción correcta, invierte pronto en la arquitectura del feature store. El patrón de doble almacén no es opcional para ML en producción; es el mecanismo que hace que las características de streaming sean utilizables tanto para el entrenamiento como para el servicio sin reconstruir el pipeline dos veces. Elige tu motor de procesamiento en función del objetivo de latencia y tus herramientas existentes, no del aspecto que tenga el diagrama de arquitectura.
El event streaming es una columna vertebral poderosa para los pipelines de ciencia de datos en tiempo real cuando el requisito de latencia es real. El error es tratarlo como una mejora del batch en lugar de como un modelo operativo diferente con costes distintos y modos de fallo distintos. Distinguir correctamente entre ambos hace que la decisión arquitectónica sea considerablemente más clara.
