Partager via

Comprendre et optimiser l’actualisation des flux de données

  • Article

Les dataflows Power BI vous permettent de vous connecter, de combiner, de transformer et de distribuer des données pour l’analyse en aval. Un élément clé des dataflows est le processus d’actualisation, qui applique les étapes de transformation que vous avez créées dans les dataflows et met à jour les données dans les éléments eux-mêmes.

Pour comprendre les durées d’exécution, le niveau de performance et si vous profitez au mieux de votre flux de données, vous pouvez télécharger l’historique d’actualisations après l’actualisation d’un flux de données.

Comprendre les actualisations

Il existe deux types d’actualisations applicables aux dataflows :

  • Complète, qui effectue un vidage et un rechargement complets de vos données.

  • Incrémentielle (Premium uniquement) , qui traite un sous-ensemble de vos données en fonction de règles temporelles, exprimées sous la forme d’un filtre que vous configurez. Le filtre sur la colonne de dates sert à répartir en direct les données dans des plages du service Power BI. Une fois l’actualisation incrémentielle configurée, le flux de données modifie automatiquement votre requête pour inclure le filtre par date. Vous pouvez modifier la requête générée automatiquement à l’aide de l’Éditeur avancé dans Power Query afin d’affiner ou de personnaliser votre actualisation. Si vous apportez votre propre instance Azure Data Lake Storage, vous pouvez voir les tranches de temps de vos données en fonction de la stratégie d’actualisation que vous avez définie.

    Notes

    Pour en savoir plus sur l’actualisation incrémentielle et son fonctionnement, consultez Utilisation de l’actualisation incrémentielle avec des flux de données.

L’actualisation incrémentielle permet d’utiliser de grands dataflows dans Power BI et offre les avantages suivants :

  • Les actualisations sont plus rapides après la première actualisation, en raison des faits suivants :

    • Power BI actualise les dernières partitions Nspécifiées par l’utilisateur (où la partition est jour/semaine/mois, etc.) ou
    • Power BI actualise uniquement les données qui doivent être actualisées. Par exemple, vous pouvez actualiser uniquement les données des cinq derniers jours dans un modèle sémantique de 10 ans.
    • Power BI actualise uniquement les données qui ont été modifiées, tant que vous spécifiez la colonne sur laquelle vous souhaitez vérifier les modifications.

  • Actualisations plus fiables : Il n’est plus nécessaire de maintenir des connexions à long terme à des systèmes sources volatiles.

  • Consommation réduite des ressources : Comme il y a moins de données à actualiser, la consommation globale de mémoire et d’autres ressources diminue.

  • Dans la mesure du possible, Power BI utilise le traitement parallèle sur les partitions, ce qui peut accélérer les actualisations.

Dans l’un de ces scénarios d’actualisation, si une actualisation échoue, les données ne sont pas mises à jour. Vos données peuvent être obsolètes jusqu’à ce que la dernière actualisation soit terminée ou vous pouvez les actualiser manuellement et ensuite terminer sans erreur. L’actualisation se produit au niveau d’une partition ou d’une entité. Par conséquent, en cas d’échec de l’actualisation incrémentielle ou si une entité comporte une erreur, l’intégralité de la transaction d’actualisation n’a pas lieu. Autrement dit, si une partition (stratégie d’actualisation incrémentielle) ou une entité échoue pour un flux de données, la totalité de l’opération d’actualisation échoue et aucune donnée n’est mise à jour.

Comprendre et optimiser les actualisations

Pour mieux comprendre le fonctionnement d’une opération d’actualisation de flux de données, examinez l’Historique des actualisations du flux de données en accédant à un de vos flux de données. Sélectionnez Plus d’options (...) pour le flux de données. Choisissez ensuite Paramètres > Actualiser l’historique. Vous pouvez également sélectionner le flux de données dans Espace de travail. Choisissez ensuite Plus d’options (...) > Actualiser l’historique.

Screenshot of dataflows refresh history.

