Snowflake & Snowpark Python

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 1 sur 17. Le plus gros bottleneck dans le big data, c'est rarement le stockage. La vraie friction arrive quand tu dois déplacer des datasets massifs sur le réseau juste pour atteindre ta couche de compute. L'architecture de Snowflake contourne complètement ce problème. On s'imagine souvent que Snowflake est juste une base de données relationnelle on-premise qu'on a lift and shift dans le cloud, ou un cluster Hadoop traditionnel que tu dois babysitter. Ce n'est ni l'un ni l'autre. Snowflake est un service entièrement self-managed, construit nativement pour le cloud. Tu n'installes aucun logiciel. Tu ne configures aucun hardware. Toute la maintenance, le management et le tuning sont gérés pour toi en arrière-plan. Pour comprendre comment il fait ça, regarde son architecture hybride. Snowflake combine une architecture shared-disk avec une architecture shared-nothing. Dans un design shared-disk classique, tous les nœuds de compute accèdent à un repository de données central. Dans un design shared-nothing, chaque nœud de compute a son propre chunk de données local à traiter. Snowflake prend le meilleur des deux. Il garde un seul repository de stockage central accessible à tous les nœuds de compute, mais il utilise des clusters de processing massivement parallèles et indépendants pour lancer les queries sur ces données. Ce modèle hybride se divise en trois couches distinctes. La première, c'est la couche Database Storage. Quand tu charges des données dans Snowflake, il ne se contente pas de dumper des fichiers bruts dans un bucket cloud. Il réorganise ces données dans un format interne, optimisé, compressé et en colonnes. Snowflake gère tous les aspects de la façon dont ces données sont stockées. Tu ne peux pas accéder directement au stockage brut, tu n'interagis avec lui que via des queries SQL. La deuxième couche, c'est le Query Processing. C'est là que le travail se fait en utilisant ce que Snowflake appelle des Virtual Warehouses. Un Virtual Warehouse, c'est tout simplement un cluster de compute indépendant. Comme le compute est strictement séparé de la couche de stockage centrale, plusieurs Virtual Warehouses peuvent query exactement les mêmes données en simultané. Ils ne sont pas en compétition pour les ressources, et ils ne se lockent pas entre eux. Voici le point clé. Tu peux scale ta puissance de compute instantanément sans déplacer un seul octet de données. Prends l'exemple d'un rapport financier de fin de mois qui demande une agrégation massive de données. Normalement, tu devrais peut-être migrer des tables vers un plus gros serveur pour gérer ce workload complexe. Dans Snowflake, tu as juste à spin up un plus gros Virtual Warehouse, faire tourner ton gros rapport en quelques minutes, et éteindre le warehouse quand tu as fini. Les tables sous-jacentes ne bougent jamais. La troisième couche qui relie tout ça, c'est les Cloud Services. C'est le cerveau de la plateforme. C'est une collection de services qui coordonnent tout à travers le système. Ça gère l'authentification des utilisateurs, ça manage l'infrastructure, ça parse les queries entrantes, et ça optimise les chemins d'exécution. Ça gère aussi les métadonnées, en trackant exactement où vivent des morceaux de données spécifiques dans la couche de stockage, pour que les queries puissent tourner efficacement sans avoir à tout scanner. Le truc le plus puissant à retenir, c'est que dans Snowflake, le scaling des performances est juste un simple switch sur le cluster de compute, pendant que les tables de données massives restent complètement immobiles. Si tu aimes cette série et que tu veux soutenir l'émission, tu peux nous trouver en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 2 sur 17. Et si tu pouvais écrire du pur Python et l'exécuter comme du SQL distribué hyper-optimisé ? C'est exactement le changement de paradigme qu'on aborde aujourd'hui avec une introduction à Snowpark. Traditionnellement, travailler avec de gros datasets en Python impliquait d'extraire les données de ta base de données. Tu écris une requête, tu récupères les données via le réseau dans ta mémoire locale ou sur un cluster de traitement externe, tu lances tes transformations, puis tu renvoies les résultats. Cette approche crée des goulots d'étranglement réseau, augmente les coûts d'infrastructure et introduit des risques de sécurité en sortant les données d'un environnement contrôlé. Snowpark inverse ce modèle. Au lieu de déplacer les données vers le compute, Snowpark pousse le compute vers les données. Une idée reçue très courante, c'est que Snowpark est un moteur de traitement externe. On s'imagine souvent qu'il faut déployer et gérer un cluster de compute séparé juste pour faire tourner du code Python. Ce n'est pas le cas. Les calculs Snowpark tournent directement dans Snowflake. Tu utilises exactement les mêmes virtual warehouses qui exécutent tes requêtes SQL standard. Il n'y a aucune nouvelle infrastructure à provisionner ou à maintenir. Quand tu écris du code avec l'API Python de Snowpark, tu interagis avec un objet DataFrame. C'est très similaire à l'utilisation de tes outils data Python habituels. Tu chaines les opérations entre elles, en définissant comment sélectionner, filtrer, grouper ou agréger tes données. Cependant, la library Snowpark n'exécute pas ces opérations en local. Au lieu de ça, elle traduit nativement tes opérations sur le DataFrame Python en constructions SQL complexes. Snowflake traite ensuite ces instructions SQL avec son moteur d'exécution standard. Voici le point clé. Snowpark utilise la lazy evaluation. Quand tu définis ton DataFrame et que tu appliques différentes transformations, aucune donnée n'est réellement déplacée ou modifiée. L'API Snowpark construit simplement un plan logique. Elle enregistre ton intention étape par étape. L'exécution réelle ne se déclenche que quand tu appelles une action spécifique, comme demander au système de renvoyer les résultats finaux ou de les écrire dans une nouvelle table. Ce modèle de lazy evaluation, combiné à la traduction SQL native, réduit considérablement les transferts de données. Imagine un scénario où tu es data engineer et que tu dois filtrer un milliard de lignes de données transactionnelles pour isoler quelques anomalies spécifiques. Tu écris ta logique de filtre dans un script Python en local. Comme l'exécution est différée jusqu'à ce que l'action soit appelée, l'API a le temps d'optimiser toute la chain d'opérations et de la traduire en une seule requête SQL ultra-performante. Le filtrage en lui-même se fait entièrement dans Snowflake. C'est la base de données qui fait tout le gros du travail. Les seules données qui transitent sur le réseau vers ta machine locale, c'est le petit sous-ensemble final d'anomalies. Tu viens de traiter un milliard de lignes en utilisant la syntaxe Python, sans charger un seul enregistrement brut dans ta mémoire locale. Le vrai avantage ici, c'est de garder une developer experience native en Python, tout en tirant parti du moteur de base de données pour ce qu'il fait de mieux. Tu écris du Python, mais Snowflake exécute du SQL. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 3 sur 17. Les boilerplates de connexion sont souvent un cauchemar de sécurité, remplis de mots de passe hardcodés et de variables d'environnement éparpillées. Tu veux donner à ton équipe un outil en ligne de commande local, mais tu ne peux absolument pas hardcoder les credentials dans le code. La solution, c'est d'établir une Session proprement en utilisant les features de configuration natives de Snowpark. Chaque script Snowpark commence par la création d'un objet Session. C'est ton lien actif vers l'environnement Snowflake. Il encapsule ton authentification, ton warehouse cible et ton contexte. Pour le construire, tu utilises l'objet builder disponible sur la classe Session. L'approche la plus directe, c'est de passer un dictionnaire. Tu crées un dictionnaire Python avec des clés pour ton account, ton user, ton password, ton role, ta database et ton warehouse. Tu passes ce dictionnaire à la méthode configs du session builder, puis tu appelles la méthode create. La logique coule directement de ton dictionnaire vers le backend Snowflake. Mais hardcoder des credentials dans un script Python est un risque de sécurité énorme, ce qui rend cette approche inadaptée pour des outils partagés. Pour retirer les credentials de ton code, Snowpark s'appuie sur un fichier de configuration standard appelé connections.toml. Tu places ce fichier soit à la racine de ton projet, soit dans un dossier caché snowflake à l'intérieur de ton répertoire utilisateur. Le fichier TOML contient des blocs de connexion. Tu peux définir un bloc default, un bloc dev et un bloc prod, chacun avec ses propres paramètres de connexion. Voici le point essentiel. Quand tu utilises un fichier TOML, ton code Python se simplifie considérablement. Tu ne passes plus de dictionnaire du tout. Tu appelles juste la méthode get ou create sur le session builder. Snowpark scanne automatiquement les répertoires standards, trouve ton fichier TOML, lit le bloc default et instancie la session. Si tu veux un environnement spécifique, tu passes le nom de la connexion à la méthode configs avant de créer la session. Ton code reste clean, et les credentials restent en toute sécurité sur la machine locale. On peut sécuriser notre outil en ligne de commande encore plus. Même avec un fichier TOML, tu ne veux peut-être pas que les développeurs stockent des mots de passe permanents en local. Tu peux éliminer complètement les mots de passe en utilisant le Single Sign-On via le navigateur. Dans ton fichier TOML, tu omets la clé password. À la place, tu ajoutes une clé appelée authenticator et tu définis sa valeur sur externalbrowser. Quand ton script atteint l'étape de création de la session, l'exécution se met en pause. Snowpark intercepte le process et ouvre automatiquement le navigateur web par défaut de l'utilisateur. Il redirige le développeur vers l'identity provider de ton organisation. Le développeur se connecte normalement, en validant toutes les exigences d'authentification multifacteur. Une fois que l'identity provider approuve la connexion, il renvoie un token d'authentification temporaire vers un port local sur lequel Snowpark écoute. Le script reçoit le token, établit la session Snowflake sécurisée, et l'exécution Python reprend. Ton outil CLI a maintenant un accès entièrement authentifié à Snowflake, sans qu'un seul mot de passe ne touche jamais tes fichiers de configuration ou ton code source. Le credential le plus sécurisé, c'est celui qui ne touche jamais ton code, et déléguer l'authentification au navigateur permet de garder tes scripts locaux à la fois sûrs et entièrement concentrés sur la data. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 4 sur 17. Tu veux tester une transformation de données rapide, mais ton environnement Python local est encore planté. Tes connection strings sont obsolètes, et tu viens de perdre vingt minutes à essayer de t'authentifier. Et si tu pouvais écrire du code sur un environnement entièrement configuré, directement dans ton navigateur, avec zéro setup ? C’est exactement le problème que résolvent les Python Worksheets dans Snowsight. Les Python Worksheets sont un éditeur de code natif intégré directement à l’interface web de Snowflake. Elles éliminent la friction de la configuration d'un environnement local. Imagine prototyper un petit script de nettoyage de données sur des données en live. Au lieu d’ouvrir un IDE et de gérer tes credentials, tu ouvres un onglet dans ton navigateur et tu commences à écrire du code immédiatement. La logique d’exécution repose sur un entry point spécifique. Tu n’écris pas un simple script procédural en vrac. Snowflake a besoin d’une fonction spécifique pour déclencher ton code. Par défaut, c'est une fonction handler appelée main. Cette fonction prend un seul argument, qui est l'objet session actif. Comme tu es déjà connecté à l'interface Snowflake, le système gère l'authentification automatiquement et passe une session en live directement à ta fonction main. Tu utilises cette session pour lire des tables, exécuter des requêtes et manipuler des données en utilisant les méthodes standard de Snowpark. Voici le point clé concernant les dépendances. Tu pourrais t'attendre à ouvrir un terminal et utiliser pip pour installer tes librairies, mais ce n'est pas comme ça que les worksheets fonctionnent. Tu n'utilises pas du tout pip. Snowflake s'intègre nativement avec le repository Anaconda. Dans l'interface de la worksheet, il y a un menu déroulant dédié aux packages. Tu cherches simplement la librairie dont tu as besoin, comme pandas ou scikit-learn, tu sélectionnes la version, et Snowflake la provisionne instantanément pour ton environnement d'exécution. Ça couvre les inputs et le setup. Et pour les outputs ? Ta fonction handler doit retourner une valeur, et tu configures comment Snowflake interprète cette valeur dans les settings de la worksheet. Tu choisis principalement entre deux types de retour, Table ou String. Si tu règles le type de retour sur Table, ta fonction main doit retourner un DataFrame Snowpark. Snowflake prend ce DataFrame et le rend sous forme de grille propre et interactive dans le panneau des résultats. C'est parfait pour inspecter l'output de ton script de nettoyage de données. Si tu règles le type de retour sur String, ta fonction doit retourner une valeur texte scalaire. Tu utilises ça quand tu veux retourner un message de statut, un agrégat numérique casté en texte, ou un payload JSON. Tu dois aligner ton code avec les settings de la worksheet. Si tu configures la worksheet pour attendre une Table mais que ta fonction retourne une String, l'exécution va échouer. La vraie puissance des Python Worksheets, ce n'est pas de construire des applications massives avec plein de fichiers. C'est la capacité de valider une logique de transformation sur des données à l'échelle de la production en quelques secondes, de manière sécurisée, sans jamais configurer de machine locale. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 5 sur 17. Si tu instancies un DataFrame qui représente un milliard de lignes, combien de mémoire ça utilise sur ton laptop ? Presque zéro. Ça s'explique par le fonctionnement de base de la création des DataFrames Snowpark. Un DataFrame Snowpark n'est pas un conteneur qui stocke tes infos. C'est simplement une référence logique vers des données qui résident dans Snowflake. Quand tu définis un DataFrame dans ton code Python, tu construis un query plan. Ça repose sur un concept qu'on appelle la lazy evaluation. Avec la lazy evaluation, Snowpark retarde l'exécution du SQL sous-jacent jusqu'à ce que tu déclenches explicitement une action qui nécessite un résultat final. Tant que ce trigger n'a pas lieu, chaque DataFrame que tu construis est juste un ensemble d'instructions très léger. La méthode principale pour commencer à construire ces instructions, c'est la méthode session dot table. Tu passes le nom d'une table ou d'une vue Snowflake existante sous forme de string. Tu peux fournir juste le nom de la table, ou un nom fully qualified qui inclut la database et le schema. Une erreur fréquente des nouveaux utilisateurs, c'est de supposer que l'appel à session dot table télécharge le contenu de la table dans leur environnement Python local, un peu comme le fait Pandas. Ce n'est pas le cas. Si tu pointes session dot table vers un log de transactions de dix téraoctets, la fonction Python retourne un résultat en quelques millisecondes. Aucune donnée ne voyage sur le réseau. L'objet DataFrame enregistre juste cette table spécifique comme le root node de ton execution plan. Une autre approche, c'est la méthode session dot sql. Tu l'utilises quand tu veux définir un DataFrame avec une string SQL brute. C'est particulièrement utile si tu as une query existante que tu veux porter, ou si tu préfères exprimer une extraction initiale spécifique en SQL. Tout comme la méthode table, passer une query à session dot sql n'envoie pas la query à Snowflake pour une exécution immédiate. Ça crée un DataFrame qui représente l'output de cette query spécifique. Tu peux voir ça comme la définition d'une inline view. Le troisième mécanisme, c'est la méthode session dot create dataframe. Celle-ci fonctionne différemment parce qu'elle commence avec des données qui se trouvent déjà sur ta machine locale. Tu peux passer une liste Python, un dictionnaire ou un DataFrame Pandas à cette méthode. Lors de l'exécution, Snowpark prend ces données locales, les uploade vers Snowflake et les place dans une table temporaire. La méthode retourne ensuite un DataFrame Snowpark qui pointe vers cette nouvelle table temporaire. Voici le point clé. Parce que session dot create dataframe déplace physiquement les données de ta machine vers Snowflake, ses performances dépendent entièrement de la taille de ton dataset local et de ta connexion réseau. Tu l'utilises pour pusher des petites lookup tables ou des paramètres de configuration dans Snowflake pour qu'ils puissent interagir avec tes datasets plus volumineux. Tu peux laisser Snowpark inférer les noms de colonnes et les data types à partir de tes objets locaux, ou tu peux définir explicitement un schema en utilisant un objet StructType de Snowpark pour garantir la précision. À chaque fois que tu construis un DataFrame Snowpark, quelle que soit la méthode, tu définis une relation vers des données plutôt que de récupérer les données elles-mêmes. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de coder !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 6 sur 17. Tu écris dix opérations complexes sur un DataFrame à la suite, mais le système n'exécute pas dix queries distinctes. Au lieu de ça, il retarde l'exécution et construit un seul statement SQL parfaitement optimisé en arrière-plan. Aujourd'hui, on parle de la transformation des DataFrames. Quand tu transformes un DataFrame, tu prépares une recette pour structurer tes données. Pour construire cette recette, tu as besoin d'un moyen fiable de référencer les colonnes de données sous-jacentes. Tu fais ça en utilisant une fonction qui s'appelle col. Tu passes le nom d'une colonne sous forme de string à cette fonction, et elle te retourne un objet colonne. Tu utilises ensuite cet objet dans d'autres méthodes pour construire des expressions, comme vérifier si la valeur d'une colonne est égale à un nombre spécifique ou à une string. Prenons un scénario concret. Tu as deux DataFrames. L'un contient les profils clients, et l'autre les enregistrements de transactions. Tu veux identifier les utilisateurs à forte valeur et les associer à leurs achats récents. Si tu écrivais ça en raw SQL, tu pourrais te retrouver avec une grosse query imbriquée qui t'oblige à lire la logique de l'intérieur vers l'extérieur. Avec les DataFrames, tu utilises le method chaining pour écrire la logique de haut en bas. D'abord, tu prends ton DataFrame client et tu appelles la méthode filter. À l'intérieur de ce filter, tu utilises la fonction col pour pointer vers la colonne du niveau de dépense, et tu spécifies qu'elle doit être égale à ton niveau le plus élevé. Juste après ce filter, tu chaînes une méthode select. Tu utilises à nouveau la fonction col pour indiquer que tu veux garder uniquement l'ID client et l'adresse e-mail. Chaque transformation retourne un nouveau DataFrame, ce qui te permet d'attacher l'instruction suivante directement à la fin de la précédente. Maintenant, la deuxième étape, c'est d'importer les données de transaction. Tu appelles la méthode join sur ton DataFrame client filtré. Tu passes le DataFrame de transactions comme premier argument. Ensuite, tu spécifies la condition pour le join, comme faire correspondre la colonne de l'ID client des deux datasets. Tu peux aussi définir le type de join, comme un inner join ou un left join. La logique se lit de manière séquentielle. Tu fais un filter, un select, et un join. Voici le point clé. Pendant que Python lit cette chaîne de méthodes, Snowpark ne touche pas aux données réelles. Les transformations sont évaluées de manière lazy. Le DataFrame agit simplement comme un blueprint. Il enregistre chaque filter, select et join que tu demandes, mais il ne les exécute pas étape par étape. Cette exécution différée permet au framework d'analyser toute ta séquence d'opérations et de l'optimiser avant que quoi que ce soit ne s'exécute vraiment. L'exécution ne se déclenche que quand tu demandes enfin un résultat concret. Ça nécessite d'appeler une méthode d'action. Si tu veux afficher un petit échantillon des données dans ton terminal, tu appelles la méthode show. Si tu veux télécharger les résultats entièrement traités dans ta mémoire Python locale, tu appelles la méthode collect. Au moment où tu appelles collect, Snowpark traduit ton blueprint en une seule query SQL efficace et l'envoie à Snowflake. Tu as l'avantage d'écrire du Python lisible, étape par étape, pendant que le moteur de base de données traite quand même les données en une seule passe hautement optimisée. C'est tout pour aujourd'hui. À la prochaine !

