Configurer les paramètres pour la mise à l’échelle

Effectué

Le modèle est conçu. Configurez maintenant les paramètres qui contrôlent la façon dont il gère les jeux de données volumineux, les requêtes simultanées et l’accès aux outils externes. Ces paramètres déterminent si le modèle peut continuer à augmenter à mesure que les volumes de données augmentent et que d’autres utilisateurs et outils l’utilisent.

Format de stockage de modèle sémantique volumineux

Le format de stockage de modèle sémantique volumineux change la façon dont le modèle stocke et compresse les données. Par défaut, Power BI limite les chargements de modèle à 10 Go. Avec ce paramètre activé, les modèles peuvent dépasser cette limite d’actualisation. La taille maximale est égale à la taille de capacité Fabric ou à la limite définie par l’administrateur de capacité.

Les modèles Direct Lake activent automatiquement ce paramètre. Vous n’avez donc pas besoin de le configurer manuellement pour ces modèles. Pour les modèles en mode Importation, vous devez l’activer explicitement.

Ce paramètre est également un prérequis pour l’accès en lecture/écriture du point de terminaison XMLA et le scale-out des requêtes. Vous devez d’abord l’activer lors de l’utilisation des modes de stockage Import ou DirectQuery.

Activez le format de stockage de modèle sémantique volumineux lorsque :

  • Vos volumes de données nécessitent des modèles qui dépassent la limite de chargement de 10 Go.
  • Vous avez besoin d’un accès au point de terminaison XMLA pour les outils externes.
  • Vous envisagez d’utiliser la mise à l'échelle des requêtes pour un haut degré de concurrence.
  • Vous envisagez d’utiliser l’actualisation incrémentielle avec des tables partitionnées.

Accès en lecture/écriture au point de terminaison XMLA

Le point de terminaison XMLA permet aux outils externes de se connecter à votre modèle sémantique. Les outils tels que l'éditeur tabulaire, DAX Studio et ALM Toolkit utilisent ce point de terminaison pour le développement, le débogage et les opérations de déploiement qui ne sont pas disponibles dans l'interface de service Fabric.

L’accès en lecture/écriture du point de terminaison XMLA nécessite le format de stockage de modèle sémantique volumineux comme condition préalable. Une fois les deux activés, vous pouvez :

  • Utilisez l’éditeur tabulaire pour l’intégration du développement de modèles et du contrôle de code source.
  • Utilisez DAX Studio pour l’analyse des requêtes et le réglage des performances.
  • Déployez des modèles via des pipelines CI/CD à l’aide des bibliothèques clientes Analysis Services.

À grande échelle, ces outils externes deviennent essentiels. Les modifications manuelles par le biais de l’interface de service ne prennent pas en charge le niveau de développement de modèles requis par les grands modèles gérés par l’équipe.

Conseil / Astuce

En savoir plus sur la connectivité des points de terminaison XMLA.

Scaleout des requêtes

La mise à l’échelle des requêtes distribue les requêtes de lecture sur les réplicas en lecture seule de votre modèle sémantique. Lorsque des centaines d’utilisateurs accèdent simultanément au même modèle, une seule instance peut devenir un goulot d’étranglement. Le scaleout de requête ajoute des réplicas qui partagent la charge de requête.

Lorsque vous activez le scale-out de requête, les réplicas en lecture utilisent une copie distincte du modèle. Cette copie se synchronise après chaque actualisation. Il peut y avoir un court délai entre le modèle principal terminant une actualisation et les réplicas reflétant les données mises à jour.

La mise à l’échelle des requêtes nécessite comme prérequis un format de stockage de modèle sémantique volumineux.

Activez le scale-out des requêtes quand :

  • Le modèle sert des centaines d’utilisateurs simultanés.
  • Les performances des requêtes se dégradent pendant les périodes d’utilisation maximales.
  • Le modèle est soutenu par une capacité Fabric qui prend en charge les répliques.

