Actualisation incrémentielle pour les jeux de données

L’actualisation incrémentielle étend les opérations d’actualisation planifiées en fournissant une création et une gestion de partition automatisées pour les tables de jeu de données qui chargent fréquemment des données nouvelles et mises à jour. Pour la plupart des jeux de données, il s’agit d’une ou plusieurs tables qui contiennent des données de transaction qui changent souvent et peuvent croître de manière exponentielle, comme une table de faits dans un schéma de base de données relationnel ou en étoile. En partitionnant la table et en actualisant uniquement la ou les partitions les plus récentes, vous réduisez considérablement la quantité de données qui doivent être actualisées.

Avec l’actualisation incrémentielle :

  • Actualisations plus rapides : Seules les données les plus récentes qui ont changé ont besoin d’être actualisées.
  • Actualisations plus fiables : Des connexions de longue durée à des sources de données volatiles ne sont pas nécessaires. Les requêtes aux données sources s’exécutent plus rapidement, ce qui réduit le risque potentiel d’interférence entre les problèmes réseau.
  • 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 les systèmes Power BI et de source de données.
  • Activation des jeux de données volumineux : Les jeux de données avec des milliards de lignes peuvent croître sans qu’il soit nécessaire d’actualiser entièrement l’ensemble du jeu de données avec chaque opération d’actualisation.
  • Installation facile : Les stratégies d’actualisation incrémentielle sont définies dans Power BI Desktop avec seulement quelques tâches. Une fois publiées, le service applique automatiquement ces stratégies à chaque actualisation.

Lorsque vous publiez un modèle Power BI Desktop sur le service, chaque table du nouveau jeu de données a une partition unique. Cette partition unique contient toutes les lignes de cette table. Si la table est volumineuse, par exemple avec des dizaines de millions de lignes ou plus encore, l’actualisation de cette table peut prendre beaucoup de temps et consommer une quantité excessive de ressources.

Avec l’actualisation incrémentielle, le service partitionne et sépare dynamiquement les données qui doivent être actualisées fréquemment à partir des données qui peuvent être actualisées moins fréquemment. Les données de la table sont filtrées à l’aide des paramètres de date/heure de Power Query avec les noms réservés qui respectent la casse RangeStart et RangeEnd. Lors de la configuration initiale de l’actualisation incrémentielle dans Power BI Desktop, les paramètres sont utilisés pour filtrer uniquement une petite période de données à charger dans le modèle. Lors de la publication sur le service, avec la première opération d’actualisation, le service crée une actualisation incrémentielle et des partitions historiques basées sur les paramètres de stratégie d’actualisation incrémentielle, puis remplace les valeurs de paramètres pour filtrer et interroger les données de chaque partition en fonction des valeurs de date/heure de chaque ligne.

Avec chaque actualisation suivante, la requête filtre et retourne uniquement les lignes de la période d’actualisation définies dynamiquement par les paramètres. Les lignes avec une date/heure comprise dans la période d’actualisation sont actualisées. Les lignes dont la date/l’heure n’est plus comprise dans la période d’actualisation deviennent partie intégrante de la période historique, qui n’est pas actualisée. Les périodes d’actualisation et historiques sont restaurées par progression. À mesure que de nouvelles partitions d’actualisation incrémentielle sont créées, les partitions d’actualisation ne sont plus dans la période d’actualisation et deviennent des partitions historiques. Au fil du temps, les partitions historiques deviennent moins granulaires, car elles sont fusionnées ensemble. Lorsqu’une partition historique n’est plus dans la période historique définie par la stratégie, elle est entièrement supprimée du jeu de données. C’est ce qu’on appelle un modèle de fenêtre dynamique.

La beauté de l’actualisation incrémentielle est que le service gère tout cela pour vous en fonction des stratégies d’actualisation incrémentielle que vous définissez. En fait, le processus et les partitions créés à partir de ce dernier ne sont même pas visibles dans le service. Dans la plupart des cas, une stratégie d’actualisation incrémentielle bien définie est tout ce qui est nécessaire pour améliorer considérablement les performances d’actualisation des jeux de données. Toutefois, pour les jeux de données de capacités Premium, des scénarios de partition et d’actualisation plus avancés sont pris en charge via le point de terminaison XMLA.

