Como funciona

La plataforma sigue una idea sencilla: un mismo dato recorre todo el sistema, de la lectura del sensor al dashboard y al almacen analitico, sin perder su identidad por el camino. Esta pagina recorre ese viaje de principio a fin, capa por capa.

El flujo de un dato, de principio a fin

Una lectura de sensor entra por la API de ingesta y sale, minutos despues, convertida en agregados, anomalias detectadas y filas en un almacen analitico. El siguiente diagrama muestra ese camino feliz completo, desde la peticion HTTP hasta la escritura en la base de datos.

1. Ingesta

Las lecturas llegan en lotes a una API HTTP construida con FastAPI. La ingesta valida y autentica la peticion, y aplica una estrategia de escritura dual con Kafka primero: la lectura se publica en el bus de eventos antes de nada, de modo que el streaming es la fuente de verdad y la persistencia no bloquea la aceptacion del dato. Cada peticion recibe un identificador de correlacion que la acompanara durante todo el recorrido.

2. Streaming

Kafka actua como columna vertebral del sistema, desacoplando a productores de consumidores mediante topics. Sobre el, un conjunto de agentes de streaming escritos con Faust procesan el flujo en continuo: un agente limpia las lecturas crudas (validacion, normalizacion, descarte de lo invalido a una cola de errores), otro las agrega en ventanas temporales de un minuto, y otro puntua anomalias en micro-lotes. El procesamiento es incremental: los datos se transforman segun fluyen, no en grandes cargas nocturnas.

3. Almacenamiento

El resultado se persiste en TimescaleDB, una base de datos time-series construida sobre PostgreSQL. Conviven las lecturas crudas, las limpias, los agregados por minuto, las anomalias y las predicciones. Una misma clave de idempotencia por sensor e instante hace que streaming y procesos batch converjan en las mismas filas sin duplicar datos, de modo que ambos caminos son reconciliables.

4. Machine Learning

Sobre los datos limpios operan los modelos de ML. La deteccion de anomalias identifica lecturas que se desvian del comportamiento normal de cada sensor, y el forecasting predice la evolucion futura de cada serie. El ciclo de vida de los modelos (experimentos, metricas, versiones) se registra con MLflow, y los reentrenamientos se orquestan de forma periodica.

5. Export analitico

Para el analisis a gran escala, los datos limpios se exportan de forma incremental a un almacen analitico: ficheros Parquet en Google Cloud Storage que se cargan en BigQuery. Esto habilita consultas analiticas masivas y separa la carga transaccional del pipeline de la carga analitica. Este patron lakehouse se muestra a continuacion.

Observabilidad y trazabilidad

Todo el sistema esta instrumentado. Prometheus recoge metricas, Grafana las visualiza en dashboards (incluidos los del propio invernadero) y Loki centraliza los logs. La trazabilidad es de extremo a extremo: el identificador de correlacion que se asigna en la ingesta entra como cabecera HTTP, viaja como cabecera de Kafka y se re-vincula en los logs del streaming, de forma que un mismo lote puede seguirse por los logs desde la peticion original hasta su escritura final en la base de datos.

Orquestacion y despliegue

Los trabajos periodicos (reentrenamientos, limpiezas batch, exports, chequeos de salud) los coordina Airflow mediante DAGs programados. La plataforma se empaqueta como servicios sobre Kubernetes: los mismos manifiestos corren en un lab local con k3s (maquinas virtuales) y, bajo demanda, en un cluster gestionado GKE en Google Cloud. El entorno cloud se levanta y se apaga cuando se necesita, y es ahi donde vive la capa analitica de GCS y BigQuery, que requiere servicios propios de Google Cloud.

El invernadero: de donde vienen los datos

Para alimentar el sistema con datos realistas sin depender de sensores fisicos, el generador de trafico es un gemelo digital de un invernadero. No es ruido aleatorio: es un simulador con estado que modela fisica (temperatura, humedad, luz), control en lazo cerrado (actuadores que reaccionan a las condiciones) y fallos inyectables (sensores que derivan, se atascan o dejan de responder). Gracias a ello, las anomalias que detecta el ML corresponden a situaciones plausibles y el pipeline se ejercita contra escenarios cercanos a los de un despliegue real.

Para profundizar

• Arquitectura por servicio — el detalle de cada componente.
• Decisiones (ADRs) — por que se eligio cada tecnologia.