L’Historique des actualisations fournit une vue d’ensemble des actualisations, y compris le type, à la demande ou planifiée, la durée et l’état d’exécution. Pour afficher les détails sous la forme d’un fichier CSV, sélectionnez l’icône de téléchargement située à l’extrême droite de la ligne de la description de l’actualisation. Le fichier CSV téléchargé comprend les attributs décrits dans le tableau suivant. Les actualisations Premium fournissent des informations supplémentaires basées sur les capacités de calcul et de flux de données supplémentaires, plutôt que sur des flux de données basés sur la capacité partagée. Par conséquent, certaines des métriques suivantes sont disponibles uniquement dans la version Premium.

Élément Description Pro Premium
Demandé le L’heure à laquelle l’actualisation a été planifiée ou à laquelle l’utilisateur a cliqué sur Actualiser maintenant, en heure locale. ✔ ✔
Nom du dataflow Nom de votre flux de données. ✔ ✔
État d’actualisation du dataflow Terminé, Échec ou Ignoré (pour une entité) sont des états possibles. Les cas d’usage comme les entités liées sont les raisons pour lesquelles une actualisation peut être ignorée. ✔ ✔
Nom de l’entité Nom de la table. ✔ ✔
Nom de la partition Cet élément dépend de si le flux de données est Premium ou non et si Pro s’affiche comme N/A parce qu’il ne prend pas en charge les actualisations incrémentielles. Premium affiche FullRefreshPolicyPartition ou IncrementalRefreshPolicyPartition-[DateRange]. ✔
Actualiser l’état L’état d’actualisation de l’entité ou de la partition individuelle, qui fournit l’état pour cette tranche de temps de données actualisées. ✔ ✔
Heure de début Avec Premium, il s’agit de l’heure à laquelle le flux de données a été mis en file d’attente pour être traité pour l’entité ou la partition. Cela peut différer si le flux de données a des dépendances et doit attendre que le jeu de résultats d’un flux de données en amont commence le traitement. ✔ ✔
Heure de fin Il s’agit de l’heure d’exécution de l’entité ou de la partition de flux de données, le cas échéant. ✔ ✔
Duration Temps total écoulé pour l’actualisation du flux de données, exprimé au format HH:MM:SS. ✔ ✔
Lignes traitées Pour une entité ou une partition donnée, le nombre de lignes analysées ou écrites par le moteur de flux de données. Cet élément peut ne pas toujours contenir de données basées sur l’opération que vous avez effectuée. Les données peuvent être omises lorsque le moteur de calcul n’est pas utilisé ou lorsque vous utilisez une passerelle pendant que les données y sont traitées. ✔
Octets traités Pour une entité ou une partition donnée, les données écrites par le moteur de dataflow, exprimées en octets.

Lorsque vous utilisez une passerelle sur ce flux de données particulier, ces informations ne sont pas fournies.		 ✔
Validation maximale (ko) La validation maximale est la mémoire de validation maximale utile pour diagnostiquer les défaillances de mémoire insuffisante lorsque la requête M n’est pas optimisée.

Lorsque vous utilisez une passerelle sur ce flux de données particulier, ces informations ne sont pas fournies.		 ✔
Temps processeur Pour une entité ou une partition donnée, le temps, exprimé au format HH:MM:SS, passé par le moteur de flux de données à effectuer des transformations.

Lorsque vous utilisez une passerelle sur ce flux de données particulier, ces informations ne sont pas fournies.		 ✔
Temps d’attente Pour une entité ou une partition donnée, le temps passé par une entité en état d’attente, en fonction de la charge de travail sur la capacité Premium. ✔
Moteur de calcul Pour une entité ou une partition donnée, des détails sur la façon dont le moteur de calcul est utilisé dans l’opération d’actualisation. Les valeurs sont :
- N/A
- Replié
- Mis en cache
- Mis en cache + replié

Ces éléments sont traités plus en détail ultérieurement dans cet article.		 ✔
Error Le cas échéant, le message d’erreur détaillé est décrit par entité ou partition. ✔ ✔

