Optimisation et maintenance des tables intercharge de travail dans Microsoft Fabric

Les tables Delta dans Microsoft Fabric peuvent servir Spark, SQL Analytics Endpoint, Power BI Direct Lake, Warehouse et d’autres expériences Fabric à partir de données stockées dans OneLake. La performance optimale entre charges de travail dépend de deux facteurs :

  • La charge de travail qui crée et maintient la table.
  • Les moteurs qui engloutissent la table.

Les tables Lakehouse sont couramment gérées par Spark, Fabric pipeline activité Copy, ou Dataflow Gen2. Spark est le rédacteur le plus courant et fournit les contrôles de mise en page et de maintenance les plus larges. L’entrepôt de données et la mise en miroir de base de données gèrent automatiquement leurs configurations physiques. Les catalogues miroir conservent la mise en page gérée dans le système source. Les exigences des consommateurs sont généralement compatibles, mais Power BI Direct Lake a des exigences de stockage supplémentaires pour des performances optimales.

Utilisez une seule table partagée chaque fois que ses exigences sont compatibles. Pour les exceptions qui justifient une autre table, voir Quand créer une autre table.

Comprendre la propriété de la disposition

Commencez par déterminer à quelle charge de travail appartient la structure physique de la table. Les commandes du tableau suivant sont les contrôles clés pertinents pour la disposition et la maintenance de la table de charge croisée, et non une liste exhaustive des capacités de chaque moteur.

Magasin de données Méthode d’écriture ou d’ingestion Mise en page et responsabilité de la maintenance Contrôles clés
Lakehouse Spark Géré par les utilisateurs Dimensionnement des fichiers : taille adaptative cible du fichier et cibles de compactage au niveau du fichier.
Écriture et maintenance : vecteurs de suppression, auto-compactage, optimisation de l’écriture, OPTIMIZE, et VACUUM.
Organisation des données : clustering liquide, partitionnement, ordre Z et ordre V.
Lakehouse pipeline Fabric, activité de copie ou Dataflow Gen2 Le service écrit les données ; le propriétaire du lakehouse assure la maintenance de la table Paramètres d’écriture spécifiques à la destination. Effectuez séparément la maintenance compatible en utilisant Spark, la maintenance Lakehouse ou une activité de maintenance de pipeline.
Entrepôt Fabric Data Warehouse, activité de copie du pipeline Fabric, ou Dataflow Gen2 Gestion d’entrepôt Le clustering de données et le réglage V-Order au niveau de l’entrepôt.
Élément en miroir Service de miroir Cela dépend du type de miroir La mise en miroir de bases de données utilise une structure V-Ordered Delta gérée par le système, sans possibilité de contrôler directement cette structure. Les catalogues miroir conservent la disposition du fichier source, que vous pouvez optimiser dans le système source lorsque cela est supporté.

Recommandations transversales sur les charges de travail

Le tableau suivant résume l’approche recommandée par le producteur et le consommateur.

Producer Consumer Approche recommandée
Lakehouse : module d’écriture Spark Spark Utilisez les paramètres par défaut de Fabric Spark 2.0 ou versions ultérieures et activez la compaction automatique. Considérez le regroupement liquide lorsque les prédicats mesurés bénéficient d’une amélioration du saut de fichiers.
Lakehouse : Spark Writer Point de terminaison des analyses SQL Utilisez la même disposition recommandée pour Spark. Ne définissez pas une taille de fichier cible statique, une limite de lignes arbitraire ou un ordre en V uniquement pour la performance des endpoints SQL analytics.
Lakehouse : Spark Writer Power BI Direct Lake Utilisez la même disposition recommandée pour Spark et activez en plus V-Order, ou utilisez le readHeavyForPBI profil de ressources.
Lakehouse : enregistreur de pipeline Fabric ou de Dataflow Gen2 Spark, point de terminaison d’analytique SQL, ou Power BI Direct Lake Surveillez l’organisation des fichiers obtenue et planifiez séparément les opérations de maintenance compatibles du lakehouse. Certains modes de destination, tels que le rafraîchissement incrémental de Dataflow Gen2, imposent des restrictions de maintenance.
Entrepôt Fabric Data Warehouse ou Spark Utilisez la mise en page gérée par le système. Fabric Data Warehouse gère automatiquement la compactation et les autres entretiens. Utilisez le regroupement de données pour améliorer le saut de fichiers pour les charges de travail avec prédicats sélectifs récurrents.
Entrepôt Power BI Direct Lake Conservez le paramètre V-Order par défaut de l’entrepôt. Utilisez le regroupement de données lorsque cela profite aux schémas de requête partagés.
Mirroring Spark, point de terminaison d’analytique SQL, ou Power BI Direct Lake Pour la mise en miroir de base de données, utilisez la configuration V-Ordered Delta gérée par le système. Pour les catalogues en miroir, optimisez les fichiers sous-jacents dans le système source lorsqu’ils sont pris en charge. Voir Qu’est-ce que la mise en miroir dans Fabric ?

