Partage via


Moteur d’exécution natif pour Fabric Spark

Le moteur d’exécution natif est une amélioration révolutionnaire pour les exécutions de travaux Apache Spark dans Microsoft Fabric. Ce moteur vectorisé optimise les performances et l’efficacité de vos requêtes Spark en les exécutant directement sur votre infrastructure lakehouse. L’intégration transparente du moteur signifie qu’elle ne nécessite aucune modification du code et évite le verrouillage du fournisseur. Il prend en charge les API Apache Spark et est compatible avec Runtime 1.2 (Spark 3.4) et Runtime 1.3 (Spark 3.5) et fonctionne avec les formats Parquet et Delta. Quel que soit l’emplacement de vos données dans OneLake ou si vous accédez aux données via des raccourcis, le moteur d’exécution natif optimise l’efficacité et les performances.

Le moteur d’exécution natif élève considérablement les performances des requêtes tout en réduisant les coûts opérationnels. Il offre une amélioration remarquable de la vitesse, atteignant jusqu’à quatre fois plus de performances plus rapides par rapport aux systèmes d’exploitation traditionnels (logiciel code source ouvert) Spark, comme validé par le point de référence TPC-DS 1 To. Le moteur est capable de gérer un large éventail de scénarios de traitement de données, allant de l’ingestion des données de routine, des travaux par lots et des tâches ETL (extraire, transformer, charger), à des analyses de science des données complexes et à des requêtes interactives réactives. Les utilisateurs bénéficient de temps de traitement accélérés, d’un débit accru et d’une utilisation optimisée des ressources.

Le moteur d’exécution natif est basé sur deux composants OSS clés : Velox, une bibliothèque d’accélération de base de données C++ introduite par Meta et Apache Gluten (en développement), une couche intermédiaire chargée du déchargement de l’exécution des moteurs SQL basés sur JVM sur des moteurs natifs introduits par Intel.

Remarque

Le moteur d'exécution natif est actuellement en préversion publique. Pour plus d’informations, consultez les limitations actuelles. Nous vous encourageons à activer le moteur d’exécution natif sur vos charges de travail sans frais supplémentaires. Vous bénéficierez d’une exécution de travail plus rapide sans payer plus efficacement, vous payez moins pour le même travail.

Quand utiliser le moteur d’exécution natif

Le moteur d’exécution natif offre une solution pour exécuter des requêtes sur des jeux de données à grande échelle ; il optimise les performances à l’aide des fonctionnalités natives des sources de données sous-jacentes et réduit la surcharge généralement associée au déplacement et à la sérialisation des données dans les environnements Spark traditionnels. Le moteur prend en charge différents opérateurs et types de données, notamment l’agrégation de hachage cumulatif, la jointure de boucle imbriquée (BNLJ) et les formats d’horodatage précis. Toutefois, pour tirer pleinement parti des fonctionnalités du moteur, vous devez prendre en compte ses cas d’usage optimaux :

  • Le moteur est efficace lors de l’utilisation de données dans des formats Parquet et Delta, qu’il peut traiter en mode natif et efficace.
  • Les requêtes qui impliquent des transformations complexes et des agrégations bénéficient considérablement des fonctionnalités de traitement et de vectorisation en colonnes du moteur.
  • L’amélioration des performances est la plus notable dans les scénarios où les requêtes ne déclenchent pas le mécanisme de secours en évitant les fonctionnalités ou expressions non prises en charge.
  • Le moteur est bien adapté aux requêtes qui sont gourmandes en calcul, plutôt que simples ou liées aux E/S.

Pour plus d’informations sur les opérateurs et les fonctions pris en charge par le moteur d’exécution natif, consultez la documentation Apache Gluten.

Activer le moteur d’exécution natif

Pour utiliser les fonctionnalités complètes du moteur d’exécution natif pendant la phase d’aperçu, des configurations spécifiques sont nécessaires. Les procédures suivantes montrent comment activer cette fonctionnalité pour les notebooks, les définitions de travaux Spark et les environnements entiers.

Important

Le moteur d’exécution natif prend en charge la dernière version du runtime en disponibilité générale, qui est Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2) et l’ancienne version - Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4).

Activer au niveau de l’environnement

