Um Sistema de Fluxos de Trabalho Científicos Eficiente e Escalável

Transcrição

1 Um Sistema de Fluxos de Trabalho Científicos Eficiente e Escalável George Teodoro e Renato Ferreira Departamento de Ciência da Computação Universidade Federal de Minas Gerais Belo Horizonte, Brasil {george, renato}@dcc.ufmg.br Resumo O aumento no volume de dados científicos disponível gerou uma demanda de processamento que extrapola a capacidade de apenas um computador, criando a necessidade de utilização de recursos distribuídos para a análise desses dados. Entretanto, a maioria das aplicações científicas são seqüenciais e não são capazes de utilizar ambientes distribuídos. Em resposta a essas dificuldades foram introduzidos os sistemas de fluxo de trabalho científicos, os quais permitem a execução de aplicações sequḙnciais em ambientes distribuídos, possibilitando a exploração de grandes bases de dados. Neste trabalho, apresentamos um sistema de fluxo de trabalho único no sentido de que o mesmo foi especialmente desenvolvido para facilitar a execução dessas aplicações em ambientes distribuídos utilizando bancos de dados para armazenamento de dados científicos. Nosso sistema é otimizado para execução fluxos de trabalho intensivos em dados, pois nos preocupamos com gerenciamento dos mesmos. Os resultados mostram que podemos alcançar speedups próximos do linear para aplicações sofisticadas, criadas por múltiplos componentes. 1. Introdução A análise de grandes volumes de dados tem se tornado fundamental em diversas áreas da ciência. Os avanços na área de tecnologia e computação tem permitido a criação e o armazenamento de dados cada vez mais volumosos. Um exemplo de projeto científico que gera dados significativamente volumosos é o projeto Large Handron Collider (LCD), iniciado em 06 no CERN, que deverá gerar da ordem de petabytes de dados por ano []. Associado a isso, notamos que muitas dessas análises podem ser vistas como a aplicação sucessiva de diversas etapas de processamento nesses grandes volumes de dados, tendo como objetivo produzir resultados publicáveis a partir dos dados brutos. Essas computações podem ser modeladas como redes de processamento em fluxo de dados, sendo descritas como grafos direcionados onde os nodos representam componentes de processamento e as arestas os fluxos de dados entre eles. Os sistemas de fluxo de trabalho científicos [2, 8, 9] (Scientific Workflow Systems) foram introduzidos com o objetivo de facilitar a execução dessas análises 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ântica da aplicação, executar os fluxos criados em grandes coleções de dados e monitorar a execução, por exemplo, através da análise de resultados intermediários. Esses sistemas também devem, naturalmente, explorar o paralelismo inerente a múltiplas tarefas num ambiente distribuído como um Grid, além de permitir a reutilização de componentes, ou seja, etapas de processamento entre aplicações. Na Figura 1, vemos o fluxo de trabalho de uma aplicação biomédica típica de análise de imagens. Esse exemplo envolve análise de imagens microscópicas de placentas de ratazanas para estudar mudanças no fenótipo, induzidas por manipulações genéticas. Nesse artigo, apresentamos um sistema de execução de fluxos de trabalho científicos baseado em Mobius [7] e Anthill [5]. Nesse sistema, duas premissas foram observadas: 1) Tanto os dados de entrada quando os dados de saída são grandes, e precisam ser armazenados em ambientes distribuídos; 2) Muitas das etapas da execução estão previamente implementadas e devem poder ser incorporadas ao fluxo de trabalho a partir de implementações protótipo, como códigos matlab. Mobius foi usado como armazenador persistente de dados, tantos os iniciais como os finais e os intermediários (aqueles que migram entre componentes). Anthill é nossa plataforma de execução de aplicações de fluxos de dados. Nesse ambiente as aplicações são decompostas em filtros que transformam dados recebidos em streams de entrada, produzindo assim streams de saída. Anthill

