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 dataflows Power BI vous permettent de vous connecter, de transformer, de combiner et de distribuer des données pour l’analytique en aval. Un élément clé dans les 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 temps d’exécution, les performances et si vous obtenez le meilleur parti de votre dataflow, vous pouvez télécharger l’historique d’actualisation après avoir actualisé un dataflow.
Comprendre les actualisations
Il existe deux types d’actualisations applicables aux flux de données :
Complète, qui effectue un vidage et le rechargement complet de vos données.
Incrémentiel (Premium uniquement) qui traite un sous-ensemble de vos données en fonction de règles basées sur le temps, exprimées sous forme de filtre, que vous configurez. Le filtre sur la colonne de date partitionne dynamiquement les données en plages dans le service Power BI. Après avoir configuré l’actualisation incrémentielle, le flux de données modifie automatiquement votre requête pour inclure le filtrage par date. Vous pouvez modifier la requête générée automatiquement à l’aide de l’éditeur avancé dans Power Query pour affiner ou personnaliser votre actualisation. Si vous apportez votre propre stockage Azure Data Lake, vous pouvez voir les tranches de temps de vos données en fonction de la stratégie d’actualisation que vous avez définie.
Note
Pour en savoir plus sur l’actualisation incrémentielle et son fonctionnement, consultez Utilisation de l’actualisation incrémentielle avec des dataflows.
L’actualisation incrémentielle active les flux de données volumineux dans Power BI avec 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 N spécifiées par l’utilisateur (où la partition est jour/semaine/mois, et ainsi de suite) ou
- Power BI actualise uniquement les données qui doivent être actualisées. Par exemple, actualisez uniquement les cinq derniers jours d’un modèle sémantique de 10 ans.
- Power BI actualise uniquement les données qui ont changé, à condition que vous spécifiiez la colonne dans laquelle vous souhaitez vérifier les modifications.
Les actualisations sont plus fiables : il n’est plus nécessaire de maintenir des connexions longues aux systèmes sources volatiles.
La consommation de ressources est réduite : moins de données à actualiser réduisent la consommation globale de mémoire et d’autres ressources.
Dans la mesure du possible, Power BI utilise le traitement parallèle sur les partitions, ce qui peut entraîner des actualisations plus rapides.
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 se termine, ou vous pouvez l’actualiser manuellement et elle peut ensuite se terminer sans erreur. L’actualisation se produit sur une partition ou une entité. Par conséquent, si une actualisation incrémentielle échoue ou qu’une entité a une erreur, la transaction d’actualisation entière ne se produit pas. Dit une autre façon, si une partition (stratégie d’actualisation incrémentielle) ou une entité échoue pour un flux de données, l’opération d’actualisation entière échoue et aucune donnée n’est mise à jour.
Comprendre et optimiser les actualisations
Pour mieux comprendre comment une opération d’actualisation du flux de données s’effectue, passez en revue l’historique des actualisations pour le flux de données en accédant à l’un de vos dataflows. Sélectionnez Plus d’options (...) pour le flux de données. Choisissez ensuite Paramètres> Historique de l'actualisation. Vous pouvez également sélectionner le flux de données dans l’espace de travail. Ensuite, choisissez Plus d’options (...) > Historique d’actualisation.
L’historique des actualisations fournit une vue d’ensemble des actualisations, notamment le type , à la demande ou planifié, 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 à l’extrême droite de la ligne de la description d’actualisation. Le fichier CSV téléchargé inclut les attributs décrits dans le tableau suivant. Les actualisations Premium fournissent plus d’informations en fonction des fonctionnalités de calcul et de dataflows supplémentaires, par rapport aux flux de données pro qui résident sur une capacité partagée. Par conséquent, certaines des métriques suivantes sont disponibles uniquement dans Premium.
| Élément | Descriptif | Pro | Premium |
|---|---|---|---|
| Demandé sur | L'actualisation de l'heure a été planifiée ou l'actualisation a été lancée maintenant, à l'heure locale. | ✔ | ✔ |
| Nom du flux de données | Nom de votre dataflow. | ✔ | ✔ |
| État de l’actualisation du flux de données | Les statuts possibles pour une entité sont complété, échoué ou ignoré. Les cas d’usage tels que les entités liées sont des raisons pour lesquelles on pourrait observer des omissions. | ✔ | ✔ |
| Nom de l’entité | Nom de la table. | ✔ | ✔ |
| Nom de la partition | Cet élément dépend du fait que le flux de données est premium ou non, et si Pro indique na, car il ne prend pas en charge les actualisations incrémentielles. Premium affiche FullRefreshPolicyPartition ou IncrementalRefreshPolicyPartition-[DateRange]. | ✔ | |
| État d’actualisation | État d’actualisation de l’entité ou de la partition individuelle, qui fournit l’état de cette tranche de temps des données actualisées. | ✔ | ✔ |
| Heure de début | Dans Premium, cet élément est le moment où le flux de données a été mis en file d’attente pour le traitement de l’entité ou de la partition. Cette fois-ci peut différer si les dataflows ont des dépendances et doivent attendre que le jeu de résultats d’un dataflow en amont commence le traitement. | ✔ | ✔ |
| Heure de fin | L’heure de fin est l’heure à laquelle l’entité ou la partition de flux de données est terminée, le cas échéant. | ✔ | ✔ |
| Durée | Temps écoulé total pour l’actualisation du flux de données exprimé en 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 en fonction de 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 lorsque les données y sont traitées. | ✔ | |
| Octets traités | Pour une entité ou une partition donnée, données écrites par le moteur de flux de données, exprimées en octets. Lorsque vous utilisez une passerelle sur ce dataflow particulier, ces informations ne sont pas fournies. |
✔ | |
| Engagement maximal (Ko) | Max Commit est la mémoire de validation maximale utile pour diagnostiquer les échecs de mémoire insuffisante lorsque la requête M n’est pas optimisée. Lorsque vous utilisez une passerelle sur ce dataflow particulier, ces informations ne sont pas fournies. |
✔ | |
| Temps processeur | Pour une entité ou une partition donnée, le temps, exprimé en HH :MM :SS que le moteur de flux de données a passé à effectuer des transformations. Lorsque vous utilisez une passerelle sur ce dataflow particulier, ces informations ne sont pas fournies. |
✔ | |
| Temps d’attente | Pour une entité ou une partition donnée, temps passé par une entité dans l’é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, détails sur la façon dont l’opération d’actualisation utilise le moteur de calcul. Les valeurs sont les suivantes : – NA -Plié - Cache - Mis en cache + plié Ces éléments sont décrits plus en détail plus loin dans cet article. |
✔ | |
| Erreur | Le cas échéant, le message d’erreur détaillé est décrit par entité ou partition. | ✔ | ✔ |
Conseils d’actualisation du flux de données
Les statistiques d’actualisation fournissent des informations précieuses que vous pouvez utiliser pour optimiser et accélérer les performances de vos dataflows. 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 dataflows A, B et C dans un espace de travail unique et un chaînage comme 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 indépendamment. En outre, si vous ajoutez une nouvelle source de données dans le flux de données B (qui n’est pas inclus dans A) que les données ne sont pas actualisées dans le cadre de l’orchestration.
Vous souhaiterez peut-être chaîner des éléments qui ne correspondent pas à l’orchestration managée que Power BI effectue. Dans ces scénarios, vous pouvez utiliser les API et/ou utiliser Power Automate. Vous pouvez consulter la documentation de l’API et le script PowerShell pour l’actualisation par programmation. Il existe un connecteur Power Automate qui permet d’effectuer cette procédure sans écrire de code. Vous pouvez voir des exemples détaillés, avec des procédures pas à pas spécifiques pour les actualisations séquentielles.
Supervision
À l’aide des statistiques d’actualisation améliorées décrites plus haut dans cet article, vous pouvez obtenir des informations détaillées sur l’actualisation par flux de données. Toutefois, si vous souhaitez voir des flux de données avec une vue d’ensemble des actualisations à l’échelle du locataire ou de l’espace de travail, peut-être pour créer un tableau de bord de surveillance, vous pouvez utiliser les API ou lesmodèles Power Automate. De même, pour les cas d’usage tels que l’envoi de notifications simples ou complexes, vous pouvez utiliser le connecteur Power Automate ou créer votre propre application personnalisée à l’aide des API.
Erreurs de délai d’expiration
L’optimisation du temps nécessaire pour effectuer 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’expiration explicites que vous pouvez configurer. Pour plus d’informations, consultez Connecteurs dans Power Query.
- Les dataflows Power BI, à l’aide de Power BI Pro, peuvent également rencontrer des délais d’expiration pour les requêtes longues au sein d’une entité ou de dataflows eux-mêmes. Cette limitation n’existe pas dans les espaces de travail Power BI Premium.
Conseils sur le délai d’expiration
Les seuils de délai d’expiration pour les dataflows Power BI Pro sont les suivants :
- Deux heures au niveau de l’entité individuelle.
- Trois heures au niveau du flux de données entier.
Par exemple, si vous avez un dataflow avec trois tables, aucune table individuelle ne peut prendre plus de deux heures et l’ensemble du flux de données expire si la durée dépasse trois heures.
Si vous rencontrez des timeouts, envisagez d’optimiser vos flux de données de requêtes et d’utiliser le pliage des requêtes sur vos systèmes sources.
Envisagez séparément la mise à niveau vers Premium par utilisateur, qui n’est pas soumise à ces délais d’attente et offre des performances accrues en raison de nombreuses fonctionnalités Power BI Premium par utilisateur.
Durées longues
Les dataflows complexes ou volumineux peuvent prendre plus de temps pour s’actualiser, car les dataflows mal optimisés peuvent prendre plus de temps. 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 dataflows consiste à créer des dataflows en fonction des meilleures pratiques. Les modèles notables sont les suivants :
- Utilisez des entités liées pour les données qui peuvent être utilisées ultérieurement dans d’autres transformations.
- Utilisez des entités calculées pour mettre en cache des données, ce qui réduit le chargement des données et la charge d’ingestion des données sur les systèmes sources.
- Fractionnez les données en dataflows intermédiaires et les dataflows de transformation, en séparant l’ETL en différents dataflows.
- Optimisez l’expansion des opérations de table.
- Suivez les instructions pour les dataflows complexes.
Ensuite, il peut vous aider à é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 les filtres de partition soient envoyés au système source lorsque les requêtes sont envoyées pour les opérations d’actualisation. Pour appliquer le filtrage en profondeur, la source de données doit prendre en charge le plissement de requêtes, ou vous pouvez mettre en œuvre une logique métier par une fonction ou d’autres moyens qui peuvent 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, les sources de données telles que les fichiers plats, les objets blob et les API ne prennent généralement pas en charge le filtrage. Dans les cas où le back-end de source de données ne prend pas en charge le filtre, il ne peut pas être poussé vers le bas. Dans ce cas, le moteur mash-up 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 entraîner la lenteur de l’actualisation incrémentielle et le processus peut manquer de ressources dans le service Power BI ou dans la passerelle de données locale, si elle est utilisée.
Étant donné les différents niveaux de prise en charge du pliage des requêtes pour chaque source de données, vous devez effectuer la vérification pour vous assurer 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 pas à pas pour Power Query Online. La plupart de ces optimisations sont des expériences au moment du design, mais après une actualisation, vous avez la possibilité d’analyser et d’optimiser vos performances d’actualisation.
Enfin, envisagez d’optimiser votre environnement. Vous pouvez optimiser l’environnement Power BI en effectuant un scale-up de votre capacité, en dimensionnant correctement les passerelles de données et en réduisant la latence 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 autre capacité.
Une passerelle est requise chaque fois que Power BI doit accéder aux données qui ne sont pas disponibles directement 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 de passerelle et les recommandations de dimensionnement, consultez le dimensionnement de la passerelle de données locale.
- Évaluez également l’apport des données en premier dans un flux de données intermédiaire et en le référençant en aval à l’aide d’entités liées et calculées.
La latence du réseau peut affecter les performances d’actualisation en augmentant le temps nécessaire pour que les demandes atteignent le service Power BI et pour que les réponses soient remises. Les locataires de Power BI sont affectés à une région spécifique. Pour déterminer l’emplacement de votre locataire, consultez Rechercher la région par défaut de votre organisation. Lorsque les utilisateurs d’un locataire accèdent au service Power BI, leurs requêtes sont toujours acheminées vers cette région. À mesure que les requêtes atteignent le service Power BI, le service peut ensuite envoyer des requêtes supplémentaires, par exemple à la source de données sous-jacente ou à une passerelle de données, qui sont également soumises à une latence réseau.
- Les outils tels qu’Azure Speed Test fournissent une indication de la latence réseau entre le client et la région Azure. En général, pour réduire l’impact de la latence du réseau, essayez de conserver les sources de données, les passerelles et votre cluster Power BI le plus proche possible. Résider dans la même région est préférable. Si la latence réseau est un problème, essayez de localiser des passerelles et des sources de données plus proches de votre cluster Power BI en les plaçant dans des machines virtuelles hébergées dans le cloud.
Temps processeur élevé
Si vous observez un temps d'utilisation du processeur élevé, vous avez probablement des transformations coûteuses qui ne sont pas optimisées. Le temps processeur élevé est dû au nombre d’étapes appliquées que vous avez, 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 élevé.
Tout d’abord, utilisez le pliage des requêtes dans la source de données elle-même, ce qui doit réduire la charge sur le moteur de calcul de flux de données directement. Le pliage des requêtes au sein de la source de données permet au système source d’effectuer la plupart du travail. Le flux de données peut ensuite passer par des requêtes dans le langage natif de la source, plutôt que d’avoir à effectuer tous les calculs en mémoire après la requête initiale.
Toutes les sources de données ne peuvent pas effectuer le pliage des requêtes, et même lorsque le pliage des requêtes est possible, il peut y avoir des dataflows qui effectuent certaines transformations qui ne peuvent pas se plier à la source. Dans ce cas, le moteur de calcul amélioré est une fonctionnalité introduite par Power BI pour améliorer potentiellement les performances jusqu’à 25 fois, pour les transformations en particulier.
Utiliser le moteur de calcul pour optimiser les performances
Bien que Power Query ait une visibilité au moment du design dans le 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 disposez d’un flux de données complexe et que vous effectuez des transformations en mémoire. Cette situation est où les statistiques d’actualisation améliorées peuvent être utiles, car la colonne du moteur de calcul fournit des détails sur l’utilisation ou non du moteur lui-même.
Les sections suivantes fournissent des conseils sur l’utilisation du moteur de calcul et ses statistiques.
Avertissement
Pendant le temps de conception, l’indicateur de pliage dans l’éditeur peut indiquer que la requête ne se plie pas lors de la consommation de données à partir d’un autre dataflow. 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é.
Conseils sur les états du moteur de calcul
Activer le moteur de calcul amélioré et comprendre les différents états est utile. 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 que vos transformations s’exécutent sur le moteur de requête ici. Les paragraphes suivants fournissent différentes situations et des conseils sur ce qu’il faut faire pour chacun d’eux.
NA : cet état signifie que le moteur de calcul n’a pas été utilisé, soit parce que :
- Vous utilisez des dataflows Power BI Pro.
- Vous avez explicitement désactivé le moteur de calcul.
- Vous utilisez le repliement de requêtes sur la source de données.
- Vous effectuez des transformations complexes qui ne peuvent pas utiliser le moteur SQL utilisé pour accélérer les requêtes.
Si vous constatez des délais prolongés et que vous obtenez toujours un statut NA, assurez-vous qu’il est activé et non désactivé accidentellement. L’un des modèles recommandés consiste à utiliser des dataflows intermédiaires pour obtenir initialement vos données dans le service Power BI, puis créer des dataflows au-dessus de ces données, une fois qu’elles se trouvent dans un dataflow intermédiaire. Ce modèle peut réduire la charge sur les systèmes sources et, avec le moteur de calcul, fournir une amélioration de la vitesse pour les transformations et améliorer les performances.
Mis en cache : si vous voyez l’état mis en cache , les données de dataflow ont été stockées dans le moteur de calcul et disponibles pour ê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 à utiliser en aval. Les données mises en cache n’ont pas besoin d’être actualisées plusieurs fois dans le même dataflow. Cette situation est également potentiellement idéale si vous souhaitez l’utiliser pour DirectQuery.
Lorsque la mise en cache est activée, l'impact sur les performances lors de l'ingestion initiale est compensé plus tard, dans le même flux de données ou dans un autre flux de données du même espace de travail.
Si vous avez une durée importante 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 l’ingestion double.
Plié : plié signifie que le flux de données a pu utiliser le calcul SQL pour lire les données. L'entité calculée a utilisé la table SQL pour lire les données, et le SQL utilisé est lié aux structures 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é des données dans un flux de données intermédiaire et l'avez référencé dans ce flux de données. 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 qu’elles ont le potentiel d’ê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, telles que la fusion (jointure), le groupe par (agrégation) et les actions d’ajout (union) dans l’Éditeur de requête.
Mis en cache + plié : lorsque vous voyez mis en cache + plié, il est probable que l’actualisation des données soit optimisée, car vous disposez d’une entité qui fait référence à une autre entité et qui est référencée par une autre entité en amont. Cette opération s’exécute également sur le sql et, par conséquent, a également le potentiel d’amélioration avec le calcul SQL. Pour vous assurer que vous obtenez les meilleures performances possibles, utilisez des transformations qui prennent en charge le pliage SQL, comme la fusion (jointure), le groupe par (agrégation) et les actions d’ajout (union) dans l’Éditeur de requête.
Conseils pour l’optimisation des performances du moteur de calcul
Les étapes suivantes permettent aux charges de travail de déclencher le moteur de calcul et, par conséquent, d’améliorer toujours les performances.
Entités calculées et liées dans le même espace de travail :
Pour l’ingestion, concentrez-vous sur l’obtention des données dans le stockage aussi rapidement que possible, utilisez des filtres uniquement s’ils réduisent la taille globale du modèle sémantique. Séparez votre 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, c’est comme la préparation alimentaire dans une cuisine : la préparation alimentaire est généralement une étape distincte et distincte de la collecte de vos ingrédients crus, et un prérequis pour mettre la nourriture dans le four. De même, vous devez préparer votre logique séparément avant de pouvoir tirer parti du moteur de calcul.
Veillez à effectuer les opérations qui plient, telles que les fusions, les jointures, la conversion et d’autres.
En outre, créez des flux de données dans le respect des lignes directrices et des limitations publiées.
Lorsque le moteur de calcul est activé, mais que les performances sont lentes :
Effectuez les étapes suivantes lors de l'examen de scénarios où le moteur de calcul est actif, mais où vous constatez des performances médiocres :
- Limitez les entités calculées et liées qui existent dans l’espace de travail.
- Lors de votre première actualisation avec le moteur de calcul en fonctionnement, les données sont écrites dans le lac et dans le cache. Cette double écriture entraîne une actualisation plus lente.
- Si vous disposez d’un flux de données lié à plusieurs dataflows, veillez à planifier des actualisations des dataflows sources afin qu’elles ne soient pas toutes actualisées en même temps.
Considérations et limitations
Une licence Power BI Pro a une limite d’actualisation des flux de données de 8 actualisations par jour.
Contenu connexe
- Utilisation de l’actualisation incrémentielle avec des flux de données
- Actualisation incrémentielle et données en temps réel pour les modèles sémantiques
- Bonnes pratiques pour les dataflows
- Fonctionnalités Premium des dataflows
- Considérations et limitations relatives aux flux de données
- Résoudre les problèmes liés aux scénarios d’actualisation