Optimaliseren van de Unipept Shotgun Metaproteomics Analysis Pipeline. Felix Van der Jeugt

Optimaliseren van de Unipept Shotgun Metaproteomics Analysis Pipeline

Felix Van der Jeugt [email protected] Academiejaar 2014-2015

1

Samenvatting Elke maand wordt een nieuwe versie van de UniProt Knowledgebase (KB) uitgegeven. Unipept, een webapplicatie voor metaproteomics analyse, maakt gebruik van de UniProt KB als referentiedatabank. Deze thesis stelt methoden voor om de periode tussen de uitgave van een nieuwe UniProt KB versie en het gebruik ervan in Unipept te minimaliseren. Verder wordt ˜ n van Unipept makkelijk lokaal kan een Docker instantie omschreven, waarmee men kopieA opzetten. Daarmee kunnen gebruikers hun metaproteomics analyses uitvoeren zonder hun data naar onze servers te sturen.

Trefwoorden metaproteomics, unipept, benchmarken, docker

Dankwoord In dit dankwoord dien ik me als eerste te richten tot mijn promoter, professor Dawyndt, en mijn begeleider, Bart Mesuere. Deze thesis zou nooit tot zijn huidige staat gevorderd zijn zonder onze wekelijkse besprekingen. In één adem bedank ik dan ook Tom Naessens, mijn medethesisstudent, tevens aanwezig op de wekelijkse besprekingen. Binnen de informatica wil ik meteen ook Stijn Seghers, Wai How Tam en Ilion Beyst bedanken voor de morele en programmatische steun die ze mij het afgelopen jaar schonken. Het rijtje van dank eindigt buiten de Sterre en heel wat dichter bij huis, namelijk met mijn ouders, Joris en Vera, niet alleen voor de morele en praktische steun, maar ook voor al het heerlijke eten tijdens mijn studies. Bij nagedacht moet ik misschien toch ook nog mijn kat Brutus bedanken, om mij af en toe tot pauzes te dwingen door het professioneel blokkeren van mijn toetsenbord.

Streamlining the Unipept Shotgun Metaproteomics Analysis Pipeline Felix Van der Jeugt Supervisor(s): prof. dr. Peter Dawyndt, ir. Bart Mesuere Abstract— Each month, a new UniProt KnowledgeBase [5] (KB) is released. Unipept [7], [6], an online tool for metaproteomics analysis, uses the UniProt KB as a reference database. We present methods to minimize the delay between a new UniProt KB release and the use of the new data in Unipept. Effort was also made to present a Docker [1] container, with which copies of Unipept can be easily deployed. This enables users to analyse their metaproteomics sample without uploading their data to our servers. Keywords—metaproteomics, unipept, benchmarking, docker

I. I NTRODUCTION Unipept is a web application offering tools for the analysis of metaproteomics samples. These tools can be used either directly in the browser, or, using the Unipept API, through a command line interface. II. T HE U NIPEPT DATABASE One of the tools quickly retrieves all proteins found in the UniProt KB [5] containing a given tryptic peptide. The taxonomic lineage of each protein is given, using the National Center Fig. 1: Each line represents an execution of the UniProt parser, for Biotechnology’s taxonomy [3]. Finally, the lowest common with varying RAM memory granted to BerkeleyDB. Observe how ancestor (LCA) of those taxa is returned. each execution slows down significantly when the in-memory In order to find all proteins containing a tryptic peptide, a fast database starts swapping excessively. index on the tryptic peptides is required. This implies all peptides, and preferably their LCAs, must be preprocessed. Parsing and preprocessing the proteins from the UniProt KB used to span two months. As a new version is released each month, this process required a speedup. Replacing the current internal mapping of tryptic peptides on their identifiers with BerkeleyDB [8], an in-memory database with file backing, and all write-only tables in the database with buffered tab separated values (TSV) output, this process was sped up to only 10 hours. We replaced the current internal mapping of tryptic peptides on their identifiers with BerkeleyDB [8]. BerkeleyDB is an inmemory database with file backing. All write-only tables in the database were replaced with buffered tab separated values (TSV) output. Together with some small modifications, these two measures sped up the process to only 10 hours. Furthermore, this RAM intensive process can now scale along with the size of the UniProt KB as can be observed in Figure 1 and Figure 2. While rewriting the code to make it faster, the code was also restructured and cleaned. This new structure can be observed in Fig. 2: This figure visualises the number of entries processed Figure 3 on the following page. Note that in the new structure, all in Figure 1 before the process started swapping excessively, in function of the memory capacity given to BerkeleyDB. Observe P. Dawyndt and B. Mesuere are associated with the Computational Biology reseach group from the Department of Applied Mathematics, Computer Sci- how the number of entries processed rises faster-than-linear. ence and Statistics, Ghent University (UGent), Ghent, Belgium. E-mail: [email protected], [email protected].

in the poster on the next page. First, the tryptic peptides in the proteins of the IGC were given taxonomic identification using Unipept. We performed some sanity checks on these identifications. While there were certainly some faults discovered in Unipept as well, we discovered some chimerae in the IGC, as reported in the bottom right block. Then, the taxonomic annotations on the IGC, made using BLAST [2], were compared to the annotations made by Unipept. In the middle right block of the poster, this comparison is visualised. This case study brought us to the conclusion the IGC en Unipept mostly agreed on the annotations when both did annotate a protein. However, Unipept offered a lot more specific annotations.

NCBI Taxons NodesNames2TaxonsLineages Lineages

TrEMBL

Taxons

SwissProt

TaxonsUniprots2Tables

RefSeq Cross References

UniProt Entries

EMBL Cross References

Peptides

GO Cross References

Sequences LineagesSequencesTaxons2LCAs

EC Cross References Sequences NCBI Assemblies

FetchAssemblies Assemblies

Entrez Assembly Sequences

Fig. 3: Structure of the new Unipept Database construction. Blue nodes indicates executables. Green nodes represent input files and intermediate results. Red nodes indicate output files ready to be loaded into the database tables. output files are TSV files. These can be loaded into the database with the same name. Because of the directed acyclic property of the new structure, the database construction is no longer executed using a collection of bash scripts. The construction is now unified in one makefile. This makefile can be configured at will using a configuration file in the same directory. Finally, one script is provided to serve as a cron job. III. D EPLOYING U NIPEPT Many users, especially big clients such as companies or large research units, cannot use Unipept due to several reasons. Their data may be to big or sensitive to transfer over the internet. A solution might be to deploy Unipept on local machines. To simplify this process, a pair of Docker containers was created. Docker containers are lightweight virtual machines, which are easily distributed through the Docker Hub. While one of the containers contains the actual web application, the other contains the database. This implies the database used by the web application can easily be swapped. In future work, we’d like to simplify setting up a database with data other than the UniProt KB. IV. T HE I NTEGRATED G ENE C ATALOG Finally, a case study was performed. In this case study, the Integrated Gene Catalog [4] (IGC) was used to do some quality checks on both the IGC and Unipept. The results can be observed

R EFERENCES [1] Docker. https://www.docker.com/. [2] Stephen F Altschul, Warren Gish, Webb Miller, Eugene W Myers, and David J Lipman. Basic local alignment search tool. Journal of molecular biology, 215(3):403–410, 1990. [3] Scott Federhen. The ncbi taxonomy database. Nucleic acids research, 40(D1):D136–D143, 2012. [4] Junhua Li, Huijue Jia, Xianghang Cai, Huanzi Zhong, Qiang Feng, Shinichi Sunagawa, Manimozhiyan Arumugam, Jens Roat Kultima, Edi Prifti, Trine Nielsen, et al. An integrated catalog of reference genes in the human gut microbiome. Nature biotechnology, 32(8):834–841, 2014. [5] Michele Magrane, UniProt Consortium, et al. Uniprot knowledgebase: a hub of integrated protein data. Database, 2011:bar009, 2011. [6] Bart Mesuere, Griet Debyser, Maarten Aerts, Bart Devreese, Peter Vandamme, and Peter Dawyndt. The unipept metaproteomics analysis pipeline. Proteomics, 15:1437–1442, 2015. [7] Bart Mesuere, Bart Devreese, Griet Debyser, Maarten Aerts, Peter Vandamme, and Peter Dawyndt. Unipept: tryptic peptide-based biodiversity analysis of metaproteome samples. Journal of proteome research, 11(12):5773– 5780, 2012. [8] Berkeley DB Oracle. Java edition.

Who lives in the human gut? The Unipept Shotgun Metagenomics Analysis Pipeline Bart Broeckx1, Felix Van der Jeugt1, Jens Van de Weygaert1, Stijn Seghers1, Kevin Velghe1, Giles Miclotte1, Pieter Vander Vennet1, Peter Dawyndt1 1The 2015 Computational Biology class All authors contributed equally to this work.

Abstract Background: Analyses of the human gut microbiome rely on the availability of high-quality gene reference databases. Recently the Integrated Gene Catalog (IGC)1 was presented as a global gene database. In this work Unipept2 is applied to evaluate the quality of this database. We aim to evaluate the quality of this database by comparing the annotations derived from IGC and Unipept for proteins contained in the IGC. Results and discussion: Unipept annotated more proteins and was more specific in its annotations. As some of the tryptic peptides from one protein could be assigned to very specific but evolutionary distinct species, the quality of a part of the IGC annotation seems to be questionable.

Shotgun Metagenomics Identification

Integrated Gene Catalog The IGC contains 9,879,896 genes established from 249 samples from the Metahit project and 1018 samples from the Human Microbiome Project.

IGC Proteins from the human gut

LCA vs LCA* The LCA of the set S = {A, F, G} LCA: The lowest common ancestor of a set of nodes A is the lowest is A, while the LCA* of S is C. node that is an ancestor of all D nodes v of A. B LCA*: The LCA* of a set of nodes A E A is the highest descendant of the F C LCA of A such that for every node G v of A: v is either an ancestor of LCA* or LCA* is an ancestor of v.

IGC ID

Unipept ID

The Unipept Shotgun Metagenomics Analysis Pipeline: prot2lca* Protein Peptide Incorrect Assembly

LCA

Certain very large proteins from the IGC database do not seem to correspond with actual natural proteins. The known occurrences of the tryptic peptides of these proteins can differ wildly for each peptide. This most likely indicates an incorrect protein assembly. The following picture illustrates this for one protein.

LCA*

Clonorchis sinensis

Proteins from the IGC are split into tryptic peptides, after which a filter is applied retaining only those peptides of size [5, 50]. These peptides are then mapped on their occurrence in the taxonomic tree. The lowest common ancestor of these mappings is sure to be a correct taxonomic identification of the origin of the peptide, assuming that the tree is complete. However by considering the LCA* instead of the LCA the final taxonomic identification can be made more specific, without losing too much accuracy.

1Junhua,

Aedes aegypti

Astyanax mexicanus

Serpula lacrymans Streptococcus Oryza sativa

L. et al.: An integrated catalog of reference genes in the human gut microbiome. Nature Biotechnology, 32, 834-841 (2014). B. et al.: The Unipept Metaproteomics Analysis Pipeline. Proteomics, 15(8), 1437-1442 (2015).

2Mesuere,

Inhoudsopgave 1 Introductie 1.1 Metaproteomics . . . . . 1.2 Shotgun Metaproteomics 1.3 Unipept . . . . . . . . . 1.4 Optimalisaties . . . . . . 1.5 De code . . . . . . . . .

. . . . .

7 7 7 8 10 10

. . . . . . . . . . . .

13 13 14 14 15 16 16 16 17 21 21 26 27

3 Lokaal deployen van Unipept c 3.1 Over Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Installatie en gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Werking Dockerfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 35 36

4 Integrated Gene Catalog 4.1 Metagenomics identificatie met Unipept CLI . . . . . . . . . . . . . . . . . . 4.2 Nagaan van de consistentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Vergelijking IGC en Unipept . . . . . . . . . . . . . . . . . . . . . . . . . . .

40 40 42 43

. . . . . . Analysis . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

2 De Unipept Databank 2.1 Beschrijving van de Unipept Databank 2.2 Constructie van de Unipept Databank 2.2.1 Databronnen . . . . . . . . . . 2.2.2 Het IO-probleem . . . . . . . . 2.2.3 Diverse oplossingen . . . . . . . 2.2.4 BerkeleyDB . . . . . . . . . . . 2.2.5 Structuur van de parser . . . . 2.2.6 Benchmarking . . . . . . . . . 2.3 Unipept Databank Makefile . . . . . . 2.3.1 Gebruik . . . . . . . . . . . . . 2.3.2 Introductie tot make . . . . . . 2.3.3 Afhankelijkheden en recepten .

5

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

INHOUDSOPGAVE 5 Toekomstig werk 5.1 De databank . . 5.2 Assemblages . . . 5.3 Publicatie Docker 5.4 K-meren . . . . .

6

. . . . . . . . . . . . container . . . . . .

A Databankstructuur A.1 Taxons . . . . . . . . A.2 Lineages . . . . . . . A.3 Sequences . . . . . . A.4 UniProt Entries . . . A.5 Peptides . . . . . . . A.6 Cross References . . A.7 Assemblies . . . . . . A.8 Assembly Sequences

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

46 46 46 47 47

. . . . . . . .

