Résoudre les problèmes en lien avec l’actualisation incrémentielle et les données en temps réel

Article
01/16/2024

Il existe deux phases lors de l’implémentation d’une solution de données d’actualisation incrémentielle et de données en temps réel, la première configuration des paramètres, le filtrage et la définition d’une stratégie dans Power BI Desktop, et la seconde étant l’opération d’actualisation initiale du modèle sémantique et les actualisations suivantes dans le service. Cet article décrit la résolution des problèmes séparément pour chacune de ces phases.

Une fois la table partitionnée dans le service Power BI, il est important de garder à l’esprit que les tables actualisées de façon incrémentielle qui obtiennent également des données en temps réel avec DirectQuery sont à présent opérationnelles en mode hybride, ce qui signifie qu’elles fonctionnent en mode d’importation et en mode DirectQuery. Toutes les tables avec des relations à une telle table hybride actualisée de manière incrémentielle doivent utiliser le mode Double pour pouvoir être utilisées en mode Importation et DirectQuery sans pénalités en matière de performances. En outre, les visuels de rapport peuvent mettre en cache les résultats pour éviter de renvoyer des requêtes à la source de données, ce qui empêche la table de récupérer les dernières mises à jour de données en temps réel. La section finale sur la résolution des problèmes couvre ces problèmes liés au mode Hybride.

Avant de résoudre les problèmes d’actualisation incrémentielle et de données en temps réel, veillez à passer en revue actualisation incrémentielle pour les modèles et les données en temps réel et des informations étape par étape dans Configurer l’actualisation incrémentielle et les données en temps réel.

Configuration dans Power BI Desktop

La plupart des problèmes qui se produisent lors de la configuration de l’actualisation incrémentielle et des données en temps réel sont liés au repli de requête. Comme décrit dans Vue d’ensemble de l’actualisation incrémentielle pour les modèles : les sources de données prises en charge, votre source de données doit prendre en charge le pliage des requêtes.

Problème : Le chargement des données est trop long

Dans l’Éditeur Power Query, après avoir sélectionné Appliquer, le chargement des données prend beaucoup de temps et de ressources de l’ordinateur. Il existe plusieurs causes potentielles.

Cause : Incompatibilité de types de données

Ce problème peut être dû à une incompatibilité de types de données où Date/Time est le type de données requis pour les paramètres RangeStart et RangeEnd, mais la colonne de date de la table sur laquelle les filtres sont appliqués ne sont pas de type de données Date/Time, ou vice-versa. Le type de données des paramètres et la colonne de données filtrée doivent être de type de données Date/Time et le format doit être le même. Si ce n’est pas le cas, la requête ne peut pas être pliée.

Solution : Vérifier les types de données

Vérifiez que la colonne date/heure de la table d’actualisation incrémentielle est de type de données Date/Time. Si votre table ne contient pas de colonne de type de données Date/Time, mais utilise à la place un type de données entier, vous pouvez créer une fonction qui convertit la valeur date/heure dans les paramètres RangeStart et RangeEnd pour qu’elle corresponde à la clé de substitution de type entier de la table de source de données. Pour plus d’informations, consultez Configurer l’actualisation incrémentielle - Convertir DateHeure en type entier.

Cause : La source de données ne prend pas en charge le repli de requête

Comme décrit dans Actualisation incrémentielle et les données en temps réel pour les modèles - Conditions requises, l’actualisation incrémentielle est conçue pour les sources de données qui prennent en charge le pliage des requêtes. Assurez-vous que les requêtes de source de données sont repliées dans Power BI Desktop avant d’effectuer la publication sur le service, où les problèmes de repli de requête peuvent être fortement composés. Cette approche est particulièrement importante lorsque vous incluez des données en temps réel dans une stratégie d’actualisation incrémentielle, car la partition DirectQuery en temps réel requiert le repli des requêtes.

Solution : Vérifier et tester les requêtes

