Snowflake & Snowpark Python

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 1 di 17. Il più grande collo di bottiglia nei big data raramente è lo storage. Il vero problema nasce quando devi spostare enormi dataset attraverso la rete solo per raggiungere il tuo compute layer. L'architettura di Snowflake aggira completamente questo problema. Spesso si pensa che Snowflake sia solo un database relazionale on-premise migrato in cloud in lift and shift, o un tradizionale cluster Hadoop a cui devi fare da babysitter. Non è nessuna delle due cose. Snowflake è un servizio completamente self-managed, creato nativamente per il cloud. Non installi software. Non configuri hardware. Tutta la manutenzione, la gestione e il tuning vengono gestiti per te dietro le quinte. Per capire come ci riesce, guarda la sua architettura ibrida. Snowflake combina un setup shared-disk con un setup shared-nothing. In un design shared-disk tradizionale, tutti i compute node accedono a un unico data repository centrale. In un design shared-nothing, ogni compute node ha il proprio chunk di dati locale da elaborare. Snowflake prende il meglio di entrambi. Mantiene un singolo storage repository centrale accessibile a tutti i compute node, ma utilizza cluster indipendenti di massively parallel processing per eseguire le query effettive su quei dati. Questo modello ibrido si divide in tre layer distinti. Il primo è il layer di Database Storage. Quando carichi i dati in Snowflake, non fa un semplice dump dei file raw in un cloud bucket. Riorganizza quei dati in un formato interno, ottimizzato, compresso e colonnare. Snowflake gestisce tutti gli aspetti di come questi dati vengono archiviati. Non puoi accedere direttamente al raw storage, ci interagisci solo tramite query SQL. Il secondo layer è il Query Processing. È qui che avviene il lavoro, utilizzando quelli che Snowflake chiama Virtual Warehouse. Un virtual warehouse è semplicemente un compute cluster indipendente. Poiché il compute è strettamente separato dal layer di storage centrale, più virtual warehouse possono fare query sugli stessi identici dati simultaneamente. Non competono per le risorse e non si bloccano a vicenda. Ecco il punto chiave. Puoi scalare la tua potenza di compute istantaneamente senza spostare un singolo byte di dati. Pensa a un report finanziario di fine mese che richiede una massiccia aggregazione di dati. Normalmente, potresti dover migrare le tabelle su un server più grande per gestire il workload complesso. In Snowflake, ti basta fare lo spin up di un virtual warehouse più grande, far girare il report pesante in pochi minuti, e spegnere il warehouse quando hai finito. Le tabelle sottostanti non si muovono mai. Il terzo layer che tiene insieme tutto è quello dei Cloud Services. Questo è il cervello della piattaforma. È una collezione di servizi che coordinano tutto all'interno del sistema. Gestisce l'autenticazione degli utenti, amministra l'infrastruttura, fa il parsing delle query in entrata e ottimizza gli execution path. Gestisce anche i metadati, tracciando esattamente dove risiedono specifici pezzi di dati nel layer di storage, così le query possono girare in modo efficiente senza scansionare tutto. Il takeaway più potente è che in Snowflake, lo scaling delle performance è solo un interruttore sul compute cluster, mentre le enormi tabelle di dati rimangono completamente immobili. Se ti sta piacendo la serie e vuoi supportare lo show, puoi trovarci cercando DevStoriesEU su Patreon. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 2 di 17. E se potessi scrivere codice Python puro ma farlo eseguire come SQL distribuito iper-ottimizzato? Questo è esattamente il cambio di paradigma che tratteremo oggi con un'introduzione a Snowpark. Tradizionalmente, lavorare con grandi dataset in Python significava estrarre i dati dal tuo database. Scrivi una query, porti i dati attraverso la rete nella memoria locale o in un cluster di processing esterno, esegui le tue trasformazioni e poi fai il push dei risultati. Questo approccio crea colli di bottiglia nella rete, aumenta i costi dell'infrastruttura e introduce rischi per la sicurezza spostando i dati al di fuori di un ambiente controllato. Snowpark ribalta questo modello. Invece di spostare i dati verso il compute, Snowpark spinge il compute verso i dati. Un malinteso comune è che Snowpark sia un processing engine esterno. Spesso si pensa di dover avviare e gestire un compute cluster separato solo per eseguire codice Python. Non è così. I calcoli di Snowpark girano direttamente all'interno di Snowflake. Stai usando gli stessi virtual warehouse che eseguono le tue query SQL standard. Non c'è nessuna nuova infrastruttura di cui fare il provisioning o da mantenere. Quando scrivi codice usando l'API Python di Snowpark, stai interagendo con un oggetto DataFrame. È molto simile a lavorare con i familiari tool per i dati di Python. Metti in chain le operazioni, definendo come selezionare, filtrare, raggruppare o aggregare i tuoi dati. Tuttavia, la libreria Snowpark non esegue queste operazioni in locale. Invece, traduce nativamente le operazioni del tuo DataFrame Python in costrutti SQL complessi. Snowflake poi processa questi statement SQL usando il suo execution engine standard. Ecco il punto chiave. Snowpark usa la lazy evaluation. Quando definisci il tuo DataFrame e applichi varie trasformazioni, nessun dato viene effettivamente spostato o modificato. L'API di Snowpark costruisce semplicemente un logical plan. Registra il tuo intento passo dopo passo. L'esecuzione vera e propria viene triggerata solo quando chiami un'action specifica, come chiedere al sistema di restituire i risultati finali o di scriverli in una nuova tabella. Questo modello di lazy evaluation combinato con la traduzione SQL nativa riduce drasticamente il trasferimento dei dati. Immagina uno scenario in cui sei un data engineer incaricato di filtrare un miliardo di righe di dati transazionali per isolare alcune anomalie specifiche. Scrivi la tua logica di filtro in uno script Python in locale. Poiché l'esecuzione è ritardata finché non viene chiamata l'action, l'API ha il tempo di ottimizzare l'intera chain di operazioni e tradurla in una singola query SQL altamente efficiente. Il filtraggio vero e proprio avviene interamente all'interno di Snowflake. Il database fa tutto il lavoro pesante. Gli unici dati che viaggiano attraverso la rete verso la tua macchina locale sono il piccolo subset finale di anomalie. Hai appena processato un miliardo di righe usando la sintassi Python senza scaricare un singolo record grezzo nella tua memoria locale. Il vero vantaggio qui è mantenere la developer experience nativa in Python, sfruttando al contempo il database engine per ciò che sa fare meglio. Tu scrivi in Python, ma Snowflake esegue SQL. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 3 di 17. I boilerplate di connessione sono spesso un incubo per la sicurezza, pieni di password hardcoded ed environment variables sparse. Vuoi fornire al tuo team un command line tool locale, ma non puoi assolutamente inserire le credenziali direttamente nel codice. La soluzione è stabilire una Session in modo pulito utilizzando le feature di configurazione native di Snowpark. Ogni script Snowpark inizia creando un oggetto Session. Questo è il tuo collegamento attivo con l'ambiente Snowflake. Incapsula la tua autenticazione, il tuo warehouse di destinazione e il tuo context. Per crearlo, usi l'oggetto builder disponibile sulla classe Session. L'approccio più diretto è passare un dictionary. Crei un dictionary Python con le chiavi per account, user, password, role, database e warehouse. Passi questo dictionary al metodo configs del session builder, e poi chiami il metodo create. La logica fluisce direttamente dal tuo dictionary al backend di Snowflake. Ma inserire credenziali hardcoded all'interno di uno script Python è un enorme rischio per la sicurezza, rendendo questo approccio inadatto per dei tool condivisi. Per rimuovere le credenziali dal tuo codice, Snowpark si basa su un file di configurazione standard chiamato connections.toml. Metti questo file nella root del tuo progetto o in una directory nascosta chiamata snowflake all'interno della tua cartella home. Il file TOML contiene dei blocchi di connessione. Puoi definire un blocco default, un blocco dev e un blocco prod, ognuno con i propri parametri di connessione. Ecco il punto chiave. Quando usi un file TOML, il tuo codice Python si semplifica notevolmente. Non passi alcun dictionary. Ti basta chiamare il metodo get o create sul session builder. Snowpark scansiona automaticamente le directory standard, trova il tuo file TOML, legge il blocco default e istanzia la session. Se vuoi un environment specifico, passi il nome della connessione al metodo configs prima di creare la session. Il tuo codice rimane pulito e le credenziali restano al sicuro sulla macchina locale. Possiamo rendere il nostro command line tool ancora più sicuro. Anche con un file TOML, potresti non volere che i developer memorizzino password permanenti in locale. Puoi eliminare completamente le password utilizzando il single sign-on basato su browser. Nel tuo file TOML, ometti la chiave password. Invece, aggiungi una chiave chiamata authenticator e imposti il suo valore su externalbrowser. Quando il tuo script raggiunge lo step di creazione della session, l'esecuzione va in pausa. Snowpark intercetta il processo e apre automaticamente il web browser di default dell'utente. Reindirizza il developer all'identity provider della tua organizzazione. Il developer fa il login normalmente, soddisfacendo qualsiasi requisito di multi-factor authentication. Una volta che l'identity provider approva il login, invia un authentication token temporaneo a una porta locale su cui Snowpark è in ascolto. Lo script riceve il token, stabilisce la session sicura di Snowflake e l'esecuzione di Python riprende. Il tuo tool CLI ora ha un accesso completamente autenticato a Snowflake senza che una singola password tocchi mai i tuoi file di configurazione o il tuo source code. La credenziale più sicura è quella che non tocca mai il tuo codice, e delegare l'autenticazione al browser mantiene i tuoi script locali sia sicuri che completamente focalizzati sui dati. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 4 di 17. Vuoi testare una rapida trasformazione dati, ma il tuo environment Python locale è di nuovo rotto. Le tue connection string sono obsolete e hai appena perso venti minuti cercando di autenticarti. E se potessi scrivere codice su un environment completamente configurato direttamente nel browser, con zero setup? Questo è esattamente il problema risolto dai Python Worksheet in Snowsight. I Python Worksheet sono un code editor nativo integrato direttamente nell'interfaccia web di Snowflake. Rimuovono la frizione della configurazione dell'environment locale. Pensa a quando devi prototipare al volo uno script di data cleaning su dati live. Invece di aprire un IDE e gestire le credenziali, apri un tab del browser e inizi subito a scrivere codice. La logica di esecuzione si basa su un entry point designato. Non scrivi un semplice script procedurale slegato. Snowflake ha bisogno di una funzione specifica per fare il trigger del tuo codice. Di default, si tratta di una funzione handler chiamata main. Questa funzione prende un singolo argomento, ovvero l'oggetto session attivo. Dato che sei già loggato nell'interfaccia di Snowflake, il sistema gestisce l'autenticazione in automatico e passa una session live direttamente alla tua funzione main. Usi questa session per leggere tabelle, eseguire query e manipolare dati usando i metodi standard di Snowpark. Ecco il punto chiave per quanto riguarda le dipendenze. Magari ti aspetti di aprire un terminale e usare pip per installare le tue librerie, ma non è così che funzionano i worksheet. Non usi pip per niente. Snowflake si integra nativamente con il repository Anaconda. All'interno dell'interfaccia del worksheet, c'è un menu a tendina dedicato ai package. Ti basta cercare la libreria che ti serve, come pandas o scikit-learn, selezionare la versione, e Snowflake ne fa il provisioning all'istante per il tuo environment di esecuzione. Questo copre gli input e il setup. E per gli output? La tua funzione handler deve ritornare un valore, e sei tu a configurare come Snowflake interpreta questo valore tramite i setting del worksheet. Scegli principalmente tra due return type: Table o String. Se imposti il return type su Table, la tua funzione main deve ritornare un DataFrame Snowpark. Snowflake prende quel DataFrame e ne fa il render come una griglia pulita e interattiva nel pannello dei risultati. Questo è perfetto per ispezionare l'output del tuo script di data cleaning. Se imposti il return type su String, la tua funzione deve ritornare un valore di testo scalare. Lo usi quando vuoi ritornare un messaggio di stato, un aggregato numerico castato a testo, o un payload JSON. Devi allineare il tuo codice ai setting del worksheet. Se configuri il worksheet per aspettarsi un Table ma la tua funzione ritorna uno String, l'esecuzione fallirà. Il vero potere dei Python Worksheet non è creare enormi applicazioni multi-file. È la capacità di validare la logica di trasformazione su dati in scala di produzione in pochi secondi, in modo sicuro, senza mai configurare una macchina locale. Grazie per avermi fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 5 di 17. Se istanzi un DataFrame che rappresenta un miliardo di righe, quanta memoria utilizza sul tuo laptop? Quasi zero. Il motivo risiede nei meccanismi fondamentali di costruzione dei DataFrame di Snowpark. Un DataFrame di Snowpark non è un container che racchiude le tue informazioni. È semplicemente un riferimento logico ai dati che risiedono all'interno di Snowflake. Quando definisci un DataFrame nel tuo codice Python, stai costruendo un query plan. Questo si basa su un concetto chiamato lazy evaluation. Con la lazy evaluation, Snowpark ritarda l'esecuzione dell'SQL sottostante finché non triggeri esplicitamente un'azione che richiede un risultato finale. Fino a quel trigger, ogni DataFrame che costruisci è solo un set leggero di istruzioni. Il modo principale per iniziare a costruire queste istruzioni è il metodo session dot table. Passi il nome di una table o view di Snowflake esistente come string. Puoi fornire solo il nome della table, oppure un fully qualified name che includa il database e lo schema. Un errore frequente che fanno i nuovi utenti è presumere che chiamare session dot table scarichi i contenuti della table nel loro ambiente Python locale, in modo simile a come opera Pandas. Non è così. Se punti session dot table a un transaction log di dieci terabyte, la funzione Python ritorna in millisecondi. Nessun dato viaggia sul network. L'oggetto DataFrame si limita a registrare quella specifica table come root node del tuo execution plan. Un altro approccio è il metodo session dot sql. Lo usi quando vuoi definire un DataFrame usando una raw SQL string. È particolarmente utile se hai una query esistente di cui vuoi fare il porting, o se preferisci esprimere una specifica estrazione iniziale in SQL. Proprio come per il metodo table, passare una query a session dot sql non invia la query a Snowflake per un'esecuzione immediata. Crea un DataFrame che rappresenta l'output di quella specifica query. Puoi vederla come la definizione di una inline view. Il terzo meccanismo è il metodo session dot create dataframe. Questo funziona in modo diverso perché parte da dati già presenti sulla tua macchina locale. Puoi passare a questo metodo una list Python, un dictionary o un DataFrame Pandas. Quando eseguito, Snowpark prende quei dati locali, ne fa l'upload su Snowflake e li inserisce in una temporary table. Il metodo ritorna quindi un DataFrame Snowpark che punta a quella nuova temporary table. Ecco il punto chiave. Poiché session dot create dataframe sposta fisicamente i dati dalla tua macchina a Snowflake, le sue performance dipendono interamente dalle dimensioni del tuo dataset locale e dalla tua network connection. Lo usi per pushare piccole lookup table o parametri di configurazione in Snowflake, così che possano interagire con i tuoi dataset più grandi. Puoi lasciare che Snowpark inferisca i nomi delle colonne e i data type dai tuoi oggetti locali, oppure puoi definire esplicitamente uno schema usando un oggetto StructType di Snowpark per garantire la precisione. Ogni volta che costruisci un DataFrame Snowpark, indipendentemente dal metodo, stai definendo una relazione con i dati anziché recuperare i dati stessi. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake & Snowpark Python, episodio 6 di 17. Scrivi dieci operazioni complesse su un DataFrame in sequenza, ma il sistema non esegue dieci query separate. Invece, ritarda l'esecuzione e costruisce un'unica istruzione SQL perfettamente ottimizzata dietro le quinte. Oggi parliamo della trasformazione dei DataFrame. Quando trasformi un DataFrame, stai preparando una ricetta per dare forma ai tuoi dati. Per costruire questa ricetta, ti serve un modo affidabile per fare riferimento alle colonne di dati sottostanti. Lo fai usando una funzione chiamata col. Passi il nome di una colonna come string a questa funzione, e ti restituisce un oggetto colonna. Poi usi questo oggetto all'interno di altri metodi per costruire espressioni, come controllare se il valore di una colonna è uguale a un numero specifico o a una text string. Vediamo uno scenario concreto. Hai due DataFrame. Uno contiene i profili dei clienti e l'altro i record delle transazioni. Vuoi identificare gli utenti di alto valore e collegarli ai loro acquisti recenti. Se lo scrivessi in raw SQL, potresti ritrovarti con una query annidata enorme, che ti costringe a leggere la logica dall'interno verso l'esterno. Con i DataFrame, usi il method chaining per scrivere la logica dall'alto verso il basso. Per prima cosa, prendi il tuo DataFrame dei clienti e chiami il metodo filter. All'interno di quel filter, usi la funzione col per puntare alla colonna della fascia di spesa, e specifichi che deve essere uguale alla tua fascia più alta. Subito dopo quel filter, aggiungi in chain un metodo select. Usi di nuovo la funzione col per dichiarare che vuoi tenere solo il customer ID e l'indirizzo email. Ogni trasformazione restituisce un nuovo DataFrame, permettendoti di attaccare l'istruzione successiva direttamente alla fine di quella precedente. Ora, la seconda parte consiste nel portare dentro i dati delle transazioni. Chiami il metodo join sul tuo DataFrame dei clienti filtrato. Passi il DataFrame delle transazioni come primo argomento. Poi, specifichi la condizione per la join, come ad esempio far corrispondere la colonna del customer ID da entrambi i dataset. Puoi anche definire il tipo di join, come una inner o una left join. La logica si legge in modo sequenziale. Fai un filter, un select e una join. Ecco il punto chiave. Mentre Python legge questa chain di metodi, Snowpark non tocca i dati veri e propri. Le trasformazioni vengono valutate in modo lazy. Il DataFrame fa semplicemente da blueprint. Registra ogni filter, select e join che richiedi, ma non li esegue passo dopo passo. Questa esecuzione ritardata permette al framework di guardare l'intera sequenza di operazioni e ottimizzarla prima che qualsiasi cosa venga effettivamente eseguita. L'esecuzione scatta solo quando finalmente richiedi un risultato concreto. Questo richiede la chiamata di un metodo di action. Se vuoi stampare un piccolo campione dei dati sul tuo terminal, chiami il metodo show. Se vuoi scaricare i risultati completamente elaborati di nuovo nella tua memoria locale di Python, chiami il metodo collect. Nel momento in cui chiami collect, Snowpark traduce il tuo blueprint in un'unica query SQL efficiente e la invia a Snowflake. Ottieni il vantaggio di scrivere codice Python leggibile e passo dopo passo, mentre il database engine elabora comunque i dati in un unico passaggio altamente ottimizzato. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 7 di 17. Stai creando una data pipeline e improvvisamente hai bisogno di una complessa string manipulation o di una conversione matematica insolita. Non devi scrivere quella logica da zero in Python. Il database sa già come farlo. È qui che entra in gioco la chiamata alle system function. Snowflake ha centinaia di system function built-in scritte in C++ altamente ottimizzato. Queste gestiscono di tutto, dal parsing del testo al calcolo delle deviazioni standard. Snowpark ti permette di richiamare queste funzioni SQL native direttamente dal tuo codice Python. Hai la struttura familiare di Python, ma il lavoro pesante avviene interamente all'interno di Snowflake. I dati effettivi non lasciano mai il server per essere elaborati nel tuo ambiente Python locale. Per accedervi, importi il modulo snowflake dot snowpark dot functions. Questo modulo contiene wrapper Python diretti per la maggior parte delle operazioni SQL standard. Se hai bisogno di convertire il testo in maiuscolo, ti basta chiamare la funzione upper da questo modulo e passarle il tuo oggetto column. Dietro le quinte, Snowpark traduce il tuo codice Python nella sintassi SQL equivalente e ne fa il pushdown al database per l'esecuzione. Questo copre la maggior parte degli use case. Ma cosa succede quando Snowflake rilascia una nuova funzione SQL, o hai bisogno di usare una system function specializzata che non ha ancora un wrapper Python esplicito nel modulo? Non devi aspettare la prossima release della libreria Snowpark per usarla. Questa è la parte che conta. Puoi usare un metodo dedicato chiamato call_function per invocare qualsiasi system function di Snowflake tramite il suo esatto nome SQL. Considera uno scenario in cui hai una tabella con milioni di righe che contengono misurazioni di angoli in gradi, e il tuo modello di machine learning a valle le richiede in radianti. Invece di scrivere una trasformazione matematica custom in Python che trascina tutte quelle righe in memoria, lasci che sia il database engine a fare il lavoro. Importi call_function. Poi, la invochi passando la string radians come primo argomento. Il secondo argomento è l'oggetto column che vuoi trasformare. Snowpark ne fa istantaneamente il pushdown come operazione SQL nativa radians su tutto il tuo dataset. Viene eseguita con la velocità del codice C++ compilato, e ti basta esattamente una riga di Python per scriverla. Il metodo call_function è flessibile. Se la funzione SQL sottostante richiede input multipli, ti basta passarli in sequenza dopo il nome della funzione. Questi input possono essere altri oggetti column, oppure possono essere valori letterali, come una string o un numero specifico. Snowpark mappa i tuoi argomenti Python direttamente ai parametri SQL previsti. Questo design mantiene il tuo codice pulito massimizzando al contempo le performance. Non perdi l'accesso alla potenza pura delle funzioni SQL native di Snowflake solo perché stai scrivendo in un linguaggio diverso. Sfruttando le system function, tratti Python come orchestratore, lasciando che il database engine faccia esattamente ciò per cui è stato creato. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 8 di 17. Scalare una pipeline pandas esistente tradizionalmente significava buttare via il tuo codice e riscriverlo completamente in un framework distribuito come Spark. E se potessi gestire un dataset cento volte più grande semplicemente modificando un singolo import? Questa è la premessa di pandas su Snowflake. pandas è lo standard universale per la manipolazione dei dati in Python. È espressivo, leggibile e profondamente radicato nel modo di lavorare dei data engineer e dei data scientist. Il problema è che pandas è fondamentalmente limitato dall'esecuzione single-node. Richiede che tutti i tuoi dati stiano nella memoria locale. Quando il tuo dataset supera le capacità del tuo laptop o della tua istanza cloud, pandas standard smette di funzionare. pandas su Snowflake rappresenta un completo cambio di paradigma per queste pipeline legacy. Agisce come un tool di migrazione zero-friction. Supponi di avere uno script Python esistente che pulisce e aggrega i log delle transazioni giornaliere. Funziona perfettamente con dieci gigabyte di dati, ma improvvisamente ti viene richiesto di elaborarne un terabyte. Per scalare tutto questo, non devi riscrivere la tua logica in SQL. Non devi nemmeno imparare la sintassi specifica delle API standard di Snowpark DataFrame. Ti basta cambiare una sola riga all'inizio del tuo file. Rimuovi lo standard import pandas as pd. Lo sostituisci con import snowflake.snowpark.modin.pandas as pd. Ed è qui che diventa interessante. Un punto di confusione comune è come questo elabori effettivamente i dati. Molti developer danno per scontato che si tratti solo di pandas standard che opera su una live connection, tirando giù milioni di righe sulla loro macchina locale per elaborarle. Questo è sbagliato. Quando usi questo specifico import di Modin, nessun dato viene scaricato sulla tua macchina. Invece, questa libreria intercetta ogni comando pandas che scrivi nel tuo script. Quando metti in chain un filter, un group-by e una mean aggregation, l'engine sottostante traduce quell'esatta sequenza in una query SQL ottimizzata per Snowflake. Fa il transpile della tua sintassi pandas in SQL, e poi invia quell'SQL al compute engine di Snowflake. L'operazione viene eseguita interamente all'interno del tuo warehouse Snowflake. La tua macchina locale si occupa solo di orchestrare i comandi. Il lavoro più gravoso viene distribuito tra i cluster Snowflake. Questo ti dà l'esatta developer experience di pandas, ma supportata da un database massivamente parallelo. Questo passaggio risolve due grossi mal di testa organizzativi in un colpo solo. Primo, elimina il problema del data egress. Poiché le operazioni vengono eseguite in pushdown sul database, i tuoi raw data non escono mai dal perimetro sicuro di Snowflake. Secondo, ti fa risparmiare mesi di retraining per i developer. Il tuo team continua a scrivere i dataframe, le join e le aggregazioni che già conosce perfettamente. Semplicemente, li fa girare sul cloud anziché sul loro processore locale. Il vero potere di pandas su Snowflake è che disaccoppia il linguaggio che usi per descrivere le tue data transformation dall'engine che le esegue effettivamente. Se trovi utili questi deep dive tecnici, puoi supportare lo show cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 9 di 17. Il tuo codice ora è abbastanza intelligente da sapere esattamente quando usare la memoria del tuo laptop e quando avviare un cloud cluster. Questo è il concetto fondamentale alla base di pandas su Snowflake: l'esecuzione ibrida. Quando usi pandas standard, ogni operazione viene eseguita nella memoria della tua macchina locale. Se carichi un dataset enorme, il processo va in crash. L'API pandas di Snowpark risolve questo problema mappando i tuoi comandi pandas in SQL ed eseguendoli nel warehouse di Snowflake. Ma non tutte le funzioni pandas hanno un equivalente SQL diretto. Alcune operazioni, come il plotting o l'applicazione di specifiche funzioni Python custom, richiedono l'esecuzione della vera e propria libreria pandas locale. La sfida è passare in modo trasparente dal cloud engine al tuo ambiente locale senza trascinare gigabyte di raw data attraverso la rete. L'esecuzione ibrida gestisce questa transizione in modo dinamico. È un modello di esecuzione costruito interamente per ottimizzare al massimo i costi di trasferimento dati. Quando esegui uno script usando l'API pandas di Snowpark, l'engine agisce come un router intelligente. Il suo comportamento di default è quello di mantenere i dati nel cloud. Traduce il tuo codice in query SQL e le esegue usando il compute di Snowflake. Vediamo uno scenario pratico. Parti da una tabella che contiene dieci milioni di righe. Scrivi una riga di codice per filtrare i record non validi, e poi raggruppi i dati per calcolare una media. Fino a questo punto, l'engine traduce i tuoi comandi di filtro e aggregazione direttamente in SQL. Il warehouse di Snowflake fa il lavoro pesante. La tua macchina locale non scarica una singola riga di quell'enorme dataset. L'aggregazione riduce quei dieci milioni di righe a una tabella riassuntiva di esattamente sette righe. Come passaggio successivo, scrivi un comando per plottare quelle sette righe in un grafico. Il plotting è intrinsecamente un'operazione locale. Il database engine di Snowflake non può disegnare un grafico per te. Ecco il punto chiave. L'engine riconosce che il comando di plot richiede una transizione al backend pandas locale. Dato che l'engine elabora le tue operazioni in modo intelligente, guarda lo stato dei tuoi dati un attimo prima che venga richiesta l'operazione locale. Sa che l'aggregazione precedente produce solo sette righe. Quindi, invece di spostare i dieci milioni di righe originali sul tuo laptop per elaborare l'aggregazione localmente, lascia che Snowflake completi i calcoli nel cloud. Poi, avvia il download di quelle sole sette righe finali nella tua memoria locale. Una volta che i dati arrivano nel tuo ambiente locale, subentra pandas standard. La libreria locale esegue il comando di plot usando quelle sette righe. Qualsiasi operazione successiva che eseguirai su quella specifica struttura dati continuerà a girare localmente, perché i dati hanno già attraversato il confine di rete. Il sistema isola la manipolazione pesante dei dati all'interno dell'infrastruttura cloud. Rimanda il trasferimento di rete finché un'operazione non richiede strettamente l'esecuzione locale. Nel momento in cui si presenta questa necessità, i tuoi step di manipolazione dei dati hanno solitamente ridotto il dataset a una frazione della sua dimensione originale. Mantieni la sintassi API che già conosci, ma eviti completamente il collo di bottiglia della rete. La caratteristica distintiva dell'esecuzione ibrida non è solo che fa fallback sulla memoria locale, ma che riduce strategicamente il payload nel cloud prima di fare il salto. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 10 di 17. E se potessi fare una query su un database PostgreSQL direttamente dall'interno del tuo script Python in Snowflake? Normalmente, spostare i dati da un database operativo a Snowflake richiede un intermediario esterno. Configuri un tool di estrazione su un server separato, gestisci le credenziali, metti i file in stage e scheduli i job solo per preparare i dati per l'analisi. L'ingestion diretta dei dati esterni tramite Snowpark Python risolve il problema, eliminando completamente l'intermediario. Questo approccio ti permette di semplificare la tua architettura dati. Sfruttando l'external network access in Snowflake, il tuo codice Python può comunicare direttamente con altri sistemi. Puoi usare le librerie standard DB-API di Python o i driver JDBC per connetterti a database esterni, direttamente da una stored procedure o da una user-defined table function di Snowpark. Considera uno scenario concreto. Hai un database di inventario PostgreSQL legacy on-premise, e devi fare una join tra quei dati di inventario e le tue tabelle clienti live su Snowflake. Invece di configurare una complessa pipeline di ingestion, scrivi una stored procedure Python in Snowpark. All'interno di quella procedura, usi un connettore standard Postgres DB-API. Passi la tua connection string, che fa riferimento a credenziali gestite in modo sicuro da Snowflake. Apri la connessione, esegui una select statement SQL standard sul database PostgreSQL esterno e fai il fetch del result set. Una volta che i dati sono in memoria all'interno della tua funzione Python, fai semplicemente lo yield delle righe a Snowflake, oppure le converti direttamente in un DataFrame di Snowpark. Ora hai i tuoi dati di inventario esterni disponibili come oggetto nativo di Snowflake, pronti per una join con le tue tabelle clienti in una singola query. La logica fluisce dal sistema operativo esterno direttamente nel tuo ambiente analitico, in modo sicuro e senza server di staging intermedi. Questo copre gli input relazionali. E per le data source semi-strutturate, come i file nested caricati in uno stage? Snowpark fornisce anche dei tool specifici per fare il parsing di formati complessi. Un ottimo esempio è l'XML RowTag reader. Quando devi fare l'ingestion di un file XML difficile da gestire, non devi scrivere una logica di parsing custom per navigare l'intero document tree. Invece, specifichi un row tag. Questo è lo specifico elemento XML che rappresenta un singolo record. Chiami il metodo read sulla tua sessione Snowpark, imposti il formato su XML e fornisci il parametro row tag. Snowflake scansiona il documento, identifica ogni istanza di quel tag e la estrae come singola riga in un DataFrame. La complessa gerarchia sopra e sotto quel tag viene appiattita o impacchettata in colonne, a seconda del tuo schema. Trasforma un documento di testo nested in una tabella pulita e interrogabile in un solo passaggio. Ecco il punto chiave. Sia che tu stia aprendo una connessione JDBC verso un vecchio database on-premise, sia che tu stia puntando un row tag reader su un file XML nested, stai consolidando la tua logica di ingestion all'interno della data platform. Stai trasformando problemi di integrazione in semplici problemi di esecuzione del codice. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake & Snowpark Python, episodio 11 di 17. Come esegui una logica custom di parsing di stringhe in Python su miliardi di righe senza spostare i dati? La risposta sta nel creare delle UDF scalari, ovvero le User-Defined Functions. Le funzioni SQL standard coprono la maggior parte delle trasformazioni di dati quotidiane. Quando l'SQL standard fallisce, le UDF Python intervengono in modo trasparente. Se hai a che fare con regole molto custom, come scrivere una regular expression complessa per fare il parsing di indirizzi email sporchi, l'SQL puro diventa rapidamente illeggibile o impossibile. Le UDF scalari risolvono questo problema permettendoti di scrivere della normale logica Python e di eseguirla nativamente all'interno del compute engine di Snowflake. Una funzione scalare elabora semplicemente una riga di input e restituisce esattamente un valore di output. Per fare il deploy del tuo codice Python, usi Snowpark per registrare la funzione. Se ti serve la logica solo per il tuo script corrente, crei una UDF anonima. Il modo più semplice per farlo è usare il decorator at-UDF. Per prima cosa, scrivi una funzione Python standard. Chiamiamola extract email domain. Al suo interno, usi il modulo regex standard di Python per fare il parsing della stringa di testo e restituire il dominio corrispondente. Subito sopra la definizione della funzione, inserisci il decorator at-UDF. Quando il tuo script viene eseguito, Snowpark serializza automaticamente questa funzione Python, la invia al server e restituisce una reference a un oggetto UDF. A questo punto puoi passare questo oggetto alle operazioni sulle colonne del tuo DataFrame, applicando il tuo parser custom su tabelle enormi come se fosse una feature nativa del database. In alternativa, puoi saltare il decorator e passare esplicitamente la tua funzione Python nel metodo session dot udf dot register. Entrambi i metodi creano un oggetto temporaneo nel database engine. Nel momento in cui la tua sessione Snowpark si chiude, la UDF anonima viene droppata completamente. Ed è qui che la cosa si fa interessante. Se la tua nuova logica di parsing è utile, probabilmente vorrai condividerla con altri utenti o renderla disponibile alle pipeline SQL di downstream. Per farlo, crei una UDF permanente e con un nome. Usando lo stesso metodo register, aggiungi un flag is permanent impostato a true, e fornisci un valore string per il parametro name. Questo nome determina come la funzione verrà chiamata nel database. Quando rendi permanente una UDF, Snowflake ha bisogno di un posto fisico in cui persistere il tuo codice Python, in modo che rimanga disponibile molto tempo dopo la disconnessione della tua sessione. Per questo motivo, devi fornire anche un parametro stage location. Questo punta a uno stage interno di Snowflake già esistente. Snowpark farà l'upload e salverà in modo sicuro i file Python compilati direttamente in quello stage. Una volta terminata la registrazione, chiunque abbia i permessi corretti sul database potrà chiamare la tua logica Python custom direttamente da una query SQL standard. Quando crei una qualsiasi UDF, Snowpark in genere si affida ai type hints di Python per capire quali data types la funzione accetta e restituisce. Se la tua funzione si aspetta una string e restituisce una string, aggiungi quei type hints standard alla definizione Python, e Snowpark li mappa automaticamente ai data types equivalenti di Snowflake. Il vero potere della UDF scalare non è solo la possibilità di scrivere in Python, ma la capacità di eseguire quel Python all'interno della memoria distribuita del database engine, eliminando completamente la latenza di rete dovuta all'estrazione dei dati per l'elaborazione. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 12 di 17. Eseguire pacchetti Python di terze parti all'interno di un database una volta significava un vero e proprio dependency hell. Finivi per creare complessi container Docker solo per passare un array a una funzione matematica. Ora, basta esattamente una riga di codice. Questo episodio tratta il Dependency Management per le UDF. Quando scrivi una User-Defined Function, o UDF, la tua logica raramente opera nel vuoto. Hai bisogno di librerie. In un setup tradizionale, spostare il tuo codice Python dove risiedono i dati significa dover spostare anche l'intero environment. Devi preoccuparti dei pip install, delle dipendenze del compiler e di mantenere il server identico alla tua macchina locale. Snowflake evita automaticamente questo incubo grazie a un'integrazione nativa con il canale Anaconda. Il canale Anaconda di Snowflake ospita migliaia di pacchetti Python pre-buildati e pre-compilati, garantiti per funzionare all'interno dell'execution environment di Snowflake. Per utilizzarli, non devi installare nulla manualmente. Dichiari semplicemente ciò di cui la tua funzione ha bisogno. Quando definisci la tua UDF usando il decorator Python, aggiungi un parametro chiamato packages. Passi a questo parametro una lista di string, con i nomi delle librerie che ti servono. Prendiamo uno scenario concreto. Vuoi usare un modello di machine learning per fare scoring delle righe direttamente all'interno di una query Snowflake. La tua funzione di predizione si basa su scikit-learn e pandas. Subito sopra la tua funzione Python, aggiungi il decorator UDF e imposti la lista packages in modo che contenga le string scikit-learn e pandas. Non crei un container e non esegui un package manager. Quando chiami quella UDF, Snowflake fa il provisioning di un environment sicuro, scarica esattamente quei pacchetti dal canale Anaconda ed esegue il tuo codice. Se ti serve una release specifica, puoi pinnare la versione aggiungendo due segni di uguale e il numero di versione direttamente all'interno della string, proprio come in un normale file requirements di Python. Questo copre le librerie esterne. Ora, la seconda parte riguarda il tuo codice custom. Non tutto ciò che scrivi va su Anaconda. Spesso hai delle helper function o delle business rule custom scritte in un file Python separato. Snowflake gestisce questo codice first-party tramite la tua session attiva. Chiami un metodo chiamato add import sull'oggetto session. Passi il path del tuo file custom ad add import. Può trattarsi di un file Python locale sul tuo laptop, di un file già presente in uno stage di Snowflake, o di un archivio zip contenente una directory di moduli più profonda. Quando registri la tua UDF, Snowflake prende i file che hai specificato e ne fa l'upload. A runtime, Snowflake estrae questi file e li posiziona direttamente sul system path dell'environment isolato che esegue la tua UDF. All'interno del codice della tua funzione principale, usi semplicemente gli statement di import standard di Python per importare i tuoi moduli custom, esattamente come se si trovassero nella stessa cartella in locale. Puoi combinare liberamente questi due approcci. Dichiari i tuoi requirements esterni tramite il parametro packages e inietti i tuoi moduli interni usando add import. Snowflake costruisce l'execution context unendo in modo sicuro i binaries di Anaconda con i tuoi file custom nello stage prima che venga processata una singola riga di dati. Ecco il punto chiave. Gestendo le dipendenze in questo modo, Snowflake disaccoppia completamente il tuo codice funzionale dall'infrastruttura necessaria per eseguirlo, permettendoti di definire un execution environment sicuro e distribuito usando nient'altro che una lista di nomi e file path. Grazie per aver ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 13 di 17. Cosa fai quando la tua funzione Python deve restituire un'intera tabella di risultati anziché un singolo valore? Le User-Defined Function standard sono ottime, ma sono strettamente limitate a restituire un singolo valore scalare per ogni riga di input. Quando devi esplodere un singolo input in più output, crei una User-Defined Table Function, o UDTF. La differenza è fondamentale. Una funzione standard restituisce un singolo valore. Una UDTF restituisce una relazione. Questo significa che restituisce una struttura tabellare su cui puoi fare query, filtrare o fare join con altre tabelle, esattamente come se fosse una tabella fisica nel tuo database. Considera uno scenario concreto. Hai una tabella con una colonna che contiene log applicativi JSON custom e altamente annidati. Ogni riga contiene un'enorme entry di log, ma quella singola entry potrebbe contenere cinque, dieci o cinquanta eventi di sistema distinti, nascosti in profondità nel JSON. Devi normalizzare questi dati programmaticamente. Vuoi passare una stringa JSON e ottenere indietro una tabella strutturata in cui ogni singolo evento viene estratto nella propria riga. Per creare una UDTF in Snowpark Python, non scrivi una funzione standalone. Scrivi una classe Python. Questa classe fa da handler per la table function e orchestra la logica usando fino a tre metodi specifici. Il primo è il metodo di inizializzazione. Questo è opzionale. Snowflake lo esegue una volta per partizione prima di processare qualsiasi riga. Se il tuo log parser deve compilare una regular expression complessa o inizializzare un dizionario di stato custom, lo fai qui, così il costo di setup viene pagato una sola volta per ogni batch di dati. Il secondo è il metodo process. Questo è l'unico metodo obbligatorio nella classe. Snowflake lo chiama per ogni singola riga di input. Nel nostro scenario di logging, il metodo process riceve la stringa JSON, fa l'unpack dell'array di eventi e ci fa un loop. È qui che avviene la conversione. Invece di restituire un valore finale, il metodo process fa lo yield di tuple. Ogni tupla di cui fa lo yield diventa istantaneamente una nuova riga nella tua tabella di output. Se una stringa di log JSON contiene dodici eventi, il metodo process fa lo yield di dodici tuple separate, e Snowflake le trasforma in dodici righe di output distinte. Il terzo è il metodo end partition. Anche questo è opzionale. Snowflake lo triggera dopo che tutte le righe nella partizione corrente sono passate attraverso il metodo process. Tipicamente lo usi se stavi aggregando lo stato attraverso la partizione e devi fare lo yield di una riga di riepilogo finale, o semplicemente per pulire memoria e risorse. Quando registri questa classe handler in Snowpark, devi dichiarare esplicitamente il tuo schema di output. Dato che una UDTF restituisce una tabella, l'execution engine del database deve conoscere i nomi esatti delle colonne e i tipi di dato delle tuple di cui stai facendo lo yield, prima ancora che la query venga eseguita. Ecco il punto chiave. Le UDTF colmano il divario tra la complessa logica Python e le operazioni sui database relazionali, permettendoti di wrappare un unnesting di dati procedurale e disordinato all'interno di un'interfaccia a tabella pulita su cui il resto della tua applicazione può fare query nativamente. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 14 di 17. Smetti di pagare per un server di orchestrazione esterno solo per eseguire script Python che dicono a Snowflake cosa fare. Creare delle stored procedure porta quel control flow direttamente nella data platform. Spesso le persone confondono le stored procedure con le User-Defined Function, o UDF. Una UDF non è pensata per l'orchestrazione. Le UDF restituiscono valori all'interno di una query e trasformano i dati riga per riga. Le stored procedure sono completamente diverse. Eseguono interi script, lanciano query multiple e gestiscono il control flow procedurale. Le usi per orchestrare task, non per calcolare i valori delle colonne. Per creare una stored procedure in Snowpark Python, scrivi una funzione Python standard. Il requisito fondamentale è il primo argomento di quella funzione. Deve essere sempre un oggetto Session di Snowpark. Questa Session è il tuo collegamento attivo con il database. Quando la tua procedura gira, usa questa session per eseguire statement SQL, costruire DataFrame e leggere o scrivere dati. Per dire a Snowflake che questa funzione è una stored procedure, metti il decorator sproc direttamente sopra la definizione della tua funzione. Il decorator fa da layer di configurazione. Lo usi per specificare il return type della tua procedura e qualsiasi pacchetto Python di terze parti che serve al tuo codice per girare. Quando esegui il codice di registrazione, Snowpark prende la tua funzione Python, la impacchetta insieme alle sue dipendenze e la registra in Snowflake. Da quel momento in poi, la logica vive all'interno del database e viene eseguita sul compute di Snowflake. Pensa a una data pipeline notturna. Il tuo processo deve creare una tabella temporanea, caricarci i dati grezzi, lanciare una serie di trasformazioni multi-step e infine ripulire gli oggetti temporanei. Se lo fai girare da un server esterno, il tuo codice Python invia un comando sulla rete, aspetta che Snowflake finisca, riceve il risultato e invia il comando successivo. Scrivendo esattamente questa stessa logica Python come stored procedure, l'intero script viene eseguito all'interno di Snowflake. Usa l'oggetto session per eseguire le creazioni delle tabelle e le trasformazioni dei DataFrame in modo nativo. C'è zero latenza di rete tra la logica di orchestrazione e i dati che manipola. Anche se una stored procedure non restituisce un valore per riga come una UDF, restituisce comunque un singolo valore quando lo script finisce. Sei tu a definire questo return type quando imposti il decorator sproc. Spesso si tratta di una semplice string che conferma il successo, di un intero che rappresenta le righe totali elaborate, o persino di un risultato tabellare che mostra un log di esecuzione. Hai diverse scelte su come fare il deploy di questo codice. Puoi definire ed eseguire una procedura anonima dinamicamente in uno script Python se ti serve solo per una singola session. Per le pipeline automatizzate, la registri come oggetto permanente. Snowflake memorizza la definizione in modo che qualsiasi utente autorizzato, applicazione esterna o task pianificato possa chiamarla in seguito. Ecco il punto chiave. Scrivere una stored procedure in Snowpark Python significa che stai trattando Snowflake come un application runtime, non solo come uno storage layer. Stai spostando il cervello della tua orchestrazione proprio accanto ai dati che controlla. Se ti piace lo show e vuoi supportare il lavoro che facciamo, puoi trovarci cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 15 di 17. Spostare terabyte di dati sicuri su un server di machine learning esterno è lento, costoso e rischioso. Passi ore a trasferire i dati sulla rete, e il tuo team di sicurezza si innervosisce per dove vanno a finire. E se invece fosse il compute ad arrivare ai dati? Questa è l'idea alla base del training di modelli di machine learning all'interno di Snowflake. Sfruttando Snowpark Python, puoi fare il training di modelli di machine learning single-node direttamente all'interno del tuo data warehouse usando delle stored procedure. I dati non escono mai dal perimetro di Snowflake. Questo risolve il problema della data gravity. Invece di estrarre milioni di righe in un'istanza cloud separata, esegui il tuo script di training esattamente dove risiedono i dati. Il training di un modello di machine learning richiede il caricamento del dataset in memoria. Un virtual warehouse standard in Snowflake è ottimizzato per query SQL parallele, non per mantenere enormi dataset nella RAM di sistema. Se provi a far girare un algoritmo complesso su un warehouse standard, molto probabilmente otterrai degli errori di out-of-memory e il processo andrà in crash. Per gestire questa situazione, hai bisogno di un profilo di compute diverso. Snowflake offre dei warehouse Snowpark-optimized specificamente per questo scopo. Questi warehouse forniscono fino a sedici volte più memoria per nodo rispetto alle istanze standard. Vediamo uno scenario concreto. Devi fare il training di un modello random forest di scikit-learn su un enorme dataset di clienti. Inizi scrivendo una stored procedure Python. Quando registri questa procedura, specifichi i package Python necessari, come scikit-learn, pandas e joblib. Snowflake fa automaticamente il provisioning di queste dipendenze usando il suo canale Anaconda integrato. Assegni inoltre l'esecuzione della procedura sul tuo warehouse Snowpark-optimized. All'interno della procedura, usi l'oggetto session di Snowpark per definire la query sui tuoi dati di training. Chiami quindi il metodo per convertire quel dataframe Snowpark in un dataframe pandas standard. Questa azione porta i risultati della query direttamente nella memoria fisica del nodo del warehouse. Dato che hai fatto il provisioning del compute ottimizzato, c'è molta RAM per mantenere l'intero dataset in una volta sola. Successivamente, inizializzi il tuo modello random forest e invochi il metodo fit, passando il dataframe pandas. Il processore del warehouse gestisce il ciclo di training esattamente come farebbe su un server di machine learning dedicato. Una volta terminato il training del modello, hai un algoritmo addestrato che risiede nella memoria temporanea dell'ambiente di esecuzione. Devi renderlo persistente per le predizioni future prima che la stored procedure finisca. È qui che entra in gioco la serializzazione. Usi una libreria come joblib per impacchettare il modello. Prendi l'oggetto del modello addestrato in memoria e ne fai il dump in un file, creando un artefatto. Poi istruisci la stored procedure a scrivere quel file appena creato direttamente in uno stage interno di Snowflake. Uno stage funge da cartella di storage sicura legata al tuo account Snowflake. Ecco il punto chiave. La tua stored procedure funge da container sicuro che collega le tue tabelle raw alle librerie di machine learning standard di Python. Mantenendo la pipeline interamente all'interno di Snowflake, riduci a zero la latenza di rete, bypassi tutte le operazioni di data egress e mantieni rigidi controlli di accesso, il tutto scrivendo esattamente lo stesso codice Python di training che già conosci. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 16 di 17. Come elabori file non strutturati da svariati gigabyte all'interno di una user-defined function senza far esplodere i limiti di memoria? Se provi a mappare file di grandi dimensioni come dipendenze statiche, il sistema cerca di scaricare tutto in anticipo e il tuo codice va in crash. La soluzione a questo problema è il Dynamic File Access con SnowflakeFile. Per capire perché questo è importante, guarda come funziona normalmente l'accesso ai file in Snowpark. Di solito, usi il parametro imports per fare il bind di un file alla tua funzione. Questo approccio statico è ottimo per piccoli file di configurazione o per un modello di machine learning specializzato, perché il file viene scaricato nel compute warehouse prima che inizi l'esecuzione. Ma non funziona su larga scala. Se la tua pipeline deve elaborare centinaia di enormi file di log del server o PDF ad alta risoluzione archiviati in uno stage Snowflake, scaricarli tutti in modo statico è incredibilmente lento e ti garantisce un errore di out-of-memory. È qui che entra in gioco la classe SnowflakeFile. Situata nel modulo snowflake dot snowpark dot files, questa classe permette alla tua funzione o stored procedure di aprire i file direttamente da uno stage a runtime. Non fai il bind del file durante la creazione della funzione. Invece, la tua funzione accetta la location del file come un normale argomento string. Quando chiami la funzione nella tua query SQL o in un'operazione sul dataframe, passi quella location. All'interno del codice Python, chiami il metodo open sulla classe SnowflakeFile e gli passi la string della location del file. Specifichi anche la modalità di lettura, usando le convenzioni standard di Python come r per il testo o r b per leggere i byte. Ecco il punto chiave. Chiamare open non carica il file. Restituisce un oggetto file-like che fa lo streaming dei dati. Il file rimane nello stage e tu recuperi i dati attraverso una network pipe. Applichiamo questo concetto allo scenario di elaborazione dei log. Hai una tabella del database in cui ogni riga contiene una scoped URL che punta a un diverso file di log di grandi dimensioni su uno stage interno. Passi quella colonna URL alla tua funzione. All'interno della funzione, apri lo stream e scrivi un loop standard per leggere il file riga per riga. Man mano che il tuo codice valuta ogni riga per estrarre codici di errore o timestamp, Python scarta le righe precedenti dalla memoria. Puoi parsare un file di log da cinquanta gigabyte mentre la tua funzione tiene in memoria solo una singola riga di testo in ogni singolo millisecondo. Lo stesso identico concetto funziona per i file binari. Se stai estraendo testo da PDF di grandi dimensioni, apri il file in modalità binaria e passi lo stream risultante direttamente a una libreria Python di parsing PDF. La libreria legge il byte stream in sequenza senza richiedere che l'intero documento risieda nella memoria di sistema. SnowflakeFile gestisce automaticamente anche il security boundary. Quando passi una scoped URL generata dinamicamente alla tua funzione, Snowflake concede l'accesso in lettura a quello specifico file solo per la durata della query, facendolo scadere immediatamente al termine della query. Fare lo streaming di file specificati dinamicamente mantiene piatto il tuo memory footprint indipendentemente dalle dimensioni del file, permettendo al tuo compute warehouse di concentrarsi interamente sull'elaborazione dei dati invece di cercare semplicemente di mantenerli in memoria. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Snowflake e Snowpark Python, episodio 17 di 17. Non faresti mai il deploy del codice di un'applicazione backend senza unit test, quindi perché le data pipeline vengono spesso mandate in produzione incrociando le dita? Snowpark cambia tutto questo rendendo la tua data logic modulare, il che significa che finalmente puoi testarla come un normale software. Testare Snowpark Python è ciò che porta il rigore del software engineering al data engineering. Snowpark ti permette di estrarre la tua transformation logic da script monolitici e di inserirla in funzioni Python standalone. Dato che queste funzioni prendono un DataFrame in input e restituiscono un DataFrame in output, puoi testarle usando dei framework Python standard. PyTest è la scelta più comune. Per eseguire qualsiasi codice Snowpark, hai bisogno di una sessione attiva. Invece di incorporare i dettagli di autenticazione in ogni singolo test, definisci una session fixture. Lo fai in un file di configurazione dedicato chiamato conftest.py, che PyTest riconosce automaticamente. All'interno di questo file, scrivi una funzione di setup che stabilisce una connessione a Snowflake, restituisce l'oggetto session e chiude la sessione quando i test finiscono. Decori questa funzione come una fixture di PyTest. Ora, qualsiasi test nel tuo progetto può richiedere una sessione attiva semplicemente chiedendola per nome negli argomenti della funzione di test. Applichiamo questo a uno scenario concreto. Hai una custom transformation complessa di un DataFrame che filtra gli utenti inattivi, calcola un risk score e standardizza i nomi delle colonne. Devi validare questa logica prima di fare il deploy della pipeline in produzione. Inizi scrivendo un test. Il primo step all'interno di quel test è creare un DataFrame di input contenente alcune righe di mock data accuratamente selezionati. Definisci i nomi esatti delle colonne e i valori delle righe necessari per triggerare gli edge case specifici nella tua logica. Usi la tua session fixture per convertire questi raw mock data in un DataFrame Snowpark. Successivamente, passi questo mock DataFrame di input alla tua transformation function. La funzione applica la tua business logic e restituisce il DataFrame di output effettivo. Ora devi verificare che la logica abbia fatto quello che doveva fare. Crei un secondo mock DataFrame all'interno del tuo test, questa volta per rappresentare l'esatto risultato atteso. Questa è la parte che conta. Devi confrontare il DataFrame effettivo con il DataFrame atteso. Tuttavia, non puoi semplicemente usare un controllo di uguaglianza Python standard sugli oggetti DataFrame stessi, perché sono solo dei riferimenti a dei query plan. Devi invece confrontare i dati che contengono. Chiami il metodo collect sia sul DataFrame effettivo che su quello atteso per riportare i risultati in memoria come liste di oggetti riga. Dato che i database distribuiti non garantiscono l'ordine dei result set a meno che non venga esplicitamente richiesto, confrontare direttamente due liste di righe potrebbe fallire anche se i dati sono corretti. Per risolvere questo problema, ordini entrambe le liste di righe prima di fare un assert che siano uguali. Se i dati effettivi ordinati corrispondono ai dati attesi ordinati, il tuo test passa. Passando dei dataset piccoli e controllati attraverso delle transformation function isolate, catturi gli errori logici in locale prima che tocchino mai una tabella di produzione. Questo isola i componenti della tua pipeline e rende il tuo workflow di data engineering affidabile quanto il software development tradizionale. Questo segna la fine della nostra serie su Snowpark Python. Ti incoraggio a esplorare la documentazione ufficiale di Snowflake, a provare a scrivere questi test hands-on, o a visitare devstories.eu per suggerire argomenti per le nostre serie future. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta moltissimo. Buona giornata!