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

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 traite de la résolution des problèmes séparément pour chacune de ces phases.

Après avoir partitionné la table dans le service Power BI, il est important de garder à l’esprit que les tables actualisées de manière incrémentielle qui obtiennent également des données en temps réel avec DirectQuery fonctionnent désormais en mode hybride, ce qui signifie qu’elles fonctionnent à la fois en mode Importation et DirectQuery. Toutes les tables avec des relations avec une table hybride actualisée de manière incrémentielle doivent utiliser le mode Double afin qu’elles puissent être utilisées en mode importation et DirectQuery sans pénalités 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êcherait la table de récupérer les dernières mises à jour de données en temps réel. La dernière section de résolution des problèmes couvre ces problèmes en 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 l’actualisation incrémentielle pour les modèles et les données en temps réel et les informations pas à pas 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 doivent être liés au pliage des requêtes. Comme décrit dans l’actualisation incrémentielle pour la vue d’ensemble des modè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 prend trop de temps

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

Cause : Incompatibilité du type de données

Ce problème peut être dû à une incompatibilité de type 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 n'est pas de type de données Date/Time, ou inversement. Le type de données des paramètres et la colonne de données filtrée doivent être Date/Time de type de données 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 le type de données

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

Cause : la source de données ne prend pas en charge le pliage des requêtes

Comme décrit dans l’actualisation incrémentielle et les données en temps réel pour les modèles - Exigences, 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 optimisées dans Power BI Desktop avant de publier sur le service Power BI, où les problèmes de pliage des requêtes peuvent être considérablement amplifié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 nécessite le pliage des requêtes.

Solution : Vérifier et tester des requêtes

Dans la plupart des cas, un avertissement s’affiche dans la boîte de dialogue de 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 pliage des requêtes. Toutefois, dans certains cas, il peut être nécessaire de s’assurer que le pliage des requêtes 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é 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 RangeStart paramètres RangeEnd qui n’incluent pas plus de quelques milliers de lignes. Lorsque le chargement des données filtrées depuis la source de données jusqu'au modèle prend beaucoup de temps et demande beaucoup de ressources, cela signifie probablement que la requête n’est pas optimisée.

Si vous déterminez que la requête n’est pas pliée, reportez-vous aux instructions de pliage des requêtes dans Power BI Desktop et à Power Query pour le pliage des requêtes afin d’obtenir de l’aide sur l’identification de ce qui peut empêcher le pliage des requêtes et comment ou si la source de données peut même prendre en charge le pliage des requêtes.

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 : le rafraîchissement initial 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 retour de requête ou un délai d’expiration de requête.

Cause : Les requêtes de source de données ne sont pas plié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 pliées et que les données ne sont pas filtrées à la source de données, le moteur tente de filtrer les données.

Solution : Vérifier le pliage des requêtes

Utilisez un outil de traçage à la source de données qui permet de déterminer que la requête passée pour chaque partition est une requête unique incluant un filtre basé sur les paramètres RangeStart et RangeEnd. Si ce n’est pas le cas, vérifiez que le pliage des requêtes se produit dans le modèle Power BI Desktop lors du chargement d’une petite quantité filtrée de donné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 pliées, reportez-vous aux instructions de pliage de requêtes dans Power BI Desktop et à Power Query pour obtenir de l’aide sur l’identification de ce qui peut empêcher le pliage des requêtes.

Cause : Les données chargées dans des 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 'Large Model'

Pour les modèles publiés dans les 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 garantir que le modèle ne limite pas la taille maximale en activant le format de stockage grand modèle avant d’effectuer la première opération d’actualisation dans le service. Pour en savoir plus, consultez Grands modèles dans Power BI Premium.

Solution : Rafraîchissement initial du Bootstrap

Pour les modèles publiés dans les capacités Premium, vous pouvez amorcer 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 ni de traiter les données historiques dans aucune 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 défaut par une limite de temps 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. Étant donné que les données sont divisées par une date, il est recommandé que les dates post (transaction) ne soient pas modifiées.

