Optimisation et mise en cache du dataset
Les tableaux de bord AI/BI mettent en cache les résultats des queries pour améliorer les temps de chargement. Cette page explique comment le cache des tableaux de bord et les optimisations des datasets fonctionnent, quand les tableaux de bord utilisent des résultats mis en cache et quand ils réexécutent des requêtes sur un SQL Warehouse.
Performances de la query
Vous pouvez inspecter les queries et leurs performances dans l'historique des queries du Workspace. L’historique des requêtes affiche les requêtes SQL exécutées à l’aide de SQL warehouses. Cliquez sur 
**Historique des query** dans la barre latérale pour afficher l'historique des query. Consultez Historique des queries.
Pour les datasets de tableau de bord, Databricks applique des optimisations de performances en fonction de la taille du résultat du dataset. Pour plus d'informations sur les seuils de performance des datasets, consultez la section Seuils de performance des datasets.
Optimisations du dataset
Vos tableaux de bord optimisent la vitesse en effectuant des opérations de filtrage et d'agrégation, guidées par les filtres ou les paramètres de visualisation, directement dans votre navigateur lorsque cela est possible. Ces optimisations des performances ont les limites suivantes :
Taille du dataset | Comportement de traitement |
|---|---|
Petit (≤ 100 000 lignes et ≤ 100 Mo) | Pour une vitesse optimale du tableau de bord, le filtrage et l'agrégation s'exécutent dans votre navigateur après le chargement initial du dataset. Étant donné que ces Opérations sont traitées localement, elles évitent toute interaction supplémentaire avec le data warehouse et n'apparaissent pas dans l'historique des query. |
Grand (> 100K lignes ou > 100 Mo) | Le filtrage et l'agrégation sont gérés par le serveur backend plutôt que par votre navigateur. La query initiale du dataset est enveloppée dans une clause SQL |
Queries combinées (grands datasets) | Pour les queries de visualisation envoyées au backend, les queries de visualisation distinctes pour le même dataset qui partagent les mêmes clauses |
Les paramètres substituent des valeurs directement dans une requête à l'exécution, donc ces opérations apparaissent toujours dans l'historique des requêtes.
Le download d'une table tronquée exécute une requête. Lorsqu'une table affiche des résultats tronqués parce que le dataset dépasse 100 000 lignes, le download des données au format CSV exécute une query sur le SQL warehouse. Cette requête apparaît dans l'historique des requêtes.
Mise en cache et fraîcheur des données
Les tableaux de bord conservent un cache de résultats de 24 heures pour optimiser les temps de chargement initiaux, dans la mesure du possible. Cela signifie que si le système tente toujours d'utiliser les résultats de query historiques liés aux informations d'identification du tableau de bord pour améliorer les performances, il existe des cas où les résultats mis en cache ne peuvent pas être créés ou maintenus. Les données mises en cache n'ont pas de limite de mémoire spécifique ni de nombre de query fixe.
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 mis en cache n'est disponible, ils vérifient le cache de résultats de query générique. Ces deux caches s'invalident différemment. Le cache de résultats de requête ne renvoie jamais de données périmées, car toute modification des données sous-jacentes invalide toutes ses entrées. Le cache du tableau de bord a un comportement d'invalidation différent. Le cache du tableau de bord peut renvoyer des résultats vieux de 24 heures même si les données sous-jacentes ont changé, et un changement des données sous-jacentes n'invalide ni ne refresh automatiquement le cache du tableau de bord.
Pour refresh de manière fiable le cache du tableau de bord, configurez une planification du tableau de bord. Une modification des données sous-jacentes ne refresh pas le cache du tableau de bord d’elle-même, et le refreshing des données dans le cadre d’une étape de pipeline ne refresh pas le cache du tableau de bord. En dehors d'un refresh planifié, le cache du tableau de bord ne se met à jour que lorsqu'un tableau de bord exécute une query que le cache ne peut pas servir.
Servir les résultats du cache du tableau de bord ne start pas le SQL Warehouse. Lorsqu'un tableau de bord renvoie des résultats mis en cache, Databricks lit à partir du cache sans exécuter de query, de sorte que le SQL Warehouse sous-jacent n'a pas besoin d'être en cours d'exécution. Le warehouse ne start que lorsqu'un tableau de bord exécute une query que le cache ne peut pas servir.
Pour les tableaux de bord multipages, les éléments suivants s'appliquent :
- La modification d'un tableau de bord brouillon charge et met en cache tous les datasets.
- Lorsque les utilisateurs ouvrent un tableau de bord publié, seuls les datasets qui prennent en charge la page active sont exécutés et mis en cache.
- Si une planification est définie, tous les datasets refresh selon cette planification, et ces résultats sont mis en cache.
Le tableau suivant explique comment la mise en cache varie en fonction de l’état et des informations d’identification du tableau de bord :
Type de tableau de bord | Type de mise en cache |
|---|---|
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 | Cache par utilisateur. Les viewers voient les résultats en fonction de leurs permissions de données. |
Les tableaux de bord utilisent automatiquement les résultats de query mis en cache si les résultats ont été récupérés il y a moins de 24 heures, même si les données sous-jacentes ont changé après la dernière query. Si des résultats obsolètes existent et que des paramètres sont appliqués au tableau de bord, les requêtes seront réexécutées, sauf si les mêmes paramètres ont été utilisés au cours des dernières 24 heures. De même, l'application de filtres à des jeux de données dépassant 100 000 lignes invite les requêtes à être réexécutées, à moins que les mêmes filtres n'aient été appliqués précédemment au cours des dernières 24 heures.
Fonctions Timestamp actuelles et invalidation du cache
L'utilisation de current_timestamp() ou de fonctions similaires dans votre requête SQL n'invalide pas le cache au niveau du tableau de bord. Cependant, ces fonctions invalident le cache de résultats de query, qui inspecte la query SQL, et déclenchent un refresh du cache.
Requêtes planifiées
L'ajout d'une planification à un tableau de bord publié avec des autorisations de données partagées peut considérablement accélérer le processus de chargement initial pour tous les spectateurs du tableau de bord.
Pour chaque mise à jour planifiée du tableau de bord, les éléments suivants se produisent :
- Toute la logique SQL qui définit les datasets s'exécute sur l'intervalle de temps désigné.
- Les résultats remplissent le cache de résultats des query et contribuent à améliorer le temps de chargement initial du tableau de bord.