Maintenance et optimisation inter-charges de travail dans Microsoft Fabric

Les tables Delta de Microsoft Fabric servent plusieurs moteurs de consommation, chacun présentant des caractéristiques de performances et des exigences d’optimisation différentes. Ce guide fournit une infrastructure complète pour comprendre comment les tables écrites par un moteur sont consommées par d’autres et comment optimiser les stratégies de maintenance des tables en conséquence.

La compréhension de la relation entre les modèles d’écriture et les performances de lecture entre différents moteurs est essentielle pour créer des plateformes de données efficaces. L’objectif est de s’assurer que les producteurs de données créent des dispositions de table qui optimisent les performances de lecture pour les consommateurs en aval, que ces consommateurs utilisent Spark, un point de terminaison d’analytique SQL, Power BI Direct Lake ou Warehouse.

Matrice de scénario d’écriture et de lecture

Le tableau suivant récapitule les caractéristiques de performances attendues pour les combinaisons d’écriture et de lecture courantes, ainsi que les stratégies d’optimisation recommandées. Utilisez cette matrice pour identifier votre scénario et comprendre les conseils pertinents.

Write, méthode	Moteur de lecture	Écarts attendus	Stratégie recommandée
Spark batch	Spark	Aucune lacune	Les configurations d’écriture Spark par défaut sont suffisantes
Traitement par lot Spark	Point de terminaison des analyses SQL	Aucune lacune	Activer le compactage automatique et optimiser l’écriture
Diffusion en continu Spark	Spark	Petits fichiers possibles	Compactage automatique et optimisation de l’écriture avec OPTIMIZE planifié
Diffusion en continu Spark	Point de terminaison des analyses SQL	Petits fichiers et points de contrôle	Compactage automatique, optimisation-écriture, couches de médaillon fractionnés
Entrepôt	Spark	Aucune lacune	La gestion de l'optimisation par le système est responsable de la disposition.
Entrepôt	Point de terminaison des analyses SQL	Aucune lacune	La mise en page est gérée par l'optimisation dirigée par le système.

Dispositions de fichiers optimales par moteur

Différents moteurs de consommation ont des dispositions de fichiers optimales variées. La compréhension de ces cibles vous aide à configurer les opérations d’écriture et les travaux de maintenance de manière appropriée.

Conseils pour le point de terminaison d’analytique SQL et Fabric Data Warehouse

Pour des performances optimales avec le point de terminaison d’analytique SQL et Warehouse, utilisez les paramètres suivants :

Taille du fichier cible : Environ 400 Mo par fichier
Taille du groupe de lignes : environ 2 millions de lignes par groupe de lignes
V-Order : améliore les performances de lecture de 10%

Un entrepôt utilise ces critères pour découvrir les candidats au compactage :

La surcharge des fichiers de table est supérieure à 10%
Les lignes de table supprimées logiquement sont supérieures à 10%
La taille de la table est supérieure à 1 024 lignes

Pendant l’exécution du compactage, le processus sélectionne les candidats en fonction de ces critères :

Tout fichier est inférieur à 25% de la taille idéale (en fonction du nombre de lignes)
N'importe quel fichier a plus de 20 % de lignes supprimées

Spark

Spark est robuste lors de la lecture de différentes tailles de fichier. Pour des performances optimales :

Taille de fichier cible : 128 Mo à 1 Go en fonction de la taille de la table
Taille du groupe de lignes : 1 million à 2 millions de lignes par groupe de lignes
V-Order : Non requis pour les performances de lecture Spark (peut ajouter 15-33 % de surcoût d’écriture)

Les lectures Spark bénéficient de la taille de fichier cible adaptative, qui s’ajuste automatiquement en fonction de la taille de la table :

Tables inférieures à 10 Go : cible de 128 Mo
Tables de plus de 10 To : jusqu’à 1 Go objectif

Power BI Direct Lake

Pour optimiser les performances de Direct Lake :

Taille du groupe de lignes cible : 8 millions de lignes ou plus par groupe de lignes pour des performances optimales
V-Order : essentiel pour une amélioration de 40 à 60 % des requêtes sur cache froid
Nombre de fichiers : réduire le nombre de fichiers pour réduire la surcharge de transcodage
Tailles de fichier cohérentes : important pour les performances des requêtes prévisibles

Les modèles sémantiques Direct Lake fonctionnent le mieux quand :

Les données de colonne sont triées en V pour la compression compatible vertiPaq
Les groupes de lignes sont suffisamment volumineux pour une fusion efficace des dictionnaires
Les vecteurs de suppression sont réduits par compactage normal

Pour plus d’informations, consultez Comprendre les performances des requêtes Direct Lake.

Mirroring

La mise en miroir dimensionne automatiquement les fichiers en fonction du volume de table :

