Risultati sui volumi di dati

Come precisato nel capitolo precedente il modello si focalizza principalmente sui tempi che riguardano la lettura da disco e l’invio di dati sulla rete. Risulta prima di tutto fondamentale testare tali quantità di dati. Sono presenti 3 principali fasi in cui risulta necessario valutare tali quantità:

 dati letti dal disco  dati scritti in shuffle write  dati letti in shuffle read

68

In tutti i casi i dati a cui si fa riferimento sono valori aggregati cioè la somma dei dati letti o scritti da tutti i task di tutti gli executor. Per quanto riguarda i parametri di Spark sono stati specificati in questo modo:

 spark.driver.memory = 15Gb  spark.executor.memory = 20Gb  spark.shuffle.compress = “False”

I valori di memoria del driver e degli executor sono stati impostati vicino al valore massimo che poteva essere utilizzato per diminuire la possibilità di incorrere in fail dei task. Per quanto riguarda invece la compressione è stata impostata a false per far si che le valutazioni possano essere più precise non dovendo considerare un fattore di compressione che può dipendere dal tipo di dati inviati.

Come detto precedentemente la valutazione degli RDD in Spark è lazy e quindi solo se è presente una action alla fine le richieste vengono realmente elaborate. Per questo ogni volta che si effettua una query si richiede di creare una tabella sul database di modo che tale richiesta forzi l’elaborazione dell’RDD (Create table tmp as select ….) per andare a scrivere il risultato della query su di una tabella temporanea.

Per quanto riguarda invece il calcolo della dimensione delle tuple ci si è basati su dati ricavati da diversi test:

 FixedTupleSize: 211 nel caso di shuffle join, 40 nel caso di group by  FixedTypeSize: 60 nel caso di shuffle join, 0 nel caso di group by

4.2.1 Dati letti dal disco

Consideriamo inizialmente la quantità di dati letti durante lo scan di una tabella (nei test è stata utilizzata la fact table) e come tali quantità variano al variare degli attributi selezionati eseguendo la seguente query:

SELECT Chiave0 FROM Ft

Partendo da questa query si sono poi aggiunti altri campi nella selezione (Chiave1,Misura0,ChiaveDt). Questo perché la tabella considerata risulta essere in formato parquet e quindi colonnare; questo ci permette di andare a leggere solamente le colonne che ci interessano e non tutte le tuple per intero permettendoci di valutare la correttezza della formula impostata precedentemente. Di seguito i risultati sperimentali dell’esecuzione di tale query:

Risultati sperimentali 69

69

Figura 39 Confronto sulla quantità di dati letti in fase di scan

Come si può osservare i valori attesi e quelli osservati risultano essere molto simili fino ad essere ovviamente uguali nel caso in cui si prelevi tutta la tabella. Si può anche osservare come ci sia un forte sbalzo tra il caso con 2 attributi e quello con 3 (così come tra 3 e 4). Questo risulta semplicemente dovuto al fatto che sono stati aggiunti in selezione attributi di tipo double (o long nel caso 4) i quali, essendo modellati con 8 byte invece che 4 come gli int (caso dei primi due attributi), risultano avere un volume maggiore. Non si sono considerati casi con filtro dato che in ogni caso per il comportamento di Spark esso sarebbe stato valutato in una fase successiva dal task lasciando quindi invariati le quantità di dati letti.

4.2.2 Dati scritti in shuffle write

Consideriamo ora la quantità di dati che devono essere scritti in shuffle write nei casi in cui sia necessario un invio di dati sulla rete. In questo caso dobbiamo fare una distinzione tra la valutazione del join e la valutazione del group by dato che sono state fatte considerazioni differenti. Nel caso di join eseguiamo la seguente query:

SELECT f.Chiave0 FROM Ft as f, Dt as d

WHERE f.Chiave0<100000000 AND d.ChiaveDt<20000000AND f.ChaiveDt=d.ChiaveDt