Guide d’actualisation des dataflows

Les statistiques d’actualisation fournissent des informations précieuses que vous pouvez utiliser pour optimiser et accélérer les performances de votre dataflow. Dans les sections suivantes, nous décrivons certains scénarios, ce qu’il faut surveiller et comment optimiser en fonction des informations fournies.

Orchestration

L’utilisation de dataflows dans le même espace de travail permet une orchestration simple. Par exemple, vous pouvez avoir des flux de données A, B et C dans un seul espace de travail et les enchaîner sous la forme A > B > C. Si vous actualisez la source (A), les entités en aval sont également actualisées. Toutefois, si vous actualisez C, vous devez actualiser les autres actualisations indépendamment. De même, si vous ajoutez une nouvelle source de données dans le flux de données B (qui n’est pas incluse dans A), ces données ne sont pas actualisées dans le cadre de l’orchestration.

Vous souhaiterez peut-être enchaîner des éléments qui ne correspondent pas à l’orchestration managée effectuée par Power BI. Dans ces scénarios, vous pouvez utiliser les API et/ou utiliser Power Automate. Vous pouvez vous reporter à la documentation de l’API et au script PowerShell pour l’actualisation par programme. Il existe un connecteur Power Automate qui permet d’y parvenir sans écrire de code. Vous pouvez consulter des exemples détaillés, avec des procédures d’ actualisation séquentielle spécifiques.

Surveillance

À l’aide des statistiques d’actualisation améliorées décrites précédemment dans cet article, vous pouvez obtenir des informations détaillées sur l’actualisation par dataflow. Toutefois, si vous souhaitez voir des dataflows avec une vue d’ensemble de l’actualisation à l’échelle du locataire ou de l’espace de travail, par exemple pour créer un tableau de bord de surveillance, vous pouvez utiliser les API ou les modèles PowerAutomate. De même, pour des cas d’usage tels que l’envoi de notifications simples ou complexes, vous pouvez utiliser le connecteur PowerAutomate ou générer votre propre application personnalisée à l’aide des API.

Erreurs de délai d’expiration

L’optimisation du temps nécessaire pour réaliser des scénarios d’extraction, de transformation et de chargement (ETL) est idéale. Dans Power BI, les cas suivants s’appliquent :

  • Certains connecteurs ont des paramètres de délai d’attente explicites que vous pouvez configurer. Pour plus d’informations, consultez Connecteurs dans Power Query.
  • Les dataflows Power BI, avec Power BI Pro, peuvent également subir des délais d’attente pour les requêtes longues dans une entité ou dans les dataflows eux-mêmes. Cette limitation n’existe pas dans les espaces de travail Power BI Premium.

Indications pour le délai d’expiration

Les seuils de délai d’attente pour les flux de données Power BI Pro sont les suivants :

  • Deux heures au niveau de l’entité individuelle.
  • Trois heures au niveau du flux de données en entier.

Par exemple, si vous avez un flux de données avec trois tables, aucune table individuelle ne peut durer plus de deux heures et l’intégralité du flux de données expire si la durée est supérieure à trois heures.

Si vous rencontrez des délais d’attente, envisagez d’optimiser vos requêtes de flux de données et d’utiliser le pliage des requêtes sur vos systèmes sources.

Procédez séparément à la mise à niveau vers Premium par utilisateur, qui n’est pas soumise à ces délais et offre de meilleures performances en raison des nombreuses caractéristiques de Power BI Premium par utilisateur.

Durées longues

L’actualisation des dataflows complexes ou de grande taille peut prendre plus de temps. Cela vaut aussi pour les dataflows mal optimisés. Les sections suivantes fournissent des conseils sur la façon d’atténuer les durées d’actualisation longues.

Conseils pour les durées d’actualisation longues

La première étape pour améliorer les durées d’actualisation longues pour les flux de données consiste à créer des flux de données en suivant nos meilleures pratiques. Ces modèles incluent les éléments importants suivants :

