Um Sistema de Fluxos de Trabalho Cient´ıficos Eficiente e Escal´avel
George Teodoro e Renato Ferreira
Departamento de Ciˆencia da Computac¸˜ao
Universidade Federal de Minas Gerais
Belo Horizonte, Brasil
{george, renato}@dcc.ufmg.br
Resumo
O aumento no volume de dados cient´ıficos dispon´ıvel ge-rou uma demanda de processamento que extrapola a capa-cidade de apenas um computador, criando a necessidade de utilizac¸˜ao de recursos distribu´ıdos para a an´alise desses dados. Entretanto, a maioria das aplicac¸˜oes cient´ıficas s˜ao seq ¨uenciais e n˜ao s˜ao capazes de utilizar ambientes dis-tribu´ıdos. Em resposta a essas dificuldades foram introdu-zidos os sistemas de fluxo de trabalho cient´ıficos, os quais permitem a execuc¸˜ao de aplicac¸˜oes sequˆenciais em ambi-entes distribu´ıdos, possibilitando a explorac¸˜ao de grandes bases de dados. Neste trabalho, apresentamos um sistema de fluxo de trabalho ´unico no sentido de que o mesmo foi especialmente desenvolvido para facilitar a execuc¸˜ao des-sas aplicac¸˜oes em ambientes distribu´ıdos utilizando bancos de dados para armazenamento de dados cient´ıficos. Nosso sistema ´e otimizado para execuc¸˜ao fluxos de trabalho inten-sivos em dados, pois nos preocupamos com gerenciamento dos mesmos. Os resultados mostram que podemos alcanc¸ar speedups pr´oximos do linear para aplicac¸˜oes sofisticadas, criadas por m´ultiplos componentes.
1. Introduc¸ ˜ao
A an´alise de grandes volumes de dados tem se tornado fundamental em diversas ´areas da ciˆencia. Os avanc¸os na ´area de tecnologia e computac¸˜ao tem permitido a criac¸˜ao e o armazenamento de dados cada vez mais volumosos. Um exemplo de projeto cient´ıfico que gera dados signifi-cativamente volumosos ´e o projeto Large Handron Collider (LCD), iniciado em 2006 no CERN, que dever´a gerar da ordem de petabytes de dados por ano [4].
Associado a isso, notamos que muitas dessas an´alises podem ser vistas como a aplicac¸˜ao sucessiva de diversas etapas de processamento nesses grandes volumes de dados, tendo como objetivo produzir resultados public´aveis a partir dos dados brutos. Essas computac¸˜oes podem ser
modela-das como redes de processamento em fluxo de dados, sendo descritas como grafos direcionados onde os nodos represen-tam componentes de processamento e as arestas os fluxos de dados entre eles.
Os sistemas de fluxo de trabalho cient´ıficos [2, 8, 9] (Sci-entific Workflow Systems) foram introduzidos com o obje-tivo de facilitar a execuc¸˜ao dessas an´alises para dados muito volumosos, que geram longos per´ıodos de processamento. Esses sistemas devem prover um ambiente onde cientistas possam criar e descrever componentes baseados nas tarefas que desejam executar, organizar os componentes em fluxo de trabalho de acordo com a semˆantica da aplicac¸˜ao, execu-tar os fluxos criados em grandes colec¸˜oes de dados e moni-torar a execuc¸˜ao, por exemplo, atrav´es da an´alise de resulta-dos intermedi´arios. Esses sistemas tamb´em devem, natural-mente, explorar o paralelismo inerente a m´ultiplas tarefas num ambiente distribu´ıdo como um Grid, al´em de permitir a reutilizac¸˜ao de componentes, ou seja, etapas de processa-mento entre aplicac¸˜oes.
Na Figura 1, vemos o fluxo de trabalho de uma aplicac¸˜ao biom´edica t´ıpica de an´alise de imagens. Esse exemplo en-volve an´alise de imagens microsc´opicas de placentas de ra-tazanas para estudar mudanc¸as no fen ´otipo, induzidas por manipulac¸˜oes gen´eticas.
Nesse artigo, apresentamos um sistema de execuc¸˜ao de fluxos de trabalho cient´ıficos baseado em Mobius [7] e Anthill [5]. Nesse sistema, duas premissas foram obser-vadas: 1) Tanto os dados de entrada quando os dados de sa´ıda s˜ao grandes, e precisam ser armazenados em ambien-tes distribu´ıdos; 2) Muitas das etapas da execuc¸˜ao est˜ao pre-viamente implementadas e devem poder ser incorporadas ao fluxo de trabalho a partir de implementac¸˜oes prot´otipo, como c´odigos matlab. Mobius foi usado como armazena-dor persistente de dados, tantos os iniciais como os finais e os intermedi´arios (aqueles que migram entre componentes). Anthill ´e nossa plataforma de execuc¸˜ao de aplicac¸˜oes de fluxos de dados. Nesse ambiente as aplicac¸˜oes s˜ao decom-postas em filtros que transformam dados recebidos em stre-ams de entrada, produzindo assim strestre-ams de sa´ıda. Anthill
FG/BG N o r m a l i z a ç ã o d o H i s t o g r a m a Classifiçacão d e C o r e s S e g m e n t a ç ã o d e T e c i d o s
I I,1 I,2 I,3 O I: Imagens Entrada (slides de placenta) I,n: Imagens depois de n operações O: Imagens de saída
Figura 1. Fluxo de trabalho exemplo.
permite que cada filtro seja instanciado um n ´umero transpa-rente de vezes, de forma a equilibrar os tempos de proces-samento entre os v´arios est´agios e obter speedups em plata-formas distribu´ıdas. Esse modelo de ambiente de execuc¸˜ao ´e bastante prop´ıcio para a implementac¸˜ao do nosso sistema. Os experimentos demonstraram que foi poss´ıvel obter spee-dups altos para aplicac¸˜oes compostas a partir de componen-tes previamente constru´ıdos como c´odigos seq ¨uenciais.
O restante de artigo ´e organizado da seguinte forma: na Sec¸˜ao 2, apresentamos alguns dos principais trabalhos rela-cionados; na Sec¸˜ao 3 discutimos a arquitetura deste sistema; na Sec¸˜ao 4 ´e apresentada a aplicac¸˜ao exemplo, assim como a mesma foi mapeada em um fluxo de trabalho; na Sec¸˜ao 5 fazemos an´alise de resultados; e finalmente na Sec¸˜ao 6 apre-sentamos as conclus˜oes e os trabalhos futuros;
2
Trabalhos Relacionados
Em [2] ´e apresentado um sistema de gerenciamento de fluxos de trabalho que utiliza bancos de dados para o ar-mazenamento das informac¸˜oes sobre os fluxos e gerenci-amento dos mesmos durante a execuc¸˜ao. Essa estrat´egia difere da adotada nesse trabalho, pois aqui utilizamos ban-cos de dados para armazenar os dados de entrada, inter-medi´arios e produzidos como sa´ıda pelos fluxos.
Chimera [6] ´e um sistema que armazena as transformac¸˜oes `as quais os dados de entrada s˜ao sub-metidos para fins de proveniˆencia. Essa informac¸˜ao pode ser utilizada por exemplo para: re-execuc¸˜ao de aplicac¸˜oes, re-criac¸˜ao de resultados, etc. Em nosso ambiente optamos pelo armazenamento de todos os est´agios intermedi´arios dos dados. O projeto Pegasus desenvolve um sistema que armazena informac¸˜oes sobre derivac¸˜ao de dados utilizando Chimera, mas tamb´em trata do mapeamento de fluxos de trabalho em grid de computadores. A abordagem utilizada permite que o usu´ario crie um fluxo de trabalho abstrato que posteriormente ´e mapeado em um fluxo concreto.
Em Kepler [9] ´e apresentado um sistema de gerencia-mento de fluxos de trabalho cient´ıficos, o qual disp ˜oe de fer-ramentas para criac¸˜ao e execuc¸˜ao desses fluxos utilizando servic¸os web. O modo de composic¸˜ao de fluxos tado ´e baseado na noc¸˜ao de atores, primeiramente apresen-tada em PTOLEMY II. Esse sistema apresenta soluc¸˜oes in-teressantes para gerenciamento de fluxos de trabalho, en-tretanto n˜ao apresenta soluc¸˜oes satisfat´orias para integrac¸˜ao das aplicac¸˜oes em execuc¸˜ao com os dados que as mesmas
utilizam. Dessa forma, constru´ımos nosso sistema com a id´eia de que o mesmo deveria prover uma interac¸˜ao eficiente e escal´avel com bancos de dados distribu´ıdos, possibili-tando o armazenamento de dados nesses sistemas.
A ferramenta respons´avel por executar os fluxos de tra-balho criados em nosso sistema ´e o Anthill [5], o qual baseia-se no modelo de programac¸˜ao filtro-fluxo (filter-stream), originalmente proposto em Active Disks [1]. No Anthill, filtros s˜ao cada etapa de processamento e os fluxos s˜ao as abstrac¸˜oes de comunicac¸˜ao entre filtros. Aplicac¸˜oes que utilizam este sistema s˜ao conjuntos de filtros executados sobre uma rede de computadores conectados atrav´es de flu-xos, criando paralelismo de tarefas. Em tempo de execuc¸˜ao, s˜ao criadas m´ultiplas c´opias de cada filtros, permitindo que cada est´agio seja replicado, criando paralelismo de dados.
Finalmente, apresentamos Mobius [7] um banco de da-dos XML para ambientes distribu´ıda-dos heterogˆeneos, o qual ´e respons´avel pelo armazenamento dos dados utilizados como entrada ou criados em tempo de execuc¸˜ao. Este sis-tema ´e projetado como um conjunto de servic¸os conectados atrav´es de redes utilizando protocolos bem definido. Os da-dos nesse ambiente s˜ao modelada-dos por meio de esquemas XML e armazenados como documentos XML, permitindo o uso de protocolos bem definidos para o armazenamento e pesquisa em sistemas heterogˆeneos.
3
Arcabouc¸o do sistema de fluxos de trabalho
Nesta sec¸˜ao, descrevemos o n ´ucleo do sistema de flu-xos de trabalho. Primeiramente, na Sec¸˜ao 3.1 apresentamos Anthill e Mobius, utilizados na construc¸˜ao desse sistema e a seguir, na Sec¸˜ao 3.2, apresentamos o n ´ucleo do sistema de execuc¸˜ao de fluxos de trabalho.
3.1
Anthill e Mobius
O sistema de fluxos de trabalho foi desenvolvido utilizando Anthill [5] e Mobius [7]. Anthill ´e res-pons´avel por gerenciar a comunicac¸˜ao e executar aplicac¸˜oes em ambientes distribu´ıdos heterogˆeneos e gerenciar a comunicac¸˜ao. Essa ferramenta utiliza conceitos do modelo de programac¸˜ao filtro-fluxo [1] (filter-stream) com algumas extens˜oes. No modelo de programac¸˜ao filtro-fluxo, filtros s˜ao a representac¸˜ao de cada est´agio da computac¸˜ao, onde existe transformac¸˜ao sobre dados, e os fluxos s˜ao abstrac¸˜oes
de comunicac¸˜ao entre os filtros. Aplicac¸˜oes, neste modelo, s˜ao criadas por um processo de decomposic¸˜ao em filtros, ou seja, pela divis˜ao da aplicac¸˜ao original em blocos de pro-cessamento que comunicam entre si atrav´es de um fluxo de dados uni-direcional sobre uma rede de computadores.
Este modelo de construc¸˜ao de aplicac¸˜oes, naturalmente, cria paralelismo de tarefas, pois os filtros s˜ao executados como em um pipeline comunicando-se atrav´es da rede. Al´em disso, em tempo de execuc¸˜ao, pode-se criar m´ultiplas c´opias transparentes de cada um dos filtros que comp ˜oem a aplicac¸˜ao nas m´aquinas dispon´ıveis, criando desta forma uma maneira de replicar a cada um dos est´agios do pipeline. Uma vez que os dados enviados a cada dos est´agios tamb´em podem ser particionados, cria-se paralelismo de dados.
Mobius [7] ´e um sistema de banco de dados XML para ambientes distribu´ıdos heterogˆeneos. Este sistema ´e pro-jetado como um conjunto de servic¸os frouxamente conec-tados com protocolos bem definidos. O componente Glo-bal Model Exchange (GME) ´e respons´avel por prover su-porte a criac¸˜ao, gerenciamento e controle de vers˜ao de es-quemas XML. No Mobius, cada documento deve satisfazer ao esquema registrado no GME. O componente Mako, por sua vez, ´e respons´avel pelos servic¸os de criac¸˜ao e gerenci-amento de bases de dados em ambientes distribu´ıdos. Do-cumentos que estejam em conformidade com os esquemas podem ser armazenados, pesquisados e recuperados remo-tamente de cada uma das instˆancias do Mako que operam independentemente. Os dados armazenados nesse sistema s˜ao indexados e podem ser pesquisados eficientemente uti-lizando XPath. Em nossa implementac¸˜ao, Mobius ´e res-pons´avel pelo armazenamento dos dados utilizadas como entrada, criados em tempo de execuc¸˜ao e os resultados. Dessa forma, cada unidade de dado do sistema ´e armaze-nada como um documento XML, assim quando falarmos sobre documentos no restante deste texto estamos nos refe-rindo as unidades de dados.
3.2
Arquitetura do sistema distribu´ıdo de
execu¸
c˜
ao de fluxos de trabalho
O sistema ´e composto de trˆes componentes principais, conforme pode ser visto na Figura 2: reposit´orio de biblio-tecas compartilhadas e execut´aveis, criador de fluxos de tra-balho e ambiente distribu´ıdo de execuc¸˜ao de fluxos de traba-lho. As duas primeiras partes, apresentadas em detalhes no artigo [11], permitem que os usu´arios possam armazenar e compartilhar programas e apresentam uma ferramenta para criac¸˜ao de fluxos de trabalho baseados em componentes ar-mazenados no reposit´orio. Usu´arios utilizando essas ferra-mentas podem criar fluxos de trabalho baseados em progra-mas compilados sem a necessidade de reescrita de c´odigo, permitindo que aplicac¸˜oes seq ¨uenciais sejam executadas em ambientes distribu´ıdos. O ambiente de execuc¸˜ao,
apresen-tado em detalhes a seguir, ´e dividido em sistema de suporte a execuc¸˜ao, sistema de gerenciamento de fluxos de trabalho e gerenciador de armazenamento persistente de dados.
Criador de Filtros
Ambiente distribuído de execução
Sistema de suporte a execução
Gerenciador de Armazenamento Persistente
Criador de Fluxos de Trabalho
Sistema de gerenciamento do workflow Filtros da aplicação
Repositório de bibliotecas compartilhadas e executáveis
Retorna executável
Armazenador de Dados em Memória
Gerenciador de Meta-dados
Descritor do fluxo
Figura 2. Arquitetura do Sistema
3.2.1 Sistema de suporte a execuc¸˜ao
Como discutido anteriormente, este componente foi imple-mentando utilizando Anthill [5], o qual ´e respons´avel por instanciar e monitorar a execuc¸˜ao dos fluxos de trabalho. Entretanto, tivemos que modifica-lo para que o mesmo pu-desse atender aos requisitos necess´arios para a construc¸˜ao dos sistema de gerenciamento de fluxos de trabalho, discu-tido em detalhes na sec¸˜ao 3.2.2.
As modificac¸˜oes feitas permitiram que aplicac¸˜oes pudes-sem comunicar-se transparentemente com o sistema de ge-renciamento, enviando informac¸˜oes necess´arias para o con-trole da execuc¸˜ao, tais como: quais dados foram proces-sados; requisic¸˜ao por dados, sempre que um filtro estiver dispon´ıvel; resultados parciais.
3.2.2 Sistema de gerenciamento de fluxos de trabalho
O sistema de gerenciamento do fluxo de trabalho ´e com-posto de dois componentes, o gerenciador de meta-dados (GMD) e o armazenador de dados em mem´oria (ADM). Ambos foram desenvolvidos utilizando Anthill [5], desta forma, pode-se, durante a execuc¸˜ao, instanciar tantas c´opias de cada um dos componentes, quantas sejam necess´arias. A seguir descrevemos detalhadamente o GMD e o ADM.
Gerenciador de meta-dados (GMD) E respons´avel pela´
a todos dados de entrada, criados durante a execuc¸˜ao e de sa´ıda. Quando a execuc¸˜ao do fluxo de trabalho ´e iniciada, o GMD recebe como entrada uma pesquisa do tipo XPath [3], que ´e utilizada para delimitar o conjunto de dados de en-trada da aplicac¸˜ao. Este repassa a requisic¸˜ao ao gerenciador de armazenamento persistente de dados (GAP), descrito em detalhes na sec¸˜ao 3.2.3, que retorna os meta-dados de cada um dos documentos que satisfazem a pesquisa. T˜ao logo termine esse processo, o GMD possui a informac¸˜ao sobre a localizac¸˜ao de cada um dos documentos do conjunto de entrada. No processo de execuc¸˜ao, cada documento passa por trˆes est´agios:
• “N˜ao processado”: todos os documentos do conjunto de dados de entrada s˜ao considerados “n˜ao processa-dos” no in´ıcio da execuc¸˜ao, o que significa que os mes-mos est˜ao dispon´ıveis para processamento.
• “Sendo processado”: o documento assume este estado quando ´e retornado para algum filtro. Al´em disso, to-dos os documentos criato-dos durante a execuc¸˜ao est˜ao nesse estado, pois eles foram criados e enviados para serem processados por outro filtro.
• “Processado”: um documento ´e dito processado so-mente quando j´a foi processado por um filtro e o resul-tado de seu processamento j´a tenha sido enviado para outro filtro e ao ADM.
Em tempo de execuc¸˜ao o GMD ´e respons´avel por decidir quais documentos devem ser processados por cada filtro. Est´a partic¸˜ao ´e feita sob-demanda, sempre que um filtro que lˆe dados do conjunto de entrada encontra-se dispon´ıvel o GMD ´e transparentemente notificado. Durante o processo de escolha do dado a ser processado tentamos, sempre que poss´ıvel, retornar um documento que seja local ao filtro, reduzindo dessa forma o custo de transmiss˜ao dos dados.
Armazenador de dados em mem´oria (ADM) O
arma-zenador de dados em mem´oria ´e o componente respons´avel por prover a interface de leitura e escrita de dados entre os filtros da aplicac¸˜ao e o GAP. Durante a inicializac¸˜ao do sis-tema de fluxo de trabalho s˜ao criadas m´ultiplas c´opias deste de acordo com configurac¸˜ao do usu´ario.
Quando a aplicac¸˜ao comec¸a sua execuc¸˜ao os filtros s˜ao agrupados aos ADMs dispon´ıveis. Esse agrupamento faz uma amarrac¸˜ao de cada filtro ao ADM que responder´a suas requisic¸˜oes durante toda a execuc¸˜ao do fluxo, a amarrac¸˜ao tenta fazer com que os filtros sejam atendidos pelo ADM locais. Caso n˜ao exista ADM na mesma m´aquina o filtro ´e ligado a um ADM qualquer.
Assim, durante a execuc¸˜ao, quando os filtros requisitam dados, a requisic¸˜ao ´e repassada ao ADM correspondente.
O ADM, por sua vez, repassa a requisic¸˜ao ao GMD e es-pera pelo meta-dado do documento que deve ser proces-sado. Ent˜ao o ADM verifica se este dado est´a armazenado em mem´oria, caso n˜ao esteja acessa o GAP e retorna os dados ao filtro. As diversas instˆancias de ADM trabalham independentemente, dessa forma elas podem estar lendo di-ferentes porc¸˜oes de dados simultaneamente. Isso cria uma forma de leitura de dados similar `a tradicional leitura para-lela de dados (parallel I/O), exceto pelo fato de que estamos realizando-a em bancos de dados XML distribu´ıdos.
A tarefa de armazenamento de resultados parciais ou in-termedi´arios tamb´em ´e executado pelo ADM. Quando so-licitado ele pode armazenar todos os dados enviados en-tre componentes dos fluxos. Durante a execuc¸˜ao o ADM cria bases de dados distribu´ıdas para cada um dos fluxos de dados existentes e armazena todas as comunicac¸˜oes como documentos no Mobius. Assim, sempre que filtros trocam mensagens elas tamb´em s˜ao enviadas ao ADM, que arma-zena os dados em mem´oria e deixam a aplicac¸˜ao prosseguir sua execuc¸˜ao, fazendo a escrita em segundo plano. Como no caso da leitura, esse processo ´e feito independentemente pelas m´ultiplas instˆancias de ADM, criando um esquema de escrita em paralelo.
3.2.3 Gerenciador de armazenamento persistente
(GAP)
O gerenciador de armazenamento persistente foi constru´ıdo com Mobius [7]. Ele utiliza o Mobius para instanciar bases de dados em ambientes distribu´ıdos. O GAP, como discu-tido anteriormente, ´e respons´avel pelo armazenamento dos dados de entrada, sa´ıda e intermedi´arios das aplicac¸˜oes de fluxo de trabalho. Todos esses conjuntos de dados s˜ao de-finidos por esquemas XML e armazenados como bases de dados XML. Quando a aplicac¸˜ao gera algum documento, esse ´e enviado ao ADM e ent˜ao armazenado no GAP.
4
Aplicac¸˜ao Exemplo
Nesta sec¸˜ao, apresentamos a aplicac¸˜ao exemplo [10], utilizada na avaliac¸˜ao desse sistema e o fluxo de trabalho no qual ela foi mapeada. A aplicac¸˜ao utiliza imagens mi-crosc´opicas de alta resoluc¸˜ao para estudar mudanc¸as, indu-zidas por manipulac¸˜oes gen´eticas, no fen ´otipo de placenta de ratazanas. O objetivo da mesma ´e fazer a segmentac¸˜ao de imagens, que comp ˜oem vis˜oes 3D de placentas de rata-zanas, em regi˜oes correspondentes aos trˆes tipos de tecidos: labirinto, espongioblasto e glicogˆenio.
Na figura 3, ´e apresentada uma vis˜ao completa da aplicac¸˜ao. A mesma foi dividida em 6 est´agios, sendo que alguns deles podem ter mais de uma etapa. A seguir, des-crevemos os trˆes est´agios que foram mapeados em fluxos de trabalho:
• Separac¸˜ao do plano da frente do plano do fundo
(Foreground/Background Separation (FG/BG)): as
imagens s˜ao convertidas do formato RGB para CMYK e as combinac¸˜oes das cores dos canais s˜ao limitadas a valores estipulados pelo usu´ario. O resultado dessa operac¸˜ao ´e o plano da frente da imagem.
• Normalizac¸˜ao do histograma: as imagens precisam ter suas cores ser corrigidas. Este processo ocorre em trˆes fases: calcula-se a m´edia das cores de todas as imagens; escolhe uma imagem para ser o alvo da normalizac¸˜ao; e normaliza o histograma de cores de cada uma das outras imagens utilizando o da imagem alvo.
• Classificac¸˜ao das cores: nesse est´agio da aplicac¸˜ao cada pixel da imagem ´e classificado em de 8 classes: n ´ucleo escuro, n ´ucleo de intensidade mediana, n ´ucleo claro, n ´ucleo extra claro, c´elulas de sangue vermelho, citoplasma claro, citoplasma escuro e fundo da ima-gem.
• Segmentac¸˜ao dos tecidos: as imagens s˜ao divididas em regi˜oes de 40x40 pixels, para as quais s˜ao cal-culadas 3 probabilidades baseadas na densidade da ´area, sendo esses valores utilizados na classificac¸˜ao da regi˜ao em um dos 3 tecidos.
FG/BG ITK Placenta PNG Máscara PNG Normalização de histograma MatLab Teste de Cores MatLab (R, G, B) CSV Imagem referência Referência Cor corrigida PNG Classificação de cores ITK Imagem mapeada PNG Segmentação dos tecidos MatLab Mapa de segmentação PNG Classificação de bayes ITK Interação Humana Informação de treinamento PNG Fase de treinamento Estágio 1 Estágio 3 Estágio 4 Estágio 5 Estágio 6 Estágio 2
Figura 3. Aplicac¸ ˜ao de segmentac¸ ˜ao da pla-centa de ratazana
4.1
Mapeamento da aplica¸
c˜
ao exemplo em
fluxo de trabalho
O mapeamente foi realizado utilizando as ferramentas apresentadas no artigo anterior [11], neste texto n˜ao apre-sentamos detalhes sobre essas ferramentas, apenas uma breve discuss˜ao sobre os passos que o usu´ario deve seguir para a criac¸˜ao do fluxo de trabalho, que s˜ao:
Desenvolvimento dos filtros : nesta fase ´e realizado o
principal trabalho de integrac¸˜ao de uma aplicac¸˜ao qualquer para utilizac¸˜ao deste sistema, que consite da construc¸˜ao da sec¸˜ao compiledFilters do arquivo de configurac¸˜ao chamado de “Descritor do fluxo”. Para tanto, o usu´ario deve forne-cer dados como: o nome da biblioteca e func¸˜ao que ser´a utilizada no filtro ou execut´avel, as entradas e seus tipos, a informac¸˜ao a respeito da transformac¸˜ao dos dados que che-gam nos canais do fluxo em dados trat´aveis pelos programas e etc.
Desenvolvimento do fluxo : Na fase de composic¸˜ao do
fluxo de trabalho o usu´ario precisa especificar quais filtros fazem parte dos fluxos, al´em das conex ˜oes entre eles. A informac¸˜ao ´e retirada, respectivamente, das sec¸˜oes place-ment e layout do “Descritor do fluxo”. Depois de realizar essas etapas o usu´ario precisa apenas executar um script, gerado pelo nosso sistema, com os parˆametros da aplicac¸˜ao e a consulta XML utilizada para identificar o conjunto de dados de entrada armazenados no GAP.
4.1.1 Fluxo de trabalho da aplicac¸˜ao exemplo
Nesta sec¸˜ao, descrevemos o fluxo de trabalho gerado a par-tir da aplicac¸˜ao exemplo. Primeiramente, como pode ser visto na Figura 3, dividimos a aplicac¸˜ao em 6 est´agios e posteriormente mapeamos os 3 computacionalmente mais intensos em fluxos de trabalho, como pode ser visto na Fi-gura 4. Na mesma fiFi-gura, acima, representamos a vis˜ao que o usu´ario tem ao criar o fluxo de trabalho e abaixo a vis˜ao desse mesmo fluxo do ponto de vista do ambiente de execuc¸˜ao.
A entrada do est´agio 4 da aplicac¸˜ao depende do fim do processamento do est´agio 2. Por´em os est´agios 2 e 3 po-dem ser executados concorrentemente, dessa forma cons-tru´ımos um sub-fluxo para cada um dos est´agios 3 e 4, as-sim quando 3 ´e executado o sistema cuida da criac¸˜ao de bases distribu´ıdas e do armazenamento de sua sa´ıda, que ´e utilizada como entrada de 4.
O est´agio 6 possui um fluxo entre dois filtros, como pode ser visto na Figura 4, existe uma seta pontilhada desse fluxo(stream) para o sistema de gerenciamento de fluxos de trabalho. A seta representa a opc¸˜ao de armazenamento
FG/BG ITK
Normalização de histograma MatLab
Sistema de Gerenciamento de fluxos de trabalho
Classificação de cores ITK Segmentação dos tecidos MatLab FG/BG
.
.
.
Sistema de Gerenciamento de fluxos de trabalho
Normalização de histograma
...
.
.
.
.
.
.
Classificação de cores Escritor Segmentação dos tecidos Escritores. . .
Estágio 3 Estágio 4 Estágio 6Figura 4. Fluxo de trabalho da aplicac¸ ˜ao da placenta de ratazana
eficiente de resultados parciais, ou seja, de mensagens en-viadas entre filtros. Esses resultados podem ser utilizados para reiniciar fluxos de trabalho sem a necessidade de exe-cutar totalmente o mesmo, sendo ´util para aplicac¸˜oes que s˜ao fortemente afetadas por parˆametros.
5
Resultados experimentais
Nesta sec¸˜ao, apresentamos os resultados experimentais utilizando o fluxo de trabalho da Figura 1, que foi cri-ado a partir de quatro est´agios de processamento de uma aplicac¸˜ao biom´edica de an´alise de imagens [10]. Detalhes sobre o mapeamento da aplicac¸˜ao no fluxo podem ser vistos nos artigos [11, 12]. Nossos experimentos foram executa-dos em um cluster de computadores com 20 m´aquinas co-nectadas por um switch Fast Ethernet. Cada nodo tem um processador AMD Athlon(tm) 64 Processor 3200+, 2GB de mem´oria e S.O. Linux 2.6.
Durante a avaliac¸˜ao do sistema utilizamos uma base de dados com 866 imagens (23.49GB) como entrada. O con-junto de dados foi dividido igualmente e armazenado no GAPD. Criamos um c´opia de ADM e uma instˆancia do GAPD em cada uma das m´aquinas, uma c´opia de GMD em uma delas e uma c´opia de cada um dos filtros do fluxo por m´aquina. As execuc¸˜oes em nossos experimentos utilizam no min´ımo duas m´aquinas, em virtude de n˜ao termos uma vers˜ao serial que execute sobre todas as imagens.
A Figura 5(a) apresenta os resultados do est´agio FG/BG,
o tempo de execuc¸˜ao utilizando duas m´aquinas ´e 3.800 segundos e decai quase linearmente com o aumento do n ´umero de nodos. A Figura 5(b), apresenta os resulta-dos da etapa de “normalizac¸˜ao do histograma”, o tempo de execuc¸˜ao com duas m´aquinas ´e de cerca de 7.000 segundos e o speedup obtido ´e pr´oximo do linear.
J´a a Figura 5(c), mostra detalhadamente os tempos do est´agio de normalizac¸˜ao do histograma. Como pode ser visto, o tempo total ´e dominado pela func¸˜ao de processa-mento, que representa o tempo entre a chamada do exe-cut´avel utilizado nesse est´agio e a finalizac¸˜ao do mesmo. O overhead adicionado pela utilizac¸˜ao desse sistema ´e muito pequeno, o mesmo pode ser dado, de forma super-estimada, pela diferenc¸a entre o tempo total de execuc¸˜ao e o tempo gasto na func¸˜ao de processamento.
Na Figura 5(d), mostramos os resultados obtidos du-rante a execuc¸˜ao do est´agio “Classificac¸˜ao das cores” e “segmentac¸˜ao dos tecidos”. Este ´e o est´agio mais demo-rado da execuc¸˜ao, sendo seu tempo de execuc¸˜ao com duas m´aquinas de aproximadamente 55.000 segundos. Mais uma vez o tempo decai linear com o aumento do n ´umero de m´aquinas. Em especial, apresentamos o resultado do ´ultimo est´agio da aplicac¸˜ao exemplo quando salvamos e quando n˜ao salvamos os dados enviados do passo “Classificac¸˜ao das cores” para o “segmentac¸˜ao dos tecidos”. Os experimentos comprovam a eficiˆencia no armazenamento de resultados parciais, pois m´edia da diferenc¸a entre os mesmos ´e de ape-nas 5%.
6
Conclus˜oes
Neste trabalho, apresentamos um sistema de suporte a fluxos de trabalho para aplicac¸˜oes intensivas em dados para ambiente distribu´ıdos heterogˆeneos. O sistema foi cons-tru´ıdo sobre Anthill [5], consistindo de filtros Anthill cri-ados automaticamente a partir da descric¸˜ao alto n´ıvel dos componentes da aplicac¸˜ao do usu´ario. Os filtros gerados podem executar c´odigos arbitr´arios de usu´ario atrav´es de uma interface simples.
As avaliac¸˜oes experimentais mostram que o sistema ´e capaz de executar aplicac¸˜oes sofisticadas, com m´ultiplos componentes, alcanc¸ando speedups lineares. Os resulta-dos destacam o baixo overhead introduzido pelo sistema na execuc¸˜ao da aplicac¸˜ao. Os resultados mostram que os cus-tos introduzidos no armazenamento de resultados parciais, ou seja, dados enviados entre componentes de um fluxo, tem a m´edia de apenas 5%, indicando a eficiˆencia do sistema nessa tarefa.
Nossos trabalho futuros partem da observac¸˜ao que aplicac¸˜oes t´ıpicas esperadas para nosso modelo movimen-tam grandes massas de dados, e tˆem um tempo de execuc¸˜ao na escala de dezenas de horas. Nesse cen´ario, ´e de se espe-rar que v´arias aplicac¸˜oes distintas estejam em execuc¸˜ao
0 500 1000 1500 2000 2500 3000 3500 4000 20 16 12 8 4 2
Tempos de execução (segundos)
Número de máquinas
Estágio Foreground/Background (FGBG−866 images(23.49GB)) Tempo de teste (a) 4 6 8 10 12 14 16 18 20 22 20 16 12 8 4 Valor Número de máquinas
Speedup do estágio de normalização do histograma(866 imagens e máscaras) Speed−up
Speed−up linear
(b)
multaneamente. Dessa forma, desejamos implementar me-canismos que permitam otimizac¸˜oes inter-aplicac¸˜oes, al-guns deles s˜ao: o compartilhamento de componente em tempo de execuc¸˜ao, pois aplicac¸˜oes diferentes podem utili-zar componentes comuns; utilizac¸˜ao de caching semˆantico, de forma a extrair informac¸˜ao parcial necess´aria em um aplicac¸˜ao, diretamente do espac¸o de mem´oria de outra que esteja executando simultaneamente.
Referˆencias
[1] A. Acharya, M. Usysal, and J. Saltz. Active disks: Program-ming model, algorithms and evaluation. Eighth Int.
Confe-rence on Architectural Support for Programming Languages and Operations Systems (ASPLOS VIII), Oct 1998.
[2] A. Ailamaki, Y. E. Ioannidis, and M. Livny. Scientific work-flow management by database management. In SSDBM ’98:
Proceedings of the 10th International Conference on Scien-tific and Statistical Database Management, pages 190–199,
Washington, DC, USA, 1998. IEEE Computer Society. [3] A. Berglund, S. Boag, D. Chamberlim, M. F. Fern´andez,
M. Kay, J. Robie, and J. Sim´eon. Xml path language (xpath).
World Wide Web Consortium (W3C), August 2003.
[4] CERN. Large hadron collider (lhc)
-http://www.interactions.org/lhc/.
[5] R. Ferreira, W. M. Jr., D. Guedes, L. Drummond, B. Cou-tinho, and G. Teodoro. Anthill:a scalable run-time environ-ment for data mining applications. SBAC-PAD, 2005.
0 1000 2000 3000 4000 5000 6000 7000 20 16 12 8 4 2
Tempo de execução (segundos)
Número de máquinas
Normalização do Histograma (866 imagens de placenta (23.49GB)) Tempo de teste Função de processamento Leitura de dados Funções de (des)serializar Escreve para fluxo
(c) 0 10000 20000 30000 40000 50000 60000 20 16 12 8 4 2
Tempo de Execução (seg)
Número de Nodos
Tempo de Execução − Classif. das Cores e Seg. do Tecido (866 imagens) Salvando estado intermediário
Não salvando estado intermediário
(d)
Figura 5. Resultados Experimentais
[6] I. Foster, J. Vockler, M. Wilde, and Y. Zhao. Chimera: Avir-tual data system for representing, querying, and automating data derivation. The 14th Conference on Scientific and
Sta-tistical Database Management (SSDBM’02), 2002.
[7] S. Hastings, S. Langella, S. Oster, and J. Saltz. Distributed data management and integration framework: The mobius project. Global Grid Forum 11 (GGF11) Semantic Grid
Ap-plications Workshop, pages 20 – 38, 2004.
[8] G. Kola, T. Kosar, J. Frey, and M. Livny. Disc: A system for distributed data intensive scientific computing.
WORLDS’04, December 2004.
[9] B. Lud¨ascher, I. Altintas, and C. Berkley. Scientific work-flow management and the Kepler system. Concurrency and
Computation: Practice & Experience, Special Issue on Sci-entific Workflows, 18(10):1039–1065, 2005.
[10] T. C. Pan and K. Huang. Virtual mouse placenta: Tissue layer segmentation. Proceedings of the 27th Annual
Inter-national Conference of the IEEE Engineering in Medicine and Biology Society (EMBC2005), Sep 2005.
[11] G. Teodoro, T. Tavares, R. Ferreira, T. Kurc, W. Meira, D. Guedes, T. Pan, and J. Saltz. Run-time support for ef-ficient execution of scientific workflows on distributed envi-ronmments. SBAC, October 2006.
[12] G. Teodoro, T. Tavares, R. Ferreira, T. Kurc, W. Meira, D. Guedes, T. Pan, and J. Saltz. Run-time support for ef-ficient execution of scientific workflows on distributed envi-ronmments, invited paper. IJPP, to appear 2007.