Spécifications

Plans pris en charge

L’actualisation incrémentielle est prise en charge pour les jeux de données Power BI Premium, Premium par utilisateur, Power BI Pro et Power BI Embedded.

Sources de données prises en charge

L’actualisation incrémentielle fonctionne mieux pour les sources de données relationnelles structurées, comme SQL Database et Azure Synapse, mais peut également fonctionner pour d’autres sources de données. Dans tous les cas, votre source de données doit prendre en charge les éléments suivants :

Colonne de date : La table doit contenir une colonne de date de types de données date/heure ou entier. Les paramètres RangeStart et RangeEnd (qui doivent être de type de données date/heure) filtrent les données de la table en fonction de la colonne de date. Pour les colonnes de date de clés de substitution de type entier sous la forme de yyyymmdd, vous pouvez créer une fonction qui convertit la valeur de date/heure dans les paramètres pour qu’elle corresponde à la clé de substitution de type entier de la table de la source de données. Pour plus d’informations, consultez Configurer l’actualisation incrémentielle : Convertir DateHeure en type entier.

Repli de requête : L’actualisation incrémentielle est conçue pour les sources de données qui prennent en charge le repli de requête, qui est une capacité Power Query pour générer une expression de requête unique pour récupérer et transformer des données sources. La plupart des sources de données qui prennent en charge les requêtes SQL prennent également en charge le « Query folding ». Ce n’est souvent pas le cas des sources de données telles que les fichiers plats, les objets blob et certains flux web.

Lorsque l’actualisation incrémentielle est configurée, une expression Power Query qui comprend un filtre de date/heure basé sur les paramètres RangeStart et RangeEnd est exécutée sur la source de données. Le filtre est appliqué à une transformation incluse dans la requête qui définit une clause WHERE basée sur les paramètres. Dans les cas où le filtre n’est pas pris en charge par la source de données, il ne peut pas être inclus dans l’expression de la requête. Le moteur d’application web hybride de requête compense et applique le filtre localement, ce qui nécessite la récupération de toutes les lignes de la table à partir de la source de données. Cela peut entraîner un ralentissement de l’actualisation incrémentielle, et le processus peut manquer de ressources dans le service Power BI ou dans une passerelle de données locale, ce qui a pour effet de nuire à l’objectif de l’actualisation incrémentielle.

Comme la prise en charge du repli de requête est différente selon les types de sources de données, une vérification doit être effectuée pour s’assurer que la logique de filtre est incluse dans les requêtes exécutées sur la source de données. Dans la plupart des cas, Power BI Desktop tente d’effectuer cette vérification pour vous lors de la définition de la stratégie d’actualisation incrémentielle. Pour les sources de données basées sur SQL, telles que SQL Database, Azure Synapse, Oracle et Teradata, cette vérification est fiable. Cependant, les autres sources de données peuvent ne pas être en mesure d’effectuer la vérification sans suivi des requêtes. Si Power BI Desktop ne parvient pas à confirmer, un avertissement s’affiche dans la boîte de dialogue Configuration de la stratégie d’actualisation incrémentielle.

Avertissement de pliage de requête

Si vous voyez cet avertissement et que vous souhaitez vérifier que le repli de requête nécessaire se produit, utilisez la fonctionnalité Power Query Diagnostics ou les requêtes de suivi à l’aide d’un outil pris en charge par la source de données, comme SQL Profiler. Si le repli de requête ne se produit pas, vérifiez que la logique de filtre est incluse dans la requête transmise à la source de données. Si ce n’est pas le cas, il est probable que la requête inclue une transformation qui empêche le repli.

Avant de configurer votre solution d’actualisation incrémentielle, veillez à lire et à comprendre soigneusement les articles Guide sur le pliage de requête dans Power BI Desktop et Repli de requête Power Query. Ces articles peuvent vous aider à déterminer si votre source de données et vos requêtes prennent en charge le repli des requêtes.

Autre types de sources de données

