1

Big Data applicati alla bioinformatica Tesina: Standard e tecnologie e supporto dei database biomedici Giuseppe Stumpo - 215HHHINGINFOR

2

INDICE Introduzione 3 Panoramica sui database biologici 6 Il formato FASTA 8 BLAST 9 GenBank 16 Tecnologie di elaborazione: Hadoop 19 Tecnologie di elaborazione: Spark 22 Caso di Studio: RefSeq, tre script in map-reduce su un dataset testuale contente informazioni sui Virus

26

Fonti 32

3

Introduzione Quando si parla di big data e delle tecnologie annesse per l’acquisizione e il trattamento di tali dati, un settore di rilievo e di notevole spicco è ricoperto dalla bioinformatica e dai dati biomedici. La bioinformatica è l’unione di due discipline, quella medica e quella informatica, si è sviluppata per fornire elementi e strumenti a supporto delle strutture e delle figure mediche, raggiungendo nuovi orizzonti e dando un nuovo impulso alla ricerca. Negli ultimi due decenni si è registrato un notevole aumento dei dati biomedici, sia per il fatto che le strutture hanno quasi completamente adottato l’archiviazione elettronica, sia per le metodologie di ricerca che coinvolgono sempre di più gli strumenti del mondo informatico. In questi archivi clinici possiamo trovare una moltitudine di tipologie di dati a partire da quelli tipici in formato testuale a finire a quelli visivi come lastre e immagini. La crescita dei dati del settore è anche dovuta al cambiamento dei metodi e strumenti stessi di analisi che hanno valicato il confine dalla “provetta” al “silicio”, se infatti prima le analisi e le osservazioni venivano effettuati gran parte in laboratorio, oggi grazie a modelli e ai simulatori, queste osservazioni ed esperimenti vengono sempre più virtualizzati tramite appositi sistemi. Altro fattore di notevole importanza inoltre è dato dai sequenziatori di DNA di nuova generazione, dal gennaio del 2008 viene adottata su larga scala l’NGS1 con la conseguente crescita di dati genomici in archivi di settori, come ad esempio il Genbank2

. Nel seguente grafico infatti possiamo apprezzare come la crescita dei dati archiviati in questo database stia aumentando notevolmente.

Figura 1: Crescita dei dati registrati in GenBank

1 Next Generation Sequencing, serie di tecnologie per il sequenziamento di genomi in tempi ristretti 2 Archivio di dati genomici

4

NGS ha ridotto, e sta riducendo i costi di sequenziamento del DNA, fornendo quindi sempre più dati che necessitano di una notevole potenza di calcolo per gli studi di settore e le ricerche annesse. Ricordiamo che nel campo dei dati si può iniziare a parlare di “Big” data anche per file nell’ordine di 1 GB, se questo file non può essere processato da una sola macchina. La notevole crescita dei dati medici, dovuta a molteplici fattori quindi, proietta una realtà con un panorama dove i dati sono e saranno in continuo aumento, e dove le tecnologie di processamento, trattamento e di data mining3

Il processo generale indicato con l’acronimo KDD

troveranno sempre più terreno fertile.

4

che trasforma i dati in conoscenza può essere schematizzato e suddiviso nelle seguenti parti:

1) Pre-Processing: tipica fase di trattamento dei dati 2) Data-Mining: fase in cui vengono applicati determinati algoritmi e procedure

per l’estrapolazione della conoscenza 3) Post-Processing: fase che può riguardare l’analisi successiva e la

presentazione dei risultati. C’è da specificare e sottolineare come questo processo non riguardi ovviamente solo l’aspetto relativo ai dati biomedici ma bensì rappresenti un approccio più generale, che ovviamente pone a monte sempre degli obiettivi, che riguardano il trattamento dei big data in svariati settori come quello commerciale piuttosto che quello della social analitycs:

Figura 2: Ciclo di vita dei dati, Fonte: https://www.voksedigital.com

3 Processo per l’estrazione di conoscenza da grandi moli di dati 4 Acronimo di knowledge Discovery in databases

5

I big data relativi a questo settore , sono complessi, e richiedono un enorme quantità e potenza di calcolo, occorre specificare inoltre che tali dataset5

1) Volume: Le dimensioni dei dataset eccedono i terabyte di dati di capacità se si pensa ad esempio che il genoma umano è rappresentato da circa 3.000.000.000 di basi, all’incirca dai 20.000 ai 30.000 mila geni e più di 100.000 proteine. un genoma umano in fase di post-processing, con dati trattati e puliti arriva ad occupare circa 700 MB, a fronte di 200 GB dei dati rudi estratti dai sequenziatori.

sono distribuiti geograficamente, poiché hanno un enorme volume, crescono rapidamente, e hanno un alto valore, in quanto i dati che popolano questi dataset, non hanno “decadimento”, ovvero un dato biologico mantiene comunque il suo valore nel tempo, rispetto ad esempio ad altri tipi di dati. Per sintetizzare dunque possiamo parlare anche in questo settore specifico dei big data delle “5 V”:

2) Velocità: Questa proprietà si riferisce sia alla velocità di trasferimento di questi grandi quantità di dati sia alla velocità di generazione di tali dati, basti solo pensare alle tantissime strutture che li generano.

3) Varietà: Siamo di fronte ad una grande eterogeneità di dati, che non riguardano prettamente la biologia umana, che già come dominio contiene un enorme varietà, ma anche l’agricoltura piuttosto che il settore bellico.

