Présentation

Dans l'environnement commercial actuel, la capacité d'analyser les données à mesure qu'elles arrivent — pas quelques heures plus tard — peut signifier la différence entre saisir une opportunité et la manquer entièrement. Les tableaux de bord analytiques en temps réel fournissent aux équipes opérationnelles, aux cadres et aux analystes de données des informations constamment mises à jour sur les mesures telles que la santé du système, le comportement des clients, les lectures de capteurs IoT et les transactions financières.

Azure Data Explorer (ADX) est une solution leader conçue spécifiquement pour ces exigences. Il offre des pipelines d'ingestion gérés, un stockage colonnel optimisé pour les séries chronologiques et les données de log, et le puissant Kusto Query Language (KQL) pour transformer des événements bruts en visualisations actionnables. Cet article fournit un guide pratique et pratique pour construire un tableau de bord analytique en temps réel de production à l'aide d'Azure Data Explorer et l'intégrer à Power BI pour des rapports interactifs. Vous apprendrez à configurer un cluster ADX, à diffuser des données de sources comme Event Hubs, à écrire des requêtes KQL efficaces, à se connecter à Power BI et à optimiser le pipeline entier pour des mises à jour à faible latence.

Qu'est-ce que Azure Data Explorer?

Azure Data Explorer est un service d'analyse de données massives entièrement géré et performant qui excelle dans l'analyse interactive de volumes importants de données structurées et semi-structurées. Il est conçu pour des scénarios tels que surveillance de l'application[, télémétrieIoT[, analyse de log de sécurité et intelligence d'entreprise[ où les données arrivent en continu et les requêtes doivent retourner les résultats en secondes ou même en millisecondes.

Les principales caractéristiques qui rendent ADX idéal pour les tableaux de bord en temps réel incluent:

  • Ingestion streaming: Ingérer les données d'Azure Event Hubs, IoT Hub, Kafka et d'autres sources de streaming avec des latences aussi faibles que quelques secondes.
  • Stockage et indexation des données : Les données sont compressées et indexées à l'aide d'index inversés et d'index B-tree, permettant une numérisation et un filtrage rapides.
  • Kusto Query Language (KQL):[ Un langage en lecture seule, semblable à SQL avec des opérateurs intégrés pour l'analyse de séries temporelles, les fonctions statistiques, les jointures et les regroupements.
  • Intégration Native Power BI:[ Le mode DirectQuery et le mode import permettent aux tableaux de bord de se rafraîchir automatiquement ou en temps quasi réel.
  • Auto-scalidation et gestion des coûts:[ Les clusters peuvent calculer et stocker de façon indépendante, et vous pouvez définir une politique de cache pour garder les données chaudes en mémoire pour les requêtes rapides.

ADX est souvent comparé à des entrepôts de données traditionnels comme Azure Synapse ou Amazon Redshift, mais il est optimisé pour forte cardinalité (p. ex., des millions de dispositifs uniques) et charges de travail [ qui sont typiques des journaux et des séries chronologiques. Pour une compréhension plus approfondie, reportez-vous à la documentation officielle d'Azure Data Explorer.

Mise en place de l'environnement

Création d'un cluster Azure Data Explorer

Pour commencer, connectez-vous au portail et créez une nouvelle ressource de type "Cluster d'explorateur de données d'Azure". Choisissez un abonnement, un groupe de ressources et une région qui s'alignent avec vos sources de données (de préférence la même région pour minimiser la latence).

  • Dev/Test: Dev(Standard D13 v2) ou Standard D14 v2 pour les petites charges de travail.
  • Production:[ Standard L8s v2, Standard L16s v2, ou la nouvelle famille de UGS avec des SSD NVMe locaux (p. ex. Standard L8s v3) pour un débit élevé.
  • Haute convergence:[ Groupes avec de multiples instances qui peuvent auto-écheller en fonction de la charge de CPU ou d'ingestion.

Une fois le cluster déployé, créez une base de données à l'intérieur de celui-ci. Utilisez les politiques de conservation et de cache par défaut au départ. Pour les tableaux de bord en temps réel, vous pouvez définir une politique de cache de plusieurs jours (ou semaines) afin que toutes les données récentes soient servies à partir de la mémoire. La politique de conservation devrait être suffisamment longue pour couvrir vos besoins en matière de rapports (p. ex., 30 à 90 jours).

Configuration des sources d'ingestion de données

Les tableaux de bord en temps réel dépendent des données de streaming. ADX prend en charge plusieurs approches d'ingestion:

  • Event Hubs: Les plus courants pour les journaux et la télémétrie. Créez un espace de noms de Hubs d'événements et un hub, puis configurez une connexion de données dans ADX qui masquart les événements JSON ou Avro à un schéma de table.
  • IoT Hub: Pour les appareils IoT, IoT Hub fournit l'authentification des appareils et le routage des messages directement vers ADX.
  • Kafka: Utilisez le connecteur ADX Kafka pour apporter des flux d'Apache Kafka ou Confluent.
  • Blob Storage/Data Lake:[ Pour ingestion par lots ou en temps quasi réel à partir de fichiers Parquet/CSV stockés dans Azure Blob ou ADLS Gen2.

Lors de la configuration des Hubs Event, assurez-vous que le nombre de partitions corresponde aux besoins de votre débit. ADX peut ingérer simultanément des données de plusieurs partitions. Pour chaque connexion de données, vous définirez une table et une mapping[ qui transforme les champs JSON en colonnes ADX. La cartographie peut également gérer les conversions de type de données (par exemple, les timestamps d'époque à datetime).

ingérer des données en temps réel

Création de tableaux et de cartes

Avant d'ingérer, créez la table de destination dans votre base de données ADX en utilisant KQL. Par exemple, une table pour les journaux d'erreurs d'applications pourrait ressembler à :

.create table AppLogs (Timestamp: datetime, Level: string, Service: string, Message: string, CorrelationId: string)

Puis créez une cartographie d'ingestion pour le format utilisé par votre source de streaming. Pour JSON à partir de Event Hubs, la commande est:

.create table AppLogs ingestion json mapping 'AppLogsJsonMapping' '[{"column":"Timestamp","datatype":"datetime","properties":{"path":"$.timestamp"}},{"column":"Level","datatype":"string","properties":{"path":"$.level"}},{"column":"Service","datatype":"string","properties":{"path":"$.service"}},{"column":"Message","datatype":"string","properties":{"path":"$.message"}},{"column":"CorrelationId","datatype":"string","properties":{"path":"$.correlationId"}}]'

Ces mappages indiquent à ADX comment extraire des champs de chaque événement.

Configuration de la connexion des Hubs d'Event

Dans le portail Azure, naviguez vers votre base de données ADX, sélectionnez « Connexions de données » et ajoutez une connexion Event Hubs. Fournissez l'espace de noms Event Hubs, le nom du hub, le groupe de consommateurs (utilisez un groupe de consommateurs dédié pour ADX pour éviter les conflits), et le nom de la table. Spécifiez la référence de mappage que vous avez créée. ADX va automatiquement commencer à consommer des événements et les rendre disponibles pour les requêtes en quelques secondes.

Pour les scénarios à haut débit, envisager d'utiliser l'ingestion en continu (facilable sur le groupe) au lieu de l'ingestion par lot. L'ingestion en continu écrit des données directement dans les limites des colonnes sans mise en scène intermédiaire, fournissant des latences sous 10 secondes. Pour la plupart des tableaux de bord en temps réel, c'est le mode préféré.

Interroger avec Kusto Query Language (KQL)

Le cœur de tout tableau de bord ADX est les requêtes KQL qui regroupent et filtrent les données en temps réel. Ci-dessous sont les modèles que vous utiliserez fréquemment.

Filtrage et regroupement de base

Pour compter les erreurs par service au cours de la dernière heure dans des bacs d'une minute :

AppLogs
| where Timestamp > ago(1h)
| where Level == "Error"
| summarize ErrorCount = count() by Service, bin(Timestamp, 1m)
| order by Timestamp asc

Cela renvoie une série chronologique prête pour un graphique en ligne.

Calculs du pourcentage

Pour les mesures de latence, vous pourriez vouloir P50, P95 et P99:

ServiceLatency
| where Timestamp > ago(30m)
| summarize P50 = percentile(LatencyMs, 50), P95 = percentile(LatencyMs, 95), P99 = percentile(LatencyMs, 99) by Service

Rejoindre les données de référence

Souvent, les tableaux de bord doivent enrichir les événements avec des données de recherche statiques (p. ex., les emplacements des appareils). ADX prend en charge les jointures légères.

Telemetry
| where Timestamp > ago(15m)
| lookup Devices on DeviceId
| project Timestamp, DeviceId, Region, MetricValue

Pour les tableaux de référence importants, envisager de les matérialiser en utilisant des vues matérialisées[ ou de les stocker dans un groupe distinct avec une politique de cache appropriée.

Fonctions de la série chronologique

ADX comprend des opérations de série chronologique puissantes comme pour la détection d'anomalies, pour la saisonnalité et pour l'analyse de fréquence. Exemple : détecter des anomalies dans le nombre d'erreurs HTTP :

AppLogs
| where Timestamp > ago(2h)
| make-series ErrorCount = count() on Timestamp step 1m
| extend anomalies = series_decompose(ErrorCount, -1, 2.0, 'ok')
| mv-expand Timestamp, ErrorCount, anomalies
| where anomalies[2] < 0 or anomalies[2] > 0

Ces requêtes sont avancées mais peuvent alimenter directement les tableaux de bord.

Pour une référence complète, voir la documentation Kusto Query Language.

Construction du tableau de bord Power BI

Connexion de la puissance BI à ADX

Azure Data Explorer intègre avec Power BI le connecteur d'Azure Data Explorer. Pour se connecter :

  1. Ouvrez le bureau Power BI, cliquez sur "Get Data" > "Plus..."
  2. Rechercher "Azure Data Explorer" et sélectionner le connecteur.
  3. Saisissez votre URL de cluster (p. ex. ) et le nom de la base de données.
  4. Choisissez entre Import (les données sont extraites dans Power BI et mises à jour périodiquement) ou DirectQuery (les requêtes sont envoyées à ADX sur chaque interaction). Pour les tableaux de bord en temps réel, utilisez DirectQuery. Cela garantit que chaque filtre, trancheur et visuel déclenche une requête KQL contre les données les plus récentes.

Écriture de requêtes KQL dans Power BI

Dans la boîte de dialogue de connecteurs, vous pouvez taper une requête KQL directement. Conservez les requêtes ciblées et assurez-vous qu'elles renvoient des données tabulaires que Power BI peut modéliser. Par exemple, pour créer un jeu de données avec des nombres d'erreurs par service par minute pour la dernière heure :

AppLogs
| where Timestamp > ago(1h)
| summarize ErrorCount = count() by Service, bin(Timestamp, 1m)

Après avoir chargé la requête, utilisez la modélisation de Power BI pour définir les mesures, les hiérarchies et les relations si vous avez plusieurs requêtes. Évitez de charger des logs complets bruts – totalisez autant que possible dans KQL.

Configuration des rafraîchis en temps réel

En mode DirectQuery, les visuels re-demandent automatiquement ADX lorsque les utilisateurs interagissent avec le rapport (par exemple, en changeant un trancheur de date). Cependant, pour que le tableau de bord soit réajusté automatiquement sans interaction utilisateur, vous devez configurer la fonction [FLT:]][FLT:]]]][FIX][FIX][FIX][FIX][FIX][FIX][FIX][

  1. Publier le rapport à un Espace de travail d'application avec une capacité Premium (ou PPU).
  2. Dans les paramètres du rapport, sous «Scheduled rafraîchissement», définissez l'intervalle de rafraîchissement DirectQuery – pour les tableaux de bord en temps réel, utilisez 1 ou 2 minutes.
  3. Sinon, utilisez la fonction (prévisualiser) qui rafraîchit la page à un intervalle fixe (par exemple toutes les 30 secondes).

Gardez à l'esprit que chaque auto-refraîchissement exécutera toutes les requêtes KQL sous-jacentes aux visuels. Optimisez vos requêtes pour revenir rapidement (moins de 5 secondes) pour éviter les attentes de l'utilisateur et la charge excessive de cluster.

Meilleures pratiques de visualisation

  • Utiliser des images de cartes[ pour les ICR (p. ex., erreurs totales dans les 5 dernières minutes).
  • ] Graphiques linéaires pour les tendances des séries chronologiques.
  • pour les ventilations top-N (p. ex., les services en panne de pointe).
  • Cartes géospatiales si vous avez des données de localisation.
  • Gauges pour montrer des progrès vers des seuils.

Parce que DirectQuery envoie des requêtes sur chaque interaction, évitez d'utiliser des visuels personnalisés qui génèrent de nombreuses requêtes.

Optimisation des performances pour les requêtes en temps réel

Groupement et réglage de l'indice

ADX crée et fusionne automatiquement des étendues (shards de données) au fil du temps. Cependant, vous pouvez influencer les performances par:

  • Choisir une politique de groupe qui équilibre le débit d'ingestion élevé avec la concordance des requêtes. Pour les tableaux de bord en temps réel avec de nombreuses requêtes visuelles, extenser (ajouter des instances) plutôt que de les étendre.
  • Définir la politique de cache appropriée sur la base de données ou les tables. Par exemple, pour garder les 7 derniers jours en cache chaud:
  • En utilisant vues matérialisées[ pour les résultats pré-agrégés qui mettent à jour progressivement. Une vue matérialisée peut calculer des résumés horaires ou quotidiens, qui servent ensuite instantanément des tableaux de bord de haut niveau.

Conseils pour l'optimisation des requêtes

  • Filter tôt: Utiliser des clauses sur la colonne de l'horodatage et des dimensions de haute cardinalité pour réduire les données numérisées.
  • Minimize rejoint: Si possible, dénormaliser les données pendant l'ingestion de sorte que les données de référence soient déjà intégrées dans les événements.
  • Éviter dans les projets:[ Lister explicitement les colonnes nécessaires pour réduire la bande passante et la mémoire.
  • pour les grandes opérations pour distribuer l'agrégation entre les nœuds.
  • Limiter les résultats:[ Utilisez toujours , ou dans les requêtes de développement.Dans Power BI, les visuels ont généralement leurs propres filtres top-N, mais les ajoutent aussi dans KQL.

Surveillance de la santé des groupes

Azure Data Explorer fournit des journaux de diagnostic et des métriques intégrés par l'intermédiaire d'Azure Monitor.

  • Latence d'ingestion:[ Temps moyen entre la création d'un événement et la possibilité d'être interrogé.
  • Latence de la demande:[ Délais d'exécution des P50 et P99.
  • CPU et utilisation de la mémoire:[ Si vous êtes constamment élevé, envisagez de l'échelle.
  • Taux d'ingestion:[ Assurez-vous que vous n'êtes pas en train de froisser; divisez les flux en plus de partitions si nécessaire.

Configurez des alertes dans Azure Monitor pour les cas où les latences de la requête dépassent un seuil (p. ex. P99 > 10 secondes) afin de pouvoir vous mettre en ligne de façon proactive.

Alerte et automatisation en temps réel

Un tableau de bord en temps réel est le plus puissant lorsqu'il est associé à des réponses automatisées. Azure Data Explorer offre plusieurs points d'intégration:

Alertes de surveillance Azure de ADX

Vous pouvez créer des requêtes programmées[ dans ADX qui fonctionnent sur un horaire (par exemple, toutes les 5 minutes) et envoyer les résultats à Azure Monitor. Ensuite, définir des règles d'alerte qui font feu lorsque les conditions sont remplies (par exemple, compte d'erreur > 100 dans une fenêtre de 5 minutes). Cela permet des actions comme :

  • Envoi d'un courriel ou d'un SMS par l'intermédiaire de groupes d'action.
  • Déclencher les applications logiques Azure pour exécuter des workflows (par exemple redémarrer un service, créer un ticket incident).
  • Appeler des webhooks pour informer les systèmes externes.

Applications logiques Azure et Microsoft Power Automate

Utilisez les applications logiques avec le connecteur "Exécuter Kusto Query" pour récupérer les données de ADX et ensuite agir. Par exemple, si une requête détecte une pointe d'utilisation du processeur dans les VMs, une application logique peut déclencher un roundbook Azure Automation pour éteindre le VMSS. Ceci ferme la boucle entre la surveillance et la restauration.

Stream Analytics et ADX comme Sink

Pour les alertes de latence encore plus faibles, faites passer les données en streaming par Azure Stream Analytics, qui peut appliquer des fenêtres temporelles et pousser les événements alerte simultanément à ADX (pour analyse historique) et à un abonné Event Hubs pour alerter immédiatement.

Cas d'utilisation et exemples du monde réel

  • DevOps Observability Dashboard: Agrégez les journaux, les métriques et les traces des microservices à travers les grappes Kubernetes. Les ingérants ADX des Hubs d'événements Fluentd/Logstash Azure, et le tableau de bord Power BI montre les taux de demande, les réponses d'erreurs et les latences de queue.
  • IoT Fleet Monitoring:[ Connectez IoT Hub à ADX pour la télémétrie du véhicule (emplacement, vitesse, état de la batterie).
  • Détection de fraude financière :[ Rationaliser les transactions par l'intermédiaire des Hubs d'événements dans ADX. Les tableaux de bord indiquent les volumes de transactions par région et les scores d'anomalie; les alertes déclenchent des listes de blocs lorsque les seuils sont dépassés.
  • Clickstream Analysis:[ L'activité de l'utilisateur des sites Web est ingérée dans ADX. Le tableau de bord suit les utilisateurs actifs, les vues de page par seconde et les entonnoirs de conversion mis à jour chaque minute.

Conclusion

En tirant parti de l'ingestion de flux ADX, des puissantes capacités de séries chronologiques de KQL et des connexions DirectQuery dans Power BI, vous pouvez créer des tableaux de bord qui rafraîchissent toutes les quelques secondes et gèrent les téraoctets de données entrantes. La clé du succès réside dans la planification de la capacité, la conception réfléchie des requêtes et le suivi continu des performances.

Comme les besoins en temps réel de votre organisation augmentent, l'élasticité d'ADX garantit que votre tableau de bord s'équilibre sans compromettre la vitesse. Pour plus d'informations, explorez le guide d'ingestion ADX Event Hubs et la documentation de connecteur .