En utilisant des fonctions de requête et une logique de requête personnalisées supplémentaires, l’actualisation incrémentielle peut être utilisée avec d’autres types de sources de données, à condition que les filtres basés sur RangeStart et RangeEnd puissent être transmis dans une seule requête. Par exemple, les fichiers de classeur Excel stockés dans un dossier, les fichiers dans SharePoint ou les flux RSS. Gardez à l’esprit qu’il s’agit de scénarios avancés qui nécessitent une personnalisation et des tests supplémentaires à ce qui est décrit ici. Veillez à consulter la section Communauté plus loin dans cet article pour obtenir des suggestions sur la façon dont vous pouvez trouver plus d’informations sur l’utilisation de l’actualisation incrémentielle pour des scénarios uniques comme ceux-ci.

Limites de temps

Indépendamment de l’actualisation incrémentielle, les jeux de données Power BI Pro ont une limite de temps d’actualisation de deux heures. Pour les jeux de données d’une capacité Premium, la limite de temps est de cinq heures. Les opérations d’actualisation utilisent beaucoup de processeurs et de mémoire. Une opération d’actualisation complète peut utiliser jusqu’à deux fois la quantité de mémoire requise par le jeu de données uniquement parce que le service conserve un instantané du jeu de données en mémoire jusqu’à la fin de l’opération d’actualisation. Les opérations d’actualisation peuvent également utiliser beaucoup de processeurs, ce qui consomme une quantité importante de ressources processeur disponibles. Les opérations d’actualisation doivent également reposer sur des connexions volatiles aux sources de données et la capacité de ces systèmes de source de données à retourner rapidement le résultat de la requête. La limite de temps est un dispositif de protection permettant de limiter la surconsommation des ressources disponibles.

Notes

Avec les capacités Premium, les opérations d’actualisation effectuées via le point de terminaison XMLA n’ont pas de limite de temps. Pour en savoir plus, consultez Actualisation incrémentielle avancée avec le point de terminaison XMLA.

Étant donné que l’actualisation incrémentielle optimise les opérations d’actualisation au niveau de la partition dans le jeu de données, la consommation des ressources peut être considérablement réduite. En même temps, même avec l’actualisation incrémentielle, sauf via le point de terminaison XMLA, les opérations d’actualisation sont liées par ces deux mêmes limites de deux et cinq heures. Une stratégie d’actualisation incrémentielle efficace réduit non seulement la quantité de données traitées avec une opération d’actualisation, mais elle réduit également la quantité de données historiques inutiles stockées dans votre jeu de données.

Les requêtes peuvent également être limitées par une limite de temps par défaut pour la source de données. La plupart des sources de données relationnelles permettent de remplacer la limite de temps dans l’expression Power Query M. Par exemple, l’expression ci-dessous utilise la fonction d’accès aux données de SQL Server pour définir CommandTimeout sur 2 heures. Chaque période définie par les plages de la stratégie soumet une requête qui respecte le paramètre de délai d’expiration de la commande.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Pour les jeux de données très volumineux dans les capacités Premium qui contiennent probablement des milliards de lignes, l’opération d’actualisation initiale peut être amorcée. L’amorçage permet au service de créer des objets de table et de partition pour le jeu de données, mais pas de charger et de traiter les données dans l’une des partitions. En utilisant SQL Server Management Studio, les partitions peuvent être traitées individuellement, séquentiellement ou en parallèle, ce qui permet de réduire la quantité de données retournées dans une requête unique, mais également de contourner la limite de cinq heures. Pour plus d’informations, consultez Actualisation incrémentielle avancée - Empêcher les délais d’attente lors de l’actualisation complète initiale.

Date et heure actuelles

La date et l’heure actuelles sont basées sur la date système au moment de l’actualisation. Si l’actualisation planifiée est activée pour le jeu de données dans le service, le fuseau horaire spécifié est pris en compte pour la détermination de la date et heure actuelles. Les actualisations planifiées et individuelles sont actualisées via le service et tiennent compte du fuseau horaire s’il est disponible. Par exemple, une actualisation qui se produit à 20 h heure du Pacifique (États-Unis et Canada) avec un fuseau horaire spécifié détermine la date et l’heure actuelles en fonction de l’heure du Pacifique et non de l’heure GMT (qui correspondrait au jour suivant). Les opérations d’actualisation qui ne sont pas appelées par le service, comme la commande d’actualisation TMSL, ne prennent pas en compte le fuseau horaire de l’actualisation planifiée.