48 48 49 49 49 50 50 51 52

Hoofdstuk 1

Introductie Om de optimalisatie van de Unipept Shotgun Metaproteomics Analysis Pipeline te kunnen volgen, is een zeker begrip van deze pijplijn noodzakelijk. Dit begrip kan niet verkregen worden zonder eerst een duik te nemen in de biologische context. Deze inleiding heeft tot doel die context te voorzien. De eerste secties leggen enkele termen uit die in de komende hoofdstukken aan bod komen. Daarna wordt Unipept [11, 10] kort beschreven. Tenslotte volgt een kort overzicht van de verschillende optimalisaties die tijdens de thesis verricht werden.

1.1

Metaproteomics

Metaproteomics is de studie van een metaproteoom. Een proteoom is de verzameling van alle eiwitten die tot expressie komen binnen één organisme. Zo’n proteoom is in de natuur echter onbestaande. Bij proteomics moet men eerst in een laboratorium het staal cultiveren. Dit vereist echter veel werk en helaas is niet elk proteoom geschikt voor cultivatie. Om die reden bestaat metaproteomics. Een metaproteoom is een mengeling van diverse proteomen. Bij metaproteomics kan men dus rechtstreeks op stalen uit de natuur werken. Wegens de grotere diversiteit in het staal is metaproteomics een stuk moeilijker dan proteomics.

1.2

Shotgun Metaproteomics Analysis

Voor bijna alle analyses op (meta-)proteomen moet dit (meta-)proteoom eerst verwerkt worden. Hiertoe wordt elk eiwit voorgesteld met een sequentie van aminozuren. Het bepalen van de juiste volgorde is echter geen eenvoudige taak. Men pakt deze taak aan door het (meta-)proteoom te sequeneren. Dit proces bestaat uit het opbreken van de eiwitten uit het

7

HOOFDSTUK 1. INTRODUCTIE

8

Figuur 1.1: Splitsing van een eiwit door het toevoegen van trypsine. Het eiwit splitst na elke K of R die niet gevolgd wordt door een P.

staal in korte delen, welke met een massaspectrometer omgezet kunnen worden in een textuele representatie. Binnen Unipept gebeurt het opbreken aan de hand van trypsine. Trypsine splitst eiwitten op een zeer systematische manier. Het eiwit zal na elk voorkomen van het aminozuur Lysine (K) of het aminozuur Arganine (R) gesplitst worden, tenzij dit voorkomen gevolgd wordt door het aminozuur Proline (P). Figuur 1.1 bevat een voorbeeld van deze splitsing. De resulterende sequenties worden tryptische peptiden genoemd. Door de beperkingen van een massaspectrometer kunnen enkel peptides van 5 tot 50 aminozuren lang ingelezen worden. Tevens kan een massaspectrometer geen onderscheid maken tussen de aminozuren Isoleucine en Leucine. Eenmaal men beschikt over een gesequeneerd staal, kan dit op twee manieren geanalyseerd worden. Enerzijds kan men het oorspronkelijke eiwit opnieuw proberen reconstrueren, een proces dat assembleren genoemd wordt. De resulterende assemblage wordt dan toegewezen aan een bepaald organisme. Anderzijds kan men rechtstreeks analyses toepassen op de peptiden. Die peptiden worden dan vergeleken met referentiedatabanken. Unipept biedt hiervoor enkele tools aan. In Figuur 1.2 wordt een metaproteomics proces ge¨ıllustreerd. Het onderste gedeelde van het schema kan met Unipept uitgevoerd worden.

1.3

Unipept

Unipept biedt namelijk een webapplicatie aan speciaal voor de analyse van metaproteomen. Op deze webapplicatie zijn vier functies beschikbaar. Met de Tryptic Peptide Analysis kan informatie opgehaald worden over een enkel tryptisch peptide. Het zoekt het gegeven peptide op in een lijst van eiwitten uit de referentiedatabank van UniProt KB [8] en geeft de


9

Figuur 1.2: Schema van een Shotgun Metaproteomics Analysis Pipeline [16]. Een stoelgangstaal wordt bewerkt en de eiwitten gesplitst met trypsine. Een massaspectrometer zet te peptiden om in een textuele representatie. Deze peptiden worden opgezocht in de geassembleerde databanken om te eiwitten te identificeren.


10

eiwitten terug waar het gezochte peptide in voorkomt. Om de beperking betreffende Leucine en Isoleucine te counteren, zal Unipept een optie geven om deze gelijk te stellen in de berekeningen. Elk van deze eiwitten behoort tot een zeker taxon. Een taxon is een classificatie van een soort of verzameling van soorten. Alle taxa samen vormen een boom, genaamd de Tree of Life. De taxa horende bij de eiwitten waar het gezochte peptide in teruggevonden kan worden, zal Unipept aggregeren tot een taxonomische afstamming. Tenslotte wordt één taxon gemarkeerd als lowest common ancestor (LCA). Dit is de kleinste verzameling waartoe alle matchende taxa in voorkomen. De gebruikte taxonomie is van het National Center for Biotechnology Information (NCBI) [4]. Figuur 1.3 geeft een grafische voorstellen van de stappen die uitgevoerd worden bij een Single Peptide Analysis. De Metaproteomics Analysis functie zal ook de LCA berekenen, maar ditmaal voor een lijst van tryptische peptiden. Typisch zijn dit alle tryptische peptiden uit een zeker metaproteomics staal. Eenmaal voor elke peptide de LCA gekend is, worden deze getoond in enkele visualisaties die inzicht geven in de biodiversiteit van het gegeven staal. Verder kan de Unique Peptide Finder gebruikt worden om te bepalen welke tryptische peptiden enkel in een gegeven soort of genus voorkomen. Tenslotte kan met Peptidome Clustering de gelijkenis tussen een verzameling van genomen berekend en gevisualiseerd worden.

1.4

Optimalisaties

Bij optimalisatie denkt een informaticus meestal alleen aan het optimaliseren van uitvoeringstijd en geheugenverbruik. Weldegelijk, de uitvoeringstijd bij het opstellen van de databank was het voornaamste probleem bij de Unipept Shotgun Metaproteomics Analysis Pipeline, beschreven in Sectie 2.2. Deze thesis draait echter niet enkel daarrond. Ook de interne structuur van de code om de databank op te stellen werd verbeterd. In Sectie 3 wordt beschreven hoe het deployen van een lokale versie van Unipept vereenvoudigd werd.

1.5

De code

De code horende bij deze thesis is terug te vinden op: • https://github.ugent.be/unipept/unipept op de feature/backend-speedup-berkeleydb branch voor Hoofdstuk 2, in de backend directory.

Figuur 1.3: Proces bij het opzoeken van peptide ENFVY[IL]AK met Unipept. Dit peptide blijkt voor te komen in de eiwitten gegeven in de tweede kolom. In de derde kolom worden de taxa gegeven waar deze eiwitten uit afkomstig zijn. Tenslotte worden deze taxa geaggregeerd tot hun LCA: de orde van de Streptophyta.

HOOFDSTUK 1. INTRODUCTIE 11


12

• https://github.ugent.be/unipept/unipept op de feature/docker branch voor Hoofdstuk 3. • https://github.ugent.be/COMPBIO2015/igc voor Hoofdstuk 4.

Hoofdstuk 2

De Unipept Databank Eén van de troeven van Unipept is zijn snelheid. Van webapplicaties wordt verwacht dat ze quasi onmiddellijk reageren op je acties, waardoor de berekeningen ook zeer snel moeten uitgevoerd worden. Dit wordt deels bereikt door snelle code die in je webbrowser loopt, maar ook door zo veel mogelijk resultaten reeds op voorhand te berekenen. Al deze voorberekeningen en de ruwe data waarop ze steunen wordt opgehaald uit de Unipept Databank. Dit hoofdstuk omschrijft hoe deze ruwe data wordt verkregen en voorverwerkt. Eerst komt echter een korte beschrijving van de diverse tabellen in de databank zelf en hoe ze gebruikt worden door Unipept. Een meer uitgebreide omschrijving is terug te vinden in Appendix A.

2.1

Beschrijving van de Unipept Databank

Een eerste tabel in de databank, genaamd taxons, bevat de taxonomie zoals de in Unipept gebruikt wordt. Elk taxon krijgt een unieke identificator, maar ook een naam en een ouder. Deze ouder is de kleinste taxonomische verzameling waarvan dit taxon (tezamen met zijn kinderen) een deelverzameling is. Verder worden aan de taxa die zich op bepaalde vast rangen bevinden ook nog de naam van die rang toegekend. Tenslotte kennen we aan elk taxon nog een waarheidswaarde toe, die aanduidt of dit taxon al dan niet geldig is. Hierdoor kunnen niet-officiële taxa optioneel genegeerd worden. Direct afleidbaar uit deze taxons tabel is de lineages tabel. Deze bevat voor elk taxon zijn volledige afstamming, maar enkel met voorouders die een benoemde taxonomische rang hebben. Deze tabel wordt voornamelijk gebruikt om andere berekeningen te versnellen. De sequences tabel is de belangrijkste tabel in de voorverwerking. Deze bevat voor elk tryptisch peptide uit de brondata een reeds berekende kleinste gemeenschappelijke voorouder 13

HOOFDSTUK 2. DE UNIPEPT DATABANK

14

(lowest common ancestor, LCA). Deze LCA moet zeer snel opgevraagd kunnen worden om terug te geven tijdens een “Tryptic Peptide Analysis” of een “Metaproteomics Analysis” van Unipept. Om meer informatie te kunnen geven over de tryptische peptiden in de Unipept Databank bestaat de peptides tabel. Deze tabel linkt de sequences tabel aan de eiwitten waarin het peptide teruggevonden wordt. De eiwitten zelf bevinden zich in de uniprot entries tabel. Hierin bevindt zich de data zoals geëxtraheerd uit verschillende eiwitdatabanken. We verwijzen naar de bron, een identifier gegeven aan dit eiwit door die bron, de naam van het eiwit, een versienummer en het taxon waar dit eiwit aan toegewezen wordt. Het eiwit zelf bevindt zich ook in deze tabel. Voor de weergave van resultaten in Unipept is het belangrijk om de peptiden en eiwitten ook te kunnen linken aan andere bronnen. Om die reden bestaan een aantal “Cross References” tabellen. Zij leggen de link van de uniprot entries tabel naar Enzyme Commission nummers [17] (ec cross references), de EMBL nucleotide sequence database [6] (embl cross references), het Gene Ontology Consortium [3] (go cross references) en de NCBI Reference Sequence Database [14] (refseq cross references). Tenslotte zijn er de assemblies en assembly sequences tabellen, die informatie bevatten over volledig geassembleerde genomen. De assemblies tabel bevat informatie zoals de naam, het taxon en de naam van het organisme dat geassembleerd werd, het assembly level, wat voor genoom deze assemblage voorsteld (full of partial ), of deze assemblage van typemateriaal afkomstig is en ID’s van het bijhorende biosample, GenBank Accession nummer en RefSeq Accession nummer. Bij elk assembly hoort dan nog een willekeurig aantal sequenties, die er in de assembly sequences tabel aan gelinkt worden.

2.2

Constructie van de Unipept Databank

Deze sectie beschrijft de constructie van de Unipept Databank. Daarvoor moet eerst de oorsprong en structuur van de databronnen bekeken worden. Vervolgens wordt het grootste probleem met de constructie beschreven en de oplossing ervoor gegeven. Het hoofdstuk eindigt met de eigenlijke structuur van de parser en enkele benchmarks.

2.2.1

Databronnen

Om de Unipept Databank op te stellen moet er veel data van andere bronnen ingelezen en verwerkt worden. Dit deel bevat een overzicht van de verschillende bronnen waar Unipept gebruikt van maakt, en welke vormen en maten deze aannemen.


15

Unipept maakt gebruik van de Tree of Life, de boom met alle taxa als toppen en hun directedeelverzamelingsrelatie R als bogen.

(A, B) ∈ R ⇐⇒ A ⊂ B ∧ ¬∃X (A ⊂ X ∧ X ⊂ B) .

(2.1)

Deze boom wordt opgesteld aan de hand van een lijst van taxa en de relatie R zoals te verkrijgen bij het NCBI. Meer specifiek betreft het de names.dmp en nodes.dmp bestanden uit het taxdmp.zip bestand te downloaden op ftp://ftp.ncbi.nih.gov/pub/taxonomy/. Beide bestanden zijn tab separated en bijgevolg eenvoudig te parsen. Ook de omvang geeft geen problemen. Op het moment van schrijven is taxdmp.zip 31 MB groot. Het merendeel van de data in de Unipept databank, in volume bekeken, heeft zijn oorsprong bij UniProt [8]. Beide delen van de UniProt Knowledgebase, Swiss-Prot en TrEMBL, worden als XML bestanden gedownload en geparset. Het manueel geannoteerde deel, Swiss-Prot, is 808 MB groot. Het automatisch geannoteerde deel, TrEMBL, omvangt 36.8 GB. Merk op dat dit in september nog 62 GB was. Sinds de publicatie van April 2015 is voor UniProt redundante informatie verwijderd uit de databank. De taxonomie van NCBI is niet de enige bron waar Unipept op steunt. Ook de assemblages worden bij NCBI gevonden. Enerzijds via de FTP-server en anderzijds met behulp van hun web services stelt Unipept een tabel op van assemblages en een andere tabel van de hierin gebruikte sequenties.