Bonjour, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 7 sur 17. Tu développes un data pipeline et tu as soudainement besoin d'une manipulation de string complexe ou d'une conversion mathématique obscure. Tu n'as pas besoin de coder cette logique from scratch en Python. La base de données sait déjà comment le faire. C'est là qu'interviennent les system functions. Snowflake intègre des centaines de system functions built-in, écrites en C++ hautement optimisé. Elles gèrent tout, du parsing de texte au calcul des écarts types. Snowpark te permet de déclencher ces fonctions SQL natives directement depuis ton code Python. Tu gardes la structure familière de Python, mais le gros du travail se fait entièrement à l'intérieur de Snowflake. Les données elles-mêmes ne quittent jamais le serveur pour être traitées dans ton environnement Python local. Pour y accéder, tu importes le module snowflake point snowpark point functions. Ce module contient des wrappers Python directs pour la plupart des opérations SQL standards. Si tu as besoin de convertir du texte en majuscules, il te suffit d'appeler la fonction upper de ce module et de lui passer ton objet column. En coulisses, Snowpark traduit ton code Python vers la syntaxe SQL équivalente et fait un push down vers la base de données pour l'exécuter. Ça couvre la majorité des use cases. Mais que se passe-t-il quand Snowflake sort une nouvelle fonction SQL, ou que tu as besoin d'utiliser une system function bien spécifique qui n'a pas encore de wrapper Python explicite dans le module ? Tu n'as pas besoin d'attendre la prochaine release de la library Snowpark pour l'utiliser. C'est ça le plus important. Tu peux utiliser une méthode dédiée appelée call_function pour invoquer n'importe quelle system function Snowflake par son nom SQL exact. Imagine un scénario où tu as une table avec des millions de lignes contenant des mesures d'angles en degrés, et que ton modèle de machine learning en aval les demande en radians. Au lieu de coder une transformation mathématique custom en Python qui charge toutes ces lignes en mémoire, tu laisses le moteur de la base de données faire le travail. Tu importes call_function. Ensuite, tu l'invoques en passant la string radians comme premier argument. Le deuxième argument est l'objet column que tu veux transformer. Snowpark fait instantanément un push down de cette opération SQL native radians sur l'ensemble de ton dataset. Ça s'exécute avec la vitesse d'un code C++ compilé, et ça te prend exactement une seule ligne de Python à écrire. La méthode call_function est flexible. Si la fonction SQL sous-jacente nécessite plusieurs inputs, il te suffit de les passer à la suite après le nom de la fonction. Ces inputs peuvent être d'autres objets column, ou ça peut être des valeurs littérales, comme une string spécifique ou un nombre. Snowpark mappe tes arguments Python directement vers les paramètres SQL attendus. Ce design garde ton code clean tout en maximisant les performances. Tu ne perds pas l'accès à la puissance brute des fonctions SQL natives de Snowflake juste parce que tu codes dans un langage différent. En tirant parti des system functions, tu traites Python comme l'orchestrateur, en laissant le moteur de la base de données faire exactement ce pour quoi il a été conçu. Merci de m'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 8 sur 17. Traditionnellement, scaler un pipeline pandas existant, ça voulait dire jeter ton code et tout réécrire dans un framework distribué comme Spark. Et si tu pouvais gérer un dataset cent fois plus gros juste en changeant un seul import ? C'est le principe de pandas sur Snowflake. pandas, c'est le standard universel pour la manipulation de données en Python. C'est expressif, lisible, et profondément ancré dans la façon de travailler des data engineers et des data scientists. Le problème, c'est que pandas est fondamentalement limité par une exécution single-node. Il faut que toutes tes données tiennent dans ta mémoire locale. Quand ton dataset devient trop gros pour ton ordi ou ton instance cloud, le pandas standard plante. pandas sur Snowflake représente un changement de paradigme complet pour ces pipelines legacy. Ça agit comme un outil de migration zéro friction. Imagine que tu as un script Python existant qui nettoie et agrège des logs de transactions quotidiens. Il marche parfaitement sur dix gigas de données, mais d'un coup, on te demande de traiter un téraoctet. Pour scaler ça, tu n'as pas besoin de réécrire ta logique en SQL. Tu n'as même pas besoin d'apprendre la syntaxe spécifique de l'API DataFrame standard de Snowpark. Tu changes juste une ligne en haut de ton fichier. Tu retires l'import standard import pandas as pd. Tu le remplaces par import snowflake.snowpark.modin.pandas as pd. C'est là que ça devient intéressant. Un point de confusion fréquent, c'est comment ça traite vraiment les données. Beaucoup de développeurs pensent que c'est juste du pandas standard qui tourne sur une connexion live, et qui pull des millions de lignes sur leur machine locale pour les process. C'est faux. Quand tu utilises cet import Modin spécifique, aucune donnée n'est téléchargée sur ta machine. À la place, cette librairie intercepte chaque commande pandas que tu écris dans ton script. Quand tu chain un filter, un group-by, et une aggregation de moyenne, le moteur sous-jacent traduit exactement cette séquence en une query SQL Snowflake optimisée. Il transpile ta syntaxe pandas en SQL, puis soumet ce SQL au compute engine de Snowflake. L'opération s'exécute entièrement à l'intérieur de ton warehouse Snowflake. Ta machine locale sert uniquement à orchestrer les commandes. Le gros du travail est distribué sur les clusters Snowflake. Ça te donne exactement la même developer experience que pandas, mais backé par une base de données massivement parallèle. Ce changement résout deux gros casse-têtes organisationnels d'un coup. Premièrement, ça élimine le problème de data egress. Comme les opérations sont pushed down vers la base de données, tes données brutes ne quittent jamais le périmètre sécurisé de Snowflake. Deuxièmement, ça économise des mois de formation pour les développeurs. Ton équipe continue d'écrire les dataframes, les joins et les aggregations qu'elle connaît déjà parfaitement. Ils les font juste tourner sur le cloud au lieu de leur processeur local. La vraie puissance de pandas sur Snowflake, c'est que ça découple le langage que tu utilises pour décrire tes transformations de données, du moteur qui les exécute réellement. Si tu trouves ces deep dives techniques utiles, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 9 sur 17. Ton code est maintenant assez intelligent pour savoir exactement quand utiliser la mémoire de ton laptop et quand démarrer un cluster cloud. C'est le concept de base derrière pandas sur Snowflake : l'Hybrid Execution. Quand tu utilises pandas standard, chaque opération tourne dans la mémoire de ta machine locale. Si tu charges un dataset massif, ton process plante. L'API Snowpark pandas résout ça en mappant tes commandes pandas en SQL et en les exécutant dans le warehouse Snowflake. Mais toutes les fonctions pandas n'ont pas un équivalent SQL direct. Certaines opérations, comme le plotting ou l'application de fonctions Python custom spécifiques, nécessitent la vraie librairie pandas locale pour s'exécuter. Le challenge, c'est de basculer de façon transparente entre le moteur cloud et ton environnement local sans faire transiter des gigaoctets de données brutes sur le réseau. L'Hybrid Execution gère cette transition dynamiquement. C'est un modèle d'exécution entièrement construit autour de l'optimisation pour obtenir le coût de transfert de données le plus bas possible. Quand tu lances un script en utilisant l'API Snowpark pandas, le moteur agit comme un routeur intelligent. Son comportement par défaut est de garder les données dans le cloud. Il traduit ton code en requêtes SQL et les exécute en utilisant le compute Snowflake. Prenons un scénario pratique. Tu commences avec une table contenant dix millions de lignes. Tu écris une ligne de code pour filtrer les records invalides, et ensuite tu groupes les données pour calculer une moyenne. Jusque-là, le moteur traduit tes commandes de filtre et d'agrégation directement en SQL. Le warehouse Snowflake fait le gros du travail. Ta machine locale ne télécharge pas une seule ligne de ce dataset massif. L'agrégation réduit ces dix millions de lignes à une table récapitulative d'exactement sept lignes. Pour ta prochaine étape, tu écris une commande pour plotter ces sept lignes dans un graphique. Le plotting est par nature une opération locale. Le moteur de base de données Snowflake ne peut pas dessiner un graphique pour toi. Voici le point clé. Le moteur reconnaît que la commande de plotting nécessite une transition vers le backend pandas local. Parce que le moteur traite tes opérations intelligemment, il regarde l'état de tes données juste avant que l'opération locale soit demandée. Il sait que l'agrégation précédente résulte en seulement sept lignes. Donc, au lieu de déplacer les dix millions de lignes originales vers ton laptop pour traiter l'agrégation localement, il laisse Snowflake finir les calculs dans le cloud. Ensuite, il déclenche un download de juste ces sept lignes finales dans ta mémoire locale. Une fois que les données arrivent dans ton environnement local, pandas standard prend le relais. La librairie locale exécute la commande de plot en utilisant ces sept lignes. Toute opération subséquente que tu fais sur cette structure de données spécifique continuera de tourner localement, parce que les données ont déjà traversé la frontière du réseau. Le système isole la manipulation lourde de données à l'intérieur de l'infrastructure cloud. Il repousse le transfert réseau jusqu'à ce qu'une opération demande strictement une exécution locale. Au moment où cette demande se produit, tes étapes de manipulation de données ont généralement réduit le dataset à une fraction de sa taille originale. Tu gardes la syntaxe d'API que tu connais déjà, mais tu évites complètement le bottleneck réseau. La caractéristique principale de l'Hybrid Execution n'est pas juste qu'elle bascule sur la mémoire locale, mais qu'elle réduit stratégiquement le payload dans le cloud avant de faire le saut. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 10 sur 17. Et si tu pouvais interroger une base de données PostgreSQL directement depuis ton script Python Snowflake ? Normalement, déplacer des données d'une base de données opérationnelle vers Snowflake nécessite un intermédiaire externe. Tu configures un outil d'extraction sur un serveur séparé, tu gères les credentials, tu mets les fichiers dans un stage, et tu planifies des jobs juste pour préparer tes données pour l'analyse. Ingérer des données externes directement via Snowpark Python résout ça en supprimant complètement l'intermédiaire. Cette approche te permet de simplifier ton architecture de données. En tirant parti de l'accès réseau externe dans Snowflake, ton code Python peut se connecter directement à d'autres systèmes. Tu peux utiliser des librairies Python DB-API standards ou des drivers JDBC pour te connecter à des bases de données externes, directement depuis une stored procedure Snowpark ou une user-defined table function. Prenons un scénario concret. Tu as une base de données d'inventaire PostgreSQL legacy on-premise, et tu dois join ces données d'inventaire avec tes tables clients Snowflake live. Au lieu de configurer un pipeline d'ingestion complexe, tu écris une stored procedure Snowpark Python. Dans cette procédure, tu utilises un connecteur Postgres DB-API standard. Tu passes ta connection string, qui fait référence à des credentials gérés de manière sécurisée par Snowflake. Tu ouvres la connexion, tu exécutes un statement SQL select standard sur la base de données PostgreSQL externe, et tu fetch le result set. Une fois que les données sont en mémoire dans ta fonction Python, tu yield simplement les lignes vers Snowflake, ou tu les convertis directement en un DataFrame Snowpark. Tu as maintenant tes données d'inventaire externes disponibles sous forme d'objet Snowflake natif, prêtes à être join avec tes tables clients dans une seule query. La logique coule du système opérationnel externe directement vers ton environnement analytique, de manière sécurisée et sans serveurs de staging intermédiaires. Ça, c'est pour les inputs relationnels. Qu'en est-il des sources de données semi-structurées, comme des fichiers nested déposés dans un stage ? Snowpark fournit aussi des tools spécifiques pour parser des formats complexes. Un excellent exemple est le reader XML RowTag. Quand tu dois ingérer un fichier XML lourd, tu n'as pas besoin d'écrire une logique de parsing custom pour naviguer dans tout l'arbre du document. À la place, tu spécifies un row tag. C'est l'élément XML spécifique qui représente un seul record. Tu appelles la méthode read sur ta session Snowpark, tu set le format sur XML, et tu fournis le paramètre row tag. Snowflake scanne le document, identifie chaque instance de ce tag, et l'extrait comme une ligne individuelle dans un DataFrame. La hiérarchie complexe au-dessus et en dessous de ce tag est flattened ou packée dans des colonnes, selon ton schéma. Ça transforme un document texte nested en une table propre et queryable en une seule étape. Voici l'idée clé. Que tu ouvres une connexion JDBC vers une ancienne base de données on-premise ou que tu pointes un reader row tag vers un fichier XML nested, tu consolides ta logique d'ingestion à l'intérieur de la data platform. Tu transformes des problèmes d'intégration en de simples problèmes d'exécution de code. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 11 sur 17. Comment tu exécutes une logique custom de string-parsing en Python sur des milliards de rows sans déplacer les données ? La réponse, c'est de créer des scalar UDFs, ou User-Defined Functions. Les fonctions SQL standards couvrent la plupart des transformations de données du quotidien. Quand le SQL standard ne suffit plus, les UDFs Python prennent le relais de façon transparente. Si tu gères des règles très custom, comme écrire une regex complexe pour parser des adresses e-mail un peu sales, le pur SQL devient vite illisible, voire impossible. Les scalar UDFs résolvent ce problème en te permettant d'écrire de la logique Python classique et de l'exécuter nativement dans le compute engine de Snowflake. Une scalar function traite simplement une row en input et retourne exactement une valeur en output. Pour deploy ton code Python, tu utilises Snowpark pour register la fonction. Si tu as juste besoin de cette logique pour ton script actuel, tu crées une UDF anonyme. Le moyen le plus simple de faire ça, c'est d'utiliser le decorator arobase UDF. D'abord, tu écris une fonction Python standard. Appelons-la extract email domain. À l'intérieur, tu utilises le module regex standard de Python pour parser la string et retourner le domaine matché. Juste au-dessus de la définition de la fonction, tu places le decorator arobase UDF. Quand ton script s'exécute, Snowpark sérialise automatiquement cette fonction Python, la push sur le serveur, et retourne une référence vers un objet UDF. Tu peux maintenant passer cet objet dans les opérations de colonnes de ton DataFrame, en appliquant ton parser custom sur des tables massives comme si c'était une feature native de la base de données. Sinon, tu peux zapper le decorator et passer ta fonction Python explicitement dans la méthode session point udf point register. Les deux méthodes créent un objet temporaire dans le database engine. Au moment où ta session Snowpark se ferme, l'UDF anonyme est entièrement dropped. C'est là que ça devient intéressant. Si ta nouvelle logique de parsing est utile, tu vas probablement vouloir la partager avec d'autres utilisateurs ou la rendre dispo pour des pipelines SQL downstream. Pour faire ça, tu crées une UDF nommée et permanente. En utilisant la même méthode register, tu ajoutes un flag is permanent mis sur true, et tu fournis une valeur string pour le paramètre name. Ce name dicte comment la fonction sera appelée dans la base de données. Quand tu rends une UDF permanente, Snowflake a besoin d'un endroit physique pour persister ton code Python pour qu'il reste dispo bien après la déconnexion de ta session. À cause de ça, tu dois aussi fournir un paramètre stage location. Ça pointe vers un stage interne Snowflake existant. Snowpark va upload et stocker en toute sécurité les fichiers Python compilés directement dans ce stage. Une fois la registration terminée, n'importe qui avec les bonnes permissions sur la base de données peut appeler ta logique Python custom directement depuis une query SQL standard. Lors de la création de n'importe quelle UDF, Snowpark se base généralement sur les type hints Python pour comprendre quels data types la fonction accepte et retourne. Si ta fonction attend une string et retourne une string, tu ajoutes ces type hints standards à la définition Python, et Snowpark les map automatiquement aux data types Snowflake équivalents. La vraie puissance de la scalar UDF, ce n'est pas juste la possibilité d'écrire du Python, mais la capacité d'exécuter ce Python dans la mémoire distribuée du database engine, éliminant complètement la network latency liée à l'extraction des données pour le processing. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 12 sur 17. Avant, faire tourner des packages Python tiers dans une base de données, c'était l'enfer des dépendances. Tu finissais par builder des conteneurs Docker complexes juste pour passer un array dans une fonction mathématique. Maintenant, ça prend exactement une ligne de code. Cet épisode couvre le Dependency Management pour les UDF. Quand tu écris une User-Defined Function, ou UDF, ta logique existe rarement dans le vide. Tu as besoin de libraries. Dans un setup traditionnel, déplacer ton code Python là où vivent les données signifie que tu dois aussi déplacer tout ton environnement. Tu te prends la tête avec les pip installs, les dépendances du compilateur, et le maintien d'un serveur identique à ta machine locale. Snowflake évite ce cauchemar automatiquement grâce à une intégration built-in avec le channel Anaconda. Le channel Anaconda de Snowflake héberge des milliers de packages Python pre-built et pre-compiled, qui sont garantis de fonctionner dans l'environnement d'exécution Snowflake. Pour les utiliser, tu n'installes rien manuellement. Tu déclares simplement ce dont ta fonction a besoin. Quand tu définis ton UDF en utilisant le décorateur Python, tu ajoutes un paramètre nommé packages. Tu passes à ce paramètre une liste de strings, nommant les libraries dont tu as besoin. Prends un scénario concret. Tu veux utiliser un modèle de machine learning pour scorer des rows directement dans une query Snowflake. Ta fonction de prédiction repose sur scikit-learn et pandas. Juste au-dessus de ta fonction Python, tu ajoutes le décorateur UDF et tu configures la liste packages pour qu'elle contienne les strings scikit-learn et pandas. Tu ne buildes pas de conteneur, et tu ne lances pas de package manager. Quand tu appelles cette UDF, Snowflake provisionne un environnement sécurisé, pull ces packages exacts depuis le channel Anaconda, et exécute ton code. Si tu as besoin d'une release spécifique, tu peux pin la version en ajoutant deux signes égal et le numéro de version directement dans la string, exactement comme dans un fichier requirements Python standard. Ça couvre les libraries externes. Maintenant, la deuxième partie de tout ça, c'est ton propre code custom. Tout ce que tu écris n'a pas sa place sur Anaconda. Tu as souvent des helper functions ou des règles métier custom écrites dans un fichier Python séparé. Snowflake gère ce code first-party via ta session active. Tu appelles une méthode nommée add import sur l'objet session. Tu passes le path de ton fichier custom à add import. Ça peut être un fichier Python local sur ton laptop, un fichier qui se trouve déjà dans un stage Snowflake, ou une archive zip contenant un répertoire plus profond de modules. Quand tu enregistres ton UDF, Snowflake récupère les fichiers que tu as spécifiés et les upload. Au runtime, Snowflake extrait ces fichiers et les place directement sur le system path de l'environnement isolé qui fait tourner ton UDF. À l'intérieur du code de ta fonction principale, tu utilises juste des statements import Python standards pour ramener tes modules custom, exactement comme s'ils se trouvaient dans le même dossier en local. Tu peux combiner librement ces deux approches. Tu déclares tes requirements externes via le paramètre packages, et tu injectes tes modules internes en utilisant add import. Snowflake construit le contexte d'exécution en fusionnant de manière sécurisée les binaires Anaconda avec tes fichiers custom en stage avant même qu'une seule row de données ne soit traitée. Voici le point clé. En gérant les dépendances de cette manière, Snowflake découple complètement ton code fonctionnel de l'infrastructure nécessaire pour le faire tourner, te permettant de définir un environnement d'exécution sécurisé et distribué en utilisant rien d'autre qu'une liste de noms et de paths de fichiers. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 13 sur 17. Qu'est-ce que tu fais quand ta fonction Python doit renvoyer une table entière de résultats au lieu d'une seule valeur ? Les User-Defined Functions standard sont super, mais elles sont strictement limitées à renvoyer une seule valeur scalaire par ligne d'input. Quand tu as besoin d'exploser un seul input en plusieurs outputs, tu construis une User-Defined Table Function, ou UDTF. La différence est fondamentale. Une fonction standard renvoie une valeur. Une UDTF renvoie une relation. Ça veut dire qu'elle renvoie une structure tabulaire que tu peux requêter, filtrer ou joindre avec d'autres tables exactement comme si c'était une table physique dans ta base de données. Prenons un scénario concret. Tu as une table avec une colonne qui contient des logs d'application JSON custom et très imbriqués. Chaque ligne contient une énorme entrée de log, mais cette seule entrée peut contenir cinq, dix ou cinquante événements système distincts cachés au fond du JSON. Tu dois normaliser ces données de façon programmatique. Tu veux passer une string JSON et récupérer une table structurée où chaque événement individuel est extrait dans sa propre ligne. Pour construire une UDTF dans Snowpark Python, tu n'écris pas une fonction standalone. Tu écris une classe Python. Cette classe agit comme le handler pour la table function et orchestre la logique en utilisant jusqu'à trois méthodes spécifiques. La première, c'est la méthode d'initialisation. Elle est optionnelle. Snowflake la lance une fois par partition avant de processer la moindre ligne. Si ton parser de logs a besoin de compiler une expression régulière complexe ou d'initialiser un dictionnaire d'état custom, tu le fais ici pour que le coût de setup ne soit payé qu'une seule fois par batch de données. La deuxième, c'est la méthode process. C'est la seule méthode obligatoire dans la classe. Snowflake l'appelle pour chaque ligne d'input. Dans notre scénario de logging, la méthode process reçoit la string JSON, unpack le tableau d'événements et boucle dessus. C'est là que la conversion se fait. Au lieu de retourner une valeur finale, la méthode process yield des tuples. Chaque tuple qu'elle yield devient instantanément une nouvelle ligne dans ta table d'output. Si une string de log JSON contient douze événements, la méthode process yield douze tuples séparés, et Snowflake les transforme en douze lignes d'output distinctes. La troisième, c'est la méthode end partition. Elle est aussi optionnelle. Snowflake la déclenche après que toutes les lignes de la partition courante soient passées par la méthode process. Tu l'utilises typiquement si tu agrégeais un état sur toute la partition et que tu as besoin de yield une ligne de résumé finale, ou simplement pour nettoyer la mémoire et les ressources. Quand tu enregistres cette classe handler dans Snowpark, tu dois déclarer explicitement ton schéma d'output. Parce qu'une UDTF renvoie une table, le moteur d'exécution de la base de données a besoin de connaître les noms de colonnes et les types de données exacts des tuples que tu yield avant même que la requête ne tourne. Voici l'idée clé. Les UDTF font le pont entre la logique Python complexe et les opérations de base de données relationnelle, ce qui te permet de wrapper un unnesting de données procédural et brouillon dans une interface de table propre que le reste de ton application peut requêter nativement. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 14 sur 17. Arrête de payer pour un serveur d'orchestration externe juste pour exécuter des scripts Python qui disent à Snowflake quoi faire. Créer des procédures stockées amène ce control flow directement dans la plateforme de données. On confond souvent les procédures stockées avec les User-Defined Functions, ou UDFs. Une UDF n'est pas faite pour l'orchestration. Les UDFs retournent des valeurs à l'intérieur d'une query et transforment les données ligne par ligne. Les procédures stockées sont complètement différentes. Elles exécutent des scripts entiers, lancent plusieurs requêtes et gèrent le control flow procédural. Tu les utilises pour orchestrer des tâches, pas pour calculer des valeurs de colonnes. Pour créer une procédure stockée dans Snowpark Python, tu écris une fonction Python standard. Le prérequis crucial, c'est le premier argument de cette fonction. Ça doit toujours être un objet Session Snowpark. Cette Session est ton lien actif avec la base de données. Quand ta procédure tourne, elle utilise cette session pour exécuter des statements SQL, construire des DataFrames, et lire ou écrire des données. Pour dire à Snowflake que cette fonction est une procédure stockée, tu places le décorateur sproc juste au-dessus de la définition de ta fonction. Le décorateur agit comme une couche de configuration. Tu l'utilises pour spécifier le return type de ta procédure et tous les packages Python tiers dont ton code a besoin pour tourner. Quand tu exécutes le code d'enregistrement, Snowpark prend ta fonction Python, la package avec ses dépendances, et l'enregistre dans Snowflake. À partir de là, la logique vit à l'intérieur de la base de données et s'exécute sur le compute de Snowflake. Imagine un data pipeline qui tourne la nuit. Ton process doit créer une table temporaire, y charger de la raw data, lancer une série de transformations en plusieurs étapes, et enfin nettoyer les objets temporaires. Si tu lances ça depuis un serveur externe, ton code Python envoie une commande sur le réseau, attend que Snowflake termine, récupère le résultat, et envoie la commande suivante. En écrivant exactement la même logique Python sous forme de procédure stockée, tout le script s'exécute à l'intérieur de Snowflake. Il utilise l'objet session pour enchaîner nativement les créations de tables et les transformations de DataFrames. Il y a zéro latence réseau entre la logique d'orchestration et les données qu'elle manipule. Même si une procédure stockée ne retourne pas une valeur par ligne comme une UDF, elle retourne quand même une valeur unique quand le script se termine. Tu définis ce return type quand tu configures le décorateur sproc. Souvent, c'est une simple string qui confirme le succès, un integer qui représente le total de lignes traitées, ou même un résultat tabulaire qui montre un log d'exécution. Tu as plusieurs choix pour la façon dont tu déploies ce code. Tu peux définir et lancer une procédure anonyme dynamiquement dans un script Python si tu n'en as besoin que pour une seule session. Pour les pipelines automatisés, tu l'enregistres comme un objet permanent. Snowflake stocke la définition pour que n'importe quel utilisateur autorisé, application externe ou tâche planifiée puisse l'appeler plus tard. Voici l'idée clé. Écrire une procédure stockée Snowpark Python, ça veut dire que tu traites Snowflake comme un runtime d'application, et pas juste comme une couche de stockage. Tu déplaces le cerveau de ton orchestration juste à côté des données qu'il contrôle. Si tu aimes l'émission et que tu veux soutenir notre travail, tu peux nous trouver en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 15 sur 17. Transférer des téraoctets de données sécurisées vers un serveur de machine learning externe est lent, coûteux et risqué. Tu passes des heures à pousser des données sur le réseau, et ton équipe de sécurité commence à stresser sur l'endroit où elles atterrissent. Et si le compute venait aux données à la place ? C'est l'idée principale derrière l'entraînement des modèles ML directement dans Snowflake. En utilisant Snowpark Python, tu peux entraîner des modèles de machine learning single-node directement dans ton data warehouse en utilisant des stored procedures. Les données ne quittent jamais le périmètre Snowflake. Ça résout le problème de data gravity. Au lieu d'extraire des millions de lignes vers une instance cloud séparée, tu exécutes ton training script exactement là où les données se trouvent. Entraîner un modèle de machine learning nécessite de charger le dataset en mémoire. Un virtual warehouse standard dans Snowflake est optimisé pour les requêtes SQL parallèles, pas pour stocker des datasets massifs dans la RAM du système. Si tu essaies de fit un algorithme complexe sur un warehouse standard, tu vas sûrement te prendre des erreurs out-of-memory et le process va crash. Pour gérer ça, tu as besoin d'un profil de compute différent. Snowflake propose des warehouses Snowpark-optimized spécialement pour cette tâche. Ces warehouses offrent jusqu'à seize fois plus de mémoire par node comparé aux instances standards. Prenons un scénario concret. Tu dois entraîner un modèle random forest scikit-learn sur un énorme dataset client. Tu commences par écrire une stored procedure Python. Quand tu enregistres cette procédure, tu spécifies les packages Python requis, comme scikit-learn, pandas et joblib. Snowflake provisionne automatiquement ces dépendances via son channel Anaconda intégré. Tu assignes aussi la procédure pour qu'elle tourne sur ton warehouse Snowpark-optimized. À l'intérieur de la procédure, tu utilises l'objet session Snowpark pour définir ta query de données de training. Tu appelles ensuite la méthode pour convertir ce dataframe Snowpark en un dataframe pandas standard. Cette action tire les résultats de la query directement dans la mémoire physique du node du warehouse. Comme tu as provisionné le compute optimisé, il y a plein de RAM pour contenir tout le dataset d'un coup. Ensuite, tu initialises ton modèle random forest et tu invoques la méthode fit, en lui passant le dataframe pandas. Le processeur du warehouse gère le cycle de training exactement comme il le ferait sur un serveur de machine learning dédié. Une fois que le modèle a fini son training, tu as un algorithme fitted qui se trouve dans la mémoire temporaire de l'environnement d'exécution. Tu dois le persister pour de futures prédictions avant que la stored procedure ne se termine. C'est là qu'intervient la serialization. Tu utilises une librairie comme joblib pour packager le modèle. Tu prends l'objet du modèle entraîné en mémoire et tu le dump dans un fichier, ce qui crée un artifact. Tu indiques ensuite à la stored procedure d'écrire ce fichier nouvellement créé directement dans un stage interne Snowflake. Un stage agit comme un dossier de stockage sécurisé lié à ton compte Snowflake. Voici l'idée clé. Ta stored procedure agit comme un conteneur sécurisé qui connecte tes tables brutes aux librairies de machine learning Python standards. En gardant le pipeline entièrement dans Snowflake, tu réduis ta latence réseau à zéro, tu contournes toutes les opérations de data egress, et tu maintiens des contrôles d'accès stricts, tout en écrivant exactement le même code de training Python que tu connais déjà. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 16 sur 17. Comment tu traites des fichiers non structurés de plusieurs gigaoctets à l'intérieur d'une user-defined function sans exploser tes limites de mémoire ? Si tu essaies de mapper des gros fichiers comme dépendances statiques, le système tente de tout télécharger en amont, et ton code crashe. La solution à ça, c'est le Dynamic File Access avec SnowflakeFile. Pour comprendre pourquoi c'est important, regarde comment l'accès aux fichiers fonctionne normalement dans Snowpark. D'habitude, tu utilises le paramètre imports pour lier un fichier à ta fonction. Cette approche statique est super pour des petits fichiers de configuration ou un modèle de machine learning spécialisé, parce que le fichier est rapatrié sur le compute warehouse avant que l'exécution commence. Mais ça ne tient plus la route à grande échelle. Si ton pipeline doit processer des centaines d'énormes fichiers de logs serveur ou des PDF haute résolution stockés dans un stage Snowflake, tous les télécharger statiquement est incroyablement lent et te garantit une erreur out-of-memory. C'est là qu'intervient la classe SnowflakeFile. Située dans le module snowflake point snowpark point files, cette classe permet à ta fonction ou stored procedure d'ouvrir des fichiers directement depuis un stage au runtime. Tu ne lies pas le fichier pendant la création de la fonction. À la place, ta fonction accepte l'emplacement du fichier comme un argument string standard. Quand tu appelles la fonction dans ta requête SQL ou ton opération sur un dataframe, tu lui passes cet emplacement. À l'intérieur du code Python, tu appelles la méthode open sur la classe SnowflakeFile et tu lui passes la string de l'emplacement du fichier. Tu spécifies aussi le mode de lecture, en utilisant les conventions Python standards comme r pour le texte ou r b pour lire des bytes. Voici le point clé. Appeler open ne charge pas le fichier. Ça renvoie un objet file-like qui stream les données. Le fichier reste sur le stage, et tu tires les données à travers un network pipe. Appliquons ça au scénario de processing de logs. Tu as une table de base de données où chaque ligne contient une scoped URL qui pointe vers un gros fichier de log différent sur un internal stage. Tu passes cette colonne d'URL à ta fonction. À l'intérieur de la fonction, tu ouvres le stream et tu écris une boucle standard pour lire le fichier ligne par ligne. Pendant que ton code évalue chaque ligne pour extraire des codes d'erreur ou des timestamps, Python supprime les lignes précédentes de la mémoire. Tu peux parser un fichier de log de cinquante gigaoctets alors que ta fonction ne garde qu'une seule ligne de texte en mémoire à n'importe quelle milliseconde. Exactement le même concept fonctionne pour les fichiers binaires. Si tu extrais du texte de gros PDF, tu ouvres le fichier en mode binaire et tu passes le stream obtenu directement dans une librairie Python de parsing de PDF. La librairie lit le byte stream séquentiellement sans avoir besoin que le document entier réside dans la mémoire système. SnowflakeFile gère aussi la security boundary automatiquement. Quand tu passes une scoped URL générée dynamiquement dans ta fonction, Snowflake accorde un accès en lecture à ce fichier spécifique juste pour la durée de la requête, et il expire immédiatement quand la requête se termine. Streamer des fichiers spécifiés dynamiquement garde ton empreinte mémoire plate peu importe la taille du fichier, ce qui laisse ton compute warehouse se concentrer entièrement sur le processing des données au lieu d'essayer juste de les stocker. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Snowflake et Snowpark Python, épisode 17 sur 17. Tu ne déploierais jamais du code d'application backend sans unit tests, alors pourquoi les data pipelines sont souvent poussés en production à l'aveuglette ? Snowpark change la donne en rendant ta data logic modulaire, ce qui te permet enfin de la tester comme un software classique. Tester Snowpark Python, c'est ce qui apporte la rigueur du software engineering au data engineering. Snowpark te permet d'extraire ta logique de transformation des scripts monolithiques pour la mettre dans des fonctions Python standalone. Comme ces fonctions prennent un DataFrame en input et renvoient un DataFrame en output, tu peux les tester avec des frameworks Python standards. PyTest est le choix le plus courant. Pour exécuter du code Snowpark, tu as besoin d'une session active. Au lieu d'embarquer les détails d'authentification dans chaque test, tu définis une fixture de session. Tu fais ça dans un fichier de configuration dédié appelé conftest.py, que PyTest reconnaît automatiquement. Dans ce fichier, tu écris une fonction de setup qui établit une connexion à Snowflake, renvoie l'objet session et ferme la session quand les tests sont terminés. Tu décores cette fonction comme une fixture PyTest. Maintenant, n'importe quel test de ton projet peut demander une session active simplement en la demandant par son nom dans les arguments de la fonction de test. Appliquons ça à un scénario concret. Tu as une transformation custom de DataFrame complexe qui filtre les utilisateurs inactifs, calcule un risk score et standardise les noms de colonnes. Tu dois valider cette logique avant de déployer le pipeline en production. Tu commences par écrire un test. La première étape dans ce test, c'est de créer un DataFrame en input contenant quelques lignes de mock data soigneusement sélectionnées. Tu définis les noms de colonnes et les valeurs de lignes exactes nécessaires pour déclencher les edge cases spécifiques de ta logique. Tu utilises ta fixture de session pour convertir ces raw mock data en un DataFrame Snowpark. Ensuite, tu passes ce DataFrame mocké en input à ta fonction de transformation. La fonction applique ta business logic et renvoie le DataFrame en output réel. Maintenant, tu dois vérifier que la logique a fait ce qu'elle était censée faire. Tu crées un deuxième DataFrame mocké dans ton test, qui représente cette fois le résultat exact attendu. C'est la partie qui compte. Tu dois comparer le DataFrame réel avec le DataFrame attendu. Cependant, tu ne peux pas juste utiliser un check d'égalité Python standard sur les objets DataFrame eux-mêmes, parce que ce ne sont que des références à des query plans. À la place, tu dois comparer les données qu'ils contiennent. Tu appelles la méthode collect sur les DataFrames réel et attendu pour ramener les résultats en mémoire sous forme de listes d'objets row. Comme les bases de données distribuées ne garantissent pas l'ordre des result sets sauf instruction explicite, comparer directement deux listes de rows peut échouer même si les données sont correctes. Pour corriger ça, tu tries les deux listes de rows avant de faire un assert sur leur égalité. Si les données réelles triées correspondent aux données attendues triées, ton test passe. En passant de petits datasets contrôlés dans des fonctions de transformation isolées, tu attrapes les erreurs logiques en local avant même qu'elles ne touchent une table de production. Ça isole les composants de ton pipeline et rend ton workflow de data engineering aussi fiable que le développement software traditionnel. Ça marque la fin de notre série sur Snowpark Python. Je t'encourage à explorer la documentation officielle de Snowflake, à essayer d'écrire ces tests hands-on, ou à visiter devstories.eu pour suggérer des sujets pour nos futures séries. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une bonne journée !