Conseil / Astuce

En savoir plus sur le scale-out des requêtes pour les modèles sémantiques.

Configuration de secours pour Direct Lake

Direct Lake lit les tables Delta directement de OneLake en mémoire. Certaines requêtes peuvent amener le modèle à revenir au mode DirectQuery, ce qui modifie les caractéristiques de performances. Le paramètre de secours contrôle la façon dont le modèle gère ces situations :

  • Autoriser le repli (valeur par défaut) : les requêtes qui ne peuvent pas s'exécuter en mode Direct Lake basculent automatiquement vers DirectQuery. Les utilisateurs obtiennent des résultats, mais les performances peuvent diminuer.
  • Interdire le repli : les requêtes qui ne peuvent pas s'exécuter en mode Direct Lake retournent une erreur. Cela applique des performances cohérentes, mais nécessite que toutes les requêtes restent dans les fonctionnalités de Direct Lake.

Pour les modèles à grande échelle, commencez par autoriser la solution de repli. Surveillez les requêtes qui le déclenchent, puis optimisez ces requêtes ou structures de données pour réduire la fréquence de basculement. Désactiver le repli uniquement lorsque tous les modèles de requête restent dans les limites de Direct Lake et que vous avez besoin d'une constance des performances garantie.

Intégration de OneLake

L’intégration de OneLake rend vos données de modèle sémantique accessibles en tant que tables Delta dans OneLake. Lorsque cette option est activée, les éléments Fabric en aval, tels que les carnets de notes, les pipelines et d'autres services, peuvent lire des données directement depuis le modèle sémantique sans le reconstruire depuis la source.

Cela étend la portée du modèle au-delà des rapports. Un modèle sémantique avec un schéma en étoile bien structuré et une logique de calcul devient une source de données organisée pour la plateforme d’analytique plus large.

Activez l’intégration de OneLake quand :

  • Les ingénieurs de données ou les data scientists doivent consommer des données de modèle sémantique dans des notebooks ou autres éléments de Fabric.
  • Vous souhaitez utiliser le modèle sémantique comme source de données partagée entre Fabric.
  • Les consommateurs en aval ont besoin d’accéder à des données enrichies par logique métier organisées sans les reconstruire à partir de sources brutes.

Note

L’intégration de OneLake exporte actuellement uniquement les tables en mode Importation. Les tables Direct Lake, les tables DirectQuery, les mesures et les tables de groupe de calcul ne peuvent pas être exportées. Si votre modèle utilise exclusivement Direct Lake, les tables Delta sous-jacentes dans OneLake sont déjà directement accessibles à d'autres éléments Fabric.

Cadre de décision des paramètres

Le tableau suivant récapitule les décisions de paramètres clés pour la mise à l’échelle :

Réglage Default Activer quand
Format de stockage de modèle sémantique volumineux Désactivé Les volumes de données dépassent 10 Go, ou vous avez besoin d'un accès au point de terminaison XMLA ou d'une extensibilité des requêtes.
Point de terminaison XMLA en lecture/écriture Lecture seule Les outils externes doivent modifier le modèle pour le développement ou le déploiement
Scaleout des requêtes Éteint La concurrence élevée dégrade les performances des requêtes (nécessite un format de stockage de modèle sémantique volumineux)
Secours Direct Lake Autorisé(e) Passer à désactivé seulement lorsque toutes les requêtes restent dans les limites de Direct Lake.
Intégration de OneLake Désactivé Les éléments de Fabric en aval doivent consommer des données de modèle sémantique

Conseil / Astuce

Ces paramètres traitent de la mise à l’échelle et de la consommation. D'autres paramètres tels que l'accréditation, l'approbation Copilot et la préparation des données pour la consommation d'IA sont couverts dans des modules distincts. Pour obtenir une référence complète, consultez les paramètres du modèle semantique dans le service Fabric.