Dans la plupart des cas, un avertissement s’affiche dans la boîte de dialogue de la stratégie d’actualisation incrémentielle, indiquant si la requête à exécuter sur la source de données ne prend pas en charge le repli de requête. Toutefois, dans certains cas, il peut être nécessaire de s’assurer que le repli de requête est possible. Si possible, surveillez la requête transmise à la source de données à l’aide d’un outil tel que SQL Profiler. Une requête avec des filtres basés sur RangeStart et RangeEnd doit être exécutée dans une requête unique.

Vous pouvez également spécifier une courte période de date/heure dans les paramètres RangeStart et RangeEnd, qui n’inclut pas plus de quelques milliers de lignes. Si le chargement de données filtrées à partir de la source de données vers le modèle prend beaucoup de temps et nécessite beaucoup de traitement, cela signifie probablement que la requête n’est pas pliée.

Si vous déterminez que la requête n’est pas pliée, reportez-vous aux articles Guide sur le repli de requête dans Power BI Desktop et Repli de requête Power Query pour vous aider à identifier ce qui peut empêcher le repli de requête et comment, ou si, la source de données peut prendre en charge le repli de requête.

Actualisation du modèle sémantique dans le service

La résolution des problèmes d’actualisation incrémentielle dans le service diffère selon le type de capacité dans lequel votre modèle a été publié. Les modèles sémantiques sur les capacités Premium prennent en charge l’utilisation d’outils tels que SQL Server Management Studio (SSMS) pour afficher et actualiser sélectivement des partitions individuelles. Les modèles Power BI Pro ne fournissent pas d’accès aux outils via le point de terminaison XMLA. Par conséquent, la résolution des problèmes d’actualisation incrémentielle peut nécessiter un peu plus d’essai et d’erreur.

Problème : L’actualisation initiale expire

L’actualisation planifiée pour les modèles Power BI Pro sur une capacité partagée a une limite de temps de deux heures. Cette limite de temps est augmentée à cinq heures pour les modèles dans une capacité Premium. Les systèmes de source de données peuvent également imposer une limite de taille de requête ou un délai d’expiration de requête.

Cause : Les requêtes de source de données ne sont pas repliées

Bien que les problèmes de pliage des requêtes puissent généralement être déterminés dans Power BI Desktop avant de publier sur le service, il est possible que les requêtes d’actualisation de modèle ne soient pas pliées, ce qui entraîne des temps d’actualisation excessifs et l’utilisation excessive des ressources du moteur mashup. Cette situation se produit parce qu’une requête est créée pour chaque partition du modèle. Si les requêtes ne sont pas repliées et que les données ne sont pas filtrées au niveau de la source de données, le moteur tente alors de filtrer les données.

Solution : Vérifier le repli de requête

Utilisez un outil de suivi au niveau de la source de données pour déterminer si la requête transmise pour chaque partition est une requête unique qui comprend un filtre basé sur les paramètres RangeStart et RangeEnd. Si ce n’est pas le cas, vérifiez que le repli de requête se produit dans le modèle Power BI Desktop lors du chargement d’une petite quantité de données filtrées dans le modèle. Si ce n’est pas le cas, commencez par l’obtenir dans le modèle, effectuez une mise à jour des métadonnées uniquement vers le modèle (à l’aide du point de terminaison XMLA) ou, si un modèle Power BI Pro sur une capacité partagée, supprimez le modèle incomplet dans le service, republiez et réessayez une opération d’actualisation initiale.

Si vous déterminez que les requêtes ne sont pas repliées, reportez-vous aux articles Guide sur le repli de requête dans Power BI Desktop et Repli de requête Power Query pour obtenir de l’aide pour identifier ce qui peut empêcher le repli de requête.

Cause : Les données chargées dans les partitions sont trop volumineuses

Solution : Réduire la taille du modèle

Dans de nombreux cas, le délai d’expiration est dû à la quantité de données qui doivent être interrogées et chargées dans les partitions de modèle dépasse les limites de temps imposées par la capacité. Réduisez la taille ou la complexité de votre modèle, ou envisagez de diviser le modèle en petits morceaux.