Taille de la table	Lignes par groupe de lignes	Lignes par fichier
Petite (jusqu’à 10 Go)	2 millions	10 millions
Moyen (de 10 Go à 2,56 To)	4 millions	60 millions
Grande (plus de 2,56 To)	8 millions	80 millions

Écrire des modèles et des configurations

Modèles d’écriture Spark

Les écritures Spark utilisent les configurations par défaut suivantes :

Paramétrage	Valeur par défaut	Descriptif
`spark.microsoft.delta.optimizeWrite.fileSize`	128 Mo	Taille de fichier cible pour les écritures optimisées
`spark.databricks.delta.optimizeWrite.enabled`	Varie selon le profil	Active la fusion automatique des fichiers
`spark.databricks.delta.autoCompact.enabled`	Disabled	Active le compactage post-écriture
`spark.sql.files.maxRecordsPerFile`	Illimité	Nombre maximal d’enregistrements par fichier

Pour configurer les écritures Spark pour la consommation SQL en aval :

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Pour plus d’informations sur les profils de ressources et leurs valeurs par défaut, consultez Configurer les configurations de profil de ressource.

Modèles de rédaction en entrepôt

L’entrepôt optimise automatiquement la disposition des données pendant les écritures :

V-Order est activé par défaut pour l’optimisation de la lecture.
Le compactage automatique s’exécute en tant que processus en arrière-plan.
La gestion des points de contrôle est gérée automatiquement.

L’entrepôt produit des fichiers optimisés pour la consommation SQL sans intervention manuelle. Les tables créées par l'entrepôt sont intrinsèquement optimisées pour le point d'accès d'analytique SQL ainsi que pour les lectures de l'entrepôt.

Opérations de maintenance de table

Commande OPTIMIZE

La OPTIMIZE commande consolide les petits fichiers en fichiers plus volumineux :

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Important

La OPTIMIZE commande est une commande Spark SQL. Vous devez l’exécuter dans des environnements Spark tels que des notebooks, des définitions de travaux Spark ou l’interface de maintenance Lakehouse. Le point de terminaison d’analytique SQL et l’éditeur de requête SQL Warehouse ne prennent pas en charge cette commande.

Pour plus d’informations, consultez Compactage de table.

Compactage automatique

Le compactage automatique évalue automatiquement l’intégrité de la partition après chaque opération d’écriture et déclenche l’optimisation synchrone lorsque la fragmentation des fichiers est détectée :

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Utilisez le compactage automatique pour les pipelines d’ingestion avec de fréquentes petites écritures (streaming ou microbatch) pour éviter la planification manuelle et conserver automatiquement les fichiers compactés.

Le compactage automatique et l’optimisation de l’écriture produisent généralement les meilleurs résultats lorsqu’ils sont utilisés ensemble. Optimiser l’écriture réduit le nombre de petits fichiers écrits et le compactage automatique gère la fragmentation restante.

Pour plus d’informations, consultez Compactage automatique.

Optimiser l’écriture

Optimiser l’écriture réduit la surcharge des petits fichiers en effectuant un compactage en pré-écriture, ce qui génère moins de fichiers plus volumineux :

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

L’optimisation de l’écriture est bénéfique pour :

tables partitionnées
Tables avec de fréquentes petites insertions
Opérations qui touchent de nombreux fichiers (MERGE, UPDATE, DELETE)

Le compactage en pré-écriture (optimiser l’écriture) est généralement moins coûteux que le compactage post-écriture (optimise). Pour plus d’informations, consultez Optimiser l’écriture.

Commande VACUUM

La VACUUM commande supprime les anciens fichiers auxquels un journal de table Delta ne fait plus référence :

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

La période de conservation par défaut est de sept jours. La définition de périodes de rétention plus courtes affecte les fonctionnalités de voyage temporel de Delta et peut entraîner des problèmes avec des lecteurs ou des enregistreurs simultanés.

Pour plus d'informations, consultez la maintenance des tables Lakehouse.

Optimisation V-Order

V-Order est une optimisation du temps d’écriture qui applique le tri, l’encodage et la compression compatibles vertiPaq aux fichiers Parquet :

Power BI Direct Lake : amélioration de 40 à 60% dans les requêtes de cache à froid
Point de terminaison d’analytique SQL et Entrepôt : environ une amélioration de 10% des performances de lecture
Spark : Aucun avantage inhérent en lecture ; écriture 15 à 33 % plus lente.

Quand activer V-Order

V-Order offre le plus d’avantages pour :

Tables de couche d'or pour Power BI Direct Lake
Tables fréquemment interrogées via le point de terminaison d’analyse SQL
Charges de travail lourdes en lecture où les performances d’écriture sont moins critiques

Quand éviter l'ordre V

Envisagez de désactiver l'ordre V pour :

