Risultati dei test di scalabilità di due applicazioni di bio-informatica (conteggio di kmer) sviluppate con Apache Spark e Apache Hadoop. I test sono stati eseguiti su un cloud del GARR. Slide della mia tesi magistrale in Informatica.

1. Soluzioni distribuite per l’analisi di
dati biomedici in ambientedati biomedici in ambiente
Virtual Data Center
2016/2017
RELATORE:
Prof. Giuseppe Cattaneo
CANDIDATO:
Giuseppe Luciano

2. Obbiettivi della tesi
Misurare le prestazioni di due applicazioni
distribuite su un V.D.C. reale, così da:
• Individuare gli strumenti migliori per lo
sviluppo di applicazioni distribuite per isviluppo di applicazioni distribuite per i
BigData
• Stabilire le strategie di implementazione
migliori

3. Indice
• Virtual Data Center
• Soluzioni Distribuite
• K-mer Counting: il benchmark
• I test e risultati ottenuti• I test e risultati ottenuti
• Come migliorare l’algoritmo dei benchmark

4. Virtual Data Center
Cosa è?
• Virtual Data Center (o I.a.a.S) é una tipologia
di cloud:
– Si può considerare come un cluster privato
– E’ un gruppo di Virtual Machine su di una– E’ un gruppo di Virtual Machine su di una
Virtual Network.
• Perché si è diffuso? Costi bassi e elasticità di
espansione

5. Virtual Data Center
Tecnologie dei server
Tecnologia Convergente Tecnologia Iperconvergente
Per comprendere le prestazioni di un VDC bisogna conoscere anche le tecnologie
hardware che lo compongono:
Entrambe le tecnologie hanno la in-memory locality
ma solo l’ipercovergenza ha anche la data locality.

6. Soluzioni Distribuite
Hadoop
Hadoop è framework per il calcolo distribuito
basato sul paradigma MapReduce e si basa
sulla data locality.
Il suo ambiente è composto da diversiIl suo ambiente è composto da diversi
middleware:

7. Soluzioni Distribuite
Spark
Apache Spark è un framework per l’ambiente
distribuito che usa il paradigma DataFlow e sfrutta
al meglio la memoria RAM anche grazie al
serializzatore Kryo.serializzatore Kryo.

8. K-mer Counting
Cosa è un k-mer
• Con il termine k-mer ci si riferisce a tutte le possibili
sottostringhe di lunghezza k presenti in una sequenza
genomica (stringa che rappresenta una sequenza del DNA).
• Il numero di k-mer estratti dalla sequenza cresce
esponenzialmente rispetto al valore k.esponenzialmente rispetto al valore k.
L’evoluzione della tecnologia del sequenziamento

9. K-mer Counting
I Benchmark
I benchmark utilizzati sono applicazioni distribuite per il
conteggio dei k-mer:
• KCH: K-mer counting su Hadoop
• KCS: K-mer counting su Spark
Si basano sul concetto di Bin:Si basano sul concetto di Bin:
• Diverse HashMap per pre-aggregare i k-mer.
• Ogni k-mer va in un solo bin.
• Per usare un numero di reduce a piacimento.
Già testati su una grid dove si è provata la scalabilità.
Ora test in ambiente cloud per verificare:
• Performance
• Problematiche

10. Test e analisi dei risultati
Le fasi
• Primi test di scalabilità con Hadoop
• Confronto tra Hadoop e Spark con file da:
– 32GB
– 128GB
I test sono stati effettuati su un I.a.a.S. fornito dal GARR,
provvisto di 33 VM:
– 128 core
– 1TB di RAM
– 6TB di hard-disk
Dove ogni VM, che gira su KVM, è provvista di:
– 8 core da 2.70 GHz ciascuno
– 32 GB di RAM
– 200GB di VHD

11. Test e analisi dei risultati
Primi test di scalabilità con Hadoop
Parametri di KCH:
– Input file: 32GB
– Bin: 300
– K: 15 e 31
Configurazione di Hadoop:
Un singolo container usa circa
6GB di RAM quando k=31
8slaves: k31 RAM
Configurazione di Hadoop:
– Fattore di replica: 2
– Block-size: 128MB
– SlowStart: 0.75
– 4 container per macchina
Configurazione Cluster:
8, 16 e 32 VM
0
1000000000
2000000000
3000000000
4000000000
5000000000
6000000000
8slaves: k31 RAM
master
slave1
slave2
slave3
slave4
slave5
slave6
slave7
slave8
Tempo (x10)
Byte