Solution : Activer le format de stockage de modèle volumineux

Pour les modèles publiés sur des capacités Premium, si le modèle dépasse 1 Go ou plus, vous pouvez améliorer les performances des opérations d’actualisation et vous assurer que le modèle ne limite pas la taille maximale en activant le format de stockage grand modèle avant effectuer la première opération d’actualisation dans le service. Pour en savoir plus, consultez Grands modèles dans Power BI Premium.

Solution : Amorcer l’actualisation initiale

Pour les modèles publiés dans les capacités Premium, vous pouvez démarrer l’opération d’actualisation initiale. Le démarrage permet au service de créer des objets de table et de partition pour le modèle, mais pas de charger et de traiter les données historiques dans l’une des partitions. Pour plus d’informations, consultez Actualisation incrémentielle avancée - Empêcher les délais d’attente lors de l’actualisation complète initiale.

Cause : Délai d’expiration de la requête de source de données

Les requêtes peuvent être limitées par une limite de temps par défaut pour la source de données.

Solution : Remplacer la limite de temps dans l’expression de requête

De nombreuses sources de données permettent de remplacer la limite de temps dans l’expression de requête. Pour plus d’informations, consultez actualisation incrémentielle pour les modèles - Limites de temps.

Problème : L’actualisation échoue en raison de valeurs dupliquées

Cause : Les dates de publication ont changé

Avec une opération d’actualisation, seules les données qui ont changé à la source de données sont actualisées dans le modèle. À mesure que les données sont divisées par une date, il est recommandé de ne pas modifier les dates de publication (transaction).

Si une date est modifiée par inadvertance, deux problèmes peuvent se produire : les utilisateurs remarquent des totaux modifiés dans les données historiques (qui ne sont pas supposés se produire) ou, pendant une actualisation, une erreur est renvoyée, indiquant qu’une valeur unique n’est en fait pas unique. Dans le dernier cas, cette situation peut se produire lorsque la table avec l’actualisation incrémentielle configurée est utilisée dans une relation 1:N avec une autre table comme le côté 1 et qu’elle doit avoir des valeurs uniques. Lorsque les données sont modifiées pour un ID spécifique, cet ID apparaît dans une autre partition et le moteur détecte que la valeur n’est pas unique.

Solution : Actualiser des partitions spécifiques

Là où une entreprise doit modifier certaines données passées à partir de dates, une solution possible consiste à utiliser SSMS pour actualiser toutes les partitions à partir du point où la modification est située et jusqu’à la partition d’actualisation actuelle, ce qui permet de conserver le côté 1 de la relation unique.

Problème : Les données sont tronquées

Cause : La limite des requêtes de source de données a été dépassée

Certaines sources de données, comme Azure Data Explorer, Log Analytics et Application Insights, ont une limite de 64 Mo (compressées) sur les données qui peuvent être retournées pour une requête externe. Azure Data Explorer peut retourner une erreur explicite, mais pour d’autres, comme Log Analytics et Application Insights, les données retournées sont tronquées.

Solution : Spécifier des périodes d’actualisation et de stockage plus petites

Spécifiez des périodes d’actualisation et de stockage plus petites dans la stratégie. Par exemple, si vous avez spécifié une période d’actualisation d’un an et qu’une erreur de requête est retournée ou si les données retournées sont tronquées, essayez une période d’actualisation de 12 mois. Vous voulez vous assurer que les requêtes de la partition d’actualisation actuelle ou de toutes les partitions historiques basées sur les périodes d’actualisation et de stockage ne retournent pas plus de 64 Mo de données.

Problème : L’actualisation échoue en raison de conflits de clés de partition

Cause : La date de la colonne de date au niveau de la source de données est mise à jour

Le filtre sur la colonne de date sert à répartir dynamiquement les données dans des plages de temps dans le service Power BI. L’actualisation incrémentielle n’a pas vocation à prendre en charge les cas où la colonne de date filtrée est mise à jour dans le système source. Une mise à jour est interprétée comme une insertion et une suppression, et non pas comme une vraie mise à jour. Si la suppression se produit dans la plage historique et non dans la plage incrémentielle, elle n’est pas sélectionnée, ce qui peut entraîner des échecs d’actualisation des données en raison de conflits de clés de partition.