Fuseau horaire

Configuration d’une actualisation incrémentielle

Nous allons passer en revue les concepts importants de la configuration de l’actualisation incrémentielle ici. Lorsque vous êtes prêt à obtenir des instructions pas à pas détaillées, consultez Configurer l’actualisation incrémentielle pour les jeux de données.

La configuration de l’actualisation incrémentielle s’effectue dans Power BI Desktop. Pour la plupart des modèles, seules quelques tâches sont requises. Toutefois, gardez ce qui suit à l’esprit :

  • En cas de publication sur le service, vous ne pouvez pas publier à nouveau le même modèle à partir de Power BI Desktop. La republication entraîne la suppression des partitions et des données existantes déjà présentes dans le jeu de données. Si vous publiez sur une capacité Premium, les modifications de schéma de métadonnées ultérieures peuvent être apportées avec ALM Toolkit Open source ou à l’aide du langage TMSL (Tabular Model Scripting Language). Pour plus d’informations, consultez Actualisation incrémentielle avancée - Déploiement de métadonnées uniquement.
  • En cas de publication sur le service, vous ne pouvez plus télécharger le jeu de données en tant que PBIX pour Power BI Desktop. Comme les jeux de données du service peuvent croître de manière importante, il est difficile de les télécharger et de les ouvrir sur un ordinateur de bureau classique.

Créer des paramètres

Lors de la configuration de l’actualisation incrémentielle dans Power BI Desktop, vous créez d’abord deux paramètres de date/heure Power Query avec les noms réservés, sensibles à la casse, RangeStart et RangeEnd. Ces paramètres, définis dans la boîte de dialogue Gérer les paramètres d’Éditeur Power Query, servent initialement à filtrer les données chargées dans la table de modèle Power BI Desktop pour inclure uniquement les lignes avec une date/heure comprises dans cette période. Une fois le modèle publié sur le service, les paramètres RangeStart et RangeEnd sont automatiquement remplacés par le service pour interroger les données définies par la période d’actualisation spécifiée dans les paramètres de stratégie d’actualisation incrémentielle.

Par exemple, la table de source de données FactInternetSales calcule la moyenne de 10 000 nouvelles lignes par jour. Pour limiter le nombre de lignes initialement chargées dans le modèle dans Power BI Desktop, nous spécifions une période de deux jours entre RangeStart et RangeEnd.

Boîte de dialogue Gérer les paramètres

Filtrer les données

Avec les paramètres RangeStart et RangeEnd définis, vous appliquez ensuite des filtres Date personnalisés à la colonne de date de votre table. Les filtres que vous appliquez sélectionnent un sous-ensemble de données qui seront chargées dans le modèle en cliquant sur Appliquer.

Filtre personnalisé

À l’aide de notre exemple FactInternetSales, après avoir créé des filtres basés sur les paramètres et appliqué des étapes, deux jours de données, soit environ 20 000 lignes, sont chargées dans notre modèle.

Définir une stratégie

Une fois que les filtres ont été appliqués et qu’un sous-ensemble de données a été chargé dans le modèle, vous définissez une stratégie d’actualisation incrémentielle pour la table. Une fois le modèle publié sur le service, la stratégie est utilisée par le service pour créer et gérer des partitions de table et effectuer des opérations d’actualisation.

Pour définir la stratégie, il existe trois paramètres obligatoires et deux paramètres facultatifs :

Boîte de dialogue Définir la stratégie

1 - Table

La zone de liste de la table est définie par défaut sur la table que vous sélectionnez dans la vue Données. Activez l’actualisation incrémentielle pour la table avec le curseur. Si l’expression Power Query pour la table n’inclut pas de filtre basé sur les paramètres RangeStart et RangeEnd, le bouton bascule est désactivé.

