Qu'est-ce que les contrôles variables ?

Si vous avez déjà travaillé avec des tableaux de bord Kibana, vous connaissez probablement nos contrôles de tableau de bord classiques : ces menus déroulants pratiques affichent des valeurs extraites de vos données pour vous permettre de les filtrer en quelques clics.

Les contrôles variables semblent similaires à première vue, mais ils comportent une particularité astucieuse : au lieu de filtrer automatiquement chaque panneau de votre tableau de bord, ils peuvent être directement intégrés dans des requêtes ES|QL au sein de visualisations individuelles.

Cela signifie que vous décidez où chaque contrôle s'applique. Mieux encore, vous pouvez les utiliser pour toutes sortes de choses, comme ajuster les intervalles de temps, changer les champs de répartition ou modifier les paramètres de visualisation à la volée. En résumé, ils offrent une expérience véritablement interactive pour vos tableaux de bord et permettent ainsi d'obtenir des informations plus rapidement et plus facilement.

Cas d'utilisation des contrôles variables

Les contrôles variables semblent utiles, mais qu'offrent-ils vraiment ? Voici quelques exemples de la manière dont ils améliorent vos tableaux de bord :

Filtrez les visualisations sélectionnées

Vous souhaitez filtrer certaines visualisations seulement ? C'est possible avec les contrôles variables. Choisissez les panneaux sur lesquels vous souhaitez agir et connectez-les dans les requêtes ES|QL à l'origine de vos visualisations.

Sélectionnez différents intervalles de temps

Donnez à vos utilisateurs la possibilité de choisir entre « 5 minutes », « 1 heure », « 1 jour », ou tout autre intervalle temporel souhaité. Créez un contrôle variable avec des intervalles prédéfinis et connectez-le à votre requête de série temporelle.

Modifier les fonctions

Au lieu de créer plusieurs graphiques pour chaque opération, les utilisateurs du tableau de bord peuvent choisir s'ils veulent voir le maximum, la moyenne, différents centiles ou tout autre agrégateur.

Grouper par différents champs

Il est parfois nécessaire de décomposer les données selon différents facteurs lors d'une enquête. Grâce aux contrôles variables, vous pouvez définir plusieurs champs « grouper par » et permettre aux utilisateurs du tableau de bord de choisir celui qui les aidera à obtenir les informations souhaitées.

Comment faire ?

Le moyen le plus simple (et probablement le plus agréable) de créer un contrôle variable est directement depuis l'éditeur de requêtes ES|QL dans votre visualisation. Commencez simplement à taper votre requête, utilisez le menu de saisie automatique et Kibana vous fournira la structure de contrôle nécessaire.

Mais si vous préférez partir de la variable elle-même, vous pouvez également aller dans : Add panel → Controls → Variable control (Ajouter un panneau → Contrôles → Contrôle de variable) et ajouter la variable à vos visualisations après avoir créé le contrôle.

Exemple 1 : Contrôle de filtrage avec sélection à valeurs multiples

1. Choisissez une visualisation alimentée par une requête ES|QL et cliquez sur « Create control » (Créer un contrôle) dans la clause WHERE

2. Vous serez automatiquement redirigé vers le menu de création de variable, où le type « Values from a query » (Valeurs d’une requête) sera sélectionné pour vous, et le nom de la variable déjà pré-rempli. N’oubliez pas que le nom d’un contrôle doit toujours commencer par « ?... » pour fonctionner dans la requête de visualisation.

Vous aurez traditionnellement besoin d'une requête comme celle-ci pour obtenir les valeurs d'un champ et les mettre à jour selon l'intervalle de temps sélectionné dans le tableau de bord :

3. Lorsque vous enregistrez le contrôle, vous le verrez apparaître en haut du tableau de bord et votre requête de visualisation sera mise à jour avec le nom du contrôle variable.

