Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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. Pour plus d’informations sur les seuils de performances du jeu de données, consultez les seuils de performances du jeu de données.
Optimisations des jeux de données
Vos tableaux de bord optimisent la vitesse en effectuant des opérations de filtrage et d’agrégation, pilotées par des filtres ou des paramètres de visualisation, directement dans votre navigateur lorsque cela est possible. Ces optimisations de performances ont les limites suivantes :
| Taille du jeu de données | Comportement de traitement |
|---|---|
| Petite (≤ 100 000 lignes et ≤ 100 Mo) | Pour une vitesse de tableau de bord optimale, le filtrage et l’agrégation s’exécutent dans votre navigateur après le chargement initial du jeu de données. Étant donné que ces opérations sont traitées localement, elles évitent d’autres interactions avec l’entrepôt de données et n’apparaissent pas dans l’historique des requêtes. |
| Large (> 100 000 lignes ou > 100 Mo) | Le filtrage et l’agrégation sont gérés sur le serveur principal au lieu de votre navigateur. La requête de jeu de données initiale est encapsulée dans une clause SQL WITH et la requête résultante apparaît dans l’historique des requêtes. |
| Requêtes combinées (jeux de données volumineux) | 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 BY et 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 ou filtres. |
Note
Les paramètres remplacent les valeurs directement dans une requête au moment de l’exécution. Ces opérations apparaissent donc toujours dans l’historique des requêtes.
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 améliorer les temps de chargement, les tableaux de bord vérifient d’abord le cache du tableau de bord. Si aucun résultat de cache n’est disponible, ils vérifient le cache de résultats de requête générique. Bien que le cache du tableau de bord puisse retourner des résultats obsolètes pendant jusqu’à 24 heures, le cache de résultats de la requête ne retourne jamais de données obsolètes. Lorsque les données sous-jacentes changent, toutes les entrées du cache de résultats de requête sont invalidées.
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 autorisations de données partagées | Cache partagé. Tous les spectateurs voient les mêmes résultats. |
| Brouillon de tableau de bord ou tableau de bord publié avec des autorisations de données individuelles | 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.
Fonctions d’horodatage actuelles et invalidation du cache
L’utilisation current_timestamp() ou les fonctions similaires dans votre requête SQL n’invalident pas le cache au niveau du tableau de bord. Toutefois, ces fonctions invalident le cache de résultats de la requête, qui inspecte la requête SQL et déclenchent une actualisation du cache.
Requête planifiée
L’ajout d’une planification à un tableau de bord publié avec des autorisations de données partagé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.