Ensuite, il peut être utile d’évaluer si vous pouvez utiliser l’actualisation incrémentielle.

L’utilisation de l’actualisation incrémentielle peut améliorer les performances. Il est important que le filtre de partition soit poussé vers le système source lorsque des requêtes sont envoyées pour les opérations d’actualisation. Pousser le filtrage signifie que la source de données doit prendre en charge le pliage des requêtes, ou vous pouvez exprimer la logique métier à l’aide d’une fonction ou d’un autre moyen qui peut aider Power Query à éliminer et filtrer des fichiers ou des dossiers. La plupart des sources de données qui prennent en charge les requêtes SQL prennent en charge le pliage des requêtes, et certains flux OData peuvent également prendre en charge le filtrage.

Toutefois, ce n’est généralement pas le cas des sources de données telles que les fichiers plats, les blobs et les API, qui ne prennent pas en charge le filtrage. Si le back-end de la source de données ne prend pas en charge le filtre, la transmission de type push vers le bas est impossible. Dans ces cas, le moteur de combinaison compense et applique le filtre localement, ce qui peut nécessiter la récupération du modèle sémantique complet à partir de la source de données. Cette opération peut ralentir sensiblement l’actualisation incrémentielle et le processus peut manquer de ressources dans le service Power BI ou dans la passerelle de données locale éventuellement utilisée.

Étant donné les différents niveaux de support du pliage de requêtes pour chaque source de données, il est recommandé de vérifier que la logique de filtre est incluse dans les requêtes sources. Pour faciliter cette opération, Power BI tente d’effectuer cette vérification pour vous, avec des indicateurs de pliage par étape pour Power Query Online. La plupart de ces optimisations sont des expériences au moment de la conception, mais après une actualisation, vous avez la possibilité d’analyser et d’optimiser les performances de l’actualisation.

Enfin, envisagez d’optimiser votre environnement. Vous pouvez optimiser l’environnement Power BI en réduisant votre capacité, en redimensionnant les passerelles de données à la taille idéale et en réduisant la latence du réseau avec les optimisations suivantes :

  • Lorsque vous utilisez des capacités disponibles avec Power BI Premium ou Premium par utilisateur, vous pouvez augmenter les performances en augmentant votre instance Premium ou en affectant le contenu à une capacité différente.

  • La passerelle est obligatoire chaque fois que Power BI accède à des données qui ne sont pas directement disponibles sur Internet. Vous pouvez installer la passerelle de données locale sur un serveur local ou sur une machine virtuelle.

    • Pour comprendre les charges de travail et les suggestions de dimensionnement de la passerelle, consultez Dimensionnement des passerelles de données locales.
    • Évaluez également l’intégration des données dans un flux de données de mise en lots et son référencement en aval à l’aide d’entités liées et calculées.

  • La latence du réseau peut affecter le niveau de performance des actualisations en augmentant le temps nécessaire aux requêtes pour atteindre le service Power BI et aux réponses pour être envoyées. Les abonnés de Power BI sont affectés à une région spécifique. Pour déterminer l’emplacement de votre abonné Power BI, consultez Rechercher la région par défaut de votre organisation. Lorsque les utilisateurs d’un client accèdent au service Power BI, leurs requêtes sont acheminées vers cette région. Lorsque les requêtes atteignent le service Power BI, celui-ci peut ensuite envoyer des requêtes supplémentaires (par exemple, à la source de données sous-jacente ou à la passerelle) qui sont également soumises à la latence du réseau.

    • Des outils tels que Azure Speed Test donnent une indication de la latence du réseau entre le client et la région Azure. De manière générale, pour minimiser l’impact de la latence du réseau, essayez de rapprocher le plus possible les sources de données, les passerelles et votre cluster Power BI. Il est préférable de résider dans la même région. Si la latence du réseau pose problème, essayez de rapprocher les passerelles et les sources de données de votre cluster Power BI en les plaçant sur des machines virtuelles hébergées sur le cloud.

Temps processeur élevé