2.2.2

Het IO-probleem

Het lezen en interpreteren van deze data zelf is niet de moeilijkheid bij het construeren van de databank. De meeste bronnen zijn goed opgebouwd volgens een eenvoudig formaat. De moeilijkheid schuilt hem in de hoeveelheid data die verwerkt moet worden. De originele implementatie van de Unipept Backend parser kon alles voldoende snel verwerken, maar werd opgehouden door de opslag van tussentijdse en finale data. Hiervoor werd een databank gebruikt, welke een bottleneck vormde voor de rest van het algoritme. Om deze bottleneck te vermijden werd de databank vervangen door een andere manier van opslaan, die in de volgende sectie toegelicht word. Merk op dat deze bottleneck enkel voorkomt bij het verwerken van de UniProt data. De andere is onvoldoende groot om problemen te veroorzaken.


2.2.3

16

Diverse oplossingen

De constructie van de Unipept databank bestaat uit het herstructureren van reeds bestaande data. Hierdoor heeft het programma een lineair karakter. Alle data die gelezen wordt, of toch een deel, wordt terug uitgeschreven. En inderdaad, de output van het programma verloopt ook merendeels lineair. Hierdoor kan de databank reeds voor een groot deel geëlimineerd worden: de insert statements kunnen vervangen worden door toevoegen achteraan een character-separated-values bestand (CSVbestand). Tenslotte hoeft deze data, eenmaal weggeschreven, niet meer opgevraagd te worden. Het is ook eenvoudig om deze CSV-bestanden bij het wegschrijven te bufferen, waardoor het opslaan de rest van het programma nauwelijks vertraagd. Helaas is niet alle data van vluchtige aard. De ingelezen data is reeds uniek, er kan dus incrementeel interne indicatoren toegewezen krijgen. Hiervoor moet gewoon een teller bijgehouden worden. De tryptische peptiden vormt Unipept zelf. Deze moeten dus nog unieke ID’s krijgen. Om te zorgen dat hetzelfde tryptisch peptide in heel de databank hetzelfde ID krijgt, moet bijgehouden worden welke peptiden eerder benoemd werden. Een bijectie tussen de tryptische peptiden en hun ID is noodzakelijk.

2.2.4

BerkeleyDB

Het snel stijgend aantal peptiden (Figuur 2.1) verhindert het bijhouden van deze bijectie in het RAM-geheugen. Het bijhouden van de mapping via een gewone databank bleek eerder al onvoldoende snel. Een oplossing vereist de snelheid van een in-memory mapping met de geheugencapaciteit van een databank. BerkeleyDB [13], een in-memory databank met file backing voldoet aan deze twee vereisten. Door uitgebreide indexering en een groot aantal bestanden met entries kan de data snel in het RAM gecachet worden. Dankzij het flexibele aantal databestanden dat aanmaakt kan worden op de schijf is BerkeleyDB een schaalbare oplossing. Bij het benchmarken blijk deze schaalbaarheid echter niet helemaal geldig. Deze resultaten zijn te vinden in Sectie 2.2.6

2.2.5

Structuur van de parser

In figuur 2.2 wordt een overzicht gegeven van de dataflow tijdens het construeren van de Unipept databank. Deze gerichte acyclische graaf wordt in praktijk gebracht met behulp van een makefile. De opbouw van deze makefile en de algemene werking van make wordt beschreven in de volgende sectie.


17

Figuur 2.1: Groei van het aantal eiwitten in de TrEMBL databank van UniProt. De halvering van data (in april 2015) is afkomstig van een reductie in data uitgevoerd door UniProt.

In de figuur worden 3 kleuren gebruikt: groen, blauw en rood. De groene blokken staan voor tussenresultaten of bronbestanden. Deze bestanden zijn wel noodzakelijk voor de berekeningen, maar kunnen, als de berekening compleet is, verwijderd worden. Databestanden die niet verwijderd mogen worden zijn de rode blokken. Deze stellen de tabellen voor die in de databank ingeladen moeten worden. Merk op dat het blok “sequences” tweemaal voor komt. De eerste keer is het nog een groen blok. Wanneer de LCA’s er aan toegevoegd zijn, wordt het een rood blok. Het toevoegen van deze LCA’s aan de sequenties en de andere commando’s en programma’s wordt voorgesteld door blauwe blokken in het schema. De pijlen die in deze blauwe blokken toekomen komen van de data die deze tabellen als input gebruiken. De pijlen die er uit vertrekken stellen dan weer de gegenereerde output-bestanden voor.

2.2.6

Benchmarking

In dit deel wordt de performantie van BerkeleyDB bekeken als in-memory databank met file backing voor het opbouwen van Unipept. Om na te gaan welke groei van UniProt binnen haalbare tijd met haalbare hardware te verwerken is, wordt het gedrag van de parser bekeken voor variërende geheugencapaciteit. Door het geheugen te verkleinen kan de verhouding geheugen/data verkleind worden, net zoals zou gebeuren moest de data groeien. Merk op dat


18

NCBI Taxons NodesNames2TaxonsLineages Lineages TrEMBL

Taxons

SwissProt

TaxonsUniprots2Tables

RefSeq Cross References

UniProt Entries

EMBL Cross References

Peptides

GO Cross References

Sequences LineagesSequencesTaxons2LCAs

EC Cross References NCBI Assemblies Entrez

FetchAssemblies

Sequences

Assemblies Assembly Sequences

Figuur 2.2: Structuur van de Unipept Databank constructie. Blauwe blokken duiden op programma’s. Groene blokken duiden op input-bestanden of nog te verwerken tussenresultaten. Rode blokken duiden op tabellen klaar om in de databank geladen te worden.


19

Figuur 2.3: Het aantal eiwitten uit SwissProt (540.000 eiwitten in totaal) verwerkt door de parser per tijd in minuten. We zien hoe, bij het stuiten op de geheugenlimiet, het verwerken bijna stilvalt.

deze testen uitgevoerd werden met enkel de SwissProt gecureerde data van UniProt. In figuur 2.3 wordt het verband uitgelegd tussen het aantal verwerkte eiwitten en de tijd gemeten voor enkele uitvoeringen van de parser. Elk van deze uitvoeringen kreeg een andere geheugencapaciteit ter beschikking. Na zekere tijd vallen de meeste uitvoeren bijna stil. Deze momenten duiden op de geheugenlimiet waar BerkeleyDB op stuit. Als deze keerpunten apart geplot worden in figuur 2.4, wordt het duidelijk dat het verband tussen de geheugengrootte en het aantal verwerkte eiwitten voor de vertraging niet helemaal lineair is. Het lijkt alsof het verband monotoon versnellend is. Waar duidelijk is dat BerkeleyDB niet de heilige graal is, blijkt het wel een goede oplossing te zijn voor Unipept.


20

Figuur 2.4: Het aantal eiwitten dat verwerkt kon worden alvorens de verandering van trend in figuur 2.3, per geheugengrootte. De groene lijn is een lijnstuk tussen het punt op 50MB en het punt op 170MB.


2.3

21

Unipept Databank Makefile

Het parsen van de bronbestanden tot de uiteindelijk databanktabellen wordt gecontroleerd door een Makefile. Subsectie 2.3.2 bevat een introductie tot het make commando en de opbouw van makefiles. In subsectie 2.3.3 wordt beschreven hoe make gebruikt werd voor de Unipept databank. In het volgende deel volgt een kort overzicht van het gebruik.

2.3.1

Gebruik

Merk op dat het uiteindelijke gebruik best gebeurt met behulp van het main.sh bestand, dat op dezelfde locatie als de makefile te vinden is. Na de makefile wordt ook dat bestand hier kort omschreven. Alvorens het gebruiken van de makefile dient deze geconfigureerd te worden. Alle configuratie bevindt zich in een enkel bestand, hieronder te vinden. Om correct te werken dient dit bestand, onder de naam config, zich in dezelfde map te bevinden als het make bestand. Merk op dat de volgorde van de definities in het configuratiebestand geen verschil maakt, zolang elke optie aanwezig is. 1 2

LOGFILE = main . log MAIL = unipept@ugent . be

3 4 5 6 7 8 9 10

DATADIR =../../ data TABDIR = $ { DATADIR }/ tables UNIDIR = $ { DATADIR }/ uniprot TAXDIR = $ { DATADIR }/ taxon GENDIR = $ { DATADIR }/ assembly INTDIR = $ { DATADIR }/ intermediate BDBDIR =../../ berkeleydb

11 12 13 14 15 16 17

# JMEMMIN = ’ - Xms140g ’ # JMEMMAX = ’ - Xmx150g ’ # BDBMEM = ’100000000000 ’ JMEMMIN = ’ - Xms2g ’ JMEMMAX = ’ - Xmx3g ’ BDBMEM =500000000

18 19 20 21 22 23

TAXON_URL = ftp :// ftp . ncbi . nih . gov / pub / taxonomy / taxdmp . zip UNIPROT_URL = ftp :// ftp . ebi . ac . uk / pub / databases / uniprot / knowledgebase / ASSEMBLY_URL = rsync :// ftp . ncbi . nlm . nih . gov / genomes / ASSEMBLY_REPORTS / All ENTREZ_URL = http :// eutils . ncbi . nlm . nih . gov / entrez / eutils ENT REZ_BATCH_SIZE = ’1000 ’

Ten eerste zien we de LOGFILE definitie. Deze geeft aan welk bestand als log gebruikt dient te worden. De waarde dient een absoluut of relatief (ten opzicht van de locatie van de makefile)


22

pad te zijn. Deze configuratie wordt enkel door main.sh gebruikt, en zal bij elke aanroep van dit script overschreven worden. De make commando’s schrijven hun log naar stdout. Ook de MAIL optie dient voor main.sh. Deze configureert waar het falen of slagen gemeld moet worden. Vervolgens komen enkele locaties van directories. Voor correcte werking van de makefile dienen deze bestandsnamen ofwel ongebruikt te zijn, ofwel directories voor te stellen. Als de makefile merkt dat dit normale bestanden zijn, zal hij zijn werking onderbreken om deze niet te verwijderen. Deze paden worden ook absoluut of relatief opgegeven. • DATADIR is een lokale variabele, die enkel gebruikt wordt om de komende locaties korter neer te schrijven. Indien hij niet gebruikt wordt in het configuratiebestand, kan hij verwijderd worden. • TABDIR is de naam van de directory waarin de finale tabellen opgeslagen moeten worden. Dit zijn slechts enkele bestanden, die varieren van klein (12MB voor de gecomprimeerde lineages tabel) tot vrij groot (9.8G voor de gecomprimeerde peptides tabel). • UNIDIR is de directory waarin de twee bronbestanden van Unipept gedownload zullen worden. Tevens bevat deze locatie een zeer klein timestamp bestand om de publicatiedatum van de andere bestanden bij te houden. • In TAXDIR wordt de gezipte taxon dump van NCBI geplaatst, samen met de twee uitgepakte bestanden die hieruit gebruikt worden. Dit zijn allemaal bestanden kleiner dan 150MB. • De ASMDIR zal na het uitvoeren van de parser zeer veel kleine bestanden (39850 van gemiddeld 105KB op het moment van schrijven) bevatten, welke rechtstreeks gedownload worden van NCBI. • INTDIR wordt gebruikt om enkele tussenresultaten op te slaan voor deze verder gebruikt worden. Deze bestanden worden na een succesvolle parsing automatisch verwijderd. • Tenslotte wordt BDBDIR gebruikt om de hulpbestanden van BerkeleyDB in op te slaan. Ook deze locatie zal tijdelijk zeer veel kleine bestanden komen te bevatten, om BerkeleyDB van random access te kunnen voorzien. BDBDIR komt best op een schijf met snelle lees- en schrijftoegang te staan. Het volgende blok bevat enkele parameters voor Java in het algemeen en BerkeleyDB specifiek. Deze worden best aangepast aan de machine waarop de parser uitgevoerd zal worden. Als voorbeeld staan twee configuraties. Eén in commentaar, voor een parser die loopt op een machine met 200G RAM. We geven Java 140G tot 150G RAM ter beschikking, waarvan we 100G laten gebruiken als cache door BerkeleyDB. De configuratie die niet in commentaar


23

