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. Il est compatible avec Runtime 1.3 (Apache 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 plus rapide des tâches sans payer davantage, 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 GA, à savoir Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). Avec la publication du moteur d’exécution natif dans Runtime 1.3, la prise en charge de la version précédente (Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4)) n’est plus disponible. Nous encourageons tous les clients à effectuer une mise à niveau vers la dernière version (Runtime 1.3). Notez que si vous utilisez le moteur d’exécution natif sur Runtime 1.2, l’accélération native sera bientôt désactivée.
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 :
Accédez à vos paramètres d'environnement.
Accédez au calcul Spark.
Accédez à l’onglet Accélération.
Cochez la case intitulée Activer le moteur d’exécution natif.
Enregistrer et publier les modifications.
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.
Important
Auparavant, le moteur d’exécution natif était activé via les paramètres Spark au sein de la configuration de l’environnement. Avec notre dernière mise à jour (déploiement en cours), nous avons simplifié cela en introduisant un bouton bascule sous l’onglet Accélération des paramètres d’environnement. Réactivez le moteur d’exécution natif à l’aide du nouveau bouton bascule. Pour continuer à utiliser le moteur d’exécution natif, accédez à l’onglet Accélération dans les paramètres d’environnement, puis activez-le via le bouton bascule. Le nouveau bouton bascule dans l’IU est désormais prioritaire sur toutes les configurations de propriétés Spark précédentes. Si vous avez activé le moteur d’exécution natif via les paramètres Spark, il est désactivé jusqu’à ce qu’il soit réactivé via le bouton bascule de l’IU.
Conformément à la politique de blocage du déploiement Azure de Microsoft pendant les fêtes de Thanksgiving et de Black Friday, nous avons replanifié le déploiement pour la région USA Centre Nord (NCUS) au 6 décembre et au 9 décembre pour la région USA Est. Nous vous remercions par avance pour votre compréhension et votre patience pendant cette période chargée.
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",
}
}
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. 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 sur false pour la cellule spécifique contenant votre requête.
%%sql
SET spark.native.enabled=FALSE;
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.
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.
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 automatique permet de garantir l’absence d’interruption dans votre workflow.
Surveiller les requêtes et les dataFrames exécutés par le moteur
Pour bien comprendre comment le moteur d’exécution natif est appliqué aux requêtes SQL et aux opérations DataFrame, et pour descendre dans la hiérarchie au niveau de la phase et de l’opérateur, vous pouvez vous référer à l’interface utilisateur Spark et au serveur d’historique Spark pour obtenir des informations plus détaillées 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 génération de Gluten et les détails de l’exécution des requêtes. Le tableau Requêtes fournit des informations sur le nombre de nœuds qui s’exécutent sur le moteur natif et ceux qui reviennent à la machine virtuelle Java pour chaque requête.
Graphique 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.
Limites
Bien que le moteur d’exécution natif améliore les performances des travaux Apache Spark, notez ses limitations actuelles.
- Certaines opérations spécifiques à Delta ne sont pas prises en charge (pour le moment, car nous y travaillons activement), par exemple les opérations de fusion, les analyses 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 de solutions de stockage qui utilisent des points de terminaison privés ne sont pas (pour le moment, car nous y travaillons activement) prises en charge.
- Le moteur ne prend pas en charge le mode ANSI. Il effectue donc une recherche, et une fois le mode ANSI activé, il repasse automatiquement en mode Spark vanilla.
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' où 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.