Si vous constatez un temps de processeur élevé, probablement, des transformations coûteuses qui ne sont pas pliées. Le temps du processeur élevé est dû au nombre d’étapes appliquées ou au type de transformations que vous effectuez. Chacune de ces possibilités peut entraîner des temps d’actualisation plus élevés.

Conseils pour le temps processeur élevé

Il existe deux options pour optimiser le temps processeur.

Tout d’abord, utilisez le pliage de requêtes dans la source de données elle-même, ce qui devrait réduire directement la charge sur le moteur de calcul du flux de données. Le pliage des requêtes dans la source de données permet au système source d’effectuer la majeure partie du travail. Le flux de données peut alors passer au travers des requêtes dans le langage natif de la source, plutôt que de devoir effectuer tous les calculs dans la mémoire après la requête initiale.

Toutes les sources de données ne peuvent pas effectuer le pliage de requêtes et même lorsque le pliage de requêtes est possible, certains flux de données peuvent effectuer certaines transformations qui ne peuvent pas être pliées vers la source. Dans ce cas, le moteur de calcul amélioré est une capacité introduite par Power BI pour améliorer potentiellement le niveau de performance jusqu’à 25 fois, particulièrement pour les transformations.

Utiliser le moteur de calcul pour maximiser le niveau de performance

Bien que Power Query ait une visibilité sur la conception du pliage des requêtes, la colonne du moteur de calcul fournit des détails sur l’utilisation du moteur interne lui-même. Le moteur de calcul est utile lorsque vous avez un flux de données complexe et que vous effectuez des transformations en mémoire. C’est dans cette situation que les statistiques d’actualisation améliorées peuvent être utiles, car la colonne du moteur de calcul fournit des détails sur l’utilisation du moteur lui-même.

Les sections suivantes fournissent des conseils sur l’utilisation du moteur de calcul et ses statistiques.

Avertissement

Pendant la conception, l’indicateur de pliage dans l’éditeur peut montrer que la requête ne se plie pas lorsqu’elle consomme des données provenant d’un autre flux de données. Vérifiez le flux de données source si le calcul amélioré est activé pour vous assurer que le pliage sur le flux de données source est activé.

Aide sur les états du moteur de calcul

Il est utile d’activer le moteur de calcul amélioré et de comprendre les différents états. En interne, le moteur de calcul amélioré utilise une base de données SQL pour lire et stocker des données. Il est préférable de faire en sorte que vos transformations s’exécutent sur le moteur de requête. Les paragraphes suivants présentent différentes situations et des conseils sur la marche à suivre pour chacune d’entre elles.

N/A : cet état signifie que le moteur de calcul n’a pas été utilisé, car :

  • Vous utilisez le flux de données Power BI Pro.
  • Vous avez explicitement désactivé le moteur de calcul.
  • Vous utilisez le pliage des requêtes sur la source de données.
  • Vous effectuez des transformations complexes qui ne peuvent pas utiliser le moteur SQL qui permet d’accélérer les requêtes.

Si vous avez des durées longues et que vous recevez toujours l’état N/A, assurez-vous qu’il est activé et qu’il n’a pas été désactivé accidentellement. Un modèle recommandé consiste à utiliser des flux de données de mise en lots pour amener initialement vos données dans le service Power BI, puis à générer des flux de données sur ces données, une fois qu’elles se trouvent dans un flux de données de mise en lots. Ce modèle peut réduire la charge sur les systèmes sources et, avec le moteur de calcul, accélérer les transformations et améliorer le niveau de performance.

Mis en cache : si vous voyez l’état Mis en cache, les données de flux de données ont été stockées dans le moteur de calcul et peuvent être référencées dans le cadre d’une autre requête. Cette situation est idéale si vous l’utilisez en tant qu’entité liée, car le moteur de calcul met en cache ces données pour une utilisation en aval. Les données mises en cache n’ont pas besoin d’être actualisées plusieurs fois dans le même flux de données. Cette situation peut également s’avérer idéale si vous souhaitez l’utiliser pour DirectQuery.

