Par Alexandre Lepage, Directeur principal, Entreprise numérique
Introduction
Depuis son lancement public en 2014, Snowflake a continuellement fait évoluer sa plateforme de données cloud en y introduisant de nouvelles fonctionnalités. C’est particulièrement notable du côté des divers moyens mis à la disposition des développeurs pour leur permettre de transformer le flocon de neige en blizzard. Cet article présente un survol pas même exhaustif de ces moyens. Il se veut surtout un prétexte pour rappeler la disponibilité générale toute récente du Snowflake Scripting.
Programmation
Comme la plupart des plateformes de données sur site ou dans le cloud, Snowflake offre une certaine flexibilité pour répondre à de nombreux cas d’usage. Les développeurs, qui ont carte blanche comme neige, ont l’embarras du choix et peuvent développer des applications de données hors Snowflake ou dans Snowflake.
Hors Snowflake
Snowflake supporte une panoplie de langages populaires en développement ou en analyse grâce à une variété de pilotes, connecteurs et APIs. Ne souhaitant mettre l’accent que sur la programmation dans Snowflake, je vais me contenter d’énumérer ici quelques-unes des options offertes hors Snowflake. J’en discuterai davantage dans un article futur. Peut-être.
Snowflake propose divers clients ou mécanismes assurant la connectivité :
- Pilotes : Go, JDBC, .NET, Node.js, ODBC, PHP PDO
- Connecteurs : Kafka, Python, Spark
- APIs : API SQL (RESTful HTTP), Snowpark (Java et Scala)
En gros, ceci signifie qu’on peut développer une application qui se connecte à Snowflake pour y lire, manipuler et sauvegarder des données dans la plupart des langages et technologies populaires ces dernières années. C’est vrai pour une application développée de zéro, c’est également vrai pour une application bâtie sur une quelconque plateforme d’intégration ou ETL no/low-code. Compte tenu de l’élasticité computationnelle offerte par Snowflake, on favorisera généralement une approche qui fera effectuer le gros du travail par Snowflake. Ce point est particulièrement significatif lorsque l’application est hébergée dans un cloud public et qu’on souhaite contrôler les coûts.
Dans Snowflake
Mais justement, comment s’assure-t-on de faire effectuer le gros du travail par Snowflake? Il y a plusieurs manières d’y arriver et l’emploi des APIs mentionnées précédemment peut en faire partie. Mais pour un grand nombre de développeurs de solutions analytiques, la réponse passera par le SQL, ou par quelque chose qui le prolonge.
Snowflake est d’abord et avant tout un moteur relationnel pouvant être interrogé à l’aide d’une syntaxe SQL conforme ANSI Snowflake. Pour bien des cas d’usage, ce sera suffisant. Mais immanquablement, plus tôt que tard, le développement d’une application de données nécessitera l’encapsulage de logiques de transformation ou l’utilisation des constructions de programmation typiques que sont les branches ou les boucles. Pour de telles situations, Snowflake fait comme la plupart des moteurs relationnels, pensons à BigQuery, Netezza, Oracle, PostgreSQL, Redshift, SQL Server, etc., et supporte le développement de fonctions et de procédures stockées.
Fonctions
Les fonctions dites « définies par l’utilisateur », ou UDFs, peuvent produire autant des résultats scalaires (une seule valeur) que tabulaires (un jeu de données), tous utilisables en SQL. Les UDFs scalaires ou tabulaires reçoivent aucun, un ou plusieurs paramètres et peuvent être programmées en :
- SQL : À employer lorsque l’exécution d’une seule requête SQL paramétrée suffit.
- JavaScript : À employer lorsqu’il ne s’agit plus d’exécuter une requête SQL mais de dériver un résultat des paramètres passés. Par exemple, le code suivant définit une UDF simple qui inverse l’ordre des éléments d’un ARRAY passé en paramètre :
Il est intéressant de savoir que le code JavaScript peut être aussi complexe que requis.
- Java : À employer pour essentiellement les mêmes raisons que le JavaScript. Évidemment, être plus familier avec le Java qu’avec le JavaScript ne nuira pas!
Aux UDFs s’ajoutent les fonctions externes. Ces fonctions permettent d’accéder à des APIs disponibles à l’extérieur de Snowflake et accessibles par le verbe HTTP POST, bénéficiant ainsi de fonctionnalités déjà exposées par divers services. Un scénario d’utilisation typique des fonctions externes est la classification selon un modèle d’apprentissage machine. Par exemple, la requête suivante analyse les sentiments qui ressortent de textes passés en appelant Azure Cognitive Services :
Le lecteur attentif argumentera ici qu’il ne s’agit plus tout à fait de programmation dans Snowflake mais parce que les fonctions externes offrent une extensibilité incroyable à Snowflake, il serait dommage de les passer sous silence.
Procédures stockées
Comme leurs noms le suggèrent, les procédures stockées servent à développer un code procédural qui exécute diverses requêtes SQL selon des critères et des séquences à respecter. Comme les UDFs, les procédures stockées reçoivent aucun, un ou plusieurs paramètres. Cependant, jusqu’à tout récemment, les procédures stockées Snowflake ne pouvaient produire que des résultats scalaires. Ce n’était pas un problème en soi pour le développeur astucieux puisque celui-ci pouvait toujours faire retourner l’identifiant d’une requête donnée pour exploiter le cache des résultats par la suite. Pour un développeur plus néophyte, c’était peut-être une autre histoire.
Pendant quelques années, les procédures stockées Snowflake ne pouvaient être programmées qu’en JavaScript. Maintenant, par l’entremise de l’API Snowpark, disponible en mode aperçu, on peut également développer des procédures stockées disons équivalentes en Java ou en Scala. L’arrivée dernière de Snowflake Scripting change maintenant la donne et j’en discute dans la section suivante. Peu importe le langage, les résultats produits par des procédures stockées ne sont pas directement utilisables en SQL.
À des fins illustratives, le code suivant définit une procédure stockée qui produit un jeu de données de 100 lignes contenant un nombre aléatoire uniforme, dans un intervalle précisé en paramètre :
Le jeu de données résultant n’est pas retourné par la procédure stockée, mais comme cette dernière a le bon goût de fournir l’identifiant de la requête qui compte, on peut toujours récupérer ledit jeu de à l’aide de la fonction RESULT_SCAN.
Snowflake Scripting
Généralement disponible depuis mai 2022, le Snowflake Scripting, soit l’exécution de scripts Snowflake en français, est la petite dernière des options de programmation dans Snowflake. Comme on peut s’en douter, cette nouvelle option est une extension au SQL qui permet de développer du code procédural presque exclusivement en SQL. En peu de mots, disons que le Snowflake Scripting est à Snowflake ce que le PL/SQL est à Oracle ou le T-SQL, à SQL Server.
Le Snowflake Scripting peut être employé en mode interactif, par exemple dans l’interface Web de Snowflake, ou en mode encapsulé dans une procédure stockée. Toujours à titre d’illustration, une réécriture en Snowflake Scripting de la procédure stockée précédente pourrait être :
Le même lecteur attentif remarquera cette fois-ci qu’une procédure stockée écrite en Snowflake Scripting peut produire un résultat tabulaire. Ce que les autres langages supportés ne permettent pas.
Qu’elles puissent produire des résultats autant scalaires que tabulaires est bien sûr un atout des procédures stockées codées en Snowflake Scripting mais le fait saillant est ailleurs. À mon avis, ce qui est déterminant avec le Snowflake Scripting, c’est qu’il permet de développer du code procédural à l’aide d’une certaine saveur SQL généralement familière aux équipes analytiques, en tout cas certainement plus que l’est d’habitude le JavaScript. Attention, je ne prétends pas ici que le langage SQL est supérieur au JavaScript! Après tout, le JavaScript n’a pas son pareil pour manipuler les types de données semi-structurés bien représentés en JSON par Snowflake (désolé pour les rockeurs déçus : les « JS » de JSON ne signifient pas « Joe Satriani »). Mais force est de reconnaître que travailler en SQL est probablement plus naturel à bien des développeurs de solutions analytiques que le faire en d’autres langages. Une chose est certaine : le Snowflake Scripting donne un souffle nouveau, un nordet quoi, aux efforts de migration vers Snowflake en mode lift & shift.
Le mot de la fin
Snowflake est une plateforme riche qui offre une multitude d’options en support au développement d’applications de données. Chacune de ces options répond à des cas d’usage spécifiques et est sujette à des limitations techniques ou… d’équipe. D’aucuns s’y perdront et clameront qu’à vouloir être très flexible, Snowflake couvre trop large. Leurs commentaires me laissent froid et, en ce qui me concerne, contrairement à la neige en janvier, je préfère trop que pas assez.
