Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Soluzioni distribuite per l’analisi di
dati biomedici in ambientedati biomedici in ambiente
Virtual Data Center
2016/2017
...
Obbiettivi della tesi
Misurare le prestazioni di due applicazioni
distribuite su un V.D.C. reale, così da:
• Individuare g...
Indice
• Virtual Data Center
• Soluzioni Distribuite
• K-mer Counting: il benchmark
• I test e risultati ottenuti• I test ...
Virtual Data Center
Cosa è?
• Virtual Data Center (o I.a.a.S) é una tipologia
di cloud:
– Si può considerare come un clust...
Virtual Data Center
Tecnologie dei server
Tecnologia Convergente Tecnologia Iperconvergente
Per comprendere le prestazioni...
Soluzioni Distribuite
Hadoop
Hadoop è framework per il calcolo distribuito
basato sul paradigma MapReduce e si basa
sulla ...
Soluzioni Distribuite
Spark
Apache Spark è un framework per l’ambiente
distribuito che usa il paradigma DataFlow e sfrutta...
K-mer Counting
Cosa è un k-mer
• Con il termine k-mer ci si riferisce a tutte le possibili
sottostringhe di lunghezza k pr...
K-mer Counting
I Benchmark
I benchmark utilizzati sono applicazioni distribuite per il
conteggio dei k-mer:
• KCH: K-mer c...
Test e analisi dei risultati
Le fasi
• Primi test di scalabilità con Hadoop
• Confronto tra Hadoop e Spark con file da:
– ...
Test e analisi dei risultati
Primi test di scalabilità con Hadoop
Parametri di KCH:
– Input file: 32GB
– Bin: 300
– K: 15 ...
Test e analisi dei risultati
Primi test di scalabilità con Hadoop
200
250
300
350
k15
MediaTempoExec
MediaMap
sec
800
1000...
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...
Test e analisi dei risultati
Primi test di scalabilità con Hadoop
Il throughput medio delle varie fasi decade all’aumento ...
Test e analisi dei risultati
Confronto tra KCH e KCS
• Si sono utilizzati due file contenenti sequenze biologiche di
tipo ...
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
...
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
...
Test e analisi dei risultati
Confronto tra KCH e KCS
File da 32GB – Conclusioni
1. Confronto tra Spark e Hadoop sui tempi:...
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...
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:...
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
D...
Test e analisi dei risultati
Confronto tra KCH e KCS
File da 128GB - Conclusioni
1. KCH soffre da 64 a 128 core: ha un peg...
Test e analisi dei risultati
Confronto tra KCH e KCS
Quale Framework utilizzare (con questo cluster)?
Con K piccoli (k<=15...
Miglioramento dei benchmark
L’idea
• La fase di reduce non fa altro che aggregare i
conteggi dei k-mer presenti nei divers...
Fine!Fine!
Upcoming SlideShare
Loading in …5
×

Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Data Center

1,106 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Data Center

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. Fine!Fine!

×