analisi di sequenze genomiche e proteomiche utilizzando Hadoop 2
annuncio pubblicitario
Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali Dipartimento di Informatica Laboratorio di Sistemi Operativi II FASTA MapReduce: analisi di sequenze genomiche e proteomiche utilizzando Hadoop 2 Professore Prof. Giuseppe Cattaneo Dott. Gianluca Roscigno Studenti Francesco Farina Marco Amoruso Anno Accademico 2013-2014 Abstract In questo documento, è presentata un’applicazione il cui scopo è allineare sequenze genomiche e proteomiche avvalendosi di algoritmi di Pairwise alignment. Tale software, realizzato per sfruttare il framework Apache Hadoop [2] si basa su FASTA [1]. L’allineamento di sequenze, rappresentate come una successione di caratteri, è elaborato grazie alla potenza computazionale di una griglia in maniera da poter confrontare un vasto numero di genomi con uno di riferimento. I Indice 1 Introduzione 1.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 Analisi preliminare 2.1 Pairwise alignment . . . . . . . . 2.2 Smith-Waterman . . . . . . . . . 2.3 Algoritmi euristici . . . . . . . . . 2.3.1 FASTA . . . . . . . . . . . 2.3.1.1 Algoritmo . . . . 2.3.1.2 Formato FASTA . . . . . . 3 3 4 5 6 6 8 . . . . . . 9 9 9 10 11 11 12 . . . . . . 13 13 14 16 17 18 20 . . . . . . . 21 21 22 23 26 26 28 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 FASTA per Hadoop 3.1 Soluzioni proposte . . . . . . . . . . . . . . 3.1.1 Porting di FASTA in Java . . . . . . 3.1.2 Implementazione di JFASTA . . . . . 3.2 Soluzione adottata . . . . . . . . . . . . . . 3.2.1 Pro e contro della soluzione adottata 3.2.2 FASTA Benchmark . . . . . . . . . 4 Implementazione Map-Reduce 4.1 Overview . . . . . . . . . . . . 4.2 Dettagli implementativi . . . 4.2.1 Inizializzazione . . . . 4.2.2 Fase di Map . . . . . . 4.2.3 Fase di Reduce . . . . 4.2.4 Risultato finale . . . . 5 Tests e Benchmarking 5.1 Configurazione di test . . . . 5.2 Il tool utilizzato per le analisi 5.3 Benchmark . . . . . . . . . . 5.3.1 Tempi di esecuzione . . 5.3.2 CPU . . . . . . . . . . 5.3.3 RAM . . . . . . . . . . 5.3.4 Disco . . . . . . . . . . . . . . . . . . . . . . . II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INDICE III 5.3.5 5.3.6 5.3.7 5.3.4.1 Lettura . . . . . . . . 5.3.4.2 Scrittura . . . . . . . Pacchetti di Rete e Throughput 5.3.5.1 IN . . . . . . . . . . . 5.3.5.2 OUT . . . . . . . . . . Anomalia riscontrata . . . . . . Analisi Prestazione . . . . . . . 5.3.7.1 Speedup . . . . . . . . 5.3.7.2 Efficienza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32 33 34 36 38 39 39 40 6 Conclusioni 42 Bibliografia 43 A Appendice 44 A.1 Link al codice sorgente . . . . . . . . . . . . . . . . . . . . . . . . . 44 Capitolo 1 Introduzione In questo documento si presenta l’utilizzo di Apache Hadoop applicato al campo della bioinformatica. In particolare, viene affrontato il problema del pairwise alignment di sequenze di DNA o proteine mediante algoritmi ad hoc, i quali necessitano di enorme potenza di calcolo e tempi di esecuzione molto lunghi. Il problema dell’allineamento di sequenze di DNA e di proteine deriva dalla necessità di confrontare e misurare la similarità di due o più sequenze, determinando un allineamento ottimale fra tutti i numerosi possibili allineamenti. In generale, essendo la natura conservativa, nel caso in cui una sequenza risulti essere somigliante a quella di un nucleotide o di una proteina, di cui è noto il comportamento, allora si è in grado di attribuire, alla sequenza in questione, una funzione identica oppure simile. Numerose sono le motivazioni per il confronto di tali sequenze [3], ad esempio: • determinare caratteristiche fisiche e genetiche a partire da sonde di rilevamento; • trovare nuovi elementi informativi in proteine e sequenze di DNA; • attribuire un ruolo ad un frammento clonato di DNA in un sistema, comparandolo con segmenti contenuti in banche di dati; • identificare l’identità di un assassino, attraverso il confronto del DNA con quello dei possibili sospetti. Per quanto riguarda lavori di ricerca e non solo, il problema dell’allineamento di sequenze può rappresentare la consuetudine. 1 Capitolo 1: Introduzione 2 Questo tipo di analisi, da un punto di vista prettamente informatico, risulta essere estremamente oneroso ed incide fortemente sui tempi necessari per ottenere i risultati richiesti, con conseguente impennate dei costi relativi all’intero processo. 1.1 Obiettivi Lo scopo di questo progetto è quello di velocizzare il processo di analisi di sequenze di genomi, mediante l’uso del paradigma Map-Reduce. Tale problema sarà analizzato in base ai vari approcci ed algoritmi che lo risolvono, al fine di valutarne la parallelizzabilità, in modo tale da poter utilizzare al meglio il cluster Hadoop a disposizione, composto da commodity hardware. Infine, saranno confrontate la soluzione già esistente con quella proposta in questo progetto, al fine di valutare il grado di bontà della soluzione stessa e la percentuale di speed-up che essa apporta. Capitolo 2 Analisi preliminare In questo capitolo si illustrano alcuni algoritmi, atti alla risoluzione delle problematiche accennate nel capitolo precedente, considerati per il calcolo del pairwise alignment, mediante Apache Hadoop. 2.1 Pairwise alignment Innanzitutto, per pairwise sequence alignment si intende il processo di allineamento di due sequenze al fine di ottenere i massimi livelli di identità, per poter stabilire un determinato grado di similarità. L’allineamento di sequenze molto brevi è semplice e può essere fatto da un essere umano. Tuttavia la maggior parte dei problemi interessanti richiedono l’allineamento di sequenze lunghe, che non possono essere allineate unicamente dall’uomo. Infatti, l’allineamento ottimale di due sequenze entrambe di lunghezza n è uno fra tutti i diversi possibili allinea1 2 menti, ovvero 2n che è approssimativamente pari a 2n . Quindi la conoscenza n umana è applicata nella costruzione di algoritmi in grado di produrre allineamenti di sequenze di alta qualità. In generale, gli approcci per l’allineamento di sequenze dal punto di vista computazionale si dividono in due categorie: globale e locale. Diversi algoritmi si basano su tali approcci ed utilizzano un sistema di scoring, che assegna dei punteggi necessari per il calcolo dell’allineamento di due sequenze. Tali algoritmi includono lenti ma corretti metodi, come di programmazione dinamica, ed efficienti algoritmi euristici o probabilistici che non garantiscono un risultato ottimo. Di seguito vengono presentati alcuni algoritmi e sistemi considerati per il calcolo dell’allineamento di sequenze, mediante l’utilizzo di Apache Hadoop. 3 Capitolo 2: Analisi preliminare 4 Più in dettaglio, vengono introdotti: • Smith-Waterman, algoritmo di programmazione dinamica; • BLAST e FASTA, algoritmi e strumenti basati su metodi euristici. 2.2 Smith-Waterman L’algoritmo di Smith-Waterman [4], proposto da Temple F. Smith e Michael S. Waterman nel 1981, sfrutta un approccio locale per l’allineamento di sequenze. In questo modo, piuttosto che considerare le sequenze nella loro interezza, l’algoritmo confronta segmenti di tutte le possibili lunghezze ed è in grado di trovare l’allineamento ottimale, rispetto al sistema di scoring utilizzato: • matrice di sostituzione, contenente gli score associati ad ogni coppia di caratteri presenti nelle sequenze, in cui per il confronto di due caratteri a e b, s(a, b) indica lo score ad esso associato; • schema di gap-scoring, che introduce un gap penality per ridurre lo score, ogni qualvolta vengono inseriti gap. L’algoritmo di Smith-Waterman, date due sequenze x ed y di lunghezza n ed m, costruisce una matrice F di dimensione n ú m, dove F (i, j), con i=1..n ed j=1..m, indica lo score locale della sottosequenza corrente. Inizialmente l’algoritmo pone F (0, 0) a 0 e successivamente procede a riempire ricorsivamente F (i, j) dall’angolo in alto a sinistra verso quello in basso a destra, con il massimo fra i seguenti valori: 1. F (i, j) = 0, corrisponde a considerare un nuovo allineamento; 2. F (i, j) = F (i ≠ 1, j ≠ 1) + s(xi , yj ), caso in cui xi , yj possono essere allineate; 3. F (i, j) = F (i ≠ 1, j) – gap penalty, caso in cui xi è allineata ad un gap; 4. F (i, j) = F (i, j ≠ 1) – gap penalty, caso in cui yj è allineata ad un gap. Per ogni F (i, j), l’algoritmo tiene traccia della cella da cui si è derivato il suo valore. Una volta riempita la matrice F, a partire dal valore F (i, j) contenente Capitolo 2: Analisi preliminare 5 lo score massimo, l’algoritmo esegue traceback, ovvero costruisce l’allineamento a partire da tale cella e seguendo i riferimenti alle celle, i quali hanno portato a tale cella. Ad ogni passo il processo di traceback si muove dalla cella corrente (i, j) verso una fra (i ≠ 1, j ≠ 1), (i ≠ 1, j) o (i, j ≠ 1), aggiungendo i simboli associati alle celle all’allineamento finale, fino al raggiungimento di una cella contenente il valore 0, il quale rappresenta l’inizio dell’allineamento. La complessità di spazio dell’algoritmo è pari a O(m ú n), in quanto costruisce e riempe una matrice di dimensioni n ú m, e la stessa complessità in termini di tempo, dovuta al processo di riempimento della matrice con tutti gli score, F (i, j). Questo equivale a dire che, per poter confrontare due sequenze, che occupano entrambe 5MB, e calcolarne l’allineamento ottimo, sarebbe necessario uno spazio in memoria pari al prodotto fra il valore in byte delle sequenze con la rappresentazione in byte di un intero, ovvero circa: 5000000 ú 5000000 ú 4 byte = 100TB. Quindi risulta impraticabile utilizzando commodity hardware, poter memorizzare la matrice sia sul disco che in RAM sulla macchina. Inoltre, non è possibile suddividere la matrice in blocchi ed analizzare ogni blocco singolarmente, in quanto il calcolo dello score di F (i, j) coinvolge anche i valori F (i≠1, j ≠1), F (i≠1, j) e F (i, j ≠ 1), che potrebbero appartenere ad altri blocchi; in tale situazione sarebbe necessario mantenersi in memoria o sul disco tutti i blocchi, ritornando così al problema di partenza. Per cui, per poter confrontare tali sequenze bisogna cambiare approccio, utilizzare un algoritmo euristico. 2.3 Algoritmi euristici Un altro approccio per il calcolo dell’allineamento di due sequenze è basato su k-tuple o word. Tale approccio si basa su algoritmi euristici che non garantiscono come risultato un allineamento ottimo, ma sono algoritmi molto più efficienti rispetto a quelli di programmazione dinamica. Questi metodi, in generale, identificano una serie di brevi e non sovrapposte sottosequenze (word) a partire da una sequenza, le quali vengono poi confrontate con altre parole candidate dell’altra sequenza. Le relative posizioni di queste word nelle due sequenze vengono sottratte per ottenere un offset, il quale indicherà una regione di allineamento, nel caso in cui più parole distinte producono lo stesso offset. Solamente se queste regioni vengono rilevate, viene applicato un criterio di allineamento più accurato; ciò elimina Capitolo 2: Analisi preliminare 6 la necessità di confrontare sottosequenze che non appaiono simili. BLAST e FASTA sono i tool di ricerca, basati su database, più conosciuti che utilizzano tale approccio. Entrambi i sistemi utilizzano un’approssimazione dell’algoritmo di Smith-Waterman e si basano sulla definizione di un determinato k, che indica la lunghezza delle sottosequenze o parole. La differenza sostanziale fra i due è che BLAST risulta essere più ottimizzato, in quanto analizza solamente le parole che hanno un match più significativo, a differenza di FASTA. Non essendo disponibile codice sorgente in Java, la scelta dell’algoritmo sul quale basarsi e su cui costruire l’implementazione è ricaduta sull’algoritmo utilizzato da FASTA, in quanto risulta essere una strada praticabile nel tempo a disposizione, rispetto all’implementazione dell’algoritmo di BLAST, il quale utilizza metodi complessi di matematica e statistica. 2.3.1 FASTA L’algoritmo di FASTA venne progettato nel 1985 da Lipman e Pearson. A partire da due sequenze, denominate come query sequence e database sequence di lunghezza rispettivamente n ed m, FASTA approssima l’allineamento ottimale cercando e riscontrando le k-tuple (match). L’algoritmo assume che sequenze relate avranno regioni somiglianti, e cercando mediante k-tuple, FASTA è in grado di trovare rapidamente piccole regioni identiche localmente. 2.3.1.1 Algoritmo L’algoritmo di FASTA [6] [7] è composto da diverse fasi: 1. FASTA crea una hash table di tutte le possibili k-tuple, attraversa l’intera query sequence e pone nella tabella le posizioni di tutte le possibili k-tuple. Ogni k-tupla nella database sequence viene ricercata nella hash table ed, ad ogni match l’algoritmo contrassegna le celle in cui questo si è verificato. Quindi l’algoritmo nella prima fase determina tutti i match di lunghezza k fra le due sequenze, chiamati hot-spots. Un hot-spot è dato dalla coppia (i, j), dove i e j sono le posizioni iniziali di un match di lunghezza k. Ogni hot-spot (i, j) giace sulla diagonale (i ≠ j) della matrice, che si avrebbe nel caso di programmazione dinamica. Utilizzando tale schema, la diagonale Capitolo 2: Analisi preliminare 7 principale ha come identificativo 0 (i = j), mentre le diagonali al di sopra della principale possiedono un identificativo positivo (i>j) e quelle al di sotto negativo (i<j). Una diagonal run è un insieme di hot-spot, che si trovano in una sequenza consecutiva sulla stessa diagonale ed ad ognuna di esse è assegnato uno score. 2. L’algoritmo ricava le dieci diagonal run con lo score maggiore, identificando ogni punto della matrice marcato, ed aggiungendo uno score positivo per ogni altra cella contrassegnata sulla diagonale, sottraendo invece una penalità per ogni cella non contrassegnata. Questi dieci migliori segmenti vengono conservati, mentre tutti i restanti vengono scartati. 3. A questo punto viene assegnato nuovamente uno score ad ognuna delle dieci diagonali, mediante una matrice di sostituzione (PAM o BLOSUM ), ed ogni diagonale con uno score inferiore ad una determinata soglia viene scartata. La diagonale con il migliore score viene denominata come init1. 4. L’algoritmo calcola gli score dell’unione di ogni possibile combinazione di diagonali adiacenti. Per calcolare lo score di una serie di unioni di diagonali, gli score di ogni diagonale vengono sommati, ed una costante di penalità viene sottratta ogni qualvolta due sottosequenze vengono unite con un gap. Tutti gli allineamenti con uno score al di sotto di una determinata soglia vengono scartati. 5. L’algoritmo definisce una diagonale avente una determinata larghezza, costruita attorno alla diagonale init1. FASTA assume che l’allineamento ottimo includerà o sarà vicino alla diagonale init1. 6. Infine, viene applicato Smith-Waterman su tale diagonale per trovare l’allineamento finale delle due sequenze. Sebbene l’algoritmo di FASTA sia molto più veloce degli algoritmi di programmazione dinamica, non garantisce come risultato l’allineamento ottimo fra due sequenze. Poiché usa le k-tuple per accelerare i calcoli, l’algoritmo può non considerare piccole aree di similarità e quindi vi è la possibilità di un disallineamento fra le due sequenze. Inoltre, limitando la larghezza dell’area di lavoro dell’algoritmo di programmazione dinamica, l’algoritmo di FASTA può produrre un allineamento non ottimale. Questo è chiaramente un trade-off fra velocità ed accuratezza. Capitolo 2: Analisi preliminare 2.3.1.2 8 Formato FASTA Il tool FASTA ha originato un formato standard per la rappresentazione standard nel campo della bioinformatica [8]. In tale formato testuale, una sequenza inizia con una descrizione sulla prima linea del file, ed a seguire le linee che rappresentano i dati della sequenza. La descrizione viene disambiguata attraverso il simbolo > all’inizio della prima riga. Nella figura in basso viene mostrata una sequenza in formato FASTA. Figura 2.1 Capitolo 3 FASTA per Hadoop L’implementazione dell’algoritmo FASTA per Hadoop si è evoluta attraverso più fasi, alcune delle quali, pur essendosi rivelate fallimentari, sono comunque servite a produrre un’implementazione corretta ed efficace, nonostante i trade-off a cui ci si è dovuti adattare. 3.1 3.1.1 Soluzioni proposte Porting di FASTA in Java Il primo approccio per eseguire l’algoritmo FASTA sul framework Hadoop è stato un tentativo di porting dell’algoritmo stesso dal linguaggio C, in cui è originariamente implementato, a Java. Essendo il codice sorgente disponibile [5], si è partiti con una analisi statica, in modo da poter individuare le componenti chiave, per poi rappresentarle nella versione Java. Attraverso tale analisi, sono sorte diverse problematiche relative: • scarsa presenza di commenti all’interno del sorgente, rendendo così difficile la comprensione della semantica del codice; • un elevato numero di file (96), così come la dimensione media dei file (migliaia di loc), causa un estremamente oneroso lavoro di porting dell’applicazione. • la natura del codice, intrinsecamente parallela ed ottimizzata, complica l’estrapolazione delle funzionalità. 9 Capitolo 3: FASTA per Hadoop 10 Tali problematiche hanno portato a cambiare approccio implementativo, ovvero utilizzare il codice sorgente di FASTA, attraverso la tecnologia JNI. Ma anche tale soluzione è stata scartata, a causa della natura del codice sorgente, ovvero un programma eseguibile. Infatti, JNI si basa principalmente sul richiamo di librerie e non di programmi eseguibili. A questo punto, scartate le ipotesi discusse in precedenza, si è scelto di implementare l’algoritmo, attraverso le linee fornite dallo pseudo-codice 2.3.1.1. 3.1.2 Implementazione di JFASTA La realizzazione dell’algoritmo in Java è iniziata senza una base di partenza, in termini di codice, ed è proseguita solamente seguendo i passi forniti dallo pseudocodice. In tale processo, si è posta particolare attenzione verso l’utilizzo delle risorse, in modo da ottimizzare il codice e soprattutto alla deallocazione delle risorse non più utili, per essere in grado di prevenire sprechi di memoria, considerando la già elevata complessità in termini di spazio dell’algoritmo. Al termine dell’implementazione, si è testato il risultato, JFASTA su diverse macchine aventi cpu Intel I7 quad-core con Hyperthreading, operante alla frequenza di 2.8 Ghz e 8 GB di RAM DDR3 a 1333MH. I tempi di esecuzione dell’algoritmo su input di sequenze di DNA pari a 500 KB sono stati di 59 sec circa, con un utilizzo della memoria, però, nei momenti di picco massimo, pari a 1.2GB circa. Lo stesso test è stato ripetuto poi su diverse macchine appartenenti al cluster Hadoop messo a disposizione per il progetto, dotate di cpu Celeron dual-core con frequenza di 2,4GHz con 4GB di memoria RAM DDR2 667MHz. Il test reale è avvenuto, però, all’interno delle macchine virtuali installate sui suddetti computer, alle quali sono allocati soltanto 3GB di RAM. L’esecuzione dell’implementazione di JFASTA in tale ambiente purtroppo non ha dato risultati. Questo è dovuto, secondo varie analisi, a due fattori: • le scarse risorse a disposizione delle macchine, che come è noto appartengono ad un cluster con commodity hardware; • l’implementazione di JFASTA essendo strettamente sequenziale, risulta essere poco efficiente in confronto all’implementazione originale dell’algoritmo, che fa uso di istruzioni SSE ed un massiccio utilizzo di parallelizzazione di basso livello. Capitolo 3: FASTA per Hadoop 11 L’implementazione di JFASTA, è comunque reperibile all’indirizzo https://github. com/indiependente/jfasta.git. A seguito di tali considerazioni, si è scelto di scartare anche questa soluzione, in quanto inutilizzabile ai fini del progetto. 3.2 Soluzione adottata Dopo le difficoltà di creare un’implementazione dell’algoritmo in questione, la soluzione adottata, a fronte dei diversi tentativi di realizzare una versione Java dell’algoritmo di FASTA, è stata frutto di diverse analisi che hanno portato alla scelta di utilizzare l’implementazione originale. Data la necessità di utilizzare in ambiente Hadoop un programma scritto in Java e vista la scelta di utilizzare l’implementazione di FASTA in C, si è deciso di implementare un semplice wrapper in Java che, mediante la classe ProcessBuilder, permettesse di richiamare e lanciare un file eseguibile. 3.2.1 Pro e contro della soluzione adottata La scelta di utilizzare l’implementazione originale di FASTA, attraverso un wrapper Java, ha portato ad alcuni trade-off, i quali vengono elencati ed analizzati di seguito: • Vantaggi – l’utilizzo di una componente off-the-shelf, efficiente ed efficace, libera risorse utilizzabili per altri task del progetto. – l’implementazione estremamente efficace, realizzata mediante istruzioni SSE e tecniche di parallelismo a basso livello, permette a FASTA di eseguire task in maniera molto più rapida. – le euristiche utilizzate nell’algoritmo permettono, come si vedrà nel paragrafo successivo, un uso della memoria estremamente ottimizzato. • Svantaggi – l’invocazione di un file eseguibile dall’interno di un programma e la sua esecuzione come black-box sicuramente non fa parte delle best pratices della programmazione, in quanto non è possibile, in alcun modo, controllare l’esecuzione, le situazioni di errore o fare debugging. Capitolo 3: FASTA per Hadoop 12 A partire dalle considerazioni appena discusse si è scelto di utilizzare, quindi, l’implementazione in C di FASTA come fondamenta per la risoluzione del problema del pairwise alignment su Hadoop. 3.2.2 FASTA Benchmark Al fine di verificare la bontà dell’implementazione di FASTA, avendo un limitato tempo a disposizione è stato effettuato un test, di tipo sequenziale, su un input di 32 file, ognuno di circa 70 KB. Tale test, effettuato su una macchina appartenente al cluster Hadoop utilizzato in questo progetto, sarà utilizzato come unità di riferimento nei capitoli successivi, al fine di poter misurare i possibili miglioramenti derivanti da un’implementazione dello stesso utilizzando il paradigma Map-Reduce. L’esecuzione di FASTA sull’input descritto in precedenza ha impiegato 578,77 minuti. Il risultato sembra non essere esaltante, ma bisogna considerare che, dati 32 file in input, l’algoritmo computa su 32 ú 32 coppie. Più in dettaglio, ogni file di riferimento dell’input viene confrontato con il restante input, ed il confronto fra il file di riferimento con sé stesso viene scartato. Ogni coppia, per essere valutata dall’algoritmo, impiega in media 35 secondi. Il dato più rilevante, però, risulta essere la quantità di memoria utilizzata: se il processore, grazie alle ottimizzazioni di parallelizzazione in FASTA, lavora in maniera costante al 198%, la memoria utilizzata dal programma si è rivelata essere, nei momenti di picco massimo, di circa 300 MB. Tale valore, confrontato con la memoria occupata dall’implementazione di JFASTA di circa 1.2 GB, giustifica da sola la scelta di utilizzare come soluzione FASTA. Capitolo 4 Implementazione Map-Reduce In questo capitolo si presenta l’approccio utilizzato per il raggiungimento della soluzione, sfruttando il paradigma Map Reduce, la sua architettura, la relativa implementazione e le scelte che hanno portato ad ottenere tale soluzione. 4.1 Overview Il problema di processare tutte le possibili coppie, a partire da un insieme di genomi memorizzati in file che rispettano il formato FASTA, può essere visto come: scegliere un genoma di riferimento e processare tutte le coppie il cui primo elemento è il genoma scelto. Tale operazione è ripetuta per ogni file appartenente all’insieme di genomi fornito in input. Il processo di elaborazione appena enunciato, è l’esatta descrizione ad alto livello di quel che l’applicazione si occupa di portare a termine. Infatti, come è illustrato dalla figura 4.1, si può notare come per ogni genoma fornito in input, questo venga preprocessato in una fase di inizializzazione, durante la quale esso è messo a disposizione dei mappers. La fase di inizializzazione prevede il caricamento sull’HDFS del file sotto lo pseudonimo di TARGET, in quanto è il file a cui ogni mapper dovrà far riferimento per quel "turno". La fase di Map, prevede il confronto tra il file TARGET del turno in questione con il file del genoma assegnato al mapper nel modo spiegato in dettaglio successivamente. Il confronto è realizzato utilizzando un eseguibile esterno chiamato FASTA36, il quale implementa l’algoritmo FASTA. Terminato il confronto, si provvede ad effettuare l’upload dell’output sul file system distribuito. Una volta terminata la fase di Map, segue la fase di Reduce che consiste nell’aggregazione dei risultati ottenuti per il genoma TARGET corrente 13 Capitolo 4: Implementazione Map-Reduce 14 in un unico file situato sull’HDFS. L’applicazione invocabile da linea di comando prende in input il path di una directory contenente gli n genomi da processare. Figura 4.1: Elaborazione dei genomi in input 4.2 Dettagli implementativi Di seguito viene esposta la soluzione introdotta precedentemente. Il deliverable è un file jar eseguibile da linea di comando: tale eseguibile prende in input due parametri quali, la modalità di esecuzione e la cartella di input. L’utilizzo della classe ProgramDriver messa a disposizione tra le utility del framework Hadoop, consente di modificare il comportamento di una applicazione, in funzione di un parametro fornito dall’utente. L’applicazione è invocata se il primo parametro ricevuto in input è "-a". L’eseguibile FASTA36 è un processo cpu-intensive che conviene eseguire in una singola istanza per volta, in quanto la concorrenza nell’ottenimento della risorsa processore andrebbe solo a far decadere le performance. Proprio per questo motivo si è scelto di permettere l’esecuzione esclusiva di un singolo processo FASTA36. Capitolo 4: Implementazione Map-Reduce 15 Per ottenere tale modalità di esecuzione è stato necessario modificare la configurazione del Resource Manager Yarn, il quale si basa su container che effettuano la computazione chiamati Yarn Child, ed un unico container addetto all’orchestrazione dei servizi detto Application Master. I settings che meglio si sono adattati al caso dell’applicazione, sono mostrati dalla tabella 4.2. yarn-site.xml Proprietà Valore yarn.nodemanager.resource.memory-mb 2048 Descrizione Il quantitativo di memoria fisica, in MB, allocabile per i containers. mapred-site.xml Proprietà Valore Descrizione mapreduce.map.memory.mb 2048 Valore in MB relativo alla memoria allocabile per Mapper. mapreduce.reduce.memory.mb 2048 Valore in MB relativo alla memoria allocabile per Reducer. mapreduce.map.java.opts -Xmx1536M Parametro da passare alla JVM che gestisce il Mapper di un nodo relativo al limite di memoria che questa può utilizzare. mapreduce.reduce.java.opts -Xmx1536M Parametro da passare alla JVM che gestisce il Reducer di un nodo relativo al limite di memoria che questa può utilizzare. Per quanto riguarda invece la configurazione relativa all’HDFS, è mostrata nella tabella 4.2: Capitolo 4: Implementazione Map-Reduce 16 hdfs-site.xml Proprietà dfs.replication dfs.blocksize Valore Descrizione 3 Numero di repliche per blocco. 64m Taglia di un singolo blocco. Tale configurazione consente di avere su ogni nodo, un solo container e quindi un solo processo FASTA. Particolare fondamentale di questa applicazione è che essa si compone di tante iterazioni di processing quanti sono i file in input. Ciò si traduce in: • Prepare Input • ’genome œ GENOMES – Create and configure Job – Map Phase – Reduce Phase 4.2.1 Inizializzazione La fase di inizializzazione può essere suddivisa in due parti: • Preparazione dell’input • Configurazione ed esecuzione di un job per ogni file in input La preparazione dell’input consiste nella creazione di un unico file, contenente tante righe quanti sono i file in input. Ogni linea del file prodotto, è esattamente uno dei file presenti nella directory di input: tali file vengono portati in formato UNIX, ed ogni newline è convertito in un carattere delimitatore. Durante questa fase, inoltre per ogni file, si calcola la checksum MD5, mantenendo l’associazione nome file - checksum. L’hash è utilizzato per gestire in maniera non ambigua i file durante le fasi di Map e Reduce. Una volta preparato l’input, si procede con il main loop. Come illustrato in figura 4.2, per ogni genoma: Capitolo 4: Implementazione Map-Reduce 17 • si ottiene l’istanza di un job; • alla configurazione del job, viene aggiunto il nome del file TARGET e la sua checksum; • viene effettuata la copia dei file sull’HDFS; • il job viene configurato sulle giuste classi Mapper e Reducer; • gestione dell’input: come anticipato, il file TARGET deve essere confrontato con tutti gli altri file. Tale operazione di splitting è realizzata in maniera efficace grazie all’utilizzo del NLineInputFormat InputSplitter, il quale provvede a fornire in input ad ogni mapper una linea diversa del file originale. In questa maniera, avendo a disposizione un input che è multiplo del numero di nodi presenti nel cluster, si può ottenere una equa ripartizione del carico, generando così un numero di MapTask tale da disporsi equamente, in generale, sui nodi del cluster; • gestione dell’output: ogni mapper produce in output l’allineamento tra il genoma TARGET ed il genoma assegnatogli dallo splitter. Tale output è quel che il processo FASTA restituisce durante la sua esecuzione, in una quantità di testo variabile in base alla taglia dei genomi da confrontare. Si è scelto di redirigere questo output in un file, da caricare sull’HDFS in una cartella specifica per tale confronto, creata durante la fase di inizializzazione. • si procede con il lancio del job, utilizzando il metodo waitForCompletion: quest’ultima è una chiamata bloccante che restituisce il controllo al thread che lo invoca, al completamento del job; • al riottenimento del controllo, il file TARGET è eliminato dall’HDFS, in quanto il suo periodo di validità termina con l’iterazione che si sta concludendo. 4.2.2 Fase di Map La fase di Map, prevede un setup iniziale, in cui recupera il nome del file dalla configurazione, per poter copiare sul file system locale, nella directory di lavoro del mapper, il file TARGET del job in corso. Una volta ottenuto tale file, si converte in formato UNIX, e si memorizza la relativa checksum MD5. Il setup termina con l’acquisizione del path all’eseguibile FASTA36. Il Map vero e proprio è effettuato su un input del tipo <LongWritable, Text> dove Capitolo 4: Implementazione Map-Reduce 18 la chiave LongWritable rappresenta l’offset della linea dall’inizio del file, mentre il valore Text è la linea. Tale valore, contenente un intero genoma in formato FASTA è processato, per ottenere il file originale, in cui il delimitatore è sostituito da un newline. Un’ottimizzazione introdotta è quella di verificare che il file TARGET ed il file contenuto nel value Text, non siano in realtà lo stesso file. Per fare ciò, si ricorre al calcolo dell’hash MD5 del file estratto dal value: se tale checksum è identica a quella del TARGET, allora il processing dei due file può essere evitato ed il Map termina la sua esecuzione. Se invece, i due file sono diversi, si procede alla memorizzazione in locale del file ottenuto dal value, questo perché l’eseguibile FASTA prende in input i path a due file da confrontare. Infine, si procede alla configurazione degli argomenti da passare all’eseguibile. A questo punto è possibile invocare FASTA36 passando come argomenti i path al file TARGET ed al file da confrontare. Per notificare al framework Hadoop ed in particolare al Resource Manager Yarn, che l’esecuzione sta avvenendo correttamente, onde evitare la terminazione del MapTask, occorre aggiornare il contesto: ciò è realizzato mediante il metodo progress dell’oggetto Context, eseguito ogni mille linee di output prodotto dal processo FASTA36. Al termine dell’esecuzione del processo FASTA36, l’output prodotto, memorizzato in un file, viene salvato nel contesto utilizzando come chiave la checksum MD5 del file TARGET, restituendo così un output del tipo <Text, Text>. 4.2.3 Fase di Reduce La fase di Reduce si pone l’obiettivo di aggregare i risultati dei confronti prodotti dai singoli processi FASTA per un determinato file TARGET. Il Reducer ottiene in input la coppia < Text, Iterable<Text> >, cioè come chiave l’hash MD5 del file di riferimento, che ne garantisce l’unicità, e come valore la lista dei risultati ottenuti in seguito ad ogni confronto. Si prosegue con l’ottenimento della directory e la creazione del file di output sull’HDFS. Quindi, ogni elemento della lista di risultati viene concatenato al file di output sull’HDFS che al termine della fase, conterrà l’output di ogni confronto effettuato con il file TARGET. Infine, l’unico reducer restituisce un output costituito da una coppia di tipo <Text, Text>, in cui la chiave è il nome del file dei risultati aggregati, mentre il valore è il percorso al file appena creato sull’HDFS contenente l’insieme dei risultati. L’output viene scritto sul contesto del Reducer mediante l’utilizzo della classe MultipleOutputs, che consente inoltre di aggiungere la checksum del file TARGET. Capitolo 4: Implementazione Map-Reduce Figura 4.2: Dettaglio Schema MapReduce per singolo job 19 Capitolo 4: Implementazione Map-Reduce 4.2.4 20 Risultato finale Il risultato che si ottiene da un’esecuzione dell’applicazione è l’insieme degli allineamenti su ogni file in input, processati da FASTA per ognuno di questi ultimi. Tali allineamenti sono presentati in un formato molto esplicativo, il che semplifica la lettura all’utente. Per questo motivo, i file prodotti non necessitano di ulteriori elaborazioni. Capitolo 5 Tests e Benchmarking 5.1 Configurazione di test I tests sono avvenuti sulle macchine del laboratorio Reti all’interno del Dipartimento di Informatica dell’Università di Salerno. Sono state impiegate 34 macchine low-end così configurate: • Processore: Intel Celeron G530 Dual Core operante a 2.4Ghz, in grado di supportare le istruzioni Intel SSE di secondo livello. • Memoria Ram: 4096Mb DDR3 a 667Mhz. • Disco fisso: 500Gb operante a 5400rpm. • Scheda di rete ethernet Intel in grado di operare fino a 1Gbps. • Sistema operativo: Windows 7 Enterprise N a 64 bit. Queste macchine sono collegate tra di loro mediante uno switch Ethernet da 100Mbps. Su ciascuna di queste macchine è stata installata una macchina virtuale utilizzando la suite VMWare [9], così preparate: • VCore utilizzabili: 2. • Memoria Ram dedicata: 3072Mb. 21 Capitolo 5: Tests e Benchmarking 22 • Disco fisso: 120Gb. • Sistema operativo: Canonical Ubuntu 12.04 LTS a 64 bit su kernel GNU/Linux 3.8.x generic x86_64. La Java Virtual Machine utilizzata è la sequente: java version "1.7.0\_60" Java(TM) SE Runtime Environment (build 1.7.0\_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode) In particolare su 33 di queste macchine virtuali è stato installato Apache Hadoop 2.2.0 compilato a 64 bit, in maniera tale da avere un master e 32 slaves. L’impiego delle macchine virtuali si è reso necessario perché non si disponeva dei privilegi di amministrazione sulle macchine fisiche e per avere un ambiente il più omogeneo e stabile possibile. La restante macchina è stata utilizzata per eseguire i test relativi al sequenziale, illustrati nella sezione 3.2.2. 5.2 Il tool utilizzato per le analisi Per poter monitorare le prestazioni del cluster durante l’esecuzione dei test è stato utilizzato il tool dstat [10]. Si tratta di un software in grado di visualizzare tutte le risorse di sistema (Cpu, memoria, disco, rete) in tempo reale fornendo chiaramente la grandezza e l’unità di misura dei dati in output. Più in dettaglio per la valutazione delle prestazioni del cluster abbiamo utilizzato il seguente comando: dstat -tcmgsdn –net-packets –float –noheaders –output out-dstat.csv 10 dove con le opzioni tcmgsdn si abilitano rispettivamente la visualizzazione dell’ora e della data per ogni riga dell’output, le statistiche sulla CPU, sulla memoria, sulla paginazione (page in e page out), lo swap, il disco (numero byte letti e scritti) e la rete (numeri pacchetti inviati e ricevuti, throughput dell’host in uplink e downlink). Nel precedente comando vengono utilizzate anche le seguenti opzioni: • net-packets: che mostra il numero di pacchetti ricevuti e trasmessi sulla rete. • float: che serve per forzare valori in output a float. Capitolo 5: Tests e Benchmarking 23 • noheaders: che disabilita la ripetizione dell’intestazione. • output: che permette la redirezione dell’output di dstat in un file csv. • 10: che indica il tempo di campionamento con cui vengono visualizzati i dati. 5.3 Benchmark In questa sezione, si analizzano i risultati ottenuti, dai test effettuati utilizzando l’applicazione descritta nel capitolo 4. Tali test sono stati effettuati, utilizzando un cluster composto da 8, 16 e 32 nodi. L’input sottomesso all’applicazione è il medesimo sottomesso all’applicazione sequenziale descritta nella sezione 3.2.2, ovvero 32 file contenenti genomi in formato FASTA, elencati in tabella 5.3. 1 La configurazione utilizzata per il cluster Hadoop, mostrata in tabella 4.2, prevede l’utilizzo di 31 YarnChild. Per cui uno dei 32 slave è utilizzato come Application Master, ottenendo così che il numero di macchine effettivamente allocate alla computazione del task sia 31, e non 32. La configurazione è analoga, per il cluster ad 8 e 16 nodi. I risultati ottenuti sono analizzati nelle sezioni a seguire, confrontando i grafici delle statistiche ad 8, 16 e 32 nodi, mettendo in mostra le differenze ed i singoli dettagli. I dati misurati comprendono statistiche riguardanti: • Utilizzo CPU • Utilizzo Memoria RAM • Lettura e Scrittura Disco • Pacchetti di rete inviati/ricevuti 1 • Throughput in input/output Sono stati selezionati tali file, per riuscire ad ottenere un risultato finale dall’esecuzione sequenziale, in tempo utile ai nostri scopi. Capitolo 5: Tests e Benchmarking 24 Capitolo 5: Tests e Benchmarking Nome file 25 Dimensione (KB) Bordetella-holmesii-F627-contig1.txt 69 Campylobacter-jejuni-subsp.-jejuni-NCTC-11168.txt 69 Ehrlichia-ruminantium-str.-Welgevonden-chromosome.fasta 69 Enterobacter-cloacae-subsp.-cloacae-GS1-GS1-c4.txt 69 GEN-Methanocaldococcus-jannaschii-DSM-2661-chromosome.txt 70 GEN-Methanothermobacter-thermautotrophicus-str-Delta-Hchromosome.txt 70 GEN-Streptococcus-pyogenes-NZ131.txt 70 Haemophilus-influenzae-PittEE.txt 69 Helicobacter pylori B38.fasta 69 Leptospira-licerasiae-serovar-Varillal-str.-VAR-0107180000002868.fasta 69 Marinomonas-sp.-MED121-scf-1099517007713.txt 69 Nautilia-profundicola-AmH.fasta 69 Neisseria-lactamica-Y92-1009.fasta 69 Photobacterium-angustum-S14-1099604003198.txt 69 Photobacterium-sp.-SKA34-scf-1099521381183.txt 69 Plesiomonas-shigelloides-302-73.txt 69 Prochlorococcus-marinus-str.-MIT-9211.fasta 69 Prochlorococcus-marinus-subsp.-marinus-str.-CCMP1375.fasta 69 Pseudomonas-aeruginosa BL20.fasta 69 Rickettsia-prowazekii-str.-NMRC-Madrid-E.txt 69 Rickettsia-prowazekii-str-Breinl.fasta 69 Salmonella-enterica-subsp-enterica-serovar-Enteritidis-str-78-1757SEEE1757-1.fasta 69 Salmonella-enterica-subsp-enterica-serovar-Enteritidis-str-CDC2010K-1543-SEEE1543-1.fasta 69 Salmonella-enterica-subsp-enterica-serovar-Enteritidis-str-CDC2010K-1884-SEEE1884-1.fasta 69 Sinorhizobium-meliloti-1021-plasmid-pSymA.fasta 69 Streptococcus-pyogenes-MGAS1882.fasta 69 Streptococcus-salivarius-M18.fasta 69 Streptococcus-agalactiae-ZQ0910.txt 69 Vibrio-alginolyticus-12G01-1100007009707.txt 69 Vibrio-angustum-S14-1099604003227.txt 69 Vibrio-parahaemolyticus-10329-VP10329-34.fasta 69 Weissella-koreensis-KACC-15510.fasta 69 Capitolo 5: Tests e Benchmarking 5.3.1 26 Tempi di esecuzione Tipo di esecuzione 5.3.2 Tempo (sec) Sequenziale 34726 8 Nodi 5486 16 Nodi 4631 32 Nodi 3327 CPU Figura 5.1 Il grafico mostra la precentuale di utilizzo di CPU, durante il test ad 8 nodi, su 32 job. Nella parte iniziale del grafico, lo scarso utilizzo di CPU, indica che sta avvenendo la fase di start del framework Hadoop, successivamente si presenta un picco, per ogni job in esecuzione. Dall’altezza di ogni cresta, si nota come l’utilizzo di CPU sia abbastanza intensivo, fino all’80% circa, caratteristica del processo FASTA, mentre l’ampiezza della singola cresta in questo grafico è la maggiore rispetto agli altri grafici riguardati la CPU, in quanto ogni slave ha da svolgere all’incirca quattro MapTask consecutivamente, ricoprendo quindi una durata di tempo maggiore. Per ogni cresta è possibile notare come, abbia un alto utilizzo di CPU iniziale per poi diminuire con il passare dei secondi, il che rispecchia la fase di Map cpuintensive, seguita dalla fase di Reduce. Capitolo 5: Tests e Benchmarking 27 Figura 5.2 Il grafico mostra la percentuale di utilizzo di CPU, durante un test a 16 nodi, su 32 job. La parte iniziale del grafico, rappresenta la fase di start del framework Hadoop, con il suo scarso utilizzo di CPU. Successivamente, si può riscontrare dalle creste presenti nell’immagine l’esecuzione dei job. Come nel grafico 5.1, si nota dall’altezza di ogni cresta, che il processo FASTA porta la CPU all’incirca all’80% di utilizzo, ma dall’ampiezza si osserva che la durata dell’elaborazione è inferiore. Questo avviene perché, ogni slave ha circa 2 MapTask da portare a termine. Anche in questo caso si nota come la fase di Map sia più intensiva rispetto a quella di Reduce, in ogni job. Figura 5.3 Capitolo 5: Tests e Benchmarking 28 Il grafico mostra la percentuale di utilizzo di CPU, durante un test a 32 nodi, su 32 job. La parte iniziale, rappresenta la fase di start del framework Hadoop, caratterizzata dallo scarso utilizzo di CPU. Successivamente, l’esecuzione dei job è riportata sotto forma di cresta nell’immagine. In questo caso, la CPU è sfruttata in maniera leggermente inferiore rispetto al grafico 5.2 e 5.1 e solamente in un caso supera il 75%, quindi in media, gli slaves lavorano leggermente meno, in quanto il carico è dilazionato su un maggior numero di macchine. Ad ogni slave è assegnato in generale un solo MapTask, terminando il job in tempo breve, come mostra l’ampiezza di ogni cresta. Ed è anche per questo motivo che la media di utilizzo di CPU risulta essere inferiore, in quanto il tempo di campionamento utilizzato per ottenere le statistiche si è rivelato essere leggermente elevato per la granularità dell’esperimento. 5.3.3 RAM Di seguito sono presentati i grafici relativi all’utilizzo di RAM durante un job, al variare del numero di slave. Figura 5.4 Capitolo 5: Tests e Benchmarking 29 Il grafico mostra la percentuale di utilizzo di memoria RAM, durante un test ad 8 nodi, su un singolo job. Come si nota, sono presenti quattro creste, ognuna rappresentante un MapTask, ciò è dovuto al fatto che avendo un numero di file in input pari a 32, ed avendo un numero di MapTask pari al numero di file, in generale ogni slave ha da elaborare in questo caso, circa quattro MapTask, vedasi la durata del job. La cresta iniziale, mostra come all’inizio del job, sia la macchina che svolge il ruolo di Application Master ad essere quella che necessita di più memoria RAM. Durante le esecuzioni dei task, gli slave utilizzano circa 700MB di RAM nelle fasi di Map, mentre 400MB durante le fasi di Reduce. Tale quantità di memoria coincide con quella mediamente utilizzata dal processo FASTA. L’immagine mostra come al termine delle fasi di Map, gli slaves rilascino memoria, mentre l’Application Master tenda ad avere una quantità di memoria utilizzata costante durante il monitoring dell’applicazione, tranne che al termine del job, in cui presenta un carico maggiore, dovuto alle operazioni da svolgere al completamento di quest’ultimo. Figura 5.5 Capitolo 5: Tests e Benchmarking 30 Il grafico mostra la percentuale di utilizzo di memoria RAM, durante un test a 16 nodi, su un singolo job. Sono visibili due creste, dovute a due MapTask assegnati agli slave, vedasi la durata del job. Anche in questo caso, così come nel grafico 5.4, all’inizio ed alla fine del job è l’Application Master ad avere la maggior quantità di RAM utilizzata, mentre durante le due fasi di Map, sono gli slave ad utilizzare circa 700MB di memoria. Figura 5.6 Il grafico mostra la percentuale di utilizzo di memoria RAM, durante un test a 32 nodi, su un singolo job. In questo caso, vi è un’unica cresta visibile, in quanto per questo esperimento ogni slave ottiene circa un MapTask. Come nei grafici 5.1 e 5.2, all’inizio ed al termine del job, è l’Application Master ad occupare più memoria RAM, mentre durante la fase di Map gli slave aumentano la quantità di memoria utilizzata, per poi rilasciarla al termine della fase. Capitolo 5: Tests e Benchmarking 5.3.4 31 Disco Di seguito sono presentati i grafici relativi all’utilizzo del disco durante un job, al variare del numero di slave. Da notare che i dati indicati sono misurati in KB/s, fattore che evidenzia la bassa quantità di dati in input. 5.3.4.1 Lettura Figura 5.7 Figura 5.8 Figura 5.9 Capitolo 5: Tests e Benchmarking 32 I grafici mostrati, presentano le operazioni di lettura necessarie durante l’esecuzione di un singolo job. Nella sezione iniziale dei grafici, si mostra l’avvio del framework Hadoop. Tale fase prevede la configurazione dei nodi del cluster, a partire da file che risiedono su disco. In seguito alla configurazione, ogni slave provvede a munirsi dell’input necessario allo svolgimento del task ad esso assegnato, procedendo con letture dal disco: ogni slave si preoccupa di leggere il file eseguibile FASTA presente su disco, ed i file di input per quest’ultimo. Dalle immagini si può notare come l’aumento del numero di slave sia inversamente proporzionale al numero di accessi al disco, in quanto ogni slave è incaricato allo svolgimento di un numero inferiore di MapTask, e quindi ha bisogno di un minor numero di letture. 5.3.4.2 Scrittura Figura 5.10 Figura 5.11 Capitolo 5: Tests e Benchmarking 33 Figura 5.12 I grafici mostrati, presentano le operazioni di scrittura necessarie durante l’esecuzione di un singolo job. Nella prima sezione di ogni grafico, come nel caso della lettura, è mostrato l’avvio del framework Hadoop, che richiede scritture dovute al caricamento dell’input sull’HDFS, che in questo caso risulta essere molto breve in quanto i dati da caricare risultano essere di dimensioni molto contenute, la sua formattazione e la scrittura dei log di sistema. Durante l’esecuzione dei job, gli slaves effettuano scritture continue sul disco in quanto l’output del processo FASTA è redirezionato su file, che successivamente sarà caricato sull’HDFS. 5.3.5 Pacchetti di Rete e Throughput Di seguito sono presentati i grafici relativi allo scambio di pacchetti ed al throughput durante un job, al variare del numero di slave. Tali grafici sono suddivisi in Capitolo 5: Tests e Benchmarking traffico in ingresso e traffico in uscita. 5.3.5.1 IN Figura 5.13 Figura 5.14 Figura 5.15 34 Capitolo 5: Tests e Benchmarking 35 Figura 5.16 Figura 5.17 Figura 5.18 I grafici mostrati, presentano il numero di pacchetti ricevuti e la quantità di traffico in entrata misurata in KB/s, durante un singolo job. Capitolo 5: Tests e Benchmarking 36 Le immagini mostrano come, il numero di creste è pari al numero di MapTask da eseguire per ogni slave. Si nota che, il numero di pacchetti ricevuti dagli slave e dall’Application Master è sempre maggiore all’inizio di ogni MapTask. In particolare l’Application Master è la principale destinazione dei pacchetti, in quanto tutti gli slave comunicano con esso per essere orchestrati nell’esecuzione dei task. Da notare, che durante l’intera esecuzione del job, sia l’Application Master che gli slave continuano a ricevere un basso numero di pacchetti, presumibilmente messaggi di heart beat. Inoltre, la quantità di pacchetti ricevuti dall’Application Master è inversamente proporzionale al numero di slave, in quanto per un singolo job, aumentano i MapTask per slave. 5.3.5.2 OUT Figura 5.19 Figura 5.20 Capitolo 5: Tests e Benchmarking Figura 5.21 Figura 5.22 Figura 5.23 Figura 5.24 37 Capitolo 5: Tests e Benchmarking 38 I grafici mostrati, presentano il numero di pacchetti inviati e la quantità di traffico in uscita misurata in KB/s, durante un singolo job. Come nei grafici precedenti, si ha un numero di creste pari al numero di MapTask per slave. Si nota che l’Application Master è il nodo che ha un maggior numero di pacchetti in uscita. Inoltre, l’invio costante di pacchetti da parte degli slave rispecchia il fatto che durante l’elaborazione della coppia di genomi, vi sia la comunicazione dell’avanzamento del task, grazie all’invocazione del metodo progress offerto dal contesto del Mapper. Probabilmente l’intervallo di campionamento utilizzato non ha permesso di ottenere delle statistiche accurate per quanto riguarda il test a 32 nodi, in quanto non è visibile il picco di pacchetti inviati dall’Application Master, e si crede sia dovuto alla breve durata del job. 5.3.6 Anomalia riscontrata I grafici riguardanti l’utilizzo di CPU con 8, 16 e 32 nodi, mostrano la presenza di un singolo job, avente un utilizzo di CPU di gran lunga inferiore ai restanti, come è evidenziato dalla figura 5.25. L’evento sospetto ha portato ad analizzare i log dell’esperimento, in particolare di quello ad 8 nodi. Da tale analisi si è riscontrato che vi era un file il cui tempo di esecuzione totale risultava essere ben inferiore ai restanti. Figura 5.25 Capitolo 5: Tests e Benchmarking 39 Il file in questione è denominato GEN-Methanocaldococcus-jannaschii-DSM-2661chromosome.txt e come è mostrato nello scorcio sottostante, è risultato non rispettare il formato FASTA. >sp|GEN|0 0 OS=GEN_Methanocaldococcus_jannaschii_DSM_2661_chromosome GN=0 >gi|15668172|ref|NC_000909.1| Methanocaldococcus jannaschii DSM 2661 chromosome, complete genome TACATTAGTGTTTATTACATTGAGAAACTTTATAATTAAAAAAGATTCATGTAAATTTCTTATTTGTTTA ... Tale file ha causato errore nel processo FASTA dei MapTask in cui esso è un elemento della coppia in input, e maggiormente nel job in cui è scelto come file TARGET. La medesima situazione si è presentata anche nell’esperimento sequenziale, per cui si ritiene che i tempi impiegati siano comunque confrontabili, nonostante l’incidente. 5.3.7 Analisi Prestazione 5.3.7.1 Speedup Figura 5.26 Capitolo 5: Tests e Benchmarking 5.3.7.2 40 Efficienza Figura 5.27 I grafici mostrano come, lo speedup calcolato sia buono per 8 nodi, meno a 16, ed a 32. Ciò è dovuto principalmente alla quantità di file forniti in input all’applicazione, la quale risulta essere bassa per un test a 32 nodi. Infatti, un risultato come quello ottenuto, era stato immaginato conoscendo la natura dell’applicazione, pensata e costruita per effettuare un gran numero di confronti. Capitolo 5: Tests e Benchmarking 41 La dimensione dei singoli file, inoltre, era esigua rispetto al tempo impiegato dall’eseguibile FASTA nel processare una singola coppia. Tale decisione, però, è stata necessaria per poter ottenere un riscontro in tempo ragionevole da parte della versione sequenziale. Lo scarso speedup ottenuto a 16 e 32 nodi è confermato dall’alta efficienza ottenuta nell’esecuzione ad 8 nodi. Anche dai grafici relativi all’utilizzo della CPU si può notare come nell’esecuzione ad 8 nodi i processori a disposizione siano stati sfruttati maggiormente. Capitolo 6 Conclusioni Molti dei problemi appartenenti al mondo della biologia e che si affacciano a quello dell’informatica, richiedono elevata potenza di calcolo e memoria. Nel documento è stata discussa un’applicazione che sfrutta il paradigma MapReduce ed il framework Hadoop per risolvere uno di questi, il Pairwise Sequence Alignment. Tale applicazione si avvale della computazione distribuita per effettuare confronti tra sequenze di genomi. Come si è evidenziato nel capitolo 2.1, l’allineamento di sequenze ha una natura sequenziale, difficile da distribuire. Tale fattore in aggiunta al fattore tempo ha fatto sì che la soluzione fosse quella di distribuire i confronti, e non più il singolo allineamento. Da tale idea nasce l’applicazione descritta nel documento. Essa mira a massimizzare il numero di confronti tra un file di riferimento e un vasto insieme di file candidati. I risultati mostrano come tale idea necessiti di un elevato numero di file in input, ognuno dei quali rappresentante un lungo genoma e di conseguenza avente maggiori dimensioni, ciò sta a significare che l’idea funzionerebbe in uno scenario del mondo reale. L’applicazione potrebbe essere migliorata avendo un input come quello descritto precedentemente, valutando inoltre diversi metodi di suddivisione dell’input, per poi applicare quello che risulti portare un incremento di efficienza e potendo essere eseguita su un numero maggiore di nodi. In aggiunta, l’eseguibile FASTA potrebbe sfruttare meglio il suo parallelismo interno se fosse eseguito su commodity hardware che riesca a mostrare maggiormente le sue potenzialità su multi-core. 42 Bibliografia [1] W.R. Pearson, D.J. Lipman, Improved tools for biological sequence comparison, 1988, disponibile all’indirizzo: http://www.ncbi.nlm.nih.gov/ pmc/articles/PMC280013/pdf/pnas00260-0036.pdf [2] Apache Hadoop, http://hadoop.apache.org/ [3] Ron Shamir, Eti Ezra, Guy Gelles, http://www.cs.tau.ac.il/ ~rshamir/algmb/98/scribe/pdf/lec02.pdf [4] Smith - Waterman Pairwise Alignment Algorithm, http://www.stat. purdue.edu/~junxie/topic2.pdf [5] Codice sorgente FASTA3.6, http://faculty.virginia.edu/wrpearson/ FASTA/CURRENT/ [6] Pseudo-algoritmo FASTA, http://ab.inf.uni-tuebingen.de/ teaching/ws06/albi1/script/BLAST_slides.pdf [7] Pseudo-algoritmo FASTA, http://www.cs.helsinki.fi/ bioinformatiikka/mbi/courses/07-08/itb/slides/itb0708_slides_ 83-116.pdf [8] Formato FASTA, http://en.wikipedia.org/wiki/FASTA_format [9] VMWare Inc., http://www.vmware.com/ [10] Dstat: Versatile resource home-made/dstat/ statistics 43 tool, http://dag.wiee.rs/ Appendice A Appendice A.1 Link al codice sorgente L’intero codice sorgente presentato in questo documento è disponibile online sulla piattaforma GitHub: • Il codice relativo al progetto jFasta è disponibile all’indirizzohttps://github. com/indiependente/jfasta • Il codice relativo al progetto Fasta MapReduce è invece accessibile all’indirizzo https://github.com/indiependente/fastamapreduce In entrambi i repository sono presenti i file per importare i progetti nell’IDE Eclipse. 44