En cas de mise en cache, l’impact sur le niveau de performance lors de l’ingestion initiale se fait ressentir plus tard, dans le même flux de données ou dans un flux de données différent dans le même espace de travail.

Si vous avez une grande durée pour l’entité, envisagez de désactiver le moteur de calcul. Pour mettre en cache l’entité, Power BI l’écrit dans le stockage et dans SQL. S’il s’agit d’une entité à usage unique, l’avantage en matière de performances pour les utilisateurs peut ne pas valoir la peine de la double ingestion.

Plié : signifie que la flux de données a pu utiliser le calcul SQL pour lire les données. L’entité calculée a utilisé la table de SQL pour lire les données, et le SQL utilisé est lié aux constructions de leur requête.

L’état Plié s’affiche si, lorsque vous utilisez des sources de données locales ou cloud, vous avez d’abord chargé les données dans un dataflow intermédiaire et que vous les référencez dans ce dataflow. Cet état s’applique uniquement aux entités qui font référence à une autre entité. Cela signifie que vos requêtes ont été exécutées sur le moteur SQL et peuvent donc être améliorées avec le calcul SQL. Pour vous assurer que le moteur SQL traite vos transformations, utilisez des transformations qui prennent en charge le pliage SQL, comme la fusion (inviter quelqu'un à prendre part à une conversation), le groupement (agrégation) et les actions d’ajout (union) dans l’Éditeur de requête.

Mise en cache + pliée : quand vous voyez l’état Mise en cache + pliée, il est probable que l’actualisation des données a été optimisée, car une entité fait référence à une autre entité et est référencée par une autre entité en amont. Cela s’exécutera également sur SQL et, par conséquent, pourra également être amélioré avec le calcul SQL. Pour vous assurer d’obtenir les meilleures performances possibles, utilisez des transformations qui prennent en charge le pliage SQL, comme la fusion (jointure), le regroupement (agrégation) et les actions d’ajout (union) dans l’éditeur de requête.

Aide pour l’optimisation du niveau de performance du moteur de calcul

Effectuez les étapes suivantes pour permettre aux charges de travail de déclencher le moteur de calcul afin de toujours améliorer le niveau de performance.

Entités calculées et liées dans le même espace de travail :

Pour l’ingestion, concentrez-vous sur l’obtention aussi rapide que possible des données dans le stockage et utilisez des filtres uniquement s’ils réduisent la taille globale du modèle sémantique. Veillez à séparer la logique de transformation de cette étape. Ensuite, séparez votre transformation et votre logique métier en un flux de données distinct dans le même espace de travail. Utilisez des entités liées ou calculées. Cela permet au moteur d’activer et d’accélérer vos calculs. Pour une analogie simple, il s’agit de la préparation des aliments dans une cuisine : la préparation des aliments constitue généralement une étape distincte de la sélection des ingrédients bruts et une condition préalable à leur cuisson dans le four. De même, vous devez préparer votre logique séparément avant d’exploiter le moteur de calcul.

Veillez à effectuer les opérations de repli, comme les fusions, les jointures, les conversions et autres.

Créez aussi les dataflows conformément aux instructions et limitations publiées.

Quand le moteur de calcul est activé mais que le niveau de performance est faible :

Effectuez les étapes suivantes dans les scénarios où le moteur de calcul est activé, mais que vous constatez de mauvaises performances :

  • Limitez les entités calculées et liées qui existent dans l’espace de travail.
  • Si votre actualisation initiale avec le moteur de calcul est activée, alors les données sont écrites dans le lac et dans le cache. Cette double écriture entraîne un ralentissement des actualisations.
  • Si vous avez un dataflow lié à plusieurs dataflows, vérifiez que vous planifiez les actualisations des dataflows sources de sorte qu’ils ne s’actualisent pas tous en même temps.

Observations et limitations

Une licence Power BI Pro a une limite d’actualisation des flux de données de 8 actualisations par jour.

Contenu connexe