Arquitectura
Flujo de datos
Kappa, capas bronce, plata y oro, y el camino de cada lectura por Kafka hasta la pantalla.
Kappa, no Lambda
| Lambda | Kappa | INDUXA | |
|---|---|---|---|
| Caminos del dato | Dos: uno en flujo (rápido) y uno por lotes que recalcula todo | Uno solo: el flujo | Uno solo: MQTT o HTTPS → Kafka → telemetría → base |
| Recalcular la historia | Lo hace la capa por lotes | Se vuelve a leer el registro de Kafka | Kafka guarda la cruda 7 días; los agregados atrasados se recalculan solos |
| Mantenimiento | La lógica se escribe dos veces | Una sola lógica | Una sola lógica, en la telemetría |
Los reportes, la disponibilidad y las predicciones no son una capa por lotes: son cálculos programados que leen los datos ya guardados, y sus resultados vuelven a entrar como lecturas por el mismo flujo.
Capas de datos: bronce, plata y oro
Fuentes
Equipos
MQTT
Gateways
Agro · PLC
Agente Desk
PCs
Agro Campo
app
Conectores
John Deere · HTTPS
Bronce
dato crudo
- El mensaje tal como llegó
- Sin validar ni traducir
- Si la base se detiene, espera aquí
Kafka · telemetria.crudo
Dura: 7 días
Plata
dato limpio
- Una lectura por tag, con empresa y sede
- Valida el contrato y la hora
- Aplica escala y unidad
- Descarta duplicados
- Tags nuevos: «por confirmar»
Kafka · telemetria.lecturas → lecturas_3m · _6m · _12m
Dura: 3, 6 o 12 meses (plan)
Oro
dato de negocio
- Agregados de 1 min, 1 h y 1 día
- Último valor y última posición
- Alertas, disponibilidad, horas de máquina
- Predicciones (ML) como tags
TimescaleDB · agregados y tablas de negocio
Dura: 1 h y 1 día: 5 años
Uso
En vivo
tiempo real
BI y reportes
tableros · PDF · Excel
ML
predicciones
Chat IA
consultas
API pública
Power BI · webhooks
CALIDAD DEL DATO→
Datos maestrosempresas · sedes · dispositivos · tags · personas · lotes · reglas · planes de mantenimiento — en PostgreSQL, por empresa (RLS). Le dan sentido a cada lectura en la capa plata.| Capa | Dónde vive | Qué tiene | Cuánto dura |
|---|---|---|---|
| Bronce (cruda) | Kafka, telemetria.crudo | El mensaje tal como llegó, de cualquier fuente | 7 días |
| Plata (limpia) | Kafka telemetria.lecturas y telemetria.posiciones → tablas lecturas_3m, _6m o _12m | Una lectura por tag, con empresa, sede, unidad y hora; sin duplicados | 3, 6 o 12 meses, según el plan de la empresa |
| Oro (negocio) | TimescaleDB y tablas de negocio | Agregados de 1 min, 1 h y 1 día; último valor y última posición; alertas, disponibilidad, horas de máquina, predicciones | 1 min: 3 meses · 1 h y 1 día: 5 años |
| Datos maestros | Esquemas de negocio en PostgreSQL | Empresas, sedes, dispositivos, tags, personas, lotes, reglas | Permanente |
Qué cuida la calidad en cada paso:
- El contrato del mensaje (versión 1) se valida: si no cumple, va a
telemetria.errorespara revisión. - La hora la pone el equipo. Si falta o es absurda, se usa la hora de llegada y la lectura se marca con calidad baja.
- Los duplicados se descartan por el
iddel mensaje (24 horas) y por la pareja tag y hora. - Cada clave nueva crea un tag por confirmar: sus datos se guardan desde el primer momento y alguien lo confirma o lo descarta en la ficha del dispositivo.
- La escala y la unidad del tag se aplican al normalizar.
El recorrido por Kafka
| Tópico | Lo escriben | Lo leen | Retención |
|---|---|---|---|
telemetria.crudo | MQTT (puente), ingesta HTTPS, John Deere y los cálculos internos | normalizador | 7 días |
telemetria.lecturas | normalizador | escritor, reglas, API en vivo | 3 días |
telemetria.posiciones | normalizador | escritor, reglas (geocercas), API en vivo | 3 días |
alertas.eventos | reglas | API en vivo | 14 días |
telemetria.errores | normalizador, escritor | revisión | 14 días |
La misma lectura normalizada la usan en paralelo tres consumidores que no se esperan entre sí:
- el escritor, que la guarda en la tabla del plan y actualiza el último valor;
- las reglas, que abren y cierran alertas y disparan los avisos;
- la API en vivo, que la empuja a las pantallas abiertas de esa empresa (como máximo un envío por segundo).
Si la base de datos se detiene, las lecturas esperan en Kafka y el escritor sigue donde quedó.
Después de guardar
- Históricos lee el nivel que corresponde al rango pedido: lecturas sueltas, 1 minuto, 1 hora o 1 día.
- En vivo y los gemelos arrancan con el último valor de cada tag y luego reciben los cambios.
- Reportes (PDF con ECharts y Excel), exportaciones y la API pública leen las capas plata y oro.
- Predicciones leen los históricos y publican sus resultados como tags del mismo equipo.
El detalle de cada fuente está en Entradas de datos.