Perché Apache Spark verrà sostituito da Python

In python vi sono varie librerie per effettuare data analysis, una tra le più importanti è Pandas.
Pandas offre funzionalità simili a R, come ad esempio i DataFrame per la gestione dei dati in formato tabella.

Purtroppo Pandas è stata implementata per gestire solo piccole quantità di dati, quando la tabella (ad es. un file csv) supera la dimensione della memoria virtuale del sistema operativo (stesso ordine di grandezza della RAM dei nostri PC) Pandas smette di funzionare.

Infatti, quando la dimensione dei dati supera una certa soglia vengono usate tecnologie differenti, questo è il contesto che viene anche chiamato Big Data.
La tecnologia maggiormente usata nel contesto dei Big Data è Apache Spark.

Purtroppo Apache Spark è scritto in Java e Scala, il che significa che se un Data Scientist comincia la sua sperimentazione su piccoli campioni, usando ad esempio R o python, quando poi vuole passare gli stessi modelli su un campione più grande si ritrova obbligato a riscrivere il codice, infatti deve effettuare degli effort addizionali nel re-implementare gli stessi modelli usando Java o Scala. Questa operazione tipicamente coinvolge un team dove altri ruoli entrato in campo, ad esempio il Data Engineer.
Qui c’è da fare una parentesi, perché Spark offre anche delle interfacce da python e R, chiamate rispettivamente pyspark e sparklyr, ma purtroppo le politiche di rilascio delle nuove funzionalità in Spark prediligono le interfacce native in Java e Scala, lasciando un po’ indietro i corrispettivi in python e R, in altri termini, quando esce una nuova funzionalità in Spark, ad esempio quando viene rilasciata la versione 2.4, passa un po’ di tempo prima che le stesse funzionalità vengano rilasciate anche in python ed R.
In più, essendo il core di Spark eseguito sulla Java Virtual Machine, esiste un ritardo (overhead) dovuto al fatto che python o R effettuano la traduzione dei dati in memoria e li inviano a Java e viceversa, in altri termini, ogni linguaggio di programmazione ha un proprio modo in cui salva i dati in memoria, quando un linguaggio deve tradurre dati per inviarli ad un altro, chiaramente, effettua delle operazioni di trasformazione che portano ad un ritardo nella computazione. Questo problema è stato in parte risolto con Apache Arrow, un progetto che prevede di standardizzare il modo in cui i dati vengono salvati in memoria, in modo da permettere una più efficiente interoperabilità tra i linguaggi di programmazione.

In ogni caso, quando un Data Scientist, dopo aver scritto una procedura su “small data” in python, usando ad esempio librerie come pandas (per i dataframe) o scikit-learn (per regressione e Machine Learning), vuole eseguire lo stesso algoritmo su Big Data deve riscrivere il codice, perché l’interfaccia con cui è stato scritto pyspark è differente.

Piccola parentesi, un'interfaccia è il modo in cui viene chiamata una funzionalità, un esempio di diversa interfaccia tra R e python è il modo in cui viene eseguita la PCA, ad esempio in R:

mtcars.pca <- prcomp(x, center = TRUE,scale. = TRUE)

summary(mtcars.pca)

Invece in python:

>>> from sklearn.decomposition import PCA
[...]
>>> pca = PCA(n_components=2)
>>> pca.fit(x)
PCA(n_components=2)
>>> print(pca.explained_variance_ratio_)
[0.9924... 0.0075...]
>>> print(pca.singular_values_)
[6.30061... 0.54980...]

La differenza tra le due interfacce riguarda sia la sintassi: i nomi delle funzioni che vengono chiamate, diversi nomi e tipi dei parametri, differente inizializzazione, ma anche la semantica della funzionalità in questione, nel senso che essendo l’implementazione sottostante diversa la traduzione del codice potrebbe portare a risultati diversi.

In questo ultimo esempio, devo dire, le due interfacce sono ancora abbastanza compatibili, perché esiste un modo più o meno chiaro di trasformare il codice da R a python. Ci sono casi in cui questo è un procedimento molto complesso, ed infatti, è a mio parere un punto di inefficienza nel moderno lavoro di data analysis, oltre che un punto di facile introduzione degli errori, perché, oltre al modello in se per se, deve essere riscritta anche tutta la pipeline di ETL, cioè tutta la procedura di caricamento, traduzione dei dati, pulitura (ad esempio l’uso delle dummy variables dei modelli di regressione, per intenderci).

Ed è qui che subentra il progetto Dask:

Dask è un progetto open source sostenuto da Anaconda Inc.

Dask è scritto totalmente in python e ha come obiettivo quello di sostituire Apache Spark come tecnologia per la data analysis su big data.
Il suo punto di forza è quello di letteralmente copiare le interfacce delle librerie usate in python per l’analisi dei dati su “small data”, ad esempio, numpy, pandas, scikit-learn ecc.

Banalmente, una volta scritto il codice per un piccolo campione, lo stesso codice può essere facilmente riadattato per grandi moli di dati e può essere eseguito senza troppi sforzi su un cluster di macchine in cloud.

Questo è Dask.

Il mio entusiasmo mi ha portato a contribuire al progetto implementando delle nuove funzionalità, qui un link alla lista delle mie pull request, che verranno rilasciate tra la versione 2.17 e la 2.18 (al momento in cui scrivo).

Per chi fosse interessato nel dettaglio alle funzionalità che ho implementato: qui è possibile trovare una descrizione, in inglese e con allegata dimostrazione matematica di correttezza.