Optimiser les tables du Lakehouse

Les tables Delta de Lakehouse nécessitent une stratégie de maintenance explicite, que Spark, Pipeline activité Copy ou Dataflow Gen2 les écrivent. Spark est l’exemple principal de cette section car il offre les contrôles de mise en page et de maintenance les plus larges dans Fabric.

Important

La maintenance des tables est essentielle pour des performances optimales d’écriture et de lecture sur tous les moteurs. Même les charges de travail uniquement annexes qui fonctionnent bien au départ sans maintenance peuvent accumuler des fichiers trop petits, ce qui affecte Spark, SQL Analytics Endpoint, Direct Lake et les lecteurs de données externes. Voir Tables Delta de compactage pour les méthodes de compactage automatiques et manuelles.

Utilisez les paramètres par défaut de l’exécution Spark

Lorsque Spark écrit la table, utilisez les paramètres par défaut de Fabric Spark runtime 2.0 ou ultérieur :

Dans l’exécution de Fabric Spark 1.3, la taille adaptative du fichier cible, les cibles de compactage au niveau du fichier et les vecteurs de suppression sont disponibles en tant que paramètres d’adhésion.

Lorsque Pipeline activité Copy ou Dataflow Gen2 écrit la table, inspectez séparément la disposition du fichier résultante et planifiez la maintenance. Ne supposez pas que ces modules d’écriture utilisent les paramètres par défaut d’exécution de Spark.

Important

Les destinations lakehouse de Dataflow Gen2 qui utilisent le rafraîchissement incrémental ne prennent en charge ni OPTIMIZE ni REORG TABLE. Respectez les limitations de rafraîchissement incrémental de Dataflow Gen2.

Évitez et compactez les fichiers de petite taille

Pour les tables écrites par Spark, il faut privilégier la compaction automatique. Cette fonctionnalité évalue la fragmentation de la table après les écritures et n’effectue une compaction que lorsque cela est nécessaire. Cela supprime la nécessité d’effectuer une vérification distincte de l’état de la table avant les opérations de maintenance.

Utilisez les directives suivantes pour les exceptions et les fonctionnalités complémentaires :

Scénario Approche recommandée
Tableau écrit par Spark Activez la compaction automatique comme stratégie de maintenance par défaut.
Écritures en streaming ou en micro-batch Activez la compaction automatique et optimisez l’écriture pour réduire l’accumulation de petits fichiers.
Charges de travail avec des exigences strictes de latence d’écriture Programmez OPTIMIZE séparément au lieu d’exécuter la compaction automatique synchrone.
Table existante contenant des petits fichiers accumulés Faites un test unique OPTIMIZE, puis activez le compacing automatique pour une maintenance continue.
Tables avec mises à jour, suppressions ou fusions fréquentes Gardez activés les vecteurs de suppression et l’auto-compactage .

OPTIMIZE compacte les fichiers et purge automatiquement les vecteurs de suppression d’un fichier lorsque plus de 5% de ses enregistrements sont référencés par des vecteurs de suppression. À utiliser REORG TABLE ... APPLY (PURGE) uniquement lorsque vous devez physiquement purger les documents en dessous de ce seuil ou que vous remplissez une exigence spécifique de conformité.

