Une plateforme data performante ne se mesure pas uniquement à la quantité de capacité dont elle dispose. Elle se mesure aussi à la manière dont cette capacité est utilisée.
Et si un même traitement pouvait s’exécuter jusqu’à six fois plus rapidement, sans nécessiter davantage de ressources ni imposer une réécriture complète du code ?
C’est l’une des promesses portées par Microsoft Fabric Runtime 2.0, désormais disponible en version GA (Generally Available) et prêt pour une utilisation en production.
Basé notamment sur Apache Spark 4.1, Delta Lake 4.2 et intégrant le Native Execution Engine, ce nouveau runtime marque une évolution importante pour les équipes Data Engineering et Data Science.
Mais au-delà de la mise à jour technologique, l’enjeu est également économique : exécuter plus efficacement les workloads signifie potentiellement mobiliser moins longtemps la capacité Fabric et donc mieux maîtriser son coût.
Pourquoi Runtime 2.0 mérite l’attention des entreprises
Dans une plateforme data moderne, performance et maîtrise des coûts sont étroitement liées.
Prenons un traitement Spark nécessitant aujourd’hui une heure de calcul. Si une évolution du moteur permet de réduire significativement son temps d’exécution, le bénéfice ne se limite pas au fait d’obtenir le résultat plus rapidement.
La capacité Fabric est également mobilisée moins longtemps.
À l’échelle de nombreux notebooks, pipelines et traitements quotidiens, ces gains peuvent devenir significatifs.
Microsoft annonce ainsi, sur certains benchmarks TPC-DS, des performances pouvant atteindre jusqu’à six fois celles d’Apache Spark open source grâce au Native Execution Engine.
Dans certaines conditions comparables et à capacité fixe, un traitement six fois plus rapide peut représenter une réduction théorique d’environ 83 % du compute nécessaire pour réaliser le même travail.
Il ne s’agit évidemment pas d’une promesse universelle de réduction de 83 % de la facture Fabric : les gains réels dépendent du workload, de sa configuration et de la proportion du traitement pouvant bénéficier de l’exécution native.
Mais le potentiel mérite clairement d’être mesuré.
Sous le capot : pourquoi Runtime 2.0 peut aller plus vite
Cette amélioration ne repose pas simplement sur davantage de puissance de calcul.
Runtime 2.0 fait évoluer plusieurs composants fondamentaux de la plateforme.
Le Native Execution Engine
Le Native Execution Engine constitue l’une des évolutions les plus importantes.
Basé notamment sur les technologies open source Apache Gluten et Velox, il permet de déplacer une partie de l’exécution des requêtes Spark hors de la JVM vers un moteur natif vectorisé en C++.
Concrètement, le traitement vectorisé permet d’exécuter efficacement des opérations sur des ensembles de données plutôt que de les traiter individuellement, tout en exploitant les capacités SIMD (Single Instruction, Multiple Data) des processeurs modernes.
L’intérêt pour les équipes data est majeur : certaines charges de travail existantes peuvent bénéficier de cette accélération sans modification du code applicatif.
Runtime 2.0 apporte également un parsing CSV vectorisé afin d’accélérer certains scénarios d’ingestion et de requêtage. D’autres capacités, notamment autour de JSON et de Structured Streaming, sont annoncées pour de futures évolutions.
Apache Spark 4.1
Runtime 2.0 s’appuie désormais sur Apache Spark 4.1.
Cette nouvelle génération apporte de nombreuses évolutions à Spark SQL et PySpark : support du type VARIANT, fonctions SQL définies par l’utilisateur, variables de session, nouvelles possibilités de syntaxe SQL, API native de visualisation Python ou encore amélioration des capacités de profiling.
Structured Streaming bénéficie également de nouvelles fonctionnalités facilitant notamment la gestion des états et le debugging.
Delta Lake 4.2
Le runtime intègre également Delta Lake 4.2, accompagné de nouvelles possibilités d’optimisation du stockage et de l’accès aux données.
Runtime 2.0 prend notamment en charge des mécanismes comme le Z-ordering, le Liquid Clustering et le chargement parallèle des snapshots Delta avec le Native Execution Engine.
L’objectif reste le même : organiser et accéder plus efficacement aux données afin de réduire le travail nécessaire à leur exploitation.
Plus rapide, mais surtout plus efficient
C’est probablement le changement de perspective le plus intéressant pour les décideurs.
Pendant longtemps, lorsqu’une plateforme data atteignait ses limites de performance, l’une des réponses naturelles consistait à augmenter les ressources disponibles.
Runtime 2.0 et le Native Execution Engine introduisent une autre logique : avant d’ajouter de la capacité, commençons par mieux utiliser celle dont nous disposons déjà.
Cette approche peut avoir un impact direct sur le ratio coût/performance d’une plateforme Fabric.
Un pipeline plus rapide libère plus tôt les ressources qu’il utilise. Un notebook optimisé réduit la pression exercée sur la capacité. Et une succession de gains sur des traitements exécutés quotidiennement peut, à terme, modifier sensiblement le dimensionnement nécessaire de la plateforme.
L’optimisation technique devient alors aussi un sujet FinOps.
Runtime 2.0 est GA : faut-il tout migrer maintenant ?
Non.
GA signifie que Runtime 2.0 est prêt pour une utilisation en production. Cela ne signifie pas que tous les workloads doivent être migrés sans qualification préalable.
Microsoft a d’ailleurs choisi une transition progressive.
Runtime 2.0 peut aujourd’hui être activé au niveau d’un workspace complet ou uniquement pour certains Environments, notebooks et Spark Job Definitions. Il n’est pas encore sélectionné par défaut.
Microsoft prévoit de faire de Runtime 2.0 le runtime par défaut pour les nouveaux workspaces et nouveaux Environments fin septembre 2026.
Cette période constitue donc une excellente fenêtre pour tester et préparer la transition.
Les points de vigilance avant de migrer
1. Tous les traitements ne bénéficieront pas des mêmes gains
Le Native Execution Engine ne prend pas nécessairement en charge chaque opération Spark.
Lorsqu’une partie d’une requête ne peut pas être exécutée nativement, Fabric peut s’appuyer sur le moteur JVM traditionnel.
Il est donc indispensable de mesurer les workloads réels plutôt que d’extrapoler les résultats d’un benchmark.
Des outils de diagnostic comme Fabric Spark Advisor permettent notamment d’identifier les opportunités d’optimisation et de mieux comprendre le comportement des traitements.
2. Tester les dépendances Python et les bibliothèques
La transition vers Runtime 2.0 implique également des évolutions importantes de l’environnement technique, notamment le passage à Python 3.13, Java 21 et Scala 2.13.
Microsoft signale actuellement un point d’attention concernant certains Environments utilisant des bibliothèques Python et Wheel.
Dans les environnements concernés, une republication des bibliothèques peut être nécessaire afin de recréer correctement l’Environment sur la nouvelle base Python.
Les notebooks et jobs Spark critiques doivent donc être qualifiés avant toute généralisation.
3. Prudence avec certaines fonctionnalités Delta Lake 4.2
Runtime 2.0 intègre Delta Lake 4.2, mais toutes ses possibilités ne doivent pas nécessairement être activées immédiatement.
Microsoft précise que certaines fonctionnalités spécifiques à Delta Lake 4.2 restent expérimentales et sont limitées aux expériences Spark, notamment les Notebooks et Spark Job Definitions.
Si les mêmes tables Delta doivent être exploitées par plusieurs workloads Microsoft Fabric, leur interopérabilité doit être vérifiée avant d’activer ces fonctionnalités.
La bonne stratégie : mesurer avant de généraliser
L’arrivée de Runtime 2.0 ne doit donc pas déclencher une migration massive sans discernement.
Elle doit déclencher un audit.
La démarche peut être relativement simple :
- Identifier les workloads Spark qui consomment le plus de capacité ou présentent les temps d’exécution les plus importants.
- Tester ces workloads avec Runtime 2.0 et le Native Execution Engine dans un environnement contrôlé.
- Mesurer les différences de temps d’exécution, de consommation et de compatibilité.
- Qualifier les éventuelles dépendances, bibliothèques et fonctionnalités Delta utilisées.
- Généraliser progressivement Runtime 2.0 lorsque les gains et la stabilité ont été validés.
L’objectif n’est pas de migrer parce qu’une nouvelle version existe.
Il est de déterminer où cette nouvelle version crée réellement de la valeur.
Une nouvelle étape pour l’optimisation de Microsoft Fabric
Runtime 2.0 illustre une évolution importante de Microsoft Fabric : améliorer les performances d’une plateforme data ne consiste plus uniquement à lui attribuer davantage de ressources.
Il s’agit aussi d’exécuter plus efficacement les traitements sur les ressources déjà disponibles.
Avec Apache Spark 4.1, Delta Lake 4.2 et surtout le Native Execution Engine, Microsoft ouvre ainsi de nouvelles possibilités pour améliorer simultanément performance, scalabilité et maîtrise des coûts.
Runtime 2.0 est désormais GA, mais Microsoft laisse encore aux organisations une période de transition avant d’en faire le choix par défaut pour les nouveaux environnements.
C’est précisément le bon moment pour mesurer.
Quels workloads consomment aujourd’hui le plus de capacité ? Lesquels peuvent bénéficier de l’exécution native ? Quels gains obtenez-vous réellement dans votre propre environnement ?
Car derrière les promesses de performance, c’est cette mesure qui permettra de transformer une évolution technologique en véritable optimisation de votre plateforme data.
Chez Ainos, nos experts Data accompagnent les organisations dans l’analyse, l’optimisation et l’évolution de leurs environnements Microsoft Fabric. Vous souhaitez évaluer ce que Runtime 2.0 peut apporter à votre plateforme ? Parlons-en.