Università degli studi di Salerno

Транскрипт

1 Università degli studi di Salerno Facoltà di Scienze Matematiche, Fisiche e Naturali Laurea Magistrale in Informatica GRENITS su HADOOP Prof: Giuseppe Cattaneo Gruppo: Giovanni Esposito Luigi Fontanella Luigi Polito Pasquale Cosimato Anno Accademico

2 INDICE 1. Introduzione al Grid Computing...pag 3 2. Hadoop ( Utilizzo del Grid Computing )...pag Architettura...pag Map\Reduce in Hadoop...pag HDFS(Hadoop Distributed File System)...pag Utilità...pag Caso di studio...pag Grenits...pag Descrizione del Problema...pag Ambiente di sviluppo e software...pag Soluzione al problema con implementazione...pag Complessità...pag Grenits utilizzando Hadoop...pag Analisi del Problema...pag Map\Reduce per l algoritmo GRENITS...pag Implementazione...pag Prestazioni e Benchmarking...pag Installazione ambiente e software...pag Configurazione hw e sw...pag Elementi di valutazione per il benchmarking...pag Test e risultati del benchmark...pag Conclusioni...pag 41 Riferimenti...pag 42 2

3 1. Introduzione al Grid Computing La sempre crescente domanda di risorse di calcolo nel mondo moderno ha portato, dagli anni '50 a oggi, alla crescita in modo esponenziale della potenza dei computer. Oggi giorno però ci si trova ad affrontare un problema per molti aspetti inedito, almeno per quanto riguarda la storia dell'informatica. Per certe applicazioni, le richieste, in termini di potenza di calcolo, di memoria e di spazio disco, sono ormai diventate impossibili da soddisfare con l'utilizzo di un singolo calcolatore. Per ovviare a questo problema, negli ultimi anni, si è iniziato a pensare di unire le risorse di più computer in modo da ottenere potenze di calcolo maggiori. Si è quindi assistito al rapido diffondersi di sistemi per collegare in rete locale una serie di computer (da poche unità a qualche centinaio), ottenendo sistemi di potenza (e complessità) con crescente progresso. Purtroppo anche questa strada ha delle limitazioni, tra le quali si possono citare lo spazio disponibile e la difficoltà di gestione: mettere un centinaio di computer in un unico posto in modo che siano gestibili con facilità dal personale tecnico, adeguatamente alimentati, controllati, aggiornati, crea numerose problematiche di non facile soluzione, quali la necessità d'impianti elettrici, di rete e di condizionamento molto costosi e complessi. L'immediata conseguenza di questo fatto è che il numero di computer che si possono mettere in cluster è necessariamente limitato, dato che i costi degli accessori e le difficoltà tecniche, a un certo punto, crescono di pari passo, se non più velocemente dei benefici che si ottengono da queste architetture. A questo punto qualcuno potrebbe pensare che l'enorme potenza di calcolo generata da un sistema di computer in cluster fra loro dovrebbe essere sufficiente per ogni applicazione umanamente concepibile, ma non è così. Esistono già applicazioni, e se ne stanno pensando altre, che richiedono risorse di calcolo superiori (a volte per ordini di grandezza) rispetto a quelle odiernamente fornite con i sistemi classici. E' nata quindi l'esigenza di andare oltre a quella che è stata fino a oggi la comune struttura di un sistema di calcolo. Una delle strade recentemente intraprese per far fronte a tutto questo sono le cosiddette "griglie computazionali", più comunemente dette "grid computing" [1]. 3

4 Grid Computing, infatti, è stato definito come tecnologia che si è occupata di raccogliere e mettere in comune risorse di calcolo e di memoria al fine di risolvere tutti quei problemi prestazionali legati a tali applicazioni. Queste griglie computazionali non rappresentano altro che una serie di computer che, collegati tramite una rete, essi condividono le proprie risorse, e utilizzano la propria potenza di calcolo per risolvere uno specifico problema. Le grid negli ultimi anni hanno avuto un notevole utilizzo soprattutto in ambito scientifico, dove esse hanno rappresentato la soluzione a tutti quegli algoritmi che avendo a disposizione soltanto un computer non sarebbero mai riusciti a risolvere in un tempo ragionevole. Le forze trainanti sono e sono state: 1) in primo luogo le comunicazioni. Oggi la banda larga è già un termine restrittivo. Con l invenzione della FCoE (Fyber Channel over Ethernet) è possibile raggiungere velocità altissime a prezzi molto accessibili. 2) i computer stessi incrementano velocemente, anche al di là di molte previsioni date per ottimistiche negli anni scorsi, il loro rapporto tra prestazioni e costo è basato su tre assi: microprocessori, memorie, software. Basta considerare un normale PC venduto in negozio: supera il gigahertz (miliardo di cicli al secondo), contiene hard disk che ormai raggiunge il centinaio di gigabyte, può essere pilotato da un sistema operativo evoluto, stabile e a bassissimo costo com'è Linux, completo di tutti i protocolli e gli standard di Internet, provati su milioni di connessioni. Da un anno a questa parte, poi, Linux sta esponenzialmente evolvendo verso lo status di ambiente informatico (nella sua accezione estesa) capace di gestire server di fascia alta, quali i cluster (reti strette di elaboratori) capaci di erogare potenze di elaborazione prima riservate ai grandi sistemi, di ordini di grandezza più costosi. 3) gli standard aperti di Internet, Linux e l Open Source rendono possibile l accesso attivo da parte di tecnologie e di scienziati all innovazione diffusa nelle architetture informatiche. Non esistono più i santoni intoccabili del software proprietario, segreto e chiuso. Oggi, per un centro di ricerca, diviene conveniente investire sui sistemi standard (basati su tecnologia PC) risparmiando il costo (enorme) di grandi supercomputer proprietari per dirottare le proprie risorse 4

5 risparmiate sulla formazione di ampi laboratori di programmazione, capaci di plasmare Linux e il software Open Source secondo le proprie esigenze di ricerca. Figura 1.1: Esempio di Grid Computing Inoltre Grid Computing offre un vasto range di applicazioni che può essere classificato principalmente nelle seguenti classi: - Supercalcolo distribuito: Questo tipo di applicazione può usare le grid per unire le risorse di calcolo di molti supercomputer per risolvere problemi che, altrimenti, sarebbero non affrontabili con l'ausilio di un unico calcolatore, per quanto potente, tra quelli oggi disponibili. - High Throughput computing: In questo tipo di applicazioni, una grid può essere utilizzata per organizzare il lavoro di un grande numero di programmi, che siano tra loro poco o per nulla collegati. Lo scopo di questo sistema è generalmente quello di sfruttare il tempo macchina inutilizzato (specialmente di notte). 5

