D-Bioflow: Uma Abordagem para Distribuição de Dados em ... · D-Bioflow: Uma Abordagem para Distribuição de Dados em Workflows de Bioinformática José Guilherme Monteiro de Menezes1,

D-Bioflow: Uma Abordagem para Distribuição de Dados

em Workflows de Bioinformática

José Guilherme Monteiro de Menezes1, Fernanda Araujo Baião2,

Maria Cláudia Cavalcanti1

1Instituto Militar de Engenharia (IME)

Pça General Tibúrcio, 80 Urca– 22.290-270 – Rio de Janeiro – RJ – Brasil

2Departamento de Informática Aplicada – UNIRIO

Av. Pasteur, 458 Urca Rio de Janeiro – RJ – Brasil.

[email protected]�[email protected]�[email protected]

Abstract. Collaboration and technological resources exploration has greatly

improved in scientific environments, due to the availability of a great number

of computing services in the internet. However, this distributed scenario

typically requires intensive data transfer between internet servers, which

impacts the execution time of scientific workflows. This paper proposes an

approach for managing distributed data in bioinformatics workflows, in order

to improve the performance of workflow re-executions through data transfer

reduction. The paper presents the proposed architecture, its implementation

and the results of a set of simulations showing the benefits of our approach.

Resumo. A disponibilização de serviços permitiu o aumento do nível de

colaboração e de aproveitamento de recursos tecnológicos no meio científico,

distribuindo o processamento em diversos sítios do mundo. No entanto, o

transporte de um grande volume de dados entre os sítios de processamento

ainda representa um grande impacto no tempo de execução de um workflow

científico. Esse artigo propõe uma abordagem para gerência de dados

distribuídos em workflows de bioinformática, visando melhorar o desempenho

das re-execuções dos workflows através da redução do volume de dados

transportados entre os sítios. O artigo apresenta a arquitetura proposta, o

protótipo desenvolvido e os resultados de simulações que validam a

abordagem.

1. Introdução

Na área científica, há uma crescente oferta de programas de simulação, transformação e

análise de dados, mais conhecidos como programas científicos [Silva, 2006]. O

desenvolvimento destes programas científicos fomentou a criação de um novo tipo de

experimento científico, denominado experimento in silico, que é definido como um

experimento científico realizado utilizando apoio computacional intensivo [Cavalcanti

et al, 2005]. Tipicamente, os experimentos in silico são definidos e executados

utilizando-se a abordagem de workflows. Segundo [Aalst e Hee, 2002], um workflow é

XXIII Simpósio Brasileiro de Banco de Dados

180


180

definido como uma coleção de tarefas organizadas para a realização de um processo,

onde uma tarefa denota um conjunto de softwares que implementam atividades

específicas. Nos workflows de experimentos in silico, as tarefas correspondem aos

programas científicos.

Em ambientes científicos, no entanto, a gerência de workflows apresenta

características especiais. A existência de múltiplas combinações possíveis de programas

e dados dificulta a definição dos workflows. Um mesmo workflow científico costuma

ser executado múltiplas vezes, com parametrizações diferentes, devendo todas as

execuções serem documentadas, mesmo quando os resultados não são satisfatórios.

Muitas vezes, estas execuções são na verdade, re-execuções totais ou parciais de um

mesmo workflow. Além disso, todos os resultados devem ser armazenados, mesmo os

não satisfatórios. Os metadados referentes às execuções também devem ser registrados

(quem executou e quando, que parâmetros foram utilizados, quais os resultados

intermediários gerados, qual a seqüência de programas executados). Assim, o volume de

dados manipulados pelos programas científicos pode ser muito grande.

Outra característica dos workflows científicos é o alto custo de processamento.

A execução de um programa científico pode ser muito custosa. Em alguns casos, uma

execução pode levar dias e consumir muitos recursos em termos de processamento e de

espaço em disco para armazenamento dos dados resultantes. Por isso, os cientistas

procuram evitar a repetição de tarefas desnecessariamente, realizando re-execuções

parciais de um workflow sempre que possível. Por fim, os programas que constituem as

tarefas de um workflow científico, em geral, não foram concebidos para funcionar de

forma encadeada pois foram desenvolvidos para sistemas operacionais específicos e/ou

usam formatos pré-definidos para os dados de entrada e de saída. Isto acarreta em

problemas de integração entre as tarefas. Assim sendo, um sistema de gerência de

workflows científicos precisa prover mecanismos para atender a tais necessidades.

Recentemente, diversos programas científicos foram disponibilizados na forma

de serviços Web [Web Services, 2008]. Assim, os workflows científicos passaram a ser

construídos a partir de uma coleção de tarefas mapeadas em serviços Web locais ou

remotos. A execução remota das tarefas que compõem um workflow, em conjunto com

a existência de servidores de armazenamento disponíveis na Internet (Storage Area

Networks [Ozsu e Valduriez, 2001]), tornou possível o armazenamento remoto dos

