Considérations et limites relatives aux flux de données

Il existe quelques limitations de flux de données pour la création, les actualisations et la gestion de la capacité que les utilisateurs doivent garder à l’esprit, comme décrit dans les sections suivantes.

Limitations générales

• Les flux de données peuvent ne pas être disponibles pour tous les clients doD du gouvernement américain. La parité des fonctionnalités entre les environnements gouvernementaux se trouve dans la disponibilité des fonctionnalités Power BI pour l’article sur le secteur public .
• Les sources de données supprimées ne sont pas supprimées de la page de source de données de dataflow, qui est un comportement bénin et n’affecte pas l’actualisation ou la modification des flux de données. Dans Vue de Traçabilité, les sources de données supprimées apparaissent comme traçabilité pour un flux de données.
• Les sources de données supprimées apparaissent toujours dans la page des paramètres dans le menu déroulant de la passerelle.
• La profondeur correspond aux flux de données reliés à d'autres flux de données. La profondeur maximale actuelle est de 32.
• L’étendue équivaut aux entités au sein d’un dataflow.
  • Il n’existe aucune aide ou limite pour le nombre optimal d’entités dans un flux de données. Toutefois, les flux de données partagés ont une limite d’actualisation de deux heures par entité et trois par flux de données. Par conséquent, si vous avez deux entités et que chacune prend deux heures, vous ne devez pas les placer dans le même dataflow.
  • Pour Power BI Premium, les conseils et les limites sont basés sur des cas d’usage individuels plutôt que sur des exigences spécifiques. La seule limite pour Power BI Premium est une actualisation de 24 heures par dataflow.
• Un abonnement Power BI Premium est nécessaire pour actualiser plus de 10 dataflows entre espaces de travail.
• Les limitations de PowerQuery se trouvent dans l’article Limites de Power Query Online .
• Les dataflows Power BI ne prennent pas en charge l’utilisation de variables globales dans un argument d’URL.
• Multi-Geo n’est actuellement pas pris en charge, sauf si vous configurez le stockage pour utiliser votre propre compte de stockage Azure Data Lake Gen2.
• La prise en charge de Vnet est réalisée via une passerelle.
• Lorsque vous utilisez des entités calculées avec des sources de données de passerelle, l’ingestion des données doit être effectuée dans différentes sources de données que les calculs. Les entités calculées doivent s’appuyer sur des entités qui sont utilisées uniquement pour l’ingestion, et ne doivent pas ingérer des données au sein de leurs propres étapes de mélange.
• Dans les dataflows Power BI, vous pouvez utiliser des paramètres, mais vous ne pouvez pas les modifier, sauf si vous modifiez l’intégralité du dataflow. À cet égard, les paramètres des flux de données se comportent comme des constantes déclarées.
• Certains connecteurs trouvés dans les scénarios d'actualisation pour la résolution des problèmes ne sont pas pris en charge pour les flux de données et les datamarts dans les espaces de travail Premium.
• Lorsque vous utilisez DirectQuery avec un dataflow, les recherches à l’aide du segment de découpage visuel respectent la casse.
• Les caractères suivants ne sont pas autorisés dans les entités dataflow : \/

Création de dataflows

Lorsque vous créez des dataflows, tenez compte des considérations suivantes :

• La création dans les flux de données est effectuée dans l’environnement Power Query Online (PQO) ; consultez les limitations décrites dans les limites de Power Query. Étant donné que la création de dataflows est effectuée dans l’environnement Power Query Online (PQO), les mises à jour effectuées sur les configurations de charge de travail des flux de données affectent uniquement les actualisations et n’ont aucun effet sur l’expérience de création.

• Les flux de données ne peuvent être modifiés que par leurs propriétaires.

• Les flux de données ne sont pas disponibles dans Mon espace de travail.

• Les flux de données utilisant des sources de données de passerelle ne prennent pas en charge plusieurs informations d’identification pour la même source de données.

• L’utilisation du connecteur Web.Page nécessite une passerelle.