4. Si vous souhaitez ajouter une sélection à valeurs multiples au contrôle, vous devez utiliser la fonction MV_CONTAINS dans la requête et sélectionner « Allow multiple selections » (Autoriser les sélections multiples) lors de la création du contrôle à l’étape 2 (disponible à partir de la version 9.3).

Exemple 2 : contrôle de l'intervalle de temps

Si vous créez une série temporelle, vous pouvez facilement ajouter un contrôle variable pour l'intervalle de votre histogramme de dates :

1. Lors de la rédaction d'une requête ES|QL pour votre série temporelle, cliquez sur « Create control » (Créer un contrôle). Lorsque vous créez une variable pour des intervalles, il est préférable d'utiliser TBUCKET au lieu de BUCKET pour prendre en charge des intervalles plus lisibles tels que « 1 heure », « 1 jour », etc. Une option automatique sera bientôt disponible pour TBUCKET afin qu'il puisse s'adapter automatiquement aux périodes de temps.

2. Définissez les intervalles pour remplir les options dans le menu déroulant.

3. Sélectionnez différents intervalles dans le menu déroulant et observez comment votre visualisation change.

Exemple 3 : variables pour les fonctions

1. Créez une variable en utilisant le type de contrôle « Static values » (Valeurs statiques) et ajoutez des noms de fonctions à vos valeurs déroulantes. Il est important d'utiliser un nom de variable qui commence par « ??… » pour remplacer les fonctions.

2. Incluez le nom de la variable dans votre requête ES|QL.

Exemple 4 : variables pour les champs

1. Vous pouvez utiliser le type de contrôle « Static values » (Valeurs statiques) et indiquer les noms des champs que vous souhaitez. Le nom de variable doit commencer par « ??… » pour les champs.

2. Référencez la variable souhaitée dans la requête de visualisation.

Contrôles variables dans Discover

Les contrôles variables ne sont pas seulement une fonctionnalité du tableau de bord. Ils sont également disponibles directement dans l'éditeur ES|QL de Discover. Vous pouvez créer des contrôles pour accélérer l'exploration des données dans Discover, les intégrer au tableau de bord et inversement.

Détails techniques

Vous avez probablement remarqué que les contrôles de variables sont assortis de quelques règles, telles que les éléments d'une requête auxquels ils peuvent faire référence et les préfixes que vous devez utiliser (« ?... » pour les valeurs et « ??... » pour les champs ou les fonctions). En effet, les variables ne sont pas de simples remplacements de chaînes effectués sur le client. Ce sont des éléments essentiels du langage de requête (connus sous le nom de paramètres dans ES|QL).

Cette conception apporte de grands avantages. D'une part, Kibana peut comprendre le contexte de chaque variable, ce qui nous permet de générer et de pré-remplir automatiquement sa configuration pour vous. C’est aussi beaucoup plus sécurisé : le langage valide strictement les entrées variables et empêche ainsi les injections malveillantes tout en signalant toute erreur. De plus, il améliore les performances et la stabilité en transférant la validation complexe et la gestion des erreurs vers le serveur plutôt que vers le client. Une note sur les performances : une bonne pratique consiste à créer des variables qui incluent des requêtes rapides, car elles se chargent avant le tableau de bord. Ainsi, des requêtes lentes peuvent affecter les performances globales du tableau de bord.

Bien sûr, cette architecture présente aussi quelques limites, pour le moment. Les variables ne prennent pas encore en charge l'option « Tout » pour le filtrage, et elles ne peuvent actuellement pas être utilisées avec certains opérateurs tels que LIKEou FROM (pour changer de source de données). La bonne nouvelle ? Nous travaillons activement à l'ajout de ces fonctionnalités.

Ce que l'avenir réserve aux contrôles

Nous ne nous arrêtons pas là ! Parmi les améliorations que nous suivons de près, citons :

✨ La possibilité de placer des contrôles n'importe où sur le tableau de bord

✨ Chaînage de vos contrôles, ce qui signifie que la sortie d'un contrôle devient l'entrée du suivant

✨ De meilleures options de sélection comme la sélection « Tout » pour les variables

