Par Maxime Fargeot, Directeur, Analytique des données
Connaissez-vous Snowpark, une puissante librairie conçue par et pour Snowflake? Dans cet article, nous allons parcourir les fonctionnalités clés de Snowpark et voir comment celui-ci tire parti du meilleur de Snowflake.
Qu’est-ce que Snowpark ?
Snowpark est une librairie de type API (Application Programming Interface) qui permet aux développeurs d’interagir avec Snowflake de manière programmatique.
Il devient alors possible de bénéficier de la puissance de calcul et de l’extensibilité de Snowflake pour interroger et manipuler efficacement de grands volumes de données tout en employant son langage préféré.
Des scénarios d’utilisation de Snowpark sont par exemple l’entraînement de modèles d’apprentissage-machine, le traitement par pipeline de données, l’analyse statistiques et bien d’autres encore.
Snowpark est une API polyvalente disponible pour trois langages de programmation populaires : Java, Python et Scala. De plus, il est possible de l’exploiter de diverses manières : en mode développement, dans un IDE ou dans un éditeur de code (VS Code, par exemple), ou de manière interactive, dans des notebooks (Jupyter, par exemple).
Les éléments clés de Snowpark
Les fonctionnalités de Snowpark reposent principalement sur trois éléments :
- Les dataframes, éléments de données fondamentaux ;
- La manipulation de données de manière programmatique (interface fluent) plutôt que déclarative (requêtes SQL) ;
- La réduction du transfert des données (exécution/instanciation lazy et pushdown).
Les dataframes Snowpark
Les dataframes sont bien connus des développeurs, analystes, scientifiques de données utilisant déjà des librairies telles que Pandas en Python, ou de diverses technologies basées sur Spark. Ici Snowflake nous offre son interprétation des dataframes au travers de son offre Snowpark.
Les dataframes Snowpark sont des jeux de données relationnels qui facilitent la manipulation de larges volumes de données tout en restant simples d’utilisation. Les données y sont représentées de manière tabulaire, un peu a l’image d’une table dans l’univers SQL. Toutefois, un dataframe ne contient pas de données. Il représente une structure sur laquelle il est possible de construire un ensemble d’opérations, un peu à l’image d’une requête SQL.
La manipulation programmatique
À la différence d’une requête SQL qui se veut déclarative : manipuler des dataframes par le code offre une grande flexibilité (interface « fluent »). Bien que tout à fait possible d’employer du SQL dans Snowpark, cela n’est pas nécessaire. On pourrait même aller jusqu’à dire qu’il serait plus naturel de ne pas utiliser de SQL dans un contexte Snowpark. En effet, pourquoi utiliser un second langage quand il est possible d’arriver à notre objectif grâce aux fonctionnalités intégrées dans l’API Snowpark. Écrire du code ouvre aussi tout un champ de possibilités et de personnalisation sur nos transformations !
Un autre avantage de Snowpark est sa capacité à gérer et piloter des fonctions et des procédures stockées dans Snowflake. Dans ce contexte, on pourrait se demander : pourquoi utiliser Snowpark plutôt que de manipuler directement ces objets dans Snowflake ? Tout simplement parce que Snowpark permet de gagner du temps et d’améliorer la maintenabilité en automatisant certaines opérations.
Par exemple, il devient inutile de mettre à jour manuellement dans Snowflake :
- Le code contenu dans une fonction ;
- L’import de librairies de code dans un stage.
En utilisant les paramètres appropriés : Snowpark s’en chargera pour vous.
De plus, ces procédures et fonctions seront aussi instanciables depuis Snowpark, applicables sur des dataframes, et exécutables dans Snowflake.
La réduction du transfert des données
Snowpark a comme objectif d’optimiser les calculs en les réalisant là où la puissance est disponible, et surtout au même endroit que les données, afin de limiter des transferts inutiles. Pour œuvrer dans ce sens, l’API Snowpark déporte les traitements et les ressources nécessaires à leur exécution directement dans Snowflake, en utilisant un principe de pushdown. Cette approche présente de nombreux avantages, notamment en termes de performances et de temps de traitement, comparativement à une exécution sur un environnement de travail personnel, dont la puissance est généralement limitée.
Une autre caractéristique intéressante, mais pas forcément propre aux dataframes de l’univers Snowpark, est l’instanciation « paresseuse » de ces derniers.
En effet, lorsqu’une série de transformations est effectuée sur un dataframe, celles-ci ne sont pas nécessairement exécutées immédiatement pour chaque commande (filtrer, sélectionner des colonnes, jointer, etc.). Ces opérations seront plutôt lancées en bloc au moment opportun, par exemple lors de l’appel à « dataframe.collect() ». Cette approche, si elle est comprise et maîtrisée, diminue à la fois la quantité de données échangées entre l’environnement client et Snowflake, et limite les coûts associés à d’inutiles calculs intermédiaires.
À noter que si divers langages de programmation sont utilisables dans Snowpark, les opérations réalisées sur les Dataframes sont transcrites sous forme de requêtes SQL en interne dans Snowflake. Ces dernières sont d’ailleurs consultables dans l’historique de Snowflake.
Des warehouses optimisés pour Snowpark
Snowflake propose maintenant la création de warehouses (ressources computationnelles) optimisés pour Snowpark. Ceux-ci offrent jusqu’à 16 fois plus de mémoire qu’un warehouse régulier. En bénéficient par exemple de certains traitements analytiques ou d’entraînement de modèles d’apprentissage-machine, souvent lourdement consommateurs en mémoire.
Concernant le coût de tels warehouses, il faut noter que leur utilisation est 50% plus onéreuse que celle de warehouses réguliers et qu’ils ne sont disponibles qu’en taille medium et plus. X-small et small ne sont pas des tailles supportées pour le moment. Cela dit, il n’est pas nécessaire d’employer Snowpark avec des warehouses optimisés pour celui-ci. Il demeure possible, et très souvent approprié, d’exécuter Snowpark sur des warehouses réguliers.
Pour finir…
Il convient de souligner que, bien que Snowpark offre une couche d’abstraction pour piloter certaines fonctionnalités de Snowflake de manière programmatique, une connaissance minimale de Snowflake est essentielle pour profiter pleinement de ses atouts.
Sans aucun doute, Snowpark est une librairie qui a toute sa place dans la boîte à outils d’un développeur Snowflake.
Dans un marché technologique changeant et concurrentiel, Snowpark est la proposition pertinente de Snowflake qui se positionne face à Spark. Il ne fait aucun doute que ce sujet pourrait à lui seul faire l’objet d’un nouveau billet de blogue… ?
Références & Sources
API Snowpark | Documentation Snowflake
Entrepôts optimisés pour Snowpark | Documentation Snowflake
Comprendre le coût du calcul | Documentation Snowflake
