Partager via


Dimensionnement de la passerelle de données locale

Cet article est destiné aux administrateurs Power BI qui souhaitent installer et gérer la passerelle de données locale.

La passerelle est requise chaque fois que Power BI doit accéder à des données qui ne sont pas directement accessibles sur Internet. Elle peut être installée sur un serveur local ou sur une infrastructure IaaS (infrastructure as a service) hébergée sur une machine virtuelle.

Charges de travail de la passerelle

La passerelle de données locale prend en charge deux charges de travail. Il est important de bien les comprendre avant d’aborder le dimensionnement de la passerelle et les recommandations.

Charge de travail Données en cache

La charge de travail de données mise en cache récupère et transforme les données sources pour le chargement dans des modèles sémantiques Power BI. Ce processus comporte trois étapes :

  1. Connexion : la passerelle se connecte aux données sources.
  2. Extraction et transformation de données : les données sont récupérées et, si nécessaire, transformées. Dans la mesure du possible, le Moteur Mashup Power Query transmet les étapes de transformation à la source de données, selon un processus appelé Query Folding . Si ce n’est pas possible, les transformations doivent être effectuées par la passerelle. Dans ce cas, elle consomme plus de ressources de processeur et de mémoire.
  3. Transfert : les données sont transférées vers le service Power BI. Une connexion Internet fiable et rapide est importante, en particulier pour les gros volumes de données.

Diagramme des données du cache montrant la passerelle de données locale se connectant aux sources locales.

Charges de travail Connexion active et DirectQuery

La charge de travail Connexion active et DirectQuery fonctionne principalement en mode Intermédiaire (pass-through). Le service Power BI envoie des requêtes, ce à quoi la passerelle répond en donnant les résultats des requêtes. En règle générale, ces derniers sont peu volumineux.

Cette charge de travail demande des ressources processeur pour le routage des requêtes et des résultats des requêtes. En général, la demande en processeur est bien moins importante que celle de la charge de travail Données du cache, en particulier s’il est nécessaire de transformer les données pour la mise en cache.

Une connectivité fiable, rapide et cohérente est importante pour que les utilisateurs des rapports bénéficient d’une expérience réactive.

Diagramme de Connexion active et DirectQuery montrant la passerelle de données locale se connectant aux sources locales.

Considération sur le dimensionnement

Le bon dimensionnement d’un ordinateur de passerelle peut dépendre des variables suivantes :

  • Pour des charges de travail de données du cache :
    • Nombre d’actualisations simultanées du modèle sémantique
    • type des sources de données (base de données relationnelle, base de données analytique, flux de données ou fichiers) ;
    • volume de données à récupérer à partir de sources de données ;
    • éventuelles transformations que doit effectuer le Moteur Mashup Power Query ;
    • volume de données à transférer au service Power BI.
  • Pour les charges de travail Connexion active et DirectQuery :
    • nombre d’utilisateurs de rapports simultanés ;
    • nombre de visuels sur les pages de rapport (chaque visuel envoie au moins une requête) ;
    • fréquence des mises à jour du cache des requêtes du tableau de bord Power BI ;
    • nombre de rapports en temps réel avec la fonctionnalité Actualisation automatique de la page ;
    • Indiquer si les modèles sémantiques appliquent la Sécurité au niveau des lignes (RLS)

En règle générale, les charges de travail Connexion active et DirectQuery demandent suffisamment de processeur, tandis que les charges de travail Données en cache nécessitent davantage de processeur et de mémoire. Les deux charges de travail dépendent d’une bonne connectivité avec le service Power BI et les sources de données.

Notes

Les capacités de Power BI imposent des limites sur le parallélisme de l’actualisation du modèle, ainsi que sur le débit Connexion active et DirectQuery. Il n’y a pas d’intérêt à dimensionner les passerelles au-delà de ce que prend en charge le service Power BI. Les limites varient selon la référence SKU Premium (et la référence SKU A de taille équivalente). Pour plus d’informations, consultez licences de capacité Microsoft Fabric et Qu’est-ce que Power BI Premium ? (nœuds de capacité).

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Recommandations