dados intermediários e finais de um workflow. Neste cenário de execução distribuída de

workflows científicos, é necessário que exista uma política estabelecida para o

armazenamento e recuperação dos dados que trafegam entre as tarefas de um workflow,

uma vez que a estratégia de armazenamento pode interferir, significativamente, no

desempenho da (re)execução de um workflow.

Num paradigma de armazenamento centralizado de dados (onde todos os dados

intermediários da execução dos workflows estejam sendo armazenados em um único

servidor de dados), os serviços Web podem estar hospedados em sítios de difícil acesso

por parte do gerente central de execução, acarretando problemas para transferência de

dados. Mesmo num ambiente de gerência distribuída de dados, um possível hiato entre

os sítios de armazenamento e os sítios de processamento pode trazer as mesmas

conseqüências da alternativa centralizada, já que o custo de transferência de dados entre


181


181

os nós de um ambiente distribuído é responsável pela maior parte do custo do

processamento de consultas [Ozsu e Valduriez, 2001] [Ruberg, Baião e Mattoso, 2002].

Considerando as abordagens propostas na literatura para a gerência de

workflows científicos, como por exemplo o Kepler [Keler, 2008], o Taverna [Taverna,

2008], o InServices [Silva, 2006] e o Vistrails [Vistrails, 2008], nenhuma delas foi

desenvolvida com foco no armazenamento distribuído de dados intermediários. Torna-

se necessário, portanto, que se estabeleça uma política adequada para armazenamento

distribuído dos dados durante a execução de workflows científicos.

Este trabalho propõe uma abordagem para gerência de dados distribuídos em

workflows de bioinformática, visando reduzir o tempo de execução dos workflows via

redução do custo envolvido na transferência dos dados.

O trabalho encontra-se organizado como descrito a seguir. Na seção seguinte

apresenta-se a motivação, incluindo a definição de alguns conceitos básicos necessários

ao entendimento do trabalho. A seção 3 descreve a arquitetura proposta juntamente com

a especificação do metamodelo e do modelo de custo utilizado. A seguir, na seção 4,

apresenta-se o protótipo desenvolvido com base na arquitetura proposta. A seção 5

relata a simulação realizada para avaliar os ganhos da proposta. Por fim, a seção 6

apresenta os trabalhos correlatos e a seção 7 conclui o artigo apontando algumas

direções no sentido de trabalhos futuros.

2. Abordagens para Gerência de Dados em Workflows Científicos

Os workflows possuem, tradicionalmente, duas etapas conhecidas como: definição e

execução. A etapa de definição consiste na fase de construção do workflow com a

definição da seqüência de tarefas, fluxos de dados e tipos dos resultados. Na etapa de

execução as tarefas são invocadas, produzindo resultados intermediários que serão

utilizados, por completo ou em parte, pela tarefa seguinte até a obtenção do resultado

final. Junto à execução, é desejável a disponibilidade de um módulo de monitoração,

para o acompanhamento da execução das tarefas.

Devido às suas especificidades, a comunidade científica demandou o

desenvolvimento de uma nova categoria de workflows, denominada workflows

científicos. Dentre as oportunidades de melhorias da etapa de execução, pode-se

destacar a área de armazenamento e recuperação dos dados. Deve-se analisar as

possibilidades de persistência e recuperação dos dados de forma centralizada ou

distribuída.

O armazenamento centralizado - onde os dados produzidos pelas tarefas são

persistidos num único servidor - pode impactar negativamente a execução do workflow

visto que o dado trafega repetidas vezes, para o servidor de armazenamento e deste para

a tarefa destino. No armazenamento distribuído, o dado gerado por cada tarefa do

workflow pode ser armazenado em qualquer sítio do sistema, com disponibilidade de

armazenamento. Deseja-se reduzir a demanda de comunicação entre os sítios envolvidos

na execução dos workflows, entretanto a decisão pela melhor estratégia de

armazenamento não é tão simples, em função de restrições do ambiente, como

limitações no espaço de armazenamento, políticas de administração dos nós remotos, e

autorização de acesso entre nós. Além disso, a escolha do servidor para armazenamento


182


182

de um dado intermediário deve levar em conta, tanto quanto possível, a probabilidade de

reuso do dado em futuras execuções de workflows no ambiente..

Técnicas de distribuição de dados têm sido empregadas com sucesso no

incremento de desempenho de aplicações que manipulam grandes volumes de dados

[Wildenberg, 2003], [Baião, Mattoso e Zaverucha, 1998], ajustando o armazenamento

de acordo com a necessidade de processamento. Entretanto, o domínio dos bancos de

dados distribuídos não trata, adequadamente, questões como: encadeamento de

execuções, interdependências entre dados e tarefas e o tratamento de dados

intermediários do processamento.

3. Gerenciando a Distribuição de Dados nos Workflows de Bionformática

