Mastering Modern Pandas

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 1 di 8. Prendi due colonne di dati finanziari, le sommi, e la somma finale non ha senso. Le righe si sono spostate, e hai appena sommato il prezzo di chiusura di ieri al volume di oggi. Questo succede quando tratti i dati come una griglia stupida invece di affidarti all'astrazione fondamentale: i DataFrame e il Label Alignment. Spesso le persone guardano pandas e pensano che sia solo uno spreadsheet programmatico o un array NumPy bidimensionale standard. Non è così. Un normale array NumPy si basa su un positional indexing rigido. Se sommi due array, l'elemento in posizione zero si somma all'elemento in posizione zero. Se ai tuoi dati manca una riga, tutto si sposta, e i tuoi calcoli vengono corrotti silenziosamente. Pandas risolve esattamente questo problema disaccoppiando i dati dalla loro posizione fisica in memoria. Utilizza un data alignment intrinseco, il che significa che allinea i dati in base alle label, mai in base alla posizione. Per capirlo, guarda le fondamenta della libreria, le Series. Una Series è un array unidimensionale che può contenere qualsiasi data type. A differenza di una list standard, ogni elemento in una Series è saldamente attaccato a una label. Queste label, nel loro insieme, formano quello che pandas chiama index. Puoi usare degli integer come label, ma più spesso usi delle string o dei timestamp. Un DataFrame è semplicemente una collection di questi oggetti Series che fungono da colonne, che condividono tutte lo stesso index, posizionate una accanto all'altra. Ecco il punto chiave. Quando esegui un'operazione in pandas, è l'index a dettare il comportamento. Mettiamo che tu abbia due Series di rendimenti azionari giornalieri. La Series A ha i dati per lunedì, martedì, mercoledì e giovedì. La Series B ha i dati per mercoledì, giovedì e venerdì. Se dici a pandas di sommare queste due Series, ignora il loro ordine fisico. Guarda le label delle date. Trova mercoledì nella Series A e lo somma a mercoledì nella Series B, anche se mercoledì è il terzo elemento nel primo dataset e il primissimo elemento nel secondo dataset. Questo solleva il problema dei giorni non sovrapposti. Lunedì esiste nella prima Series ma non nella seconda. Venerdì esiste nella seconda ma non nella prima. Pandas non va in crash, e di certo non indovina un valore. Invece, crea un nuovo index che è l'unione di tutte le label da entrambi gli input. Per ogni label che non esiste in entrambi i posti, pandas inserisce un NaN, che significa Not a Number. L'operazione viene completata con successo, e puoi vedere immediatamente dove i tuoi dati sono incompleti. Non devi mai scrivere un loop per controllare se le date combaciano. L'allineamento è automatico, integrato direttamente nella data structure stessa. Questa stessa logica scala direttamente sui DataFrame. Un DataFrame si allinea su entrambe le dimensioni simultaneamente. Quando operi su due DataFrame, pandas fa il match tra row label e row label, e tra nome della colonna e nome della colonna. Allinea perfettamente l'intera struttura prima di eseguire una singola operazione matematica. Tutto ciò che non si sovrappone tra le righe e le colonne viene contrassegnato come missing data. Il vero potere di pandas non è la matematica che esegue, ma il fatto che la label viaggia sempre con i dati, rendendo i mismatch posizionali strutturalmente impossibili. Se vuoi supportare lo show, puoi trovarci cercando DevStoriesEU su Patreon. Grazie per l'ascolto, e happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 2 di 8. Estrai una slice dei tuoi dati, aggiorni un singolo valore e improvvisamente il tuo dataset originale risulta corrotto. O peggio, ricevi un warning imprevedibile e non hai idea se il tuo aggiornamento sia stato effettivamente applicato alla slice o alla sorgente. La versione 3.0 risolve finalmente questo caos rendendo il Copy-on-Write il comportamento di default. Il Copy-on-Write riscrive radicalmente il modo in cui pandas gestisce la memoria. Nelle versioni precedenti, pandas creava spesso delle copie difensive per impedirti di modificare accidentalmente il dataset originale. Se filtravi un dataset, pandas lo copiava. Se facevi il drop di una colonna, pandas copiava il resto. Questo sprecava enormi quantità di memoria e cicli di CPU. Quando non copiava, restituiva una view, il che significava che modificare il nuovo oggetto alterava silenziosamente il parent. Con il Copy-on-Write, qualsiasi DataFrame o Series che deriva da un altro condivide esattamente la stessa memoria sottostante. Questo significa che estrarre un subset, fare il drop di una colonna o il reset di un index è quasi istantaneo. Nessun dato viene duplicato in partenza. Ecco il punto chiave. Non confondere una view legacy con una lazy copy del Copy-on-Write. In una view tradizionale, sia il parent che il child puntano alla stessa memoria, e una modifica a uno cambia anche l'altro. Il Copy-on-Write è diverso. La memoria condivisa è temporanea e rigorosamente protetta. La condivisione dura solo finché non provi a cambiare qualcosa. Considera uno scenario concreto. Hai un DataFrame che contiene dei profili utente. Selezioni la colonna age e la assegni a una nuova variabile chiamata age subset. In questo preciso istante, age subset occupa zero memoria extra. Punta direttamente al DataFrame originale dei profili utente. Successivamente, aggiorni il primo valore nel tuo age subset a novantanove. È qui che entra in gioco la parte write del Copy-on-Write. Pandas rileva la modifica. Prima di eseguire il tuo aggiornamento, controlla se qualche altro oggetto sta condividendo questo specifico blocco di dati. Dato che il DataFrame parent lo sta ancora usando, pandas alloca all'istante nuova memoria, ci copia i dati, e poi scrive il valore novantanove nella nuova posizione. Il tuo DataFrame parent rimane al sicuro e inalterato. Mutare un subset non muta mai il parent. Questo meccanismo si propaga perfettamente attraverso le operazioni in chain. Quando metti in chain operazioni come il drop di righe vuote, il replace di valori e il rename di colonne, le vecchie versioni di pandas creavano una copia fisica a ogni singolo step. Con il Copy-on-Write, quegli step intermedi condividono semplicemente la memoria. Una copia fisica viene attivata solo quando uno step muta effettivamente gli array di dati sottostanti. Se un'operazione si limita a riorganizzare le reference, non avviene alcuna copia. Questo elimina completamente la corruzione accidentale dei dati. Non devi più indovinare se un'operazione ha restituito una view o una copia, e non vedrai mai più il warning Setting With Copy. La regola è assoluta: un oggetto parent e un oggetto child non si modificheranno mai a vicenda. Rimandando le copie fino al millisecondo esatto in cui avviene una modifica, pandas ti offre le performance veloci e il basso memory footprint delle view, uniti alla rigorosa sicurezza delle deep copy. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 3 di 8. Carichi un dataset con qualche milione di righe e improvvisamente l'utilizzo della memoria schizza alle stelle. I numeri sono a posto, ma le colonne di testo e i missing value stanno silenziosamente distruggendo la tua RAM. La soluzione è un cambiamento fondamentale nel modo in cui pandas memorizza i dati, ed è esattamente di questo che parla questo episodio: la PyArrow Engine Room. Se hai sentito parlare di Apache Arrow, potresti pensare che sia strettamente per grandi sistemi distribuiti come Spark o Hadoop. Non è così. Arrow ora è un memory format nativo di prim'ordine e un execution engine integrato direttamente dentro pandas. Per anni, pandas si è affidato interamente a NumPy. NumPy è incredibilmente veloce per i calcoli numerici densi, ma ha un enorme punto cieco per quanto riguarda i missing data. NumPy non ha un concetto nativo di missing integer o missing boolean. Se hai una colonna di integer e manca un singolo valore, storicamente pandas è stato costretto a convertire l'intera colonna in numeri floating-point solo per poter usare il marcatore Not a Number. Questo cambia i tuoi data type, rovina gli exact match e consuma più memoria. PyArrow risolve questo problema usando una validity bitmap. Invece di cambiare il data type per gestire un missing value, Arrow mantiene i tuoi integer come integer. Aggiunge un array nascosto e altamente compresso di uno e zeri accanto ai tuoi dati. Un uno significa che il valore è valido. Uno zero significa che è mancante. Il tuo data type rimane intatto, e tracciare i missing value costa quasi zero memoria. Ecco il punto chiave. Il risparmio di memoria è ancora più estremo quando si ha a che fare con il testo. Tradizionalmente, pandas memorizza le string usando l'object data type di NumPy. Questo significa che la colonna non contiene effettivamente il tuo testo. Contiene dei memory pointer. Ogni riga punta a uno string object standard di Python sparso da qualche altra parte nella memoria del tuo computer. Se hai dieci milioni di righe di testo, hai dieci milioni di pointer e dieci milioni di string object separati. L'overhead di memoria è impressionante, e iterare su di essi è terribilmente lento. PyArrow cambia completamente l'architettura. Quando imposti le tue colonne pandas per usare uno string data type di PyArrow, il testo viene memorizzato in un singolo blocco di memoria contiguo. La colonna si limita a tenere traccia dei byte offset. Registra esattamente dove inizia e finisce ogni parola in quel grande blocco continuo. Immagina un dataset ad alta cardinalità. Hai una colonna di user agent string o ID di transazione univoci. Molte delle righe sono vuote. Se leggi questo in pandas nel modo tradizionale, il default è un object array di NumPy. Ora, di' a pandas di usare invece l'engine PyArrow, assegnando esplicitamente uno string data type basato su PyArrow durante il tuo step di lettura. All'istante, il memory footprint crolla, spesso del cinquanta percento o più. Il miglioramento va oltre i limiti della RAM. Dato che ora i dati sono impacchettati strettamente insieme in una struttura costruita per l'analytics, le operazioni di string matching accelerano. Se esegui una ricerca con regular expression su quella colonna, l'engine Arrow elabora i raw byte direttamente a livello di sistema. Bypassa completamente il lento overhead dei Python object. Ottieni colonne integer che rimangono effettivamente integer quando mancano dei dati, e operazioni sulle string che non soffocano il tuo hardware. Se elabori testo o messy data, affidarsi al NumPy object array è obsoleto. Usare data type basati su PyArrow è in assoluto il modo più veloce per rendere istantaneamente più leggera una pipeline pandas pesante. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 4 di 8. Hai un file Parquet di svariati gigabyte con cento colonne. Te ne servono solo quattro per far girare le tue metriche. Se la tua prima mossa è caricare l'intero file in un dataframe e poi filtrare le colonne, stai sprecando enormi quantità di RAM e cicli di CPU prima ancora che la tua analisi inizi. La soluzione sta nel padroneggiare la data ingestion moderna. Il principale collo di bottiglia nella data ingestion è l'input e output su disco. Le funzioni read di Pandas, come read underscore csv e read underscore parquet, scansionano i dati dal disco alla memoria. Per minimizzare questo trasferimento, usi un argomento chiamato usecols. Passi una lista contenente i nomi esatti delle colonne che vuoi. Il parser legge dal file solo quelle specifiche colonne. Il guadagno di performance che ottieni dipende pesantemente dal formato del tuo file. I file CSV salvano i dati riga per riga. Quando usi usecols con un CSV, il parser deve comunque scansionare l'intero file di testo riga per riga, ma scarta immediatamente le colonne che non ti servono prima di allocare memoria per il dataframe. I file Parquet, invece, salvano i dati colonna per colonna. Per un file Parquet da cento colonne dove ti servono solo quattro colonne di metriche, passare usecols significa che il parser ignora completamente i blocchi del file che contengono le altre novantasei colonne. Legge dal disco solo i byte di cui ha assolutamente bisogno. Questo riduce drasticamente sia il tuo tempo di lettura che il tuo memory footprint. Limitare le colonne è solo il primo passo. La prossima ottimizzazione riguarda come Pandas salva quelle colonne in memoria. Storicamente, Pandas si basava interamente sugli array NumPy. NumPy è eccellente per la computazione numerica densa, ma fa fatica con i dati di testo e i missing values. Salva le string come oggetti Python sparsi in memoria, e forza le colonne di interi a diventare float solo per rappresentare i dati mancanti. Per risolvere questo problema, Pandas ha introdotto l'argomento dtype backend. Quando imposti questo argomento alla string pyarrow, Pandas usa invece Apache Arrow come backend per i tuoi dati. Arrow salva le string in blocchi di memoria contigui e altamente efficienti, e usa una bitmask separata per tracciare i missing values, mantenendo intatti i tuoi interi. Ecco il punto chiave. Potresti pensare che Pandas legga prima i dati in array NumPy e poi li converta in Arrow. Non è quello che succede. Quando specifichi il backend PyArrow durante la funzione read, Pandas bypassa completamente NumPy durante la fase di parsing. I dati fluiscono direttamente dal file su disco agli array PyArrow in memoria. Questo evita la grave performance penalty delle allocazioni di memoria intermedie. Diamo un'occhiata all'intera pipeline. Chiami read underscore parquet. Primo, passi il tuo file path. Secondo, passi usecols con una lista delle tue quattro colonne di metriche. Terzo, imposti l'argomento dtype backend a pyarrow. Il parser salta direttamente alle quattro colonne su disco, le estrae e ne fa lo stream direttamente nella memoria con backend Arrow. Ti ritrovi con un dataframe snello e velocissimo che contiene esattamente ciò di cui hai bisogno, supportato da data type moderni. Filtrare le colonne al layer di IO invece che all'application layer è il modo più efficace in assoluto per prevenire crash out-of-memory in Pandas. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 5 di 8. Hai un elenco di dieci milioni di transazioni, e ognuna ha solo un customer ID. Hai bisogno dei nomi effettivi dei clienti associati a queste transazioni. Se stai scrivendo un loop Python o usando un dictionary mapping per associare quegli ID ai nomi, stai sprecando cicli di CPU e memoria. Pandas ha un engine ottimizzato, creato appositamente per operazioni in stile SQL in una singola riga. Oggi parliamo di algebra relazionale: Merge e Join. Prima di proseguire, chiariamo un equivoco comune. Spesso si confonde il merge con la concatenazione. La concatenazione consiste semplicemente nell'impilare fisicamente gli array uno sopra l'altro o uno accanto all'altro. Il merge è completamente diverso. Il merge serve per le join nei database relazionali. Allinea le righe di due tabelle diverse in base ai valori delle chiavi condivise. La funzione principale per questo è pandas punto merge. Prende due DataFrame, che chiamiamo tabella di sinistra e tabella di destra. Ripensa al nostro scenario delle transazioni. Il tuo DataFrame di sinistra è una fact table enorme contenente milioni di acquisti. Il tuo DataFrame di destra è una dimension table più piccola contenente i dettagli dei clienti, come nomi e indirizzi email. Entrambe le tabelle condividono una colonna chiamata customer ID. Questo setup specifico è chiamato many-to-one join. Hai molte transazioni appartenenti a un singolo cliente. Quando fai il merge usando la chiave customer ID, pandas prende il singolo record del cliente dalla tabella di destra e fa il broadcast su tutte le transazioni corrispondenti nella tabella di sinistra. Ecco il punto chiave. Il parametro più critico che controlli è l'argomento how. Questo determina quali chiavi sopravvivono al merge e arrivano nel risultato finale. Di default, pandas utilizza una inner join. Se non specifichi l'argomento how, il risultato mantiene solo le righe in cui il customer ID esiste in entrambe le tabelle. Se un cliente ha effettuato una transazione ma il suo record è stato eliminato dal database dei clienti, quella transazione scompare completamente dal risultato del merge. Per evitare di perdere dati dalla tua tabella primaria, usi una left join. Passando left all'argomento how, pandas mantiene ogni singola riga della tua tabella di sinistra, ovvero il tuo enorme elenco di transazioni. Se una transazione ha un customer ID che non esiste nella tabella di destra, pandas mantiene comunque la riga della transazione, ma riempie i dettagli mancanti del cliente con valori Not a Number. Questa è esattamente la logica che vuoi quando colleghi i dettagli di una dimension table a una fact table primaria. L'esatto opposto è una right join. Passando right mantieni tutte le righe della dimension table dei clienti, indipendentemente dal fatto che abbiano transazioni corrispondenti nella tabella di sinistra. Ti ritrovi così con un elenco di tutti i clienti, e quelli che non hanno comprato nulla mostrano semplicemente dei missing values per i dati delle transazioni. Infine, c'è la outer join. Passa outer all'argomento how, e pandas mantiene tutto. Prende l'unione delle chiavi da entrambi i frame. Ogni transazione e ogni cliente arrivano nel dataset finale, con i missing values che riempiono i vuoti ovunque non venga trovata una corrispondenza perfetta. La inner join di default elimina silenziosamente i dati non corrispondenti, quindi, a meno che tu non voglia esplicitamente filtrare le righe, dovresti sempre specificare una left join quando colleghi delle lookup table al tuo dataset principale. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 6 di 8. Probabilmente pensi che raggruppare i dati significhi semplicemente aggregare i numeri per trovare un totale o una media. Ma cosa succede se devi valutare una singola riga in base al comportamento del gruppo a cui appartiene, senza perdere la shape originale del tuo dataset? Questo richiede di andare oltre i semplici riepiloghi e di utilizzare il pattern Split-Apply-Combine. Quando chiami un metodo groupby in pandas, attivi un processo sequenziale in tre step. Il primo è lo split. Pandas prende l'intero dataset e lo divide in gruppi indipendenti in base a una key che fornisci. Successivamente c'è lo step di apply, in cui una funzione viene eseguita su ciascun gruppo in modo completamente indipendente dagli altri. Infine, lo step di combine prende i risultati di ogni gruppo e li unisce in un'unica struttura dati. Molti sviluppatori pensano che lo step di apply serva esclusivamente per l'aggregazione. L'aggregazione prende un gruppo di valori e restituisce un singolo numero, come la somma o la media. Se raggruppi un dataset di assistenza clienti per agente e chiedi il tempo medio di risoluzione, ottieni un nuovo dataset con una riga per agente. Questo è utile, ma è solo un terzo della storia. Ecco il punto chiave. Lo step di apply viene utilizzato con la stessa frequenza per la transformation e la filtration. Una transformation esegue un calcolo sul gruppo, ma restituisce un oggetto indicizzato esattamente come i dati originali. Non riduce il row count. Torniamo al nostro dataset di assistenza clienti. Vuoi sapere se un ticket specifico ha richiesto un tempo insolitamente lungo per essere risolto. Ma un tempo insolito per un agente junior potrebbe essere un tempo normale per un agente senior che gestisce problemi molto complessi. Hai bisogno dello z-score del tempo di risoluzione, relativo solo alla media storica di quello specifico agente. Fai lo split dei dati per agente e applichi una transformation function che calcola lo z-score. Pandas calcola la media e la deviazione standard per l'agente A, standardizza i ticket dell'agente A, fa esattamente la stessa cosa per l'agente B e poi li combina. Ottieni di nuovo il tuo dataset originale, riga per riga, ma ora ogni ticket ha uno score standardizzato basato rigorosamente sul suo specifico contesto di gruppo. La terza applicazione fondamentale è la filtration. Questo ti permette di scartare interi gruppi in base a una proprietà collettiva, anziché valutare le singole righe. Supponi di voler analizzare quegli z-score dei ticket, ma alcuni agenti nel tuo dataset hanno elaborato solo due o tre ticket. Le loro medie non hanno alcun significato statistico. Puoi usare una filter function sul tuo grouped object per verificare la size di ciascun gruppo. Se un gruppo ha meno di dieci ticket, la filter logic restituisce false, e pandas droppa ogni singola riga appartenente a quell'agente. Lo step di combine restituisce quindi un dataset contenente solo i ticket degli agenti con un sample size valido. Fai lo split dei dati in base a una key, applichi una regola logica che valuta il gruppo, e combini i sopravvissuti. L'aggregazione riduce i dati. La transformation standardizza i dati all'interno del loro contesto locale. La filtration scarta i dati in base alle regole di gruppo. Il vero potere del pattern split-apply-combine è che ti permette di manipolare singole righe utilizzando il contesto a livello di gruppo, senza mai scrivere un loop manuale. Se trovi utili questi deep dive e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio 7 di 8. Creare a mano le tue aggregazioni temporali è un incubo fatto di intervalli mancanti, anni bisestili e logica dei giorni lavorativi. Se ti ritrovi a scrivere codice custom per arrotondare i timestamp grezzi in bucket regolari, stai facendo troppa fatica. La soluzione è padroneggiare le time series usando le strutture temporali native di pandas. La spina dorsale delle funzionalità per le time series in pandas è il DatetimeIndex. Invece dei classici numeri di riga interi, l'index del tuo dataframe diventa una sequenza rigorosa di timestamp precisi. Aggiornare il tuo index a un DatetimeIndex cambia radicalmente il comportamento del dataframe, rendendo l'intera struttura consapevole del tempo. Questo abilita lo slicing nativo basato sul tempo. Se ti servono i dati solo di ottobre 2023, ti basta passare la semplice string "2023-10" al row locator. Pandas calcola automaticamente i limiti esatti al microsecondo per quel mese e restituisce il subset corretto. Puoi passare delle string di date parziali fino all'ora o al minuto, e l'index risolve la matematica dei timestamp sottostante. Una volta che i tuoi dati sono consapevoli del tempo, di solito hai bisogno di aggregarli. Molti developer confondono il resampling basato sul tempo con il grouping di base. Tentano di applicare operazioni di group-by standard a una colonna di date. Questo approccio fallisce quando hai a che fare con time series del mondo reale, disordinate. Il grouping standard guarda solo le righe esplicite attualmente presenti nel tuo dataframe. Se un server va offline per un'ora, un'operazione di group-by standard salta semplicemente quell'ora per intero. La tua timeline di output avrà un gap nascosto, sballando qualsiasi calcolo successivo basato sul tempo. Ecco il punto chiave. Il metodo dot resample è fondamentalmente diverso perché comprende nativamente la logica del calendario. Proietta una griglia temporale rigida e continua sui tuoi dati. Se fai un resample a intervalli di dieci minuti, e non arrivano dati durante una specifica finestra di dieci minuti, pandas genera comunque quel bucket. Lascia i valori vuoti, preservando la rigorosa integrità matematica della tua timeline. Il resampling comprende intrinsecamente gli intervalli vuoti, le durate irregolari dei mesi e i calendari dei giorni lavorativi che escludono weekend e festività. Considera lo scenario di un analista quantitativo che elabora dati di trading. Stai ricevendo dati tick ad alta frequenza da un exchange. I singoli trade arrivano a intervalli completamente irregolari, a volte tre al microsecondo, a volte nessuno per venti secondi. Il tuo modello di pricing non può gestire questo caos. Richiede barre da cinque minuti perfettamente allineate. Poiché i prezzi dei tuoi trade sono mappati su un DatetimeIndex, chiami il metodo dot resample sul tuo dataframe e passi la string di frequenza "5min". Questo mappa ogni tick irregolare su una rigorosa griglia da cinque minuti. Per alimentare un modello finanziario, ti servono specificamente i prezzi di Open, High, Low e Close per ogni bucket. Invece di scrivere funzioni custom per estrarre il primo, il massimo, il minimo e l'ultimo trade di ogni finestra, chiami in chain il metodo dot ohlc direttamente sulla tua chiamata di resample. Pandas calcola tutte e quattro le metriche in una volta sola, restituendo in output un dataset strutturato in modo pulito di barre da cinque minuti. Quegli intervalli vuoti di cui parlavamo prima rimangono intatti in questo output. Puoi quindi aggiungere in chain un altro metodo per fare il forward-fill dei prezzi di chiusura precedenti nei gap vuoti, assicurandoti che il tuo modello abbia sempre dati validi. Il resampling trasforma record irregolari ed event-driven in una timeline prevedibile e matematicamente solida, senza che tu debba scrivere una singola riga di logica di calendario. Grazie per l'ascolto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Mastering Modern Pandas, episodio otto di otto. Prima di richiedere un'istanza cloud enorme o di passare a un cluster di calcolo distribuito, potresti sorprenderti nello scoprire che puoi processare terabyte di dati direttamente sul tuo laptop. La maggior parte degli errori di out-of-memory non richiede un nuovo framework, ma solo un cambiamento nel modo in cui leggi i file. Oggi parleremo dello scaling su dataset out-of-core. Il processing out-of-core significa semplicemente lavorare con dataset più grandi della memoria di sistema disponibile. Una reazione comune a un crash per out-of-memory è presumere che pandas abbia raggiunto il suo limite fisico. Spesso la gente passa subito a riscrivere le proprie pipeline in PySpark o Dask. Ma pandas può gestire dati enormi nativamente se smetti di cercare di caricare l'intero dataset in RAM tutto in una volta. Semplici pattern con i generator risolvono la stragrande maggioranza di questi problemi di scaling. Il meccanismo principale per il processing out-of-core è il chunking. Se hai a che fare con un singolo file di testo enorme, la funzione read standard accetta un argomento chunk size. Quando passi questo argomento, pandas smette di restituire un DataFrame. Al suo posto, restituisce un iterator. Ogni volta che il tuo codice fa avanzare l'iterator, pandas legge dal disco solo il numero di righe specificato e le restituisce come un normale DataFrame. Applichi la tua logica a quel chunk, estrai il risultato e scarti il chunk. Dato che i vecchi dati vengono rimossi dalla memoria prima di leggere il batch successivo, il tuo utilizzo di memoria rimane completamente piatto, indipendentemente da quanto sia grande il file sottostante. È qui che la cosa si fa interessante. Le moderne infrastrutture dati raramente si basano su singoli file di testo giganti. Di solito, i grandi dataset sono salvati come directory che contengono centinaia di file più piccoli e partizionati, tipicamente in un formato binario come Parquet. I file Parquet sono altamente compressi e si caricano molto velocemente, ma non puoi comunque caricare cinquanta gigabyte di file Parquet in sedici gigabyte di RAM. Per gestire questo, applichi il concetto di chunking manualmente tra i file. Immagina di avere una directory di file Parquet annuali e di voler calcolare la frequenza totale delle categorie sull'intero dataset storico. Costruisci un semplice loop iterativo. Per prima cosa, inizializza una Series vuota di pandas. Questa farà da accumulatore per i tuoi totali globali. Poi, itera attraverso la tua directory file per file. All'interno del loop, leggi il file corrente in un DataFrame. Ora, esegui la funzione value counts sulla colonna specifica che stai analizzando. Questo ti darà una Series contenente le frequenze solo per quello specifico anno. Il passaggio cruciale è combinare questo risultato locale con il tuo accumulatore globale. Lo fai chiamando il metodo add sulla tua Series globale e passandogli la Series locale. Dato che alcune categorie potrebbero esistere in un file ma non in un altro, devi impostare l'argomento fill value a zero. Questo assicura che pandas allinei correttamente gli indici e sommi i conteggi senza introdurre missing values. Una volta che il loop finisce di processare quel file, passa al successivo. Python fa automaticamente il garbage collect del vecchio DataFrame. In pratica, stai facendo lo streaming di un enorme dataset attraverso la memoria un file alla volta, costruendo un'aggregazione globale continua. Il processing out-of-core non consiste nel buttare hardware su un problema. Si tratta di mantenere piccolo il tuo stato attivo e di spingere le aggregazioni matematiche giù al livello del singolo chunk. Dato che questa è la fine della serie, ti incoraggio vivamente a esplorare la documentazione ufficiale di pandas sullo scaling e a provare questi pattern hands-on con i tuoi dati. Se hai argomenti che vorresti che trattassimo nelle prossime serie, visita devstories dot eu e faccelo sapere. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.