Les recommandations de dimensionnement de la passerelle dépendent de nombreuses variables. Dans cette section, nous vous donnons des recommandations générales que vous pouvez prendre en compte.

Dimensionnement initial

Il peut être difficile d’estimer avec précision la taille appropriée. Nous vous recommandons de commencer avec un ordinateur disposant d’au moins 8 cœurs de processeur, 8 Go de RAM et plusieurs cartes réseau Gigabit. Vous pouvez ensuite mesurer une charge de travail de passerelle type en enregistrant les compteurs système de processeur et de mémoire. Pour plus d’informations, consultez Surveiller et optimiser les performances de la passerelle de données locale.

Connectivité

Prévoyez la meilleure connectivité possible entre le service Power BI et votre passerelle, ainsi qu’entre votre passerelle et les sources de données.

  • Visez la fiabilité, la rapidité et des latences faibles et cohérentes.
  • Éliminez (ou réduisez) les sauts d’ordinateur entre la passerelle et vos sources de données.
  • Supprimez toute limitation de bande passante imposée par la couche de proxy de votre pare-feu. Pour plus d’informations sur les points de terminaison Power BI, consultez Ajout d’URL Power BI à la liste verte.
  • Configurez Azure ExpressRoute pour établir des connexions gérées privées avec Power BI.
  • En ce qui concerne les sources de données dans des machines virtuelles Azure, vérifiez que ces machines virtuelles sont colocalisées avec le service Power BI.
  • Pour les charges de travail Connexion active à SQL Server Analysis Services (SSAS) impliquant une sécurité RLS dynamique, veillez à une bonne connectivité entre l’ordinateur de passerelle et Active Directory local.

Clustering

Pour les déploiements à grande échelle, vous pouvez créer une passerelle avec plusieurs membres du cluster. Les clusters évitent les points de défaillance uniques et peuvent équilibrer la charge du trafic entre les passerelles. Vous pouvez :

  • Installez une ou plusieurs passerelles dans un cluster.
  • Isolez les charges de travail dans des passerelles autonomes ou des clusters de serveurs de passerelle.

Pour plus d’informations, consultez Gérer l’équilibrage de charge et les clusters à haute disponibilité de la passerelle de données locale.

Conception et paramètres du modèle sémantique

La conception du modèle sémantique et ses paramètres peuvent avoir un impact sur les charges de travail de la passerelle. Pour réduire cette charge de travail, vous pouvez effectuer les actions suivantes.

Pour les modèles sémantiques d’importation :

  • Configurez une actualisation des données moins fréquente.
  • Configurez une actualisation incrémentielle pour réduire la quantité de données à transférer.
  • Dans la mesure du possible, veillez à ce qu’un Pliage de requêtes s’applique.
  • En particulier pour de gros volumes de données ou des exigences de résultats à faible latence, convertissez la conception en modèle DirectQuery ou Composite.

Pour les modèles sémantiques DirectQuery :

  • Optimisez la conception des sources de données, des modèles et des rapports. Pour obtenir plus d’informations, consultez Guide du modèle DirectQuery dans Power BI Desktop.
  • Créez des agrégations pour mettre en cache des résultats de niveau supérieur afin de réduire le nombre de requêtes DirectQuery.
  • Limitez les intervalles d’Actualisation automatique de la page dans les conceptions de rapports et les paramètres de capacité.
  • En particulier lorsque la RLS est appliquée, restreignez la fréquence de mise à jour du cache du tableau de bord.
  • En particulier pour les volumes plus petits de données ou pour les données non volatiles, convertissez la conception en modèle Importation ou Composite.

Pour les modèles sémantiques Connexion active :

  • En particulier lorsque la RLS est appliquée, restreignez la fréquence de mise à jour du cache du tableau de bord.

Pour plus d’informations en rapport avec cet article, consultez les ressources suivantes :