Neste trabalho, propõe-se uma abordagem cuja arquitetura dê suporte à gerência de

dados intermediários distribuídos, interagindo com os principais sistemas de gerência de

workflows existentes. A abordagem proposta pressupõe a segregação dos workflows em

abstratos e executáveis. Os workflows abstratos possuem apenas a organização lógica

das tarefas, sem a definição dos servidores que as executarão. Os workflows

executáveis são definidos a partir dos workflows abstratos, e possuem todas as

instruções necessárias para dar suporte à execução distribuída, e no contexto deste

trabalho, para dar suporte à gerência de dados distribuídos. A arquitetura proposta para é

ilustrada na figura 1 e descrita em mais detalhes a seguir.

Figura 1. Arquitetura D-Bioflow

3.1. Arquitetura D-Bioflow

A arquitetura lógica do D-BioFlow prevê a existência de um módulo central,

denominado Gerente de Workflow. Fisicamente, este módulo é instanciado em um dos

sítios do ambiente, denominado sítio central. O Gerente de Workflow é constituído por

quatro módulos: Serviço de BD, Definição, Pré-Execução e Execução. Os módulos de

definição e execução estão normalmente presentes na arquitetura de sistemas de

gerência de workflows (SGWFs), e permitem que os usuários possam descrever seus

workflows e mais tarde executá-los. Na abordagem proposta, foi acrescentado um


183


183

módulo de Serviço de Banco Dados, um módulo de Pré-Execução, e um Repositório

Central de Dados. O módulo de Serviços de Banco de Dados é responsável por

coletar e prover informações para permitir que o módulo de Pré-Execução realize a

redefinição dos workflows abstratos, transformando-os em workflows executáveis

capazes de tratar o armazenamento dos dados intermediários. Por fim, o Repositório

Central mantém informações úteis para o Gerente de Workflows de modo geral, mas

em especial este repositório inclui metadados que descrevem os workflows abstratos e

executáveis, e os servidores que hospedam os serviços que implementam as tarefas e/ou

que estão disponíveis para armazenamento de dados. O esquema que especifica estes

metadados está descrito no metamodelo da figura 2.

A arquitetura do D-BioFlow prevê também que em cada sítio estejam

instanciados três módulos, além dos serviços lá hospedados: SA, Serviço de Workflow e

um gerente local de BD. O módulo SA (Serviço de Administração) provê informações

administrativas - como disponibilidade do servidor, espaço disponível,

permissionamento de leitura e escrita de arquivos, etc.- ao Gerente de Workflow. O

módulo BD (Gerente Local de BD), é responsável pela persistência e recuperação local

da informação, quando o sítio em questão for de armazenamento. O Serviço de

Workflow realiza as interações necessárias entre o Gerente de Workflow, os serviços

hospedados no sítio, o módulo de BD do sítio e demais sítios de processamento.

3.2. Metamodelo

O metamodelo da Figura 2 prevê as informações necessárias para descrever todo

o ambiente para o módulo Gerente do Workflow, incluindo os workflows abstratos e

suas tarefas, os tipos de dados de entrada e saída de cada tarefa, os serviços que

implementam cada tarefa, os workflows executáveis, os servidores que hospedam cada

serviço e que armazenam os dados intermediários, entre outras informações como

descrito a seguir. O metamodelo inclui classes que representam informações que devem

estar armazenadas nos sítios remotos, tais como as classes AreaArmazenamento,

DataContainer e Dado, que serão detalhadas a seguir.

A classe Workflow representa os workflows abstratos, enquanto a classe

InstanciaWorkflow representa os workflows executáveis. Os workflows abstratos e

executáveis estão relacionados a uma classe Usuário que representa o cientista (que

registra e executa os workflows o ambiente) ou administrador, usuários do sistema (que

registram workflows abstratos e realizam execuções dos workflows). A classe Workflow

tem um auto-relacionamento que indica a derivação de workflows, isto é, quando um

workflow é derivado de outro por alguma modificação na composição de tarefas. A

classe Tarefa representa os algoritmos que podem ser escolhidos para a construção dos

workflows abstratos. A classe Tarefa relaciona-se com a classe TipoDado, que por sua

vez relaciona-se com a classe Dado; estas classes mapeiam os tipos de dados utilizados

nos parâmetros de entrada e saída utilizados pelos algoritmos. A classe Tarefa,

relaciona-se também com uma classe Serviço, que por sua vez está relacionada a uma

classe Servidor. Estas classes modelam os sítios remotos, onde podem estar hospedados

vários serviços Web (classe Serviço), Uma Tarefa pode possuir vários serviços Web

que a implementam. Um mesmo serviço Web pode estar hospedado em vários sítios de

processamento (classe Servidor). A classe Servidor possui o atributo tipo para

identificar se uma instância de servidor é do tipo processamento (que hospeda somente


184


184

serviços), armazenamento (que hospeda somente dados) ou ambos. Um workflow