Pour garantir une amélioration uniforme des performances, activez le moteur d’exécution natif sur tous les travaux et notebooks associés à votre environnement :

  1. Accédez à vos paramètres d'environnement.

  2. Accédez au calcul Spark.

  3. Accédez à l’onglet Accélération .

  4. Cochez la case intitulée Activer le moteur d’exécution natif.

  5. Enregistrez et publiez les modifications.

    Capture d’écran montrant comment activer le moteur d’exécution natif à l’intérieur de l’élément d’environnement.

Lorsqu’ils sont activés au niveau de l’environnement, tous les travaux et notebooks suivants héritent du paramètre. Cet héritage garantit que toutes les nouvelles sessions ou ressources créées dans l’environnement bénéficient automatiquement des fonctionnalités d’exécution améliorées.

Activer pour un notebook ou une définition du travail Spark

Pour activer le moteur d’exécution natif pour un seul notebook ou une définition de travail Spark, vous devez incorporer les configurations nécessaires au début de votre script d’exécution :

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
       "spark.shuffle.manager": "org.apache.spark.shuffle.sort.ColumnarShuffleManager" 
   } 
} 

Pour les notebooks, insérez les commandes de configuration requises dans la première cellule. Pour les définitions de travaux Spark, incluez les configurations en première ligne de votre définition du travail Spark.

Capture d’écran montrant comment activer le moteur d’exécution natif à l’intérieur du notebook.

Le moteur d’exécution natif est intégré aux pools dynamiques. Par conséquent, une fois que vous avez activé la fonctionnalité, elle prend effet immédiatement sans vous obliger à lancer une nouvelle session.

Important

La configuration du moteur d’exécution natif doit être effectuée avant l’initiation de la session Spark. Une fois la session Spark démarrée, le paramètre spark.shuffle.manager devient immuable et ne peut pas être modifié. Assurez-vous que ces configurations sont définies dans le bloc %%configure dans les notebooks ou dans le constructeur de session Spark pour les définitions de jobs Spark.

Contrôle au niveau de la requête

Les mécanismes permettant d’activer le moteur d’exécution natif au niveau du locataire, de l’espace de travail et de l’environnement, intégrés en toute transparence à l’interface utilisateur, sont en cours de développement. En attendant, vous pouvez désactiver le moteur d’exécution natif pour des requêtes spécifiques, en particulier s’ils impliquent des opérateurs qui ne sont pas actuellement pris en charge (voir limitations). Pour désactiver, définissez spark.native.enabled de configuration Spark sur false pour la cellule spécifique contenant votre requête.

%%sql 
SET spark.native.enabled=FALSE; 

Capture d’écran montrant comment désactiver le moteur d’exécution natif à l’intérieur d’un notebook.

Après avoir exécuté la requête dans laquelle le moteur d’exécution natif est désactivé, vous devez le réactiver pour les cellules suivantes en définissant spark.native.enabled sur true. Cette étape est nécessaire, car Spark exécute des cellules de code de manière séquentielle.

%%sql 
SET spark.native.enabled=TRUE; 

Identifier les opérations exécutées par le moteur

Il existe plusieurs méthodes pour déterminer si un opérateur dans votre travail Apache Spark a été traité à l’aide du moteur d’exécution natif.

Serveur d’historique Spark et d’interface utilisateur Spark

Accédez au serveur d’historique Spark ou à l’interface utilisateur Spark pour localiser la requête que vous devez inspecter. Dans le plan de requête affiché dans l’interface, recherchez les noms de nœuds qui se terminent par le suffixe Transformer, NativeFileScan ou VeloxColumnarToRowExec. Le suffixe indique que le moteur d’exécution natif a exécuté l’opération. Par exemple, les nœuds peuvent être étiquetés comme RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer, ou BroadcastNestedLoopJoinExecTransformer.

Capture d’écran montrant comment vérifier la visualisation du DAG qui se termine par le suffixe Transformer.

Explication du DataFrame

Vous pouvez également exécuter la commande df.explain() dans votre notebook pour afficher le plan d'exécution. Dans la sortie, recherchez les mêmes suffixes Transformer, NativeFileScan ou VeloxColumnarToRowExec. Cette méthode permet de vérifier rapidement si des opérations spécifiques sont gérées par le moteur d’exécution natif.

Capture d’écran montrant comment vérifier le plan physique de votre requête et voir que la requête a été exécutée par le moteur d’exécution natif.

