d-bioflow: uma abordagem para distribuição de dados em ... · d-bioflow: uma abordagem para...
Post on 06-Jul-2019
215 Views
Preview:
TRANSCRIPT
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.
guilherme.menezes@gmail.com�fernanda.baiao@uniriotec.br�yoko@ime.eb.br
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
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
181
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
182
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
183
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
184
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
185
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
186
XXIII Simpósio Brasileiro de Banco de Dados
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.
XXIII Simpósio Brasileiro de Banco de Dados
187
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
188
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
189
XXIII Simpósio Brasileiro de Banco de Dados
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.
XXIII Simpósio Brasileiro de Banco de Dados
190
XXIII Simpósio Brasileiro de Banco de Dados
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.
XXIII Simpósio Brasileiro de Banco de Dados
191
XXIII Simpósio Brasileiro de Banco de Dados
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
XXIII Simpósio Brasileiro de Banco de Dados
192
XXIII Simpósio Brasileiro de Banco de Dados
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.
XXIII Simpósio Brasileiro de Banco de Dados
193
XXIII Simpósio Brasileiro de Banco de Dados
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.
XXIII Simpósio Brasileiro de Banco de Dados
194
XXIII Simpósio Brasileiro de Banco de Dados
194
top related