executável (instância da classe InstanciaWorkflow) representa um workflow que pode

ser executado. Note que um workflow executável pode representar um workflow que

acabou de passar pela redefinição (processo de pré-execução) mas que ainda não

iniciou a sua execução, um workflow que esteja sendo executado ou, ainda, um

workflow que tenha sua execução concluída.

Figura 2: Metamodelo do Repositório Central de Dados da D-BioFlow

Os workflows executáveis, modelados pela classe InstanciaWorkflow, ao serem

executados instanciarão os serviços Web que implementam as tarefas. Estas instâncias

de serviços Web são modeladas pela classe InstanciaTarefa. Num workflow, seja

abstrato ou executável, as tarefas ou instâncias de tarefa, devem seguir as regras de

encadeamento especificadas. Neste encadeamento, os dados produzidos por uma tarefa

são consumidos pela tarefa seguinte. Essa propriedade é modelada pelo relacionamento

entre as classes InstanciaTarefa e DadoTarefa. Como uma Tarefa pode receber mais de

um parâmetro de entrada, a classe OrdemParametro contém a ordem em que os

referidos dados são passados como parâmetro. Um workflow produz também um

resultado final, representado pela classe DadoWorkflow. As classes DadoWorkflow e


185


185

DadoTarefa são especializações da classe Dado, que modela todos os dados produzidos pelas execuções dos workflows. A classe AreaArmazenamento modela as possíveis áreas de armazenamento disponíveis nos sítios remotos. Quando uma instância da classe Servidor for do tipo armazenamento (ou do tipo processamento e armazenamento), a instância disporá de áreas de armazenamento para armazenar localmente os dados. A classe DataContainer modela o recurso de reserva prévia de espaço para o dado que ainda será produzido. Uma vez produzido o dado, a reserva prévia de espaço é excluída, liberando o recurso alocado para receber a informação definitiva. As instâncias de DataContainer possuem uma etiqueta de tempo para a expiração. Esse recurso garante que, por qualquer motivo o dado não seja produzido no limite de tempo estabelecido, a reserva prévia de espaço liberará o espaço alocado para outros processos.

3.3. Modelo de Custo

A distribuição dos dados intermediários de um workflow envolve um Problema de Alocação de Dados. No domínio de Sistemas de Bancos de Dados Distribuídos (SBDD), diversos aspectos são tradicionalmente considerados na definição de um projeto de alocação de dados [Ozsu e Valduriez, 2001]. Adicionalmente, no domínio de Workflows Distribuídos, pode-se acrescentar novos aspectos para apoiar a construção de um projeto de alocação para os dados intermediários dos workflows.

Essa seção apresenta um modelo de custo, que considera aspectos dos domínios de SBDD e de workflows distribuídos. Este modelo é usado para estimar o custo de execução de um workflow em um ambiente distribuído, de forma a orientar o projeto de alocação dos dados intermediários gerados por cada serviço durante a execução de um workflow, visando reduzir o tempo total de execução dos workflows através da redução dos custos de transferência de dados entre os serviços.

O modelo de custos proposto considera diversos parâmetros, agrupados em:

� Rede: Constitui o custo de transferência de uma unidade de dado entre os sítios da rede. É representado por uma matriz CTR, onde ctrij é o custo de transferir um dado do sítio si para o sítio sj. Para simplificar o problema, CTR é uma matriz simétrica onde ctrii é igual a 0.

� Armazenamento: Constitui o custo envolvido para armazenar o dado em um determinado sítio de armazenamento. É representado por um vetor CARM, onde CARM[i] representa o custo para se armazenar o dado no sítio i.

� Leitura: Custo envolvido na leitura do dado que esteja armazenado em um determinado sítio de armazenamento. É representado por um vetor CREC, onde CREC[i] representa o custo para se recuperar o dado que está armazenado no sítio i.

Considerando estes parâmetros, define-se uma função de custo a partir da qual pode-se estimar o custo para se armazenar um dado d nos sítios de armazenamento disponíveis. Considere um workflow constituído pelo conjunto encadeado de tarefas T ={t1, t2,t3,...,tm}, onde ti+1 representa a tarefa sucessora de ti, 0 < i < m-1. O ambiente de execução é constituído por um conjunto de servidores remotos S = {s1, s2, s3,...,sn}, onde cada si pode ser um servidor de processamento, armazenamento ou ambos. Cada servidor de processamento s, s ∈ S, hospeda um conjunto definido de serviços que


186


186

implementam um subconjunto das tarefas de T. Define-se a função Srv(t), que retorna

um conjunto S’ (S’⊆ S) de servidores remotos que hospedam os serviços que

implementam a tarefa t.

Considere K = {k1, k2, k3,..., ks}, o conjunto de todos os servidores de

armazenamento do ambiente com espaço disponível para armazenar o dado d. Para cada