4) Veracità: i dati sono complessi e hanno bisogno di opportuni processi per essere trattati e puliti, ad esempio nei sequenziatori NGS capita spesso di trovare ridondanze da eliminare, questi dati possono contenere quindi degli errori e si ha bisogno di tecniche di controllo della qualità.

5) Valore: i dati di questo settore come detto non hanno decadimento di valore, una valore inteso sia a livello di mercato che soprattutto di conoscenza.

Una delle principali sfide risiede nello storage di questi dati, come sappiamo ad esempio dal punto di vista clinico in Italia siamo di fronte ad una realtà molto frammentata con tante strutture fornite da diversi sistemi, alcuni molto datati, che contengono questi dati, un obiettivo interessante sarebbe quindi avere questi dati in un unico database al servizio della ricerca e delle cliniche stesse. Stessa cosa nel settore genetico, anche se qui abbiamo delle realtà più evolute rispetto alla realtà clinica, con importanti database che costituiscono già al giorno d’oggi un notevole punto di riferimento.

5 Collezione di dati, strutturati o non strutturati

6

Panoramica sui database biologici Un database biologico è un insieme di record, attributi e valori che contiene dati di tipo biologico, come accennato in precedenza possono riguardare le molecole di DNA, RNA, proteine, etc. A livello tecnologico queste basi di dati possono essere implementate dai tipici database relazionali, implementati quindi in tabelle e possono essere interrogati tramite linguaggi come SQL e derivati, tuttavia, spesso, molti di questi database sono di tipo non strutturato, composti da semplici file o file testuali. Molti di questi database sono accessibili liberamente sul web, altri hanno bisogno di un autorizzazione per potervi accedere, i maggiori DBs6

• Data coverage: ovvero che obiettivo hanno e cosa coprono questi dati.

di questo settore possono essere trovati nella rivista Nucleic Acid Research, in Database, oppure su repository web quali biodbs.info, pathguide.org ed NCBI. E’ importante definire una classificazione di questi DBs, in modo tale da avere un orientamento in questo settore e capire quali metodi utilizzare per sfruttarli. I criteri di classificazione possono riguardare:

• Livello di manutenzione: ad esempio ogni quanto vengono aggiornati e controllati questi dati.

• Metodo di manutenzione: se sono sottoposti a metodi automatizzati e/o vi è anche una manutenzione manuale più approfondita.

• Tipo di dati: formato e tipo. Il data coverage, può essere considerato uno dei criteri migliori poiché individua la tipologia del database con cui si a che fare. Possiamo avere quindi un data coverage di tipo Comprehensive, che comprende i database che contengono informazioni complete come ad esempio:

• Genbank • EMBL-EBI • DDBJ

Esistono poi DBs più specializzati, che hanno un set di dati dedicato ad un particolare settore come ad esempio:

• TCGA: dati sulla patologia del cancro • PPD: dati su proteine • HGMD: Contiene dati sulle mutazioni dei geni umani

6 Abbreviazione di Databases

7

Al centro di questi DBs ovviamente troviamo i dati, che rappresentano il punto focale e la linfa vitale per cui queste tecnologie e la ricerca stessa esiste. Abbiamo brevemente accennato in precedenza che tipo di dati possiamo trovare in questi supporti, ma è bene fare un approfondimento ulteriore per avere più coscienza e capire meglio ai fini di questo elaborato cosa questi DBs memorizzano. Il tipo di dati ovviamente può essere considerato un criterio stesso di classificazione, Possiamo avere quindi in linea generale queste tipologie:

• Dati relativi alle molecole di DNA, RNA e proteine. • Dati relativi ad esperimenti. • Dati relativi a rilevazioni tramite imaging ad esempio PET e lastre. • Dati clinici, che sono i tipici dati che descrivono valori relativi ad esempio a

risultati di analisi di sangue, urina, etc. I metodi e le tecniche di progettazione/gestione e interrogazione di questi DBs sono riconducibili agli strumenti conosciuti come ad esempio modelli E/R, implementazione tabellare e linguaggio SQL e suoi derivati per query. Al giorno d’oggi molti dei principali DBs offrono un interfaccia web per le interrogazioni, ad esempio EMBL-EBI7

nella propria homepage presenta due immediati campi di ricerca come nella seguente immagine:

Figura 3: EMBL-EBI moduli web per la ricerca

7 Archivio europeo dati genomici

8

Il Formato FASTA

Occorre fare un ulteriore precisazione in merito a questi database, parlare delle basi su cui si poggia la memorizzare e la ricerca delle sequenze di DNA, RNA e proteine. Questi DBs hanno l’obiettivo chiaro ed esplicito di memorizzare le sequenze di molecole, di ricercarle e rendere accessibili i file che contengono questi dati. La prima base risiede nel formato in cui le sequenze genomiche, dal punto di vista informatico possano essere rappresentate e quindi memorizzate. In questo ci viene in aiuto lo standard FASTA che in sostanza usa una rappresentazione mono - carattere per ogni molecola della sequenza, nel DNA ad esempio abbiamo quattro possibili molecole quali Adenina, Citosina, Timina e Guanina, i caratteri corrispondenti sono A,C,T,G. Per l’RNA le sequenze sono rappresentate anche dai quattro caratteri A,C,U,G, simile al DNA solo che al posto della timina abbiamo l’Uracile. Per le proteine invece le sequenze sono rappresentate da circa 20 caratteri che ne identificano le basi rispettive. Il notevole e complesso flusso informativo riferito solo quindi ai campi che memorizzano la serie di stringhe relative alla successione delle basi ha trovato in questo standard un notevole supporto. Il formato FASTA quindi, introdotto nel 1985, codifica la sequenza di molecole con le relative lettere associate, questa idea semplifica il trattamento e il parser delle sequenze da parte dei linguaggi di programmazione. Nello specifico una sequenza in formato FASTA viene preceduta da una riga di descrizione che inizia con il carattere “>”, dopo la descrizione, nella riga successiva si ha la sequenza:

>SEQUENCE_1 MTEITAAMVKELRESTGAGMMDCKNALSETNGDFDKAVQLLREKGLGKAAKKADRLAAEG LVSVKVSDDFTIAAMRPSYLSYEDLDMTFVENEYKALVAELEKENEERRRLKDPNKPEHK IPQFASRKQLSDAILKEAEEKIKEELKAQGKPEKIWDNIIPGKMNSFIADNSQLDSKLTL MGQFYVMDDKKTVEQVIAEKEKEFGGKIKIVEFICFEVGEGLEKKTEDFAAEVAAQL >SEQUENCE_2 SATVSEINSETDFVAKNDQFIALTKDTTAHIQSNSLQSVEELHSSTINGVKFEEYLKSQI ATIGENLVVRRFATLKAGANGVVNGYIHTNGRVGVVIAAACDSAEVASKSRDLLRQICMH Questo formato, inizialmente nato per i software della pacchetto FASTA, si è esteso nei principali DBs del settore biomedico. NCBI8

8 Ente governativo americano che coordina e gestisce vari database del settore biomedico

nella sua documentazione relativa agli input accettati nei form web per le query di ricerca indica il formato FASTA come uno dei possibili, gli altri due formati

9

sono il Bare Sequence, che altri non è che la sequenza senza la prima linea descrittiva come nel formato FASTA nativo, o l’identifiers, un codice univoco alfanumerico che identifica la tupla9

BLAST

del DB direttamente. L’adozione di questo standard nel formato si è reso necessario per vari motivi, abbiamo anticipato già in precedenza che rappresentare le molecole con i relativi caratteri facilità il compito perché trattiamo questi dati come delle stringhe, questo significa sfruttare le librerie di manipolazione e trattamento per le stringhe appunto che tutti i linguaggi di programmazione dispongono quasi di default, il formato FASTA inoltre consente anche una buona leggibilità all’occhio umano e facilita anche le tecniche di ricerca di sequenze specifiche.

Una volta definito il formato con cui le sequenze vengono memorizzate, la seconda base è rappresentata dalla tecnologia di ricerca delle sequenze. BLAST , che nel settore della bioinformatica è l’acronimo di Basic Local Alignment Tool è in sintesi un software per comparare i dati di sequenze genomiche. Dalla documentazione ufficiale viene definito BLAST come un tool capace di comparare sequenze di nucleotidi10

1. Scelta della sequenza

o proteine calcolandone la corrispondenza e presentando i valori tramite una valutazione poggiata su parametri statistici. BLAST è una tecnologia proprietaria di NCBI, esiste anche una versione open-source chiamata mpiBLAST. BLAST è un metodo di “approssimazione”, o più precisamente un metodo euristico di allineamento, ovvero nelle sue procedure non effettua un confronto puro e preciso delle sequenze, ma sfrutta una tecnica basata sugli indici che garantisce dei risultati vicini a quelli ottimali in tempi brevi. BLAST può essere sfruttato e fruito in vari modi, sulla piattaforma web NCBI tramite i form offerti, oppure tramite API fornite dalla stessa NCBI piuttosto che tramite interfaccia. Tipicamente una procedura BLAST è suddivisa in quattro parti:

2. Scelta dell’algoritmo BLAST 3. Scelta del database 4. Scelta di parametri opzionali

9 riga di un database che racchiude più attributi 10 Unità che compongono la molecola del DNA

10

La sequenza può essere immessa in formato FASTA o come accession number (RefSeq11

) come da esempio in questo screen tratto da NCBI:

Figura 4: Eseguire BLAST con una sequenza in formato FASTA su NCBI

La scelta del programma/algoritmo si riferisce al metodo da utilizzare, ne esistono vari specifici per determinate sequenze, ad esempio Protein blast cerca nel database di proteine una sequenza di proteine, un esempio dei metodi disponibili nell’immagine a seguire:

Figura 5: Alcuni degli algoritmi BLAST disponibili

11 Archivio di dati genomici

11

Gli algoritmi disponibili sono:

• Blastn: cerca sequenze di nucleotidi nel database di nucleotidi • Blastp: cerca sequenze di proteine nel database di proteine • Blastx: cerca sequenze di nucleotidi tradotti nel database di proteine • tBalstm: cerca sequenze di proteine nel database di nucleotidi tradotti • tBlast: cerca sequenze di nucleotidi tradotti nel database di nucleotidi tradotti

La scelta del database può riguardare la scelta tra database di nucleotidi o quello delle proteine, come già gli algoritmi BLAST ci suggeriscono. I parametri opzionali invece si riferiscono ad opportuni filtri come la scelta dell’organismo o di altri parametri più specifici alla qualità della ricerca legate alla meccanica dello stesso algoritmo. Come detto BLAST è una procedura che sfrutta una tecnica di allineamento, vediamo a grandi linee come lavora. La proceduta ha inizio con la creazione di parole di lunghezza W chiamati W-MERS che soddisfano un punteggio maggiore ad una soglia T, questo punteggio viene calcolato secondo una matrice di sostituzione:

Un esempio di Matrice di corrispondenza dove vengono calcolati i valori è la Blosum62:

12

Il prossimo passo che svolge la procedura è la scansione del database per le voci della lista che hanno superato la soglia, questa procedura è relativamente veloce perché i database sono già indicizzati per la ricerca di parole di lunghezza w tramite l’uso di tabelle hash.

Un esempio di sequenza da indicizzare con parole di lunghezza w=2:

ATHCGTAATGCGATATGTA La tabella hash consente di tenere traccia di tutte le sequenze di lunghezza w di una data sequenza, questo velocizza la ricerca dei relativi “seed12

” .

Il terzo passo riguarda l’estensione della ricerca, quando viene avviene un “hit13

” nel database, sia verso destra che verso sinistra.

Figura 6: estensione dell'allineamento in BLAST

Spieghiamo meglio questo concetto, quando viene trovato un seed corrispondente con una sequenza, viene fatta una opportuna verifica con le altre sequenze sia a

12 Seme, dove inizia l’allineamento in corrispondenza della parola w in una sequenza 13 Corrispondenza nel database della parola di lunghezza w

13

destra che a sinistra del seed. Nella prima versione di BLAST bastava un hit per procedere alla estensione, dal 1997 nella versione successiva di BLAST, per poter procedere con l’estensione sono necessari due hit vicini, entro una certa distanza A, in questo modo avvengono meno estensioni e si ha un maggiore risparmio di tempo. Quando si accennava degli altri parametri selezionabili in BLAST prima di avviare la ricerca, sono appunto la soglia T e la dimensione delle parole w, che di default è 3, notiamo nel seguente grafico come la scelta di questi due parametri influisca sulla ricerca, ad esempio parole più grandi possono produrre meno hit a discapito della sensibilità:

C’è da precisare che l’estensioni che verranno prese in considerazione devono essere maggiori di uno “score” S. Questo score viene tenuto in considerazione secondo un parametro chiamato HSP, high score segment pair che indica in sostanza la similarità di allineamento della sequenza immessa nella query e quella trovata, vengono inoltre usati nell’allineamento dei caratteri “+” e “–“ che indicano la similarità della sequenza o la diversità, chiariamo questo concetto con la seguente immagine:

14

Gli HSP quindi con un certo score al di sotto di una soglia S vengono scartati. Come sappiamo BLAST opera su database che contengono milioni di sequenze, questo significa che un allineamento che corrisponde non potrebbe avere una rilevanza biologica, in questo caso occorre una valutazione statistica degli allineamenti, ad ogni sequenza quindi presentata in output BLAST associa un parametro chiamato “E-Value” , valore che indica quanto è probabile che il punteggio S indichi una correlazione biologia tra le due sequenze. Vediamo nello specifico un esempio di come BLAST produce l’output. Come prima cosa mostra una pagina con l’id della richiesta ed altre info generali: Successivamente viene presentata una rappresentazione grafica che va interpretata in questo modo:

• la linea rossa spessa e graduata rappresenta la sequenza della query; • i numeri sotto di essa si riferiscono alla sua lunghezza in basi ( caratteri ); • ciascuna linea sottile sottostante, di vari colori, indica un allineamento della

suddetta sequenza con una sequenza del database; • il colore di tali linee indica la bontà dell’allineamento, in base alla scala

colorimetrica posta all’inizio dell’immagine (rosso - migliore, nero - peggiore); • passando su ciascuna linea sottile con la freccia del mouse, sul riquadro subito

sopra l’immagine compare la descrizione della sequenza nucleotidica del database con cui la sequenza query si allinea in quel caso:

• cliccando su tali linee si va invece direttamente all’allineamento tra la sequenza query e una data sequenza del database.

Figura 7: Output BLAST grafico

15

Nella pagina di output seguono poi l’elenco delle sequenze nucleotidiche che hanno prodotto degli allineamenti significativi:

Figura 8: output BLAS, 1: sequenza similare, 2: Score, 3: E-Value, 4: Link a LocusLink, database contenente informazioni sulla sequenze

Infine l’ultima parte è occupata dagli allineamenti fra le sequenze in input e gli allineamenti accompagnati dai relativi parametri:

I numeri alla fine della sequenza indicano la posizione degli amminoacidi all’interno della sequenza ad esempio qui la base T è nella posizione 237.

16

GenBank

Lanciato nel 1982, GenBank è un database che contiene sequenze genetiche istituito dal NIH14

• Rendendo disponibili i dati

. GenBank è uno dei database facente parte di un consorzio internazionale atto a raccogliere dati genetici insieme a DDBJ e ENA. Questo database rilascia una release ogni due mesi, ogni release è accompagnata da una opportuna documentazione con le note di quanto cambiato, aggiornato o aggiunto. GenBank è un database che alimenta la ricerca scientifica e lo fa in due modi:

• Permettendo di inviare dati alimentando e accrescendo la stessa banca dati, GenkBank vive grazie ai contributi inviati che comunque devono essere più accurati possibili e rispettare la natura “Comprehensive” del database.

L’accesso al database per recuperare i dati può avvenire in vari modi:

• Tramite modulo web di ricerca utilizzato come input l’identifiers della tupla su NCBI che a sua volta coordina e sfrutta il sistema ENTREZ global query, un sistema di query “Cross-database” che interroga vari database biomedici e quindi anche GenBank.

• Tramite query per ricerca e allineamento di sequenze genetiche sfruttando BLAST

• Tramite E-Utilities, un sistema di otto programmi che possono comprendere servizi di accesso basati su web service di tipo SOAP o utility sfruttabili sui sistemi Unix tramite riga di comando.