Si une date est modifiée accidentellement, deux problèmes peuvent se produire : les utilisateurs remarquent que certains totaux ont été modifiés dans les données historiques (ce qui n’est pas censé se produire) ou lors d’une actualisation, une erreur est retournée indiquant qu’une valeur unique n’est pas en fait unique. Pour ce dernier, cette situation peut se produire lorsque la table avec actualisation incrémentielle configurée est utilisée dans une relation avec l'autre table en tant que côté 1 et doit avoir des valeurs uniques. Lorsque les données sont modifiées pour un ID spécifique, cet ID apparaît ensuite dans une autre partition et le moteur détecte que la valeur n’est pas unique.

Solution : Actualiser des partitions spécifiques

Lorsqu'il y a un besoin commercial de modifier certaines données passées à partir des dates, une solution possible consiste à utiliser SSMS pour actualiser toutes les partitions à partir du point de la modification jusqu'à la partition d'actualisation actuelle, en conservant ainsi l'unicité du côté 1 de la relation.

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

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

Certaines sources de données, telles qu’Azure Data Explorer, Log Analytics et Application Insights, ont une limite de 64 Mo (compressée) 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 de rafraîchissement et de stockage plus courtes.

Spécifiez des périodes d'actualisation et de stockage plus courtes 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 que les données retournées sont tronquées, essayez une période d’actualisation de 12 mois. Vous souhaitez vous assurer que les requêtes pour la partition d’actualisation actuelle ou pour les partitions historiques, basées sur les périodes de mise à jour et de stockage, ne retournent pas plus de 64 Mo de données.

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

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

Le filtre de la colonne de date est utilisé pour partitionner dynamiquement les données en plages de périodes dans le service Power BI. L’actualisation incrémentielle n’est pas conçue pour 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 comme une mise à jour réelle. Si la suppression se produit dans la plage historique et non dans la plage incrémentielle, elle n’est pas récupérée, ce qui peut entraîner des échecs d’actualisation des données en raison de conflits de clé de partition.

Mode hybride dans le service

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

Problème : les performances des requêtes sont médiocres

Les tables hybrides fonctionnant en mode Importation et DirectQuery nécessitent que toutes les tables associées soient en mode Dual afin qu’elles puissent agir soit mises en cache, soit non mises en cache, selon le contexte de la requête qui est 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 être envoyées à la source de données nécessitant que Power BI récupère plus de données que nécessaire. Étant donné que les tables doubles peuvent agir comme des tables DirectQuery ou Import, cette situation est évitée.

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

Les tables qui fonctionnent actuellement en mode DirectQuery sont facilement basculées en mode Double. Dans les propriétés du tableau, sous Avancé, sélectionnez Double dans la zone de liste du mode stockage. Toutefois, les tables fonctionnant actuellement en mode d'importation nécessitent un travail manuel. Les tables doubles ont les mêmes contraintes fonctionnelles que les tables DirectQuery. Power BI Desktop ne peut donc pas convertir les tables d’importation, car elles peuvent s’appuyer sur d’autres fonctionnalités non 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 : Les résultats des requêtes de cache Power BI améliorent les performances et réduisent la charge back-end

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. Éviter les requêtes de source de données inutiles améliore les performances et réduit la charge de source de données, mais cela peut également signifier que les dernières modifications de données à la source ne sont pas incluses dans les résultats.

Solution : Configurer l’actualisation automatique de la page

Pour continuer à extraire les dernières modifications de données de la source, configurez l’actualisation automatique des pages pour vos rapports dans le service Power BI. L’actualisation automatique de la page peut être effectuée dans des intervalles fixes, tels que 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 des visuels sur une page en fonction de la détection des modifications dans les 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 pour les modifications. La détection des modifications n’est prise en charge que dans les espaces de travail qui font partie d’une capacité Premium. Pour plus d’informations, consultez Actualisation automatique des pages dans Power BI.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-11-19