2 I I,1 I,2 Normalização I,3 O I: Imagens Entrada (slides de placenta) Classifiçacão do I,n: Imagens depois de n operações de Cores de Tecidos Histograma O: Imagens de saída Figura 1. Fluxo de trabalho exemplo. permite que cada filtro seja instanciado um número transparente de vezes, de forma a equilibrar os tempos de processamento entre os vários estágios e obter speedups em plataformas distribuídas. Esse modelo de ambiente de execução é bastante propício para a implementação do nosso sistema. Os experimentos demonstraram que foi possível obter speedups altos para aplicações compostas a partir de componentes previamente construídos como códigos seqüenciais. O restante de artigo é organizado da seguinte forma: na Seção 2, apresentamos alguns dos principais trabalhos relacionados; na Seção 3 discutimos a arquitetura deste sistema; na Seção é apresentada a aplicação exemplo, assim como a mesma foi mapeada em um fluxo de trabalho; na Seção 5 fazemos análise de resultados; e finalmente na Seção 6 apresentamos as conclusões e os trabalhos futuros; 2 Trabalhos Relacionados Em [2] é apresentado um sistema de gerenciamento de fluxos de trabalho que utiliza bancos de dados para o armazenamento das informações sobre os fluxos e gerenciamento dos mesmos durante a execução. Essa estratégia difere da adotada nesse trabalho, pois aqui utilizamos bancos de dados para armazenar os dados de entrada, intermediários e produzidos como saída pelos fluxos. Chimera [6] é um sistema que armazena as transformações às quais os dados de entrada são submetidos para fins de proveniência. Essa informação pode ser utilizada por exemplo para: re-execução de aplicações, re-criação de resultados, etc. Em nosso ambiente optamos pelo armazenamento de todos os estágios intermediários dos dados. O projeto Pegasus desenvolve um sistema que armazena informações sobre derivação de dados utilizando Chimera, mas também trata do mapeamento de fluxos de trabalho em grid de computadores. A abordagem utilizada permite que o usuário crie um fluxo de trabalho abstrato que posteriormente é mapeado em um fluxo concreto. Em Kepler [9] é apresentado um sistema de gerenciamento de fluxos de trabalho científicos, o qual dispõe de ferramentas para criação e execução desses fluxos utilizando serviços web. O modo de composição de fluxos apresentado é baseado na noção de atores, primeiramente apresentada em PTOLEMY II. Esse sistema apresenta soluções interessantes para gerenciamento de fluxos de trabalho, entretanto não apresenta soluções satisfatórias para integração das aplicações em execução com os dados que as mesmas utilizam. Dessa forma, construímos nosso sistema com a idéia de que o mesmo deveria prover uma interação eficiente e escalável com bancos de dados distribuídos, possibilitando o armazenamento de dados nesses sistemas. A ferramenta responsável por executar os fluxos de trabalho criados em nosso sistema é o Anthill [5], o qual baseia-se no modelo de programação filtro-fluxo (filterstream), originalmente proposto em Active Disks [1]. No Anthill, filtros são cada etapa de processamento e os fluxos são as abstrações de comunicação entre filtros. Aplicações que utilizam este sistema são conjuntos de filtros executados sobre uma rede de computadores conectados através de fluxos, criando paralelismo de tarefas. Em tempo de execução, são criadas múltiplas cópias de cada filtros, permitindo que cada estágio seja replicado, criando paralelismo de dados. Finalmente, apresentamos Mobius [7] um banco de dados XML para ambientes distribuídos heterogêneos, o qual é responsável pelo armazenamento dos dados utilizados como entrada ou criados em tempo de execução. Este sistema é projetado como um conjunto de serviços conectados através de redes utilizando protocolos bem definido. Os dados nesse ambiente são modelados 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êneos. 3 Arcabouço do sistema de fluxos de trabalho Nesta seção, descrevemos o núcleo do sistema de fluxos de trabalho. Primeiramente, na Seção 3.1 apresentamos Anthill e Mobius, utilizados na construção desse sistema e a seguir, na Seção 3.2, apresentamos o núcleo do sistema de execução de fluxos de trabalho. 3.1 Anthill e Mobius O sistema de fluxos de trabalho foi desenvolvido utilizando Anthill [5] e Mobius [7]. Anthill é responsável por gerenciar a comunicação e executar aplicações em ambientes distribuídos heterogêneos e gerenciar a comunicação. Essa ferramenta utiliza conceitos do modelo de programação filtro-fluxo [1] (filter-stream) com algumas extensões. No modelo de programação filtro-fluxo, filtros são a representação de cada estágio da computação, onde existe transformação sobre dados, e os fluxos são abstrações