• Gli ASN.115 e i flatfile 16 sono disponibili tramite FTP anonimo ai rispettivi link: ftp://ftp.ncbi.nlm.nih.gov/ncbi-asn1 e ftp://ftp.ncbi.nlm.nih.gov/genbank. per i flatfile.

L’invio dei dati anche può avvenire secondo diversi standard, nella pagina di riferimento per il submitting17

14 National Institute of Healt (US.A.)

vengono specificati i dati non accettati. Inoltre per specifiche sequenze genomiche, come ad esempio quelle dei batteri, sono disponibili guide specifiche.

15 File in standard J-SON 16 file testuale strutturato con vari campi 17 Azione di invio dei dati

17

Si possono scegliere tra i seguenti metodi per inviare dati a GenBank :

• Tramite BankIT: un tool web-based con un wizard18

• Tbi2asn: una utility utilizzabile tramite riga di comando per trasferire grossi file direttamente tramite protocollo FTP, utilizzabile sia su sistemi Unix che su sistemi windows.

che guida il processo di invio.

• Tramite il Submission Portal, che è in attuale espansione, dove si possono inviare insieme vari tipi di dati.

• Tramite Sequin, un software stand-alone19 che si scarica al seguente link: https://www.ncbi.nlm.nih.gov/Sequin/ dove si possono effettuare vari tipi di invii anche sfruttando il protocollo FTP.

Sulla documentazione ufficiale viene specificato che gli invii tramite BankIT e Submission Portal vengono automaticamente inviati al GenBank, per gli altri metodi occorre prima inviare una e-mail al seguente indirizzo: gb-sub@ncbi.nlm.nih.gov.

GenBank il Flat File format Nella documentazione ufficiale fornita su NCBI, è possibile vedere e capire come il flat file, una delle risorse principali di GenBank, è organizzato. In tutto sono 9 fileds generali che a loro volta contengono altri fields e sono:

• LOCUS: Questo campo contiene vari tipi di dati come il Locus name, la lunghezza della sequenza e la data di modifica, nel dettaglio sono: - Locus Name - Sequence Length - Molecule Type - GenBank Division - Modification Date.

• DEFINITION: Contiene una breve descrizione dell’organismo di provenienza, il nome del gene/proteina e la descrizione di cosa fa la sequenza.

• ACCESSION: Un identificativo univoco di formato alfanumerico che non cambia mai e che identifica il record.

18 Procedura software guidata 19 Software installato e che svolge il suo lavoro su una macchina in locale

18

• VERSION: Indica la versione della sequenza, se vi è un aggiornamento il version number viene incrementato. Possiamo trovare anche un sottocampo denominato “GI”, GetInfo Identifier, un altro identificativo per le sequenze di nucleotidi che cambia ad ogni aggiornamento.

• KEYWORDS: Frasi o parole che descrivono sinteticamente la sequenza, tipicamente della lunghezza di un periodo.

• SOURCE: un campo dal formato libero che include un dato abbreviato sul nome dell’organismo e qualche volta anche il tipo di molecola. Possiamo trovare anche il sottocampo “Organism” che contiene il nome formale scientifico dell’organismo.

• REFERENCE: qui troviamo i dati relativi Alle pubblicazioni relativi alle squenze questi dati vengono ordinati in base alla data di pubblicazione in ordine crescente. I sottocampi di riferimento sono: - AUTHORS - TITLE - JOURNAL - PUBMED - Direct Submission

• FEATURES: In questo campo troviamo dati relativi ai geni e alla rilevanza biologica di tali geni. Possiamo avere vari feature, una lista easustiva la si può trovare al seguente link: https://www.insdc.org/documents/feature_table.html In breve i sotto campi disponibili sono: - Source - Taxon - Cds - <1..206 - Protein_id - GI - Traslation - Gene - Complement - Other Feature

• ORIGIN: Questo campo può essere vuoto o può contenere un puntatore alla sequenza di origine.

19

Tecnologie a supporto dell’elaborazione: Hadoop

Come abbiamo visto la gestione dei dati biomedici su database strutturati sfrutta tecnologie come BLAST, tuttavia sappiamo bene che nel panorama dei dati dobbiamo tenere conto dei database non strutturati che in proporzione hanno una crescita pari a 15 volte in più rispetto ai dati strutturati. Una delle sfide riguarda quindi il trattamento di queste grandi moli di dati, al fine soprattutto di trarre valore e conoscenza. Le tecnologie basate sul calcolo e lo storage distribuito hanno trovato quindi terreno fertile nel trattare questi dati non strutturati. L’acquisizione stessa può basarsi su diverse tecnologie , che possono essere a grandi linee le seguenti:

- Dati acquisiti tramite API di chi fornisce i dati. - Dati importati mediante strumenti ETL, ovvero dei tool software che svolgono

in modo automatico l’estrazione di dati. - Dati importati mediante l’utilizzo di software di web scraping, esempio parser

html per l’estrapolazione di dati dalle pagine web, documenti condivisi, etc. - Dati in formato stream provenienti da sensori o altre tipologie simili di

dispositivi. Come possiamo notare quindi, anche da questo elenco sintetico di “fonti” di acquisizione si può immaginare la mole di dati con cui si ha a che fare. In questo contesto, una delle architetture predominanti atta ad immagazzinare e processare questi dati è l’ecosistema Hadoop, una tecnologia basata sul calcolo distribuito che ha trovato successo grazie a due fattori principali:

- Hadoop è open source. - Hadoop sfrutta commodity hardware20