Mécanisme de secours

Dans certains cas, le moteur d’exécution natif peut ne pas être en mesure d’exécuter une requête en raison de raisons telles que des fonctionnalités non prises en charge. Dans ces cas, l’opération revient au moteur Spark traditionnel. Ce mécanisme de secours garantit qu’il n’y a aucune interruption de votre flux de travail.

Capture d’écran montrant le mécanisme de secours.

Capture d’écran montrant comment vérifier les journaux associés au mécanisme de secours.

Surveiller les requêtes et les dataFrames exécutés par le moteur

Pour mieux comprendre comment le moteur d’exécution native est appliqué aux requêtes SQL et aux opérations dataFrame, et pour explorer les niveaux intermédiaires et opérateur, vous pouvez faire référence au serveur d’historique Spark et à l’interface utilisateur Spark pour plus d’informations sur l’exécution du moteur natif.

Onglet Moteur d’exécution natif

Vous pouvez accéder à la nouvelle onglet « Gluten SQL / DataFrame » pour afficher les informations de build gluten et les détails de l’exécution des requêtes. La table Requêtes fournit des insights sur le nombre de nœuds s’exécutant sur le moteur natif et ceux qui reviennent à la machine virtuelle JVM pour chaque requête.

Capture d’écran montrant l’onglet moteur d’exécution natif.

Graph d’exécution de requête

Vous pouvez également cliquer sur la description de la requête pour la visualisation du plan d’exécution de requête Apache Spark. Le graphique d’exécution fournit des détails d’exécution natifs entre les étapes et leurs opérations respectives. Les couleurs d’arrière-plan différencient les moteurs d’exécution : le vert représente le moteur d’exécution natif, tandis que le bleu clair indique que l’opération s’exécute sur le moteur JVM par défaut.

Capture d’écran montrant le graphique d’exécution de requête.

Limites

Bien que le moteur d’exécution natif améliore les performances des travaux Apache Spark, notez ses limitations actuelles.

  • Le moteur ne prend pas en charge l’écriture partitionnée pour les tables Delta. Certaines opérations spécifiques à Delta ne sont pas prises en charge, notamment les opérations de fusion, les balayages de points de contrôle et les vecteurs de suppression.
  • Certaines fonctionnalités et expressions Spark ne sont pas compatibles avec le moteur d’exécution natif, comme les fonctions définies par l’utilisateur (UDF) et la fonction array_contains, ainsi que le streaming structuré Spark. L’utilisation de ces opérations ou fonctions incompatibles dans le cadre d’une bibliothèque importée entraîne également le basculement vers le moteur Spark.
  • Les analyses à partir de solutions de stockage qui utilisent des points de terminaison privés ne sont pas prises en charge.
  • Le moteur ne prend pas en charge le mode ANSI, donc il effectue des recherches, et une fois que le mode ANSI est activé, il revient à vanille Spark.

Lors de l’utilisation de filtres de date dans les requêtes, il est essentiel de s’assurer que les types de données des deux côtés de la correspondance de comparaison afin d’éviter les problèmes de performances. Les types de données incompatibles peuvent ne pas apporter d’amélioration de l’exécution des requêtes et nécessiter une projection explicite. Veillez toujours à ce que les types de données du côté gauche (LHS) et du côté droit (RHS) d’une comparaison soient identiques, car les types incompatibles ne seront pas toujours projetés automatiquement. Si une incompatibilité de type est inévitable, utilisez une projection explicite pour correspondre aux types de données, tels que CAST(order_date AS DATE) = '2024-05-20'. Les requêtes avec des types de données incompatibles qui nécessitent une projection ne seront pas accélérées par le moteur d’exécution natif, de sorte que la cohérence des types est essentielle pour maintenir les performances. Par exemple, au lieu de order_date = '2024-05-20'order_date est DATETIME et la chaîne est DATE, faites passer explicitement order_date à DATE pour garantir des types de données cohérents et améliorer les performances.

Remarque

Le moteur d’exécution natif est actuellement en préversion et vos insights sont importants pour nous. Nous vous invitons à partager vos commentaires et les résultats de votre évaluation directement avec notre équipe produit. Veuillez remplir le formulaire de commentaires. Nous nous réjouissons de vos précieuses contributions et sommes impatients de discuter de vos résultats en détail.