3 de comunicação entre os filtros. Aplicações, neste modelo, são criadas por um processo de decomposição em filtros, ou seja, pela divisão da aplicação original em blocos de processamento que comunicam entre si através de um fluxo de dados uni-direcional sobre uma rede de computadores. Este modelo de construção de aplicações, naturalmente, cria paralelismo de tarefas, pois os filtros são executados como em um pipeline comunicando-se através da rede. Além disso, em tempo de execução, pode-se criar múltiplas cópias transparentes de cada um dos filtros que compõem a aplicação nas máquinas disponíveis, criando desta forma uma maneira de replicar a cada um dos estágios do pipeline. Uma vez que os dados enviados a cada dos estágios também podem ser particionados, cria-se paralelismo de dados. Mobius [7] é um sistema de banco de dados XML para ambientes distribuídos heterogêneos. Este sistema é projetado como um conjunto de serviços frouxamente conectados com protocolos bem definidos. O componente Global Model Exchange (GME) é responsável por prover suporte a criação, gerenciamento e controle de versão de esquemas XML. No Mobius, cada documento deve satisfazer ao esquema registrado no GME. O componente Mako, por sua vez, é responsável pelos serviços de criação e gerenciamento de bases de dados em ambientes distribuídos. Documentos que estejam em conformidade com os esquemas podem ser armazenados, pesquisados e recuperados remotamente de cada uma das instâncias do Mako que operam independentemente. Os dados armazenados nesse sistema são indexados e podem ser pesquisados eficientemente utilizando XPath. Em nossa implementação, Mobius é responsável pelo armazenamento dos dados utilizadas como entrada, criados em tempo de execução e os resultados. Dessa forma, cada unidade de dado do sistema é armazenada como um documento XML, assim quando falarmos sobre documentos no restante deste texto estamos nos referindo as unidades de dados. 3.2 Arquitetura do sistema distribuído de execução de fluxos de trabalho O sistema é composto de três componentes principais, conforme pode ser visto na Figura 2: repositório de bibliotecas compartilhadas e executáveis, criador de fluxos de trabalho e ambiente distribuído de execução de fluxos de trabalho. As duas primeiras partes, apresentadas em detalhes no artigo [11], permitem que os usuários possam armazenar e compartilhar programas e apresentam uma ferramenta para criação de fluxos de trabalho baseados em componentes armazenados no repositório. Usuários utilizando essas ferramentas podem criar fluxos de trabalho baseados em programas compilados sem a necessidade de reescrita de código, permitindo que aplicações seqüenciais sejam executadas em ambientes distribuídos. O ambiente de execução, apresentado em detalhes a seguir, é dividido em sistema de suporte a execução, sistema de gerenciamento de fluxos de trabalho e gerenciador de armazenamento persistente de dados. Repositório de bibliotecas compartilhadas e executáveis Retorna executável Criador de Filtros Criador de Fluxos de Trabalho Filtros da aplicação Ambiente distribuído de execução Sistema de suporte a execução Armazenador de Dados em Memória Descritor do fluxo Gerenciador de Meta-dados Sistema de gerenciamento do workflow Gerenciador de Armazenamento Persistente Figura 2. Arquitetura do Sistema Sistema de suporte a execução Como discutido anteriormente, este componente foi implementando utilizando Anthill [5], o qual é responsável por instanciar e monitorar a execução dos fluxos de trabalho. Entretanto, tivemos que modifica-lo para que o mesmo pudesse atender aos requisitos necessários para a construção dos sistema de gerenciamento de fluxos de trabalho, discutido em detalhes na seção As modificações feitas permitiram que aplicações pudessem comunicar-se transparentemente com o sistema de gerenciamento, enviando informações necessárias para o controle da execução, tais como: quais dados foram processados; requisição por dados, sempre que um filtro estiver disponível; resultados parciais Sistema de gerenciamento de fluxos de trabalho O sistema de gerenciamento do fluxo de trabalho é composto de dois componentes, o gerenciador de meta-dados (GMD) e o armazenador de dados em memória (ADM). Ambos foram desenvolvidos utilizando Anthill [5], desta forma, pode-se, durante a execução, instanciar tantas cópias de cada um dos componentes, quantas sejam necessárias. A seguir descrevemos detalhadamente o GMD e o ADM. Gerenciador de meta-dados (GMD) É responsável pela monitoração e gerenciamento dos meta-dados relacionados