, ovvero non serve hardware specializzato per processare i dati.

Brevemente richiamiamo i concetti di quest’architettura che è alla base del meccanismo che ci appresteremo ad analizzare in seguito. Hadoop è una tecnologia che gestisce il calcolo distribuito attraverso alcuni standard e politiche di gestione che ne hanno affermato il successo. Hadoop è un ambiente distribuito, gestisce una serie di nodi organizzati in cluster, il file system è chiamato HDFS ed i suoi blocchi fisici hanno tipicamente la dimensione di 128 MB. 20 Hardware comune di basso costo, tipicamente di fascia consumer

20

I Nodi sono organizzati in due modi:

- I Namenode, che contengono le informazioni relative al file system, quindi alla struttura delle directory.

- I Datanodes, che rappresentano i nodi che processano il lavoro, in pratica i worker.

In linea generale quindi quando un work viene sottomesso, il nodo master si occupa di smistare il lavoro tra i vari datanodes, ognuno dei datanode svolgerà la sua porzione di compito che infine rimanderà il risultato al nodo master che gestisce l’applicazione, rendendo tale operazione trasparente all’utente. Le versioni successive di Hadoop hanno visto un arrochimento dell’architettura con l’aggiunta del componente YARN, che altro non è che il resources manager di Hadoop. YARN si occupa quindi di gestire lo scheduling delle risorse attraverso tre politiche principali:

- FIFO: Politica semplice, il primo che entra utilizza le risorse - Capacity: Politica incentrata su code di elaborazione basate sulla capacità di

elaborazione. - Fair: Politica che cerca di modulare il carico di lavoro distribuendolo

uniformemente tra le risorse a disposizione. Questa architettura rappresenta la base ideale di “job” sottoscritti e sviluppati tramite la tecnica map & reduce, che è un modello di programmazione per gestire le elaborazioni di grossi “chunk” di dati. Brevemente esponiamo anche qualche concetto relativo a mapreduce, dato che di fatto è il reagente principale di questa architettura che si offre ad elaborare i dati in maniera distribuita. Come sappiamo, i dati, ad un più alto livello di astrazione vengono manipolati da un linguaggio di programmazione che rappresenta il meccanismo prossimo alla fase di visualizzazione e analisi. Tramite questa tecnologia, che è guidata comunque in essere sempre dagli obiettivi individuati in fase di pre-analisi, si estrapolano ed elaborano i dati, in modo da avere un insieme di valore dove avviare la fase di analisi vera e propria. Mapreduce in sintesi è una tecnica che è composta appunto da una fase di mapping, che si occupa di selezionare i dati da passare alla fase di reduce che li raggrupperà e li riordinerà in base a quanto programmato e deciso dall’utente. Dobbiamo immaginare questa operazione in larga scala, i vari chunk della fase di map vengono smistati ai vari slave che produrranno un risultato intermedio che verrà a suo volta lavorato nella fase di reduce che infine farà un “melt” dei risultati,

21

che potranno poi essere finalmente visualizzati ed analizzati. In sintesi possiamo illustrare l’architettura di lavoro con i seguenti schemi:

Figura 9: Architettura Hadoop, Fonte: http://www.hadoopadmin.co.in

Figura 10: Esempio di job in map-reduce, Fonte: https://www.simplilearn.com

22

Tecnologie a supporto dell’elaborazione: Spark Spark è un framework per l’elaborazione di grandi moli di dati, indicato soprattutto per job che richiedono un analisi in tempi brevi o in real time. Questo è possibile grazie al fatto che Spark elabora i task in memoria centrale, ovvero sfrutta la memoria centrale per i risultati intermedi e finali aumentando di fatto le prestazioni di elaborazione rispetto ad Hadoop, che ricordiamo essere una tecnologia che lavora sui file e quindi con tempi di elaborazione nettamente più lenti. C’è da dire una cosa prima di illustrare l’architettura di Spark, navigando sul web si trovano molti paragoni tra Spark e Hadoop, con pro e contro, questo a nostro avviso è qualcosa di errato, perché le due tecnologie hanno obiettivi diversi. Il fatto che hadoop sfrutti i file ed è impostato per sfruttare commodity hardware lo rende comunque una tecnologia con costi inferiori e con capacità nettamente superiori come quantità di dati da elaborare rispetto a Spark che sfruttando la memoria centrale, non può avere sicuramente la portata che ha Hadoop. Un altro problema di Spark, come citato dalla documentazione di Apache è che la sicurezza di default è OFF, questo significa che bisogna affidarsi a tecnologie di terze parti e seguire alcune misure cautelative elencate nell’apposita documentazione. Inoltre per come sono progettate, le due architetture lavorano a due diversi livelli di astrazione, Spark a un livello più alto, Hadoop molto più basso, il che fa intuire che le due tecnologie possono lavorare anche insieme, infatti Spark può sfruttare come sorgente anche risorse organizzate su HDFS e utilizzare YARN come gestore di risorse. Fatta questa breve premessa, concludiamo questa riflessione ponendo l’attenzione sugli obiettivi, che restano la vera guida e punto di riflessione iniziale che deve portare poi a sviluppare le considerazione necessarie su cosa deve guidare uno sviluppatore o un azienda nell’adottare l’una o l’altra tecnologia o entrambe. Spark offre varie API per l’elaborazione dei dati, e può sfruttare come detto anche YARN, per la gestione delle risorse, inoltre può caricare i file da varie fonti tra cui appunto anche HDFS. Non è legato ad una particolare tecnologia di gestione del cluster che può essere affidata a vari orchestratori. Come linguaggi di programmazione può essere utilizzato da Java, Phyton, Scala e recentemente è stata sviluppata anche un integrazione per R. La potenza di questa tecnologia sta nel poter attuare elaborazioni iterative sui dati, senza dover aspettare i tempi di accesso sui file, dato che la tecnologia sfrutta come detto la memoria centrale, i dati memorizzati sono riusabili in tempi brevissimi, permettendo quindi più elaborazioni sullo stesso set di dati velocemente. Spark funziona con un motore di computazione che viene sfruttato dagli altri componenti che si integrano bene tra loro che sono:

23

• Spark SQL • Spark Streaming • MLlib • GraphX

Figura 11: Core e componenti di Spark

Il core di spark gestisce la memoria, lo scheduling delle risorse ed anche le procedure di recovery dei failure di eventuali nodi del cluster, quando questi failure avvengono vengono ricalcolati solo i dati persi. Il core fornisce un API per la gestione degli RDDs, i Resilient Distribuited Datasets, che altro non sono i dati distribuiti sul cluster e a cui vengono svolte le operazioni di elaborazione e modifica. Spark SQL invece, come è intuibile, permette di fare interrogazioni su dati strutturati e semi-strutturati tramite HiveQL, una variante di SQL. E’ possibile eseguire query anche su file in formato JSON, file di testo e altri formati supportati da Hive, come Parquet o ORC. Spark Streaming permette di analizzare i flussi di dati in tempo reale, come log di errori o un flusso su un canale social. MLlib è invece una libreria che contiene algoritmi di machine learning che sono di loro natura parallelizzabili come k-means o regressione lineare. E’ molto performante dato che sfrutta il fatto che i dati di Spark sono in memoria centrale, e quindi gli algoritmi iterativi vengono svolti in tempi veloci. GraphX è una libreria per l’analisi di grafi di grandi dimensioni che non potrebbero essere elaborati su una sola macchina, Ad esempio un grafo che rappresenta la rete di influencer e amici di un dato profilo dove i nodi rappresentano i profili e gli archi i

24

collegamenti. Questa libreria di default offre vari algoritmi come PageRank o calcolo delle componenti connesse. Questa componente unifica ETL, analisi esplorativa e calcoli iterativi su grafi, infatti i grafi vengono gestiti come dataset. Infine tramite l’API Pregel si possono scrivere algoritmi iterativi custom. L’architettura di Spark può essere eseguita su un singolo nodo o su un cluster. In generale vi sono una serie di processi in esecuzione per ogni applicazione: Un driver che gestisce diversi executor, gestisce l’applicazione, decidendo che compiti far svolgere agli executor, che sono in esecuzione sul nodo o sul cluster a differenza del driver, che viene eseguito sul client. Nel Driver è presente un oggetto SparkContext, la cui istanza comunica con il gestore delle risorse del cluster, come detto sono supportati diversi gestori di risorse come YARN, Mesos, EC2 oppure il manager stand-alone dello stesso Spark.

Figura 12: Architettura Spark

Abbiamo quindi un tipo di architettura Master/Slave dove un Driver gestisce vari executor. Un applicazione Spark è composta da un Jobs per ogni azione, che si occupa di ottenere dal sistema un risultato, ogni Job è composto da un insieme di stage svolti in sequenza, ogni stage esegue dei task svolti in parallelo dagli executor. La base del sistema dati è gestita dagli RDDs, che è un set di dati suddivisi in varie partizioni, ad esempio una tabella key-value segmentata in vari pezzi. La politica di gestione degli RDD ha queste caratteristiche:

25

1. Ogni RDD è immutabile, una volta creato non si può cambiare, ma se ne può creare un altro mediante trasformazione.

2. Ogni RDD può essere creato inizialmente partendo dai dati su disco oppure da altri RDD, queste trasformazioni sono mappabili e ripetibili, in modo tale che in caso di recovery si possa risalire all’RDD precedente al point of failure.

3. Ogni RDD può restare in memoria centrale o essere memorizzato su disco, a discrezione dello sviluppatore.

4. Ogni RDD dispone di un set di metadati che ne descrivono la caratteristica e ne aiutino il recovery in caso di failure.

Nell’immagine a seguire uno schema di come i dati vengono caricati, elaborati e trasformati nell’architettura Spark:

Figura 9: Schema logico del percorso dei dati in Spark, Fonte: Lester Martin, DevNexus 2017

26

Caso di studio: Rielaborazione ed estrazione di informazione di un dataset riguardante i virus registrati su RefSeq. Come caso di studio proponiamo tre job sviluppati in map-reduce su un dataset che contiene dati relativi alle sequenze genomiche dei virus registrati sul database RefSeq. Il file è fruibile tramite ftp anonimo come da immagine a seguire:

Il dataset è organizzato nel seguente modo:

Possiamo notare come i dati relativi ad esempio al “virus Compox” siano ripetuti poiché in RefSeq sono state registrate più sequenze genomiche. Le sequenze sono raggiungibili tramite l’apposito ID, la prima colonna del dataset. Obiettivo dei nostri job è riorganizzare e presentare nuovi dataset nel seguente modo:

1. Nome Virus (non ripetuto) – Dominio 2. Dominio – Numero sequenze virus registrate 3. Nome Virus – Numero sequenze registrate

Come base di esecuzione del Job abbiamo utilizzato una Virtual Machine con sistema operativo Linux Mint, su cui è stato installato Hadoop con impostazione mono-nodo, nodo master e nodo slave quindi coincidono con lo stesso elaboratore, ovviamente questi job hanno un puro scopo didattico, in realtà un job in hadoop e map-reduce coinvolge vari nodi nel cluster come sappiamo.