6 - On demand computing: Le applicazioni on demand (a richiesta) si appoggiano sulle grid per rendere disponibili, un tantum, risorse di calcolo che, per il loro saltuario utilizzo, non sarebbe né pratico né economicamente conveniente avere a disposizione localmente. - Data intensive computing: Nelle applicazioni come queste, il cui scopo è la gestione di gigantesche quantità di dati distribuiti geograficamente, normalmente per eseguirne sintesi di vario tipo. - Calcolo collaborativo: Questo tipo di applicazione mira soprattutto a favorire le comunicazioni e le collaborazioni tra le persone, pertanto sono spesso pensate in termini di spazi virtuali. Molte di queste applicazioni devono rendere disponibili risorse di calcolo condivise, così come archivi di dati e accesso alle simulazioni; pertanto finiscono per condividere tutti gli aspetti delle applicazioni già viste. La sfida maggiore in questo tipo di applicazioni è la necessità di fornire tutte queste funzionalità il più possibile in tempo reale, altrimenti l'utilizzo ne sarebbe molto penalizzato. Affinché anche le grid diventino una realtà e possano effettivamente essere utilizzate nelle applicazioni prima descritte, è necessario soddisfare certi requisiti. Innanzitutto una grid deve essere un'infrastruttura, poiché pensata come una struttura a larga scala che metta a disposizione risorse di calcolo, di memorizzazione e di trasporto dati, nascondendo, per così dire, sotto il tappeto, le difficoltà tecniche all'utente finale; senza tralasciare che la struttura deve anche occuparsi di tutte le funzioni di controllo e monitoraggio. 6

7 Un ulteriore requisito è la continuità del servizio, poiché gli utenti devono poter contare su un'applicazione che garantisca loro prestazioni di alto livello, ma le più possibili continue: nessuno vorrebbe usare un processore che offre prestazioni elevatissime, ma di seguito, senza nessun preavviso, compromette due giorni senza poter lavorare perché la rete è intasata. Altro fattore decisivo è la diffusione, noi vorremmo che una tecnologia, per far parte della vita lavorativa di tutti i giorni, fosse disponibile ovunque ci capiti di doverla usare. Vi è poi la consistenza del servizio: perché il sistema abbia una certa diffusione, è necessario che sia basato il più possibile su standard, o che lo possano diventare facilmente, e che resti standard il più a lungo possibile. Inoltre, è necessario che la struttura sia affidabile, riducendo la probabilità di guasti che possano causare perdite di dati o di tempo. In relazione a ciò, vi è il problema del fault tollerance, cioè la capacità dell'infrastruttura nel suo insieme di sopperire ai problemi generati da un guasto a qualche componente software o hardware del sistema. Infine, il costo deve essere molto basso, se paragonato al guadagno che si ottiene utilizzando una grid piuttosto che i normali sistemi di calcolo. La parola da associare a grid è, quindi, parallelismo. Lo scopo, infatti, è quello di parallelizare un certo algoritmo, tale da renderlo quanto più adatto a una computazione parallela e quanto più performante possibile, indipendentemente dalle risorse utilizzate. 7

8 2. Hadoop Hadoop è un sistema di calcolo Map\Reduce distribuito per processi di tipo batch piuttosto scalabile e in grado di maneggiare terabyte o petabyte di dati, supportando applicazioni distribuite con elevato accesso ai dati sotto una licenza libera. Per l utilizzo di Hadoop, ci serviamo di Grid Computing, che come detto in precedenza ci consente la condivisione coordinata di risorse all interno di una dinamica e multi - istituzionale organizzazione virtuale (Virtual Organization, brevemente indicata con VO), con un'incredibile potenza computazionale e capacità di memorizzazione in grado di sopportare grandi carichi di lavoro Architettura di Hadoop Per riuscire a comprendere il sistema e le sue funzioni più da vicino, è importante capire l'architettura di Hadoop. In parole semplici, esso è un framework che funziona in combinazione con diversi elementi. Il primo elemento da considerare è l Hadoop Distribuited File System (HDFS). Il file system distribuito è progettato per gestire grandi file (diversi GB) con operazioni di lettura/scrittura sequenziali. Ogni file è diviso in grossi pezzi e memorizzati su diversi nodi, chiamati Data Node, come file locali. Esiste un nodo centrale chiamato NameNode che tiene traccia delle strutture di directory e della collocazione delle varie parti del file ( chunk ). Il NameNode può essere replicato se necessario Figura 2.1.1: HDFS (SecondaryNameNode). 8

9 1. Per leggere un file, le librerie Hadoop del client calcolano l indice di blocco basandosi sull offset del puntatore al file e fanno una richiesta al NameNode. Il NameNode risponderà con il DataNode che ha una copia di tale blocco. Da questo punto, il client contatta il DataNode direttamente, senza passare attraverso il NameNode. 2. Per scrivere un file, il nodo client deve prima contattare il NameNode per chiedere la replica primaria che gestisce il file richiesto. La risposta del NameNode contiene la replica principale e le repliche secondarie. Il client aggiorna tutte le copie DataNode ma tali cambiamenti sono memorizzati in un buffer da ogni DataNode. Dopo che tutte le copie hanno memorizzato nel proprio buffer queste modifiche, il client invia una commit al NameNode che aggiorna tutte le copie. Il NameNode non solo usa un file di log per recuperare le sue azioni in seguito ad un crash, ma salva periodicamente in suo stato con check-point regolari in un file. Per recuperare dai crash, un nuovo NameNode può subentrare dopo aver ripristinato lo stato dall'ultimo checkpoint e ripetendo le operazioni nel log. Quando avviene un crash di un DataNode, viene rilevato dal NameNode perché non riceve più le notifiche (il nodo per segnalare la sua esistenza invia dei segnali periodicamente). Il NameNode rimuove il DataNode che è andato in crash dal cluster e diffonde i suoi blocchi ad altri DataNode che sono attivi. In questo modo, il fattore di replica di ogni pezzo viene mantenuto in tutto il cluster. Se il DataNode si riprende dal crash, segnala tutti i blocchi di file che gestisce al NameNode. Ogni blocco ha un numero di versione, che è aumentata a ogni aggiornamento. Pertanto, il NameNode può facilmente capire se uno dei blocchi del DataNode è una versione non aggiornata, per poter eliminarli. 9