Mode Hybride dans le service (préversion)

Lorsque Power BI applique une stratégie d’actualisation incrémentielle avec des données en temps réel, il transforme la table actualisée de manière incrémentielle en table hybride qui fonctionne en mode Importation et en mode DirectQuery. Notez la partition DirectQuery à la fin de la liste de partitions suivante d’un exemple de table. La présence d’une partition DirectQuery a des implications pour les tables associées et des visuels de rapport qui interrogent cette table.

Problème : les performances de la requête sont médiocres

Les tables hybrides fonctionnant en mode Importation et DirectQuery nécessitent toutes les tables associées qui fonctionnent en mode Double afin qu’elles puissent agir comme mises en cache ou non mises en cache, selon le contexte de la requête soumise au modèle Power BI. Le mode double permet à Power BI de réduire le nombre de relations limitées dans le modèle et de générer des requêtes de source de données efficaces pour garantir de bonnes performances. Les relations limitées ne peuvent pas faire l’objet d’un push vers la source de données nécessitant Power BI pour récupérer plus de données que nécessaire. Étant donné que les tables doubles peuvent agir comme des tables DirectQuery ou Importer, cette situation est évitée.

Lors de la configuration d’une stratégie d’actualisation incrémentielle, Power BI Desktop vous rappelle de basculer toutes les tables associées vers le mode Double lorsque vous sélectionnez les données les plus récentes en temps réel avec DirectQuery (Premium uniquement). En outre, veillez à passer en revue toutes les relations de table existantes dans la vue de modèle.

Les tables qui fonctionnent actuellement en mode DirectQuery sont facilement basculées en mode Double. Dans les propriétés de la table, sous Avancé, sélectionnez Double dans la zone de liste Mode de stockage. Toutefois, les tables qui fonctionnent actuellement en mode d’importation nécessitent un travail manuel. Les tables doubles ont les mêmes contraintes fonctionnelles que les tables DirectQuery. Par conséquent, Power BI Desktop ne peut pas convertir les tables d’importation, car elles peuvent reposer sur d’autres fonctionnalités qui ne sont pas disponibles en mode Double. Vous devez recréer manuellement ces tables en mode DirectQuery, puis les convertir en mode Double. Pour plus d’informations, consultez Gérer le mode de stockage dans Power BI Desktop.

Problème : les visuels de rapport n’affichent pas les données les plus récentes

Cause : Power BI met en cache les résultats de la requête pour améliorer les performances et réduire la charge du serveur principal

Par défaut, Power BI met en cache les résultats des requêtes, afin que les requêtes des visuels de rapport puissent être traitées rapidement, même si elles sont basées sur DirectQuery. Le fait d’éviter d’avoir des requêtes de source de données superflues améliore les performances et réduit la charge de la source de données, mais cela peut également signifier que les dernières modifications de données au niveau de la source ne sont pas incluses dans les résultats.

Solution : configurer l’actualisation automatique des pages

Pour continuer à récupérer les dernières modifications de données à partir de la source, configurez l’actualisation automatique des pages pour vos rapports dans le service Power BI. L’actualisation automatique des pages peut être effectuée à intervalles fixes, par exemple cinq secondes ou dix minutes. Lorsque cet intervalle spécifique est atteint, tous les visuels de cette page envoient une requête de mise à jour à la source de données et se mettent à jour en conséquence. Vous pouvez également actualiser les visuels sur une page en fonction de la détection des modifications apportées aux données. Cette approche nécessite une mesure de détection des modifications que Power BI utilise ensuite pour interroger la source de données à la recherche de modifications. La détection des modifications est uniquement prise en charge dans les espaces de travail qui font partie d’une capacité Premium. Pour plus d’informations, consultez Actualisation automatique des pages dans Power BI.