staat, laat de parser toe op een laptop met 4G RAM uit te voeren. Dit is natuurlijk enkel haalbaar in tijd voor het parsen van SwissProt, en niet TrEMBL. Het verhogen van de cache van 500MB is dan onnodig, zoals beschreven in 2.2.6. Tenslotte volgen nog enkele URL’s waar eventuele mirror servers ingesteld kunnen worden en een batchsize voor aanvragen bij Entrez [15], welke best niet aangepast wordt. Nu, voor het gebruik van een makefile dient het make commando. Als argument aan make kan je nul of meerdere targets meegeven. Bij afwezigheid van argumenten wordt het default target gemaakt, in het geval van Unipept alle finale tabellen. Mogelijke targets zijn bestandsnamen van bestanden die je wilt maken, of enkele in de makefile gedefinieerde targets. Deze extra targets worden hieronder opgelijst: • Indien Maven ge¨ınstalleerd is op de machine, zal make jar een Java Archive maken dat door veel van de andere targets gebruikt zal worden. Dit is een synoniem voor make target/unipept-$(VERSION)-SNAPSHOT.jar. • Het uitvoeren van make download zal alle databronnen downloaden, zodat bijna geheel de rest van de commando’s geen verbinden met het internet meer zal vereisen. Enkel het opstellen van de assemblies en assembly sequences tabellen gebruikt nog internet, omdat de Entrez dienst live aangesproken dienen te worden. • make taxons zal gebruik maken van het NCBI taxon zipbestand en de taxons en lineages tabellen opstellen. • Met make tables worden de tabellen afhankelijk van de UniProtKB opgesteld. Enkel de sequences tabel zal nog ontbreken uit de TABDIR, en zich in INTDIR bevinden. • Daaraan worden door make sequences namelijk nog twee kolommen toegevoegd, die de LCA’s bevatten. • make assemblies handelt geheel onafhankelijk van de andere commando’s en zal de assemblies en assembly sequences tabellen opstellen. Het grootste deel van de download kan optioneel al uitgevoerd worden met make download, maar dit commando zal nog steeds internet vereisen voor de verbinding met Entrez. • Met make all (tevens het default target) worden al bovenstaande targets gemaakt. • make clean intermediates kan aangeroepen worden na het succesvol maken van alle tabellen. Het zal namelijk de tussentijdse bestanden verwijderen. • make clean zal, naast het oproepen van bovenstaand target ook alle finale tabellen verwijderen. • Tenslotte zal make pristine verder bouwen op make clean en ook alle gedownloade bestanden en de .jar verwijderen.


24

Het construeren van de Unipept databank gebeurt best aan de hand van een cron job op een server met veel geheugen. Samen met de makefile wordt een shell -script voorzien dat hiervoor gebruikt kan worden. Dit script maakt gebruik van een timestamp om te onthouden wat de laatst gedownloade versie van UniProtKB is. Tot het einde van deze sectie wordt nu dit script overlopen en becommentarieerd. 1

# !/ bin / bash

2 3

source config

4 5 6

set -e trap " rm -f $oldstamp ; mailx -s ’ Unipept Database Build Failed ’ -a ’ $LOGFILE ’ ’ $MAIL ’ <<<’ EOM ’ " EXIT

Het script maakt duidelijk dat dit een shell -script is, en leest de config file in om alle configuratie juist te zetten. Verder zorgen set en trap ervoor dat het script crasht bij de eerste fout, en op dat moment een mail zal versturen naar het geconfigureerde adres met het logbestand in bijlage. 7 8 9 10 11 12 13 14 15 16 17 18 19 20

log () { exec 3 >&1 exec >> " $LOGFILE " if [ -z " $1 " ]; then while read line ; do echo " [ $ ( date ) ] $line " done else echo " [ $ ( date ) ] $ * " fi exec >&3 } true > " $LOGFILE " log " Starting unipept backend run . "

De log-functie wordt gedefinieerd. Deze zal ofwel een argument nemen en dit in het logbestand schrijven, vergezeld van een tijdstip, ofwel aan elke lijn op stdin een tijdstip toekennen en ze doorgeven aan het logbestand. Hierna zal het script het logbestand leeg maken en de nieuwe uitvoering aankondigen. 21 22

newstamp = " $ ( mktemp ) " oldstamp = " $UNIDIR /. STAMP "

23 24 25

# Get the new " Last Modified " stamp from uniprot . curl -s -- head " $UNIPROT_URL / uniprot_trembl . xml . gz " > " $newstamp "

26 27 28

# If there ’ s an old stamp and it ’ s the same as the new one , there ’ s # no new database , so we just exit .

HOOFDSTUK 2. DE UNIPEPT DATABANK 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

25

if [ -f " $oldstamp " ]; then if diff -q " $oldstamp " " $newstamp " 2 >/ dev / null ; then log " No new version available online . " log " Current version is $ ( head -1 " $oldstamp " ) " trap - EXIT exit fi log " New version available online . " log " Old version was $ ( head -1 " $oldstamp " ) " log " New version is $ ( head -1 " $newstamp " ) " else mkdir -p " $UNIDIR " touch " $oldstamp " log " No local version . " log " New version is $ ( head -1 " $newstamp " ) " fi

Dit deel van de code regelt de timestamping van de UniProt bronnen. De locatie van de oude timestamp bevindt zich in oldstamp, de nieuwe wordt in een tijdelijk bestand geplaatst. Als oldstamp geen bestaand bestand is, wordt dat in het logbestand geschreven en beginnen we een nieuwe uitvoering. Zijn de timestamps verschillend, dan loggen we beide en beginnen we ook een nieuwe download. Enkel als de versie onveranderd is, stoppen we de uitvoering. 45 46 47 48

# Start the actual downloads . log " Starting download . " make -- quiet -B download > >( log ) 2 >&1 log " Finished download . "

De download wordt gescheiden van de andere berekeningen uitgevoerd. Deze duurt namelijk vrij lang en gaat vaak mis. Door hem apart te plaatsen, is het snel duidelijk waar de fout precies veroorzaakt werd. Merk op dat > >(log) 2>&1 wordt gebruikt in plaats van 2>&1 | log om de exit-code van het voorgaande commando te bewaren en de set -e niet teniet te doen. 49 50 51 52 53 54

# If we ’ ve got maven installed , rebuild the backend . if hash mvn 2 >/ dev / null && [ -f pom . xml ]; then log " Rebuilding the unipept jar . " make -- quiet jar > >( log ) 2 >&1 log " Finished rebuilding the unipept jar . " fi

Het maken van de Jar is ook afgezonderd van de rest van de berekeningen. Dit zorgt ervoor dat machines zonder maven een eigen Jar kunnen gebruiken, maar machines met maven wel kunnen verzekeren dat ze de laatste versie van de Jar gebruiken. 55

# Rebuild everything with the new downloads ( and new jar ) .

HOOFDSTUK 2. DE UNIPEPT DATABANK 56 57 58

26

log " Starting calculation of the database tables . " make -- quiet > >( log ) 2 >&1 log " Finished calculation of the database tables . "

59 60 61 62 63

# Everythin went well , let ’ s clean . log " Starting the cleanup . " make -- quiet clean_intermediates > >( log ) 2 >&1 log " Finished the cleanup . "

64 65 66 67

trap - EXIT mv " $newstamp " " $oldstamp " mailx -s " Unipept Database Build Successful " -a " $LOGFILE " " $MAIL " <<<" EOM "

Tenslotte worden de tabellen opgesteld met een make all. Indien niets foutliep, zullen de tussentijdse bestanden opgeruimd worden, zal de nieuwe timestamp weggeschreven worden, en zal een mail gestuurd worden om het succes te melden.

2.3.2

Introductie tot make

Een makefile wordt normaalgezien gebruikt in grote gecompileerde projecten. In plaats van bij elke wijziging alles opnieuw te compileren, zouden enkel het gewijzigde bestand gemaakt moeten worden. Er kunnen echter bestanden afhangen van dit opnieuw gecompileerde objectbestand. Deze moeten dan ook opnieuw gemaakt worden, en zo zal de wijziging propageren waar nodig. Een makefile is een bestand dat enerzijds beschrijft welke bestanden waarvan afhankelijk zijn en anderzijds hoe een bestand opgebouwd kan worden uit de bestanden waarvan het afhankelijk is. Een basis-makefile bestaat uit een reeks regels (rules) van volgend formaat: target ... : prerequisites ... recipe ... Het target of doel is ofwel de naam van het bestand dat door deze regel gegenereerd wordt, ofwel de naam van een actie die deze regel zal uitvoeren. De prerequisites of voorwaarden zijn ofwel bestanden die de regel als input zal gebruiken, ofwel acties waarvan deze regel afhankelijk is. In de praktijk betekent dit dat als één van deze bestanden recenter werd ge¨ updatet dan het doelbestand, het doelbestand ook opnieuw gemaakt moet worden. Tenslotte volgen een aantal lijnen recipe, het recept. Dit recept, net als een recept in een kookboek, beschrijft hoe met de ingrediënten (de voorwaarden) een gerecht (het doel) kan gemaakt worden. Deze worden door de SHELL variabele, standaard /bin/sh, uitgevoerd.


2.3.3

27

Afhankelijkheden en recepten

In dit hoofdstuk wordt de makefile, gebruikt door de Unipept databank, overlopen en becommentarieerd. 1

SHELL := / bin / bash

2 3

include config

4 5 6 7 8 9 10 11 12 13 14 15

TABLES = \ $ ( TABDIR ) / peptides . tsv . gz \ $ ( INTDIR ) / sequences . tsv . gz \ $ ( TABDIR ) / uniprot_entries . tsv . gz \ $ ( TABDIR ) / r ef s eq _c r os s _r ef e re n ce s . tsv . gz \ $ ( TABDIR ) / ec_cross_references . tsv . gz \ $ ( TABDIR ) / embl _cro ss_re fere nc es . tsv . gz \ $ ( TABDIR ) / go_cross_references . tsv . gz SRC = $ ( shell find src / - type f - name ’*. java ’) JAR = target / unipept -0.0.1 - SNAPSHOT . jar PAC = org . unipept . tools

De makefile begint met het instellen van bash als shell om de recepten uit te voeren. Hierdoor kunnen enkele constructies uit Bash gebruikt worden die niet in elke shell beschikbaar zijn. Vervolgens wordt het configuratiebestand ingelezen, net als in main.sh. Merk op dat dit vereist dat deze file door bash en make leesbaar moet zijn. Dit beperkt de syntaxis tot het definiëren van variabelen, maar dat is voor de configuratie voldoende. Dan definiëren we nog enkele variabelen om de regels wat leesbaarder en korter te maken. De SRC variabele wordt berekend door gewoon alle java bronbestanden op te lijsten. 16

17 18 19 20 21 22

23

all : $ ( TABDIR ) / taxons . tsv . gz $ ( TABDIR ) / lineages . tsv . gz $ ( TABLES ) $ ( TABDIR ) / sequences . tsv . gz $ ( TABDIR ) / assemblies . tsv . gz $ ( TABDIR ) / assembly_sequences . tsv . gz jar : $ ( JAR ) taxons : $ ( TABDIR ) / taxons . tsv . gz $ ( TABDIR ) / lineages . tsv . gz tables : $ ( TABLES ) sequences : $ ( TABDIR ) / sequences . tsv . gz assemblies : $ ( TABDIR ) / assemblies . tsv . gz $ ( TABDIR ) / assembly_sequences . tsv . gz download : $ ( TAXDIR ) / taxdmp . zip $ ( UNIDIR ) / uniprot_sprot . xml . gz # $ ( UNIDIR ) / uniprot_trembl . xml . gz rsync -- ignore - existing " $ ( ASSEMBLY_URL ) / GCA_ *. assembly . txt " $ ( ASMDIR )

Nu de variabelen gedefinieerd zijn, kunnen de acties opgesteld worden. De eerste regel is de standaardregel, die all heet. Om de all actie te voltooien, moeten alle finale bestanden gemaakt worden. Eenmaal deze bestanden gemaakt zijn, hoeft er niets meer te gebeuren, dus is er geen recept.


28

De andere acties zijn gelijkaardig, op de download actie na. Deze actie zal naast het vereisen van de bronbestanden (die door andere regels gedownload zullen worden) de assemblage bestanden downloaden. Dit moet gescheiden verlopen, omdat dit te veel bestanden zijn om in regels te plaatsen. 24 25 26

# Compiling $ ( JAR ) : $ ( SRC ) mvn package

27 28

%. class : $ ( JAR )

Deze twee regels zorgen ervoor dat het jar-bestand aangemaakt zal worden met behulp van Maven als een andere regel een class-bestand of de jar zelf nodig heeft. 29 30 31 32 33 34 35

# Downloading $ ( TAXDIR ) / taxdmp . zip : echo " Starting taxon dump download . " mkdir -p $ ( TAXDIR ) - rm -f $@ wget --no - verbose " $ ( TAXON_URL ) " -O $@ echo " Finished taxon dump download . "

Deze regel vormt de eerste stap in het maken van de taxons en lineages tabellen: het downloaden van de taxonomie van NCBI. Deze regel heeft geen voorwaarden, en is dus een blad in de afhankelijkheidsgraaf. Het recept om het zip-bestand te verkrijgen bestaat uit het verzekeren dat er plaats is (door de directory aan te maken indien die niet zou bestaan), eventuele oude versies te verwijderen en een nieuwe versie met wget te downloaden. De speciale variable $@ die gebruikt wordt, is een synoniem voor het doel dat gemaakt wordt. 36 37 38 39

$ ( TAXDIR ) / names . dmp $ ( TAXDIR ) / nodes . dmp : $ ( TAXDIR ) / taxdmp . zip echo " Starting unzipping names and nodes from the taxon dump . " unzip - DDo $ < $ ( notdir $@ ) -d $ ( dir $@ ) echo " Finished unzipping names and nodes from the taxon dump . "