Note

La compaction automatique supprime les vecteurs de suppression uniquement lorsque la partition remplit également la condition de déclenchement liée aux petits fichiers. Si une charge de travail effectue des mises à jour ou des suppressions sans générer de petits fichiers, exécutez OPTIMIZE périodiquement pour purger les vecteurs de suppression éligibles. Utilisez REORG TABLE ... APPLY (PURGE) lorsque vous devez forcer une purge physique.

Exécutez VACUUM selon un calendrier séparé pour supprimer les fichiers non référencés après la période de rétention. VACUUM Ça récupère du stockage mais n’améliore pas la disposition active des fichiers.

Avertissement

Ne raccourcez pas la VACUUM période de rétention sans évaluer les besoins liés au voyage dans le temps et les lecteurs ou auteurs simultanés. Supprimer les fichiers trop tôt peut rendre les versions obligatoires des tables indisponibles.

Organiser les données pour le saut de fichiers

Utilisez le regroupement liquide lorsque les filtres récurrents ou les schémas de traitement bénéficient d’une amélioration du saut de fichiers. Les tables en cluster liquide nécessitent OPTIMIZEou une compaction automatique pour organiser les données nouvellement écrites.

Évitez de partitionner par défaut. Utilisez-le lorsqu’une exigence spécifique justifie les compromis opérationnels, comme isoler les auteurs concurrents qui mettent à jour, suppriment ou fusionnent des données entre partitions disjointes. Pour plus d’informations, voir Quand utiliser le partitionnement.

Pour les tables partitionnées existantes, considérons l’ordre Z lorsque des prédicats sélectifs filtrent généralement sur les mêmes colonnes au sein d’une partition.

Optimiser les tables gérées par l’entrepôt

Fabric Data Warehouse gère la disposition physique de la table Delta, quelle que soit la méthode d’ingestion.

Utilisez les contrôles stratégiques exposés par Warehouse pour ajuster la disposition des données :

  • Appliquer le regroupement de données à de grandes tables lorsque les requêtes utilisent à répétition des prédicats sélectifs sur les mêmes colonnes.
  • Gardez V-Order activé pour les charges de travail orientées lecture et mixtes. V-Order est activé par défaut.
  • Envisagez de désactiver V-Order pour les charges de travail d’entrepôt gourmands en écriture.

Avertissement

Désactiver l’Ordre V est une opération irréversible au niveau de l’entrepôt. Testez la charge complète de lecture et d’écriture avant de la désactiver.

Pour des conseils complets sur l’entrepôt, consultez les directives de performance dans Fabric Data Warehouse.

Optimiser les données en miroir

Votre capacité à améliorer la mise en page physique dépend du fait que Fabric replique les données ou consulte des fichiers sources :

  • Miroir de base de données : Fabric réplique les données sources dans des tables Delta dans OneLake et gère la mise en page et la maintenance des fichiers V-Order. Vous ne pouvez pas configurer directement la taille du fichier cible, le nettoyage par vecteur de suppression, le clustering liquide, le partitionnement ou l’ordre V sur la destination miroir.
  • Catalogues en miroir : Fabric synchronise les métadonnées et utilise des raccourcis OneLake pour référencer les données sources sur place. Fabric ne réécrit ni ne maintient ces fichiers. Améliorer la mise en page physique et le nettoyage du système source lorsque les fonctionnalités supportées le permettent. Ces changements sont visibles via les raccourcis sans créer une autre copie dans Fabric.

Pour les données en miroir de base de données :

  • Utilisez des prédicats sélectifs et évitez les colonnes inutiles dans Spark et les requêtes SQL.
  • Concevoir des modèles sémantiques Power BI et des mesures DAX pour une consommation efficace de Direct Lake.

Pour les catalogues miroir :

  • Utilisez les fonctionnalités de maintenance et de mise en page prises en charge par la plateforme source.
  • Évaluez la répartition du fichier source et des groupes de lignes pour les consommateurs de Fabric qui interrogent les raccourcis.
  • Pour Direct Lake, évaluez la création d’une couche de service supplémentaire modélisée dimensionnellement, ordonnée en V, lorsque la disposition source ne répond pas aux exigences de performance.