3814,4 7628,8 15257,6 22886,4 3788,8 7680 15257,6 22886,4 0 5000 10000 15000 20000 25000 1 2 3 4 M e gab yte

Numero di attributi selezionati

Lettura dati

Modello Test

70

E’stato anche inserito un filtro per evitare che la quantità di dati scritti in shuffle write risulti essere eccessiva a causa del mancato utilizzo della compressione, in ogni caso si è osservato che la quantità di dati scritti in shuffle write cambia in maniera direttamente proporzionale rispetto al filtro. Anche in questo caso valutiamo come si comportano i dati all’aumentare degli attributi selezionati (Chiave1,Misura0,Attributo0).

Figura 40 Confronto sulla quantità di dati scritti in shuffle write in caso di join

Anche in questo caso si può osservare come i valori del modello e quelli osservati siano molto vicini. Al contrario della lettura da disco all’aumentare degli attributi selezionati la quantità di dati non aumenta allo stesso modo ma più lentamente. Questo è dovuto al fatto che i dati scritti essendo prima serializzati non aumentano in maniera rilevante se viene aggiunto un attributo dello stesso tipo del precedente risulta essere più rilevante invece il caso in cui l’attributo aggiunto sia di tipo diverso ma partendo comunque da una base comune di FixedTupleSize piuttosto elevata risulta incidere poco sul valore finale.

Passando invece al caso del group by si deve considerare come vari la quantità di dati scritti al variare del numero di valori distinti dell’attributo di group by. I test sono stati quindi effettuati sulla dimension table nella quale sono presenti attributi con quantità di valori distinti differenti considerando la seguente query:

SELECT Attributo0 FROM dtuniforme100m GROUP BY Attributo0 16'947 17'142 19'999 21'146 16'896 17'203 20'378 21'606 0 5'000 10'000 15'000 20'000 25'000 1 2 3 4 Gi gab yte

Numero di attributi selezioanti

Shuffle Write Join

SW Modello SW Test

Risultati sperimentali 71

71

In ogni test si è quindi modificato l’attributo di group by per osservare se la quantità di dati scalasse correttamente

Figura 41 Confronto sulla quantità di dati scritti in shuffle write nel caso di group by

In base al numero di gruppi creati la quantità di dati può variare di molto passando da pochi Kilobyte a diversi Gigabyte per questo è stata utilizzata una scala logaritmica. In ogni caso si può osservare come i dati del modello e quelli osservati scalino allo stesso modo all’aumentare del numero di gruppi considerati.

4.2.3 Dati letti in shuffle read

Dopo che uno stage ha scritto i dati in shuffle write lo stage successivo li andrà a leggere e tale quantità sarà definita come shuffle read. Ovviamente la quantità di dati in shuffle write coincide con la quantità in shuffle read ma si deve comunque considerare che una parte viene letta in locale e una parte viene invece letta dai nodi remoti (se si utilizza più di un executor). Per confrontare tale quantità quindi si è considerata la stessa query utilizzata per la valutazione dello shuffle write nel caso del join ma eseguendola con diversi executor per osservare se all’aumentare degli executor anche la quantità di dati letti da nodi remoti aumenti. Di seguito i risultati dei test:

2,77 27,73 277 2'775 27'740 277'340 2'095'104 2,80 27,70 290 3'072 31'744 330'854 2'516'582 1,00 10,00 100,00 1000,00 10000,00 100000,00 1000000,00 10000000,00 1 10 100 1000 10000 100000 1000000 K ilo b yte

Numero di valori distinti dell'attributo di group by

Shuffle Write Group By

SW Modello SW Test

72

Figura 42 Confronto sulla quantità di dati letti in shuffle read utilizzando più executor

Come si può osservare le quantità di dati sperimentali e calcolati sono molto vicine. Si evidenzia un piccolo scostamento verso il basso dei valori calcolati dal modello ma questo è dovuto al fatto che la quantità di dati in shuffle write calcolata risulta essere di 20,46 Gb mentre quella sperimentale di 20,7 Gb