4 a todos dados de entrada, criados durante a execução e de saída. Quando a execução do fluxo de trabalho é iniciada, o GMD recebe como entrada uma pesquisa do tipo XPath [3], que é utilizada para delimitar o conjunto de dados de entrada da aplicação. Este repassa a requisição ao gerenciador de armazenamento persistente de dados (GAP), descrito em detalhes na seção 3.2.3, que retorna os meta-dados de cada um dos documentos que satisfazem a pesquisa. Tão logo termine esse processo, o GMD possui a informação sobre a localização de cada um dos documentos do conjunto de entrada. No processo de execução, cada documento passa por três estágios: Não processado : todos os documentos do conjunto de dados de entrada são considerados não processados no início da execução, o que significa que os mesmos estão disponíveis para processamento. Sendo processado : o documento assume este estado quando é retornado para algum filtro. Além disso, todos os documentos criados durante a execução estão nesse estado, pois eles foram criados e enviados para serem processados por outro filtro. Processado : um documento é dito processado somente quando já foi processado por um filtro e o resultado de seu processamento já tenha sido enviado para outro filtro e ao ADM. Em tempo de execução o GMD é responsável por decidir quais documentos devem ser processados por cada filtro. Está partição é feita sob-demanda, sempre que um filtro que lê dados do conjunto de entrada encontra-se disponível o GMD é 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ão dos dados. Armazenador de dados em memória (ADM) O armazenador de dados em memória é o componente responsável por prover a interface de leitura e escrita de dados entre os filtros da aplicação e o GAP. Durante a inicialização do sistema de fluxo de trabalho são criadas múltiplas cópias deste de acordo com configuração do usuário. Quando a aplicação começa sua execução os filtros são agrupados aos ADMs disponíveis. Esse agrupamento faz uma amarração de cada filtro ao ADM que responderá suas requisições durante toda a execução do fluxo, a amarração tenta fazer com que os filtros sejam atendidos pelo ADM locais. Caso não exista ADM na mesma máquina o filtro é ligado a um ADM qualquer. Assim, durante a execução, quando os filtros requisitam dados, a requisição é repassada ao ADM correspondente. O ADM, por sua vez, repassa a requisição ao GMD e espera pelo meta-dado do documento que deve ser processado. Então o ADM verifica se este dado está armazenado em memória, caso não esteja acessa o GAP e retorna os dados ao filtro. As diversas instâncias de ADM trabalham independentemente, dessa forma elas podem estar lendo diferentes porções de dados simultaneamente. Isso cria uma forma de leitura de dados similar à tradicional leitura paralela 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 intermediários também é executado pelo ADM. Quando solicitado ele pode armazenar todos os dados enviados entre componentes dos fluxos. Durante a execução o ADM cria bases de dados distribuídas para cada um dos fluxos de dados existentes e armazena todas as comunicações como documentos no Mobius. Assim, sempre que filtros trocam mensagens elas também são enviadas ao ADM, que armazena os dados em memória e deixam a aplicação prosseguir sua execução, fazendo a escrita em segundo plano. Como no caso da leitura, esse processo é feito independentemente pelas múltiplas instâncias de ADM, criando um esquema de escrita em paralelo 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 discutido anteriormente, é responsável pelo armazenamento dos dados de entrada, saída e intermediários das aplicações de fluxo de trabalho. Todos esses conjuntos de dados são definidos por esquemas XML e armazenados como bases de dados XML. Quando a aplicação gera algum documento, esse é enviado ao ADM e então armazenado no GAP. Aplicação Exemplo Nesta seção, apresentamos a aplicação exemplo [10], utilizada na avaliação desse sistema e o fluxo de trabalho no qual ela foi mapeada. A aplicação utiliza imagens microscópicas de alta resolução para estudar mudanças, induzidas por manipulações genéticas, no fenótipo de placenta de ratazanas. O objetivo da mesma é fazer a segmentação de imagens, que compõem visões 3D de placentas de ratazanas, em regiões correspondentes aos três tipos de tecidos: labirinto, espongioblasto e glicogênio. Na figura 3, é apresentada uma visão completa da aplicação. A mesma foi dividida em 6 estágios, sendo que alguns deles podem ter mais de uma etapa. A seguir, descrevemos os três estágios que foram mapeados em fluxos de trabalho:

5 Separação do plano da frente do plano do fundo (Foreground/Background Separation ()): as imagens são convertidas do formato RGB para CMYK e as combinações das cores dos canais são limitadas a valores estipulados pelo usuário. O resultado dessa operação é o plano da frente da imagem. Normalização do histograma: as imagens precisam ter suas cores ser corrigidas. Este processo ocorre em três fases: calcula-se a média das cores de todas as imagens; escolhe uma imagem para ser o alvo da normalização; e normaliza o histograma de cores de cada uma das outras imagens utilizando o da imagem alvo. das cores: nesse estágio da aplicação cada pixel da imagem é classificado em de 8 classes: núcleo escuro, núcleo de intensidade mediana, núcleo claro, núcleo extra claro, células de sangue vermelho, citoplasma claro, citoplasma escuro e fundo da imagem. dos tecidos: as imagens são divididas em regiões de 0x0 pixels, para as quais são calculadas 3 probabilidades baseadas na densidade da área, sendo esses valores utilizados na classificação da região em um dos 3 tecidos. Placenta Estágio 3.1 Mapeamento da aplicação exemplo em fluxo de trabalho O mapeamente foi realizado utilizando as ferramentas apresentadas no artigo anterior [11], neste texto não apresentamos detalhes sobre essas ferramentas, apenas uma breve discussão sobre os passos que o usuário deve seguir para a criação do fluxo de trabalho, que são: Desenvolvimento dos filtros : nesta fase é realizado o principal trabalho de integração de uma aplicação qualquer para utilização deste sistema, que consite da construção da seção compiledfilters do arquivo de configuração chamado de Descritor do fluxo. Para tanto, o usuário deve fornecer dados como: o nome da biblioteca e função que será utilizada no filtro ou executável, as entradas e seus tipos, a informação a respeito da transformação dos dados que chegam nos canais do fluxo em dados tratáveis pelos programas e etc. Desenvolvimento do fluxo : Na fase de composição do fluxo de trabalho o usuário precisa especificar quais filtros fazem parte dos fluxos, além das conexões entre eles. A informação é retirada, respectivamente, das seções placement e layout do Descritor do fluxo. Depois de realizar essas etapas o usuário precisa apenas executar um script, gerado pelo nosso sistema, com os parâmetros da aplicação e a consulta XML utilizada para identificar o conjunto de dados de entrada armazenados no GAP. Teste de Cores (R, G, B) CSV Estágio 1 Imagem referência Referência Estágio 2 Máscara Normalização de histograma Estágio 6 Estágio Cor corrigida de cores Imagem mapeada dos tecidos Mapa de segmentação Estágio 5 Fase de treinamento Interação Humana de bayes Informação de treinamento Figura 3. Aplicação de segmentação da placenta de ratazana.1.1 Fluxo de trabalho da aplicação exemplo Nesta seção, descrevemos o fluxo de trabalho gerado a partir da aplicação exemplo. Primeiramente, como pode ser visto na Figura 3, dividimos a aplicação em 6 estágios e posteriormente mapeamos os 3 computacionalmente mais intensos em fluxos de trabalho, como pode ser visto na Figura. Na mesma figura, acima, representamos a visão que o usuário tem ao criar o fluxo de trabalho e abaixo a visão desse mesmo fluxo do ponto de vista do ambiente de execução. A entrada do estágio da aplicação depende do fim do processamento do estágio 2. Porém os estágios 2 e 3 podem ser executados concorrentemente, dessa forma construímos um sub-fluxo para cada um dos estágios 3 e, assim quando 3 é executado o sistema cuida da criação de bases distribuídas e do armazenamento de sua saída, que é utilizada como entrada de. O estágio 6 possui um fluxo entre dois filtros, como pode ser visto na Figura, existe uma seta pontilhada desse fluxo(stream) para o sistema de gerenciamento de fluxos de trabalho. A seta representa a opção de armazenamento