tarefa ti ∈ T. A função de custos deve calcular os custos envolvidos para armazenar o

dado d no servidor ky, 1 � y � s e retornar ky que represente o custo mínimo. Assim, a

função de custos é definida conforme na equação I:

∀x ∈ S’, onde S’ = Srv(ti);

∀w ∈ W, onde W = Srv(ti+1);

Min(Ctr(x, ky ,d ) + Ctr( ky, w ,d )+ Carm( ky ,d)+ Crec(ky,d)) (I)

A função Ctr(si, si+1, d) representa o custo de transferência do dado d, em

pacotes de dados, do servidor si para o servidor si+1 é definida como:

Ctr(si, si+1, d) = ]][[_

1+× ii SSCTRDATAPCT

d

Onde:

PCT_DATA: Tamanho do pacote padrão de dados na rede.

As funções Carm(k,d) e Crec(k,d) representam os custos de armazenamento e

recuperação do dado d no servidor k. Desta forma, as funções Carm(k,d) e Crec(k,d) são

definidas como a seguir.

Carm(k,d) = ][_

kSCARMDATAPCT

d×

Crec(k,d) = ][_

kSCRECDATAPCT

d×

O modelo de custos apresentado nesse trabalho considera que o tempo total de

execução de um workflow é composto pela soma dos tempos de execução das tarefas

com o tempo necessário para transferir os dados entre as tarefas, considerando o custo

de persistência dos dados. Desta forma, o tempo de execução de um workflow pode ser

representado como uma função crescente.

A alocação de dados intermediários de um workflow pode ser encarada como

um projeto de alocação de dados. Neste caso, utilizando a função de custos definida na

função de custos I, será encontrado um plano de alocação de dados intermediários que

represente a melhor alternativa de armazenamento, conforme os critérios discutidos

anteriormente. Porém, num ambiente com grande número de servidores, o número de

possibilidades a serem analisadas, para escolha do plano de alocação de dados, pode ser

substancialmente grande. Segundo [Wildenberg, 2003] o problema de encontrar uma

alocação de dados ótima em um SBDD é NP-Difícil. Neste cenário, a função definida na

equação I analisará todas as combinações possíveis de servidores de processamento e

armazenamento, o que pode demandar um custo computacional inviável.


187


187

Em cenários complexos, uma alternativa para reduzir o custo computacional

envolvido na construção de planos de alocação de dados seria restringir o espaço de

busca. Essa alternativa levará a construção de planos de alocação de dados satisfatórios,

porém não ótimos, num tempo computacional viável. O espaço de busca pode ser

restringido através da inserção de heurísticas no modelo de custos utilizado.

No contexto deste trabalho, workflows de bioinformática, é característico a

repetição freqüente de combinações de tarefas, bem como a existência de workflows

derivados. Um workflow pode possuir vários níveis de derivação. Considere, por

exemplo, um workflow w1 composto pelo encadeamento das tarefas T1->T2->T3->T4.

Define-se um workflow w2 constituído pelo encadeamento de tarefas T1->T2->T3->T5-

>T6, derivado do workflow w1. Pode-se definir um workflow w3, constituído pelas

tarefas T1->T2->T3->T5->T6->T7, que é derivado de w2. Como o workflow w2 é

derivado de w1, então w3 também será derivado do workflow w1. Desta forma, uma

execução do workflow w3 pode aproveitar dados de execuções anteriores dos workflows

w1 e w2.

Assim, escolheu-se usar uma heurística que leva em conta a existência de

workflows derivados e, dentre os workflows derivados, a associação freqüente de pares

de tarefas. Pode-se ainda considerar a freqüência de execução dos workflows, induzindo

o modelo a aproximar os dados dos servidores que hospedam as prováveis tarefas

consumidoras. Essas alternativas podem levar a uma decisão ruim para a execução

corrente, mas objetiva-se obter significativa melhora global.

Assim, no modelo de custos proposto, passa-se a inserir a função Consumer(ti, n)

que retorna, quando houver, as n tarefas que foram definidas com maior freqüência

como consumidoras de ti, ordenadamente. A função de custos ficará então definida

como:

∀x ∈ S’, onde S’ = Srv(ti);

∀h ∈ H, onde H = Consumer(ti,n);

∀z ∈ Z, onde Z = Srv(h);

Min((Ctr(x, ky ,d)+Ctr( ky,z ,d )+Carm( ky,d)+Crec(ky,d))) (II)

4. Protótipo e-BioFlow

Figura 3. Arquitetura funcional do e-BioFlow


188


188

A arquitetura funcional (implementada) do protótipo e-BioFlow, é apresentada na figura

3. O módulo de definição apóia o cientista no processo de definição do workflow

abstrato. Periodicamente, o e-BioFlow realiza a leitura de todas as tarefas, que foram

previamente cadastradas pelo usuário administrador, no repositório central de dados e

constrói um grande serviço Web, denominado �ervices, contendo uma representação

vazia das tarefas. O serviço Web �ervices conterá uma função para cada tarefa

registrada. Uma vez gerada, a nova versão de �ervices é automaticamente publicada

gerando um novo arquivo WSDL, contendo uma operação para cada tarefa.

O cientista constrói um workflow abstrato com auxílio de uma ferramenta de

construção de workflows, como o editor gráfico do Taverna [Taverna, 2008] por

exemplo. Na construção do workflow abstrato, o cientista encadeia as tarefas

apontando-as para o serviço Web �ervices. Ao final, todas as tarefas do workflow

abstrato apontarão para o mesmo serviço Web, diferenciando-se apenas pela operação

escolhida.

O módulo de execução é dividido em dois submódulos: Pré-Execução e

Máquina de Execução. O módulo de Pré-Execução recebe um workflow abstrato

como parâmetro e retorna um workflow executável. A redefinição - transformação - de

um workflow abstrato em um workflow executável, consiste na substituição dos

serviços Web, de abstratos para físicos, bem como a inserção de novos serviços Web

para gerenciar o armazenamento e execução distribuídas. O processo de redefinição será

detalhado a seguir.

Finalizada a etapa de Pré-Execução, o workflow executável construído é

enviado ao módulo Máquina de Execução para realizar a sua execução. O módulo de

Máquina de Execução realiza chamadas em segundo plano para o sistema de gerência

de workflows selecionado, que na atual implementação do e-BioFlow, é o Taverna,

podendo ser estendido para novos sistemas. A Máquina de Execução recupera os

dados de entrada do workflow, armazenados no Repositório Central de Dados, realiza

os ajustes de formato necessários para o sistema de gerência de execução selecionado e

inicia a execução do workflow via chamada em segundo plano. Finalizada a execução

do workflow, são coletados os dados do log de execução e resultado final, que são

armazenados no Repositório Central de Dados.

Assim, no estágio atual da implementação do e-Bioflow, pode-se dizer que é um

sistema de gerência de workflows que utiliza os módulos de definição e execução de

workflows do Taverna.

5. Avaliação e Discussão

A abordagem D-BioFlow foi validada através de um modelo de simulação. O ambiente

de simulação é composto por quinze tarefas, implementadas por quinze serviços Web

hospedadas em dezesseis diferentes servidores simulados (quinze servidores de

processamento e armazenamento e um servidor central de armazenamento). Os custos

de comunicação entre servidores, armazenamento e recuperação de dados foram

parametrizados através de matrizes de custos, onde os custos de armazenamento e

recuperação variaram entre 1 e 9 e os custos de transferência entre cada par de sítios

variou de 5 a 45 refletindo a variação de tempo que acontece em ambientes reais onde


189


189

alguns serviços encontram-se dentro de uma rede local, e outros têm que ser

instanciados remotamente. Para a simulação, foi considerado um ambiente em que todos

os servidores remotos possuíssem espaço de armazenamento ilimitado.

O propósito da simulação era comparar quatro diferentes abordagens de

armazenamento: centralizado, distribuído posterior, distribuído sem heurística e

distribuído com heurística, sendo esta última a proposta da arquitetura D-BioFlow. A

abordagem centralizada simula um ambiente em que um único servidor do ambiente

guarda todos os dados intermediários dos workflows, tradicionalmente utilizado nas

abordagens existentes [Silva, 2006], [Kepler, 2008], [Taverna, 2008] e [VisTrails,

2008]. No contexto do armazenamento distribuído dos dados intermediários de um

workflow, na abordagem distribuída posterior, os dados intermediários são sempre

gravados no servidor que hospeda a tarefa subseqüente. A abordagem distribuída sem

heurística faz uso de uma função de custos para encontrar, dentre os servidores do

ambiente, aqueles que representam as melhores alternativas de armazenamento (função

de custos I da seção 3). Por fim, a abordagem D-BioFlow, utiliza uma função de custos

combinada a uma heurística que busca reaproveitar dados de execuções de workflows

derivados (função II da seção 3).

Figura 4. Tempo médio de execução para cada abordagem de armazenamento

A simulação foi realizada utilizando-se 48 workflows abstratos. A partir deles, o

simulador gerou um total 320 workflows executáveis para cada abordagem de

armazenamento. Para comparação dos resultados obtidos, foi considerado o tempo

médio de execução dos workflows executáveis. O simulador realiza 3 tipos de

simulação: execução completa, re-execução completa e re-execução parcial. A execução

completa representa uma execução de ciclo completo, quando um workflow abstrato é

selecionado para execução. Numa re-execução total, um workflow executável é

escolhido e re-executado com nova entrada de dados. Uma re-execução parcial ocorre

quando apenas parte de um workflow é executada. O gráfico apresentado na figura 4

mostra uma comparação do tempo médio de execução das 4 abordagens consideradas.


190


190

Observa-se que as 3 abordagens distribuídas apresentaram ganho de tempo na

execução dos workflows, quando comparadas com a abordagem centralizada. A

abordagem servidor posterior, apresenta um ganho de tempo médio de execução de

aproximadamente 29,6%. A abordagem D-BioFlow apresentou um ganho de tempo

médio de execução de 32,58%. Dentre as abordagens distribuídas, a abordagem D-

BioFlow apresentou um ganho aproximado de 4,2%, frente à abordagem servidor

posterior.

O gráfico da Figura 5 apresenta os dados obtidos, considerando apenas os casos

de re-execuções parciais e um percentual de re-execuções parciais de aproximadamente

23%. Observa-se que a abordagem D-BioFlow apresentou um ganho de

aproximadamente 17,16% em relação à abordagem centralizada.

Figura 5. Tempo médio de re-execuções parciais para cada abordagem de armazenamento

Comparado à abordagem distribuída sem heurística, o D-BioFlow apresentou

um ganho de aproximadamente 5%. Esse resultado evidencia a atuação da heurística

discutida na seção 3 deste trabalho. A abordagem D-BioFlow apresentou um ganho de

tempo de execução, quando comparado às outras 3 abordagens. Ampliando o número de

workflows executáveis para 411, foi observado um aumento no ganho, do D-BioFlow,

para aproximadamente 6,5%.

Considerando ambientes reais, onde diversos workflows têm inúmeras re-

execuções parciais (devido grande tempo requerido no processamento das tarefas) o uso

da heurística tende a ser mais vantajoso, visto que haverá maiores oportunidades de

reaproveitamento de dados.

No sentido de verificar a possibilidade de ganhos maiores para justificar o

esforço do cálculo, novos testes, utilizando maiores massas de dados, estão sendo

realizados.


191


191

6. Trabalhos Relacionados

Dentre os diversos trabalhos na área de gerência de workflows científicos, pode-se citar

alguns projetos que serão brevemente descritos a seguir, destacando-se algumas de suas

características relevantes.

Baseado no projeto PtolomeuII [Ptolemy, 2008] (Universidade de Berkeley), o

projeto Kepler [Kepler, 2008] é um sistema de gerência de workflows científicos

genérico. No Kepler, utilizam-se os conceitos de diretores e atores na composição de

workflows, isto é, um workflow é descrito por um diretor e uma coleção de atores. Para

descrevê-los, o Kepler adota a linguagem MoML (Modeling Markup Language),

herdada do PtolomeuII. Através de atores específicos é possivel definir tarefas baseadas

em serviços Web. Embora o Kepler não possua uma estrutura formal de identificação e

armazenamento dos dados intermediários, o usuário pode redefinir manualmente seus

workflows para realizar o armazenamento destes em arquivo ou SGBD, local ou remoto.

O registro das execuções dos workflows (proveniência de dados), até o momento da

escrita deste artigo, encontrava-se em fase de desenvolvimento.

Uma outra proposta de gerenciamento de workflows científicos é o InServices

[Silva, 2006] que é um sistema concebido especificamente para a bioinformática. No

InServices, as tarefas do workflow são diretamente mapeadas em Serviços Web. Com o

objetivo de facilitar a interoperabilidade, o InServices adotou a linguagem de definição

de workflows BPEL (Business Process Execution Language) pois esta linguagem tem

sido largamente adotada pela indústria [OASIS, 2008], e a máquina de execução da

Oracle [Oracle, 2008]. Com relação ao armazenamento de dados intermediários, o

InServices é o único dentre as abordagens em discussão que oferece tal facilidade,

porém utilizando o paradigma centralizado. Os dados são persistidos de acordo com o

GUS (Genomic Unified Schema) [GUS, 2008], que é um esquema de dados genérico

para a área genômica.

Já o VisTrails [VisTrails, 2008] é um sistema de gerência de workflows

científicos, com enfoque na visualização gráfica dos resultados. No Vistrails, as tarefas

são implementadas por módulos - componentes de software - conectáveis ao ambiente.

O suporte a serviços Web ocorre via módulo específico. Até o momento da elaboração

deste trabalho, a versão 1.0 do VisTrails, não apresentava um mecanismo formal para

persistir os resultados em um SGBD, ou mesmo identificá-los. Os resultados

(intermediários ou finais) podem ser armazenados em arquivos locais, através do

componente FileSink, desde que ao definir seu workflow o usuário inclua este

componente ou simplesmente salve o resultado como um arquivo local.

Por fim, o Taverna [Taverna, 2008] é um sistema de gerência de workflows

científicos também voltado para a bioinformática, pertencente ao projeto MyGrid. No

Taverna, as tarefas também são modeladas em serviços Web, a linguagem de definição

de workflows utilizada é a SCUFL (Simple Conceptual Unified Flow Language) e os

dados são identificados por LSID [Clark e Martin, 2004]. O suporte à proveniência de

dados se dá via o Plugin LogBook, que persiste os dados e metadados num SGBD

MySQL.

Nota-se que todas as abordagens acima oferecem a possibilidade de mapear

tarefas em serviços Web, o que viabiliza o aproveitamento dos diversos programas


192


192

científicos disponibilizados desta forma. No entanto, apesar de oferecer meios para

permitir o armazenamento de dados intermediários, nenhuma delas oferece tal facilidade

de forma automática, isto é, fica sob a responsabilidade do usuário no momento da

definição do workflow. Assim, o diferencial do e-Bioflow é permitir o armazenamento

de dados intermediários de modo automático, sem a interferência do usuário,

considerando ainda heurísticas para a escolha do sítio mais apropriado para o

armazenamento destes dados.

7. Conclusão

Devido às características dos workflows científicos, a estratégia de armazenamento dos

dados intermediários em um ambiente distribuído pode impactar significativamente no

desempenho da (re)execução de experimentos. Este trabalho propôs uma abordagem

para gerência de dados distribuídos em workflows científicos, visando melhorar o

desempenho da re-execução dos mesmos, considerando características específicas do

domínio da bioinformática.

As contribuições deste trabalho são: a especificação de um metamodelo para

armazenar os metadados de workflows e informações descrevendo o ambiente

distribuído; a extensão de uma arquitetura típica de gereciamento de workflows; a

definição de heurísticas para seleção do sítio de armazenamento dos dados

intermediários, de modo a melhorar o desempenho da re-execução de um workflow

através da redução do tráfego de dados; e a implementação de um protótipo, via

extensão do sistema de gerência de workflows Taverna. Além disso, foram apresentados

os resultados dos testes em um ambiente de simulação, que mostram que a arquitetura

D-Bioflow apresentou ganho de tempo de execução.

Como trabalhos futuros pretende-se realizar testes em ambientes reais, onde

diversos workflows têm inúmeras re-execuções. Uma outra possibilidade de trabalho

futuro é a adaptação do e-Bioflow para outros SGWFs científicos. Por fim, pretende-se

também trabalhar a proposta D-Bioflow em ambientes de Grid.

8. Agradecimentos

Este trabalho foi realizado com o apoio do CNPq, processo número 308809/2005-0.

Referências

Aalst W. e Hee K.(2002). Workflow Management: Models, Methods, and Systems. MIT

Press 2002

Baião, F. Mattoso, M. Zaverucha, G. (1998). Towards An Inductive Design Of

Distributed Object Oriented Databases. em Third IFCIS International Conference on

Cooperative Information Systems (CoopIS98), New York, USA. IEEE CS Press, v.

1. p. 188-197.

Cavalcanti, M. et al. (2005). Managing structural genomic workflows using Web

services. Data & Knowledge Engineering , v. 53. p. 45-74.

Clark, T. Martin, S. Ted, L. (2004). Globally distributed object identification for

biological knowledgebases. em Briefings in Bioinformatics 5. v. 1. p. 59-70.


193


193

GUS. GUS WEBSITE. (2008); Disponível em: http://www.gusdb.org.

Kepler. Kepler WEBSITE. (2008); Disponível em: www.kepler-project.org.

OASIS. OASIS WEBSITE. (2008); Disponível em: http://www.oasis-open.org.

ORACLE. ORACLE WEBSITE. (2008); Disponível em: www.oracle.com/

Ozsu, M. e Valduriez, P. (2001). Principles of Distributed Database Systems. Prentice-

Hall.

Ptolemy. PtolemyII WEBSITE.(2008); Disponível em: http://ptolemy.berkeley.edu/

ptolemyII.

Ruberg, G., Baião, F. e Mattoso, M. (2002). Estimating Costs of Path Expression

Evaluation in Distributed Object Databases. em 13th International Conference on

Database and Expert Systems Applications. DEXA. p. 351-360.

Silva, F. ; Cavalcanti, M. e Dávila, A. (2006). In Services: Data Management for In

Silico Workflows. em 17th International Workshop on Database and Expert Systems

Applications, Cracóvia, Polônia. DEXA Workshops, 2006, p. 206-210.

Taverna. Taverna WEBSITE. (2008); Disponível em: http://taverna.sourceforge.net.

technology/bpel.

Vistrails. Vistrails WEBSITE. (2008); Disponível em: http://www.vistrails.org.

Web Services, (2008) disponível em http://www.w3.org/2002/ws/.

Wildenberg, M.et al (2003) .Alocação de dados em Bancos de Dados Distribuídos. In:

XVIII Simpósio Brasileiro de Banco de Dados, 2003, Manaus. SBBD 2003.


194


194

Documents

D-Bioflow: Uma Abordagem para Distribuição de Dados em ... · D-Bioflow: Uma Abordagem para Distribuição de Dados em Workflows de Bioinformática José Guilherme Monteiro de Menezes1,