← Retour à Architecture Cloud · Analyse de données

Azure Data
Explorer

Moteur columnar de séries temporelles qui stocke la télémétrie de toute la flotte et répond à des requêtes KQL sur des téraoctets de données de vibration en moins de deux secondes.

Qu'est-ce que c'est

Azure Data Explorer (ADX), basé sur le moteur Kusto développé en interne par Microsoft, est un service d'analyse de données de séries temporelles conçu pour l'ingestion massive et les requêtes analytiques interactives. Son architecture de stockage columnar à compression agressive (LZ4 + codage Huffman) le rend particulièrement efficace pour les données IoT où les valeurs d'une même métrique ont une forte corrélation temporelle.

ADX n'est pas une base de données transactionnelle : il est optimisé pour le schéma d'accès « écrire une fois, lire plusieurs fois » typique de la télémétrie industrielle. Les requêtes s'expriment en KQL (Kusto Query Language), un langage déclaratif pipe-based doté de primitives spécialisées pour les séries temporelles.

Rôle dans IN-SIGHT

  • Entrepôt central de télémétrie : Il reçoit la télémétrie de vibration, de température et de portes de toute la flotte depuis IoT Hub via Event Hub. Chaque enregistrement comprend vehicle-id, pod-id, timestamp (précision nanoseconde), métrique et valeur.
  • Calcul des métriques de santé : Des requêtes programmées calculent le RUL estimé (Remaining Useful Life), les indices de dégradation des roulements et les percentiles d'énergie de vibration par sous-système.
  • Comparaison avec le Golden Run : L'EKF cloud interroge ADX pour obtenir la référence du véhicule et calculer l'innovation (différence entre état prédit et mesuré).
  • Alimentation du portail : Les requêtes KQL sont la source de données du portail d'alertes et des tableaux de bord techniques en temps réel via l'API REST native d'ADX.
  • Rétention historique : Les données historiques sont conservées dans le tier « hot » (SSD, accès < 1 s) pendant 90 jours et dans le tier « cold » (Azure Blob Storage) indéfiniment pour l'audit et le ré-entraînement des modèles.
Exemple de requête KQL : Détection d'une tendance de dégradation de roulement sur les 7 derniers jours pour un véhicule précis, avec une moyenne glissante d'une heure.
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)

Architecture interne

ADX organise les données en extents (shards) columnar immuables de ~1 Go compressé. Lorsqu'un nouveau lot de télémétrie est ingéré, le moteur crée de nouveaux extents et les indexe ; il les fusionne (merge) périodiquement pour optimiser les performances de requête.

L'index de chaque extent comprend la plage de timestamps et les valeurs min/max de chaque colonne, ce qui permet au query planner d'écarter des extents entiers sans les lire lorsque la requête filtre par plage temporelle ou par véhicule spécifique.