6 Estágio 3 Estágio. Sistema de Gerenciamento de fluxos de trabalho Normalização de histograma de cores Sistema de Gerenciamento de fluxos de trabalho.... Normalização de histograma... Escritores de cores Estágio 6 dos tecidos Escritor dos tecidos Figura. Fluxo de trabalho da aplicação da placenta de ratazana eficiente de resultados parciais, ou seja, de mensagens enviadas entre filtros. Esses resultados podem ser utilizados para reiniciar fluxos de trabalho sem a necessidade de executar totalmente o mesmo, sendo útil para aplicações que são fortemente afetadas por parâmetros. 5 Resultados experimentais Nesta seção, apresentamos os resultados experimentais utilizando o fluxo de trabalho da Figura 1, que foi criado a partir de quatro estágios de processamento de uma aplicação biomédica de análise de imagens [10]. Detalhes sobre o mapeamento da aplicação no fluxo podem ser vistos nos artigos [11, 12]. Nossos experimentos foram executados em um cluster de computadores com máquinas conectadas por um switch Fast Ethernet. Cada nodo tem um processador AMD Athlon(tm) 6 Processor 30+, 2GB de memória e S.O. Linux 2.6. Durante a avaliação do sistema utilizamos uma base de dados com 866 imagens (23.9GB) como entrada. O conjunto de dados foi dividido igualmente e armazenado no GAPD. Criamos um cópia de ADM e uma instância do GAPD em cada uma das máquinas, uma cópia de GMD em uma delas e uma cópia de cada um dos filtros do fluxo por máquina. As execuções em nossos experimentos utilizam no minímo duas máquinas, em virtude de não termos uma versão serial que execute sobre todas as imagens. A Figura 5(a) apresenta os resultados do estágio, o tempo de execução utilizando duas máquinas é segundos e decai quase linearmente com o aumento do número de nodos. A Figura 5(b), apresenta os resultados da etapa de normalização do histograma, o tempo de execução com duas máquinas é de cerca de segundos e o speedup obtido é próximo do linear. Já a Figura 5(c), mostra detalhadamente os tempos do estágio de normalização do histograma. Como pode ser visto, o tempo total é dominado pela função de processamento, que representa o tempo entre a chamada do executável utilizado nesse estágio e a finalização do mesmo. O overhead adicionado pela utilização desse sistema é muito pequeno, o mesmo pode ser dado, de forma super-estimada, pela diferença entre o tempo total de execução e o tempo gasto na função de processamento. Na Figura 5(d), mostramos os resultados obtidos durante a execução do estágio das cores e segmentação dos tecidos. Este é o estágio mais demorado da execução, sendo seu tempo de execução com duas máquinas de aproximadamente segundos. Mais uma vez o tempo decai linear com o aumento do número de máquinas. Em especial, apresentamos o resultado do último estágio da aplicação exemplo quando salvamos e quando não salvamos os dados enviados do passo das cores para o segmentação dos tecidos. Os experimentos comprovam a eficiência no armazenamento de resultados parciais, pois média da diferença entre os mesmos é de apenas 5%. 6 Conclusões Neste trabalho, apresentamos um sistema de suporte a fluxos de trabalho para aplicações intensivas em dados para ambiente distribuídos heterogêneos. O sistema foi construído sobre Anthill [5], consistindo de filtros Anthill criados automaticamente a partir da descrição alto nível dos componentes da aplicação do usuário. Os filtros gerados podem executar códigos arbitrários de usuário através de uma interface simples. As avaliações experimentais mostram que o sistema é capaz de executar aplicações sofisticadas, com múltiplos componentes, alcançando speedups lineares. Os resultados destacam o baixo overhead introduzido pelo sistema na execução da aplicação. Os resultados mostram que os custos introduzidos no armazenamento de resultados parciais, ou seja, dados enviados entre componentes de um fluxo, tem a média de apenas 5%, indicando a eficiência do sistema nessa tarefa. Nossos trabalho futuros partem da observação que aplicações típicas esperadas para nosso modelo movimentam grandes massas de dados, e têm um tempo de execução na escala de dezenas de horas. Nesse cenário, é de se esperar que várias aplicações distintas estejam em execução si-