Met deze regel zien we al de eerste uitzondering op het algemene template uit sectie 2.3.2. Er staan twee doelen. Door, net zoals in vorige regel, de variabele $@ te gebruiken, kunnen twee of meer regels soms samengevoegd worden. $@ wordt dan vervangen door het doel dat ditmaal gemaakt moet worden. We maken hier ook gebruik van de speciale variabele $<, welke vervangen wordt door de eerste voorwaarde, in dit geval $(TAXDIR)/taxdmp.zip. In dit geval zijn de twee doelen twee bestanden die we beide uit hetzelfde zip-bestand kunnen halen. 40 41 42

$ ( UNIDIR ) / uniprot_sprot . xml . gz $ ( UNIDIR ) / uniprot_trembl . xml . gz : echo " Starting downloading $@ . " mkdir -p $ ( UNIDIR )

HOOFDSTUK 2. DE UNIPEPT DATABANK 43 44 45

29

rm -f $@ wget -- progress = dot : giga " $ ( UNIPROT_URL ) $ ( notdir $@ ) " -O $@ echo " Finished downloading $@ . "

Ook deze regel heeft twee doelen. Beide UniProt bestanden worden namelijk op dezelfde plaats gedownload. Geen reden om de regels dus niet samen te voegen en zo codeduplicatie te verhinderen. Deze regel is gelijkaardig aan de regel om taxdmp.zip. We tonen echter een progress bar om de vooruitgang van deze (langdurige) download te tonen. Hierop volgend komt de eerste complexere regel: 46 47

48 49 50

51

# Taxons and Lineages $ ( TABDIR ) / taxons . tsv . gz $ ( TABDIR ) / lineages . tsv . gz : $ ( TAXDIR ) / names . dmp $ ( TAXDIR ) / nodes . dmp echo " Starting calculation of taxons and lineages tables . " mkdir -p $ ( dir $@ ) java $ ( JMEMMIN ) $ ( JMEMMAX ) - cp $ ( JAR ) $ ( PAC ) . N a m e s N o de s 2 T a x o n s L i n e a g e s $ ( TAXDIR ) / names . dmp $ ( TAXDIR ) / nodes . dmp $ ( TABDIR ) / taxons . tsv . gz $ ( TABDIR ) / lineages . tsv . gz echo " Finished calculation of taxons and lineages tables . "

De taxons en lineages tabellen worden opgesteld. Hiervoor zijn de twee dumps van NCBI noodzakelijk. Beide worden meegegeven aan de java NodesNames2TaxonsLineages klasse, tezamen met enkele configuratieparameters. Daarvoor wordt nog kort verzekerd dat $(dir $@), de directory waar het doelbestand in terecht zal komen, wel bestaat. 52 53

54 55 56 57

58 59

# Uniprot entries , peptides , sequences and cross references $ ( TABLES ) : $ ( TABDIR ) / taxons . tsv . gz $ ( UNIDIR ) / uniprot_sprot . xml . gz $ ( UNIDIR ) / uniprot_trembl . xml . gz echo " Finished calculation of most tables . " mkdir -p $ ( BDBDIR ) mkdir -p $ ( INTDIR ) java $ ( JMEMMIN ) $ ( JMEMMAX ) - cp $ ( JAR ) $ ( PAC ) . Ta xonsU nipr ots2T able s $ ( BDBDIR ) $ ( BDBMEM ) $ ( TABDIR ) / taxons . tsv . gz $ ( TABLES ) $ ( UNIDIR ) / uniprot_sprot . xml . gz " swissprot " $ ( UNIDIR ) / uniprot_trembl . xml . gz " trembl " echo " Finished calculation of most tables . " # }}}

De regel om de meeste tabellen op te stellen wordt aangezet met het doel $(TABLES), een variabele die eerder al aangemaakt werd. Vervolgens worden de nodige directories aangemaakt, indien nodig. $(TABDIR) moet niet gecontroleerd worden, gezien de voorwaarde $(TABDIR)/taxons.tsv.gz het bestaan hiervan garandeert. Vervolgens wordt het javaprogramma dat de tabellen zal berekenen aangeroepen.


30

Deze aanroeping vereist wel wat uitleg. De eerste parameter aan het programma zelf, is $(BDBDIR). Deze deelt mee aan TaxonsUniprots2Tables waar het de bestanden van BerkeleyDB mag plaatsen. De parameter erna, hier $(BDBMEM), geeft mee hoeveel geheugen BerkeleyDB mag gebruiken voor zijn indexering. De volgende parameter is de eerder berekende taxons tabel. Daarna komen de output-tabellen en diverse parameters gescheiden door spaties in de TABLES variabele. Tot slot komen in paren de te parsen xml-bestanden en hun namen. Deze paren kunnen één of meerdere keren voorkomen. 60 61

62 63 64 65 66 67 68 69 70

# Sequences with LCA $ ( INTDIR ) / sequence_taxon . tsv . gz : $ ( TABDIR ) / peptides . tsv . gz $ ( TABDIR ) / uniprot_entries . tsv . gz echo " Starting the joining of equalized peptides and uniprot entries . " mkdir -p $ ( INTDIR ) join -t ’ ’ -o ’1.2 ,2.4 ’ -1 4 -2 1 \ <( zcat $ ( TABDIR ) / peptides . tsv . gz ) \ <( zcat $ ( TABDIR ) / uniprot_entries . tsv . gz ) \ | sort -S 20% - k1n \ | gzip - \ > $@ echo " Finished the joining of equalized peptides and uniprot entries . "

71 72

73 74 75 76 77 78 79 80 81

$ ( INTDIR ) / o ri g in al _ se q ue nc e _t a x o n . tsv . gz : $ ( TABDIR ) / peptides . tsv . gz $ ( TABDIR ) / uniprot_entries . tsv . gz echo " Starting the joining of non - equalized peptides and uniprot entries . " mkdir -p $ ( INTDIR ) join -t ’ ’ -o ’1.3 ,2.4 ’ -1 4 -2 1 \ <( zcat $ ( TABDIR ) / peptides . tsv . gz ) \ <( zcat $ ( TABDIR ) / uniprot_entries . tsv . gz ) \ | sort -S 20% - k1n \ | gzip - \ > $@ echo " Finished the joining of non - equalized peptides and uniprot entries . "

Eenmaal de lineages, peptides en uniprot entries berekend zijn, kan de berekening van de LCA’s beginnen. Deze begint met het joinen van ID’s van tryptische peptiden met het ID van het taxon waartoe ze behoren. Hetzelfde gebeurt, maar dan met de peptiden waar aminozuur I niet gelijk werd gesteld aan aminozuur L. Omdat join niet met gegzipte bestanden kan werken, geven we file descriptors naar gegunzipte versies in plaats van gewoon bestandsnamen. Door deze join daarna te sorteren, komen alle gelijke peptiden gegroepeerd te staan. Als alle taxon ID’s van gelijke peptiden gegroepeerd zijn, kan hun LCA makkelijk berekend worden. Dit wordt dan ook gedaan in de volgende regels. 82

$ ( INTDIR ) / LCAs . tsv . gz : $ ( TABDIR ) / lineages . tsv . gz $ ( INTDIR ) / sequence_taxon . tsv . gz

HOOFDSTUK 2. DE UNIPEPT DATABANK 83 84

85

31

echo " Starting the calculation equalized LCA ’ s . " java $ ( JMEMMIN ) $ ( JMEMMAX ) - cp $ ( JAR ) $ ( PAC ) . L i n e a g e s S e q u e n c e s T a x o n s 2 L C A s $ ^ $@ echo " Finished the calculation equalized LCA ’ s . "

86 87

88 89

90

$ ( INTDIR ) / original_LCAs . tsv . gz : $ ( TABDIR ) / lineages . tsv . gz $ ( INTDIR ) / o r i g i n al _ se qu e nc e _t ax o n . tsv . gz echo " Starting the calculation non - equalized LCA ’ s . " java $ ( JMEMMIN ) $ ( JMEMMAX ) - cp $ ( JAR ) $ ( PAC ) . L i n e a g e s S e q u e n c e s T a x o n s 2 L C A s $ ^ $@ echo " Finished the calculation non - equalized LCA ’ s . "

Deze twee bijna identieke regels zullen LineagesSequencesTaxons2LCAs aanroepen om een mapping van elk tryptisch peptide op zijn LCA te berekenen. Dit moet twee maal gebeuren: eenmaal voor de ge¨ unificeerde peptiden en eenmaal voor de niet ge¨ unificeerde algoritmen. In deze regels wordt een derde speciale variabele uit make ge¨ıntroduceerd: $^ zal vervangen worden door de lijst van alle voorwaarden. 91

92 93 94

95

96 97 98

$ ( TABDIR ) / sequences . tsv . gz : $ ( INTDIR ) / sequences . tsv . gz $ ( INTDIR ) / LCAs . tsv . gz $ ( INTDIR ) / original_LCAs . tsv . gz echo " Starting the creation of the sequences table . " zcat $ ( INTDIR ) / sequences . tsv . gz \ | join -- nocheck - order - a1 -t ’ ’ -o " 1.1 1.2 2.2 " - <( zcat $ ( INTDIR ) / original_LCAs . tsv . gz ) \ | join -- nocheck - order - a1 -t ’ ’ -o " 1.1 1.2 1.3 2.2 " - <( zcat $ ( INTDIR ) / LCAs . tsv . gz ) \ | gzip - \ > $@ echo " Finished the creation of the sequences table . "

Als de normale LCA en de ge¨ unificeerde LCA berekend zijn, kunnen zij samensamen met de intermediaire sequences-tabel tot de finale sequences-tabel gemaakt worden. Wat nog overblijft zijn twee regels om de assemblies en assembly sequences tabellen op te stellen. 99 100

101 102 103

104 105 106 107 108

# Assembly tables $ ( INTDIR ) / unst raine d_as sembl ies . tsv . gz $ ( TABDIR ) / assembly_sequences . tsv . gz : parse_assemblies . awk echo " Starting the assembly parsing . " mkdir -p $ ( ASMDIR ) rsync -- ignore - existing --no - motd -- verbose " $ ( ASSEMBLY_URL ) / GCA_ *. assembly . txt " $ ( ASMDIR ) find $ ( ASMDIR ) - name ’ GCA_ *. assembly . txt ’ \ | sort \ | xargs cat \ | awk -f parse_assemblies . awk \ -v assemblies_file = >( sed -e ’s / * */ /g ’ -e ’s / * $$ // ’ | gzip - > $ ( INTDIR ) / un stra ined_ asse mblie s . tsv . gz ) \

HOOFDSTUK 2. DE UNIPEPT DATABANK 109

110

32