2 - Stocker les lignes du dernier

Ce paramètre obligatoire détermine la période historique dans laquelle les lignes avec une date/heure comprises dans cette période sont incluses dans le jeu de données, plus les lignes de la période historique incomplète en cours, plus les lignes de la période d’actualisation jusqu’à la date et l’heure actuelles.

Par exemple, si nous spécifions 5 ans, notre table stocke les cinq dernières années de données historiques en partitions d’année, ainsi que les lignes pour l’année en cours dans les partitions du trimestre, du mois ou du jour, jusqu’à la période d’actualisation incluse.

Pour les jeux de données des capacités Premium, les partitions historiques obsolètes peuvent être actualisées de manière sélective à une granularité déterminée par ce paramètre. Pour plus d’informations, consultez Actualisation incrémentielle avancée - Partitions.

3 - Actualiser les lignes du dernier

Ce paramètre obligatoire détermine la période d’actualisation incrémentielle dans laquelle toutes les lignes ayant une date/heure comprise dans cette période sont incluses dans la ou les partitions d’actualisation et sont actualisées à chaque opération d’actualisation.

Par exemple, si vous spécifiez une période d’actualisation de 10 jours, le service remplace les paramètres RangeStart et RangeEnd à chaque opération d’actualisation pour créer une requête pour les lignes avec une date/heure au cours d’une période de dix jours, en commençant et en finissant en fonction de la date et de l’heure actuelles. Les lignes avec une date/heure au cours des 10 derniers jours jusqu’à l’heure de l’opération d’actualisation actuelle sont actualisées. Avec ce type de stratégie, nous pouvons espérer que notre table de jeu de données FactInternetSales dans le service, qui calcule la moyenne de 10 000 nouvelles lignes par jour, actualise environ 100 000 lignes à chaque opération d’actualisation.

Veillez à spécifier une période qui comprend uniquement le nombre minimal de lignes nécessaires pour garantir la précision des rapports. Si vous définissez des stratégies pour plusieurs tables, vous devez utiliser les mêmes paramètres RangeStart et RangeEnd, même si différentes périodes de stockage et d’actualisation sont définies pour chaque table.

4 - Détecter les changements de données

Ce paramètre est facultatif. L’actualisation incrémentielle de 10 jours est plus efficace qu’une actualisation complète de cinq années. Toutefois, l’actualisation peut être encore plus sélective. Avec l’option Détecter les changements de données, vous pouvez sélectionner une colonne date/heure à utiliser pour identifier et actualiser uniquement ces jours où les données ont changé. Cela suppose que cette colonne existe dans la source de données, généralement à des fins d’audit. Il ne doit pas s’agir de la même colonne que celle utilisée pour partitionner les données avec les paramètres RangeStart et RangeEnd. La valeur maximale de cette colonne est évaluée pour chacune des périodes définies dans la plage incrémentielle. Si cette valeur n’a pas changé depuis la dernière actualisation, la période n’a pas besoin d’être actualisée. Dans cet exemple, cela peut potentiellement réduire les jours concernés par l’actualisation incrémentielle de dix à deux environ.

Dans la conception actuelle, la colonne utilisée pour détecter les changements de données doit être persistante et mise en mémoire cache. Les techniques suivantes peuvent être utilisées pour réduire la cardinalité et la consommation de mémoire :

  • Conservez uniquement la valeur maximale de la colonne au moment de l’actualisation, éventuellement à l’aide d’une fonction Power Query.
  • Diminuez la précision à un niveau acceptable en fonction de vos exigences de fréquence d’actualisation.
  • Définissez une requête personnalisée pour la détection des modifications de données à l’aide du point de terminaison XMLA et évitez de conserver entièrement la valeur de la colonne.