7 Tempos de execução (segundos) Estágio Foreground/Background (FGBG 866 images(23.9gb)) 000 Tempo de teste Tempo de execução (segundos) Normalização do Histograma (866 imagens de placenta (23.9GB)) Tempo de teste Função de processamento Leitura de dados Funções de (des)serializar Escreve para fluxo Número de máquinas Número de máquinas (a) (c) Valor Speedup do estágio de normalização do histograma(866 imagens e máscaras) Speed up Speed up linear Tempo de Execução (seg) Tempo de Execução Classif. das Cores e Seg. do Tecido (866 imagens) Salvando estado intermediário Não salvando estado intermediário 8 12 Número de máquinas Número de Nodos (b) (d) multaneamente. Dessa forma, desejamos implementar mecanismos que permitam otimizações inter-aplicações, alguns deles são: o compartilhamento de componente em tempo de execução, pois aplicações diferentes podem utilizar componentes comuns; utilização de caching semântico, de forma a extrair informação parcial necessária em um aplicação, diretamente do espaço de memória de outra que esteja executando simultaneamente. Referências [1] A. Acharya, M. Usysal, and J. Saltz. Active disks: Programming model, algorithms and evaluation. Eighth Int. Conference on Architectural Support for Programming Languages and Operations Systems (ASPLOS VIII), Oct [2] A. Ailamaki, Y. E. Ioannidis, and M. Livny. Scientific workflow management by database management. In SSDBM 98: Proceedings of the 10th International Conference on Scientific and Statistical Database Management, pages , Washington, DC, USA, IEEE Computer Society. [3] A. Berglund, S. Boag, D. Chamberlim, M. F. Fernández, M. Kay, J. Robie, and J. Siméon. Xml path language (xpath). World Wide Web Consortium (W3C), August 03. [] CERN. Large hadron collider (lhc) - [5] R. Ferreira, W. M. Jr., D. Guedes, L. Drummond, B. Coutinho, and G. Teodoro. Anthill:a scalable run-time environment for data mining applications. SBAC-PAD, 05. Figura 5. Resultados Experimentais [6] I. Foster, J. Vockler, M. Wilde, and Y. Zhao. Chimera: Avirtual data system for representing, querying, and automating data derivation. The 1th Conference on Scientific and Statistical Database Management (SSDBM 02), 02. [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 Applications Workshop, pages 38, 0. [8] G. Kola, T. Kosar, J. Frey, and M. Livny. Disc: A system for distributed data intensive scientific computing. WORLDS 0, December 0. [9] B. Ludäscher, I. Altintas, and C. Berkley. Scientific workflow management and the Kepler system. Concurrency and Computation: Practice & Experience, Special Issue on Scientific Workflows, 18(10): , 05. [10] T. C. Pan and K. Huang. Virtual mouse placenta: Tissue layer segmentation. Proceedings of the 27th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC05), Sep 05. [11] G. Teodoro, T. Tavares, R. Ferreira, T. Kurc, W. Meira, D. Guedes, T. Pan, and J. Saltz. Run-time support for efficient execution of scientific workflows on distributed environmments. SBAC, October 06. [12] G. Teodoro, T. Tavares, R. Ferreira, T. Kurc, W. Meira, D. Guedes, T. Pan, and J. Saltz. Run-time support for efficient execution of scientific workflows on distributed environmments, invited paper. IJPP, to appear 07.