10 2.2. Map\Reduce Hadoop Il modello di calcolo Map\Reduce deve il suo nome a due celebri funzioni della programmazione funzionale, map e reduce, delle quali rispecchia in un certo senso il comportamento. In una computazione Map\Reduce, infatti, i dati iniziali sono una serie di record che sono trattati singolarmente da processi chiamati Mapper e in seguito aggregati da processi chiamati Reducer. Figura 2.2.1: Hadoop - Fasi di Map\Reduce. Questo modello di calcolo si presta ottimamente alla parallelizzazione anche spinta, tuttavia viene da chiedersi quanti problemi reali sia possibili risolverli con esso. In realtà sono molti più di quelli che si potrebbe pensare: attualmente Map\Reduce viene utilizzato nelle elaborazioni dei dati generati da enormi applicazioni web (es. Google, Facebook), ma anche per studi di genetica e di molti altri campi. 10

11 I processi Mapper elaborano i dati in input, che nel modello di calcolo di Hadoop sono logicamente suddivisi in record (ad esempio un record può essere una linea di un file di testo o qualcosa del genere) e producono una coppia chiave-valore per ciascun record. Queste coppie chiave-valore (di norma ci sono più coppie aventi la stessa chiave) prodotte dai Mapper sono poi passate ai processi Reducer che aggregano le coppie corrispondenti alla stessa chiave; il risultato dei Reducer è un insieme di coppie chiavevalore aventi una sola coppia per chiave e viene generalmente scritto su un file di output nello stesso HDFS. Il vantaggio della Map\Reduce è che permette un'elaborazione distribuita delle operazioni di mappatura e riduzione. Fornendo ogni operazione di map indipendente dalle altre, tutte le map possono essere eseguite in parallelo. Map\Reduce può essere applicato significativamente a più grandi quantità di dati che i server possono gestire comodamente - una grande server farm può usare Map\Reduce per ordinare petabyte di dati in sole poche ore. Figura 2.2.2: Paradigma Map\Reduce 11

12 2.3. HDFS(Hadoop Distributed File System) HDFS è il file system distribuito di Hadoop. E stato scritto in Java ed è stato progettato per gestire file di grosse dimensioni. Esso, infatti, è alquanto scalabile e portabile ed è basato su diversi protocolli di comunicazione che permettono la gestione e la trasmissione dei dati tra i diversi nodi. Inoltre tramite il meccanismo del NameNode e del DataNode accennati in precedenza Hadoop riesce a gestire in maniera ottimale l intero File System che utilizza il protocollo TCP/IP a livello di comunicazione. HDFS si presenta alquanto affidabile poiché si basa su meccanismi di replica che permettono di non perdere dati necessari in caso di malfunzionamenti. Infatti, esso possiede un Secondary NameNode che è collegato direttamente al NameNode principale, salvando informazioni su quest'ultimo, in modo tale da poter ripristinarlo in caso di guasti. Particolarmente interessanti in Hdfs sono le operazioni di scrittura e lettura di un file. HDFS utilizza un modello a singola scrittura e a multipla lettura. Infatti, dopo che un file è stato scritto, i byte scritti non possono essere modificati o rimossi ma l unica operazione concessa è quella di poter appenderne altri. Ogni volta che un client apre un file in scrittura, esso stipula un contratto con il NameNode che rinnova ogni volta dopo un certo tempo di time-out. Finché il contratto è valido, nessun altro client potrà accedere in scrittura a quel determinato file. Molto differente invece è la lettura che può avvenire anche in maniera parallela. HDFS quindi si mostra molto adatto e stabile per l applicazione Hadoop il cui scopo è di parallelizzare il calcolo dovendo gestire un'enorme mole di dati. 12

13 2.4. Utilità Hadoop nasce con scopi ben precisi e chi decide di utilizzarlo ha bene in mente i benefici che può offrire: 1) Prestazioni computazionali migliori: tutto ciò è dovuto alle varie strategie applicate, dando così una distribuzione dei carichi di lavoro alle macchine nella griglia e attivando il concetto di parallelismo tra i nodi coinvolti. 2) Elaborare l'intero input in sottoparti: con l'aumentare della tecnologia, i dati in input a un determinato problema, assumono dimensioni notevoli che, un singolo PC, probabilmente, non è in grado di supportare. Hadoop permette di poter suddividere tale input in più parti, in modo che ogni macchina possa elaborare soltanto un sottoinsieme dell input, ottenendo un risultato coerente. 3) Calcolo indipendente dal contesto: è possibile isolare una serie di computer dal contesto di utilizzo creando così una griglia-cluster tale da, poter far girare un'applicazione in modo agevole e veloce, ottenendo risultati in tempo ragionevole anche con dati in input di dimensioni enormi. 13

14 3. Caso di studio 3.1. Grenits (Gene regulatory Network Inference Using Time Series) Gli esperimenti Time Series sono diventati sempre più popolari per lo studio di una vasta gamma di sistemi biologici. Tuttavia, quando si analizzano questi esperimenti, vengono affrontate molte sfide computazionali. Gli algoritmi specifici progettati per questi esperimenti devono essere comunque capaci di sfruttare le loro caratteristiche (come ad esempio la capacità di inferire la causalità dal modello di risposta temporale) e affrontare i problemi specifici che vengono sollevati. GRENITS, acronimo di Gene Regulatory Network Inference Using Time Series [2], è un pacchetto che offre quattro modelli d'inferenza statistica di rete Dynamic Bayesian Networks e le Gibbs Variable Selection: un modello d'interazione lineare, due modelli d'interazione lineare con aggiunta di rumore sperimentale (gaussiana e studenti distribuiti) disponibili per il caso in cui si replica e un modello d'iterazione non lineare. Il pacchetto è destinato a essere utilizzato sia da utenti con un background in inferenza bayesiana, sia da utenti occasionali. A questo scopo, i parametri MCMC (catena di Markov Monte Carlo) sono stati impostati di default con valori che sono adeguati a una vasta gamma di set di dati. Oltre a questo, sono fornite alcune trame di base di diagnostica e di analisi. 14