-v as s em bl y _s e qu en c es _f i le = >( cut -f1 ,2 ,6 ,7 | sed -e ’s /\.[^.]*// ’ -e ’s / * ^ A · */ ^ A · /g ’ -e ’s / * $$ // ’ | gzip - > $ ( TABDIR ) / assembly_sequences . tsv . gz ) echo " Finished the assembly parsing . "

Deze regel is complexer dan de voorgaande. Na het aanmaken van een directory voor de bestanden, worden de assemblagebestanden van NCBI gedownload. Bemerk dat dit een kopie is van de regel bij doel download, maar door de grote hoeveelheid bestanden kan dit niet in een aparte regel ondergebracht worden. Na het downloaden van de assemblagebestanden lijsten we ze op, en sorteren we ze op naam. De bestanden worden in één groot bestand samengevoegd en dan naar een awk programma gestuurd. Dit programma neemt zijn twee outputbestanden als variabelen aan. Deze outputbestanden zijn file descriptors, zodat de output nog aangepast kan worden in een pijplijn voor deze effectief uitgeschreven wordt. Zo wordt er bij de assemblies tabel nog voor gezorgd dat er geen velden eindigen op spaties. Bij de assembly sequences tabel wordt naast diezelfde operatie ook nog eens een selectie uit de tabellen genomen en wordt het versienummer van de GenBank Accession Number kolom verwijderd. 111

112 113

114

$ ( TABDIR ) / assemblies . tsv . gz : $ ( INTDIR ) / unstr aine d_ass embl ies . tsv . gz s t r a ins_assembly_ids . sh echo " Starting the straining of assemblies . " ENTREZ_URL = $ ( ENTREZ_URL ) ENTREZ_BATCH_SIZE = $ ( ENTREZ_BATCH_SIZE ) ./ s t rains_assembly_ids . sh $ ( INTDIR ) / un strai ned_ assem blie s . tsv . gz $@ echo " Finished the straining of assemblies . "

Tenslotte wordt in een apart script nog een kolom toegevoegd aan de assemblies tabel, welke aanduidt of deze assemblage typemateriaal is. Wegens incompleetheid van de NCBI assemblagebestanden werkt deze aanpak niet altijd. Met een andere werking, reeds ge¨ımplementeerd in een apart Pythonscript kan deze incompleetheid vermeden worden. Dit script is echter nog onbruikbaar traag en dient nog aangepast te worden voor publicatie. 115 116 117 118

. PHONY : clean_intermediates c l ea n _ in termediates : rm - vf $ ( INTDIR ) /* rm - vf $ ( TAXDIR ) / names . dmp $ ( TAXDIR ) / nodes . dmp

119 120 121 122 123 124

. PHONY : clean clean : c lean_intermediates rm - vf $ ( TABDIR ) / taxons . tsv . gz $ ( TABDIR ) / lineages . tsv . gz rm - vf $ ( TABDIR ) / assemblies . tsv . gz $ ( TABDIR ) / assembly_sequences . tsv . gz rm - vf $ ( TABLES )

125 126

. PHONY : pristine

HOOFDSTUK 2. DE UNIPEPT DATABANK 127 128 129 130 131

33

pristine : clean rm - vf $ ( JAR ) rm - vf $ ( TAXDIR ) / taxdmp . zip rm - vf $ ( UNIDIR ) / uniprot_sprot . xml . gz $ ( UNIDIR ) / uniprot_treml . xml . gz find $ ( ASMDIR ) / - name ’*. assembly . txt ’ - exec rm - vf \{\} \;

Helemaal op het einde van de makefile volgen nog enkele regels om de gemaakte bestanden terug te verwijderen. Voor uiteindelijk gebruik zal enkel clean intermediates nuttig zijn, maar ook voor het verwijderen van alle tabellen en zelfs de jar en bronbestanden zijn regels voorzien.

Hoofdstuk 3

Lokaal deployen van Unipept Niet voor alle gebruikers, voornamelijke grote gebruikers zoals bedrijven of grote onderzoeksinstellingen, is het even haalbaar om Unipept over het internet te gebruiken. De verbinding kan te traag zijn, of men wil/kan eigen data niet zomaar uitsturen voor analyse naar een externe toepassing. Zo kan een arts de gegevens van een patiënt niet laten analyseren, of kunnen onderzoeksinstellingen met vertrouwelijke data geen gebruik maken van Unipept. Dit kan opgelost worden door lokaal een instantie van Unipept uit te voeren. In de praktijk blijkt dat echter niet altijd even eenvoudig. Biologen hebben vaak geen ervaring met het opzetten van een server. Om deze reden is het beter om een Virtuele Machine (VM) ter beschikking te stellen van de gebruiker. De gebruiker hoeft enkel deze VM op een eigen computer uit te voeren, waar standaard procedures voor zijn. Een virtuele machine bevat c echter veel extra’s, naast de eigenlijke server. Docker biedt hiervoor een oplossing.

3.1

c Over Docker

c Docker is een open platform dat door programmeurs en systeem beheerders gebruikt kan worden om hun toepassing eenvoudig te bouwen en te verspreiden. Ook het gedistribueerd uitvoeren van applicaties is mogelijk met Docker.

De Docker Engine vormt een laag tussen het besturingssysteem en de applicatie, waardoor de applicatie op elk besturingssysteem hetzelfde zal werken. Hierdoor moeten niet voor elk mogelijk besturingzsysteem tests uitgevoerd worden en installatie-instructies geschreven worden. Tegelijk komt Docker met de Docker Hub. Dit is een cloud service waar men Docker containers (de container die de applicatie bevat) gecentraliseerd kan downloaden. Ditzelfde kan ook bereikt worden door het bouwen van een virtuele machine en deze in zijn geheel te verspreiden. Docker heeft echter enkele voordelen ten opzichte van virtuele machines. 34

HOOFDSTUK 3. LOKAAL DEPLOYEN VAN UNIPEPT

35

Elke virtuele machine draagt namelijk een volledig besturingssysteem met zich mee. Docker containers bevatten zelf geen besturingssysteem. Dit is vervangen door de eerder vernoemde Docker Engine. Deze wordt echter gedeeld tussen alle containers op dezelfde fysieke machine, waardoor de container zelf veel lichter wordt.

3.2

Installatie en gebruik

Om een Unipept instantie lokaal te deployen moet men beschikken over een werkende installatie van Docker zelf, en een Docker container met daarin de Unipept webapplicatie. De installatie van Docker zelf is uitgebreid gedocumenteerd op hun website [1]. De container zou, na publicatie, gewoon van de Docker Hub gedownload kunnen worden. Om zelf een container te bouwen, dient men gewoon het commando docker build -t unipept . uit te voeren in de root directory van de Unipept repository. Alvorens de Unipept container zelf gestart wordt, moet eerst een databank opgezet worden. Ook dit gebeurt in een Docker container die verkregen zal kunnen worden op de Docker Hub. Voorlopig kan hij gebouwd worden met het uitvoeren van docker build -t unipept-mysql . in de mysql-docker directory. Het eigenlijke starten van de databank gebeurt met het commando docker run --name unipept-mysql unipept-mysql Eenmaal de databank werd opgestart, kan de Unipept container gestart worden met docker run --name unipept --link unipept-mysql:mysql -p 80:80 unipept In dit commando wordt de Unipept container onmiddellijk gelinkt aan de databank container. Ook wordt de webapplicatie opengesteld op poort 80. Beide commando’s worden best als daemon in de achtergrond gelopen door -d mee te geven als vlag. Eenmaal deze containers gestart zijn, kunnen ze gepauzeerd en terug gestart worden met docker stop en docker start , met als naam ofwel “unipept” ofwel “unipeptmysql”. Merk op dat de databank steeds opgestart dient te worden voor en afgesloten dient te worden na de webapplicatie om corruptie te vermijden. Merk op dat, om een Unipept instantie te kunnen draaien, een server minstens 100GB op de harde schrijf te beschikking moet hebben om de databank op te slaan. Het is ook aan te raden om meer dan 16GB RAM ter beschikking te stellen aan Unipept.


3.3

36

Werking Dockerfile

Net zoals de werking van make door een makefile bepaald wordt, zal de opbouw van een Docker container door een Dockerfile bepaald worden. In deze sectie wordt de Dockerfile horende bij de Unipept container in detail besproken. 1 2

FROM ubuntu :14.04 MAINTAINER unipept@ugent . be

Docker containers worden opgebouwd in lagen. Elk commando in een Dockerfile legt een nieuwe laag bovenop een bestaande. Met behulp van het FROM commando geeft men aan op welke reeds bestaande container men verder wilt bouwen. Bij het builden van deze container wordt dan eerst de bestaande container gedownload van de Docker Hub. Het eerste dat deze Dockerfile wijzigt aan de basis, een Ubuntu container, is wie de container zal onderhouden. Dit wordt aangegeven met het MAINTAINER commando. 3

4

RUN echo mysql - server mysql - server / root_password password rootpassword | debconf - set - selections && \ echo mysql - server mysql - server / root_password_again password rootpassword | debconf - set - selections

Vervolgens komt een kleine laag die de MYSQL root wachtwoorden configureert. Omdat het bouwen van een container met een Dockerfile niet interactief kan verlopen, moeten deze op voorhand geconfigureerd worden. Het RUN commando staat toe om commando’s uit te voeren in een niet-interactieve bash omgeving. Elk RUN commando voegt een nieuwe laag toe aan de container, waarin het gegeven commando uitgevoerd werd. 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

RUN apt - get update && \ apt - get install - qq -y \ git \ unzip \ curl \ ca - certificates \ apache2 \ mysql - server \ libcurl4 - openssl - dev \ apache2 - threaded - dev \ libapr1 - dev \ libaprutil1 - dev \ ruby - rmagick \ libmagickwand - dev \ nodejs \ --no - install - recommends && \ rm - rf / var / lib / apt / lists /*


37

Als de MYSQL wachtwoorden ingesteld zijn, installeren we MYSQL tegelijkertijd met de verschillende programma’s die de Unipept container zal gebruiken. De opties -y, -qq en --no-install-recommends zijn noodzakelijk om het apt-get commando in stilte en nietinteractief uit te voeren. Als alle updates ge¨ınstalleerd zijn, verwijdert het commando de gedownloade lijsten van pakketten om plaats te besparen in de container. Dit dient in hetzelfde RUN commando te gebeuren omdat Docker elke laag apart zal bijhouden in een soort geschiedenis. Het verwijderen van de lijsten in een ander commando zou niet verhinderen deze lijsten in één van de tussentijdse containers bij te houden. 6 7 8

9

10 11

12 13

14 15 16

17 18 19 20 21 22

RUN \ # enable some modules ln -s / etc / apache2 / mods - available / expires . load / etc / apache2 / mods - enabled / && \ ln -s / etc / apache2 / mods - available / headers . load / etc / apache2 / mods - enabled / && \ # enable ‘*. json ‘ compression in ‘/ etc / apache2 / mods - enabled / deflate . conf ‘ sed -i ’/ rss / a \\ t \ tA ddO ut pu tFi lt er ByT yp e DEFLATE application / json ’ / etc / apache2 / mods - enabled / deflate . conf && \ # Installing Ruby gpg -- keyserver hkp :// keys . gnupg . net -- recv - keys 409 B 6 B 1 7 9 6 C 2 7 5 4 6 2 A 1 7 0 3 1 1 3 8 0 4 B B 8 2 D 3 9 D C 0 E 3 && \ curl -L https :// get . rvm . io | bash -s stable && \ mkdir -p $ { APACHE_RUN_DIR : -/ var / run / apache2 } && \ mkdir -p $ { APACHE_RUN_USER : - www - data } $ { APACHE_LOCK_DIR : -/ var / lock / apache2 } && \ bash -c ’ \ . / etc / profile . d / rvm . sh ; \ rvm install 2.1; \ gem install passenger ; \ . / etc / apache2 / envvars ; \ yes | passenger - install - apache2 - module ’

De volgende laag is een configuratielaag bovenop de installatielaag. De pakketten die in de vorige laag ge¨ınstalleerd werden, worden hier geconfigureerd voor gebruik. In deze laag zal ook Ruby ge¨ınstalleerd worden met behulp van rvm. Merk op hoe bepaalde commando’s binnen een eigen bash-shell uitgevoerd worden. Dit is noodzakelijk omdat rvm en gem beide commando’s zijn die gebruik maken van wijzigingen in de omgevingsvariabelen. Docker zal echter tussen twee commando’s door de omgeving sluiten en opnieuw openen, waardoor deze verloren gaat. Om wijziging van de omgeving zo min mogelijk door te zetten, kan deze binnen een eigen shell gehouden worden. 23 24 25

RUN mkdir -p / root / rails WORKDIR / root / rails ADD Gemfile / root / rails /

HOOFDSTUK 3. LOKAAL DEPLOYEN VAN UNIPEPT 26 27 28 29

38

# mac only gem RUN sed -i ’/ terminal - notifier - guard /d ’ Gemfile ADD Gemfile . lock / root / rails / RUN bash -c ’. / etc / profile . d / rvm . sh ; bundle install -- system ’

30 31 32 33 34 35 36 37 38 39

ADD ADD ADD ADD ADD ADD ADD ADD RUN

app / / root / rails / app / config / / root / rails / config / db / / root / rails / db / lib / / root / rails / lib / public / / root / rails / public / script / / root / rails / script / vendor / / root / rails / vendor / Capfile config . ru Guardfile LICENSE . md Rakefile README . md / root / rails / bash -c ’. / etc / profile . d / rvm . sh ; RAILS_ENV = production bundle exec rake assets : precompile ’

Hierna volgt een reeks van RUN, WORKDIR en ADD commando’s. Het RUN commando is al gekend. Met behulp van WORKDIR kan men het cd commando uit een gewone interactieve shell nabootsen. Het ADD commando werkt als het cp commando uit een gewone shell, maar zal een bestand of directory van het bestandssysteem waarop de container gebouwd wordt (relatief ten opzichte van de plaats waar het docker build commando aangeroepen werd) kopiëren naar de opgegeven locatie binnen de container. In de eerste reeks worden enkel de nodige bestanden toegevoegd om alle gems te kunnen installeren. Gems zijn Ruby pakketten die bibliotheken en programma’s bevatten, klaar voor gebruik. bundle is het commando dat alle gebruikte gems (zoals opgesomd in de Gemfile) zal installeren. Hierna wordt de applicatie zelf helemaal in de container gekopieerd. Door alle bestanden gescheiden te kopiëren kunnen overbodige bestanden vermeden worden. Tenslotte worden de assets, die statisch geserveerd worden maar dynamisch gedefinieerd zijn, reeds gecompileerd. 40 41 42 43 44

ADD apache_default / etc / apache2 / sites - available / default RUN / etc / init . d / apache2 restart EXPOSE 80 ADD entrypoint . sh / entrypoint . sh ENTRYPOINT " / entrypoint . sh "

Als nog een configuratiebestand voor Apache toegevoegd wordt, is de omgeving binnen de container klaar. Met het commando EXPOSE zorgen we dat poort 80 binnen de container ook van buitenaf beschikbaar gemaakt kan worden. Tenslotte voegen we met het ENTRYPOINT commando nog een commando toe dat uitgevoerd dient te worden bij het opstarten van de container. In entrypoint.sh wordt de webapplicatie gestart, nadat de databank gevuld werd. Op deze manier kunnen de containers verdeeld worden zonder dat deze data er bij inbegrepen moet


39

worden. Hieronder is de broncode van entrypoint.sh te vinden. 1

# !/ bin / bash

2 3 4

# Sourcing rvm . / etc / profile . d / rvm . sh

5 6 7

# Database setup rake db : setup

8 9 10 11 12 13 14 15 16 17 18 19

files =( " e c _cross_references . tsv " " e m b l _cro ss_re fere nces . tsv " " g o _cross_references . tsv " " lineages . tsv " " peptides . tsv " " r e f s eq _c r os s _r ef e re n ce s . tsv " " sequences . tsv " " taxons . tsv " " uniprot_entries . tsv " )

20 21

gateway = " $ ( route -n | grep ’^0.0.0.0 ’ | sed ’s /

*/

/g ’ | cut - f2 ) "

