Passer au contenu principal
La fonctionnalité Data Explorer est en préversion publique. Nous prévoyons y apporter des changements continus à mesure que nous recueillons des commentaires
et que nous l’optimisons pour l’utilisation par les clients. Le mode avancé de Data Explorer est conçu pour des requêtes plus complexes et des analyses plus approfondies à l’aide du langage de requête Azure Data Explorer, un langage semblable à SQL optimisé pour l’exploration de données ad hoc. Pour apprendre à écrire des requêtes non techniques, consultez le tutoriel Prise en main du mode de base de Data Explorer.

Création de requêtes personnalisées

Pour commencer à créer vos propres requêtes en mode avancé, il est important de comprendre d’abord la forme des données auxquelles vous accédez.

La table events.all

La table events.all est la destination par défaut de tous les événements entrants. Il s’agit d’une table unique semi-structurée avec des colonnes pour les valeurs courantes, comme l’heure et le nom de l’événement. Vous vous familiariserez rapidement avec la colonne EventData, qui contient la charge utile JSON originale complète et qui est utile dans presque toutes les requêtes. Vous pouvez lire la documentation suivante sur la table events.all.

L’anatomie d’une requête

Une expression de requête commence le plus souvent par le nom de la table. Celui-ci est suivi du délimiteur barre verticale (|). Viennent ensuite un ou plusieurs opérateurs. Chaque opérateur est séparé par le délimiteur barre verticale. Expression Selon votre préférence, une requête peut être exprimée sur une seule ligne ou avec un retour à la ligne avant chaque délimiteur barre verticale. Cela ne fait aucune différence pour la requête elle-même. Volet Requête Le volet Requête peut contenir plus d’une requête. Il est ainsi facile de commencer par une expression simple, de vérifier qu’elle s’exécute, puis de la développer. Une ligne vide sépare une requête d’une autre. La position de votre curseur détermine quelle requête s’exécute lorsque vous appuyez sur le bouton « Run ». Vous pouvez également mettre en surbrillance une partie de la requête pour exécuter uniquement cette expression. Exécuter

Création de votre première requête

Créons maintenant votre première requête à partir de zéro. Vous pouvez taper le nom de la table dans le volet Requête. Mais nous allons utiliser un petit raccourci. Trouvez la table events.all dans le volet Ressources. Vous devrez peut-être développer la base de données de votre ID de titre en cliquant sur la flèche. Table events.all Une fois la table events.all repérée, double-cliquez sur le nom de la table. Vous remarquerez que cette expression a été ajoutée au volet Requête.
En préversion, vous devrez ajouter manuellement les crochets et les guillemets simples autour du nom de la table. Une correction de cet inconvénient est en cours.
Notez les crochets et les guillemets simples autour du nom. Ils sont requis chaque fois que le nom de la table ou de la colonne comprend un « . ». Votre curseur est maintenant à la bonne position pour créer votre premier opérateur. Commençons par utiliser l’opérateur take.
Exécutez cette requête. Notez que le volet Résultats affiche maintenant 100 lignes de données brutes. Dans le volet Résultats, sélectionnez la première ligne. À l’aide de la flèche droite, déplacez-vous jusqu’à la colonne FullName_Name. Il s’agit du nom de l’événement. Descendez avec la flèche jusqu’à ce que vous trouviez un événement player_logged_in. Une fois que vous en avez trouvé un, déplacez-vous avec la flèche droite jusqu’à la colonne EventData et double-cliquez. Vous devriez maintenant voir ceci : Colonne EventData Votre requête peut référencer n’importe quelle propriété du JSON EventData à l’aide de la notation pointée (.). Vous pouvez l’essayer maintenant en modifiant votre requête pour qu’elle retourne uniquement les événements player_logged_in d’un seul joueur. Double-cliquez sur le GUID EntityID et copiez-le dans le presse-papiers. Mettez maintenant votre requête à jour comme suit et insérez le GUID que vous avez copié :
Les doubles signes d’égalité servent à évaluer l’équivalence de chaînes. Les guillemets simples au début et à la fin délimitent une chaîne.
Exécutez la requête et vous verrez que le volet Résultats affiche les événements player_logged_in uniquement pour le joueur sélectionné. Vous pouvez utiliser la notation pointée pour référencer plusieurs niveaux imbriqués de la hiérarchie JSON en ajoutant simplement un point entre chaque niveau. Créons maintenant une deuxième requête pour regrouper les connexions des joueurs par région. Sans supprimer ce que vous avez écrit, appuyez deux fois sur Entrée. Ajoutons un commentaire à notre prochaine requête à l’aide de « // ». Les commentaires ne sont pas exécutés et sont utiles pour garder une trace de l’intention derrière chaque requête.
Encore une fois, double-cliquez sur la table events.all dans le volet Ressources. Cette fois, ajoutons un délimiteur temporel à notre expression pour limiter notre requête aux trois derniers jours seulement.
Exécutez cette requête pour obtenir la liste complète de tous les événements de connexion des trois derniers jours. Cependant, nous voulons savoir combien de joueurs distincts se sont connectés, et non le nombre d’événements. Pour ce faire, nous utiliserons l’opérateur distinct sur l’ID d’entité.
Cette requête retourne la liste des ID d’entité qui se sont connectés au cours des trois derniers jours. Le volet Résultats affiche le nombre d’enregistrements, ce qui nous permet de voir le nombre total. Enregistrements Obtenons maintenant le nombre de joueurs qui se sont connectés à partir de chaque plateforme. Pour ce faire, nous aurons besoin du nombre distinct d’ID d’entité regroupés par la propriété de plateforme du JSON EventData. Cela nécessite l’opérateur summarize. Comme summarize ne prend pas en charge les types dynamiques, nous devrons également convertir la plateforme en chaîne.
Terminons en beauté. En ajoutant une seule expression supplémentaire, nous pouvons afficher nos résultats sous forme de graphique à colonnes.
Requêtes

Exemples de requêtes

Nous n’avons fait qu’effleurer la surface des types de requêtes pouvant être créées dans Explorer. D’autres exemples de requêtes peuvent être chargés à partir de la page Explorer en appuyant sur « What’s This ». Chacun de ces exemples de requêtes est choisi pour illustrer certains des divers opérateurs disponibles et la façon dont ils peuvent s’appliquer à des questions concrètes.
Comme la forme de vos données peut différer de celle de notre jeu de données de démonstration, vous devrez peut-être modifier l’exemple de requête pour qu’il s’exécute dans votre scénario.

Limites

Deux limites régissent l’utilisation des requêtes dans Explorer :
  1. Durée d’exécution maximale d’une requête : une requête individuelle ne peut pas s’exécuter pendant plus de 30 secondes. Si cette limite est dépassée, la requête est arrêtée et vous recevez un message d’erreur.
  2. Utilisation par intervalle : chaque titre dispose d’une durée d’exécution totale cumulative de trois minutes par intervalle de 10 minutes. Si cette limite est dépassée, vous recevez un message d’erreur et devez attendre avant d’exécuter d’autres requêtes.

Conservation des données

Par défaut, les requêtes Data Explorer s’exécutent sur le stockage à chaud, qui peut être configuré dans l’outil de gestion. Les requêtes qui cherchent au-delà des données conservées dans le stockage à chaud ont des durées d’exécution considérablement plus longues et peuvent expirer.
Dernière modification le 6 octobre 2026