15 Descrizione del problema Per la risoluzione del nostro problema, proponiamo una rete dinamica bayesiana e un modello di regressione con stima non parametrica [3] per la costruzione di un microarray per i geni regolatori con serie temporale. Il metodo proposto può evitare un difetto del modello di rete bayesiana per quanto riguarda le regolazioni cicliche (esempio: un gene regolatore A regola un gene B e un gene regolatore B regola un gene A); può analizzare i dati del micro-array come dati continui e può catturare anche relazioni non lineari tra geni. Si può prevedere che questo modello darà una migliore visione dei sistemi biologici complessi, derivando un nuovo criterio di valutazione di una stima per le reti Bayesiane. Le recenti tecnologie sviluppate sui cdna micro-array consentono di misurare i differenti livelli dell'espressione genica per l intero genoma nello stesso istante di tempo. Mentre la quantità di dati disponibili di espressione genica è aumentata rapidamente, le tecniche matematiche necessarie per analizzare tali dati sono ancora in via di sviluppo. Infatti, è particolarmente difficile derivare un gene regolatore dai dati di un'espressione genica poiché questi geni sono soggetti a enormi variazioni. L obiettivo è di calcolare tutti i geni regolati dal gene regolatore in base all espressione genica evoluta nel tempo costruendo così una matrice di adiacenza Prior di dimensioni N x N e specificare se un gene regola l altro. Sono stati messi sotto osservazione i geni ed è stata costruita una matrice Expr di dimensioni N x T che specifica le espressioni geniche per ogni gene in differenti instanti temporali. 15