Dans certains cas, l’activation de l’option Détecter les changements de données peut être améliorée. Par exemple, vous pouvez vouloir éviter la persistance de la colonne de la dernière mise à jour dans le cache en mémoire, ou activer des scénarios dans lesquels la table configuration/instruction est préparée par des processus ETL pour signaler uniquement ces partitions qui doivent être actualisées. Dans les cas de ce type, pour les capacités Premium, utilisez la langage TMSL (Tabular Model Scripting Language) et/ou le modèle d’objet tabulaire (TOM) pour remplacer le comportement Détecter les changements de données. Pour plus d’informations, consultez Actualisation incrémentielle avancée - Requêtes personnalisées pour détecter les changements de données.

5 - Actualiser uniquement les jours complets

Ce paramètre est facultatif. Supposons que vous avez planifié l’actualisation à 4 h 00 chaque matin. Si de nouvelles lignes de données s’affichent dans la table de source de données pendant les quatre heures comprises entre minuit et 4 h, vous souhaitez peut-être ne pas en tenir compte. L’actualisation de certaines métriques métier, comme le nombre de barils par jour dans l’industrie du pétrole et du gaz, n’a aucun sens si elle concerne des jours partiels. Un autre exemple est l’actualisation des données d’un système financier où les données du mois précédent sont approuvées le 12e jour calendaire du mois. Vous pouvez définir une période d’actualisation d’un mois et planifier l’actualisation le 12e jour du mois. Par exemple, avec cette option sélectionnée, les données du mois de janvier sont actualisées le 12 février.

N’oubliez pas qu’à moins que l’actualisation planifiée ne soit configurée pour un fuseau horaire non UTC, les opérations d’actualisation dans le service s’exécutent en heure UTC, ce qui peut déterminer la date effective et les périodes complètes effectives.

Publish

Après avoir configuré la stratégie d’actualisation incrémentielle, vous publiez le modèle sur le service. Une fois la publication terminée, vous pouvez effectuer l’opération d’actualisation initiale sur le jeu de données.

Pour les jeux de données publiés dans les espaces de travail affectés aux capacités Premium, si vous pensez que le jeu de données va croître au-delà de 1 Go ou plus, vous pouvez améliorer les performances de l’opération d’actualisation et vous assurer que le jeu de données n’a pas atteint les limites de taille maximale en activant le format de stockage du jeu de données volumineux avant d’effectuer la première opération d’actualisation dans le service. Pour en savoir plus, consultez Jeux de données volumineux dans Power BI Premium.

Important

Après publication sur le service, vous ne pouvez pas télécharger PBIX.

Actualiser

Après publication sur le service, vous effectuez une opération d’actualisation initiale sur le jeu de données. Cette actualisation doit être individuelle (manuelle) pour vous permettre de surveiller la progression. L’opération d’actualisation initiale peut prendre un certain temps. Les partitions doivent être créées, les données historiques chargées, les objets tels que les relations et les hiérarchies sont générés ou reconstruits, et les objets calculés sont recalculés.

Les opérations d’actualisation ultérieures, individuelles ou planifiées, sont beaucoup plus rapides, car seules la ou les partitions d’actualisation incrémentielles sont actualisées. D’autres opérations de traitement doivent toujours avoir lieu, comme la fusion de partitions et le recalcul, mais il ne prend généralement qu’une petite fraction de temps par rapport à l’actualisation initiale.

Actualisation incrémentielle avancée

Si votre jeu de données est sur une capacité Premium avec le point de terminaison XMLA activé, l’actualisation incrémentielle peut être étendue pour des scénarios avancés. Par exemple, vous pouvez utiliser SQL Server Management Studio pour afficher et gérer les partitions, amorcer l’opération d’actualisation initiale ou actualiser les partitions historiques obsolètes. Pour en savoir plus, consultez Actualisation incrémentielle avancée avec le point de terminaison XMLA.

Communauté

Power BI a une communauté dynamique où des MVP, des professionnels BI et des pairs partagent leur expertise dans des groupes de discussion, des vidéos, des blogs et bien plus encore. Lorsque vous vous familiarisez avec l’actualisation incrémentielle, veillez à consulter ces ressources supplémentaires :

Étapes suivantes

Configurer une actualisation incrémentielle pour les jeux de données
Actualisation incrémentielle avancée avec le point de terminaison XMLA
Résoudre les problèmes d’actualisation incrémentielle
Actualisation incrémentielle des flux de données