12. Test e analisi dei risultati
Primi test di scalabilità con Hadoop
200
250
300
350
k15
MediaTempoExec
MediaMap
sec
800
1000
1200
1400
1600
k31
MediaTempoExec
MediaMap
sec
Risultato: non c’è lo scaling dei tempi!
8 16 32
0
50
100
150
MediaMap
MediaShuffle
MediaReduce
slave
sec
8 16 32
0
200
400
600
800 MediaMap
MediaShuffle
MediaReduce
slave
sec
Aumentano i tempi delle fasi del Map-Reduce all’aumentare delle VM!
Slaves Elapsed Avg map Avg shuffle Avg merge Avg reduce
8 5mins, 29sec 34sec 13sec 0 4sec
8 5mins, 35sec 35sec 13sec 0 4sec
16 4mins, 26sec 48sec 20sec 0 10sec
16 4mins, 24sec 48sec 22sec 0 8sec
32 5mins, 6sec 2mins, 4sec 1mins, 1sec 0 10sec
32 4mins, 58sec 1mins, 43sec 56sec 1sec 20sec

13. Test e analisi dei risultati
Primi test di scalabilità con Hadoop
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
20
40
60
80
%
8slave test1: k15 CPU
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
20
40
60
80
%
32slave test1: k15 CPU
Confronto tra il cluster con 8 slave e 32 slave quando k=15
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
5E+09
1E+10
1,5E+10
32slave test1: k15 RAM
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
50000000
100000000
150000000
Byte/sec
32slave test1: k15 DiskWrite
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
5E+09
1E+10
1,5E+10
Byte
8slave test1: k15 RAM
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0
100000000
200000000
300000000
400000000
Byte/sec
8Slave test1 : k15 DiskWrite

14. Test e analisi dei risultati
Primi test di scalabilità con Hadoop
Il throughput medio delle varie fasi decade all’aumento delle VM utilizzate:
Throughtput medio k15 8 slave 16 slave 32 slave
Lettura dal disco 1,6MB/s 1,0MB/s 0,7MB/s
Scrittura sul disco 36MB/s 22MB/s 12MB/s
Lettura dalla rete 26MB/s 17MB/s 8,1MB/s
Scrittura sulla rete 23MB/s 17MB/s 8,1MB/s
Possibile spiegazione per l’aumento dei tempi delle fasi intermedie:
L’ I/O rallenti troppo e non fa scalare l’applicazione.
Throughtput medio k31 8 slave 16 slave 32 slave
Lettura dal disco 15MB/s 2,8MB/s 5MB/s
Scrittura sul disco 59MB/s 28MB/s 13MB/s
Lettura dalla rete 30MB/s 15MB/s 7,3MB/s
Scrittura sulla rete 30MB/s 15MB/s 7,3MB/s
Condivisione del hardware fisico

15. Test e analisi dei risultati
Confronto tra KCH e KCS
• Si sono utilizzati due file contenenti sequenze biologiche di
tipo short da:
– 32GB
– 128GB
• Si sono usati i valori di K: 10, 15, 20, 25 e 30• Si sono usati i valori di K: 10, 15, 20, 25 e 30
– Varia la quantità dei dati generati:
• Nei risultati ho considerato il numero di core totali utilizzati e
non le VM:
– Ogni container utilizza un core.
K File intermedi di Spark File intermedi di Hadoop Output finale
K10 3.2GB 4GB 8.9MB
K15 260GB 326GB 9GB
K20 377GB 584GB 184GB
K25 435GB 568GB 269GB
K30 483GB 542GB 339GB

16. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 32GB – k=10
00:14:24
00:17:17
00:20:10
00:23:02
00:25:55
K10
4 8 16 32 64 128
00:00:00
00:02:53
00:05:46
00:08:38
00:11:31
00:14:24
tempoSpark
tempoHadoop
Core
Tempo
Core Rapporto Hadoop/Spark
4 6,93
8 3,91
16 3,32
32 2,47
64 1,85
128 1,07
Core
Tempo
Spark
Fattore di
scala
Tempo
Hadoop
Fattore di
scala
4 00:03:30 00:24:16
8 00:02:18 1,52 00:08:59 2,70
16 00:01:30 1,53 00:04:59 1,80
32 00:00:55 1,64 00:02:16 2,20
64 00:00:47 1,17 00:01:27 1,56
128 00:01:00 0,78 00:01:04 1,36

17. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 32GB – k=30
01:26:24
01:40:48
01:55:12
02:09:36
02:24:00
K30
Da K=15 a K=30 il comportamento dei tempi è simile
4 8 16 32 64 128
00:00:00
00:14:24
00:28:48
00:43:12
00:57:36
01:12:00
01:26:24
tempoSpark
tempoHadoop
Core
Tempo
Core Rapporto Spark/Hadoop
4 1,36
8 1,81
16 1,87
32 1,63
64 1,29
128 1,09
Core
Tempo
Spark
Fattore di
scala
Tempo
Hadoop
Fattore di
scala
4 02:06:00 01:32:30
8 01:06:00 1,91 00:36:22 2,54
16 00:36:00 1,83 00:19:13 1,89
32 00:21:00 1,71 00:12:52 1,49
64 00:14:00 1,50 00:10:49 1,19
128 00:12:00 1,17 00:11:01 0,98

18. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 32GB – Conclusioni
1. Confronto tra Spark e Hadoop sui tempi:
– K<=10: Spark è più veloce
– K>10: Hadoop è più veloce
2. Analizzando lo scaling:
– Spark diminuisce sempre i tempi all’aumentare dei core
– Hadoop inizialmente lo fa meglio, ma da 64 a 128 core diventa
negativo
Scaling Spark k10 k15 k20 k25 k30 Media
4-8 1,52 1,88 1,92 1,90 1,91 1,83
8-16 1,53 1,92 1,83 1,76 1,83 1,78
16-32 1,64 1,67 1,81 2,00 1,71 1,77
32-64 1,17 1,70 1,45 1,42 1,50 1,45
64-128 0,78 1,17 1,34 1,26 1,17 1,15
Scaling Hadoop k10 k15 k20 k25 k30 Media
4-8 2,70 2,27 2,16 2,63 2,54 2,46
8-16 1,80 1,86 1,71 1,80 1,89 1,81
16-32 2,20 1,89 1,50 1,64 1,49 1,74
32-64 1,56 1,30 1,31 1,11 1,19 1,29
64-128 1,36 1,00 0,93 1,01 0,98 1,06
Unico caso per Spark
Tabelle di riepilogo dei risultati

19. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 128GB – Setup
• Si sono usate solo 16 e 32 VM
• Si sono usate come block-size: 128MB e 512MB
• Si è usato bin=301: si distribuisce meglio il carico nei
reduce quando la block-size è 512MB

20. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 128GB – K=10
00:14:24
00:17:17
00:20:10
00:23:02
00:25:55
00:28:48
Tempo
K10
Spark128m
K=10 e K=15 hanno un comportamento simile dei tempi
Il tempo migliore di Spark è il 40% più veloce di quello Hadoop
00:00:00
00:02:53
00:05:46
00:08:38
00:11:31
00:14:24
16 32 64 128
Tempo
Core
Spark128m
Spark512m
Hadoop128m
Hadoop512m
Core Spark128m Spark512m Hadoop128m Hadoop512m
16 00:04:08 00:04:18 00:24:59 00:12:17
32 00:02:48 00:02:48 00:10:11 00:05:10
64 00:02:24 00:02:00 00:04:35 00:03:01
128 00:01:54 00:02:06 00:03:15 00:02:39
Fattore di scaling
Scaling Spark128m Spark512m Hadoop128m Hadoop512m
16-32 1,48 1,54 2,45 2,38
32-64 1,17 1,40 2,22 1,71
64-128 1,26 0,95 1,41 1,14

21. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 128GB – K=30
03:36:00
04:48:00
06:00:00
Tempo
K30
Spark128m
Da K=20 a K=30 il comportamento dei tempi è simile
00:00:00
01:12:00
02:24:00
16 32 64 128
Tempo
Core
Spark512m
Hadoop128m
Hadoop512m
Core Spark128m Spark512m Hadoop128m Hadoop512m
16 01:54:00 05:30:00 01:19:33 01:30:15
32 01:06:00 03:00:00 01:03:29 01:00:56
64 00:44:00 01:42:00 00:46:04 00:59:55
128 00:37:00 01:30:00 00:49:03 01:03:13
Fattore di scaling
Scaling Spark128m Spark512m Hadoop128m Hadoop512m
16-32 1,73 1,83 1,25 1,48
32-64 1,50 1,76 1,38 1,02
64-128 1,19 1,13 0,94 0,95
Il tempo migliore di Spark è 27% più veloce di quello Hadoop

22. Test e analisi dei risultati
Confronto tra KCH e KCS
File da 128GB - Conclusioni
1. KCH soffre da 64 a 128 core: ha un peggioramento dei tempi di
esecuzione da k=20.
2. KCS scala sempre e quando usa 128 core ha i tempi migliori in2. KCS scala sempre e quando usa 128 core ha i tempi migliori in
assoluto.
3. Considerando i tempi:
- k<=15: il tempo migliore di Spark è il 40% più veloce di quello Hadoop.
- k>15: la differenza tra i tempi migliori si abbassa al 34%.
4. Per quanto riguarda I/O:
L’abbassamento del throughput sul cluster non dipende dal numero delle
VM, ma dal numero di processi che utilizzano l’ I/O del disco e della rete.

23. Test e analisi dei risultati
Confronto tra KCH e KCS
Quale Framework utilizzare (con questo cluster)?
Con K piccoli (k<=15) è meglio usare:
• Una block-size grande.
• Spark: ha le prestazioni migliori in ogni configurazione.
Con K grandi (k>15) è meglio usare la block-size a 128MB e :
 File grandi: Spark
 File piccoli: Hadoop con non più di a 64 core

24. Miglioramento dei benchmark
L’idea
• La fase di reduce non fa altro che aggregare i
conteggi dei k-mer presenti nei diversi Bin.
• Si potrebbe migliorare usando una HashMap
Distribuita per l’aggregazione globale dei conteggi.Distribuita per l’aggregazione globale dei conteggi.
• Possibili Middleware:
– Apache HBase
– Apache Ignite
– Spark Alluxio

25. Fine!Fine!