✨ Nouveaux types de contrôle (contrôle de type rechercher et variables pour vos sources de données)

✨ Et d'autres améliorations de l'expérience utilisateur que vous avez demandées, comme le pré-filtrage des contrôles normaux

Si vous avez des idées ou des commentaires, n'hésitez pas à nous en faire part.

Différences par rapport à la première analyse Spotify Wrapped

Dans le premier blog, nous avons utilisé l'export Spotify directement et n'avons effectué aucune tâche de normalisation ni aucun autre traitement de données. Cette fois-ci, nous utiliserons les mêmes données, mais nous les traiterons pour les rendre plus utilisables. Cela nous permettra de répondre à des questions beaucoup plus complexes, comme par exemple :

• Quelle est la durée moyenne d'une chanson dans mon top 100 ?

• Quelle est la popularité moyenne d'une chanson dans mon top 100 ?

• Quelle est la durée médiane d'écoute d'une chanson ?

• Quelle est la piste que je saute le plus souvent ?

• Quand est-ce que j'aime sauter des pistes ?

• Suis-je plus attentif à une heure particulière de la journée qu'à d'autres ?

• Est-ce que j'écoute plus un jour de la semaine que les autres ?

• S'agit-il d'un mois particulièrement intéressant ?

• Quel est l'artiste dont la durée d'écoute est la plus longue ?

Spotify Wrapped est une expérience amusante chaque année, vous montrant ce que vous avez écouté cette année. Il n'indique pas les changements d'une année sur l'autre, et il se peut donc que vous passiez à côté d'artistes qui figuraient autrefois dans votre top 10, mais qui ont maintenant disparu.

Traitement des données Spotify Wrapped pour analyse

Il y a une grande différence dans la façon dont nous traitons les données dans le premier et le second message. Si vous souhaitez continuer à travailler avec les données du premier message, vous devrez tenir compte de certains changements de noms de champs et revenir à ES|QL pour effectuer certaines extractions comme hour of day à la volée.

Néanmoins, vous devriez tous être en mesure de suivre ce message. Le traitement des données est effectué dans le référentiel Spotify to Elasticsearch et consiste à demander à l'API Spotify la durée de la chanson, la popularité, ainsi qu'à renommer et à enrichir certains champs. Par exemple, le champ artist dans l'export Spotify n'est qu'une chaîne de caractères et ne représente pas les fonctionnalités ou les titres multi-artistes.

Visualiser les données de Spotify Wrapped avec des tableaux de bord

J'ai créé un tableau de bord dans Kibana pour visualiser les données. Le tableau de bord est disponible ici et vous pouvez l'importer dans votre instance Kibana. Le tableau de bord est très complet et répond à de nombreuses questions.

Examinons quelques-unes de ces questions et la manière d'y répondre ensemble !

Quelle est la durée moyenne d'une chanson dans mon top 100 ?

Pour répondre à cette question, nous pouvons utiliser Lens ou ES|QL. Explorons ces trois options. Formulons cette question correctement à la manière d'Elasticsearch. Nous voulons trouver les 100 chansons les plus populaires et calculer la durée moyenne de toutes ces chansons combinées. En termes d'Elasticsearch, il s'agit de deux agrégations :

1. Déterminer les 100 chansons les plus populaires

2. Calculez la durée moyenne de ces 100 chansons.

Lens

Dans Lens, c'est assez simple : créez un nouveau Lens, passez à une table et glissez-déposez le champ title dans la table. Cliquez ensuite sur le champ title et fixez la taille à 100, ainsi que le mode accuracy. Faites ensuite glisser le champ duration dans la table et utilisez last value, car nous n'avons besoin que de la dernière valeur de la durée de chaque chanson. Une même chanson n'aura qu'une seule durée. Au bas de cette agrégation last value se trouve un menu déroulant permettant d'obtenir une ligne de résumé. Sélectionnez average et vous obtiendrez le résumé.

ES|QL