27

Come prima operazione abbiamo avviato i servizi con il comando da shell start-all.sh. Da sottolineare che questo comando è obsoleto, la procedura corretta e di avviare i servizi uno alla volta con i comandi start-hdfs.sh e start-yarn.sh Una volta avviati i servizi, carichiamo su hdfs il nostro dataset tramite il comando hadoop fs –put “path del file” “path di hdfs” Illustriamo quanto appena descritto nella seguente immagine:

Successivamente avviamo R-studio, dove abbiamo scritto e testato i nostri job:

28

I tre job sono stati sviluppati tramite map-reduce, essendo il file in formato .tab, tramite i metodi unlist e strsplit della libreria stringr abbiamo “spezzato” il file in righe. Per ogni riga, grazie alla libreria plyr, abbiamo applicato una funzione, dove si sono isolati i dati che ci interessano, nello specifico i dati nel file .tab sono suddivisi tramite il carattere “\t”, una volta estrapolati i dati di interesse abbiamo impostato la coppia chiave-valore da passare al reduce che ha raggruppato i risultati. a seguire il codice sorgente dei tre job: quello completo del job1, per gli altri due solo i metodi del map-reduce, dato che il “telaio” dello sciprt rimane sempre uguale, a seguire per ogni job il relativo screen con una parte dei risultati:

Job 1

library(rmr2) library(rhdfs) library(stringr) library(plyr)

hdfs.init()

virus1 = function(input, output = NULL){

myFun = function(x){

lsplit = unlist(strsplit(x,"\t")) c(lsplit[3],lsplit[5])

}

wc.map = function(., lines) {

words = unlist(strsplit(lines,"\n")) df = ldply(words,myFun) colnames(df) <- c('Dominio','Nome')

return(keyval(df$Nome,df$Dominio))

}

wc.reduce = function(k, v ) {

keys = unique(k) values = unique(v)

keyval(keys, values)

29

}

mapreduce(

input = input , output = output, input.format = "text", map = wc.map, reduce = wc.reduce, combine = T)

}

system("/usr/local/hadoop/bin/hadoop fs -rm -r /user/out")

hdfs.root <- '/user' hdfs.data <- file.path(hdfs.root, 'dataset_virus.tab') hdfs.out <- file.path(hdfs.root, 'out') out <- virus1(hdfs.data, hdfs.out)

results <- from.dfs(out)

results.df <- as.data.frame(results, stringsAsFactors=F) colnames(results.df) <- c('Nome', 'Dominio') results.df

30

Job 2

myFun = function(x){

lsplit = unlist(strsplit(x,"\t")) c(lsplit[3])

}

wc.map = function(., lines) {

words = unlist(strsplit(lines,"\n")) df = ldply(words,myFun) colnames(df) <- c('Dominio')

return(keyval(df$Dominio,1))

} wc.reduce = function(k, v ) { keyval(keys, sum(values)) }

mapreduce( input = input , output = output, input.format = "text", map = wc.map, reduce = wc.reduce, combine = T)

31

Job 3

myFun = function(x){

lsplit = unlist(strsplit(x,"\t")) c(lsplit[5])

}

wc.map = function(., lines) {

words = unlist(strsplit(lines,"\n")) df = ldply(words,myFun) colnames(df) <- c('Nome')

return(keyval(df$Nome,1))

} wc.reduce = function(k, v ) { keyval(keys, sum(values)) }

mapreduce( input = input , output = output, input.format = "text", map = wc.map, reduce = wc.reduce, combine = T)

32

Fonti:

I Big data Biologici Uninettuno – Emanuel Weitschek, Classe Interattiva del 19/02/2018 I database Biologici Uninettuno – Emanuel Weitschek, Classe Interattiva del 12/03/2018 An Introduction to Biological Database – Marie Cloude Blatter https://bioinf.comav.upv.es/courses/biotech3/theory/databases.html Matrici di Sostituzione http://www.di-srv.unisa.it/~ads/BIOINFORMATICA/BLAST/matrici_sostituzione.html FASTA Wikipedia

BLAST

https://www.ncbi.nlm.nih.gov/BLAST/fasta.shtml

https://blast.ncbi.nlm.nih.gov/Blast.cgi ddlab.sci.univr.it/alberto/bioinformatica/Teoria_L05_Blast_PSI-Blast.pdf http://www.di-srv.unisa.it/~ads/BIOINFORMATICA/BLAST/blast.html docente.unife.it/matteo.ramazzotti/bioinfo/05-Blast_Fasta.pdf NCBI https://www.ncbi.nlm.nih.gov/ https://www.ncbi.nlm.nih.gov/books/NBK25501/

GenBank https://www.ncbi.nlm.nih.gov/genbank/ https://www.ncbi.nlm.nih.gov/genbank/submit/ https://www.ncbi.nlm.nih.gov/books/NBK53707/ https://www.ncbi.nlm.nih.gov/Sitemap/samplerecord.html https://www.ncbi.nlm.nih.gov/Structure/asn1.html RefSeq https://www.ncbi.nlm.nih.gov/refseq/about/

Hadoop e Spark https://amslaurea.unibo.it/8876/1/gatto_lorenzo_tesi.pdf https://hadoop.apache.org/docs/stable/

https://spark.apache.org/documentation.html https://mac109.wordpress.com/2014/07/23/apache-spark-spiegato-in-italiano/