• Dans l’expérience d’édition de dataflows Gen1, les utilisateurs peuvent ne pas pouvoir supprimer une connexion de passerelle de données locale du flux de données à l’aide d’Options>Project>Data Load>select (none) dans la liste déroulante Data Gateway. Les étapes suivantes peuvent résoudre le problème :

  1. Commencez à modifier le flux de données dans lequel vous souhaitez supprimer la connexion de passerelle de données locale.
  2. Sélectionnez Options>Project Data Load>Data Gateway, sélectionnez None , puis OK.
  3. Si un avertissement jaune avec un bouton « Configurer la connexion » s’affiche, sélectionnez Configurer la connexion, sélectionnez la connexion cloud dans la zone de liste déroulante et insérez les informations d’identification si nécessaire pour la connexion cloud.
  4. Sélectionnez Gérer les connexions> , puis sélectionnez le bouton dissocier la connexion de passerelle.
  5. Fermez la boîte de dialogue Gérer les connexions , si vous devez à nouveau « Configurer la connexion », procédez ainsi. Sélectionnez Enregistrer et fermer, puis attendez que l’opération d’enregistrement se termine.
  6. Si l’avertissement « Configurer la connexion » n’apparaît pas après l’application des étapes précédentes, appliquez les étapes précédentes, enregistrez et fermez le flux de données, puis modifiez-le à nouveau et recherchez l’avertissement « Configurer la connexion » pour qu’il apparaisse pour que vous y preniez des mesures.

  Si la connexion à la passerelle n’est toujours pas supprimée du flux de données, vous devrez peut-être recréer un nouveau dataflow avec les mêmes requêtes, et non liés à la passerelle.

Considérations relatives aux API

Vous trouverez plus d’informations sur les API REST de flux de données prises en charge dans la référence de l’API REST. Voici quelques considérations à prendre en compte :

• L’exportation et l’importation d’un dataflow donnent à ce flux de données un nouvel ID.
• L’importation de dataflows qui contiennent des tables liées ne met pas à jour les références existantes dans le flux de données (ces requêtes doivent être mises à jour manuellement avant d’importer le dataflow).
• Lorsque vous déployez un flux de données, vous pouvez utiliser les gestionnaires de conflit GenerateUniqueName et les paramètres Abort pour abandonner l’opération lorsqu’elle existe déjà ou indiquer à l’API de créer automatiquement un nom unique. Les flux de données peuvent être remplacés par le paramètre CreateOrOverwrite , s’ils ont été créés initialement à l’aide de l’API d’importation.

Flux de données dans les capacités partagées

Il existe des limitations pour les flux de données dans les capacités partagées (capacités non Premium) :

• Lorsqu'un flux de données est actualisé, les délais d’expiration dans une capacité partagée sont de 2 heures par table et de 3 heures par flux de données.
• Les tables liées ne peuvent pas être créées dans des dataflows partagés, bien qu’elles puissent exister dans le flux de données tant que la propriété Load Enabled sur la requête est désactivée.
• Les tables calculées ne peuvent pas être créées dans des dataflows partagés.
• AutoML et Cognitive Services ne sont pas disponibles dans les dataflows partagés.
• L’actualisation incrémentielle ne fonctionne pas dans les dataflows partagés.

Flux de données dans la version Premium

Les dataflows qui existent dans Premium ont les considérations et limitations suivantes.

Actualisations et considérations relatives aux données :

• Lors de l’actualisation des dataflows, les délais d’expiration sont de 24 heures (aucune distinction pour les tables et/ou les dataflows).
• La modification d’un flux de données d’une stratégie d’actualisation incrémentielle en une actualisation normale, ou inversement, supprime toutes les données.
• La modification du schéma d’un dataflow supprime toutes les données.
• Lorsque vous utilisez une licence Premium par utilisateur (PPU) avec des dataflows, les données sont effacées lors du déplacement de données hors d’un environnement PPU.
• Lorsqu’un flux de données est actualisé dans un contexte Premium par utilisateur (PPU), les données ne sont pas visibles pour les utilisateurs non-PPU.
• L’actualisation incrémentielle fonctionne avec des dataflows uniquement lorsque le moteur de calcul amélioré est activé.

Tables liées et calculées :

• Les tables reliées peuvent aller jusqu'à une profondeur de 32 références.
• Les dépendances cycliques des tables liées ne sont pas autorisées.
• Une table liée ne peut pas être jointe à une table régulière qui obtient ses données à partir d’une source de données locale.
• Lorsqu’une requête (requête A, par exemple) est utilisée dans le calcul d’une autre requête (requête B) dans les flux de données, la requête B devient une table calculée. Les tables calculées ne peuvent pas faire référence à des sources locales.
• Les tables liées qui référencent des entités dans différents locataires ne sont pas prises en charge.