22 23 24 25 26 27 28 29 30 31 32

for file in " $ { files [ @ ]} " ; do echo " $file " curl -q " $gateway :8000/ $file " > " $file " sed -i ’1d ’ " $file " mysqlimport -- user = unipept - punipept \ -- host = " $ M Y S Q L _ P O RT _ 3 3 0 6 _ T C P _ A D D R " \ -- port = " $ M Y S Q L _ P O RT _ 3 3 0 6 _ T C P _ P O R T " \ -- local unipept " $file " rm " $file " done

33 34

passenger start -a 0.0.0.0 -p 80 -e production

Bij het starten van de docker wordt eerst het databankschema geladen in de databank met rake db:setup. Vervolgens moet de data zelf in de databank ge¨ımporteerd worden. Hiervoor worden de tabelbestanden gedownload van de host machine. Bij publicatie zou deze URL vervangen moeten worden door de locatie van een Unipept server die de dumps aanbiedt. Tenslotte wordt de passenger server gestart op poort 80. Door poort 80 bij het opstarten van de container dan naar buiten toe te forwarden kan men van buiten de container aan de lopende Rails server.

Hoofdstuk 4

Integrated Gene Catalog De Integrated Gene Catalog [7] (IGC) is een databank met 9,879,896 eiwitten, verkregen uit 249 stoelgangstalen uit het Metahit project en 1018 stoelgangstalen uit het Human Microbiome Project. De IGC bevat naast de eiwitten zelf ook annotaties met onder andere een taxonomische identificatie. Voor elk van de eiwitten worden het phylum en genus gegeven, indien gekend. Dit hoofdstuk omschrijft een case study waarin de taxonomische annotaties van de IGC, toegekend met behulp van BLAST [2], vergeleken werden met de annotaties die Unipept zou geven aan dezelfde eiwitten. Tevens worden de eiwitten in de IGC gebruikt om een kwaliteitscontrole uit te voeren op Unipept. Deze case study werd uitgevoerd in context van de Mastercursus Computationele Biologie gedoceerd door professor Dawyndt. Aan dit project werkten naast mijzelf ook Bart Broeckx, Jens Van de Weygaert, Stijn Seghers, Kevin Velghe, Giles Miclotte en Pieter Vander Vennet. De studie geeft ook een indicatie of het integreren van de IGC als databron voor Unipept, naast de UniProt KB, zinvol zou zijn. Tenslotte kunnen toekomstige gebruikers van de Docker container ook eigen referentiedatabanken indexeren bij het opstellen van de Unipept databank.

4.1

Metagenomics identificatie met Unipept CLI

Omwille van de grote hoeveelheid data die verwerkt moest worden, maakt deze studie geen gebruik van de Unipept Webapplicatie, maar van de bijhorende command line interface (CLI). Deze maakt gebruik van JSON requests naar de Unipept API. Door de verschillende command line tools aan elkaar te koppelen, kunnen krachtige berekeningen op eenvoudige wijze uitgevoerd worden. De eerste stap in het identificeren van eiwitten met Unipept bestaat uit het opbreken van 40

HOOFDSTUK 4. INTEGRATED GENE CATALOG

41

A B D

C E

H

F I

G J

Figuur 4.1: Toepassing van LCA* op een boom. De LCA* van {A, F, I, J} is F .

deze eiwitten in tryptische peptiden. De functie van trypsine wordt nagebootst door het prot2pept commando. Dit commando zal een bestand in FASTA formaat als input nemen en elk eiwit opsplitsen in tryptische peptiden, met behoudt van de FASTA headers. Vervolgens moeten deze peptiden gefilterd worden. Net zoals een massaspectrometer willen we enkel peptiden van lengte 5 tot 50 overhouden voor de rest van de berekening. Hiervoor staat het peptfilter commando ter beschikking. Dan begint het echte werk. Met het subcommando pept2lca van unipept wordt de Unipept API aangesproken om voor elke peptide zijn LCA op te halen. Als het IGC FASTA bestand (gecomprimeerd) opgeslagen was als IGC.pep.gz en we het resultaat willen opslaan in IGC.pep.lca.csv dan kan heel deze reeks commando’s uitgevoerd worden als 1

zcat IGC . pep . gz | prot2pept | peptfilter | unipept pept2lca > IGC . pep . lca . csv

De IGC geeft echter een identificatie per eiwit en niet per peptide. De LCA’s van alle peptiden uit een eiwit moeten dus nog geaggregeerd worden tot één LCA voor het eiwit. Hiervoor wordt pept2lca2lca gebruikt, een implementatie van het LCA* algoritme, geschreven door Tom Naessens [12]. De werking van LCA* wordt ge¨ıllustreerd in Figuur 4.1. Definiëren we A → B als “taxon B is een kind van taxon A in de taxonomische boom” en A →∗ B als “taxon B is een node in de deelboom van de taxonomische boom met wortel A”, dan geldt A = lca∗ (S), met S een verzameling van taxa, als en slechts als beide voorwaarden voldaan zijn: • (∀T ∈ S)(A →∗ T ∨ T →∗ A) • ¬(∃B ∈ S)(A 6= B ∧ B →∗ A ∧ (∀T ∈ S)(B →∗ T ∨ T →∗ B)) Om de LCA* van de peptiden in het eerder aangemaakte bestand te berekenen, volstaat het om volgend commando uit te voeren: 1 2

python tree - of - life / pept2lca2lca . py < IGC . pep . lca . csv \ | sed ’/^ >/! d ’ > IGC . pep . lca2lca . csv

Na deze stap zal IGC.pep.lca2lca.csv per eiwit een lijn bevatten, en per lijn 4 waarden gescheiden door een komma: de oorspronkelijke FASTA hoofding van dit eiwit en het ID, de


42

naam en de rang van het geaggregeerde taxon.

4.2

Nagaan van de consistentie

Neem enkele peptiden uit een eiwit afkomstig uit een koolmees. Sommige van die peptiden zullen enkel voorkomen in de koolmees. Anderen kunnen echter gemeenschappelijk zijn onder alle mezen, vogels, of zelfs gewoon alle levende wezens. Wat echter niet mogelijk is, is dat zo’n peptide kenmerkend zou zijn voor, pakweg, een chimpansee. Alle peptiden zouden op één pad moeten liggen van het taxon waar een staal uit genomen werd naar de wortel van de taxonomische boom. Om het met andere woorden te zeggen, de taxonomische rang van de LCA* van al deze peptiden zou gelijk moeten zijn aan de rang van het meest specifieke peptide. In Figuur 4.1 is dit echter niet het geval. We zien één rang verschil tussen de LCA* F en de meest specifieke peptiden, I en J. Wanneer dit niet het geval is, is dit aan twee redenen te wijten. Enerzijds kan het gegeven eiwit niet echt afkomstig zijn uit een bestaand organisme, maar uit een Chimera, een mix van andere organismen. Dit eiwit kan bijvoorbeeld ontstaan zijn door foutieve assemblage van een gesequeneerde DNA reads. Anderzijds kan de fout ook bij Unipept liggen. De peptiden worden misschien op verkeerde taxa afgebeeld. Met het volgende commando kan de inconsistentie onderzocht worden: 1 2

./ path_consistency . py IGC . pep . lca . csv IGC . pep . lca2lca > consist_output cut - f6 consist_output | sort | uniq -c > consist_counted

Op dit moment is de inhoud van consist counted als volgt: 1 2 3 4 5 6 7 8 9 10

3299304 5734535 164322 132203 208231 88340 418014 969839 517852 83987

0 1 2 3 4 5 6 7 8

De - betekent dat de LCA* de wortel van de taxonomische boom was. Dit wijst op een vermoedelijk incorrecte assemblage. Dit is het geval voor 3299304 van de 11616627 eiwitten, ofwel ongeveer 28%. Voor 5734535 eiwitten, wat 49% van het totaal is, is er geen inconsistentie in het pad te vinden. De overige 22% van de eiwitten bevat een lichte tot sterke inconsistentie.


4.3

43

Vergelijking IGC en Unipept

Naast het bekijken van de consistentie van de individuele taxonomische identificatie van alle tryptische peptiden van elk eiwit uit de IGC, kan ook gekeken worden naar de consistentie in taxonomische annotatie van de IGC en deze gemaakt door Unipept. Waar de IGC enkel een taxonomische identificatie maakt op phylum en genus niveau, geeft Unipept één identificatie op de meest specifieke rang die volgt uit de individuele identificaties van de tryptische peptiden. Dit maakt het analyseren van de verschillen niet gemakkelijk. Voor de verschillen geanalyseerd en gevisualiseerd kunnen worden, moeten ze eerst gevonden worden. Dit gebeurt aan de hand van het commando 1

diff / c a l c u l at e _ d if f _ a nd _ s t at s . sh IGC . annotation_OF . summary . gz IGC . pep . lca2lca . csv

Dit commando zal, in tegenstelling tot de vorige, geen stroom aan lijnen verhandelen, maar naar enkele vaste outputbestanden schrijven. Deze zijn: • diff/igc annotations.tsv: Hierin wordt een opgeruimde versie van de annotaties op de IGC geschreven. Elke regel bestaat uit de naam van een eiwit en zijn phylum en genus annotaties. Als er een annotatie ontbreekt, wordt deze vervangen door “unknown.” • diff/unipept lcas.tsv: Ook dit bestand bevat een regel per eiwit. Op elke regel komt de naam van het eiwit en het ID van het taxon dat Unipept eraan toekent. • diff/diff output.tsv: De werkelijke vergelijking komt in dit bestand terecht. Opnieuw bevat het bestand een regel per eiwit. De naam van het eiwit staat echter niet meer op die regel. Deze bevat de waarden die vergeleken worden (het phylum volgens de IGC, het genus volgens de IGC, het phylum volgens Unipept en het genus volgens Unipept), een kleurcode die het verschil duidelijk moet maken, en de taxonomische rang van de LCA*. De exacte kleurcodes worden later verduidelijkt. • diff/colored stats.tsv: Hierin kan een telling van het aantal voorkomens van kleurcode per taxonomische rang gevonden worden. Meer specifiek bevat elke regel een geheel getal, een kleurcode en een rang. Het geheel getal is het aantal keer dat deze combinatie van kleur en rang voorkwam in diff/diff output.tsv. • diff/mismatch stats.tsv: Bevat net als voorgaand bestand een telling, ditmaal van de combinaties van annotaties, indien deze niet gelijk zouden zijn voor de IGC en Unipept. • mismatch plot/stats.json: Tenslotte bevat dit bestand dezelfde informatie als voorgaand bestand, maar geherstructureerd in ander formaat. Hierdoor is dit bestand beter leesbaar door een later gemaakte visualisatie.


44

Uit de data in diff/diff output.tsv kan Figuur 4.2 gemaakt worden, met bijhorende legende in Figuur 4.3. Uit deze figuur kunnen enkele conclusies getrokken worden: • De overweldigende hoeveelheid middelgrijs geeft aan dat veel van de eiwitten niet ge¨ıdentificeerd kunnen worden, noch door de IGC noch door Unipept. • Het lichtgrijs stelt eiwitten voor die Unipept specifieker kon identificeren dan de IGC. Dat betekent echter niet dat deze identificaties correct zijn. • Die correctheid wordt echter wel sterk gesteund door de hoeveelheid groen, zeker relatief ten opzichte van het rode en orange in de figuur. Dit betekent dat, als de IGC en Unipept beide identificaties gemaakt hebben, die identificaties bijna altijd overeen komen. • Het donkergrijs wijst op een vrij groot aantal eiwitten dat de IGC op phylum-rang weet te identificeren, en waar Unipept slechts een superkingdom of zelfs geen identificatie kan aan geven.


45

Figuur 4.2: Verschillen in identificaties van de eiwitten tussen de IGC en Unipept. Per taxonomische rang worden het aantal eiwitten afgebeeld die op die rang ge¨ıdentificeerd worden door Unipept. De verdeling van kleuren per rang gebeurt volgens de kleurcode in Figuur 4.3.

Figuur 4.3: Kleurcodes gebruikt in Figuur 4.2. Oranje bijvoorbeeld betekent dat de IGC en Unipept beide een phylum en genus ge¨ıdentificeerd hebben voor een zeker eiwit, maar het oneens zijn over het genus.

Hoofdstuk 5

Toekomstig werk Ondanks een academiejaar aan werk is een thesis als deze nooit helemaal af. Dit hoofdstuk somt op welke features en correcties nog hadden kunnen gebeuren.

5.1

De databank

De databank die momenteel gebruikt wordt door Unipept is intussen wat verouderd. De namen van de tabellen die initieel goed waren, passen niet altijd meer perfect bij wat de tabel precies bevat. Zo zou de uniprot entries tabel beter de proteins tabel genoemd worden. Op deze manier kunnen er ook eiwitten van andere bronnen in opgeslagen worden. Het type veld, dat nu ofwel “trembl” ofwel “swissprot” is, zou dan hernoemd kunnen worden naar source en aanduiden uit welke bron het eiwit afkomstig is. Misschien is het ook mogelijk om de verschillende tabellen met Cross References samen te voegen tot één enkele tabel, en geen afzonderlijke tabel per soort referentie te nemen. Al deze veranderingen zouden echter ook veel aanpassingen in de broncode van de webapplicatie vereisen. Dit maakt het te veel moeite en werk om door te voeren zonder eerst alle andere mogelijke veranderingen te overwegen, zodat dit proces niet herhaald zal moeten worden.

