Comprendre V-Order pour les entrepôts Microsoft Fabric
S’applique à : 
Warehouse dans Microsoft Fabric
L’entrepôt dans le stockage Microsoft Fabric utilise le format de table Delta Lake pour toutes les données utilisateur. En plus des optimisations fournies par le format Delta, un entrepôt applique des optimisations au stockage pour fournir des performances de requête plus rapides dans les scénarios analytiques, tout en conservant l’adhésion au format Parquet. Cet article traite de l’optimisation des écritures de V-Order, ses avantages et la façon de la contrôler.
Qu’est-ce que V-Order ?
V-Order est une optimisation du temps d’écriture au format de fichier Parquet qui permet des lectures rapides sous les moteurs de calcul Microsoft Fabric, tels que Power BI, SQL, Spark et autres.
Les moteurs Power BI et SQL utilisent la technologie Microsoft Verti-Scan et les fichiers Parquet avec V-Order pour obtenir des temps d’accès aux données en mémoire similaires. Spark et d’autres moteurs de calcul non-Verti-Scan bénéficient également des fichiers avec V-Order avec une moyenne de temps de lecture 10 % plus rapide, avec certains scénarios jusqu’à 50 %.
V-Order fonctionne en appliquant un tri spécial, la distribution de groupes de lignes, l’encodage de dictionnaire et la compression sur les fichiers Parquet. Par conséquent, les moteurs de calcul nécessitent moins de ressources réseau, disque et processeur pour lire les données à partir du stockage, ce qui offre une plus grande rentabilité et de meilleures performances. Son format Parquet 100 % open source compatible ; tous les moteurs Parquet peuvent le lire comme un fichier Parquet standard.
Considérations relatives aux performances
Tenez compte des éléments suivants avant de décider de désactiver V-Order :
- Le mode Microsoft Fabric Direct Lake dépend de V-Order.
- Dans l’entrepôt, l’effet sur les performances de V-Order peut varier en fonction des schémas de table, des volumes de données, des requêtes et des modèles d’ingestion.
- Veillez à tester la façon dont V-Order affecte les performances d’ingestion des données et de vos requêtes avant de décider de le désactiver. Envisagez de créer une copie de votre entrepôt de test à l’aide du contrôle de code source, de désactiver V-Order sur la copie et d’exécuter des tâches d’ingestion et d’interrogation de données pour tester les implications relatives aux performances.
Scénarios dans lesquels V-Order peut ne pas être bénéfique
Prenez en compte l’effet de V-Order sur les performances pour déterminer si la désactivation de V-Order est appropriée pour vous.
Attention
Actuellement, la désactivation de V-Order ne peut être effectuée qu’au niveau de l’entrepôt, et elle est irréversible : après désactivation, vous ne pouvez pas l’activer à nouveau. Les utilisateurs doivent prendre en compte les performances s’ils choisissent de désactiver V-Order dans l’entrepôt Fabric.
La désactivation de V-Order peut être utile pour les entrepôts nécessitant beaucoup d’écritures, comme les entrepôts dédiés aux données mises en lots dans le cadre d’un processus d’ingestion de données. Les tables de mise en lots sont souvent supprimées et recréées (ou tronquées) pour traiter de nouvelles données. Ces tables de mise en lots peuvent ensuite être lues une ou deux fois, ce qui peut ne pas justifier le temps d’ingestion ajouté en appliquant V-Order. En désactivant V-Order et en réduisant le temps d’ingestion des données, votre temps global de traitement des données pendant les travaux d’ingestion pourrait être réduit. Dans ce cas, vous devez séparer l’entrepôt de mise en lots de votre entrepôt principal accessible aux utilisateurs afin que les requêtes analytiques et Power BI puissent tirer parti de V-Order.