← Volver a Arquitectura Cloud · Análisis de datos

Azure Data
Explorer

Motor columnar de series temporales que almacena la telemetría de toda la flota y responde consultas KQL sobre terabytes de datos de vibración en menos de dos segundos.

Qué es

Azure Data Explorer (ADX), basado en el motor Kusto desarrollado internamente por Microsoft, es un servicio de análisis de datos de series temporales diseñado para ingestión masiva y consultas analíticas interactivas. Su arquitectura de almacenamiento columnar con compresión agresiva (LZ4 + codificación Huffman) lo hace especialmente eficiente para datos IoT donde los valores de una misma métrica tienen alta correlación temporal.

ADX no es una base de datos transaccional: está optimizado para el patrón de acceso «escribe una vez, lee muchas veces» típico de telemetría industrial. Las consultas se expresan en KQL (Kusto Query Language), un lenguaje declarativo de pipe-based con primitivas especializadas para series temporales.

Rol en IN-SIGHT

  • Almacén central de telemetría: Recibe la telemetría de vibración, temperatura y puertas de toda la flota desde IoT Hub vía Event Hub. Cada registro incluye vehicle-id, pod-id, timestamp (precisión nanosegundos), métrica y valor.
  • Cálculo de métricas de salud: Queries programadas calculan el RUL estimado (Remaining Useful Life), índices de deterioro de rodamientos y percentiles de energía de vibración por subsistema.
  • Comparación con Golden Run: El EKF cloud consulta ADX para obtener el baseline del vehículo y calcular la innovación (diferencia entre estado predicho y medido).
  • Alimentación del portal: Las queries KQL son la fuente de datos del portal de alertas y los dashboards técnicos en tiempo real vía API REST nativa de ADX.
  • Retención histórica: Los datos históricos se retienen en el tier «hot» (SSD, acceso < 1 s) durante 90 días y en el tier «cold» (Azure Blob Storage) indefinidamente para auditoría y re-entrenamiento de modelos.
Ejemplo de query KQL: Detección de tendencia de deterioro de rodamiento en los últimos 7 días para un vehículo concreto, con moving average de 1 hora. 
telemetry
| where vehicle_id == "TMB-5042"
  and metric == "bearing_rms"
  and timestamp > ago(7d)
| summarize avg_rms = avg(value)
    by bin(timestamp, 1h), pod_id
| order by timestamp asc
| extend trend = series_fit_line_dynamic(
    avg_rms, timestamp)

Arquitectura interna

ADX organiza los datos en extents (shards) columnar inmutables de ~1 GB comprimido. Cuando se ingiere un nuevo lote de telemetría, el engine crea nuevos extents y los indexa; periódicamente los combina (merge) para optimizar el rendimiento de consulta.

El índice de cada extent incluye el rango de timestamps y los valores min/max de cada columna, lo que permite al query planner descartar extents enteros sin leerlos cuando la query filtra por rango temporal o por vehículo específico.