Nouveauté dans la vue Lakehouse : Spark Query

Pour celles et ceux qui ont déjà travaillé avec des Lakehouse sur Fabric, le développement en Spark SQL, et l’utilisation du SQL Endpoint (en T-SQL) pour la vérification ou les analyses usuelles peuvent devenir un vrai casse-tête.

Entre le code qui ne se transpose pas directement du T-SQL (coucou à toi le Select Top 100) vers le Spark SQL, le temps de rafraîchissement du SQL Endpoint et tous les autres petits détails, on passe son temps à jongler entre les deux mondes.

Sans parler des opérations d’update, de delete ou de merge, tout simplement impossibles côté SQL Endpoint (read-only oblige).

Microsoft Fabric introduit une nouveauté avec l’option Spark Query sur les Lakehouse.

Dans le fond, pas un énorme changement : juste la transposition d’un notebook directement dans la vue Lakehouse. Mais un peu de confort en plus.

Fini les notebooks qui polluent le workspace

Fini les Notebook 1,2,3,4,5…999 qui polluent le workspace dès que l’on veut faire une mise à jour des données et que l’on crée laborieusement sans jamais penser à les supprimer.

Et au passage, on y gagne quelques petits plus

IntelliSense sur les tables et colonnes, et plusieurs onglets de requêtes en parallèle, chacun avec son état et ses résultats.
Des requêtes cross-schema, et même cross-lakehouse (lakehouse.schema.table), depuis un seul onglet.
Des résultats exportables (CSV, JSON, XML) et des graphiques inline, sans une ligne de code.
Un « Save as View » pour persister une requête utile en vue, directement visible dans l’arborescence du Lakehouse.

Limites

Pas de sauvegarde des requêtes ni d’historique pour le moment (c’est annoncé pour une prochaine release), pas de PySpark, pas de vues matérialisées, pas de scheduling.

Et les onglets ne survivent pas à la fermeture du Lakehouse.

Bref, on gardera le bon vieux notebook_maintenance pour les actions répétitives.

Sous le capot

Finalement pour Fabric, c’est comme cliquer sur une table pour avoir un aperçu des données : une session Spark se lance et est visible dans le monitoring.
Bonne nouvelle côté consommation : plusieurs requêtes consomment la même session Spark. Le premier Run démarre une session légère via le endpoint Livy du Lakehouse, optimisée pour un démarrage rapide, puis les requêtes suivantes réutilisent la session déjà chaude : exécution immédiate, sans repasser par le « Starting Session ».

Conclusion

Pas une révolution, mais une addition bienvenue pour rendre l’outil plus simple d’accès et ergonomique.

Attention à bien garder le SQL Endpoint pour les analyses principales et pour les readers : quand la Spark Query n’est pas nécessaire, vous vous économiserez une session Spark (et la capacité qui va avec).😉

Source : la documentation officielle Microsoft – Query data by using the Lakehouse query explorer .

Vous industrialisez déjà des pipelines dans Microsoft Fabric ou vous commencez à structurer vos orchestrations ?

On peut échanger sur vos cas d’usage et vos patterns d’industrialisation.

Article rédigé par Romain Data Engineer Fabric

Contactez-nous !