Pour les concepts, types et sources prises en charge par le miroir, voir Qu’est-ce que le miroir dans Fabric ? et Comment fonctionne le miroir des métadonnées.

Appliquer une optimisation spécifique au consommateur

Spark et SQL Analytics Endpoint fonctionnent bien sur la même configuration adaptative de type lakehouse. Utilisez une taille de fichier cible adaptative, évitez de trop petits fichiers, et appliquez un regroupement liquide lorsque les prédicats mesurés bénéficient d’une meilleure gestion du saut de fichiers. N’activez pas V-Order uniquement pour les performances de Spark ou SQL analytics. Pour des détails spécifiques au moteur, voir considérations sur la performance des terminaux d’analyse SQL.

Power BI Direct Lake

Direct Lake utilise les mêmes tables Delta sous-jacentes mais ajoute des recommandations liées au transcodage et au cadrage incrémental :

Note

Direct Lake se comporte généralement mieux avec des groupes de rangs compris entre 1 million et 16 millions de rangs. Évaluer la répartition des groupes de lignes et les performances de Direct Lake avant de modifier un paramètre de producteur pris en charge.

Pour les tables écrites par Spark, il spark.sql.parquet.native.writer.maxRowGroupRowCount définit le nombre maximal de lignes par groupe de lignes lorsque le moteur d’exécution natif écrit les fichiers Parquet. La valeur par défaut est 0, qui n’impose pas de maximum. Si l’analyse montre que la taille des groupes de lignes affecte la performance de Direct Lake, fixez une limite testée avant d’écrire ou de réécrire la table. Par exemple:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Ne fixez pas la limite uniquement pour atteindre un nombre de lignes précis. La largeur des lignes, la compression, la distribution des fichiers et le parallélisme de capacité affectent également les performances. Utilisez Delta Analyzer pour évaluer la disposition obtenue.

Pour des conseils détaillés sur le cadrage, le transcodage, les groupes de lignes, les patrons de mise à jour et l’analyseur Delta, voir Comprendre la performance des requêtes Direct Lake.

Appliquez ces recommandations aux couches Medallion

Le bronze, l’argent et l’or décrivent l’objectif et le raffinement des données. Ils ne déterminent pas si la mise en page est gérée par l’utilisateur ou par le système, et ils n’exigent pas de copies séparées pour chaque consommateur.

Couche Objectif principal Recommandations inter-charges de travail
Bronze (atterrissage) Préserver la fidélité du code source et le débit d’ingestion Priorisez le débit d’écriture tout en maintenant des tables écrites par Spark avec compaction automatique. Évitez les modèles sémantiques Power BI Direct Lake sur les tables Bronze brutes, sauf si le modèle et la forme des données sont intentionnellement conçus pour cet usage.
Argent (sélection) Fournir des données validées et conformes pour réutilisation Réutilisez la table auprès des consommateurs Fabric compatibles. Pour les tables lakehouse créées avec Spark, activez V-Order uniquement lorsque Direct Lake est un principal consommateur.
Or (diffusion) Fournir des dimensions, des faits, des agrégats et des modèles analytiques prêts à l’emploi Je préfère cette couche pour les modèles sémantiques de Direct Lake. Réutilisez le tableau entre les consommateurs compatibles et appliquez les contrôles spécifiques au producteur décrits dans cet article.

Résoudre les problèmes de disposition et de maintenance

Utilisez une remédiation tenant compte du producteur. Appliquer les commandes de maintenance Spark aux tables lakehouse lorsque le mode de destination prend en charge ces opérations. Considérez les signaux comme des indicateurs plutôt que comme des seuils universels, et validez-les par rapport au schéma d’écriture de la table et à la performance du consommateur.