16 Ambiente di sviluppo e software L ambiente di sviluppo utilizzato per la risoluzione del problema è stato R. R rappresenta un particolare tool matematico specifico per l'analisi statistica. È un software open source ed è disponibile per diversi sistemi operativi. Per la risoluzione dell'algoritmo è stata utilizzata, in particolare, la libreria Grenits che offre quattro modelli d'inferenza statistica utilizzando le Dynamic Bayesian Networks e le Gibbs Variable Selection, come descritto nel paragrafo Soluzione al problema con implementazione L'input non consiste più di un'unica matrice Prior ed Expr ma è composto da più sottomatrici Prior ed Expr ricavate da un algoritmo di suddivisione della matrice. Ad ogni sottomatrice Expr è associata una sottomatrice Prior. Utilizzeremo le funzioni e i relativi comandi utili alla soluzione del problema contenute nella libreria GRENITS e BIOBASE mediante la console di R. Sarà utilizzata principalmente la funzione LinearNet che prenderà in input la sottomatrice Prior ed Expr e restituirà in output una cartella con i risultati compresi i geni regolatori. Infine i risultati parziali saranno combinati per ottenere l'unica matrice dei geni regolatori. GRENITS.R library(grenits) library(biobase) file_list <- list.files(path = "~/Scrivania/input", full.names = TRUE, recursive = FALSE) output.folder = "~/Scrivania/outputLinear" size <- length(file_list)/2 for(i in 1:size){ express <- as.matrix(read.table(file_list[i])) prior <- as.matrix(read.table(file_list[i+size])) 16

17 LinearNet(output.folder, express, fixme=prior) analyse.output(output.folder, timeseries = express) dir(output.folder) chain1 <- read.chain(output.folder,1) chain2 <- read.chain(output.folder,2) gamma1 <- colmeans(chain1$gamma) gamma2 <- colmeans(chain2$gamma) prob.file <- paste(output.folder," ~/Scrivania/NetworkProbability_Matrix.txt",sep= "") file.rename(prob.file,paste("~/scrivania/result/prob.mat",substr(file_list [i],43,100),sep="")) rm(list=ls()) load("scrivania/preprocessgrenits_workspace") resultlist <- list.files(path = "~/Scrivania/result", pattern = "result_expr", full.names = TRUE, recursive = FALSE) totalnet <- as.matrix(read.table(resultlist[1])) totalnet[,] <- 0 translateresult <- totalnet for(i in resultlist){ tmp <- as.matrix(read.table(i)) translateresult[rownames(tmp),colnames(tmp)] <- tmp totalnet <- pmax(translateresult, totalnet) write.table(totalnet," ~/Scrivania/output") translateresult[,] <- 0 17

18 Complessità La complessità esponenziale dell algoritmo rende inaccettabile il tempo impiegato per la risoluzione del problema. Volendo fare una stima, il tempo necessario per calcolare i geni,che sono regolati da un solo gene in un instante temporale, è di circa 1 minuto. Considerando che ci sono T istanti e N geni regolatori, il tempo impiegato per il calcolo sia di circa T x N minuti. Nella nostra osservazione se N 1800 e T = 4 allora l algoritmo impiega 1800 x minuti e sapendo che un giorno è composto da 1440 minuti, il tempo di esecuzione totale è circa 5 giorni. Dato che l'input è suddiviso in sottomatrici di dimensioni K x T con K < N, il tempo di esecuzione sarà C x (K x T), dove C è il numero di sottomatrici ottenute dall'algoritmo di suddivisione della matrice principale. Tale risultato dimostra, di fatto, un miglioramento nelle prestazioni dell'algoritmo. Nel tentativo di ridurre ulteriormente il tempo di esecuzione, sarebbe utile distribuire il lavoro sulla griglia. 18

19 3.2. Grenits utilizzando Hadoop Analisi del problema L'algoritmo è stato progettato per la computazione su un singolo PC con la consapevolezza che gli input non raggiungessero dimensioni notevoli e che la stessa computazione poteva impiegare un tempo ragionevole. Se osserviamo bene la costruzione dell'algoritmo, notiamo che potremmo parallelizzare l algoritmo, poiché ogni coppia di sottomatrici dei geni può essere elaborata da un singolo PC. L'idea è di far processare a ogni macchina l'algoritmo GRENITS prendendo in input la coppia (sottomatrice Prior, sottomatrice Expr) da poter eseguire il calcolo in parallelo con più PC riducendo il tempo di esecuzione. Tale algoritmo è stato pensato di eseguirlo su una griglia e in particolare utilizzando lo strumento Hadoop che facilita la costruzione del map\reduce. 19

20 Map\Reduce per l algoritmo Grenits Input N sottomatrici Expr, N sottomatrici Prior e InputFile (contiene N linee, dove ogni linea è composta dal nome del file della sottomatrice Expr associata al nome del file della sottomatrice Prior). Output OutputFile che contiene la matrice di adiacenza dei geni regolatori con le dipendenze aggiornate. Figura Schema Map\Reduce per l'algoritmo Grenits. 20

21 SPLIT: Solitamente, la fase di split è determinata dalla quantità immensa di input non rilocabile su un singolo pc, per cui sarebbe stato necessario suddividere l'input file in split file di dimensioni più piccole, in modo da poterle allocare a ogni PC libero nella griglia. Poiché l'algoritmo Grenits non ha bisogno di grandi quantità di dati questo tipo di split non è necessario. L'input file contiene per ogni linea la coppia (Expr i, Prior i ) e ognuna di esse sarà splittata ottenendo così N blocchi. Ognuno di questi blocchi sarà associato a un map-task come valore in input. MAP: A ogni macchina disponibile sarà assegnata una coppia <chiave, valore> dove, la chiave conterrà l'indice j del blocco e il valore conterrà la coppia (Expr i, Prior i ). La macchina esegue l'algoritmo ottenendo un risultato parziale Result j e sarà associato come valore in input al reduce-task. REDUCE: Alla macchina disponibile sarà assegnata una coppia <chiave, valore> dove, la chiave conterrà l'indice 1 e il valore conterrà la lista di tutti i risultati parziali. Ultima elaborazione combinerà i risultati parziali ottenendo un'unica matrice di adiacenza salvata in OutputFile Implementazione Il linguaggio utilizzato per l'implementazione è fondamentalmente java poiché Hadoop supporta questo tipo di linguaggio. La libreria JRI sarà utilizzata per le funzioni che interfacciano il linguaggio R a sua volta utilizzato per l'algoritmo GRENITS. L'input è costituito da 800 file, dove 400 file contengono le sotto-matrici della matrice EXPR e altri 400 file contengono le sotto-matrici della matrice PRIOR. Il file input contiene la lista dei path di ogni file, ovvero, ogni linea del file è costituita da un path file per la sottomatrice EXPR e un path file per la sottomatrice PRIOR associata. Questo ci permette di ridurre l'over-head iniziale della suddivisione delle sottomatrici. La fase di split avviene sull'input file dove ogni linea del file sarà assegnata a un maptask. Ogni map-task esegue l'algoritmo su tale input e crea una cartella dei risultati. Ogni risultato sarà condotto all'unico reduce-task che costruirà un unico risultato. 21

22 I file dell'input saranno salvati su HDFS (Hadoop Distributed File System) e ogni task, prima di accedere ai file, effettuerà una copia locale del file per elaborarli e, successivamente, salverà i risultati su HDFS. Questo permette di condividere tali sottomatrici a tutte le macchine per evitare di propagare i file interi come valore nella coppia <chiave, valore>. NLINEINPUTFORMAT.java package newproject; import java.io.ioexception; import java.util.arraylist; import java.util.list; import org.apache.hadoop.conf.configuration; import org.apache.hadoop.fs.fsdatainputstream; import org.apache.hadoop.fs.filestatus; import org.apache.hadoop.fs.filesystem; import org.apache.hadoop.fs.path; import org.apache.hadoop.io.longwritable; import org.apache.hadoop.io.text; import org.apache.hadoop.mapreduce.inputsplit; import org.apache.hadoop.mapreduce.job; import org.apache.hadoop.mapreduce.jobcontext; import org.apache.hadoop.mapreduce.recordreader; import org.apache.hadoop.mapreduce.taskattemptcontext; import org.apache.hadoop.mapreduce.lib.input.fileinputformat; import org.apache.hadoop.mapreduce.lib.input.filesplit; import org.apache.hadoop.mapreduce.lib.input.linerecordreader; import org.apache.hadoop.util.linereader; /* splitta l'input file in N linee e assegna una linea ad ogni map-task */ public class NLineInputFormat extends FileInputFormat<LongWritable, Text> { public static final String LINES_PER_MAP = "mapreduce.input.lineinputformat.linespermap"; 22

23 public RecordReader<LongWritable, Text> createrecordreader( InputSplit genericsplit, TaskAttemptContext context) throws IOException { context.setstatus(genericsplit.tostring()); return new LineRecordReader(); /* splitta N linee come un unico split */ public List<InputSplit> getsplits(jobcontext job) throws IOException { List<InputSplit> splits = new ArrayList<InputSplit>(); int numlinespersplit = getnumlinespersplit(job); for (FileStatus status : liststatus(job)) { splits.addall(getsplitsforfile(status, job.getconfiguration(), numlinespersplit)); return splits; public static List<FileSplit> getsplitsforfile(filestatus status, Configuration conf, int numlinespersplit) throws IOException { List<FileSplit> splits = new ArrayList<FileSplit> (); Path filename = status.getpath(); if (status.isdir()) { throw new IOException("Not a file: " + filename); FileSystem fs = filename.getfilesystem(conf); LineReader lr = null; try { FSDataInputStream in = fs.open(filename); lr = new LineReader(in, conf); Text line = new Text(); int numlines = 0; long begin = 0; long length = 0; int num = -1; while ((num = lr.readline(line)) > 0) { numlines++; length += num; 23

24 if (numlines == numlinespersplit) { if (begin == 0) { splits.add(new FileSplit(fileName, begin, length - 1, new String[] {)); else { splits.add(new FileSplit(fileName, begin - 1, length, new String[] {)); begin += length; length = 0; numlines = 0; if (numlines!= 0) { splits.add(new FileSplit(fileName, begin, length, newstring[]{)); finally { if (lr!= null) { lr.close(); return splits; /** * Set the number of lines per split job the job to modify numlines the number of lines per split */ public static void setnumlinespersplit(job job, int numlines) { job.getconfiguration().setint(lines_per_map, numlines); /** * Get the number of lines per split job the job the number of lines per split */ public static int getnumlinespersplit(jobcontext job) { return job.getconfiguration().getint(lines_per_map, 1); 24

25 GRENITS.java package newproject; import java.io.*; import java.lang.iterable; import java.lang.reflect.field; import java.io.file; import java.io.fileinputstream; import java.io.fileoutputstream; import java.io.ioexception; import java.util.zip.gzipoutputstream; import java.util.zip.zipentry; import java.util.zip.zipoutputstream; import org.rosuda.jri.*; import newproject.nlineinputformat; import org.apache.hadoop.conf.configuration; import org.apache.hadoop.conf.configured; import org.apache.hadoop.fs.*; import org.apache.hadoop.mapreduce.lib.input.textinputformat; import org.apache.hadoop.mapreduce.lib.output.textoutputformat; import org.apache.hadoop.io.text; import org.apache.hadoop.io.longwritable; import org.apache.hadoop.util.*; import org.apache.hadoop.mapreduce.inputsplit; import org.apache.hadoop.mapreduce.job; import org.apache.hadoop.mapreduce.mapper; import org.apache.hadoop.mapreduce.reducer; import org.apache.hadoop.mapreduce.lib.input.fileinputformat; import org.apache.hadoop.mapreduce.lib.output.fileoutputformat; public class Grenits extends Configured implements Tool { protected static FileSystem fs; // FASE MAP public static class Map extends Mapper<LongWritable, Text, Text, Text> { protected Rengine re; 25

26 @Override public void map(longwritable key, Text value, Context context) throws IOException, InterruptedException { String v = value.tostring(); //Splitta i nomi dei file contenuti in value String[] namefile = v.split(" "); //Crea l'oggetto configure per le info sulla //configurazione di hadoop per caricare e scaricare i //file sull' HDFS Configuration configuration = new Configuration(); fs = FileSystem.get(configuration); String hdfs="hdfs://master:9000/user/huser/"; String local="/usr/local/hadoop/tmp/"; Path[] src=new Path[nameFile.length]; Path[] des=new Path[nameFile.length]; //Carica i file in locale e memorizza i nomi try{ for(int i=0; i< namefile.length;i++){ System.out.println(hdfs+"job/"+nameFile[i]); System.out.println(local+"job/"+nameFile[i]); src[i] = new Path(hdfs+"job/"+nameFile[i]); des[i] = new Path(local+""+nameFile[i]); fs.copytolocalfile(src[i], des[i]); //Se ha caricato entrambi i file if(src.length==2 && des.length==2){ // separo il nome expr00x dall'estensione String[] namefolder = src[0].getname().split("\\."); // file che conterrà il risultato // (matrice probabilistica) //hdfs://localhost:9000/user/hadoop/mapper/result_expr00x.txt String remotefolder = hdfs+"mapper/result_"+src[0].getname(); 26

27 // cartella locale che contiene i risultati // temporanei // /usr/local/hadoop/tmp/result_expr00x String localfolder = local+"result_"+namefolder[0]; // file locale che contiene il risultato //finale (matrice probabilistica) // /usr/local/hadoop/tmp/result_expr00x.txt String nameresult = local+"result_"+src[0].getname(); REXP x; Text newkey = new Text("result_map"); re.eval("expr <- as.matrix( read.table('"+des[0].tostring()+"'))"); re.eval("prior <- as.matrix( read.table('"+des[1].tostring()+"'))"); re.eval("output.folder<-'"+localfolder+"'"); re.eval("linearnet(output.folder, expr,fixme=prior)"); System.out.println(localFolder); re.eval("analyse.output(output.folder, timeseries = express)"); re.eval("chain1 <- read.chain(output.folder,1)"); re.eval("chain2 <- read.chain(output.folder,2)"); re.eval("gamma1 <- colmeans(chain1$gamma)"); re.eval("gamma2 <- colmeans(chain2$gamma)"); re.eval("prob.file <- paste(output.folder, '/NetworkProbability_Matrix.txt', sep = '')"); re.eval("file.rename(prob.file, '"+nameresult+"')"); fs.movefromlocalfile(new Path(nameResult), new Path(remoteFolder)); value.set(remotefolder); context.write(newkey, value); 27

28 System.out.println(des[0].toString()); System.out.println(des[1].toString()); System.out.println(localFolder); fs.delete(new Path(des[0].toString()), true); fs.delete(new Path(des[1].toString()), true); else throw new IllegalStateException("Path src and des are null pointer(dim < 2)"); catch (Exception e) { e.printstacktrace(); //viene lanciato solo la prima volta e avvia R con le librerie //da utilizzare ad ogni esecuzione del metodo protected void setup(context context) throws IOException, InterruptedException { super.setup(context); String[] args = {"--vanilla", "--slave"; re=new Rengine(args, true, null); // the engine creates R is a new thread, // so we should wait until it's ready if (!re.waitforr()) { throw new IllegalStateException("*** R: cannot start the engine."); re.eval("library(grenits)"); re.eval("library(biobase)"); 28

29 //viene lanciato solo una volta e chiude protected void cleanup(context context) throws IOException, InterruptedException { if (re == null) { return; re.end(); if (!re.waitforr()) { System.out.println("*** R: engine is stopped."); else { System.err.println("*** R: engine turned to zombie."); super.cleanup(context); // FASE REDUCE public static class Reduce extends Reducer<Text, Text, Text, Text> { protected Rengine public void reduce(text key, Iterable<Text> values, Context context)throws IOException, InterruptedException { Configuration configuration = new Configuration(); fs = FileSystem.get(configuration); String hdfs="hdfs://master:9000/user/huser/"; String local="/usr/local/hadoop/tmp/"; // copia i risultati nella cartella locale tmp Path src=new Path(hdfs+"mapper"); Path des=new Path(local+"input"); fs.copytolocalfile(src, des); try{ re.eval("resultlist <- list.files(path='"+local+"input', pattern = 'result_expr', full.names = TRUE, recursive = FALSE)"); re.eval("totalnet <-as.matrix( read.table(resultlist[1]))"); re.eval("totalnet[,] <- 0"); re.eval("translateresult <- totalnet"); // legge ogni risultato in locale ed effettua il reduce re.eval("dir.create('"+local+"result_reduce', showwarnings = TRUE, recursive = FALSE)"); 29

30 re.eval("for(i in resultlist){"+ "tmp <- as.matrix(read.table(i));"+ "translateresult[rownames(tmp),colnames(tmp)] <- tmp;"+"totalnet <- pmax(translateresult, totalnet);"+"translateresult[,] <- 0 "); // sposta i risultati nella cartella output master re.eval("write.table(totalnet,'"+local+"result_reduce')"); fs.movefromlocalfile(new Path(local+"result_reduce"), new Path(hdfs+"reduce")); catch(exception e){e.printstacktrace(); Text value = new Text(hdfs+"reduce"); key.set("reduce"); protected void setup(context context) throws IOException, InterruptedException { super.setup(context); String[] args = {"--vanilla", "--slave"; re=new Rengine(args, true, null); // the engine creates R is a new thread, // so we should wait until it's ready if (!re.waitforr()) { throw new IllegalStateException("*** R: cannot start the engine."); re.eval("library(grenits)"); re.eval("library(biobase)"); Configuration configuration = new Configuration(); fs = FileSystem.get(configuration); String hdfsworkspace = "hdfs://master:9000/user/huser/job/preprocessgrenits_workspace"; String localworkspace = "/usr/local/hadoop/tmp/preprocessgrenits_workspace"; fs.copytolocalfile(new Path(hdfsWorkspace), new Path(localWorkspace)); re.eval("load('"+localworkspace+"')"); 30

31 @Override protected void cleanup(context context) throws IOException, InterruptedException { if (re == null) { return; re.end(); if (!re.waitforr()) { System.out.println("*** R: engine is stopped."); else { System.err.println("*** R: engine turned to zombie."); super.cleanup(context); public static void main(string[] args) throws Exception { Configuration configuration = new Configuration(); int n=1; //Setta il numero di coppie <key,value> di default è 1 if(args.length > 2) n=integer.parseint(args[2]); configuration.setint("mapreduce.input.lineinputformat.linespermap", n); int rc = ToolRunner.run(configuration, new Grenits(), args); System.exit(rc); public int run(string[] args) throws Exception { Job job = new Job(); job.setjarbyclass(grenits.class); job.setjobname("grenits"); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); job.setmapperclass(map.class); job.setreducerclass(reduce.class); job.setnumreducetasks(1); job.setinputformatclass(nlineinputformat.class); job.setoutputformatclass(textoutputformat.class); job.setoutputkeyclass(text.class); job.setoutputvalueclass(text.class); return rc; 31

32 3.3. Prestazioni e Benchmarking Installazione ambiente e software Hadoop Distributed Hadoop Distributed è un framework che supporta applicazioni con un elevato numero di accessi ai dati. Esso, infatti, permette alle applicazioni di lavorare con migliaia di nodi e petabyte di dati, al fine di ridurre il tempo computazionale di algoritmi molto complessi. Per ovvi motivi, siamo intenzionati ad utilizzare Hadoop per dimostrare che l'algoritmo GRENITS migliori le sue prestazioni notevolmente in confronto al semplice calcolo su un singolo calcolatore. VMPlayer VMPlayer è un software open source, utilizzato per eseguire la macchina virtuale con sistema operativo Ubuntu e provvedere all'installazione di Hadoop. E' utile per utilizzare i diversi PC del laboratorio e di fatti rappresenta un player di macchine virtuali cui è possibile adattare diversi tipi di sistemi operativi sia a 32 e sia a 64 bit. R, librerie Grenits e Biobase, relative dipendenze L'algoritmo GRENITS è stato implementato in R e ha usufruito di due particolari librerie, Grenits e Biobase, per l'utilizzo di alcune funzioni già implementate all'interno di ognuna di esse. L'installazione delle librerie ha comportato all'installazione di ulteriori dipendenze, per far sì, che l algoritmo possa essere eseguito correttamente e secondo i risultati attesi e prevedibili durante l'esecuzione su un singolo calcolatore. 32

33 JRI (Java R Interface) Hadoop utilizza il linguaggio Java è necessario quindi utilizzare una libreria che potesse interfacciare Java con R. JRI (Java R Interface) è un'interfaccia che fornisce una serie di API che permettono di richiamare funzioni R tramite il linguaggio Java Configurazione hw e sw Configurazione PC Intel Celeron(R) CPU G530 2x2.40 GHz 4 GB RAM WIN 7 32 bit 120 GB Hard-Disk Disponibilità PC: 39 macchine (38 slaves e 1 master) Configurazione VM (Master) Intel Celeron(R) CPU G530 2x2.40 GHz 2 GiB RAM Ubuntu bit 20.1 GB Hard-Disk Configurazione VM (Slave) Intel Celeron(R) CPU G530 2x2.40 GHz 2 GiB RAM Ubuntu bit 51.8 GB Hard-Disk 33

34 Elementi di valutazione per il benchmarking Saranno introdotti alcuni elementi di valutazione standard per i test di benchmark effettuati su una griglia e relativi al problema trattato. Saremo interessati a valutare principalmente il tempo totale di computazione dell'algoritmo sulla griglia di computer e confrontare l'andamento con l'aumentare dei nodi PC. Il risultato atteso è il miglioramento del tempo di cpu con l'aumentare dei nodi PC. Soltanto questo elemento di valutazione non è sufficiente poiché è stata utilizzata una griglia che ha un'architettura composta da più fasi prima che l'algoritmo per ogni PC sia processato, è necessario quindi prendere in considerazione il tempo di over-head. Anche in questo caso l'over-head lo valuteremo all'aumentare dei nodi presupponendo che abbia un andamento crescente. Vari fattori potranno influenzare il tempo di cpu e l'over-head a causa di probabili malfunzionamenti di nodi che comporteranno a ritentare una fase di map\reduce sullo stesso nodo o in caso di rottura del nodo, la computazione sarà condivisa da meno nodi iniziali. Al verificarsi di ognuna delle anomalie è consigliabile ripetere il test più di una volta per evitare di introdurre tempo aggiuntivo alla computazione. 34

35 Test e risultati del benchmark Avendo a disposizione PC dual-core e installato le macchine virtuali su ognuno di essi, il primo test effettuato è stato basato sulla performance del PC impostato sia come singlecore sia dual-core. Poiché il problema trattato impiega abbastanza tempo, allora utilizziamo una quantità ridotta di input tale da computare l'algoritmo in tempo ragionevole. E' necessario tenere sotto controllo la memoria utilizzata per evitare che l'algoritmo fallisca. La Figura rende evidente la perfomance dei due PC impostati dalla macchina virtuale sia come single-core sia dual-core. ---> Test con 2 input slave12 single-core real 23m45.810s user 0m2.848s sys 0m0.496s slave26 dual-core real 14m3.430s user 0m2.032s sys 0m0.448s slave12 dual-core real 14m58.594s user 0m2.188s sys 0m0.356s Figura : Test prestazioni tra PC single-core e dual-core Osserviamo che il PC single-core impiega quasi il doppio del tempo di un PC dual-core ma è ben evidente che se i due input fossero processati in parallelo da due PC singlecore impiegherebbero meno tempo di un solo PC dual-core. Se il numero di PC fosse infinito, allora la scelta migliore sarebbe utilizzare PC singlecore per la computazione evitando così over-head tra gli stessi PC dual-core. Tenendo conto della disponibilità istantanea dei PC nel laboratorio non sarebbero stati sufficienti utilizzare PC single-core, per cui sono stati utilizzati PC dual-core usufruendo al massimo le risorse per la computazione dell'algoritmo GRENITS. 35

36 La Figura evidenzia l'utilizzo della memoria da parte dei due tipi di PC utilizzati. --> Memory Test slave12 single-core real 196MB.676KB virtual 1987MB.53KB slave26 dual-core real 196MB.746KB virtual 1989MB.39KB slave12 dual-core real 196MB.890KB virtual 1993MB.89KB Figura : Memory test tra PC single-core e dual-core Notiamo che in entrambi i casi, la memoria reale utilizzata è circa 200 MB e la memoria virtuale utilizzata è circa 2000 MB mantenendo così un uso piuttosto costante. Per ulteriori facilitazioni per la fase di benchmark dell'algoritmo i test sono stati iniziati con l'utilizzo di 4 PC per evitare l'enorme attesa di esecuzione completa dell'algoritmo. La Figura mostra i risultati dei test con PC su 400 input. ---> Test con 400 input Test 4 pc ideal 4753/8 = about 595 minutes real 720m56.004s user 0m33.578s sys 0m11.153s Test 8 pc ideal 4753/16 = about 298 minutes real 401m25.855s user 0m14.897s sys 0m8.337s Test 16 pc ideal 4753/32 = about 149 minutes real 235m37.947s user 0m10.593s sys 0m5.308s 36

37 Test 32 pc ideal 4753/64 = about 75 minutes real 138m3.866s user 0m5.860s sys 0m4.748s Figura : Test Benchmark con 32 pc dual-core Prima di eseguire delle valutazioni sui risultati dei test è necessario, invece, calcolare delle stime di test nel caso in cui si utilizza un singolo PC poiché impiegherà abbastanza tempo e prendiamo in considerazione i test effettuati sul singolo PC nel caso in cui siano single-core e multi-core. La Figura mostra i test stimati su 400 input per il singolo PC. ---> Test con 400 input Test 1 pc estimate slave12 single-core real 4600m+( )s = about 4753 minutes estimate slave26 dual-core ideal 4753/2 = about 2377 minutes real 2800m+(600+86)s = about 2812 minutes estimate slave12 dual-core ideal 4753/2 = about 2377 minutes real 2800m+( )s = about 2997 minutes average-estimate slave12-26 dual-core ideal 4753/2 = about 2377 minutes real about 2905 minutes Figura : Estimate Test PC single-core Si noti la stima ottenuta dal PC single-core che ha un tempo di computazione abbastanza alto ed è utilizzato come riferimento per calcolare altre stime sia per il tempo ideale e sia per il tempo reale di computazione, da poter confrontare in seguito e determinando l'over-head. Due PC dual-core hanno impiegato tempi diversi per la computazione per cui è stata calcolata una stima media. 37

38 E' possibile ora riassumere tutti i test in un'unica tabella evidenziando il tempo ideale, il tempo reale e l'over-head (sia in minuti sia in percentuale) come in figura Resume Test Benchmark - PC dual-core 1 PC 4 PC 8 PC 16 PC 32 PC Ideal-time(m) Real-time(m) Over-head(m) Over-head(%) Figura : Tabella Test Benchmark riassuntiva con PC dual-core La Figura mostra il tempo reale di esecuzione rispetto al tempo ideale atteso Ideal-time(m) Real-time(m) PC 4 PC 8 PC 16 PC 32 PC PC dual-core Figura : Execution Time (ideal & real) con PC dual-core Osserviamo che all'aumentare dei nodi il tempo di esecuzione reale si avvicina a quello ideale ma ci sarà un limite a quest'andamento dovuto al crescente over-head. Accadrà che a un certo numero di PC, il tempo di esecuzione dell'algoritmo sarà nettamente superiore al tempo ideale di esecuzione. 38

39 La figura mostra di quanto aumenta l'over-head all'aumentare dei nodi PC 4 PC 8 PC 16 PC 32 PC PC dual-core Over-head(%) Figura : Over-head of Execution Time Osservando l'andamento potrebbe accadere che con più di 32 PC l'over-head possa raggiungere il 100% e peggiorare di volta in volta con situazioni di % di overhead, questo implica che il tempo di esecuzione è 3-4 volte maggiore rispetto al tempo ideale. Successiva osservazione in riguardo all'over-head, nel nostro caso non è soltanto dovuto alla preparazione delle varie fasi di map\reduce(caricamento librerie di R, split del file, ecc ) come accennato nel paragrafo ma da alcuni nodi che hanno ripetuto l'esecuzione del job o addirittura abbandonato la griglia per il verificarsi di alcuni errori, riducendo così le prestazioni dell'algoritmo. Il test è stato ripetuto più volte e sono stati scelti i risultati migliori. I vari errori avvenuti nella fase di test sono stati riportati nei log-file e si sono presentati molte volte nella stessa fase di test in diverse tipologie: 1) java.io.ioexception: Task process exit with nonzero status of 1. at org.apache.hadoop.mapred.taskrunner.run(taskrunner.java:418) 2) Error: Java heap space 3) Lost task tracker: tracker_slave3:localhost/ :

40 E' possibile eseguire sulla stessa macchina 4 tentativi dopodiché la macchina viene esclusa dalla computazione. Figura : Test Benchmark - 4 PC dual-core La Figura dimostra che erano necessari 400 map-task per la computazione ma sono stati aggiunti altri 8 map-task dovuti a 7 fallimenti e 1 abbandono del task comportando ulteriori tempi aggiuntivi alla computazione dell'algoritmo. Lo stesso problema si è verificato nei successivi test come mostrati nelle figure , e e possiamo notare che all'aumentare il numero di nodi, maggiore è la probabilità che un task fallisca o sia abbandonato. L'andamento dell'over-head che è stato esaminato in precedenza è contaminato fortemente dalla presenza degli errori comportando ognuno di essi una perdita di tempo tra i minuti. Figura : Test Benchmark - 8 PC dual-core 40

41 Figura : Test Benchmark - 16 PC dual-core Figura : Test Benchmark - 32 PC dual-core 41

42 4. Conclusioni Hadoop ha prodotto grandi risultati sul tempo di esecuzione dell'algoritmo GRENITS raggiungendo così grandi miglioramenti. Per i nostri obiettivi è stato sufficiente ottenere questi risultati ma denotiamo quali sono alcune considerazioni ricavate dai rispettivi test: 1) Più PC sono utilizzati nella griglia, migliore è il tempo di esecuzione. 2) Più PC sono utilizzati nella griglia, più aumenta l'over-head, sommando tempi aggiuntivi al tempo totale di esecuzione reale. 3) Coinvolgere molti PC alla computazione comporta ad aumentare la probabilità di malfunzionamenti di alcuni PC riducendo così le prestazioni. Possiamo concludere che la scelta del numero di PC da utilizzare per la computazione è determinata dall'over-head. Possiamo calcolare il numero di PC da utilizzare per l'elaborazione dell'algoritmo GRENITS facendo aumentare di volta in volta i PC e fermarsi appena il tempo impiegato ottenuto sia maggiore di quello precedente. Inoltre per la forte probabilità di malfunzionamenti sarebbe opportuno utilizzare un ridotto numero di PC. 42

43 Riferimenti [1] Grid Computing: CEEQFjAG&url=http%3A% [2] GRENITS: Gene Regulatory Network Inference Using Time Series, Edward R.Morrissey, Systems Biology Doctoral Training Centre, University of Warwick, March 31, [3] Dynamic Bayesian network and nonparametric regression for nonlinear modeling of gene networks from time series gene expression data, Sunyong KimCorresponding author, Human Genome Center, Institute of Medical Science, University of Tokyo, Shirokanedai, Minato-ku, Tokyo , Japan. 43