5.2

Assemblages

Zoals reeds vermeld in subsectie 2.3.3, het deel over de makefile, zijn de assemblages nog niet helemaal correct. Meer bepaald worden nog niet alle sequenties gebruikt in een assemblage met die assemblage gelinkt in de assembly sequences tabel. Er werd al een script geschreven 46

HOOFDSTUK 5. TOEKOMSTIG WERK

47

in Python om dit gebrek te corrigeren, maar dit script is nog onbruikbaar traag. Dit script zou nog versneld moeten worden door, in plaats van de web services van het NCBI aan te spreken, bijvoorbeeld rechtstreeks te werken op lokale (gedownloade) tabellen. Andere oplossingen zouden kunnen zijn om in nog grotere batches de API van het NCBI aan te spreken.

5.3

Publicatie Docker container

De Docker containers, omschreven in Hoofdstuk 3, moeten nog gepubliceerd worden. Voor dit gebeurt, moet echter nog wat werk verricht worden aan de containers. Zo moet er nog een server komen die de databank aanbiedt in de vorm van tab separated values bestanden. Deze kunnen dan gedownload worden bij het opstarten van de container, zodat de lokale databank gevuld kan worden. Het zou ook handig zijn indien de databank container een optie zou krijgen om, in plaats van de complete databank te downloaden van Unipept, de databank zelf op te stellen van de brondata. Dit zou de gebruiker de kans bieden om zelf bronnen toe te voegen aan de databank.

5.4

K-meren

Een k-mer is een DNA-sequentie van lengte k. Veel bestaande tools omtrent DNA-analyse werken met k-meren. Het zou interessant zijn om ook peptiden van lengte k te beschouwen, in plaats van de tryptische peptiden in Unipept. De overlappende aard van k-meren staat toe deze efficiënt op te slaan [9] en te indexeren. Door te werken met k-meren, kunnen kleine afwijkingen in eiwitsequenties deels opgevangen worden. Analyses op basis van tryptische peptiden kunnen enkel omgaan met exacte matches.

Appendix A

Databankstructuur Deze appendix bevat een gedetailleerde omschrijving van de Unipept Databank. In 2.1 staat een meer beknopte en minder technische omschrijving van de diverse tabellen. Per tabel wordt hier een grondige omschrijving van elke kolom gegeven.

A.1

Taxons

Deze tabel bevat de taxonomie die door Unipept gebruikt wordt in zijn berekeningen. Een taxonomie neemt de vorm aan van een boom. Deze wordt in de tabel opgeslagen als een lijst van toppen, telkens met een parent pointer. id (unsigned integer) Het ID van dit taxon zoals toegekend door National Center for Biotechnology Information (NCBI). Omdat NCBI soms taxa verwijdert uit zijn databank, ontbreken sommige ID’s in deze lijst. name (string) De naam toegekend aan dit taxon. rank (enumerator) De rang toegekend aan dit taxon weer. De rang is ofwel no rank voor waarden dit zich tussen de benoemde rangen in bevinden, ofwel één van: superkingdom, kingdom, subkingdom, superphylum, phylum, subphylum, superclass, class, subclass, infraclass, superorder, order, suborder, infraorder, parvorder, superfamily, family, subfamily, tribe, subtribe, genus, subgenus, species group, species subgroup, species, subspecies, varietas of forma. parent (unsigned integer) Het ID van het taxon waaronder dit taxon rechtstreeks valt. In het geval van de wortel van de taxonomische boom is dit de wortel zelf. valid (boolean) Duidt op de geldigheid van dit taxon. Taxa waarbij deze booleaanse waarde op “onwaar” staat, worden niet gebruikt bij sommige berekeningen. 48

APPENDIX A. DATABANKSTRUCTUUR

A.2

49

Lineages

id (unsigned integer) Een ID door Unipept toegekend aan deze afstamming. Dit ID is niet consistent over updates van de databank heen. Aangezien deze echter enkel intern gebruikt worden, geeft dat geen probleem. Ditzelfde geldt voor de andere door Unipept toegekende ID’s. taxon id (unsigned integer) Het taxon waar dit de afstamming van is. Vervolgens komt nog één kolom per taxonomische rang, genoemd in volgorde bij de beschrijving van de rank kolom van de taxons tabel. Het type van deze kolommen is signed integer, en ze verwijzen naar rijen in de taxons tabel. De codering voor rang A is als volgt: • Als dit taxon een voorouder heeft met rang A, en deze voorouder is gemarkeerd als “geldig”, dan is de waarde gelijk aan het ID van die voorouder. • Als dit taxon een voorouder heeft met rang A en deze voorouder is gemarkeerd als “ongeldig”, dan is de waarde gelijk aan de negatie van het ID van die voorouder. • Als dit taxon geen voorouder heeft van rang A maar wel een voorouder (zichzelf inclusief) van lagere rang (verder van de wortel), dan is de waarde \N (null) of −1, respectievelijk als die lagere voorouder als “geldig” of “ongeldig” gemarkeerd is. • In alle andere gevallen zal de waarde \N (null) zijn.

A.3

Sequences

id (unsigned int) Een ID door Unipept toegekend. sequence id (string) Een tryptische peptide, opgeslagen in een string van maximaal lengte 50. lca il (unsigned int) Het ID van een taxon uit de taxons tabel, meer specifiek de LCA van alle broneiwitten waarin dit tryptisch peptide, of een variant waarbij de aminozuren I en L uitgewisseld zijn, teruggevonden werd. lca (unsigned int) Tevens een ID uit de taxons tabel, ditmaal de LCA berekend zonder I en L gelijk te stellen.

A.4

UniProt Entries

id (unsigned int) Een ID door Unipept toegekend.


50

uniprot accession number (string) Een uniek ID toegekend aan dit eiwit door UniProt. Merk op dat dit geen getal is. version (unsigned int) De versie van dit eiwit in UniProt. taxon id (unsigned int) Het ID van het taxon in de taxons tabel waar dit eiwit in teruggevonden wordt. type (enumerator) De bron van dit eiwit. Voorlopig een enumerator die enkel de waarden “swissprot” en “trembl” kan aannemen. protein (text) Het eiwit zelf.

A.5

Peptides

id (unsigned int) Een ID door Unipept toegekend. sequence id (unsigned int) Het ID van dezelfde sequentie, maar waarbij I en L gelijkgesteld worden. original sequence id (unsigned int) Het ID van een rij in de sequences tabel. uniprot entry id (unsigned int) Het ID van een broneiwit waar de eerder vernoemde sequentie in teruggevonden werd. position (unsigned int) De plaats in het broneiwit waar de sequentie zich bevindt.

A.6

Cross References

De Unipept databank bevat 4 tabellen gevuld met referenties naar andere databanken. Deze hebben een gelijkaardige structuur, hieronder gelijktijdig beschreven. Deze structuur betreft de tabellen: • ec cross references • embl cross references • go cross references • refseq cross references id (unsigned int) Een ID door Unipept toegekend. uniprot entry id (unsigned int) Het ID van een rij in de uniprot entries tabel die we willen linken aan een externe databank.


51

protein id (string) Het ID van het UniProt eiwit in de protein-tabel van de EMBL/RefSeq databank. Deze kolom wordt enkel gebruikt in de EMBL en RefSeq cross references tabellen. sequence id (string) Het ID van het UniProt eiwit in de sequentie-tabel van de EMBL/RefSeq databank. Deze kolom wordt enkel gebruikt in de EMBL en RefSeq cross references tabellen. go id (string) Het ID van het UniProt eiwit in de Gene Ontology. Komt enkel voor in de go cross references tabel. ec id (string) Het Enzyme Commission number horende bij het UniProt eiwit. Komt enkel voor in de ec cross references tabel.

A.7

Assemblies

id (unsigned int) Een ID door Unipept toegekend. genbank assembly accession (string) Het GenBank ID van het assembly in deze rij. refseq assembly accession (string) Het RefSeq ID van het assembly in deze rij. taxon id (unsigned int) Het ID van het taxon waaraan deze assemblage aan toegewezen wordt. genome representation (enumerator) Duidt op de volledigheid van het genoom waarvan dit een assemblage is. Ofwel “full” ofwel “partial”. assembly level (enumerator) Het level van dit assemblage. Eén van “Chromosome”, “Chromosome with gaps”, “Complete Genome”, “Contig”, “Gapless Chromosome” en “Scaffold”. assembly name (string) De gegeven naam van deze assemblage. organism name (string) De gegeven naam van het organisme waaruit deze assemblage samengesteld werd. biosample id (string) Het ID binnen het NCBI van het biosample waaruit de eiwitten van deze assemblage gewonnen werden. type strain (boolean) Geeft aan of dit genoom gesequeneerd werd van typemateriaal. Bij de officiële beschrijving van een soort moet één fysiek specimen van de soort aangeduid worden als het typemateriaal dat dient als referentie voor deze soort [5]. Voor planten en dieren moet het (dode) typemateriaal beschikbaar gesteld worden in musea. Voor bacteriën worden levende stammen bewaard in zogenaamde cultuurcollecties.


A.8

52

Assembly Sequences

id (unsigned int) Een ID door Unipept toegekend. assembly id (unsigned int) Het ID van de assemblage in de assemblies tabel waarin deze sequentie gebruikt wordt. genbank accession number (string) Het GenBank Accession number van de sequentie die tot de assemblage behoort.

Bibliografie [1] Docker. https://www.docker.com/. [2] Stephen F Altschul, Warren Gish, Webb Miller, Eugene W Myers, and David J Lipman. Basic local alignment search tool. Journal of molecular biology, 215(3):403–410, 1990. [3] Gene Ontology Consortium et al. Gene ontology consortium: going forward. Nucleic Acids Research, 43(D1):D1049–D1056, 2015. [4] Scott Federhen. The ncbi taxonomy database. Nucleic acids research, 40(D1):D136– D143, 2012. [5] Scott Federhen. Type material in the ncbi taxonomy database. Nucleic acids research, page gku1127, 2014. [6] Carola Kanz, Philippe Aldebert, Nicola Althorpe, Wendy Baker, Alastair Baldwin, Kirsty Bates, Paul Browne, Alexandra van den Broek, Matias Castro, Guy Cochrane, et al. The embl nucleotide sequence database. Nucleic Acids Research, 33(suppl 1):D29–D33, 2005. [7] Junhua Li, Huijue Jia, Xianghang Cai, Huanzi Zhong, Qiang Feng, Shinichi Sunagawa, Manimozhiyan Arumugam, Jens Roat Kultima, Edi Prifti, Trine Nielsen, et al. An integrated catalog of reference genes in the human gut microbiome. Nature biotechnology, 32(8):834–841, 2014. [8] Michele Magrane, UniProt Consortium, et al. Uniprot knowledgebase: a hub of integrated protein data. Database, 2011:bar009, 2011. [9] Guillaume Mar¸cais and Carl Kingsford. A fast, lock-free approach for efficient parallel counting of occurrences of k-mers. Bioinformatics, 27(6):764–770, 2011. [10] Bart Mesuere, Griet Debyser, Maarten Aerts, Bart Devreese, Peter Vandamme, and Peter Dawyndt. The unipept metaproteomics analysis pipeline. Proteomics, 15:1437– 1442, 2015.

53

BIBLIOGRAFIE

54

[11] Bart Mesuere, Bart Devreese, Griet Debyser, Maarten Aerts, Peter Vandamme, and Peter Dawyndt. Unipept: tryptic peptide-based biodiversity analysis of metaproteome samples. Journal of proteome research, 11(12):5773–5780, 2012. [12] Tom Naessens. Van metagenoom naar metaproteoom. 5 2015. [13] Berkeley DB Oracle. Java edition. [14] Kim D Pruitt, Tatiana Tatusova, and Donna R Maglott. Ncbi reference sequence (refseq): a curated non-redundant sequence database of genomes, transcripts and proteins. Nucleic acids research, 33(suppl 1):D501–D504, 2005. [15] E Sayers. Entrez programming utilities help. URL http://www. ncbi. nlm. nih. gov/books/NBK25499, 2009. [16] Nathan C Verberkmoes, Alison L Russell, Manesh Shah, Adam Godzik, Magnus Rosenquist, Jonas Halfvarson, Mark G Lefsrud, Juha Apajalahti, Curt Tysk, Robert L Hettich, et al. Shotgun metaproteomics of the human distal gut microbiota. The ISME journal, 3(2):179–189, 2009. [17] Edwin C Webb et al. Enzyme nomenclature 1992. Recommendations of the Nomenclature Committee of the International Union of Biochemistry and Molecular Biology on the Nomenclature and Classification of Enzymes. Number Ed. 6. Academic Press, 1992.

Optimaliseren van de Unipept Shotgun Metaproteomics Analysis Pipeline. Felix Van der Jeugt

Recommend Documents