ES|QL est un langage assez récent par rapport aux agrégations DSL &, mais il est très puissant et facile à utiliser. Pour répondre à la même question en ES|QL, vous devez écrire la requête suivante :

Laissez-moi vous guider pas à pas dans cette requête ES|QL :

1. from spotify-history - C'est le modèle d'index que nous utilisons.

2. stats duration=max(duration), count=count() by title - Il s'agit de la première agrégation, nous calculons la durée maximale de chaque chanson et le nombre de chansons. Nous utilisons max au lieu de last value comme dans la lentille, parce que ES|QL n'a pas de prénom ni de nom de famille.

3. sort count desc - Nous trions les chansons en fonction du nombre d'écoutes, de sorte que la chanson la plus écoutée se trouve en haut de la liste.

4. limit 100 - Nous limitons le résultat aux 100 premières chansons.

5. stats Average duration of the songs=avg(duration) - Nous calculons la durée moyenne des chansons.

Un mois présente-t-il un intérêt particulier pour moi ?

Pour répondre à cette question, nous pouvons utiliser Lens avec l'aide du champ d'exécution et ES|QL. Nous remarquons tout de suite qu'il n'y a pas de champ dans les données qui indique directement month, mais que nous devons le calculer à partir du champ @timestamp. Il y a plusieurs façons de procéder :

1. Utiliser un champ d'exécution pour alimenter la lentille

2. ES|QL

Je pense personnellement que ES|QL est la solution la plus propre et la plus rapide.

C'est tout, il n'y a rien d'extraordinaire à faire, nous pouvons utiliser la fonction DATE_EXTRACT pour extraire le mois du champ @timestamp et ensuite l'agréger. En utilisant la visualisation ES|QL, nous pouvons l'intégrer au tableau de bord.

Quelle est ma durée d'écoute par artiste et par an ?

L'idée sous-jacente est de voir si un artiste n'est qu'un phénomène ponctuel ou s'il est récurrent. Si je me souviens bien, Spotify n'affiche que les 5 premiers artistes de l'année. Peut-être que votre artiste numéro 6 reste le même tout le temps, ou qu'il change fortement après la 10e position ?

L'une des représentations les plus simples est le diagramme à barres en pourcentage. Nous pouvons utiliser Lens à cette fin. Suivez les étapes :

Faites glisser et déposez le champ listened_to_ms. Ce champ représente la durée d'écoute d'une chanson en millisecondes. Par défaut, Lens crée une agrégation median, ce que nous ne voulons pas, mais plutôt sum. Dans la partie supérieure, sélectionnez percentage au lieu de stacked pour le type de diagramme à barres. Pour la répartition, sélectionnez artist et dites top 10. Dans la liste déroulante Advanced, n'oubliez pas de sélectionner accuracy mode. Désormais, chaque bloc de couleur représente le nombre de fois où vous avez écouté cet artiste. En fonction de votre marqueur temporel, les barres peuvent représenter des valeurs de jours, de semaines, de mois ou d'années. Si vous souhaitez un décompte hebdomadaire, sélectionnez le site @timestamp et réglez le site mininum interval sur year. Dans mon cas, on peut dire que Fred Again.. est l'artiste que j'ai le plus écouté, près de 12% de mon temps d'écoute total ayant été consommé par Fred Again... Nous constatons également que Fred Again.. a légèrement diminué en 2024, mais que Jamie XX a largement progressé. Si l'on compare uniquement la taille des barres. Nous pouvons également constater que pendant que Billie Eilish est constamment joué dans 2024, le bar s'élargit. Cela signifie que j'ai écouté Billie Eilish plus en 2024 qu'en 2023.

Qu'en est-il des meilleurs titres par artiste et par durée d'écoute par rapport à la durée d'écoute totale ?

C'est une question qui a de la gueule. Permettez-moi d'essayer d'expliquer ce que je veux dire par là. Spotify vous informe sur la meilleure chanson d'un artiste, ou sur vos 5 meilleures chansons. C'est très intéressant, mais qu'en est-il de la décomposition d'un artiste ? Est-ce que tout mon temps est consommé par une seule chanson que je joue encore et encore, ou est-ce que ce temps est réparti de manière égale ?

