| Name: | Description: | Size: | Format: | |
|---|---|---|---|---|
| 716.87 KB | Adobe PDF |
Authors
Advisor(s)
Abstract(s)
Em Bioinformática são frequentes problemas cujo tratamento necessita de considerável poder de processamento/cálculo e/ou grande capacidade de armazenamento de dados e elevada largura de banda no acesso aos mesmos (de forma não comprometer a eficiência do seu processamento). Um exemplo deste tipo de problemas é a busca de regiões de similaridade em sequências de amino-ácidos de proteínas, ou em sequências de nucleótidos de DNA, por comparação com uma dada sequência fornecida (query sequence). Neste âmbito, a ferramenta computacional porventura mais conhecida e usada é o BLAST (Basic Local Alignment Search Tool) [1]. Donde, qualquer incremento no desempenho desta ferramenta tem impacto considerável (desde logo positivo) na atividade de quem a utiliza regularmente (seja para investigação, seja para fins comerciais). Precisamente, desde que o BLAST foi inicialmente introduzido, foram surgindo
diversas versões, com desempenho melhorado, nomeadamente através da aplicação
de técnicas de paralelização às várias fases do algoritmo (e. g., partição e distribuição
das bases de dados a pesquisar, segmentação das queries, etc. ), capazes de tirar
partido de diferentes ambientes computacionais de execução paralela, como:
máquinas multi-core (BLAST+ 2), clusters de nós multi-core (mpiBLAST3J e, mais
recentemente, co-processadores aceleradores como GPUs" ou FPGAs. É também
possível usar as ferramentas da família BLAST através de um interface/sítio WEB5,
que permite, de forma expedita, a pesquisa de uma variedade de bases de dados
conhecidas (e em permanente atualização), com tempos de resposta suficientemente
pequenos para a maioria dos utilizadores, graças aos recursos computacionais de
elevado desempenho que sustentam o seu backend. Ainda assim, esta forma de
utilização do BLAST poderá não ser a melhor opção em algumas situações, como por
exemplo quando as bases de dados a pesquisar ainda não são de domínio público,
ou, sendo-o, não estão disponíveis no referido sitio WEB. Adicionalmente, a utilização
do referido sitio como ferramenta de trabalho regular pressupõe a sua disponibilidade
permanente (dependente de terceiros) e uma largura de banda de qualidade
suficiente, do lado do cliente, para uma interacção eficiente com o mesmo. Por estas
razões, poderá ter interesse (ou ser mesmo necessário) implantar uma infra-estrutura
BLAST local, capaz de albergar as bases de dados pertinentes e de suportar a sua
pesquisa da forma mais eficiente possível, tudo isto levando em conta eventuais
constrangimentos financeiros que limitam o tipo de hardware usado na implementação
dessa infra-estrutura. Neste contexto, foi realizado um estudo comparativo de diversas versões do
BLAST, numa infra-estrutura de computação paralela do IPB, baseada em
componentes commodity: um cluster de 8 nós (virtuais, sob VMWare ESXi) de
computação (com CPU Í7-4790K 4GHz, 32GB RAM e 128GB SSD) e um nó dotado de
uma GPU (CPU Í7-2600 3.8GHz, 32GB RAM, 128 GB SSD, 1 TB HD, NVIDIA GTX
580). Assim, o foco principal incidiu na avaliação do desempenho do BLAST original e
do mpiBLAST, dado que são fornecidos de base na distribuição Linux em que assenta o cluster [6]. Complementarmente, avaliou-se também o BLAST+ e o gpuBLAST no nó
dotado de GPU. A avaliação contemplou diversas configurações de recursos, incluindo
diferentes números de nós utilizados e diferentes plataformas de armazenamento das
bases de dados (HD, SSD, NFS). As bases de dados pesquisadas correspondem a
um subconjunto representativo das disponíveis no sitio WEB do BLAST, cobrindo uma
variedade de dimensões (desde algumas dezenas de MBytes, até à centena de
GBytes) e contendo quer sequências de amino-ácidos (env_nr e nr), quer de
nucleótidos (drosohp. nt, env_nt, mito. nt, nt e patnt). Para as pesquisas foram 'usadas
sequências arbitrárias de 568 letras em formato FASTA, e adoptadas as opções por
omissão dos vários aplicativos BLAST. Salvo menção em contrário, os tempos de
execução considerados nas comparações e no cálculo de speedups são relativos à
primeira execução de uma pesquisa, não sendo assim beneficiados por qualquer
efeito de cache; esta opção assume um cenário real em que não é habitual que uma
mesma query seja executada várias vezes seguidas (embora possa ser re-executada,
mais tarde).
As principais conclusões do estudo comparativo realizado foram as seguintes:
- e necessário acautelar, à priori, recursos de armazenamento com capacidade
suficiente para albergar as bases de dados nas suas várias versões
(originais/compactadas, descompactadas e formatadas); no nosso cenário de teste a
coexistência de todas estas versões consumiu 600GBytes;
- o tempo de preparação (formataçâo) das bases de dados para posterior pesquisa
pode ser considerável; no nosso cenário experimental, a formatação das bases de
dados mais pesadas (nr, env_nt e nt) demorou entre 30m a 40m (para o BLAST), e
entre 45m a 55m (para o mpiBLAST);
- embora economicamente mais onerosos, a utilização de discos de estado sólido, em
alternativa a discos rígidos tradicionais, permite melhorar o tempo da formatação das
bases de dados; no entanto, os benefícios registados (à volta de 9%) ficam bastante
aquém do inicialmente esperado;
- o tempo de execução do BLAST é fortemente penalizado quando as bases de dados
são acedidas através da rede, via NFS; neste caso, nem sequer compensa usar vários
cores; quando as bases de dados são locais e estão em SSD, o tempo de execução
melhora bastante, em especial com a utilização de vários cores; neste caso, com 4
cores, o speedup chega a atingir 3.5 (sendo o ideal 4) para a pesquisa de BDs de
proteínas, mas não passa de 1.8 para a pesquisa de BDs de nucleótidos;
- o tempo de execução do mpiBLAST é muito prejudicado quando os fragmentos das
bases de dados ainda não se encontram nos nós do cluster, tendo que ser distribuídos
previamente à pesquisa propriamente dita; após a distribuição, a repetição das
mesmas queries beneficia de speedups de 14 a 70; porém, como a mesma base de
dados poderá ser usada para responder a diferentes queries, então não é necessário
repetir a mesma query para amortizar o esforço de distribuição;
- no cenário de teste, a utilização do mpiBLAST com 32+2 cores, face ao BLAST com
4 cores, traduz-se em speedups que, conforme a base de dados pesquisada (e
previamente distribuída), variam entre 2 a 5, valores aquém do máximo teórico de 6.5
(34/4), mas ainda assim demonstradores de que, havendo essa possibilidade,
compensa realizar as pesquisas em cluster; explorar vários cores) e com o gpuBLAST, realizada no nó com GPU (representativo
de uma workstation típica), permite aferir qual a melhor opção no caso de não serem
possíveis pesquisas em cluster; as observações realizadas indicam que não há
diferenças significativas entre o BLAST e o BLAST+; adicionalmente, o desempenho
do gpuBLAST foi sempre pior (aproximadmente em 50%) que o do BLAST e BLAST+,
o que pode encontrar explicação na longevidade do modelo da GPU usada;
- finalmente, a comparação da melhor opção no nosso cenário de teste, representada
pelo uso do mpiBLAST, com o recurso a pesquisa online, no site do BLAST5, revela
que o mpiBLAST apresenta um desempenho bastante competitivo com o BLAST
online, chegando a ser claramente superior se se considerarem os tempos do
mpiBLAST tirando partido de efeitos de cache; esta assunção acaba por se justa, Já
que BLAST online também rentabiliza o mesmo tipo de efeitos; no entanto, com
tempos de pequisa tão reduzidos (< 30s), só é defensável a utilização do mpiBLAST
numa infra-estrutura local se o objetivo for a pesquisa de Bds não pesquisáveis via
BLAS+ online.
Description
Keywords
BLAST, mpiBLAST Avaliação de desempenho
Citation
Rufino, Jose (2015) Desempenho Comparativo do BLAST e do mpiBLAST". In VI Workshop em Bioinformática. Escola Superior Agrária de Bragança.
Publisher
Escola Superior Agrária de Bragança