Optimisation et mise en cache des jeux de données
Les tableaux de bord A/BI sont des outils précieux d’analyse des données et de prise de décision, et des temps de chargement efficaces peuvent améliorer considérablement l’expérience utilisateur. Cet article explique comment la mise en cache et les optimisations des jeux de données rendent les tableaux de bord plus performants et plus efficaces.
Performances des requêtes
Vous pouvez inspecter les requêtes et leur niveau de performance dans l’historique des requêtes de l’espace de travail. L’historique des requêtes montre les requêtes SQL exécutées en utilisant des entrepôts SQL. Cliquez sur 
Historique des requêtes dans la barre latérale pour afficher l’historique des requêtes. Consulter l'Historique des requêtes.
Pour les jeux de données de tableau de bord, Azure Databricks applique des optimisations de niveau de performance en fonction de la taille du jeu de données.
Optimisations des jeux de données
Les jeux de données de tableau de bord A/BI incluent les optimisations des performances suivantes :
- Si la taille du résultat du jeu de données est petite (inférieure ou égale à 100 000 lignes ou à 100 Mo, la valeur la plus petite étant retenue), le résultat du jeu de données est extrait vers le client, et le filtrage et l’agrégation spécifiques à la visualisation sont effectués dans le navigateur. Le filtrage et l’agrégation des données pour les petits jeux de données sont très rapides, et le fait de s’assurer que votre jeu de données est petit peut vous aider à optimiser les performances du tableau de bord. Avec de petits jeux de données, seule la requête de jeu de données apparaît dans l’historique des requêtes.
- Si la taille du résultat du jeu de données est importante (supérieure à 100 000 lignes ou à 100 Mo), le texte de la requête de jeu de données est encapsulé dans une clause SQL
WITH, et le filtrage et l’agrégation spécifiques à la visualisation sont effectués dans une requête sur le serveur principal plutôt que dans le navigateur. Avec des jeux de données volumineux, la requête de visualisation apparaît dans l’historique des requêtes. - Pour les requêtes de visualisation envoyées au back-end, es requêtes de visualisation distinctes portant sur le même ensemble de données et partageant les mêmes clauses
GROUP BYet prédicats de filtrage sont combinées en une seule requête pour le traitement. Dans ce cas, les utilisateurs peuvent voir une requête combinée dans l’historique des requêtes qui extrait les résultats de plusieurs visualisations.
Mise en cache et actualisation des données
Les tableaux de bord conservent un cache de résultats de 24 heures pour optimiser les temps de chargement initiaux, fonctionnant de manière optimale. Cela signifie que même si le système tente toujours d’utiliser les résultats de requête historiques liés aux informations d’identification du tableau de bord pour améliorer le niveau de performance, il existe certains cas où les résultats mis en cache ne peuvent pas être créés ou conservés. Les données mises en cache n’ont pas de limite de mémoire spécifique ou le nombre de requêtes fixes.
Pour les tableaux de bord multipage, les éléments suivants s’appliquent :
- La modification d’un tableau de bord brouillon charge et met en cache tous les jeux de données.
- Lorsque les visionneuses ouvrent un tableau de bord publié, seuls les jeux de données qui prennent en charge la page active sont exécutés et mis en cache.
- Si une planification est définie, tous les jeux de données s’actualisent en fonction de la planification et ces résultats sont mis en cache.
Le tableau suivant explique comment la mise en cache varie selon l’état du tableau de bord et les informations d’identification :
| Type de tableau de bord | Caching-type |
|---|---|
| Tableau de bord publié avec des informations d’identification incorporées | Cache partagé. Tous les spectateurs voient les mêmes résultats. |
| Tableau de bord publié ou de brouillon sans les informations d’identification incorporées | Par utilisateur(-trice) de cache. Les visionneuses voient les résultats en fonction de leurs autorisations de données. |
Les tableaux de bord utilisent automatiquement les résultats de requête mis en cache si les données sous-jacentes restent inchangées après la dernière requête ou si les résultats ont été récupérés il y a moins de 24 heures. Si des résultats obsolètes existent et que les paramètres sont appliqués au tableau de bord, les requêtes sont réexécutées, sauf si les mêmes paramètres ont été utilisés au cours des 24 dernières heures. De même, l’application de filtres à des jeux de données dépassant 100 000 lignes invite les requêtes à réexécuter, sauf si les mêmes filtres ont été précédemment appliqués au cours des 24 dernières heures.
Requête planifiée
L’ajout d’une planification à un tableau de bord publié avec des informations d’identification incorporées peut accélérer considérablement le processus de chargement initial pour tous les utilisateurs du tableau de bord.
Pour chaque mise à jour planifiée du tableau de bord, les événements suivants se produisent :
- Toute logique SQL qui définit les jeux de données s’exécute sur l’intervalle de temps désigné.
- Les résultats remplissent le cache des résultats de la requête et aident à améliorer le temps de chargement initial du tableau de bord.