Tables de couche bronze orientées sur la vitesse d'ingestion
Pipelines Spark à Spark où SQL et Power BI n’utilisent pas les données
Charges de travail lourdes en écriture où la latence des données est critique

Configurer V-Order

V-Order est désactivé par défaut dans les nouveaux espaces de travail Fabric. Pour l’activer, procédez comme suit :

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Pour appliquer de manière sélective V-Order en fonction de la consommation Direct Lake, envisagez d’automatiser l’activation de V-Order pour les tables utilisées dans les modèles sémantiques Direct Lake. Les tables non consommées par Direct Lake peuvent rester sans V-Order pour améliorer les performances d’écriture.

Pour plus d'informations, consultez Optimisation de la table Delta Lake et V-Order.

Clustering liquide et ordre Z

Clustering liquide

Le clustering liquide est l’approche recommandée pour l’organisation des données. Contrairement au partitionnement traditionnel, le clustering liquide.

S’adapte à la modification des modèles de requête
Nécessite OPTIMIZE pour appliquer le clustering
Fournit un meilleur saut de fichier pour les requêtes filtrées

Activez le clustering liquide lors de la création d’une table :

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Ordre Z

Z-Order colocalise les données associées dans les mêmes fichiers, de sorte que vous obtenez de meilleures performances de requête sur les prédicats de filtre.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Utilisez l'Ordre Z quand :

Votre table est partitionnée, car Liquid Clustering ne fonctionne pas avec les tables partitionnée.
Vos requêtes filtrent souvent sur deux colonnes ou plus ensemble.
Vos prédicats sont suffisamment sélectifs pour bénéficier d’un saut de fichier.

Recommandations en matière d’architecture Medallion

L’architecture de médaillon (couches Bronze, Argent, Or) fournit un framework permettant d’optimiser les stratégies de maintenance de table en fonction de l’objectif de chaque couche.

Couche bronze (zone d’atterrissage)

Les tables bronze se concentrent sur les performances d’écriture et l’ingestion à faible latence :

Priorité d’optimisation : vitesse d’ingestion par rapport aux performances de lecture
Partitionnement : acceptable mais déconseillé pour les nouvelles implémentations
Petits fichiers : acceptable, car le focus est sur la vitesse d’ingestion
V-Order : non recommandé (ajoute une surcharge d’écriture)
Compactage automatique : Activer pour réduire la taille des petits fichiers, mais cela peut être sacrifié au profit de la vitesse d’ingestion.
Vecteurs de suppression : Activer pour les tables avec des modèles de fusion

Les tables Bronze ne doivent pas être fournies directement au point de terminaison de l’analytique SQL ou aux utilisateurs de Power BI Direct Lake.

Couche argent (zone sélectionnée)

Les tables Silver équilibrent les performances d’écriture et de lecture :

Priorité d’optimisation : équilibre entre l’ingestion et les performances des requêtes
Tailles de fichier : Modéré (128-256 Mo) pour prendre en charge les opérations d’écriture et de lecture
V-Order : Facultatif ; activer si le point de terminaison d’analytique SQL et la consommation de Power BI sont significatifs.
Clustering liquide ou Z-Order : recommandé pour améliorer les performances des requêtes
Compactage automatique et optimisation de l’écriture : activer en fonction des exigences en aval
Vecteurs de suppression : Activer pour les tables avec des mises à jour fréquentes
OPTIMIZE planifié : Exécuter de manière agressive pour maintenir la disposition des fichiers

Couche or (zone de service)

Les tables Gold hiérarchisent les performances de lecture pour la consommation des utilisateurs finaux :

Priorité d’optimisation : Performances de lecture pour l’analyse
Tailles de fichier : grande (400 Mo à 1 Go) pour des performances SQL et Power BI optimales
V-Order : Obligatoire pour Power BI Direct Lake ; avantageux pour le point de terminaison d'analyse SQL
Liquid Clustering : requis pour un saut de fichier optimal
Optimiser l’écriture : requis pour les tailles de fichier cohérentes
OPTIMIZE planifié : Exécuter intensément pour maintenir une mise en page optimale

Optimisez différemment les tables d'or en fonction du moteur de consommation principal :

Moteur de consommation	V-Order	Taille du fichier cible	Taille du groupe de lignes
Point de terminaison des analyses SQL	Oui	400 Mo	2 million de lignes
Power BI Direct Lake	Oui	400 Mo à 1 Go	plus de 8 millions de lignes
Spark	Optional	128 Mo à 1 Go	1 à 2 millions de lignes

Plusieurs copies de tables

Il est acceptable de conserver plusieurs copies de tables optimisées pour différents modèles de consommation :

Table Silver optimisée pour le traitement Spark
Une table Gold optimisée pour l'endpoint d'analytique SQL et pour Power BI Direct Lake.
Pipelines de données qui transforment et placent la structure appropriée à chaque couche

