Snowflake & Snowpark Python

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 1 din 17. Cel mai mare bottleneck în big data este rareori stocarea. Adevărata problemă apare atunci când trebuie să muți dataset-uri masive prin rețea doar pentru a ajunge la layer-ul de compute. Arhitectura Snowflake ocolește complet această problemă. Lumea presupune adesea că Snowflake este doar o bază de date relațională on-premise, migrată prin lift-and-shift în cloud, sau un cluster Hadoop tradițional de care trebuie să ai grijă. Nu este niciuna dintre ele. Snowflake este un serviciu complet self-managed, construit nativ pentru cloud. Nu instalezi software. Nu configurezi hardware. Toată mentenanța, managementul și tuning-ul sunt gestionate pentru tine în fundal. Pentru a înțelege cum reușește asta, uită-te la arhitectura sa hibridă. Snowflake combină un setup shared-disk cu un setup shared-nothing. Într-un design tradițional shared-disk, toate nodurile de compute accesează un repository central de date. Într-un design shared-nothing, fiecare nod de compute are propriul său chunk local de date de procesat. Snowflake ia ce e mai bun din ambele. Păstrează un singur repository central de storage accesibil tuturor nodurilor de compute, dar folosește clustere independente de massively parallel processing pentru a rula query-urile efective pe acele date. Acest model hibrid se împarte în trei layere distincte. Primul este layer-ul de Database Storage. Când încarci date în Snowflake, nu aruncă pur și simplu fișierele raw într-un cloud bucket. Reorganizează acele date într-un format intern, optimizat, comprimat și columnar. Snowflake gestionează toate aspectele modului în care sunt stocate aceste date. Nu poți accesa direct storage-ul raw, interacționezi cu el doar prin query-uri SQL. Al doilea layer este Query Processing. Aici se întâmplă toată munca, folosind ceea ce Snowflake numește Virtual Warehouses. Un virtual warehouse este pur și simplu un cluster de compute independent. Deoarece partea de compute este strict separată de layer-ul central de storage, mai multe virtual warehouses pot rula query-uri pe exact aceleași date simultan. Nu concurează pentru resurse și nu se blochează reciproc. Iată ideea cheie. Îți poți scala puterea de compute instantaneu fără a muta un singur byte de date. Gândește-te la un raport financiar de sfârșit de lună care necesită o agregare masivă de date. În mod normal, ar trebui să migrezi tabelele pe un server mai mare pentru a face față unui workload complex. În Snowflake, pur și simplu dai spin up la un virtual warehouse mai mare, rulezi raportul greu în câteva minute și oprești warehouse-ul când termini. Tabelele de la bază nu se mișcă niciodată. Al treilea layer care leagă totul împreună este Cloud Services. Acesta este creierul platformei. Este o colecție de servicii care coordonează totul în întregul sistem. Gestionează autentificarea utilizatorilor, administrează infrastructura, face parse la query-urile primite și optimizează execution paths. De asemenea, gestionează metadata, urmărind exact unde se află anumite bucăți de date în layer-ul de storage, astfel încât query-urile să poată rula eficient fără a scana totul. Cel mai important takeaway este că, în Snowflake, scalarea performanței este doar un toggle switch pe clusterul de compute, în timp ce tabelele masive de date rămân complet staționare. Dacă îți place seria și vrei să susții show-ul, ne poți găsi căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mersi că asculți și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 2 din 17. Ce-ar fi dacă ai putea scrie Python pur, dar să-l execuți ca SQL distribuit hiper-optimizat? Aceasta este exact schimbarea de paradigmă pe care o abordăm astăzi, printr-o introducere în Snowpark. În mod tradițional, lucrul cu dataset-uri mari în Python însemna să tragi datele din baza ta de date. Scrii un query, tragi datele prin rețea în memoria locală sau într-un cluster de procesare extern, rulezi transformările și apoi împingi rezultatele înapoi. Această abordare creează bottleneck-uri în rețea, crește costurile de infrastructură și introduce riscuri de securitate prin mutarea datelor dintr-un mediu guvernat. Snowpark dă peste cap acest model. În loc să mute datele către compute, Snowpark împinge compute-ul direct la date. O concepție greșită des întâlnită este că Snowpark ar fi un engine de procesare extern. Lumea presupune adesea că trebuie să ridice și să gestioneze un compute cluster separat doar pentru a rula cod Python. Nu este așa. Calculele Snowpark rulează direct în Snowflake. Folosești exact aceleași virtual warehouses care îți execută query-urile SQL standard. Nu ai nicio infrastructură nouă de provizionat sau de întreținut. Când scrii cod folosind API-ul Snowpark Python, interacționezi cu un obiect DataFrame. Asta se simte foarte similar cu lucrul cu tool-urile de date familiare din Python. Faci chain la operațiuni, definind cum să selectezi, să filtrezi, să grupezi sau să agreghezi datele. Totuși, library-ul Snowpark nu execută aceste operațiuni local. În schimb, îți traduce nativ operațiunile pe DataFrame-ul Python în constructuri SQL complexe. Snowflake procesează apoi aceste statement-uri SQL folosind engine-ul său standard de execuție. Aici este ideea cheie. Snowpark folosește lazy evaluation. Când îți definești DataFrame-ul și aplici diverse transformări, nicio dată nu se mută și nu se modifică de fapt. API-ul Snowpark construiește pur și simplu un plan logic. Îți înregistrează intenția pas cu pas. Execuția reală se declanșează doar atunci când apelezi o acțiune specifică, cum ar fi să ceri sistemului să returneze rezultatele finale sau să le scrie într-un tabel nou. Acest model de lazy evaluation, combinat cu traducerea nativă în SQL, reduce drastic transferul de date. Ia în considerare un scenariu în care ești un data engineer care are sarcina de a filtra un miliard de rânduri de date tranzacționale pentru a izola câteva anomalii specifice. Îți scrii logica de filtrare într-un script Python local. Pentru că execuția este amânată până când acțiunea este apelată, API-ul are timp să optimizeze întregul chain de operațiuni și să-l traducă într-un singur query SQL extrem de eficient. Filtrarea propriu-zisă are loc în întregime în Snowflake. Baza de date face tot greul. Singurele date care circulă prin rețea către mașina ta locală sunt subsetul final, mic, de anomalii. Tocmai ai procesat un miliard de rânduri folosind sintaxa Python fără să tragi nicio înregistrare brută în memoria ta locală. Adevăratul avantaj aici este păstrarea developer experience-ului nativ în Python, profitând în același timp de engine-ul bazei de date pentru ceea ce face cel mai bine. Tu scrii Python, dar Snowflake execută SQL. Asta e tot pentru acest episod. Mersi că m-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 3 din 17. Boilerplate-ul de conexiune este adesea un coșmar de securitate, plin de parole hardcoded și environment variables împrăștiate. Vrei să oferi echipei tale un command line tool local, dar sub nicio formă nu poți să pui credentials direct în cod. Soluția este stabilirea unei sesiuni într-un mod curat, folosind funcțiile native de configurare din Snowpark. Fiecare script Snowpark începe prin crearea unui obiect Session. Aceasta este legătura ta activă către mediul Snowflake. Încapsulează autentificarea, target warehouse-ul și contextul tău. Pentru a-l construi, folosești obiectul builder disponibil pe clasa Session. Cea mai directă abordare este să pasezi un dicționar. Creezi un dicționar Python cu chei pentru account, user, password, role, database și warehouse. Pasezi acel dicționar în metoda configs a session builder-ului, apoi apelezi metoda create. Logica merge direct din dicționarul tău în backend-ul Snowflake. Dar să faci hardcoding la credentials într-un script Python este un risc masiv de securitate, ceea ce face această abordare nepotrivită pentru tool-uri shared. Pentru a elimina acele credentials din cod, Snowpark se bazează pe un fișier de configurare standard numit connections.toml. Pui acest fișier fie în project root, fie într-un director ascuns snowflake din user home folder-ul tău. Fișierul TOML conține blocuri de conexiune. Poți defini un bloc default, un bloc dev și un bloc prod, fiecare cu propriii parametri de conexiune. Iată ideea cheie. Când folosești un fișier TOML, codul tău Python se simplifică dramatic. Nu mai pasezi deloc un dicționar. Pur și simplu apelezi metoda get sau create pe session builder. Snowpark scanează automat directoarele standard, găsește fișierul TOML, citește blocul default și instanțiază sesiunea. Dacă vrei un anumit environment, pasezi numele conexiunii către metoda configs înainte de a crea sesiunea. Codul rămâne curat, iar acele credentials rămân în siguranță pe mașina locală. Putem securiza și mai mult command line tool-ul nostru. Chiar și cu un fișier TOML, s-ar putea să nu vrei ca developerii să stocheze parole permanente local. Poți elimina complet parolele folosind single sign-on bazat pe browser. În fișierul TOML, omiți cheia password. În schimb, adaugi o cheie numită authenticator și îi setezi valoarea la externalbrowser. Când scriptul ajunge la pasul de creare a sesiunii, execuția se pune pe pauză. Snowpark interceptează procesul și deschide automat browserul web default al utilizatorului. Acesta redirecționează developerul către identity provider-ul organizației tale. Developerul se loghează normal, îndeplinind orice cerințe de multi-factor authentication. Odată ce identity provider-ul aprobă login-ul, trimite un authentication token temporar înapoi către un port local pe care ascultă Snowpark. Scriptul primește token-ul, stabilește sesiunea securizată de Snowflake, iar execuția Python se reia. Tool-ul tău CLI are acum acces complet autentificat la Snowflake, fără ca vreo parolă să atingă vreodată fișierele de configurare sau source code-ul. Cel mai sigur credential este cel care nu îți atinge niciodată codul, iar delegarea autentificării către browser îți menține scripturile locale în siguranță și concentrate în întregime pe date. Aș vrea să îți mulțumesc pentru că ne asculți — ne ajută foarte mult. Să ai o zi super!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 4 din 17. Vrei să testezi o transformare rapidă de date, dar environment-ul tău local de Python este din nou stricat. Connection string-urile tale sunt învechite și tocmai ai pierdut douăzeci de minute încercând să te autentifici. Cum ar fi dacă ai putea scrie cod pe un environment complet configurat, direct în browser, cu zero setup? Asta este exact problema pe care o rezolvă Python Worksheets în Snowsight. Python Worksheets sunt un code editor nativ, integrat direct în interfața web Snowflake. Ele elimină bătaia de cap a configurării unui environment local. Gândește-te cum e să faci prototipul unui script rapid de data cleaning pe date live. În loc să deschizi un IDE și să gestionezi credențiale, deschizi un tab în browser și începi să scrii cod imediat. Logica de execuție se bazează pe un entry point desemnat. Nu scrii pur și simplu un script procedural. Snowflake are nevoie de o funcție specifică pentru a face trigger la codul tău. By default, aceasta este o funcție de tip handler numită main. Această funcție primește un singur argument, care este obiectul de tip session activ. Pentru că ești deja logat în interfața Snowflake, sistemul gestionează automat autentificarea și pasează un session live direct în funcția ta main. Folosești acest session pentru a citi tabele, a executa query-uri și a manipula date folosind metode standard Snowpark. Iată detaliul cheie legat de dependențe. Poate te aștepți să deschizi un terminal și să folosești pip pentru a-ți instala librăriile, dar nu așa funcționează worksheet-urile. Nu folosești pip deloc. Snowflake se integrează nativ cu repository-ul Anaconda. În interfața worksheet-ului, există un dropdown menu dedicat pentru pachete. Pur și simplu cauți librăria de care ai nevoie, cum ar fi pandas sau scikit-learn, selectezi versiunea, iar Snowflake o provizionează instant pentru environment-ul tău de execuție. Asta acoperă partea de input-uri și setup. Dar cum rămâne cu output-urile? Funcția ta de handler trebuie să returneze o valoare, iar tu configurezi modul în care Snowflake interpretează această valoare folosind setările worksheet-ului. În principal, alegi între două tipuri de return, Table sau String. Dacă setezi return type-ul pe Table, funcția ta main trebuie să returneze un Snowpark DataFrame. Snowflake preia acel DataFrame și îl randează ca un grid curat și interactiv în panoul de rezultate. Asta este perfect pentru a inspecta output-ul scriptului tău de data cleaning. Dacă setezi return type-ul pe String, funcția ta trebuie să returneze o valoare text scalară. Folosești asta atunci când vrei să returnezi un status message, un agregat numeric făcut cast la text, sau un JSON payload. Trebuie să-ți aliniezi codul cu setările worksheet-ului. Dacă configurezi worksheet-ul să aștepte un Table, dar funcția ta returnează un String, execuția va eșua. Adevărata putere a Python Worksheets nu este să construiești aplicații masive, multi-file. Este abilitatea de a valida logica de transformare pe date la scară de producție în câteva secunde, în siguranță, fără să configurezi vreodată o mașină locală. Mersi că ai stat pe aici. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 5 din 17. Dacă instanțiezi un DataFrame care reprezintă un miliard de rânduri, câtă memorie folosește pe laptop? Aproape zero. Motivul ține de mecanica de bază a construirii de DataFrame-uri Snowpark. Un DataFrame Snowpark nu este un container care conține informațiile tale. Este pur și simplu o referință logică la datele care se află în Snowflake. Când definești un DataFrame în codul tău Python, construiești un query plan. Asta se bazează pe un concept numit lazy evaluation. Prin lazy evaluation, Snowpark amână execuția SQL-ului din spate până când declanșezi explicit o acțiune care necesită un rezultat final. Până la acel trigger, fiecare DataFrame pe care îl construiești este doar un set lightweight de instrucțiuni. Principala modalitate de a începe să construiești aceste instrucțiuni este metoda session dot table. Pasezi numele unui tabel sau view Snowflake existent ca string. Poți da doar numele tabelului, sau un nume fully qualified, care include baza de date și schema. O greșeală frecventă pe care o fac utilizatorii noi este să presupună că apelarea session dot table descarcă conținutul tabelului în mediul lor local de Python, similar cu modul în care funcționează Pandas. Nu se întâmplă asta. Dacă îndrepți session dot table către un transaction log de zece terabytes, funcția Python returnează în milisecunde. Nu circulă date prin rețea. Obiectul DataFrame doar înregistrează acel tabel specific ca root node al execution plan-ului tău. O altă abordare este metoda session dot sql. O folosești atunci când vrei să definești un DataFrame folosind un string SQL raw. Asta este util în special dacă ai un query existent pe care vrei să-l portezi, sau dacă preferi să exprimi o extracție inițială specifică în SQL. La fel ca metoda table, pasarea unui query în session dot sql nu trimite query-ul către Snowflake pentru execuție imediată. Creează un DataFrame care reprezintă output-ul acelui query specific. Te poți gândi la asta ca la definirea unui inline view. Al treilea mecanism este metoda session dot create dataframe. Asta funcționează diferit, deoarece pornește de la date care se află deja pe mașina ta locală. Poți pasa o listă Python, un dicționar sau un DataFrame Pandas în această metodă. Când este executată, Snowpark ia acele date locale, le urcă în Snowflake și le plasează într-un tabel temporar. Metoda returnează apoi un DataFrame Snowpark care pointează către acel nou tabel temporar. Iată ideea cheie. Pentru că session dot create dataframe mută fizic datele de pe mașina ta în Snowflake, performanța sa depinde în întregime de dimensiunea dataset-ului tău local și de conexiunea la rețea. Folosești asta pentru a face push la lookup tables mici sau parametri de configurare în Snowflake, astfel încât să poată interacționa cu dataset-urile tale mai mari. Poți lăsa Snowpark să deducă numele coloanelor și tipurile de date din obiectele tale locale, sau poți defini explicit o schemă folosind un obiect Snowpark StructType pentru a asigura precizia. De fiecare dată când construiești un DataFrame Snowpark, indiferent de metodă, definești o relație cu datele, în loc să recuperezi datele în sine. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 6 din 17. Scrii zece operații complexe pe DataFrame-uri la rând, dar sistemul nu rulează zece query-uri separate. În schimb, amână execuția și construiește un singur statement SQL perfect optimizat în spate. Astăzi, vorbim despre transformarea DataFrame-urilor. Când transformi un DataFrame, pregătești o rețetă pentru cum să-ți modelezi datele. Pentru a construi această rețetă, ai nevoie de o metodă sigură de a face referință la coloanele de date din spate. Faci asta folosind o funcție numită col. Pasezi numele unei coloane ca string în această funcție, iar ea returnează un obiect de tip coloană. Apoi folosești acest obiect în alte metode pentru a construi expresii, cum ar fi să verifici dacă valoarea unei coloane este egală cu un anumit număr sau string de text. Hai să ne uităm la un scenariu concret. Ai două DataFrame-uri. Unul conține profiluri de clienți, iar celălalt conține înregistrări ale tranzacțiilor. Vrei să identifici utilizatorii valoroși și să-i conectezi cu achizițiile lor recente. Dacă ai scrie asta în raw SQL, s-ar putea să te alegi cu un query mare și nested, care te obligă să citești logica din interior spre exterior. Cu DataFrame-uri, folosești method chaining pentru a scrie logica de sus în jos. Mai întâi, iei DataFrame-ul cu clienți și apelezi metoda filter. În interiorul acelui filter, folosești funcția col pentru a indica spre coloana nivelului de cheltuieli și specifici că trebuie să fie egală cu nivelul tău superior. Imediat după acel filter, înlănțuiești o metodă select. Folosești din nou funcția col pentru a declara că vrei să păstrezi doar ID-ul clientului și adresa de e-mail. Fiecare transformare returnează un nou DataFrame, permițându-ți să atașezi următoarea instrucțiune direct la finalul celei anterioare. Acum, a doua parte a procesului este să aduci datele tranzacțiilor. Apelezi metoda join pe DataFrame-ul tău filtrat cu clienți. Pasezi DataFrame-ul cu tranzacții ca prim argument. Apoi, specifici condiția pentru join, cum ar fi potrivirea coloanei cu ID-ul clientului din ambele dataset-uri. De asemenea, poți defini tipul de join, cum ar fi un inner join sau left join. Logica se citește secvențial. Faci filter, faci select și faci join. Iată ideea cheie. Pe măsură ce Python citește acest chain de metode, Snowpark nu atinge datele propriu-zise. Transformările sunt evaluate lazy. DataFrame-ul acționează pur și simplu ca un blueprint. Înregistrează fiecare filter, select și join pe care le soliciți, dar nu le execută pas cu pas. Această execuție amânată permite framework-ului să analizeze întreaga ta secvență de operațiuni și să o optimizeze înainte ca ceva să ruleze efectiv. Execuția se declanșează doar atunci când soliciți în sfârșit un rezultat concret. Asta necesită apelarea unei metode de tip acțiune. Dacă vrei să printezi un mic sample de date în terminalul tău, apelezi metoda show. Dacă vrei să descarci rezultatele complet procesate înapoi în memoria ta locală de Python, apelezi metoda collect. În momentul în care apelezi collect, Snowpark traduce blueprint-ul tău într-un singur query SQL eficient și îl trimite către Snowflake. Ai avantajul de a scrie cod Python pas cu pas, ușor de citit, în timp ce motorul bazei de date procesează datele într-o singură trecere extrem de optimizată. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 7 din 17. Construiești un data pipeline și dintr-o dată ai nevoie de o manipulare complexă de string-uri sau de o conversie matematică obscură. Nu trebuie să scrii acea logică de la zero în Python. Baza de date știe deja cum să o facă. Aici intervine apelarea funcțiilor de sistem. Snowflake are sute de funcții de sistem built-in, scrise în C++ extrem de optimizat. Acestea gestionează totul, de la parsing de text până la calcularea deviațiilor standard. Snowpark îți permite să apelezi aceste funcții SQL native direct din codul tău Python. Ai parte de structura familiară din Python, dar procesarea grea are loc în întregime în interiorul Snowflake. Datele propriu-zise nu părăsesc niciodată serverul pentru a fi procesate în mediul tău local de Python. Pentru a le accesa, imporți modulul snowflake dot snowpark dot functions. Acest modul conține wrappere directe de Python pentru majoritatea operațiunilor SQL standard. Dacă ai nevoie să convertești textul în majuscule, trebuie doar să apelezi funcția upper din acest modul și să îi pasezi obiectul column. În culise, Snowpark traduce codul tău Python în sintaxa SQL echivalentă și îl trimite către baza de date pentru execuție. Asta acoperă majoritatea use case-urilor. Dar ce se întâmplă când Snowflake lansează o nouă funcție SQL, sau ai nevoie să folosești o funcție de sistem specializată care nu are încă un wrapper explicit de Python în modul? Nu trebuie să aștepți următorul release al librăriei Snowpark pentru a o folosi. Asta e partea care contează. Poți folosi o metodă dedicată numită call_function pentru a invoca orice funcție de sistem Snowflake prin numele ei exact din SQL. Ia în considerare un scenariu în care ai un tabel cu milioane de rânduri care conțin măsurători ale unghiurilor în grade, iar modelul tău downstream de machine learning le cere în radiani. În loc să scrii o transformare matematică custom în Python care trage toate acele rânduri în memorie, lași motorul bazei de date să facă treaba. Imporți call_function. Apoi, o invoci pasând string-ul radians ca prim argument. Al doilea argument este obiectul column pe care vrei să-l transformi. Snowpark îi face instant push down ca o operațiune SQL nativă radians pe întregul tău dataset. Se execută cu viteza codului C++ compilat și îți ia exact o linie de Python să o scrii. Metoda call_function este flexibilă. Dacă funcția SQL din spate necesită mai multe input-uri, pur și simplu le pasezi în secvență după numele funcției. Aceste input-uri pot fi alte obiecte column, sau pot fi valori literale, cum ar fi un anumit string sau număr. Snowpark mapează argumentele tale din Python direct la parametrii SQL așteptați. Acest design îți menține codul curat, maximizând în același timp performanța. Nu pierzi accesul la puterea brută a funcțiilor SQL native din Snowflake doar pentru că scrii într-un limbaj diferit. Folosind funcțiile de sistem, tratezi Python ca pe un orchestrator, lăsând motorul bazei de date să facă exact ceea ce a fost construit să facă. Mersi că ne-ai ascultat. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 8 din 17. Scalarea unui pipeline pandas existent însemna în mod tradițional să îți arunci codul și să rescrii totul într-un framework distribuit precum Spark. Cum ar fi dacă ai putea gestiona un dataset de o sută de ori mai mare doar modificând un singur import? Aceasta este premisa pandas pe Snowflake. pandas este standardul universal pentru manipularea datelor în Python. Este expresiv, ușor de citit și profund înrădăcinat în modul în care lucrează data engineers și data scientists. Problema este că pandas este fundamental constrâns de execuția single-node. Necesită ca toate datele tale să încapă în memoria locală. Când datasetul tău depășește capacitatea laptopului sau a instanței de cloud, pandas standard cedează. pandas pe Snowflake reprezintă o schimbare completă de paradigmă pentru aceste pipeline-uri legacy. Acționează ca un tool de migrare zero-friction. Să presupunem că ai un script Python existent care curăță și face agregări pe logurile zilnice de tranzacții. Funcționează perfect pe zece gigabytes de date, dar dintr-o dată ți se cere să procesezi un terabyte. Ca să scalezi asta, nu trebuie să îți rescrii logica în SQL. Nici măcar nu trebuie să înveți sintaxa specifică a API-ului standard Snowpark DataFrame. Modifici o singură linie în partea de sus a fișierului tău. Elimini importul standard import pandas as pd. Îl înlocuiești cu import snowflake.snowpark.modin.pandas as pd. Aici devine interesant. O confuzie frecventă este legată de modul în care procesează datele de fapt. Mulți developeri presupun că este vorba doar de pandas standard care operează pe o conexiune live, trăgând milioane de rânduri pe mașina lor locală pentru a le procesa. Asta este incorect. Când folosești acest import specific Modin, nu se descarcă date pe mașina ta. În schimb, această librărie interceptează fiecare comandă pandas pe care o scrii în scriptul tău. Când faci chain la un filter, un group-by și o agregare de tip mean, engine-ul din spate traduce exact acea secvență într-un query SQL Snowflake optimizat. Îți transpilează sintaxa pandas în SQL, iar apoi trimite acel SQL către compute engine-ul Snowflake. Operațiunea se execută în întregime în interiorul warehouse-ului tău Snowflake. Mașina ta locală este responsabilă doar de orchestrarea comenzilor. Greul este distribuit pe clusterele Snowflake. Asta îți oferă exact acel developer experience din pandas, dar susținut de o bază de date masiv paralelă. Această schimbare rezolvă simultan două bătăi de cap organizaționale majore. În primul rând, elimină problema de data egress. Pentru că operațiunilor li se face push down în baza de date, datele tale raw nu părăsesc niciodată perimetrul securizat Snowflake. În al doilea rând, salvează luni întregi de recalificare a developerilor. Echipa ta continuă să scrie dataframe-urile, join-urile și agregările familiare pe care le știe deja perfect. Doar că le rulează în cloud în loc de procesorul lor local. Adevărata putere a pandas pe Snowflake este că decuplează limbajul pe care îl folosești pentru a descrie transformările de date de engine-ul care le execută efectiv. Dacă ți se par utile aceste deep dive-uri tehnice, poți susține emisiunea căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mersi că m-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 9 din 17. Codul tău este acum suficient de inteligent ca să știe exact când să folosească memoria laptopului și când să pornească un cluster în cloud. Acesta este conceptul de bază din spatele pandas pe Snowflake: execuția hibridă. Când folosești pandas standard, fiecare operațiune rulează în memoria mașinii tale locale. Dacă încarci un dataset masiv, procesul tău dă crash. API-ul Snowpark pandas rezolvă asta mapând comenzile tale pandas la SQL și executându-le în warehouse-ul Snowflake. Dar nu orice funcție pandas are un echivalent SQL direct. Anumite operațiuni, cum ar fi plotting-ul sau aplicarea unor funcții Python custom, necesită librăria pandas locală pentru a se executa. Provocarea este să treci fluid între engine-ul din cloud și environment-ul tău local, fără să tragi gigabytes de raw data prin rețea. Execuția hibridă gestionează dinamic această tranziție. Este un model de execuție construit în întregime în jurul optimizării pentru cel mai mic cost posibil de transfer de date. Când rulezi un script folosind API-ul Snowpark pandas, engine-ul acționează ca un router inteligent. Comportamentul lui default este să păstreze datele în cloud. Îți traduce codul în query-uri SQL și le execută folosind Snowflake compute. Hai să trecem printr-un scenariu practic. Începi cu un tabel care conține zece milioane de rânduri. Scrii o linie de cod ca să filtrezi înregistrările invalide, iar apoi grupezi datele ca să calculezi o medie. Până în acest punct, engine-ul îți traduce comenzile de filtrare și agregare direct în SQL. Warehouse-ul Snowflake face munca grea. Mașina ta locală nu descarcă nici măcar un rând din acel dataset masiv. Agregarea reduce acele zece milioane de rânduri la un tabel de sumar de exact șapte rânduri. Pentru următorul pas, scrii o comandă de plot pentru a pune acele șapte rânduri într-un grafic. Plotting-ul este în mod inerent o operațiune locală. Engine-ul bazei de date Snowflake nu poate desena un grafic pentru tine. Aici e ideea cheie. Engine-ul recunoaște că acea comandă de plot necesită o tranziție către backend-ul local pandas. Pentru că engine-ul îți procesează operațiunile în mod inteligent, se uită la starea datelor tale fix înainte ca operațiunea locală să fie cerută. Știe că agregarea precedentă are ca rezultat doar șapte rânduri. Așa că, în loc să mute cele zece milioane de rânduri originale pe laptopul tău ca să proceseze agregarea local, lasă Snowflake să termine calculele în cloud. Apoi, declanșează un download doar pentru acele ultime șapte rânduri în memoria ta locală. Odată ce datele ajung în environment-ul tău local, pandas standard preia controlul. Librăria locală execută comanda de plot folosind acele șapte rânduri. Orice operațiuni ulterioare pe care le faci pe acea structură de date specifică vor continua să ruleze local, pentru că datele au trecut deja granița rețelei. Sistemul izolează manipularea grea a datelor în interiorul infrastructurii de cloud. Amână transferul prin rețea până când o operațiune cere strict execuție locală. Până în momentul în care apare acea cerere, pașii tăi de manipulare a datelor au redus de obicei dataset-ul la o fracțiune din dimensiunea lui originală. Păstrezi sintaxa de API pe care o știi deja, dar eviți complet bottleneck-ul de rețea. Caracteristica definitorie a execuției hibride nu este doar că face fallback la memoria locală, ci că micșorează strategic payload-ul în cloud înainte să facă saltul. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 10 din 17. Ce-ar fi dacă ai putea face un query pe o bază de date PostgreSQL din interiorul scriptului tău Snowflake Python? În mod normal, mutarea datelor dintr-o bază de date operațională în Snowflake necesită un intermediar extern. Configurezi un tool de extracție pe un server separat, gestionezi credentials, faci stage la fișiere și dai schedule la joburi doar ca să-ți pregătești datele pentru analiză. Ingestia datelor externe direct prin Snowpark Python rezolvă asta prin eliminarea completă a intermediarului. Abordarea asta îți permite să-ți simplifici arhitectura de date. Folosind external network access în Snowflake, codul tău Python poate accesa direct alte sisteme. Poți folosi librării standard Python DB-API sau drivere JDBC ca să te conectezi la baze de date externe, direct dintr-un stored procedure Snowpark sau dintr-un user-defined table function. Să luăm un scenariu concret. Ai o bază de date de inventar legacy on-premise PostgreSQL și trebuie să faci join între datele de inventar și tabelele tale live cu clienți din Snowflake. În loc să configurezi un pipeline complex de ingestie, scrii un stored procedure în Snowpark Python. În interiorul acelui procedure, folosești un conector standard Postgres DB-API. Pasezi acel connection string, care face referință la credentials gestionate în siguranță de Snowflake. Deschizi conexiunea, execuți un statement SQL select standard pe baza de date externă PostgreSQL și faci fetch la result set. Odată ce datele sunt în memorie în funcția ta Python, pur și simplu dai yield la rânduri înapoi către Snowflake, sau le convertești direct într-un DataFrame Snowpark. Acum ai datele externe de inventar disponibile ca un obiect nativ Snowflake, gata pentru join cu tabelele tale de clienți într-un singur query. Logica merge din sistemul operațional extern direct în mediul tău analitic, în siguranță și fără servere intermediare de staging. Asta acoperă inputurile relaționale. Dar sursele de date semi-structurate, cum ar fi fișierele nested puse într-un stage? Snowpark oferă, de asemenea, tool-uri specifice pentru parsing de formate complexe. Un exemplu excelent este XML RowTag reader. Când trebuie să faci ingest la un fișier XML imens, nu trebuie să scrii logică de parsing custom ca să navighezi prin tot document tree-ul. În schimb, specifici un row tag. Acesta este elementul XML specific care reprezintă un singur record. Apelezi metoda read pe sesiunea ta Snowpark, setezi formatul pe XML și oferi parametrul row tag. Snowflake scanează documentul, identifică fiecare instanță a acelui tag și o extrage ca un rând individual într-un DataFrame. Ierarhia complexă de deasupra și de sub acel tag este flattened sau împachetată în coloane, în funcție de schema ta. Transformă un document text nested într-un tabel curat, pe care poți face query, într-un singur pas. Iată ideea principală. Indiferent dacă deschizi o conexiune JDBC la o bază de date on-premise veche sau folosești un row tag reader pe un fișier XML nested, îți consolidezi logica de ingestie în interiorul platformei de date. Transformi problemele de integrare în simple probleme de execuție a codului. Mersi că ne-ai ascultat. Până data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 11 din 17. Cum rulezi o logică custom de string parsing în Python pe miliarde de rânduri fără să muți datele? Răspunsul stă în crearea de UDF-uri scalare, sau User-Defined Functions. Funcțiile SQL standard acoperă majoritatea transformărilor de date de zi cu zi. Când SQL-ul standard nu face față, UDF-urile Python intervin perfect. Dacă ai de-a face cu reguli foarte custom, cum ar fi scrierea unui regular expression complex pentru a parsa adrese de email dezordonate, SQL-ul pur devine rapid ilizibil sau imposibil de folosit. UDF-urile scalare rezolvă această problemă permițându-ți să scrii logică Python simplă și să o execuți nativ în compute engine-ul Snowflake. O funcție scalară procesează pur și simplu un rând de input și returnează exact o valoare de output. Pentru a da deploy la codul tău Python, folosești Snowpark ca să înregistrezi funcția. Dacă ai nevoie de logică doar pentru scriptul curent, creezi un UDF anonim. Cea mai ușoară metodă să faci asta este să folosești decoratorul at-UDF. Mai întâi, scrii o funcție Python standard. Să o numim extract email domain. În interiorul ei, folosești modulul regex standard din Python pentru a parsa string-ul de text și a returna domeniul care face match. Chiar deasupra definiției funcției, pui decoratorul at-UDF. Când scriptul tău se execută, Snowpark serializează automat această funcție Python, îi face push pe server și returnează o referință către un obiect UDF. Acum poți pasa acest obiect în operațiunile pe coloane din DataFrame, aplicând parser-ul tău custom pe tabele masive ca și cum ar fi un feature nativ al bazei de date. Alternativ, poți sări peste decorator și să pasezi funcția Python explicit în metoda session dot udf dot register. Ambele metode creează un obiect temporar în database engine. În momentul în care sesiunea ta Snowpark se închide, UDF-ul anonim primește drop complet. Aici devine interesant. Dacă noua ta logică de parsing este valoroasă, probabil vrei să-i dai share cu alți utilizatori sau să o faci disponibilă pentru pipeline-urile SQL downstream. Pentru a realiza asta, creezi un UDF cu nume, permanent. Folosind aceeași metodă register, adaugi un flag is permanent setat pe true, și oferi o valoare de tip string pentru parametrul name. Acest nume dictează cum va fi apelată funcția în baza de date. Când faci un UDF permanent, Snowflake are nevoie de un loc fizic pentru a persista codul tău Python, astfel încât să rămână disponibil mult timp după ce sesiunea ta se deconectează. Din acest motiv, trebuie să oferi și un parametru stage location. Acesta indică spre un stage intern Snowflake existent. Snowpark va face upload și va stoca în siguranță fișierele Python compilate direct în acel stage. Odată ce înregistrarea se termină, oricine are permisiunile corecte pe baza de date poate apela logica ta custom din Python direct dintr-un query SQL standard. Când creezi orice UDF, Snowpark se bazează de obicei pe type hints din Python pentru a înțelege ce data types acceptă și returnează funcția. Dacă funcția ta așteaptă un string și returnează un string, adaugi acele type hints standard la definiția Python, iar Snowpark le mapează automat la data types echivalente din Snowflake. Adevărata putere a UDF-ului scalar nu este doar abilitatea de a scrie Python, ci abilitatea de a executa acel Python în memoria distribuită a database engine-ului, eliminând complet network latency-ul cauzat de extragerea datelor pentru procesare. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 12 din 17. Rularea pachetelor Python third-party într-o bază de date însemna de obicei dependency hell. Ajungeai să construiești containere Docker complexe doar pentru a pasa un array printr-o funcție matematică. Acum, este nevoie de exact o linie de cod. Acest episod acoperă dependency management pentru UDF-uri. Când scrii un User-Defined Function, sau UDF, logica ta rareori există într-un vid. Ai nevoie de librării. Într-un setup tradițional, mutarea codului Python acolo unde se află datele înseamnă că trebuie să muți și întregul environment. Îți faci griji de pip installs, dependențele compilatorului și de menținerea serverului identic cu mașina ta locală. Snowflake evită automat acest coșmar printr-o integrare nativă cu canalul Anaconda. Canalul Snowflake Anaconda găzduiește mii de pachete Python pre-built și pre-compiled, care sunt garantate să funcționeze în mediul de execuție Snowflake. Pentru a le folosi, nu instalezi nimic manual. Pur și simplu declari de ce are nevoie funcția ta. Când îți definești UDF-ul folosind decoratorul Python, adaugi un parametru numit packages. Pasezi acestui parametru o listă de string-uri, care numește librăriile de care ai nevoie. Ia un scenariu concret. Vrei să folosești un model de machine learning pentru a face scoring pe rânduri direct în interiorul unui query Snowflake. Funcția ta de predicție se bazează pe scikit-learn și pandas. Chiar deasupra funcției tale Python, adaugi decoratorul UDF și setezi lista packages să conțină string-urile scikit-learn și pandas. Nu construiești un container și nu rulezi un package manager. Când apelezi acel UDF, Snowflake face provision unui mediu securizat, face pull exact acelor pachete din canalul Anaconda și îți execută codul. Dacă ai nevoie de un release specific, poți face pin la versiune adăugând două semne de egal și numărul versiunii chiar în interiorul string-ului, exact ca într-un fișier requirements standard de Python. Asta acoperă librăriile externe. Acum, a doua parte a acestui lucru este propriul tău cod custom. Nu tot ceea ce scrii aparține de Anaconda. Adesea ai helper functions sau reguli de business custom scrise într-un fișier Python separat. Snowflake gestionează acest cod first-party prin sesiunea ta activă. Apelezi o metodă numită add import pe obiectul session. Pasezi calea fișierului tău custom către add import. Acesta poate fi un fișier Python local de pe laptopul tău, un fișier care se află deja într-un stage Snowflake sau o arhivă zip care conține un director mai adânc de module. Când îți înregistrezi UDF-ul, Snowflake preia fișierele specificate și le uploadează. La runtime, Snowflake extrage aceste fișiere și le plasează direct pe system path-ul mediului izolat care rulează UDF-ul tău. În codul funcției tale principale, folosești pur și simplu import statements standard din Python pentru a aduce modulele tale custom, exact ca și cum ar sta local, în același folder. Poți combina liber aceste două abordări. Îți declari requirements-urile externe prin parametrul packages și îți injectezi modulele interne folosind add import. Snowflake construiește contextul de execuție îmbinând în siguranță binarele Anaconda cu fișierele tale custom din stage, înainte ca un singur rând de date să fie procesat. Iată ideea cheie. Prin gestionarea dependențelor în acest fel, Snowflake decuplează complet codul tău funcțional de infrastructura necesară pentru a-l rula, permițându-ți să definești un mediu de execuție distribuit și securizat, folosind doar o listă de nume și căi de fișiere. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 13 din 17. Ce faci când funcția ta Python trebuie să returneze un întreg tabel de rezultate în loc de o singură valoare? Funcțiile User-Defined standard sunt excelente, dar sunt strict limitate la returnarea unei singure valori scalare per input row. Când trebuie să explodezi un singur input în mai multe output-uri, construiești o User-Defined Table Function, sau UDTF. Diferența este fundamentală. O funcție standard returnează o valoare. O UDTF returnează o relație. Asta înseamnă că returnează o structură tabelară pe care poți face query, filter sau join cu alte tabele, exact ca și cum ar fi un tabel fizic din baza ta de date. Să luăm un scenariu concret. Ai un tabel cu o coloană care conține log-uri de aplicație JSON custom, puternic nested. Fiecare rând conține un log entry masiv, dar acel singur entry ar putea conține cinci, zece sau cincizeci de evenimente de sistem distincte, ascunse adânc în JSON. Trebuie să normalizezi aceste date programatic. Vrei să pasezi un JSON string și să primești înapoi un tabel structurat în care fiecare eveniment individual este extras în propriul său rând. Pentru a construi o UDTF în Snowpark Python, nu scrii o funcție standalone. Scrii o clasă Python. Această clasă acționează ca handler pentru table function și orchestrează logica folosind până la trei metode specifice. Prima este metoda de inițializare. Aceasta este opțională. Snowflake o rulează o dată per partiție înainte de a procesa vreun rând. Dacă log parser-ul tău trebuie să compileze un regex complex sau să inițializeze un state dictionary custom, o faci aici, astfel încât costul de setup să fie plătit o singură dată per batch de date. A doua este metoda process. Aceasta este singura metodă obligatorie din clasă. Snowflake o apelează pentru fiecare input row în parte. În scenariul nostru de logging, metoda process primește JSON string-ul, despachetează array-ul de evenimente și face loop prin ele. Aici are loc conversia. În loc să returneze o valoare finală, metoda process face yield la tuple-uri. Fiecare tuple la care face yield devine instantaneu un rând nou în tabelul tău de output. Dacă un JSON log string conține doisprezece evenimente, metoda process face yield la doisprezece tuple-uri separate, iar Snowflake le transformă în doisprezece rânduri de output distincte. A treia este metoda end partition. Aceasta este, de asemenea, opțională. Snowflake o declanșează după ce toate rândurile din partiția curentă au trecut prin metoda process. De obicei, folosești asta dacă agregai state-ul pe întreaga partiție și trebuie să faci yield la un rând final de sumar, sau pur și simplu pentru a curăța memoria și resursele. Când înregistrezi această clasă handler în Snowpark, trebuie să declari explicit schema de output. Deoarece o UDTF returnează un tabel, motorul de execuție al bazei de date trebuie să cunoască exact numele coloanelor și tipurile de date ale tuple-urilor la care faci yield, înainte măcar ca query-ul să ruleze. Iată ideea cheie. UDTF-urile reduc distanța dintre logica complexă Python și operațiunile bazelor de date relaționale, permițându-ți să împachetezi unnesting-ul de date procedural și dezordonat într-o table interface curată, pe care restul aplicației tale poate face query nativ. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 14 din 17. Nu mai plăti pentru un server extern de orchestrare doar ca să rulezi scripturi Python care îi spun lui Snowflake ce să facă. Scrierea de Stored Procedures aduce acel control flow direct în platforma de date. Lumea confundă des Stored Procedures cu User-Defined Functions, sau UDF-uri. Un UDF nu este gândit pentru orchestrare. UDF-urile returnează valori în interiorul unui query și transformă datele rând cu rând. Stored Procedures sunt complet diferite. Ele execută scripturi întregi, rulează mai multe query-uri și gestionează acel control flow procedural. Le folosești ca să orchestrezi task-uri, nu ca să calculezi valorile coloanelor. Ca să creezi un Stored Procedure în Snowpark Python, scrii o funcție Python standard. Cerința crucială este primul argument al acelei funcții. Trebuie să fie mereu un obiect de tip Snowpark Session. Această sesiune este legătura ta activă cu baza de date. Când procedura ta rulează, folosește această sesiune ca să execute statement-uri SQL, să construiască DataFrame-uri și să citească sau să scrie date. Ca să-i spui lui Snowflake că această funcție este un Stored Procedure, pui decoratorul sproc direct deasupra definiției funcției. Decoratorul acționează ca un layer de configurare. Îl folosești ca să specifici return type-ul procedurii și orice pachete Python third-party de care codul tău are nevoie ca să ruleze. Când execuți codul de înregistrare, Snowpark îți ia funcția Python, o împachetează împreună cu dependențele ei și o înregistrează în Snowflake. Din acel moment, logica trăiește în baza de date și se execută pe compute-ul Snowflake. Gândește-te la un data pipeline care rulează noaptea. Procesul tău trebuie să creeze un tabel temporar, să încarce raw data în el, să ruleze o serie de transformări multi-step și, în final, să curețe obiectele temporare. Dacă rulezi asta de pe un server extern, codul tău Python trimite o comandă prin rețea, așteaptă ca Snowflake să termine, primește rezultatul înapoi și trimite următoarea comandă. Scriind exact aceeași logică Python ca un Stored Procedure, întregul script se execută în Snowflake. Folosește obiectul session ca să treacă nativ prin creările de tabele și transformările de DataFrame-uri. Ai zero network latency între logica de orchestrare și datele pe care le manipulează. Deși un Stored Procedure nu returnează o valoare per rând, cum face un UDF, tot returnează o singură valoare atunci când scriptul se termină. Tu definești acest return type atunci când setezi decoratorul sproc. De multe ori, acesta este un simplu string care confirmă succesul, un integer care reprezintă numărul total de rânduri procesate, sau chiar un rezultat tabelar care arată un log de execuție. Ai mai multe opțiuni pentru cum să dai deploy la acest cod. Poți să definești și să rulezi dinamic o procedură anonimă într-un script Python dacă ai nevoie de ea doar pentru o singură sesiune. Pentru pipeline-uri automate, o înregistrezi ca obiect permanent. Snowflake îi stochează definiția, astfel încât orice utilizator autorizat, aplicație externă sau scheduled task să o poată apela ulterior. Iată ideea cheie. Scrierea unui Stored Procedure în Snowpark Python înseamnă că tratezi Snowflake ca pe un application runtime, nu doar ca pe un storage layer. Muți creierul orchestrației tale fix lângă datele pe care le controlează. Dacă îți place emisiunea și vrei să ne susții munca, ne poți găsi căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că ne-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 15 din 17. Mutarea terabyților de date securizate către un server extern de machine learning este lentă, costisitoare și riscantă. Petreci ore întregi transferând date prin rețea, iar echipa ta de securitate devine nervoasă în legătură cu locul unde ajung. Ce-ar fi dacă, în schimb, compute-ul ar veni la date? Aceasta este ideea centrală din spatele antrenării modelelor de ML în Snowflake. Folosind Snowpark Python, poți antrena modele de machine learning single-node direct în data warehouse-ul tău, folosind stored procedures. Datele nu părăsesc niciodată perimetrul Snowflake. Asta rezolvă problema de data gravity. În loc să extragi milioane de rânduri într-o instanță de cloud separată, execuți scriptul de training fix acolo unde locuiesc datele în prezent. Antrenarea unui model de machine learning necesită încărcarea dataset-ului în memorie. Un virtual warehouse standard în Snowflake este optimizat pentru query-uri SQL paralele, nu pentru a ține dataset-uri masive în memoria RAM a sistemului. Dacă încerci să dai fit unui algoritm complex pe un warehouse standard, probabil te vei lovi de erori de out-of-memory, iar procesul va da crash. Pentru a gestiona asta, ai nevoie de un profil de compute diferit. Snowflake oferă warehouse-uri optimizate pentru Snowpark special pentru acest task. Aceste warehouse-uri oferă de până la șaisprezece ori mai multă memorie per nod în comparație cu instanțele standard. Să parcurgem un scenariu concret. Trebuie să antrenezi un model random forest din scikit-learn pe un dataset imens de clienți. Începi prin a scrie un stored procedure în Python. Când înregistrezi acest procedure, specifici pachetele Python necesare, cum ar fi scikit-learn, pandas și joblib. Snowflake face provision automat pentru aceste dependențe folosind canalul său integrat Anaconda. De asemenea, asignezi procedure-ul să ruleze pe warehouse-ul tău optimizat pentru Snowpark. În interiorul procedure-ului, folosești obiectul session din Snowpark pentru a defini query-ul pentru datele de training. Apoi apelezi metoda pentru a converti acel dataframe Snowpark într-un dataframe pandas standard. Această acțiune trage rezultatele query-ului direct în memoria fizică a nodului de warehouse. Pentru că ai făcut provision la compute-ul optimizat, există suficientă memorie RAM pentru a ține întregul dataset deodată. Apoi, inițializezi modelul random forest și invoci metoda fit, pasând dataframe-ul pandas. Procesorul warehouse-ului gestionează ciclul de training exact așa cum ar face-o pe un server dedicat de machine learning. Odată ce modelul termină training-ul, ai un algoritm fitted care stă în memoria temporară a mediului de execuție. Trebuie să îl persiști pentru predicții viitoare înainte ca stored procedure-ul să se termine. Aici intervine serializarea. Folosești o librărie precum joblib pentru a împacheta modelul. Iei obiectul modelului antrenat din memorie și îi dai dump într-un fișier, creând un artefact. Apoi instruiești stored procedure-ul să scrie acel fișier nou creat direct într-un stage intern Snowflake. Un stage acționează ca un folder de storage securizat legat de contul tău Snowflake. Aici este ideea cheie. Stored procedure-ul tău acționează ca un container securizat care conectează tabelele tale raw la librăriile standard de machine learning din Python. Păstrând pipeline-ul în întregime în Snowflake, reduci latența de rețea la zero, faci bypass la toate operațiunile de data egress și menții controale stricte de acces, toate astea în timp ce scrii exact același cod de training în Python pe care îl știi deja. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 16 din 17. Cum procesezi fișiere nestructurate de dimensiunea gigabyților în interiorul unei user-defined function fără să-ți depășești limitele de memorie? Dacă încerci să mapezi fișiere mari ca dependențe statice, sistemul încearcă să descarce totul upfront, iar codul tău dă crash. Soluția la asta este Dynamic File Access cu SnowflakeFile. Ca să înțelegi de ce contează asta, uită-te la cum funcționează în mod normal accesul la fișiere în Snowpark. De obicei, folosești parametrul imports ca să faci bind unui fișier la funcția ta. Abordarea asta statică este excelentă pentru fișiere mici de configurare sau pentru un model specializat de machine learning, pentru că fișierul este descărcat în compute warehouse înainte să înceapă execuția. Dar pică la scale. Dacă pipeline-ul tău trebuie să proceseze sute de log files masive de server sau PDF-uri high-resolution stocate într-un stage Snowflake, descărcarea lor statică este incredibil de lentă și garantează o eroare de out-of-memory. Aici intervine clasa SnowflakeFile. Aflată în modulul snowflake dot snowpark dot files, clasa asta îi permite funcției sau stored procedure-ului tău să deschidă fișiere direct dintr-un stage la runtime. Nu faci bind fișierului în timpul creării funcției. În schimb, funcția ta acceptă locația fișierului ca un argument standard de tip string. Când apelezi funcția în query-ul tău SQL sau în operațiunea pe dataframe, pasezi acea locație. În interiorul codului Python, apelezi metoda open pe clasa SnowflakeFile și îi pasezi string-ul cu locația fișierului. De asemenea, specifici modul de citire, folosind convenții standard din Python, cum ar fi r pentru text sau r b pentru a citi bytes. Iată ideea cheie. Apelarea metodei open nu încarcă fișierul. Returnează un file-like object care face stream la date. Fișierul rămâne pe stage, iar tu tragi datele printr-un network pipe. Hai să aplicăm asta la scenariul de procesare de loguri. Ai un tabel în baza de date unde fiecare rând conține un scoped URL care pointează către un log file mare diferit, aflat pe un internal stage. Pasezi acea coloană cu URL-ul către funcția ta. În interiorul funcției, deschizi stream-ul și scrii un loop standard ca să citești fișierul linie cu linie. Pe măsură ce codul tău evaluează fiecare linie ca să extragă error codes sau timestamps, Python elimină liniile anterioare din memorie. Poți să faci parse unui log file de cincizeci de gigabyți, în timp ce funcția ta ține o singură linie de text în memorie în orice milisecundă. Exact același concept funcționează și pentru fișiere binare. Dacă extragi text din PDF-uri mari, deschizi fișierul în binary mode și pasezi stream-ul rezultat direct într-o librărie Python de PDF parsing. Librăria citește byte stream-ul secvențial, fără să aibă nevoie ca întregul document să stea în memoria sistemului. SnowflakeFile gestionează automat și security boundary-ul. Când pasezi un scoped URL generat dinamic în funcția ta, Snowflake acordă read access la acel fișier specific doar pe durata query-ului, expirând imediat când query-ul se termină. Streaming-ul fișierelor specificate dinamic îți menține memory footprint-ul plat indiferent de dimensiunea fișierului, lăsând compute warehouse-ul tău să se concentreze în întregime pe procesarea datelor, în loc să încerce doar să le țină în memorie. Asta e tot pentru acest episod. Mersi de ascultare și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Snowflake și Snowpark Python, episodul 17 din 17. Nu ai face niciodată deploy la cod de backend fără unit tests, așa că de ce sunt data pipelines adesea trimise în producție la voia întâmplării? Snowpark schimbă acest lucru făcând logica ta de date modulară, ceea ce înseamnă că o poți testa, în sfârșit, ca pe un software obișnuit. Testarea în Snowpark Python este ceea ce aduce rigoarea de software engineering în data engineering. Snowpark îți permite să extragi logica de transformare din scripturi monolitice și să o muți în funcții Python independente. Deoarece aceste funcții primesc un DataFrame ca input și returnează un DataFrame ca output, le poți testa folosind framework-uri Python standard. PyTest este cea mai comună alegere. Pentru a rula orice cod Snowpark, ai nevoie de o sesiune activă. În loc să incluzi detaliile de autentificare în fiecare test în parte, definești un session fixture. Faci acest lucru într-un fișier de configurare dedicat numit conftest.py, pe care PyTest îl recunoaște automat. În interiorul acestui fișier, scrii o funcție de setup care stabilește o conexiune la Snowflake, returnează obiectul session și închide sesiunea când testele se termină. Decorezi această funcție ca un PyTest fixture. Acum, orice test din proiectul tău poate solicita o sesiune activă pur și simplu cerând-o după nume în argumentele funcției de test. Să aplicăm acest lucru pe un scenariu concret. Ai o transformare custom complexă de DataFrame care filtrează utilizatorii inactivi, calculează un scor de risc și standardizează numele coloanelor. Trebuie să validezi această logică înainte de a face deploy la pipeline în producție. Începi prin a scrie un test. Primul pas în cadrul acestui test este crearea unui input DataFrame care conține câteva rânduri de mock data atent selectate. Definești numele exacte ale coloanelor și valorile rândurilor necesare pentru a declanșa acele edge cases specifice din logica ta. Folosești session fixture-ul pentru a converti aceste raw mock data într-un Snowpark DataFrame. Apoi, pasezi acest mock input DataFrame în funcția ta de transformare. Funcția aplică logica ta de business și returnează output DataFrame-ul real. Acum trebuie să verifici dacă logica a făcut ceea ce trebuia să facă. Creezi un al doilea mock DataFrame în cadrul testului tău, de data aceasta reprezentând rezultatul exact așteptat. Aceasta este partea care contează. Trebuie să compari DataFrame-ul real cu DataFrame-ul așteptat. Cu toate acestea, nu poți folosi pur și simplu un equality check standard din Python pe obiectele DataFrame în sine, deoarece acestea sunt doar referințe către query plans. În schimb, trebuie să compari datele pe care le conțin. Apelezi metoda collect atât pe DataFrame-ul real, cât și pe cel așteptat, pentru a aduce rezultatele înapoi în memorie sub formă de liste de row objects. Deoarece bazele de date distribuite nu garantează ordinea pentru result sets decât dacă sunt instruite explicit, compararea directă a două liste de rânduri ar putea eșua chiar dacă datele sunt corecte. Pentru a remedia acest lucru, sortezi ambele liste de rânduri înainte de a face assert că sunt egale. Dacă datele reale sortate se potrivesc cu datele așteptate sortate, testul tău trece. Prin pasarea unor seturi de date mici și controlate prin funcții de transformare izolate, detectezi erorile logice local, înainte ca ele să atingă vreodată o tabelă de producție. Acest lucru izolează componentele pipeline-ului tău și face ca workflow-ul tău de data engineering să fie la fel de fiabil ca software development-ul tradițional. Aici se încheie seria noastră despre Snowpark Python. Te încurajez să explorezi documentația oficială Snowflake, să încerci să scrii aceste teste hands-on sau să vizitezi devstories.eu pentru a sugera subiecte pentru viitoarele noastre serii. Aș dori să îți mulțumesc pentru că ne asculți — ne ajută foarte mult. Să ai o zi excelentă!