Pathologie Signal Table Lakehouse Table d’entrepôt
Fichiers trop petits Le nombre de fichiers augmente plus rapidement que la taille de la table active, et les fichiers restent en dessous de la cible adaptative. Avec Spark, exécutez une session OPTIMIZE unique pour le retard existant, puis activez la compaction automatique. Pour l’activité de copie de pipeline ou les écritures Dataflow Gen2, planifiez séparément la maintenance des lakehouses pris en charge. Aucune action. La compactation d’entrepôt est automatique.
Fichiers hérités surdimensionnés Le nombre de fichiers reste bien supérieur à la cible adaptative actuelle, et un trop petit nombre de fichiers limite le parallélisme de l’analyse. Réécrivez la table en utilisant une réécriture ou CREATE OR REPLACE TABLE AS SELECT en activant la taille adaptative du fichier cible . Aucune action. L’entrepôt gère automatiquement la taille des fichiers.
Accumulation du vecteur de délétion DESCRIBE HISTORY Les métriques montrent que les vecteurs de suppression sont ajoutés ou mis à jour plus rapidement que la compactation ne les supprime, ce qui peut augmenter la surcharge de lecture. Gardez la compactation automatique activée. Si les vecteurs de suppression s’accumulent sans déclencher la compactation de petits fichiers, planifiez OPTIMIZE. Utilisez REORG TABLE ... APPLY (PURGE) uniquement pour des exigences explicites de purge. Aucune action. Le nettoyage est géré par le système.
Mauvais saut de fichiers Les prédicats sélectifs parcourent une grande part de la table, ou l’évaluation de la qualité du clustering indique une mauvaise organisation. Avec Spark, configurez le clustering liquide ou utilisez l’ordre Z pour une table partitionnée existante. Configurez le clustering de données de l’entrepôt.
Surcharge de transcodage Direct Lake Delta Analyzer montre un excès de fichiers, de petits groupes de lignes ou un re-décodage large après les mises à jour. Compactez de petits fichiers, examinez les groupes de lignes et appliquez l’ordre V aux tables écrites par Spark. Vous pouvez également configurer le liquid clustering pour améliorer la qualité de compression au sein des fichiers Parquet. Gardez V-Order activé et évaluez le regroupement de données.
Croissance du stockage de fichiers non référencée Le stockage OneLake croît plus rapidement que la taille de la table active après des opérations de modification de données. Exécutez VACUUM conformément aux exigences de conservation. Aucune action. Le nettoyage est géré par le système.

Pour les données miroir, suivez la correction spécifique au producteur dans Optimiser les données miroirées. La mise en miroir de la base de données est gérée par le système ; pour les catalogues mis en miroir, appliquez les opérations de maintenance prises en charge sur la plateforme source.

Pour les tables de type lakehouse, les options d’inspection supportées par Spark incluent :

  • Exécutez DESCRIBE DETAIL pour inspecter le nombre de fichiers, la taille totale et la propriété évaluée delta.targetFileSize.adaptive .
  • Exécutez DESCRIBE HISTORY pour examiner les modèles d’écriture et l’historique de maintenance.
  • Utilisez Delta Analyzer lorsque vous avez besoin d’une analyse détaillée des groupes de lignes de Direct Lake et des schémas de mise à jour.

Inspecter la taille moyenne des fichiers

Utilisez DESCRIBE DETAIL pour calculer la taille moyenne du fichier comme indicateur initial de la disposition du tableau :

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Une moyenne peut masquer l’écart entre partitions ou fichiers récents et précédemment compactés. Si la moyenne indique un problème possible de configuration, inspectez les fichiers Parquet individuels ou utilisez Delta Analyzer pour évaluer la distribution avant de modifier les paramètres de maintenance.

Quand créer une autre table

Ne créez pas une autre table physique uniquement parce que plusieurs moteurs Fabric consomment les données.

Créez une autre table lorsqu’elle a un objectif indépendant, comme :

  • Une transformation ou une agrégation qui modifie le grain des données ou la signification commerciale.
  • Exigences différentes en matière de sécurité, de rétention ou de qualité des données.
  • Une exigence de latence ou de rafraîchissement que la table partagée ne peut pas satisfaire.
  • Une disposition spécifique au consommateur dont le bénéfice mesuré dépasse les coûts de stockage, de traitement, de lignée et de gouvernance.

Contenu connexe

  • Last updated on