Le stockage est peu coûteux par rapport au calcul. L’optimisation des tables pour leurs modèles de consommation offre une meilleure expérience utilisateur que d’essayer de servir tous les consommateurs à partir d’une seule disposition de table.

Identifier l’état de santé des tables

Avant d’optimiser les tables, évaluez l’état actuel des tables pour comprendre les besoins d’optimisation.

Inspecter directement les fichiers Parquet

Vous pouvez parcourir le dossier de tables dans OneLake pour inspecter les tailles des fichiers Parquet individuels. Les tables saines ont des tailles de fichier distribuées uniformément. Recherchez :

Tailles de fichier cohérentes : les fichiers doivent avoir une taille approximativement identique (dans un intervalle de 2x entre eux).
Aucun fichier extrêmement petit : les fichiers de moins de 25 Mo indiquent la fragmentation.
Aucun fichier extrêmement volumineux : les fichiers de plus de 2 Go peuvent réduire le parallélisme.

La distribution de taille de fichier inégale indique souvent des modèles d’écriture incohérents ou compactage manquants entre différents travaux.

OPTIMISER LE TEST À BLANC dans Spark SQL

Utilisez l’option DRY RUN pour afficher un aperçu des fichiers éligibles à l’optimisation sans exécuter le compactage :

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

La commande retourne une liste de fichiers qui seraient réécrits lors de l’optimisation. Utilisez cette option pour :

Évaluez l’étendue de l’optimisation avant de l’exécuter.
Comprendre la fragmentation des fichiers sans modifier la table.
Estimer le temps d’optimisation en fonction du nombre de fichiers affectés.

Distribution de taille de fichier

Utilisez l’approche suivante pour analyser les tailles et la distribution des fichiers :

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

La distribution peut être asymétrique, car les fichiers proches de la tête de la table ou d’une partition spécifique peuvent ne pas être optimisés.

Vous pouvez évaluer la distribution en exécutant une requête qui regroupe par les clés de partitionnement ou de clustering de la table.

Déterminer les besoins d’optimisation

En fonction du moteur de consommation, comparez les tailles de fichier réelles aux tailles cibles :

Engine	Taille du fichier cible	Si les fichiers sont plus petits	Si les fichiers sont plus volumineux
Point de terminaison des analyses SQL	400 Mo	Exécutez `OPTIMIZE`	Les fichiers sont acceptables
Power BI Direct Lake	400 Mo à 1 Go	Exécutez `OPTIMIZE VORDER`	Les fichiers sont acceptables
Spark	128 Mo à 1 Go	Activer le compactage automatique	Les fichiers sont acceptables

Historique des tables et journal des transactions

Passez en revue l’historique des tables pour comprendre les modèles d’écriture et la fréquence de maintenance :

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Bonnes pratiques de configuration

Utiliser les propriétés de table sur les configurations de session

Les propriétés de table persistent entre les sessions et garantissent un comportement cohérent pour tous les travaux et les auteurs :

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Les configurations au niveau de la session s’appliquent uniquement à la session Spark actuelle et peuvent entraîner des écritures incohérentes si différentes sessions utilisent des configurations différentes.

Activer la taille de fichier cible adaptative

La taille de fichier cible adaptative ajuste automatiquement les cibles de taille de fichier en fonction de la taille de la table :

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Cette fonctionnalité :

Commence par des fichiers plus petits (128 Mo) pour les petites tables
Augmente la capacité à 1 Go pour des tables de plus de 10 To
Réévalue automatiquement pendant OPTIMIZE les opérations

Activer les cibles de compactage au niveau du fichier

Empêchez la réécriture des fichiers précédemment compactés lorsque les tailles cibles changent :

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Résumé des recommandations

Couche	Compactage automatique	Optimiser l’écriture	V-Order	Clustering liquide	Optimisation planifiée
Bronze	Activer (facultatif)	Enable	Non	Non	Optional
Argent	Enable	Enable	Optional	Oui	Agressif
Or	Enable	Enable	Oui	Oui	Agressif

Pour des scénarios spécifiques, utilisez les recommandations suivantes :

Spark-to-Spark : Concentrez-vous sur l’optimisation de la taille des fichiers ; V-Order facultatif.
Spark-to-SQL : Activer l’optimisation de l’écriture et le compactage automatique ; ciblez des fichiers de 400 Mo avec 2 millions de groupes de lignes.
Ingestion de streaming : Activer le compactage automatique ; programmer des tâches supplémentaires OPTIMIZE pour les consommateurs SQL.
Power BI Direct Lake : Activer V-Order ; viser à plus de 8 millions de groupes de lignes ; exécuter OPTIMIZE VORDER.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-02-13