Moteur de calcul :

• Lors de l’utilisation du moteur de calcul, il y a une augmentation initiale approximative de 10% à 20% du temps d’ingestion des données.
  • Cela s’applique uniquement au premier flux de données qui se trouve sur le moteur de calcul et lit les données de la source des données.
  • Les dataflows suivants qui utilisent le dataflow source n’entraînent pas la même pénalité.
• Seules certaines opérations utilisent le moteur de calcul, et uniquement lorsqu’elles sont utilisées par le biais d’une table liée ou comme table calculée. Une liste complète des opérations est disponible dans ce billet de blog.

Gestion de la capacité :

• Par conception, les capacités Power BI Premium ont un Resource Manager interne qui limite les charges de travail de différentes manières lorsque la capacité s’exécute sur une mémoire faible.
  • Pour les flux de données, cette pression de limitation réduit le nombre de conteneurs M disponibles.
  • La mémoire des flux de données peut être définie sur 100%, avec un conteneur de taille appropriée pour vos tailles de données, et la charge de travail gère le nombre de conteneurs de manière appropriée.
• Le nombre approximatif de conteneurs est disponible en divisant la mémoire totale allouée à la charge de travail par la quantité de mémoire allouée à un conteneur.

Utilisation du flux de données dans les modèles sémantiques

• Lorsque vous créez un modèle sémantique dans Power BI Desktop, puis publiez-le sur le service Power BI, vérifiez que les informations d’identification utilisées dans Power BI Desktop pour la source de données des flux de données sont les mêmes informations d’identification que celles utilisées lorsque le modèle sémantique est publié sur le service.
  • Le défaut de s'assurer que ces identifiants sont les mêmes entraîne une erreur de clé introuvable lors de l'actualisation du modèle sémantique.

Flux de données et connexions nommées

Lorsque vous utilisez des dataflows avec des connexions nommées, les limitations suivantes s’appliquent :

• Vous ne pouvez créer qu’une seule connexion cloud d’un chemin et d’un type particulier, par exemple, vous ne pouvez créer qu’une seule connexion SQL plus serveur/base de données cloud. Vous pouvez créer plusieurs connexions de passerelle.
• Vous ne pouvez pas nommer ou renommer des sources de données cloud ; vous pouvez nommer ou renommer des connexions de passerelle.

Limitations d’ADLS

• ADLS n’est pas disponible dans les environnements GCC, GCC High ou DOD. Pour plus d’informations, consultez Power BI pour les clients du gouvernement américain.
• Vous devez être affecté en tant que propriétaire de la ressource, en raison des modifications apportées aux API ADLS Gen 2.
• La migration d’abonnement Azure n’est pas prise en charge, mais il existe deux alternatives à effectuer :
  • Première approche : après la migration, l’utilisateur peut détacher des espaces de travail et les détacher à nouveau. Si vous utilisez le compte au niveau du locataire, vous devez d'abord détacher tous les espaces de travail, puis au niveau du locataire, et enfin rattacher. Cela peut être indésirable pour les clients qui ne souhaitent pas supprimer tous leurs flux de données ou qui ont de nombreux espaces de travail.
  • Deuxième approche : si l’approche précédente n’est pas réalisable, envoyez une demande de support pour modifier l’ID d’abonnement dans la base de données.
• ADLS ne prend pas en charge la plupart des éléments de la liste dans la section Répertoires et noms de fichiers de l’article pour le nommage et le flux de données de l’espace de travail, en raison des limitations suivantes :
  • Power BI retourne une erreur non utile ou autorise le processus à se produire, mais l’actualisation échoue.
• Les abonnements ADLS inter-locataires ne sont pas pris en charge. AdLS attaché à Power BI doit faire partie du même locataire Azure que Power BI utilise pour l’ID Microsoft Entra.

Types de données de flux

Les types de données pris en charge dans les flux de données sont les suivants :

Contenu connexe

Les articles suivants vous permettront de découvrir plus d’informations sur les flux de données et Power BI :

• Introduction aux flux de données et à la préparation des données en libre-service
• Création d’un flux de données
• Configurer et consommer un flux de données
• Configuration du stockage dataflow pour utiliser Azure Data Lake Gen 2
• Fonctionnalités Premium des flux de données
• Planification de l’implémentation de Power BI - Intégration à d’autres services
• Meilleures pratiques relatives aux flux de données