Créez un nouvel objectif et sélectionnez Treemap comme type. Pour metric, même chose que précédemment : sélectionnez sum et utilisez listened_to_ms comme champ. Pour le site group by, nous avons besoin de deux valeurs. Le premier est artist et le second est title. Le résultat intermédiaire est le suivant :

Changeons cela pour le top 100 des artistes et désélectionnons le other dans le menu déroulant avancé, ainsi que l'activation du mode précision. Pour le titre, modifiez-le en top 10 et activez le mode précision. Le résultat final est le suivant :

Qu'est-ce que cela nous apprend exactement ? Sans tenir compte de la durée, on peut dire que sur l'ensemble de mon historique d'écoute avec Spotify, j'ai passé 5,67% à écouter Fred Again... En particulier, j'ai passé 1,21% de ce temps à écouter Delilah (pull me out of this). Il est intéressant de voir s'il y a une seule chanson qui occupe un artiste, ou s'il y a aussi d'autres chansons. La carte arborescente elle-même est une forme agréable pour représenter de telles distributions de données.

Est-ce que j'écoute à une heure et à un jour précis ?

Nous pouvons répondre à cette question de manière très simple grâce à une visualisation de la lentille qui exploite le site Heat Map. Créez un nouvel objectif, sélectionnez Heat Map. Pour le champ Horizontal Axis select dayOfWeek, définissez Top 7 au lieu de Top 3. Pour le Vertical Axis, sélectionnez le hourOfDay et pour le Cell Value, un simple Count of records. Cette opération permet d'obtenir ce panneau :

Il y a deux ou trois choses ennuyeuses autour de cette lentille, qui me dérangent lors de l'interprétation. Essayons d'y mettre un peu d'ordre. Tout d'abord, je ne me soucie pas trop de la légende, utilisez le symbole en haut avec le triangle, le carré, le cercle et désactivez-le.

La deuxième partie qui est gênante est le tri des jours. C'est lundi, mercredi, jeudi, ou autre chose, selon les valeurs que vous avez. Le site hourOfDay est correctement trié. La façon de trier les jours est une astuce amusante qui consiste à utiliser Filters au lieu de Top Values. Cliquez sur dayOfWeek et sélectionnez Filters, cela devrait ressembler à ceci :

Il ne vous reste plus qu'à taper les jours. Un filtre par jour. "dayOfWeek" : Monday et lui attribuer le label Monday, puis rincer et répéter.

Un bémol cependant : Spotify fournit les données en UTC+0 sans aucune information sur le fuseau horaire. Bien sûr, ils fournissent également l'adresse IP et le pays où vous avez écouté et nous pourrions en déduire les informations relatives au fuseau horaire, mais cela peut s'avérer bancal et pour des pays comme les États-Unis qui ont plusieurs fuseaux horaires, cela peut s'avérer trop fastidieux. C'est important car Elasticsearch et Kibana prennent en charge les fuseaux horaires et en fournissant le bon fuseau horaire dans le champ @timestamp, Kibana ajustera automatiquement l'heure à celle de votre navigateur.

Il devrait ressembler à ceci lorsqu'il sera finalisé, et on peut dire que je suis un auditeur très actif pendant les heures de travail et moins le samedi et le dimanche.

Conclusion

Dans ce blog, nous avons approfondi les subtilités des données de Spotify. Nous avons montré quelques moyens simples et rapides de mettre en place des visualisations. Il est tout simplement incroyable d'avoir autant de contrôle sur son propre historique d'écoute. Consultez les autres parties de la série :

• Partie 1 : Comment créer son propre Spotify Wrapped dans Kibana

• Partie 3 : Emplois de la population pour la détection des anomalies

• Partie 4 : Détecter les relations dans les données

• Partie 5 : Trouver son meilleur ami musical avec les vecteurs