info.info-db
À Prof 
  
Prof Marta Mattoso 
  
Patrick Valduriez 
  
Prof Daniel De Oliveira 
  
Ao Prof Alvaro Coutinho 
  
Ao Thaylon Guedes 
  
Luciano Leite 
  
José Vitor Delgado 
  
Thiago Perrotta 
  
Débora Pina 
  
Vinícius Campos 
  
Renan Souza 
  
Mara Prata 
  
Gutierrez Da Costa 
  
Claudia Prata 
  
Análise De Dados 
  
Científicos Sobre 
  
Múltiplas Fontes 
  
D E Dados 
  
A O Longo 
  
D A Execução 
  
D E Simulações 
  
Computacionais Vítor 
  
Silva Sousa 
  
Marta Lima De Queirós Mattoso 
  
Daniel Cardoso 
  
Moraes De Oliveira 
  
Patrick Valduriez 
  
Silva Vítor 
  
Sousa 
  
Diante Disso 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
ANALYSIS OF RAW DATA FROM MULTIPLE DATA SOURCES DURING THE EXECUTION OF COMPUTATIONAL SIMULATIONS

analisados pelos usuários do domínio científico a fim de validar as suas hipóteses científicas. Entretanto, esta não é uma tarefa trivial,

x LISTAGEM DE FIGURAS Figura 1. Exemplo de simulação de astronomia para a análise de dados científicos. 5 Figura 2. Exemplo de fluxo de dados. [START_REF] Oldfield | Evaluation of methods to integrate analysis into a large-scale shock physics code[END_REF]. As setas representam a movimentação de dados entre recursos computacionais, enquanto os retângulos unidos correspondem ao uso de dados ainda alocados em memória. Figura 5. Camadas da arquitetura ARMFUL. Figura 6. Exemplo de extração de dados científicos em arquivos no formato HDF5. Figura 7. Diagrama de classe PROV-Df (SILVA et al., 2016c). Figura 23. Ajuste em um programa de simulação para a extração de dados científicos.

95

Figura 24. Exemplo de representação de dados de domínio em um conjunto de dados.

97

Figura 25. Visão dataflows para a especificação de fluxo de dados da Figura 14. 99

Figura 26. Visão datasetSchemas para o fluxo de dados da Figura 14. 99

Figura 27. Visualização de uma especificação de fluxo de dados na perspectiva de grafo.

Figura 28. Visão counts para a execução do script da Figura 14.

Figura 29. Análise do fluxo de elementos de dados pelos rastros de proveniência nos níveis físico (setas laranjas) e lógico (seta verde).

Figura 30. Consulta para a análise do fluxo de elementos no exemplo de contagem de palavras.

Figura 31. Exemplo de dependência de dados: t2 depende de t1.

Figura 32. Mapeamento do fluxo de dados para o modelo de dados lógico.

Figura 33. Operação de extração de dados científicos.

Figura 34. Operação de indexação de dados científicos.

Figura 35. Exemplo de tarefas a partir da execução do script em Python da Figura 14. Tabela 14. Armazenamento de dados em disco para o tanque real de batimetria. 171

Tabela 15. Tempo de processamento de consultas de acordo a abordagem de extração e indexação de dados científicos. 181

Capítulo 1 -Introdução

As aplicações de Ciência Computacional e Engenharia (CSE) são baseadas em modelos computacionais que resolvem problemas que normalmente requerem Processamento de Alto Desempenho (PAD) [START_REF] Rüde | Research and Education in Computational Science and Engineering[END_REF]. As aplicações de CSE não estão vinculadas a um domínio específico. Elas podem ser encontradas em biologia, astronomia, geologia, várias áreas de engenharia, etc. Elas têm a natureza exploratória de aplicações científicas, ao mesmo tempo em que têm que lidar com execuções em grande escala, que duram por um longo tempo, mesmo quando usam PAD. O ecossistema de software para desenvolver essas aplicações envolve muito mais que escrever scripts ou invocar uma cadeia de códigos científicos legados [START_REF] Rüde | Research and Education in Computational Science and Engineering[END_REF]. Cientistas computacionais desenvolvem seus códigos de aplicações de CSE baseados em uma modelagem matemática complexa que resulta na chamada de componentes de ambientes e bibliotecas de CSE. As aplicações de CSE (ou simulações computacionais) são caracterizadas pelo encadeamento de chamadas desses componentes que muitas vezes já estão preparados para a execução paralela otimizada.

No entanto, vários parâmetros precisam ser definidos para chamar esses componentes. Essa escolha de valores é muito difícil de ser predefinida e precisa de monitoramento para ajustes em tempo de execução. Para realizar o monitoramento de uma simulação computacional é necessário acompanhar a evolução da geração de dados científicos ao longo da execução. Uma aplicação de CSE gera um grande volume de dados científicos [START_REF] Pennisi | Will Computers Crash Genomics?[END_REF]. Esses dados se caracterizam por estarem fragmentados em um grande número de partições devido ao PAD. Além das partições de dados de arquivos, associadas a uma etapa da simulação, outros arquivos são gerados a cada etapa do encadeamento de componentes da aplicação de CSE. Acompanhar a evolução desses dados requer acessar os dados científicos diretamente no sistema de arquivos, o que é uma atividade custosa devido à quantidade, tamanho, estrutura de dados e formato padrão desses arquivos. Esse acesso necessita da escrita de programas específicos para identificar e percorrer os arquivos envolvidos na análise, relacionando os dados de seus conteúdos, o que se caracteriza por um acesso ad-hoc aos dados. Outra dificuldade é associar os dados dos arquivos aos parâmetros e etapas da simulação em andamento, além de arquivos de visualizações que são gerados para o monitoramento (SILVA et al., 2016c).

científicos relacionados entre si para análise, durante a execução em ambiente PAD, sem as limitações do acesso ad-hoc sobre os arquivos e do acesso ao SGBD post-mortem.

Uma primeira abordagem para o problema de relacionar dados gerados em diferentes etapas de uma simulação computacional seria o uso de modelos de dados de proveniência [START_REF] Freire | Provenance for Computational Tasks: A Survey[END_REF]. Modelos de dados de proveniência permitem a representação de fluxos de dados registrando o histórico dos dados consumidos, propagados e produzidos pelos componentes da simulação. A grande vantagem no uso desse modelo advém do esforço de padronização de sua representação, realizado pelo consórcio W3C com o PROV [START_REF] Moreau | Provenance: an introduction to PROV[END_REF]. Ao adotar um modelo genérico de representação, a identificação dos atores das consultas fica facilitada, independente do domínio de dados da aplicação, tornando-se uma abordagem genérica. Outra vantagem dessa representação é que os relacionamentos entre os dados são registrados a partir de identificadores ou valores escalares dos dados científicos que fluem ao longo da execução, o que facilita o seu registro em um SGBD qualquer. Ou seja, ao invés de se inserir todos os dados na base de dados de proveniência, apenas alguns valores são inseridos. Esses dados e seus relacionamentos oferecem um amplo panorama da evolução dos dados e seus relacionamentos decorrentes das etapas de execução. Finalmente, dados de proveniência também são importantes para melhorar as soluções de análise de dados post-mortem e principalmente para a reprodução dos resultados da simulação.

O Projeto Interoperable Design of Extreme-scale Application Software ("IDEAS productivity") é uma iniciativa de 2018 que contempla uma família de projetos, envolvendo

várias instituições e laboratórios nos EUA, preocupados com a complexidade do desenvolvimento de software para aplicações de CSE. O IDEAS visa a "permitir uma atitude fundamentalmente diferente de criar e apoiar aplicações de CSE" com características desejáveis, como proveniência e reprodutibilidade [START_REF] Bernholdt | Improving Reproducibility Through Better Software Practices[END_REF]. Na verdade, os dados de proveniência podem ajudar no registro de opções de parâmetros da simulação. Associá-los aos resultados pode melhorar tanto o ajuste fino quanto as análises de dados em tempo de execução.

São muitas as soluções de análise de dados baseadas no registro dos dados de proveniência [START_REF] Oliveira | Provenance Analytics for Workflow-Based Computational Experiments: A Survey[END_REF]. Para o uso de dados de proveniência na análise de dados, é necessário: um mecanismo de captura de dados; a carga desses dados em uma ferramenta de análise de dados, tipicamente um SGBD; e um mecanismo de consulta. No entanto, tais soluções possuem diversas limitações para o uso em análises de dados ao longo da execução de aplicações de CSE. As duas principais são: (i) a dificuldade em capturar e registrar os dados junto a um ambiente de PAD, ao mesmo tempo em que a simulação é executada, sem prejudicar o desempenho da simulação; e (ii) a limitação aos tipos de análise sobre os dados.

A primeira limitação é que as abordagens de proveniência são em sua grande maioria do tipo post-mortem, com as exceções do Chiron e SciCumulus. Dados são capturados e registrados em arquivos de log para, somente após a execução, estruturá-los e disponibilizá-los para consulta. A segunda limitação é que, por ser um modelo genérico, o poder de análise é limitado a consultas do tipo quais sãos os dados de entrada da segunda etapa da simulação ou quais são os parâmetros ou dados de saída da terceira etapa. Na realidade, uma análise de dados científicos requer mais acesso aos "conteúdos" desses dados, como qual é a média dos valores de A, sendo A um resultado da segunda etapa. Ou ainda quais os arquivos de visualização de dados para a décima iteração da simulação, ou quais os valores de X (valor dentro de um arquivo de saída da terceira etapa) que estão relacionados a valores de A > y. Ao analisar a literatura, não foram encontradas soluções genéricas que permitam a captura e o registro de dados de domínio junto aos dados de proveniência. Realizamos, inclusive um levantamento sobre essa limitação em [START_REF] De Oliveira | How Much Domain Data Should Be in Provenance Databases?[END_REF]. Existe ainda uma outra categoria de consultas durante a execução que requer uma análise ligada ao comportamento do desempenho, como qual é a média do tempo de execução da terceira etapa, considerando que essa etapa é executada em milhares de iterações. Esse tipo de análise permite ao cientista computacional optar por mudar valores de parâmetros que tornem a execução mais curta.

Considerando as características das aplicações de CSE, para que os dados de proveniência sejam efetivamente usados em análises de dados, é necessário que sejam capturados em ambientes de PAD, disponibilizados para consulta durante a execução e que sejam acrescidos de dados de arquivos ou variáveis para favorecer análises mais específicas ao domínio da aplicação. Ainda, para que sejam realizadas consultas sobre o desempenho, os dados sobre a execução também precisam ser capturados, registrados e todos relacionados entre si.

Dessa forma, a análise exploratória de dados científicos envolve comumente três tipos de consultas, que consideram o acesso (i) ao conteúdo dos arquivos de dados científicos, (ii) aos múltiplos arquivos relacionados pelos programas de simulação, e (iii) aos elementos de dados relacionados pelos arquivos. Essas consultas são referenciadas ao longo desta tese pelos seguintes termos, respectivamente, (i) conteúdo de arquivos, (ii) múltiplos arquivos e (iii) elementos de dados relacionados.

A Figura 1 mostra um exemplo que contempla os três tipos de acesso aos dados científicos produzidos por uma simulação no domínio da astronomia, baseando-se no conjunto de ferramentas do Montage [START_REF] Jacob | Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking[END_REF]. O workflow Montage visa construir mosaicos personalizados no formato de arquivo FITS. Na Figura 1, o arquivo de dados de entrada images.tbl contém uma lista de imagens no formato FITS para uma região específica do espaço. A primeira atividade do workflow Montage consome esse arquivo de entrada e gera um conjunto de arquivos do tipo FITS, para cada arquivo que está relacionado ao valor CRVAL1 que é um elemento de dados de images.tbl. A segunda atividade do workflow converte arquivos do tipo FITS em uma extensão específica, chamada HDU, que exige a representação dos dados da imagem em valores inteiros positivos. Em seguida, a terceira atividade realiza transformações lineares gerando projeções de imagens no arquivo projected_images.tbl. Por último, a quarta atividade gera um mosaico da região do espaço no formato JPG. Cada um dos tipos de acesso a dados é descrito a seguir para consultas sobre dados gerados ao longo das atividades do workflow Montage. Exemplo de consulta ao conteúdo de arquivos: O usuário deseja realizar uma consulta que obtém as transformações lineares realizadas pelo programa de projeção, atributos FA e FB (marcados pelos retângulos no arquivo projected_images.tbl), quando o valor do comprimento de onda em um pixel de referência é maior que 210,4218200 (i.e., CRVAL1 > 210,4218200). Para isso, é necessário acessar o arquivo projected_images.tbl, percorrê-lo para encontrar os valores de CRVAL1, FA e FB e verificar a condição CRVAL1 > 210,4218200. Caso o conteúdo do arquivo projected_images.tbl estivesse estruturado dentro de uma base de dados utilizando um Sistema de Gerência de Banco de Dados (SGBD), seria trivial realizar essa consulta.

Exemplo de consulta envolvendo múltiplos arquivos: As setas com a cor preta representam a sequência dos arquivos nos formatos TBL e FITS, que são projetados em outros arquivos TBL e transformados para criar um mosaico no formato de arquivo JPG.

Quando esses relacionamentos são registrados, eles proveem o acesso necessário para a realização das consultas que consideram o rastro dos arquivos intermediários que lidam computacional.

Exemplo de consulta aos elementos de dados relacionados: A Figura 1 mostra o fluxo de elementos de dados científicos em caminhos a serem percorridos por esse tipo de acessopor meio das setas na cor vermelha entre arquivos. Nesse exemplo, o atributo CRVAL1 é usado como chave para relacionar os dados científicos em diferentes arquivos.

Portanto, o arquivo hdu_1n.fits pode ser relacionado ao elemento de dados FB: 0,001969140. Consequentemente, é possível analisar o conteúdo do arquivo Header Data Unit (HDU) (atributo HDU_MATRIX) em relação às transformações lineares (e.g., atributos FA e FB). Por outro lado, sem o apoio ao fluxo de elementos de dados, os usuários teriam que escrever programas para buscar cada valor dessas chaves ao longo do fluxo de arquivos, assim como para relacionar e analisar esses elementos de dados.

Caso o conteúdo de projected_images.tbl estivesse estruturado dentro de um SGBD, seria trivial fazer a consulta que envolve o acesso ao conteúdo do arquivo. No entranto, na maioria dos arquivos de dados científicos, não é viável inserir todos os dados brutos no SGBD. Além disso, muitos desses dados podem não ser nunca consultados. Soluções do tipo NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF] e RAW [START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF] seriam indicadas nesse caso. No entanto, essas soluções não conseguiriam identificar os relacionamentos entre os arquivos, como as relações de dependência ou de associação de elementos de dados. Além disso, não foram encontradas soluções para consultas que envolvem o acesso aos elementos de dados relacionados, muito menos que apoiassem as consultas que envolvem o acesso envolvendo múltiplos arquivos e elementos de dados relacionados ao mesmo tempo.

O estado da arte em soluções para a análise sobre dados científicos se concentra em apoiar as consultas que acessam o conteúdo de arquivos. Não foram encontradas soluções para consultas que acessam elementos de dados relacionados, muito menos que apoiassem as consultas que envolvem múltiplos arquivos e acessam elementos de dados relacionados ao mesmo tempo. As diversas análises da literatura realizadas ao longo desta tese indicaram que as soluções existentes não possibilitam as consultas necessárias para aplicações de CSE [START_REF] Camata | In situ visualization and data analysis for turbidity currents simulation[END_REF], DE OLIVEIRA et al., 2015, OCAÑA et al., 2015, OLIVEIRA et al., 2014, SILVA et al., 2016a, 2016c, 2017b). Por exemplo, soluções focadas na captura de dados de proveniência em simulações computacionais têm se destacado no apoio à análise post-mortem dos dados envolvidos em diferentes etapas de um mesmo programa ou script, porém sem apoio a ambientes PAD, como a ferramenta noWorkflow [START_REF] Murta | noWorkflow: Capturing and Analyzing Provenance of Scripts[END_REF] e a biblioteca Tigres [START_REF] Hendrix | Tigres Workflow Library: Supporting Scientific Pipelines on HPC Systems[END_REF]. Como complicador nesse cenário temos a falta de interação com ferramentas de análise por meio de visualização de dados científicos (e.g., ParaView), complementando as análises via consultas. Somando-se a isso, o grande volume de dados, requer muitas vezes que o dado seja capturado in situ, ou seja, compartilhando o endereço de memória da simulação computacional, não permitindo que o mesmo dado seja movimentado, e muito menos replicado e manipulado em diferentes formatos e meios de armazenamento.

Ademais, os desafios de soluções para a análise de dados científicos ao longo da execução de aplicações de CSE podem ser classificados em: (i) levantamento do tipo de análise de dados desejada; (ii) escolha dos dados a serem monitorados para análise; (iii) modelagem dos relacionamentos desses dados junto aos dados de proveniência; (iv) extração de dados durante a execução para a análise; (v) armazenamento dos dados de forma a serem consultados durante a execução, à medida que são gerados; (vi) mecanismos de acesso eficiente aos dados científicos; e (vii) recursos de consulta a esses dados durante a execução. Aliado a esses desafios, existe o requisito de que a solução de análise de dados não prejudique o desempenho de PAD da aplicação de CSE. A solução proposta nesta tese aborda os sete desafios conforme a seguir.

Como solução proposta nesta tese, foram propostas inicialmente uma abstração teórica para registrar o fluxo de dados da simulação computacional (Seção 3.1) e uma modelagem do fluxo com dados de proveniência (Seção 3.2), permitindo representar os dados científicos gerados pelas simulações computacionais como conjuntos de dados e o processamento computacional de cada etapa da simulação como transformações de dados.

Em seguida, analisou-se o apoio aos dados de proveniência dos SGWfC e foi proposta uma metodologia para viabilizar a realização dos passos (i) a (iii). Além disso, analisou-se os mecanismos de extração de dados científicos (Capítulo 2) e finalmente foi proposta uma arquitetura (Capítulo 4) contemplando (iv) a (vii) para a captura e a análise de dados científicos produzidos por simulações computacionais.

Além desta introdução, esta tese está organizada em outros seis capítulos. O Capítulo 2 apresenta os trabalhos relacionados a esta tese quanto a análise exploratória de dados científicos, considerando os três tipos de acesso aos dados frequentemente realizados nesse contexto. O Capítulo 3 apresenta a fundamentação teórica necessária para o melhor entendimento do restante da tese, abordando os conceitos de fluxo de dados, proveniência

de dados e workflow científico. O Capítulo 4 descreve a abordagem adotada nesta tese para a análise exploratória de dados científicos por meio da abstração de fluxo de dados e a sua primeira instância em um SGWfC. O Capítulo 5 apresenta a implementação da abordagem independente de um SGWfC, considerando as restrições comumentes encontradas em aplicações de CSE. O Capítulo 6 discute os resultados experimentais obtidos a partir de quatro simulações computacionais. O Capítulo 7 conclui esta tese e apresenta as oportunidades de trabalhos futuros nesse tópico de pesquisa.

Capítulo 2 -Análise exploratória de dados científicos

A partir da motivação e do problema de interesse desta tese, este capítulo discute os principais trabalhos relacionados. Mais especificamente, as seções deste capítulo discutem os trabalhos existentes quanto ao apoio aos três tipos de consultas necessárias para a análise exploratória de dados científicos, enfatizando as suas diferenças e as suas limitações.

Apesar do foco ser na análise de dados científicos, este capítulo também discute o processo de captura dos dados científicos ou mesmo da especificação do fluxo de dados, enumerando

as vantagens e as desvantagens dos trabalhos relacionados. Vale ressaltar também que os passos adotados nessa análise da literatura foi baseada em um artigo do tipo survey que já havia sido publicado pelo nosso grupo de pesquisa [START_REF] Mattoso | Dynamic steering of HPC scientific workflows: A survey[END_REF].

Análise de dados científicos em apenas um arquivo

Diversas propostas lidam com a análise de dados científicos em arquivos de forma isolada, mantendo o seu conteúdo no formato original [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF][START_REF] Blanas | Parallel data analysis directly on scientific file formats[END_REF], KIM et al., 2011[START_REF] Ma | Efficient Attribute-Based Data Access in Astronomy Analysis[END_REF][START_REF] Wu | FastBit: interactively searching massive data[END_REF]. Em geral, essas propostas acessam elementos de dados específicos em arquivos (também conhecidos como região de interesse), depois elas indexam esses dados usando linguagens específicas de consulta, máquinas ou APIs (do termo em inglês Application Programming Interface), aliviando assim o esforço de desenvolvimento de códigos para cada tipo de análise. Como exemplos dessa abordagem temos o FastBit [START_REF] Wu | FastBit: interactively searching massive data[END_REF], o Attribute-based Unified Data Access Service (AUDAS) [START_REF] Ma | Efficient Attribute-Based Data Access in Astronomy Analysis[END_REF]), o FastQuery (CHOU et al., 2011), o SDS/Q [START_REF] Dong | SDS: a framework for scientific data services[END_REF] e o AQUAdex [START_REF] Hong | AQUAdex: A Highly Efficient Indexing and Retrieving Method for Astronomical Big Data of Time Series Images[END_REF]. Mais especificamente, o FastQuery e o SDS/Q lidam com a indexação e a consulta de dados de forma paralela, reduzindo o tempo de resposta ao processar consultas, quando comparado com abordagens sequenciais.

Em relação às técnicas de indexação, existem duas propostas de índices largamente utilizadas nessas soluções: bitmap e posicional. A indexação baseada em um mapa de bits, conhecida como indexação bitmap, consiste na análise do domínio de determinados atributos presentes em arquivos de dados científicos para gerar índices booleanos por meio da verificação de equações algébricas. Por exemplo, assumindo-se que os valores do atributo X para todos os arquivos de dados científicos apresentam um domínio com apenas quatro valores possíveis, assumindo-se uma estrutura de dados de números inteiros, então o mapa de bits necessita de quatro colunas para avaliar a presença ou não de um determinado valor, assumindo-se uma equação de equidade, conforme apresentado na Tabela 1. Existem casos também em que o uso de inequações para a indexação bitmap é mais vantajoso. Por exemplo, no caso de números em ponto flutuante com um domínio muito extenso, o uso de inequações pode favorecer tanto a geração de índices (menor número de colunas de bits no mapa), como consultas que buscam um determinado intervalo de valores para o atributo indexado (restrição do espaço de busca pelos índices gerados). Como tecnologias que empregam a indexação bitmap, pode-se citar o FastBit [START_REF] Wu | FastBit: interactively searching massive data[END_REF], o FastQuery [START_REF] Chou | FastQuery: A Parallel Indexing System for Scientific Data[END_REF] e o SDS/Q [START_REF] Dong | SDS: a framework for scientific data services[END_REF]. O SDS/Q executa consultas diretamente sobre arquivos, eliminando a sobrecarga relacionada à conversão da estrutura de dados do conteúdo bruto e a sua carga em uma estrutura de dados diferente. No que diz respeito à execução paralela, o SDS/Q explora os recursos providos pelo uso da memória volátil, uma vez que ele emprega a indexação bitmap (ELMASRI e NAVATHE, 2010) e o processamento de consultas em memória. Ele também apresenta melhorias de desempenho no processamento de consultas pelo uso de técnicas para paralelizar a execução intra-e inter-nós, além de implementar índices bitmap usando o FastBit. Por outro lado, a sua máquina é restrita ao formato de arquivo HDF5.

Outra proposta presente em trabalhos mais recentes sobre a indexação de dados científicos considera a geração de índices posicionais. De uma forma simplificada, esses índices utilizam informações que facilitam a localização (i.e., posição) dos dados científicos nos arquivos. Por exemplo, um índice posicional pode ser o bit, em que o valor de um determinado atributo precisa começar a ser lido do arquivo. Comparando-se esse tipo de índice com o mapa de bits gerado pela indexação bitmap, os índices posicionais tendem a fornecer uma sobrecarga de dados menor para a gerência dos dados científicos, pois, diferentemente do índice bitmap, este não cria bits redundantes (i.e., sequência de zeros no mapa de bits) que crescem de acordo com o aumento do domínio dos atributos indexados (i.e., aumento do número de colunas a serem representadas no mapa de bits). Como exemplos de sistemas que empregam índices posicionais, pode-se citar o NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF] e o RAW [START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF].

O NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF] propõe a extração de conteúdo específico presente em arquivos de dados científicos e a sua carga em uma versão modificada do SGBD relacional PostgreSQL, conhecido como PostgresRaw. Apesar de evitar mudanças nas estruturas originais dos dados científicos, o NoDB baseia-se no processamento de consultas adaptativas, que utiliza estatísticas e estratégias de caching para ter acesso aos dados científicos e realizar as transformações de dados estritamente necessárias. [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF] apresentam melhorias de desempenho significativas ao utilizar o NoDB, uma vez que apenas os dados científicos necessários pelas consultas são efetivamente indexados.

Entretanto, como limitação, o NoDB realiza a carga dos dados científicos acessados no PostgresRaw, o que caracteriza uma sobrecarga de armazenamento dos dados em um repositório usando outras estruturas de dados (i.e., estruturas de dados que podem ser diferentes das adotadas no arquivo com dados científicos).

Para lidar com essas limitações, o mesmo grupo de pesquisa propôs o RAW [START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF], uma máquina de processamento de consulta que adapta o plano de execução das consultas para os formatos dos dados científicos, sem apresentar a sobrecarga de armazenar os dados científicos em outro repositório externo ou base de dados.

Essa abordagem é similar ao SDS/Q, ao mesmo tempo em que não é restrita a apenas um formato de arquivo. Em relação ao seu desenvolvimento, o RAW implementa caminhos para acesso aos dados durante a execução da consulta (conhecidos pelo termo em inglês, just-in-time access paths), assim como apresenta heurísticas para selecionar as colunas relevantes para a consulta desejada. A proposta dos caminhos de acesso considera a geração deles em tempo de execução para direcionar o mapeamento dos operadores de varredura aos dados científicos no plano de execução da consulta. Além disso, o RAW busca adiantar o máximo possível as operações de seleção de elementos de dados no plano de execução da consulta.

Com outra técnica de indexação, o AQUAdex (Accelerating Query Using Area pixelization indexing) [START_REF] Hong | AQUAdex: A Highly Efficient Indexing and Retrieving Method for Astronomical Big Data of Time Series Images[END_REF] propõe a indexação e a recuperação de séries temporais de imagens a partir de conjuntos de dados astronômicos, tendo como motivação a descoberta de imagens presentes em uma região específica do espaço e capturadas em um determinado intervalo de tempo. Para isso, o AQUAdex realiza o acesso, a extração e a indexação espacial de arquivos no formato FITS que foi construída com base no HEALPix1 

(Hierarchical Equal Area isoLatitude Pixelization of a sphere), para realizar análises em séries temporais.

Recentemente, o AQUAdex propôs uma extensão da sua proposta original a fim de reduzir a sobrecarga em termos de tempo de processamento por carregar os índices e outros metadados em uma base de dados e eventuais operações que envolviam o uso de disco. Essa extensão, conhecida como AQUAdexIM (AQUAdex In-Memory) [START_REF] Hong | AQUAdexIM: highly efficient in-memory indexing and querying of astronomy time series images[END_REF], tira proveito de dados já alocados em memória pela simulação computacional para realizar a indexação dos dados e o processamento de consultas por meio do uso da memória principal.

Além disso, algumas otimizações foram realizadas em suas estruturas de dados para a redução do custo no processamento de consultas, como o uso de mapas baseados em uma função hash por meio da estrutura de dados HashMap. Por outro lado, ambas as propostas, AQUAdex e AQUAdexIM, apresentam limitações quanto ao apoio à indexação de apenas um formato de arquivo e o processador de consultas não considera análises que envolvem elementos de dados de diferentes transformações de dados da simulação computacional.

A partir de outra abordagem, o SimDB (LUSTOSA, 2015) consiste em um sistema para otimizar o armazenamento de malhas a partir de uma estrutura de dados baseada em octrees utilizando o SciDB (BROWN, 2010), considerando dados de simulação em larga escala representados por matrizes e malhas. O SimDB apresenta como principais contribuições a redução de células sem conteúdo no armazenamento de dados pelo SciDB, em função da representação dos dados em octrees; um melhor desempenho no processamento de consultas que não cabem em memória, quando comparado com outros SGBD; e a integração com o ParaView [START_REF] Ayachit | The ParaView guide: updated for ParaView version 4.3[END_REF], permitindo análises visuais de resultados de consultas por parte do usuário. Nesse mesmo grupo de pesquisa, o DEXL, do Laboratório Nacional de Computação Científica2 (LNCC), pode-se observar outro trabalho que argumenta a importância do uso de bases de dados probabilísticas para a gerência de dados científicos de natureza incerta (GONÇALVES e PORTO, 2014).

Entretanto, pelo fato desses trabalhos serem focados em arquivos "isolados", eles não permitem análises sobre o fluxo de dados. Para que o fluxo de dados fosse representado nos SGBD adaptados aos dados científicos, os programas de simulação, que geram os dados científicos, teriam que ser reescritos, mudando todo o seu acesso às estruturas de dados de acordo com a implementação do SGBD, algo que não seria viável no panorama atual de programas de simulação computacional, em função do esforço de desenvolvimento e desses programas serem vistos, em várias circunstâncias, como caixas-pretas (ou seja, código privado e inacessível). A outra alternativa seria manter os dados em seus formatos originais e replicá-los nos sistemas de gerência e análise de dados científicos, algo que não se mostrou efetivo na experiência do NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF], nem parece compatível com a larga escala de dados no contexto de processamento de dados in situ, em sintonia com os sistemas de simulação computacional [START_REF] Kim | Parallel in situ indexing for dataintensive computing[END_REF].

Dessa forma, os trabalhos existentes não consideram a análise do fluxo dos elementos de dados a partir da execução dos programas de simulação que produzem arquivos, cujo conteúdo deve ser acessado, extraído, indexado e consultado ao final da simulação computacional. Para apoiar a análise do fluxo de dados, essas propostas precisariam permitir a gerência dos diversos arquivos envolvidos e dos elementos de dados relacionados pelos programas de simulação. No que diz respeito às simulações computacionais, esta tese apoia aplicações que acompanham a execução escalável de problemas de CFD difíceis, como em (KIM et al., 2011), em que aplicam-se otimizações em estruturas octrees adaptativas para modelos computacionais otimizados que executam com milhares de núcleos computacionais (do termo em inglês cores) em cálculos baseados em Equações Diferenciais Parciais (EDP) não lineares, heterogêneas e mal condicionadas.

Análise de múltiplos arquivos

As abordagens para a gerência do fluxo de arquivos têm como meta o apoio às transformações de dados pelo sistema de arquivos, ignorando os conteúdos específicos do domínio presentes nos arquivos. Por consequência, essa abordagem trata os arquivos como caixas-pretas, uma vez que não apresentam índices para os dados científicos ou apoio às consultas para os conteúdos dos arquivos de dados científicos. Considerando esse assunto, [START_REF] Vahi | Rethinking Data Management for Big Data Scientific Workflows[END_REF] propõem duas abordagens baseadas no armazenamento de dados, em que os usuários do domínio científico não precisam modificar seus programas para armazenar os dados produzidos em dispositivos de armazenamento.

A primeira abordagem considera o armazenamento de objetos, que se caracteriza pela captura de todos os arquivos consumidos e produzidos na simulação computacional.

Desse modo, essa solução permite gerenciar os arquivos manipulados em tempo de execução de forma distribuída, em que os arquivos necessários são requisitados ao mecanismo de armazenamento de objetos. Já a segunda abordagem é baseada em um sistema de arquivos compartilhados para armazenar os arquivos manipulados em tempo de execução, também utilizando dispositivos de armazenamento de objetos.

Nesse trabalho de Vahi et al. (2013), as simulações computacionais foram executadas em um ambiente de nuvem computacional (Amazon EC2), considerando uma simulação no domínio da astronomia (i.e., Montage) caracterizada por muitas operações de entrada e saída (i.e., centrada em dados) e outra centrada em CPU (i.e., Rosetta). Os resultados apresentaram um desempenho melhor para o sistema de arquivos compartilhados em comparação com o sistema de arquivos distribuídos devido ao custo de comunicação, ou seja, o custo de transferência de arquivos entre recursos computacionais.

Ademais, o arcabouço AWARD [START_REF] Assuncao | Autonomic Activities in the Execution of Scientific Workflows: Evaluation of the AWARD Framework[END_REF] provê uma solução baseada no fluxo de dados por meio de uma representação orientada a tuplas para gerenciar a execução de simulações computacionais. Esse arcabouço apoia a distribuição dos dados em diferentes centros de dados (i.e., diferentes regiões espaciais). Assim, para controlar a execução da simulação, o AWARD captura as tuplas (conjunto de valores de parâmetros) em tempo de execução e gerencia a responsabilidade de propagação dos dados entre os programas de simulação de acordo com as dependências de dados existentes (i.e., transferência de dados entre centros de dados). Entretanto, a integração do AWARD com uma base de dados de proveniência não é trivial, pois esse arcabouço apresenta um esquema fixo e qualquer mudança para inserir novos metadados requer modificações substanciais na sua máquina. Logo, na perspectiva da gerência do fluxo de arquivos, o AWARD permite que as referências para os arquivos consumidos e produzidos em cada transformação de dados sejam representadas como valores de parâmetros nas tuplas.

Dessa forma, nenhuma dessas soluções considera a gerência do fluxo dos elementos de dados no contexto da análise exploratória de dados científicos. Apesar de representar os valores dos parâmetros, o AWARD não lida com valores de parâmetros como elementos de dados na sua representação relacional, o que inviabiliza a reconstrução do fluxo de dados nesse nível de abstração. Além disso, nenhuma dessas soluções discute a captura de dados científicos presentes em arquivos produzidos pelos programas de simulação.

Análise de elementos de dados relacionados pelos arquivos

Os Sistemas de Gerência de Workflows Científicos (SGWfC), apresentados formalmente na Seção 3. Diante desses trabalhos relacionados à análise do fluxo de elementos de dados, observa-se que eles estão inseridos em dois cenários distintos. Primeiramente, temos as soluções baseadas em SGWfC, que assumem que os programas de simulação são caixaspretas e precisam ser invocados de forma paralela em ambientes de PAD, variando-se os valores dos atributos de entradas. Nesse caso, os dados de proveniência são capturados respeitando-se a estrutura do workflow modelado e não exigem um esforço adicional do ponto de vista de instrumentação do código fonte dos programas de simulação. Por outro lado, essas soluções exigem um conhecimento dos usuários para modelar os workflows científicos e os SGWfC apresentam limitações para apoiar os três tipos de consultas na análise exploratória de dados científicos.

Enquanto isso, outras ferramentas e bibliotecas têm sido propostas para permitir a captura de dados de proveniência por meio da instrumentação ou a análise dos dados manipulados pelos scripts em tempo de execução. Nesse cenário, os usuários têm acesso ao conteúdo dos scripts para poder ajustá-los e extrair os dados científicos de interesse.

Contudo, essas ferramentas comumente apresentam limitações relacionadas ao fato de serem exclusivas para uma linguagem de programação, de apresentarem um grafo de proveniência muito detalhado quando são pouco intrusivas no código fonte, de não terem apoio à execução paralela em ambientes de PAD ou mesmo à captura de dados científicos em arquivos. Por outro lado, elas apresentam contribuições quanto à análise do fluxo dos elementos de dados, considerando a gerência da proveniência dos dados.

Análise global da literatura

Somando-se às análises pontuais de cada categoria de soluções existentes, realizadas nas seções anteriores, esta seção apresenta uma análise mais global da literatura. Diante dessa realidade, esta tese visa propor uma solução focada na captura e na análise de dados científicos ao longo da execução de simulações. Mais especificamente, considera-se uma abordagem que permita apoiar os três tipos de consultas discutidos para a análise exploratória de dados científicos, sendo que nenhum dos sistemas estudados permitem análises baseadas em todos os tipos de consultas. Tais consultas almejam acessar (i) o conteúdo de arquivos de dados científicos, (ii) múltiplos arquivos relacionados pelas etapas da simulação e (iii) elementos de dados relacionados pelos múltiplos arquivos.

Capítulo 3 -Referencial teórico

Esse capítulo tem o propósito de apresentar a fundamentação teórica para melhor compreensão desta tese. Por isso, os conceitos de fluxo de dados, proveniência e workflows científicos são definidos formalmente. Ao mesmo tempo, o SGWfC SCC (SciCumulus + Chiron) é apresentado em detalhes na Seção 3.3.4 pelo fato dele ser usado no desenvolvimento dos primeiros experimentos desta tese. Ademais, as abordagens existentes para a captura e a análise de dados científicos são descritas nesse capítulo para facilitar a compreensão do cenário alvo desta tese.

Fluxo de dados

Esta tese assume a abstração de fluxo de dados para permitir a gerência dos dados científicos e dos seus relacionamentos ao longo da execução de simulações computacionais.

Essa abstração adotada foi adaptada de um formalismo já proposto por [START_REF] Ikeda | Logical provenance in data-oriented workflows?[END_REF] para o cenário de workflows científicos, a fim de atender à nossa nomenclatura e ser mais direcionada ao fluxo de elementos de dados. Nesta seção, apresentamos uma definição formal de fluxo de dados (Subseção 3.1.1) e os dois níveis existentes para a gerência de fluxos de dados (Subseção 3.1.2).

Definição

Na abstração do fluxo de dados, a menor unidade de interesse consiste em um elemento de dados (Definição 3.1.1) que apresenta uma sequência de valores para os atributos predefinidos no conjunto de dados ao qual esse elemento de dados pertence.

Assim, um conjunto de dados apresenta uma sequência de atributos, de modo que o i-ésimo valor de um elemento de dados corresponde ao i-ésimo atributo desse conjunto. Um conjunto de elementos de dados consiste em uma coleção de dados (Definição 3.1.2), sendo que um conjunto de dados (Definição 3.1.3) é composto por coleções de dados e por uma sequência de atributos. Além disso, uma transformação de dados (ou, de forma abreviada, transformação) (Definição 3.1.4) realiza o processamento de dados baseado em procedimentos de um algoritmo ou modelo computacional, consumindo dados de um ou mais conjuntos de dados como entrada e produzindo um ou mais conjuntos de dados como saída. Ao mesmo tempo, as transformações podem apresentar dependências de dados (Definição 3.1.5) entre si em função de um conjunto de dados, que é produzido por uma transformação de dados e consumido por outra transformação de dados. A partir desses conceitos, um fluxo de dados (Definição 3.1.6) é definido pela composição de transformações de dados, manipulando conjuntos de dados e respeitando as dependências de dados dessa composição.

De forma semelhante, essa especificação de fluxo de dados pode ser representada por um grafo direcionado 𝐺 = (𝑉, 𝐸), em que os vértices 𝑉 correspondem às transformações de dados, e as arestas 𝐸 correspondem aos conjuntos de dados. Uma transformação de dados pode ser instanciada de acordo com o consumo de um subconjunto de suas coleções de dados de entrada e a produção de um subconjunto de suas coleções de dados de saída, sendo este conceito definido como instância de uma transformação de dados (Definição 3.1.7). Em outras abstrações, o conceito de instância de uma transformação de dados é conhecido como tarefa. Vale ressaltar que as definições adotam as letras maiúsculas para representar um conjunto ou uma sequência de entidades (e.g., 𝑇 representa um conjunto de transformações de dados), enquanto que uma instância de uma entidade é representada em letra minúscula (e.g., 𝑡 representa uma transformação de dados).

Como exceção temos a representação de fluxo de dados, que é descrito por uma letra maiúscula, isto é, 𝐷 𝐹 . manipulados pela transformação de dados 𝑡. OCCURRENCE que representam a ocorrência de uma palavra no arquivo investigado, e 𝑠 3 possui a sequência de atributos WORD e COUNT que representam o número de vezes que cada palavra esteve presente em todos os arquivos de entrada. A Figura 2 apresenta esse exemplo de fluxo de dados, assim como a representação de cada conceito (transformação de dados, conjunto de dados, dependência, atributos, entre outros) de acordo com as definições apresentadas.

Gerência do fluxo de dados

Somando-se às questões de especificação formal do fluxo de dados, as soluções precisam ser capazes de gerenciar o fluxo adotado pelos dados consumidos e produzidos por cada transformação de dados durante a sua execução. Semelhante aos tópicos discutidos no Capítulo 2, discutimos o potencial analítico associado à gerência do fluxo de dados em SILVA et al. (2016). Ademais, definimos nesse artigo dois níveis de abstração para apoiar a gerência do fluxo de dadosi.e., físico e lógico -, sendo que eles fazem parte das principais contribuições desta tese.

A gerência do fluxo de dados no nível físico consiste no apoio às transformações de dados no nível do sistema de arquivos. Logo, as transformações de dados são analisadas apenas em relação ao consumo e à produção de arquivos por cada programa de simulação, sem considerar o conteúdo de arquivos específicos do domínio da simulação. Nessa mesma perspectiva, esse nível de gerência do fluxo de dados trata os arquivos como caixas-pretas, uma vez que não existem índices ou apoio a consulta com acesso aos dados científicos presentes nesses arquivos. Consequentemente, as análises oferecidas aos usuários do domínio científico ficam restritas a ponteiros para os arquivos envolvidos no fluxo de dados, sendo necessário que eles analisem cada arquivo individualmente ou desenvolvam programas específicos para ter acesso aos dados científicos presentes nos arquivos. Em ambas as alternativas para a análise específica de domínio, os usuários apresentam tarefas que são propensas a erros e serão capazes de realizar apenas um tipo de análise. Já a gerência do fluxo de dados no nível lógico lida com o monitoramento de como os elementos de dados são consumidos, produzidos e propagados pelos programas de simulação. Esses elementos de dados contemplam tanto os conteúdos de arquivos de dados científicos, como a propagação de dados pelos programas de simulação. A partir do monitoramento dos elementos de dados, os seus relacionamentos podem ser utilizados para reconstruir o fluxo de dados, agregando valor ao potencial analítico desse nível de gerência.

Do ponto de vista dos usuários do domínio científico, eles podem realizar consultas direcionadas aos aspectos do domínio da simulação computacional, sem precisar do desenvolvimento de programas específicos para os arquivos de dados científicos, como 

𝐷 𝐹 = 𝑇, 𝑆, Φ 𝑇 = 𝑡 1 , 𝑡 2 𝑆 = 𝑠 1 , 𝑠 2 , 𝑠 3 𝜑 = 𝑠 2 , 𝑡 1 , 𝑡 2 𝑡 1 = 𝑠 1 , 𝑠 2 𝑡 2 = 𝑠 2 , 𝑠 3
constatado na gerência do fluxo de dados no nível físico. Por outro lado, o custo computacional é maior para a gerência no nível lógico devido a sua granularidade mais fina, em que os elementos de dados precisam ser capturados e monitorados em tempo de execução.

Ainda em relação ao nível lógico, ele pode ser dividido em fluxo de elemento de dados e fluxo de coleção de dados. O fluxo de elemento de dados representa as transformações em um elemento de dados ao longo da execução do fluxo de dados por meio de diferentes programas em uma simulação computacional. Nesta tese, define-se que um elemento de dados é um item de dado que apresenta uma sequência de valores, sendo que o valor na i-ésima posição corresponde ao atributo na i-ésima posição da sequência de atributos do conjunto de dados ao qual o elemento de dados pertence. Já o fluxo de coleção de dados rastreia o conteúdo específico do domínio que pode ser organizado como uma coleção de dados, ou seja, representado por dois ou mais elementos de dados.

Proveniência

Apesar das definições relacionadas à abstração do fluxo de dados, a proveniência de dados é que efetivamente permite o registro do histórico das transformações de dados, especificando quando uma determinada transformação foi instanciada, quais coleções de dados foram consumidas e produzidas, entre outras informações relacionadas à execução.

Nesse sentido, apoiar a gerência da proveniência de uma forma correta, precisa e mínima atrelada à abstração de fluxo de dados é essencial para garantir o potencial analítico no contexto desta tese. Sendo assim, esta seção apresenta as noções de proveniência de dados.

Definição

Como apresentado por Buneman et al. (2001), a proveniência de dados pode ser definida pela "descrição das origens de uma porção de dados e do processo pelo qual ela alcança uma base de dados" (tradução da seguinte passagem do texto em inglês "the description of the origins of a piece of data and the process by which it arrived in a database"). Nesse contexto, a gerência da proveniência dos dados pode ser baseada em duas granularidades, sendo conhecidas como proveniência em granularidade grossa e fina [START_REF] Freire | Provenance for Computational Tasks: A Survey[END_REF]. A proveniência em granularidade grossa é definida pela descrição das origens de uma porção de dados de acordo com as operações do conjunto de dados. Ou seja, a proveniência em granularidade grossa compreende a gerência das transformações de dados a partir de uma visão geral de consumo e produção de conjuntos de dados, sem considerar a gerência do fluxo de dados no nível lógico. Como proveniência em granularidade fina, pode-se definir que os dados de proveniência são capturados em relação às derivações dos elementos de dados em cada transformação de dados. Logo, essa granularidade considera as transformações de dados do ponto de vista do fluxo de elementos ou de coleções de dados.

Para permitir a padronização, o compartilhamento e a interoperabilidade de dados de proveniência, diferentes grupos, como o World Wide Web Consortium (W3C), têm proposto modelos de dados que consistem em uma representação de como os dados de proveniência devem ser capturados e armazenados em uma base de dados. A partir da aplicação de domínio, um modelo de dados de proveniência pode ser integrado a artefatos que estão associados ao domínio da simulação computacional. Como um exemplo, o PROV-DM (MOREAU e GROTH, 2013) é uma iniciativa do W3C PROV para representar diferentes tipos de dados de proveniência de forma a não ser específico para apenas um domínio. No cenário de simulações computacionais, o PROV-Df (SILVA et al., 2016c) é nesta tese (Seção 4.4) como um modelo de dados baseado nas recomendações do PROV-DM para capturar e consultar dados de proveniência e dados específicos do domínio em um mesmo repositório durante a execução de simulações computacionais, permitindo que dados de domínio possam ser relacionados aos dados de proveniência e, consequentemente, a análise do fluxo de dados no nível lógico.

Propriedades da proveniência

Uma especificação de proveniência de dados precisa apoiar três propriedades básicas conhecidas como corretude, precisão e minimalidade, para que os usuários sejam capazes de analisar o histórico das transformações de dados em simulações computacionais de uma forma correta e mínima. Nesse sentido, uma proveniência de dados é dita correta, quando ela apresenta todos os elementos de dados de entradas envolvidos na produção de um elemento de dados de saída específico em uma determinada transformação de dados (Definição 3.2.1). Uma proveniência de dados é mais precisa que outra, quando os seus elementos de dados estão contidos no conjunto de elementos de dados da outra proveniência (Definição 3.2.2). Consequentemente, uma proveniência é mínima, quando não existe outra proveniência correta tão precisa quanto ela (Definição 3.2.3). Esses conceitos foram propostos originalmente no trabalho de Ikeda et al. (2013) , onde 𝑝𝑟𝑜𝑣 𝑡 (𝑒) é a proveniência em apenas um nível de 𝑒 com relação às instâncias de 𝑡. Se 𝑒 é um elemento de dados de entrada, então 𝑝𝑟𝑜𝑣 𝐷 𝐹 (𝑒) = {𝑒}.

Categorias de dados de proveniência

Considerando os diversos aspectos do processamento de dados, existem duas categorias de proveniência: prospectiva e retrospectiva. A proveniência prospectiva tem o objetivo de apresentar uma visão geral sobre a composição do fluxo de dados, uma vez que ela descreve os componentes estruturais do fluxo de dados (e.g., transformações de dados, os seus conjuntos de dados e as suas dependências). Desse modo, o uso dos dados dessa categoria permite apenas verificar a representação ou a especificação do fluxo de dados. Ou seja, as análises são restritas a quais são as transformações de dados definidas na simulação computacional, assim como quais conjuntos são consumidos e produzidos por cada transformação em um nível mais abstrato (e.g., nome do conjunto de dados, sem considerar os elementos de dados). Consequentemente, os usuários do domínio científico não são capazes de analisar informações associadas à execução das transformações (e.g., o tempo de execução de um programa e a linha de comando para a invocação desse programa).

A proveniência retrospectiva, por outro lado, captura informações sobre os dados processados durante a execução de cada transformação de dados, como o tempo decorrido para uma transformação de dados específica, os arquivos consumidos por cada transformação de dados, ou mesmo o diretório em que acontece a invocação de uma transformação de dados. Outra característica consiste em permitir que os usuários do domínio científico monitorem o desempenho, assim como os dados de domínio manipulados por uma instância de uma transformação de dados em tempo de execução.

Além disso, os usuários podem utilizar esses dados de proveniência retrospectiva para realizar análises mais aprofundadas quanto à simulação computacional executada, a fim de validar suas hipóteses científicas.

Em alguns casos, os resultados obtidos pelos programas de simulação, sejam eles dados específicos do domínio ou de desempenho, podem não apresentar o comportamento esperado do ponto de vista científico. Assim, os usuários do domínio precisam interagir com os especialistas em ciência da computação para realizar ajustes na própria configuração do fluxo de dados ou abortar a execução da simulação, caso ela ainda não tenha sido finalizada [START_REF] Mattoso | User-steering of HPC workflows: state-of-the-art and future directions[END_REF]. Após tais ajustes e novas submissões de execução da simulação, eles conseguiriam analisar e validar os novos resultados obtidos. Nesse sentido, diversos estudos têm sido desenvolvidos para destacar a importância da intervenção humana no processo exploratório de simulações computacionais a partir dos dados de proveniência.

Esta proposta de trabalho é conhecida pelo termo putting the Human-In-the-Loop (HIL) (W.F.J., 2007), que faz uma alusão ao processo de inserir o ser humano nesse desenvolvimento iterativo. Para que isso seja possível, os dados de proveniência são imprescindíveis para garantir a rastreabilidade, a confiabilidade e a reprodutibilidade das simulações computacionais, em especial os associados à proveniência retrospectiva.

Rastro de proveniência

No cenário de fluxo de dados, os dados de proveniência podem ser capturados durante a execução das transformações de dados, de forma que rastro de proveniência seja registrado. Diante dessas definições, a função 𝑝𝑟𝑜𝑣 𝑡 (𝑒), que analisa a proveniência de um elemento de dados, investiga o mapeamento de múltiplos atributos na transformação de dados 𝑡, define quais atributos apresentam relação entre o consumo e a produção de dados, e identifica, por meio desse mapeamento, quais elementos de dados de entrada foram responsáveis pela produção de 𝑒. Esse comportamento seria semelhante ao uso dos atributos do mapeamento como atributos de equidade ao realizar a junção (operação da álgebra relacional) entre um conjunto de dados de entrada e um conjunto de dados de saída para uma determinada transformação, realizando a projeção apenas dos elementos de dados de entrada. De forma semelhante, os resultados dessas junções poderiam ser utilizados em outras operações de junções com conjuntos de dados manipulados por outras transformações de dados. Assim, essa proposta seria capaz de analisar a proveniência do fluxo de dados e, consequentemente, de apoiar a análise de elementos de dados relacionados por múltiplas transformações de dados. 

Análise de dados de proveniência

A partir dos conceitos apresentados nas subseções anteriores, essa subseção discute o potencial analítico ao capturar dados de proveniência, assumindo-se que os dados científicos sejam acessíveis (e.g., uso de ferramentas alternativas para capturar tais dados armazenados frequentemente em arquivos -FastBit). Tais potenciais e benefícios de utilizar dados de proveniência são discutidos no estudo proposto por [START_REF] Mattoso | Dynamic steering of HPC scientific workflows: A survey[END_REF]. Nessa linha, quatro tipos de análises de dados de proveniência são discutidos nessa seção, sendo os seguintes: monitoramento, awareness, depuração e investigação de dados de domínio.

O monitoramento da execução do fluxo de dados baseia-se no processo de verificar o estado da execução em um determinado momento da simulação computacional para identificar se ocorreu (ou está ocorrendo) algum comportamento específico (MATTOSO et al., 2015). Para que seja possível apoiar esse tipo de análise, os componentes responsáveis pelo monitoramento dependem do sistema de fluxo de dados. Em função dessa análise ser realizada em tempo de execução, a ferramenta de monitoramento precisa coletar os dados durante a condução da simulação computacional. Se considerarmos um caso real, espera-se que, com essas informações, os usuários do domínio científico sejam capazes de analisar comportamentos inesperados em tempo de execução.

Diferentemente do monitoramento, que é caracterizado por atuar de uma forma mais passiva, as análises de awareness visam informar o estado atual da execução da simulação computacional (e do fluxo de dados gerado) aos usuários do domínio científico, a fim de que eles possam planejar ações por meio do rastro dos dados de proveniência. Essas ações são normalmente baseadas em consultas, a fim de permitir que os usuários do domínio científico com o auxílio de especialistas em ciência da computação evitem falhas, antecipem problemas ou melhorem os resultados. No caso das melhorias dos resultados específicos do domínio, eles podem realizar refinamentos na composição do fluxo de dados (i.e., na sua estrutura) ou ajustes finos nos elementos de dados (i.e., valores assumidos para atributos específicos do domínio da simulação computacional).

As análises de depuração são caracterizadas pela avaliação de resultados que, por meio de métricas, descrevem se o sistema está apresentando o comportamento esperado durante a execução do fluxo de dados. As métricas para depuração precisam ser definidas, coletadas e salvas durante a execução do fluxo de dados, a fim de que os cientistas possam melhorar o desempenho do sistema para a execução paralela e resolver eventuais falhas relacionadas ao próprio fluxo de dados.

Por último, as análises com dados de domínio investigam o conteúdo dos elementos de dados de saída, relacionando-os com outros tipos de dados de proveniência. Nesse caso, os usuários estão normalmente dedicados a verificar um fragmento de conjunto de dados referentes ao domínio da simulação (i.e., seleção de elementos de dados). Em cenários mais complexos, eles desejam investigar esse fragmento rastreando as suas origens e a sua evolução ao longo da simulação computacional (i.e., junção de conjuntos de dados). A partir de análises minuciosas, os usuários são capazes de compreender o comportamento de um fragmento específico em um determinado domínio da ciência, restringindo a sua análise apenas aos atributos de interesse (i.e., projeção de atributos em um conjunto de dados). De acordo com a conclusão obtida, eles ainda conseguem sugerir ajustes nos elementos de dados de domínio, para que os resultados irrelevantes sejam filtrados, reduzindo a quantidade de dados intermediários analisados ao longo do fluxo de dados.

A investigação de dados de domínio também pode utilizar dados de proveniência associados às informações da execução da simulação computacional, o que potencializa a capacidade analítica. Nessa circunstância, vale destacar a importância de um modelo de dados de proveniência capaz de integrar esses diferentes tipos de dados (Seção 3.2.1) [START_REF] De Oliveira | How Much Domain Data Should Be in Provenance Databases?[END_REF], OCAÑA et al., 2015, SILVA et al., 2016b[START_REF] Souza | Monitoramento de Desempenho usando Dados de Proveniência e de Domínio durante a Execução de Aplicações Científicas[END_REF].

Workflow Científico

Outra forma de lidar com a complexidade das simulações computacionais em larga escala consiste na sua modelagem como workflows científicos [START_REF] Deelman | Workflows and e-Science: An overview of workflow system features and capabilities[END_REF].

Workflows científicos estendem o conceito original de workflows. Workflows são tradicionalmente vistos como a definição do processo para a criação, o armazenamento, o compartilhamento e a revisão da informação. Analogamente, workflow científico é um método de abstração e sistematização do processo experimental ou de parte dele (DIAS et al., 2015). Esta seção tem o propósito de apresentar uma definição de workflow científico no cenário de simulação computacional, assim como detalhes sobre o funcionamento de Sistemas de Gerência de Workflows Científicos (SGWfC) e os seus recursos para o monitoramento da execução de simulações computacionais.

Definição

Um workflow científico é definido pelo encadeamento de atividades responsáveis pela invocação de programas de simulação, onde o encadeamento de duas atividades descreve uma dependência de dados entre elas, ou seja, os dados produzidos por um programa são consumidos por outro. De forma análoga, um workflow científico pode ser representado por um fluxo de dados, em que as atividades correspondem às transformações de dados e as dependências de dados correspondem ao fluxo de dados entre duas transformações de dados. SILVA et al., 2016b[START_REF] Souza | Monitoramento de Desempenho usando Dados de Proveniência e de Domínio durante a Execução de Aplicações Científicas[END_REF] foi desenvolvido e integrado ao SCC com o objetivo de integrar dados de proveniência em granularidade fina com informações de desempenho e de consumo de recursos computacionais (e.g., consumo de CPU, quantidade de dados alocados em memória e número de operações de entrada e saída).

SGWfC SCC

Desenvolvido pelos grupos de pesquisa de Computação de Alto Desempenho e Banco de Dados A partir da especificação da SciWfA, pode-se observar que uma ativação no SCC é mais que simplesmente a invocação de uma transformação de dados. De fato, ela é caracterizada por três procedimentos: instrumentação, invocação e extração [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF]. Antes da execução do workflow científico, os usuários definem o esquema dos conjuntos de dados de entrada e saída para todas as transformações de dados. Na instrumentação, os elementos de dados de entrada são obtidos e a invocação do programa de simulação é preparada de acordo o esquema dos dados de entrada. Após isso, a invocação de uma ativação consiste em chamar um programa de simulação em um determinado recurso computacional, consumindo os elementos de dados de entrada definidos na instrumentação e produzindo elementos de dados de saída. Como último procedimento, a extração realiza a captura de dados produzidos pelos programas de simulação para serem representados em relações. Mais detalhes sobre a definição formal de ativação podem ser encontrados em [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF].

Vale ressaltar que outros dados de proveniência também são capturados durante os procedimentos de uma ativação e podem ser utilizados para apoiar os cientistas em diversas análises. Como exemplos de análises, podemos citar as seguintes questões:

• Existe alguma ativação que ainda esteja executando?

• Algum erro foi constatado nas ativações? Se positivo, qual foi o código do erro observado e a sua mensagem?

• Quanto tempo uma ativação necessita, em média, para executar com sucesso um determinado programa de simulação?

• Existe alguma anomalia associada ao uso dos recursos computacionais?

Mais importante que isso, os dados de proveniência associados aos dados de domínio conseguem auxiliar os usuários na depuração de programas (i.e., dados de desempenho ou erros em função dos valores de atributos do domínio). Isso viabiliza análise mais ricas em tempo de execução, além de permitir o monitoramento da execução [START_REF] Oliveira | Debugging Scientific Workflows with Provenance: Achievements and Lessons Learned[END_REF], SILVA et al., 2016b[START_REF] Souza | Monitoramento de Desempenho usando Dados de Proveniência e de Domínio durante a Execução de Aplicações Científicas[END_REF].

Em relação à distribuição de ativações para favorecer o paralelismo (Seção 3.3.2), o SCC conta com duas estratégias para gerenciar a execução paralela de workflows científicos, sendo as seguintes: First Tuple First (FTF) e First Activity First (FAF) [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF]. Para explicar a diferença entre essas estratégias, utilizaremos um exemplo simples de workflow científico: duas transformações de dados t1 e t2, em que t2 depende de t1. Na estratégia FTF, uma ativação de t2 apenas aguarda que os seus elementos de dados de entrada sejam produzidos pela ativação correspondente à t1 (ou seja, da transformação de dados anterior), sendo esse o comportamento típico de pipeline em fluxo de dados. Por outro lado, na estratégia FAF, t2 apenas começa a execução das suas ativações, quando todas as ativações de t1 tiverem sido executadas por completo. Logo, t2 permanece bloqueada até que t1 termine.

Abordagens para a captura e a análise de dados científicos

Para apoiar a captura e a análise de dados científicos, existem diferentes abordagens para determinar o momento em que os dados científicos devem ser acessados, extraídos, carregados e analisados. Como premissa para essas etapas, os programas de simulação já devem ter produzido os dados científicos relevantes. A partir dessa condição, as abordagens existentes para a captura e a análise de dados científicos podem ser classificadas em três categorias: post mortem, in situ e in transit. Essas abordagens são apresentadas em mais detalhes nas demais subseções.

Post mortem

As soluções tradicionais, conhecidas como post mortem, caracterizam-se por capturar e analisar os dados científicos após a execução dos programas de simulação [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF][START_REF] Chou | FastQuery: A Parallel Indexing System for Scientific Data[END_REF][START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF][START_REF] Wu | FastBit: interactively searching massive data[END_REF]. Nesse cenário, os programas de simulação produzem os dados científicos e os Ao mesmo tempo, a principal vantagem dessa categoria consiste em não adicionar sobrecarga de tempo para executar os programas de simulação, pois a captura e a análise de dados científicos podem ser realizadas de forma concorrente, em outros recursos computacionais. Todavia, essa categoria requer mais espaço de armazenamento, pois os dados científicos produzidos pelos programas de simulação precisam ser armazenados em arquivos (para os programas de extração) para estarem disponíveis em análises futuras.

Além disso, essa categoria apresenta como outra desvantagem o fato de não apoiar análises durante a execução das simulações computacionais, sendo esta uma característica essencial na análise exploratória de dados científicos [START_REF] Mattoso | Dynamic steering of HPC scientific workflows: A survey[END_REF].

Considerando os trabalhos relacionados à captura e à análise de dados científicos apresentados na Seção 2.1, e.g., o NoDB (ALAGIANNIS et al., 2015) [START_REF] Hong | AQUAdex: A Highly Efficient Indexing and Retrieving Method for Astronomical Big Data of Time Series Images[END_REF].

In situ

Diante dos avanços nas simulações, os modelos computacionais têm se tornado cada vez mais complexos, produzindo, consequentemente, um volume de dados maior. Mesmo assim, as melhorias de desempenho associadas ao armazenamento de dados (i.e., operações de leitura e escrita em disco) não têm acompanhado o progresso em termos de processamento computacional (i.e., uso de CPU). Assim, simulações em larga escala têm apresentado uma dificuldade maior em lidar com latências entre a geração dos dados científicos e o seu efetivo armazenamento, como discutido em [START_REF] Ayachit | Performance Analysis, Design Considerations, and Applications of Extreme-scale in Situ Infrastructures[END_REF][START_REF] Bennett | Combining in-situ and intransit processing to enable extreme-scale scientific analysis[END_REF]. Com o objetivo de tirar proveito de dados já alocados na memória pelos programas de simulação, ou seja, antes do efetivo armazenamento em arquivos, soluções baseadas na categoria in situ buscam se acoplar aos programas de simulação para serem capazes de capturar e analisar os dados científicos relevantes durante a execução das simulações computacionais [START_REF] Ayachit | Performance Analysis, Design Considerations, and Applications of Extreme-scale in Situ Infrastructures[END_REF], BAUER et al., 2016[START_REF] Lasluisa | In-situ feature-based objects tracking for data-intensive scientific and enterprise analytics workflows[END_REF][START_REF] Rubel | WarpIV: In Situ Visualization and Analysis of Ion Accelerator Simulations[END_REF]. Desse modo, as soluções in situ utilizam os mesmos recursos computacionais dedicados aos programas de simulação para analisar dados científicos e evitam que todos os dados acessados sejam armazenados em disco rígido (i.e., armazenamento não-volátil), como apresentado na Figura 4(b).

Ademais, para que seja possível relacionar os dados produzidos pelos programas de simulação com as estruturas de dados utilizadas pelas ferramentas de análise e visualização de dados científicos, as soluções dessa categoria necessitam de um mapeamento das estruturas de dados entre os programas de simulação e as ferramentas de análise. Uma vez definido este mapeamento, os dados podem ser compartilhados entre eles por meio do uso da memória volátil, enquanto que as ferramentas de análise de dados podem executar suas rotinas para validarem hipóteses científicas, extrair determinados elementos de dados de 

In transit

Em outros cenários, as análises de dados científicos podem exigir uma capacidade de processamento computacional, ou mesmo de gerência dos dados, com potencial de interferir no desempenho dos modelos computacionais executados pelos programas de simulação. Ou seja, elas podem aumentar o tempo de execução da simulação computacional significativamente. Nesses casos, as soluções conhecidas como in transit permitem que os dados científicos acessados sejam mapeados e utilizados pelas ferramentas de análise de dados em outros recursos computacionais, como apresentado na Figura 4(c). Com isso, a principal diferença para a abordagem in situ consiste em não executar os programas de simulação nos mesmos recursos computacionais das ferramentas de análise de dados. Em relação à abordagem post mortem, essa abordagem também apresenta potencial de redução do volume de dados armazenados em disco rígido, pois os usuários do domínio científico podem analisar (ou investigar) os dados ainda alocados em memória volátil para armazenar apenas os dados relevantes, como também observado na abordagem in situ.

Em contrapartida, essa abordagem introduz um custo de comunicação entre os recursos computacionais, já que os dados gerados pelos programas de simulação precisam ser transferidos para os recursos computacionais em que serão utilizadas as ferramentas de análise de dados. Ao mesmo tempo, esse custo é proporcional ao volume de dados envolvido nas análises desejadas e depende da configuração da rede. Do ponto de vista do usuário, essa abordagem apresenta uma latência para prover os resultados das análises aos usuários do domínio científico em função do custo de comunicação. Diante dessas abordagens, destaca-se que a escolha da solução a ser aplicada depende do momento em que se deseja realizar as análises, do tipo de análises a serem realizadas (assim como o volume de dados envolvido) e dos impactos em termos de desempenho ao introduzir esse apoio analítico.

Capítulo 4 -ARMFUL: uma arquitetura para a captura e a análise de dados científicos

A partir da motivação, da caracterização do problema e do referencial teórico, este capítulo apresenta a abordagem utilizada para proporcionar a análise exploratória de dados 

Visão Geral

A partir da abstração de fluxo de dados e da importância da gerência dos dados de proveniência em uma granularidade fina, conforme apresentado respectivamente nas Seções 3.1 e 3.2, esta tese apresenta a arquitetura baseada em componentes ARMFUL6 (do termo em inglês, Analysis of Raw data from Multiple Files ou, em português, Análise de Dados Científicos a partir de Múltiplos Arquivos) (SILVA et al., 2017b). A ARMFUL apoia a gerência dos dados de proveniência e dos dados científicos envolvidos no encadeamento dos programas de simulação a fim de que mecanismos subsequentes também sejam capazes de analisar esses dados durante ou após as simulações computacionais.

Mais especificamente, essa arquitetura apoia o processamento de consultas aos dados científicos presentes em arquivos ou alocados em memória, assim como analisa o fluxo de elementos de dados científicos oriundos da execução da simulação computacional (pertencentes a diferentes transformações de dados). Para isso, adotamos a gerência da proveniência dos elementos de dados no nível físico e lógico, monitorando, respectivamente, os identificadores das instâncias das transformações de dados (também conhecidas como tarefas) e os valores dos atributos específicos do domínio (i.e., dados científicos). Essa abordagem de gerência da proveniência dos elementos de dados é descrita na Seção 3.2.

Ademais, esta tese defende que a ARMFUL seja baseada em duas etapas para apoiar a análise exploratória de dados científicos. Primeiramente, considera-se uma etapa dedicada à captura de dados científicos de forma integrada aos dados de proveniência. Portanto, o fluxo de arquivos e os relacionamentos necessários para permitir a gerência do fluxo de dados no nível lógico (i.e., fluxo dos elementos de dados) são requisitos dessa etapa, conforme discutido no Capítulo 3. Na segunda etapa, propõe-se um mecanismo capaz de processar consultas que assumem o acesso aos dados de proveniência e aos dados científicos, ainda considerando o fluxo de dados nos níveis físico e lógico.

A Figura 5 mostra os comportamentos esperados na etapa de captura de dados de proveniência de uma forma integrada com os dados científicos por meio das seguintes camadas: Captura de Dados Científicos, Captura de Dados de Proveniência e Armazenamento de Dados. Semelhante aos SGWfC existentes que apoiam a gerência de dados de proveniência, os componentes da camada Captura de Dados de Proveniência são responsáveis pela captura de dados de proveniência e pelo armazenamento dos mesmos em um determinado repositório (componente da camada Armazenamento de Dados), que pode ser, e.g., uma base de dados. Nesse caso, considera-se apenas dados associados à composição e à execução do fluxo de dados, como a especificação dos programas de simulação utilizados em cada transformação de dados e o tempo de execução de uma determinada transformação de dados (i.e., dados de proveniência prospectiva e retrospectiva). Ademais, essa camada requer um mecanismo capaz de validar os dados de proveniência que estão sendo capturados, a fim de que não existam inconsistências na base de dados (componente Validador de Dados de Proveniência). Somando-se a isso, o volume de dados científicos gerado durante a execução das simulações computacionais é um fator essencial para definir a melhor estratégia de representação desses dados. Assumindo-se, por exemplo, uma simulação que gera um pequeno volume de dados em cada transformação de dados, ao mesmo tempo em que apresentam poucos atributos a serem capturados em cada arquivo de dados científicos e uma estrutura de dados "padrão" (e.g., ponto flutuante, inteiro ou cadeia de caracteres), a melhor abordagem nesse caso seria carregar os dados científicos com o próprio valor de cada atributo dos seus arquivos na base de dados. Ressalta-se que, nesta tese, o termo ingestão de dados compreende a carga dos dados em uma base de dados de proveniência.

Entretanto, no caso em que um grande volume de dados precisa ser capturado e as estruturas de dados são mais complexas (e.g., octrees e malhas), pode-se empregar técnicas de indexação de dados científicos [START_REF] Chou | FastQuery: A Parallel Indexing System for Scientific Data[END_REF], KIM et al., 2011). Essas técnicas baseiam-se na geração de índices para referenciar os dados científicos nos arquivos. Assim, os valores armazenados na base de dados de proveniência integrada seriam ponteiros (i.e., índices) que serviriam como referências para consultas nos arquivos de dados científicos.

Nesse cenário, o acesso e a captura dos elementos de dados de interesse (i.e., valores dos atributos) podem ser realizados apenas pelo componente Extração de Dados Científicos da Figura 5, enquanto que o uso de técnicas de indexação de dados exige que esse componente seja integrado ao componente de Indexação de Dados Científicos para gerar índices apenas para os elementos de dados de interesse. Ao mesmo tempo, o componente Ingestão de Dados também precisa estar ciente da abordagem de captura de dados científicos, ou seja, extração ou indexação, para que os elementos de dados ou os índices gerados sejam carregados de forma apropriada na base de dados.

Uma vez que os índices gerados para os dados científicos ou mesmo os seus valores tenham sido armazenados em uma base de dados integrada, os usuários podem desenvolver e submeter consultas em SQL para o componente Processador de Consulta, que retornará os resultados obtidos da base de dados. De forma mais específica, o processador de consulta precisa ter ciência de qual abordagem de captura de dados científicos foi adotada para definir se ele usará apenas os recursos de processamento de consultas do Sistema de Gerência de Banco de Dados (SGBD) empregado para a base de dados, ou se ele precisará dos recursos de ferramentas alternativas utilizadas para indexar os dados científicos (só que agora para acessar os dados por meio dos índices), como o FastBit.

Camada de captura de dados científicos

Conforme discutido no Capítulo 2, a análise exploratória de dados científicos caracteriza-se pela investigação por parte dos usuários do domínio científico de resultados parciais e finais obtidos a partir da execução de simulações computacionais. Nesse cenário, os dados científicos produzidos pelos programas de simulação são comumente armazenados em arquivos ou alocados em memória. Dessa forma, para apoiar a análise desses dados, as soluções existentes nessa linha de pesquisa precisam se concentrar no acesso e na captura dos dados científicos relevantes que estão presentes nessas fontes de dados, a fim de que os dados capturados sejam carregados em repositórios externos ou bases de dados para estarem disponíveis no processamento de consultas. Nessa seção apresentamos as abordagens existentes para a captura de dados científicos que se dedicam à extração dos dados (Subseção 4.2.1) e ao uso de técnicas de indexação (Subseção 4.2.2) para reduzir o volume de dados carregados em repositórios externos e favorecer o acesso eficiente aos dados científicos por meio dos índices gerados.

Extração de dados científicos

Tendo como objetivo a captura dos dados científicos, presentes em arquivos, manipulados por transformações de dados, o componente Extração de Dados Científicos realiza o acesso a esses dados por meio de duas análises, conhecidas como léxica e sintática.

Na ciência da computação, a análise léxica (conhecida pelo termo em inglês tokenizing) caracteriza-se pela leitura da entrada de linhas de caracteres e pela geração de uma sequência de símbolos léxicos, conhecidos pelo termo em inglês lexical tokens [START_REF] Blanas | Parallel data analysis directly on scientific file formats[END_REF]. Logo, em outras palavras, a análise léxica permite a verificação de um determinado alfabeto. Na Figura 5, o alfabeto está presente no Catálogo de Dados Científicos, que consiste em um conjunto de metadados necessários para a compreensão do alfabeto adotado em cada formato de arquivo (e.g., arquivos no formato HDF5 em simulações de dinâmica de fluidos computacionais). Assim, a análise léxica consiste na capacidade de acessar os dados científicos de acordo com o formato do arquivo e de verificar se os dados científicos obtidos estão de acordo com o domínio da simulação computacional.

A partir dos símbolos gerados na análise léxica, a análise sintática (conhecida pelo termo em inglês parsing) baseia-se na verificação da sequência de caracteres de entrada para determinar estruturas segundo uma determinada gramática formal [START_REF] Blanas | Parallel data analysis directly on scientific file formats[END_REF]. Em termos práticos, um analisador sintático pode ser utilizado para decompor o texto em unidades estruturais a serem organizadas dentro de um bloco de disco. No cenário de acesso aos dados científicos, pode-se utilizar um analisador sintático para transformar a sequência de caracteres de entrada em uma estrutura de dados conhecida (e.g., grafo), assim como para fornecer informações pertinentes para a indexação posterior dos dados científicos, se aplicável. Semelhante à análise léxica, a análise sintática precisa ter acesso ao catálogo de dados científicos, uma vez que cada formato de arquivo ou estrutura de dados em memória apresenta um conjunto de atributos e suas estruturas de dados características.

Logo, o uso de metadados nessas análises facilitam a conversão dos dados científicos em estruturas de dados específicas a serem armazenadas na base de dados.

Assumindo-se que os dados científicos estejam acessíveis após as análises léxica e sintática, essa etapa também permite que apenas os atributos de interesse sejam extraídos para apoiar análises futuras. Para isso, uma condição de seleção (ou de filtragem) dos dados precisa ser definida para indicar quais valores de atributos (ou regiões de interesse) são importantes para os usuários em suas análises exploratórias, assim como uma lista de atributos deve ser informada para obter apenas os valores de atributos relevantes. Esse processo de seleção de determinados atributos e dos seus respectivos valores a partir de arquivos, respeitando-se as condições de seleção e de projeção, é conhecido pelo termo extração de dados científicos. O processo de extração de dados científicos é vantajoso, principalmente, em cenários de simulações computacionais em larga escala, em que, apesar do grande volume de dados produzidos, os usuários estão mais interessados em regiões específicas de interesse dos dados gerados. 

Indexação de dados científicos

Uma vez que os dados científicos tenham sido acessados, provendo informações sobre as estruturas de dados e os metadados para a geração de índices, o componente Indexação de Dados Científicos implementa técnicas de indexação dos dados científicos capturados com o propósito de reduzir o volume de dados carregados em um repositório externo ou uma base de dados, e de prover uma forma de acesso eficiente aos dados científicos. Mais especificamente, a geração de índices oferece vantagens relacionadas principalmente ao processamento de consultas, ao mesmo tempo em que introduz uma sobrecarga durante o acesso aos dados científicos em diferentes arquivos. Além disso, a indexação de dados científicos só deve ser aplicada em arquivos, pois os dados são armazenados de forma não-volátil, permitindo a geração de índices consistentes, ou seja, que podem ser utilizados posteriormente na consulta aos dados científicos.

Como o cenário em foco desta tese envolve arquivos com grande volume de dados, assumindo-se estruturas de dados que, em geral, não são vantajosas de serem armazenadas em um Sistema de Gerência de Banco de Dadosda sigla SGBD -(alto custo de ingestão dos dados), as técnicas existentes de indexação dos dados científicos [START_REF] Blanas | Parallel data analysis directly on scientific file formats[END_REF], KIM et al., 2011, SILVA et al., 2016c) evita exatamente essa sobrecarga na ingestão de dados. Nesse sentido, existem diferentes algoritmos para apoiar a indexação de dados científicos, como os índices bitmap e posicional apresentados na Seção 2.1.

Considerando os aspectos de desenvolvimento de cartuchos usando o componente Indexação de Dados Científicos da arquitetura ARMFUL, três métodos são definidos para permitir o acesso e a geração de índices para dados científicos presentes em arquivos, sendo conhecidos como index(), run() e access(). O método index() gera índices para todos os atributos escolhidos pelo usuário, sendo que esses atributos precisam estar presentes no arquivo de dados científicos. O Algoritmo 2 apresenta a implementação desse método, assumindo que o método index() invoca um algoritmo de indexação escolhido pelo usuário (argumento algorithm) e gera índices para os atributos de interesse (argumento atts).

Algoritmo 2. Geração de índices para acessar dados científicos em um arquivo.

Entrada:

algorithm: algoritmo de indexação datafile: elementos de dados extraídos de um arquivo de dados científicos atts: lista de atributos Saída:

dataset: conjunto de dados de saída 

Ademais, semelhante ao comportamento dos cartuchos de Extração de Dados

Científicos, o método run() invoca o método index() para gerar índices para todos os atributos em cada registro (ou elemento de dados) presente em diversos arquivos de dados científicos. Já o método access() obtém os dados científicos usando os índices gerados pelo método index(), conforme apresentado no Algoritmo 3. Portanto, diferentemente da extração de dados que tem acesso direto aos elementos de dados a partir do conjunto de dados (armazenado na base de dados), a técnica de indexação de dados exige que os índices gerados sejam obtidos, primeiramente, do conjunto de dados para serem utilizados no acesso aos elementos de dados presentes em arquivos de dados científicos.

Apesar das tecnologias permitirem a indexação de dados científicos e as suas máquinas de processamento de consultas usarem esses índices para melhorar o acesso aos dados, elas não são capazes de gerenciar dados científicos relacionados em múltiplos arquivos. Ou seja, as soluções existentes são focadas em analisar dados científicos em arquivos de uma forma isolada. Logo, aspectos associados ao fluxo de arquivos e ao fluxo de elementos de dados não são apoiados por essas tecnologias. Tendo em vista essa limitação, a nossa abordagem representa esses dados científicos em uma base de dados integrada, ou seja, que também considera (i) dados de proveniência prospectiva (Seção 3.2.4)tipo de dado que permite especificar os principais programas de simulação como transformações de dados e as dependências de dados entre as transformações -; e dados de proveniência retrospectiva (Seção 3.2.4)tipo de dado obtido durante a execução de uma simulação computacional.

Algoritmo 3. Acesso aos dados científicos usando índices.

Entrada:

algorithm: algoritmo para acesso aos dados científicos usando índices path: caminho para o arquivo de entrada filename: nome do arquivo de entrada dataset: conjunto de dados, em que cada elemento contém os índices gerados atts: attributos de interesse Saída:

output: conjunto de dados de saída 

Camada de captura de dados de proveniência

Assim como os dados científicos precisam ser capturados de arquivos, os sistemas com apoio ao monitoramento de fluxos de dados, como os SGWfC pela abstração de workflows científicos, também precisam gerenciar os dados de proveniência gerados, em tempo de execução, pelas simulações computacionais (camada Captura de Dados de Proveniência). Na nossa abordagem, temos como meta capturar os dados de proveniência em uma granularidade fina (componente Captura de Dados de Proveniência), a fim de que os três tipos de análises exploratórias em arquivos de dados científicos sejam apoiados, conforme apresentado no Capítulo 2. Ademais, após a captura dos dados de proveniência, essa camada requer que esses dados sejam validados por meio do componente Validação de Dados de Proveniência com o objetivo de garantir que o fluxo de dados modelado siga as definições da Subseção 3.1.1 e os dados de proveniência retrospectiva sejam consistentes com a especificação do fluxo de dados (i.e., transformações de dados e suas dependências de dados) ou, em outras palavras, com os dados de proveniência prospectiva.

Outra preocupação da nossa proposta consiste na representação dos dados de proveniência e dos dados científicos capturados de arquivos. No que diz respeito a essa representação, nossa abordagem segue as recomendações de grupos e instituições para que o modelo de dados de proveniência seja padronizado, estruturado e interoperável. Nesta tese apresentamos uma extensão do diagrama de classes dos dados de proveniência para workflows científicos, conhecido como PROV-Wf, que foi desenvolvido em colaboração com o D.Sc. Flavio [START_REF] Costa | Capturing and Querying Workflow Runtime Provenance with PROV: A Practical Approach[END_REF]. A adaptação desse diagrama teve o propósito de estender a representação de dados de proveniência em granularidade fina para descrever os dados científicos acessados, extraídos e indexados a partir de arquivos e de permitir análises direcionadas ao fluxo de dados nos níveis físico e lógico (Subseção 3.1.2).

Portanto, para seguir a abstração de fluxo de dados apresentada na Subseção 3.1.1, a Seção 4.4 apresenta mais detalhes dessa adaptação do PROV-Wf, que foi nomeada como PROV-Df (SILVA et al., 2016c), uma vez que o foco está nas noções de fluxo de dados e não de workflows científicos.

PROV-Df: diagrama de classes para modelar o fluxo de dados

Como apresentado anteriormente, a arquitetura ARMFUL permite o acesso, a indexação e o armazenamento de dados científicos por meio de cartuchos, que utilizam algoritmos desenvolvidos pelos usuários ou ferramentas alternativas. Entretanto, as análises exploratórias de dados científicos não se restringem ao acesso isolado dos dados científicos presentes em arquivos consumidos ou gerados por transformações de dados, conforme discutido no Capítulo 2. Os usuários do domínio científico regularmente necessitam analisar o fluxo de arquivos ao longo da execução da simulação, assim como relacionar os elementos de dados presentes em diferentes arquivos.

Nessa perspectiva, o armazenamento dos dados é um aspecto importante na captura de dados de proveniência em granularidade fina. Ademais, iniciativas têm sido desenvolvidas para orientar a representação desses dados, como as recomendações do PROV (MOREAU e GROTH, 2013) pela World Wide Web Consortium (W3C). A proposta dessas iniciativas é permitir que os modelos de dados de proveniência sejam padronizados, estruturados e interoperáveis. Assim, uma vez que os estereótipos possam ser definidos de acordo com um metamodelo (e.g., PROV-DM7 ), diferentes modelos de dados de proveniência podem ser relacionados de acordo com a nomenclatura do metamodelo.

Seguindo as recomendações do PROV W3C, um diagrama de classes, conhecido como PROV-Wf [START_REF] Costa | Capturing and Querying Workflow Runtime Provenance with PROV: A Practical Approach[END_REF], já havia sido proposto e empregado pelo SGWfC SCC para representar os dados de proveniência gerados por workflows científicos, em particular, com execuções paralelas em larga escala. Entretanto, considerando-se as definições de fluxo de dados apresentadas na Seção 3.1, esta tese estendeu o PROV-Wf para apoiar tais conceitos (SILVA et al., 2017b). Esse diagrama de classes para os dados de proveniência estendido foi nomeado como PROV-Df, conforme mostrado na Figura 7.

Comparando-se o PROV-Wf com o PROV-Df, as suas contribuições estão exatamente no mapeamento dos conceitos de workflow científico para a abstração de fluxo de dados, além das extensões para permitir a representação de conjuntos de dados, com coleções e elementos de dados, assim como o processo de extração de dados científicos em arquivos. Ao mesmo tempo, uma base de proveniência que segue o diagrama PROV-Df permite o acesso aos arquivos de dados científicos, que podem coexistir com diversos outros arquivos gerados por transformações de dados em diferentes espaços de trabalho (i.e., diretórios). As referências para os arquivos podem ser registradas em uma base por meio de ponteiros (e.g., URI), a fim de utilizá-los na análise do fluxo de arquivos e dos elementos de dados presentes nesses arquivos. Dessa forma, os usuários são capazes de elaborar consultas analíticas com caráter investigativo (mais profundas) em sua base de proveniência, considerando tanto os dados específicos de domínio (i.e., dados científicos presentes em arquivos), como informações do fluxo de dados, para observar os dados de diferentes arquivos manipulados ao longo da execução da simulação computacional.

Ingestão de dados científicos

Apesar das diferentes técnicas de indexação de dados científicos, existem circunstâncias em que a ingestão dos dados científicos (i.e., carga dos valores assumidos pelos atributos) junto com os dados de proveniência em um determinado repositório (e.g., base de dados) seja o mais recomendado por questões de desempenho. Como exemplo, pode-se considerar a ingestão dos dados científicos como mais vantajosa, se a indexação de dados científicos com estruturas de dados padrões (e.g., cadeia de caracteres e inteiros) ocupar mais espaço de armazenamento que a ingestão do próprio dado científico e o tempo de consulta usando índices for maior que o custo de consultar diretamente os dados científicos na base de dados de proveniência integrada. Em função desse cenário, a nossa abordagem permite que os usuários definam se pretendem indexar os dados científicos ou se preferem carregar os elementos de dados diretamente na base de dados. Além de permitir que o usuário defina se realizará a indexação ou a ingestão dos dados científicos, a nossa abordagem é capaz de escolher a técnica de indexação de dados científicos a ser utilizada e, consequentemente, modificar a proposta de armazenamento na base de dados.

No caso da ingestão de dados científicos, os índices são gerados diretamente pelo SGBD e, depois, eles são usados para acessar os dados científicos dos arquivos armazenados na base de dados. Por conseguinte, a nossa abordagem representa os valores dos atributos no esquema da base de dados de proveniência de acordo com a natureza dos dados científicos: estruturas de dados dos valores de atributos carregados de arquivos ou estruturas de dados necessárias para representar os índices gerados a partir de dados científicos presentes em arquivos. Vale ressaltar que o resultado desse processo com extração ou indexação dos dados científicos, portanto, é uma base de dados de proveniência com os registros de fluxo de dados de diferentes simulações computacionais, sendo que o esquema dessa base de dados segue a especificação do PROV-Df.

Processamento de consultas aos dados científicos

Uma vez que os dados científicos tenham sido capturados e armazenados em um SGBD, os usuários podem consultá-los para validar ou refutar as suas hipóteses científicas.

Para que isso seja possível, alguns mecanismos precisam ser adicionados como uma etapa de pré-processamento das consultas para permitir as análises focadas nos dados científicos, quando técnicas de indexação com ferramentas alternativas são aplicadas. Semelhante à primeira etapa existente em processadores de consultas, o pré-processamento também deve contemplar as análises léxica e sintática. No caso de consultas para permitir o acesso aos dados científicos, esse componente precisa ser capaz de considerar os seguintes aspectos, assumindo-se que os dados científicos foram capturados por técnicas de indexação:

• As estruturas dos dados científicos não correspondem necessariamente às estruturas de dados adotadas pelos atributos armazenados na base de proveniência, pois os valores armazenados correspondem aos índices gerados ao acessar o conteúdo dos arquivos de dados científicos; e

• A referência para o arquivo utilizado na indexação de determinados atributos normalmente não está presente na especificação desses atributos na base de dados.

Logo, a base de dados precisa ser capaz de representar essas referências aos arquivos e relacionar esses arquivos aos atributos capturados (i.e., que apresentam os índices para os dados científicos).

A partir dessas análises, esse mecanismo de pré-processamento é capaz de identificar os índices gerados em cada conjunto de dados, assim como de subdividir a consulta de acordo com a natureza dos dados. Nesse caso, os dados de proveniência, os dados de execução e os dados científicos extraídos diretamente de arquivos de dados podem ser consultados pela subconsulta que é executada pelo SGBD, em que temos a base de dados da ARMFUL seguindo as especificações do PROV-Df. Já as subconsultas, que consideram o acesso aos dados científicos por meio dos índices gerados, serão executadas pelos mecanismos de processamento de consultas das ferramentas alternativas utilizadas, como a ferramenta FastBit. Ao final de cada um desses comportamentos, os resultados obtidos precisam ser unidos de acordo com a especificação da consulta submetida. Caso haja qualquer tipo de erro ao processar a consulta, uma mensagem de erro deve ser gerada por esse mecanismo em tempo de execução.

SCC-A: uma instância da ARMFUL usando o SGWfC SCC

Como primeira instância da ARMFUL, o SGWfC SCC foi estendido para permitir a captura e a análise de dados científicos, sendo essa implementação conhecida como SCC-A8 . Como o SCC já apresentava um recurso de extração de dados, sem considerar o acesso ao conteúdo presente em arquivos de dados científicos, o seu modelo arquitetural (Subseção Já a camada Processamento de Ativação lida com a identificação dos comportamentos necessários para permitir a execução de uma ativação: a invocação dos programas de simulação, a extração de dados científicos e a captura dos dados de proveniência. Nesse sentido, a camada Invocação de Programa é responsável pela instrumentação e execução propriamente dita dos programas de simulação envolvidos em uma ativação, segundo a especificação de uma atividade. Ademais, a camada Invocação de Extrator tem o objetivo de permitir a carga de dados gerados durante a execução de workflows científicos em uma base de dados de proveniência relacional. Por último, a camada Processamento de Dados de Proveniência apoia o mecanismo de processamento de consultas do SCC, garantindo a captura de dados de proveniência em tempo de execução.

Nesse caso, o SCC implementa o processamento de consultas por meio de uma conexão com um Sistema de Gerência de Banco de Dados (SGBD) relacional, mais especificamente, o PostgreSQL9 .

Apesar dessas camadas, a álgebra relacional de workflows científicos, proposta inicialmente e implementada no Chiron [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF], não é suficiente para realizar a captura de dados científicos em arquivos por meio da camada Invocação de Extrator. A etapa original de extração de dados do SCC consiste apenas na captura de dados por meio da invocação de programas externos que acessam dados produzidos (normalmente em arquivos de log) e os representam como relações de saída das atividades do workflow.

Após a execução desses programas, esse SGWfC paralelo exige a escrita dos dados capturados em um arquivo no formato tabular, conhecido como ERelation.txt.

Diferentemente dessa proposta original do SCC, defendemos que o processo de extração de dados científicos deve acessar e capturar os dados científicos em arquivos com dados em sua forma bruta, assim como representar esses dados extraídos também no arquivo ERelation.txt. Mais especificamente, esse processo é composto de três etapas: acesso aos dados científicos de arquivos com dados em sua forma bruta, indexação dos dados extraídos e a carga dos dados científicos em um repositório externo ou uma base de dados. No cenário de captura de dados científicos, o acesso e a indexação dos dados científicos requerem um conhecimento prévio das estruturas de dados presentes nos formatos de arquivo de interesse. Além disso, em casos de arquivos com grande volume de dados a serem extraídos, o SCC pode empregar técnicas de indexação para evitar a carga de muitos dados científicos ou de estruturas de dados complexas e densas em repositórios externos ou em bases de dados. Ao mesmo tempo, o SCC deve fornecer funcionalidades que permitam os usuários selecionarem os atributos de dados científicos relevantes para as suas análises futuras.

Diante dessas questões, esta tese propõe uma extensão do SGWfC SCC, conhecida como SCC-A, que contemple dois mecanismos possíveis na etapa de extração de dados: carga e indexação de dados científicos. A carga de dados consiste no mesmo comportamento existente nesse SGWfC paralelo, que é caracterizada pela invocação de um programa externo, mas com o acesso a dados presentes em arquivos de dados científicos.

Dessa forma, os valores dos atributos de interesse (i.e., dados científicos) seriam carregados diretamente no SGBD relacional utilizado pelo SCC-A. Enquanto isso, a indexação de dados científicos lida com o acesso aos dados científicos presentes em arquivos em formatos específicos do domínio, a geração de índices (e.g., bitmap e posicional) para permitir o acesso eficiente a esses dados posteriormente e a carga dos índices na base de proveniência do SCC-A. Logo, ao invés de armazenar os valores dos atributos na base de proveniência, o SCC-A carrega os índices referentes aos dados científicos. Além disso, essa base de proveniência gerencia quais atributos tiveram seus valores indexados, a fim de apoiar o acesso aos dados científicos presentes nos arquivos pelo uso dos índices gerados.

Ao acoplar a arquitetura ARMFUL com o SCC (Seção 4.7), esta tese tirou proveito das relações utilizadas pelo SCC para representar os dados consumidos e produzidos pelas transformações de dados em uma base de proveniência, com o objetivo de monitorar, depurar e analisar o fluxo de dados em simulações computacionais. Essa abordagem relacional também favorece consultas aos dados científicos de uma forma estruturada (i.e., uma relação contém todos os dados científicos referentes a um conjunto de dados para uma transformação de dados específica), o que facilita as análises desenvolvidas pelos usuários.

Além disso, o SCC-A utiliza as expressões algébricas para direcionar a execução paralela do workflow científico, armazenando os dados na base de proveniência. Nesse aspecto, o SCC-A armazena dados de proveniência prospectiva e retrospectiva, que podem ser representados, respectivamente, pelas especificações das expressões algébricas realizadas em cada transformação de dados (e as suas dependências de dados) e os metadados relacionados à execução do workflow científico [START_REF] Costa | Capturing and Querying Workflow Runtime Provenance with PROV: A Practical Approach[END_REF].

Dado que esta tese considera a gerência do fluxo de arquivos e dos elementos de dados, estendeu-se a base de proveniência do SCC para armazenar metadados relacionados aos dados específicos do domínio; arquivos consumidos e produzidos; e elementos de dados extraídos a partir de arquivos de dados científicos (i.e., formatos de arquivos específicos do domínio). Seguindo as recomendações do PROV W3C, um diagrama de classes, conhecido como PROV-Wf [START_REF] Costa | Capturing and Querying Workflow Runtime Provenance with PROV: A Practical Approach[END_REF], já havia sido proposto e empregado no SCC para representar os dados de proveniência para workflows científicos, em particular, com execuções paralelas em larga escala. Assim, considerando-se as definições de fluxo de dados (Seção 3.1), esta tese estendeu o PROV-Wf para apoiar tais conceitos (SILVA et al., 2017b). Esse modelo de dados de proveniência estendido é conhecido como PROV-Df, conforme discutido na Seção 4.4.

Já no que diz respeito à análise dos dados científicos nessa base integrada de dados de proveniência, o processador de consultas terá a responsabilidade de utilizar os índices gerados e as referências para os arquivos para obter os valores assumidos pelos atributos de dados científicos. Do mesmo modo, o modelo de dados de proveniência deve permitir que os metadados referentes ao tipo de índice empregado e ao formato do arquivo com dados científicos estejam acessíveis, para que o processador de consulta possa obtê-los ao gerar o plano de execução da consulta. Em circunstâncias em que as análises necessitam relacionar dados científicos de diferentes arquivos, o modelo de dados também precisa representar os fluxos de dados nos níveis físico e lógico gerados pela simulação computacional. O componente RDI realiza a indexação dos dados científicos por meio do acesso aos conteúdos presentes em arquivos. Nesta implementação do SCC-A, utilizou-se duas técnicas de indexação, que foram baseadas no mapeamento posicional proposto por [START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF], nos cartuchos para os formatos de arquivo FITS e CSV, e em mapas de bits usando a ferramenta FastBit. No caso do uso da ferramenta FastBit, esse cartucho foi resultado de um trabalho de pesquisa em colaboração com o M.Sc. José Vitor Leite (SILVA et al., 2017b), em que se utilizou essa ferramenta alternativa para gerar índices do tipo mapa de bits para os dados científicos de interesse. De forma semelhante, outras ferramentas alternativas podem ser utilizadas pela arquitetura RDC para indexar os dados científicos, como o NoDB, o Slalom e o SDS.

Diferentemente do RDI, o componente EI permite a invocação de programas de extração de dados científicos, conhecidos como extratores, para a carga dos valores dos atributos de interesse diretamente na base de dados do SCC-A. Consequentemente, o Cartucho para Invocação de Programa Externo tem o objetivo de invocar programas externos para extrair dados científicos de arquivos produzidos pelos programas de simulação. Ao contrário, o componente RDI propõe o uso de técnicas de indexação para reduzir a carga de dados na base de proveniência e, consequentemente, o tempo de execução da simulação computacional. Somando-se a isso, o RDI apresenta como desvantagem uma sobrecarga na etapa de consulta aos dados científicos, devido ao custo de recuperação dos índices gerados e armazenados na base de dados de proveniência para depois utilizá-los no acesso aos dados científicos armazenados nos arquivos.

Raw e RawI: operadores algébricos estendidos na SciWfA para extrair e indexar dados científicos

Apesar da abordagem algébrica do SCC apresentar três procedimentos para descrever a execução de uma ativação (i.e., instrumentação, execução e extração), a álgebra relacional para workflows científicos, conhecida como SciWfA [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF], não permite descrever a extração e a indexação de dados científicos em uma transformação dos dados. Nesse sentido, essa álgebra foi estendida nesta tese, adicionandose dois operadores algébricos para permitir a extração e a indexação de dados científicos, sendo esses novos operadores algébricos conhecidos como Raw e RawI, respectivamente.

Semelhante aos operadores originais do SCC, os operadores Raw e RawI devem apresentar o tipo da atividade operada, os operandos adicionais e a relação de entrada. Como operandos adicionais, esses operadores necessitam de duas informações: o nome do atributo da relação de entrada que apresenta como valores as referências para os arquivos a terem seu conteúdo extraído e os nomes dos atributos que precisam ter seus valores capturados desses arquivos.

Ademais, o tempo de processamento computacional pode variar de acordo com o operador algébrico. Para o operador Raw, existe apenas um comportamento possível: a invocação de programas externos para extrair dados científicos de arquivos. Logo, a especificação da transformação de dados deve contemplar a linha de comando para invocar os programas externos. Já o operador RawI permite dois comportamentos possíveis: a invocação de ferramentas alternativas, como o FastBit; ou o uso de algoritmos desenvolvidos em determinados cartuchos da arquitetura RDC para indexar dados científicos acessados em arquivos. Consequentemente, a invocação de ferramentas alternativas exige a especificação da linha de comando para executar essas ferramentas, ao especificar a transformação de dados, enquanto que o uso de cartuchos com algoritmos próprios requer apenas a identificação do cartucho a ser utilizado. No contexto desta tese, desenvolveu-se dois cartuchos com algoritmos próprios na arquitetura RDC, mas inspirados em soluções existentes, como o Cartucho FITS10 e o Cartucho CSV baseado na geração de índices posicionais, conforme a proposta do NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF]. Vale ressaltar que, caso seja de interesse do usuário, as invocações para as ferramentas alternativas podem ser acopladas como um cartucho com algoritmo próprio, sem que o usuário tenha que ter conhecimento de como deve invocar essas ferramentas para indexar os dados científicos.

Além disso, a relação do número de tuplas consumidas e produzidas varia consideravelmente nesses operadores algébricos, pois depende da quantidade de arquivos analisados e do próprio volume de dados presente nesses arquivos. Portanto, essa relação pode ser representada por 1:n, a fim de que a operação desempenhada pelo operador Raw ou RawI apresente o comportamento mais genérico possível (i.e., expressando que cada arquivo de entrada pode extrair um ou mais elementos de dados científicos). Nessa circunstância, assume-se que cada invocação desses operadores é responsável por acessar e, eventualmente, indexar dados científicos presentes em apenas um arquivo. Diante dessas informações, os operadores algébricos Raw e RawI podem ser especificados formalmente, conforme apresentado abaixo: Ademais, essa biblioteca de componentes defende uma solução agnóstica à linguagem de programação, ou seja, os usuários podem modificar os seus programas de simulação independentemente da linguagem de programação. Para isso, essa biblioteca de componentes conta com um conjunto de serviços RESTful para a captura de dados de proveniência e científicos, e com programas binários ou ferramentas alternativas que os usuários podem invocar a partir de seus códigos fontes para realizar a extração e, eventualmente, a indexação de dados científicos presentes em arquivos. Essa proposta difere das soluções existentes para a análise de dados de proveniência em scripts e programas, que tendem a seguir uma linguagem de programação específica e serem sequenciais, como o noWorkflow [START_REF] Murta | noWorkflow: Capturing and Analyzing Provenance of Scripts[END_REF], específico para scripts sequenciais na linguagem de programação Python.

𝑅𝑒𝑙𝑎çã𝑜 𝑠𝑎í𝑑𝑎 ← 𝑅𝑎𝑤 ( 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑎 𝑒𝑥𝑡𝑒𝑟𝑛𝑜 , { {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜 𝑎𝑟𝑞𝑢𝑖𝑣𝑜𝑠 }, {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑎𝑐𝑒𝑠𝑠𝑎𝑑𝑜𝑠 } }, 𝑅𝑒𝑙𝑎çã𝑜 𝑒𝑛𝑡𝑟𝑎𝑑𝑎 ) ( 2 
)
𝑅𝑒𝑙𝑎çã𝑜 𝑠𝑎í𝑑𝑎 ← 𝑅𝑎𝑤𝐼 ( 𝐹𝑒𝑟𝑟𝑎𝑚𝑒𝑛𝑡𝑎 𝑎𝑙𝑡𝑒𝑟𝑛𝑎𝑡𝑖𝑣𝑎 𝑜𝑢 𝐶𝑎𝑟𝑡𝑢𝑐ℎ𝑜 𝑖𝑛𝑑𝑒𝑥𝑎çã𝑜 , { {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜 𝑎𝑟𝑞𝑢𝑖𝑣𝑜𝑠 }, {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑎𝑐𝑒𝑠𝑠𝑎𝑑𝑜𝑠 } }, 𝑅𝑒𝑙𝑎çã𝑜 𝑒𝑛𝑡𝑟𝑎𝑑𝑎 ) (3 
Para apoiar a captura de dados científicos comumente presentes em arquivos, a

DfAnalyzer apresenta uma operação, denominada extract, que oferece o acesso, a extração e, eventualmente, a indexação dos dados científicos. Como primeiro passo, portanto, essa operação acessa os conteúdos presentes em cada arquivo, sendo que apenas os valores dos atributos de interesse são selecionados e extraídos. De acordo com uma sequência de atributos predefinidos, a extração de dados científicos representa uma sequência de valores para esses atributos como um elemento de dados, segundo a abstração de fluxo de dados (Seção 3.1). Já na indexação de dados científicos, ao invés de extrair diretamente os valores dos atributos, técnicas de indexação podem ser aplicadas para criar índices, a fim de permitir um acesso eficiente aos dados científicos. Assim, a indexação de dados tende a ser mais vantajosa em estruturas de dados mais avançadas, como malhas, ou quando o volume de dados acessados é muito grande (i.e., grande quantidade de elementos de dados que poderiam ser referenciados apenas por um arquivo de índices).

Além disso, a DfAnalyzer foi integrada ao ParaView Catalyst, uma ferramenta para a análise e a visualização de dados in situ. Dessa forma, além de permitir a análise de dados científicos em arquivos, a nossa ferramenta é capaz de tirar proveito de dados alocados em memória, reduzindo o custo de operações em disco e, consequentemente, o tempo de execução da simulação computacional, conforme apresentado nas avaliações experimentais desta tese. Outra contribuição é a geração de visualizações para estruturas de dados mais complexas, como malhas, facilitando a análise de dados científicos.

Motivados também pelas tecnologias relacionais padrão apresentarem um bom alicerce na gerência e na manipulação de uma grande variedade de conjuntos de dados, a

DfAnalyzer representa os conjuntos de dados como relações. Ademais, essa biblioteca de componentes tira proveito do poder analítico da linguagem SQL, permitindo análises focadas em múltiplos arquivos e diversos elementos de dados relacionados (armazenados em relações). Do ponto de vista de implementação, a DfAnalyzer adota um Sistema de Gerência de Banco de Dados (SGBD) relacional orientado a coluna e apresenta um conjunto de componentes para apoiar as funcionalidades discutidas anteriormente. Esses componentes são descritos em mais detalhes na Subseção 5.4.

Metodologia orientada ao fluxo de dados em simulações computacionais

Como discutido anteriormente, as simulações computacionais são caracterizadas pelo processamento de modelos computacionais encadeados cada vez mais complexos, Nessa fase, esses usuários identificam as transformações de dados, os conjuntos de dados, os atributos presentes em cada conjunto de dados, que podem ser capturados de arquivos, e as dependências de dados entre as transformações. Para apoiar a captura de dados científicos por meio do uso de um programa ad-hoc ou uma ferramenta alternativa, a nossa abstração de fluxo de dados foi estendida para contemplar o conceito de extrator de dados científicos, ou, simplesmente, extrator. Assim, os extratores também fazem parte da especificação do fluxo de dados.

Como resultado, essa colaboração entre os usuários obtém a especificação do fluxo de dados para a simulação computacional de interesse. Essa especificação do fluxo de dados é normalmente representada por um modelo conceitual de dados, por meio de um diagrama Entidade-Relacionamento (ER) para, em seguida, ser mapeado em um modelo de dados lógico [START_REF] Heuser | Projeto de Banco de Dados[END_REF]. Considerando a abstração de fluxo de dados, a definição de conjunto de dados segue uma representação próxima de uma relação e as tecnologias relacionais apresentam um bom alicerce na gerência de uma grande variedade de dados, favorecendo que a DfAnalyzer siga uma metodologia baseada no armazenamento dos metadados do fluxo de dados em uma base de dados relacional.

Uma vez que a especificação do fluxo de dados tenha sido obtida, o especialista em ciência da computação realiza ajustes nos programas de simulação com o propósito de capturar os dados de proveniência produzidos pelas diferentes instâncias das transformações de dados, também conhecidas como tarefas. Assim, enquanto a especificação do fluxo de dados contempla dados de proveniência prospectiva (Seção 3.2), os ajustes dessa fase são importantes para apoiar a captura de dados de proveniência retrospectiva (quando a simulação computacional for executada). Vale ressaltar que essa fase não depende do usuário do domínio científico, pois o especialista em ciência da computação já estaria ciente dos requisitos da simulação computacional.

Ademais, esse passo é importante na obtenção das dependências de dados em tempo de execução, ao especificar, no código fonte dos programas de simulação, quais tarefas são responsáveis pela produção e pelo consumo de elementos de dados em um conjunto. Nesse sentido, esses ajustes apresentam frequentemente um comportamento dinâmico, a fim de capturar as dependências de dados de diversas instâncias de uma transformação de dados (ou tarefas). Como exemplo, temos os cenários de varredura de parâmetros [START_REF] Raicu | Many-task computing for grids and supercomputers[END_REF], em que diferentes elementos de dados de entrada (diversas combinações de valores dos atributos) são utilizados para avaliar um modelo computacional, realizando uma iteração na primeira transformação de dados para cada combinação de valores dos atributos de entrada.

Na fase seguinte, o usuário do domínio científico retoma a sua parceria com o especialista em ciência da computação para modelarem apenas os dados de domínio. Como primeiro passo, esses usuários definem quais valores de atributos podem ser obtidos diretamente dos programas de simulação, sem especificar um extrator de dados científicos.

Em seguida, eles trabalham para definir os programas ad-hoc ou ferramentas alternativas a serem utilizadas pelos extratores de dados científicos e como associar os dados científicos (ou valores de atributos) extraídos aos valores de atributos obtidos sem extratores.

Como resultado, os usuários são capazes de compreender como dados científicos de diferentes origens, como um arquivo de dados científicos ou dados ainda alocados em memória pelo programa de simulação, são relacionados e, posteriormente, representados como elementos de dados em um conjunto de dados. Além disso, eles aproveitam o trabalho em colaboração para definir o trecho do código fonte em que as invocações dos extratores serão realizadas nos programas de simulação e como associá-las a um conjunto de dados, além de ajustes para carregar os elementos de dados dos conjuntos de dados na base de dados da DfAnalyzer. Dado que as fases anteriores tenham sido concluídas, os usuários podem executar a simulação computacional. Assim, a DfAnalyzer é capaz de capturar os dados de proveniência e os dados científicos produzidos pelos programas de simulação modificados e de armazenar esses dados em uma base de dados relacional, seguindo o nosso modelo de dados lógico. Somando-se a isso, a nossa ferramenta disponibiliza um conjunto de visões para apoiar a análise de dados científicos em tempo de execução. Nesse sentido, a última fase da nossa metodologia corresponde à modelagem de consultas por meio das visões oferecidas pela DfAnalyzer.

Apesar desta tese apresentar essa metodologia no contexto da DfAnalyer, em qualquer solução de análise de dados é necessária uma etapa de modelagem que represente

as atividades e as dependências de um workflow na aplicacao científica. Isso é necessário quando se usa um SGWfC e, principalmente, quando se usa uma abordgem específica para a captura e a análise de dados (e.g., DfAnalyzer). Portanto, um SGWfC também deveria ter uma metodologia, tanto para identificar as atividades quanto os dados a serem capturados.

Nesse sentido, a metodologia apresentada nas subseções a seguir também poderia ser aplicada ao utilizar-se um SGWfC. Como mencionado anteriormente, a primeira fase da nossa metodologia consiste na modelagem da simulação computacional de interesse como um fluxo de dados a partir da gerência dos dados de proveniência. Entretanto, a especificação do fluxo de dados, até o momento, não está explícita para a simulação computacional de interesse. Por exemplo, a

Figura 12 não mostra quais são as principais etapas de processamento computacional (i.e., transformações de dados na abstração de fluxo de dados), os dados consumidos e produzidos em cada etapa (i.e., conjuntos de dados e seus atributos) e as dependências de dados entre essas etapas. Tais conceitos são essenciais para expressar o fluxo dos elementos de dados e, eventualmente, de arquivos na simulação computacional de interesse.

Para atender a essa questão, o usuário do domínio científico trabalha com o especialista em ciência da computação em uma especificação do fluxo de dados.

Frequentemente, eles apresentam um conjunto de passos bem definidos para obter essa especificação, sendo descrito nesta subseção. Como primeiro passo nesse processo, esses usuários identificam os trechos de código fonte em seus programas e scripts com um processamento computacional que exigem análises futuras, de acordo com dados que serão consumidos e produzidos. Nesse momento, esses usuários identificam, portanto, apenas as transformações de dados e o seu comportamento em termos de processamento computacional. Por exemplo, a Figura 13 mostra as três transformações de dados envolvidas no script em Python para a contagem de palavras, sendo essas transformações responsáveis por identificar as linhas presentes nos arquivos de texto de entrada (Obter linhas), obter as ocorrências de palavras em cada linha (Identificar ocorrências de palavras) e agrupar as ocorrências por palavra (Contar ocorrências de palavras).

Figura 13. Especificação das transformações de dados em uma simulação computacional.

Após a identificação das transformações de dados, os usuários trabalham para identificar os conjuntos de dados (e os seus atributos) que serão consumidos e produzidos em cada transformação de dados. Além disso, quando conjuntos de dados são consumidos por uma transformação e produzidos por outra, eles aproveitam para definir as dependências de dados. Nesse contexto, uma dependência de dados consiste em dizer que uma transformação depende de dados produzidos por outra transformação em função de um conjunto de dados (Definição 3.1.5 da Seção 3.1). A Figura 14 mostra os conjuntos de dados manipulados pelas transformações de dados identificadas no passo anterior, assim como expressa as dependências de dados ao relacionar as transformações pelas setas. Além disso, destacamos em negrito o rótulo (ou nome) dos conjuntos de dados, pois, ao adotarmos uma abstração de fluxo de dados, o nosso foco está na análise do fluxo de elementos de dados manipulados pelos conjuntos de dados. Considerando novamente a especificação do fluxo de dados do script em Python para a contagem de palavras (Figura 14), temos dois comportamentos possíveis para as suas transformações de dados. Existem transformações de dados 1:n, em que, para cada elemento de dados de entrada, uma tarefa produz vários elementos de dados de saída, como instâncias das transformações get_lines e identify_occurrences. Por outro lado, temos transformações de dados n:1, em que, para cada conjunto de elementos de dados de entrada (ou coleção de dados), uma tarefa produz apenas um elemento de dados de saída, como uma instância da transformação count_words. Essas informações são essenciais para o especialista em ciência da computação realizar corretamente os ajustes nos programas de simulação e gerenciar as dependências de dados em função das instâncias das transformações de dados.

Em virtude das mudanças realizadas nos programas de simulação, a nossa biblioteca de componentes favorece a execução de diferentes iterações da simulação computacional (semelhante ao cenário de varredura de parâmetros), de modo que os processos de captura e de carga dos dados de proveniência sejam realizados corretamente, garantindo a consistência da nossa base de dados. Consequentemente, por respeitar os requisitos definidos no diagrama ER para a especificação do fluxo de dados, os dados armazenados extractor("odeduplication", "odeduplication", "EXTRACTION", "EXTERNAL_PROGRAM", ["word","count], ["text","numeric"])

transformation("count_words", ["occurrences"], ["counts"], ["CountWords::reduceByKey()"])

na nossa base de dados nesse passo também contemplam os rastros de proveniência. Mais detalhes sobre essa questão são apresentados na Subseção 5.3.3.

Modelagem dos dados de domínio

Na subseção anterior vimos os passos envolvidos na fase de modelagem dos dados de proveniência. Entretanto, o modelo de dados lógico obtido não apresenta os dados científicos de interesse comumente analisados pelo usuário do domínio científico. Nesse sentido, esta subseção apresenta a fase de modelagem dos dados de domínio, assim como a importância de especificarmos os extratores no cenário da análise exploratória de dados científicos. Ademais, os ajustes necessários nos programas de simulação para apoiar essa fase também são apresentados em detalhes. Dessa forma, a nossa metodologia ainda não havia, de fato, especificado como os dados científicos seriam obtidos ou extraídos de arquivos nessa simulação computacional.

Como primeiro passo dessa fase, portanto, uma modelagem conceitual foi realizada a partir de conceitos da nossa especificação do fluxo de dados para compreender os conjuntos de dados, os atributos e os extratores de dados científicos utilizados na simulação computacional de interesse. Como resultado, um segundo diagrama ER (Figura 19) foi criado para descrever quais conjuntos de dados e extratores (com os seus atributos) são manipulados pelas diferentes transformações de dados e como eles podem ser relacionados ao longo da especificação do fluxo de dados. Esse mapeamento é mais intuitivo do ponto de vista do usuário do domínio científico do que o primeiro diagrama, pois esse usuário conhece os atributos de interesse e o modelo computacional responsável por manipular os dados de domínio desses atributos.

Basicamente, as entidades nesse diagrama correspondem aos conjuntos de dados e aos extratores de dados, sendo que os atributos das entidades representam os atributos dos conjuntos de dados ou os atributos obtidos pelos extratores, enquanto os relacionamentos descrevem como instâncias de uma transformação de dados (ou tarefas) consomem elementos de dados de um conjunto e produzem elementos de dados em outro conjunto, ou como dados científicos extraídos estão associados aos elementos de dados de um conjunto.

Ou seja, os relacionamentos são fundamentais para a descrição das dependências de dados e do processo de extração de dados científicos.

Considerando o script para a contagem de palavras da Figura 14, a Figura 20 mostra as instâncias da entidade occurrences, que correspondem aos elementos de dados do conjunto de dados occurrences para uma execução dessa simulação computacional.

Enquanto isso, a Figura 21 mostra instâncias do relacionamento count_words, que considera o consumo de vários elementos de dados do conjunto occurrences (instâncias da entidade occurrences) por uma instância da transformação de dados count_words para produzir apenas um elemento de dados no conjunto counts (instâncias da entidade counts). Por A partir da especificação dos conjuntos de dados e dos extratores, o próximo passo consiste na modelagem lógica realizada apenas pelo especialista em ciência da computação.

Nesse caso, os conceitos envolvidos no diagrama ER da Figura 19 são mapeados em um modelo de dados lógico. Primeiramente, cada entidade do diagrama ER para os dados de domínio é mapeada em uma nova relação no modelo de dados lógico, a fim de representar um conjunto de dados, em que as tuplas da relação correspondem aos elementos de dados, ou um extrator, em que as tuplas da relação correspondem aos dados científicos extraídos de arquivos. A Figura 22 mostra esse modelo de dados lógico, em que as relações dos conjuntos de dados são nomeadas com um prefixo "ds_" acrescido do rótulo do conjunto de dados (e.g., a relação ds_input_files foi criada para o conjunto de dados input_files).

Além disso, cada atributo de uma entidade do diagrama ER é representado por um campo na sua respectiva relação. Em termos de mapeamento, se o atributo for do tipo arquivo, então o seu campo adotará o tipo inteiro com uma restrição de chave estrangeira para o campo id da relação file. Isso evidencia que todos os arquivos manipulados pela nossa solução, mesmo que sejam expressos em um conjunto de dados ou um extrator, são armazenados na relação file e, consequentemente, associados à instância da transformação de dados (campo task_id) responsável pela sua geração.

Figura 22. Modelo de dados lógico para os dados de domínio capturados no exemplo da Figura 14.

Uma vez criadas as relações para os conjuntos de dados e os extratores, os relacionamentos do diagrama ER são avaliados. Para os relacionamentos entre dois conjuntos de dados, temos que, semanticamente, uma instância de uma transformação de dados específica foi executada para consumir elementos de dados de um conjunto e produzir elementos de dados em outro conjunto. Assim, um novo campo é criado em cada relação do conjunto de dados para identificar as instâncias dessa transformação envolvidas na manipulação de elementos de dados. Esse novo campo apresenta o rótulo da transformação de dados acrescido do sufixo "_id", e.g., os campos identify_occurrences_id nas relações ds_lines e ds_occurrences obtidos do relacionamento identify_occurrences_id.

Além da criação do campo para as instâncias da transformação de dados, uma restrição de chave estrangeira é definida desse campo para o campo id da relação task, a fim de garantir a integridade referencial. Ao mesmo tempo, uma restrição é definida para expressar o relacionamento entre elementos de dados de dois conjuntos de dados distintos em função das instâncias de uma transformação. Esse relacionamento é fundamental na análise exploratória de dados científicos, pois ele permite a análise do rastro dos dados de proveniência no nível físico (Subseção 3.2.4), ou seja, ele favorece a investigação do fluxo de elementos de dados em uma simulação computacional utilizando as instâncias de uma transformação para associar elementos de dados de diferentes conjuntos de dados. 

Modelagem das consultas

Nas fases anteriores, vimos como uma simulação computacional pode ser representada por um fluxo de dados, assim como os dados de proveniência e do domínio científico podem ser modelados em uma base de dados que segue o nosso modelo de dados lógico. Nesse contexto, os usuários do domínio científico estão frequentemente interessados em realizar análises baseadas apenas na especificação do fluxo de dados (i.e., dados de proveniência prospectiva) ou análises exploratórias dos dados científicos manipulados pela simulação computacional (i.e., dados de proveniência retrospectiva e dados científicos).

Como discutido no Capítulo 2, observamos três tipos mais frequentes de análises da segunda categoria, que consideram o acesso:

(i) ao conteúdo de arquivos de dados científicos;

(ii) aos múltiplos arquivos relacionados pelos programas de simulação; e (iii) aos elementos de dados relacionados por múltiplos arquivos.

Esta fase propõe uma abordagem baseada na virtualização dos dados, a fim de facilitar a modelagem das consultas, integrando os dados pertinentes nessas análises como visões de dados, segundo o nosso modelo de dados lógico. De forma mais específica, essa abordagem introduz um conjunto de definições de visões (RAMAKRISHNAN e GEHRKE, 2003) para apoiar análises baseadas na estrutura do fluxo de dados, nos rastros de proveniência e nos dados científicos capturados de arquivos. Somando-se a isso, a visão em si consiste em uma relação, cujas tuplas não estão explicitamente armazenadas na base de dados, mas podem ser computadas a partir das definições de visões. Nesta subseção, discutimos também como as visões podem ser utilizadas na modelagem de cada tipo de análise mencionado anteriormente.

Para analisar as especificações de fluxo de dados armazenadas na base de dados, três definições de visões foram propostas para consultar o encadeamento das transformações em função dos conjuntos de dados (dataflows), os esquemas dos conjuntos de dados (datasetSchemas) e os programas de simulação utilizados por cada transformação de dados (programs). A definição da visão dataflows realiza uma consulta com a cláusula SELECT aos dados de proveniência prospectiva da nossa base de dados com o intuito de obter as especificações de fluxo de dados, ou seja, as dependências de dados dos fluxos de dados registrados. Como resultado, uma visão, ou uma relação, é apresentada com os rótulos Além disso, metadados adicionais podem estar relacionados aos conjuntos e às transformações de dados, como os atributos presentes em cada conjunto de dados (visão datasetSchemas) e os programas de simulação executados por cada transformação de dados (visão programs). Considerando novamente o script de contagem de palavras, mas agora assumindo que as operações nos RDDs (conjunto de dados usando o Spark) de cada transformação de dados foram especificadas, separadamente, em um arquivo com a extensão da linguagem de programação Python, a Figura 27 mostra uma visualização da especificação do seu fluxo de dados na perspectiva de grafos com os metadados adicionais (atributos de cada conjunto e os programas executados por cada transformação).

Somando-se a essas visões de dados de proveniência prospectiva, introduzimos também definições de visões para apoiar os três tipos frequentes de análises exploratórias de dados científicos. Nesse contexto, observamos que essas análises são baseadas em três conceitos da nossa abstração de fluxo de dados: arquivo, elemento de dados (considerando a extração de dados científicos) e instância da transformação de dados (ou tarefa). No que diz respeito aos arquivos, os usuários estão interessados em saber quais arquivos foram consumidos e produzidos por determinadas instâncias de transformações de dados. Em relação aos conjuntos de dados, os usuários investigam os elementos de dados manipulados pelas instâncias de transformações de dados durante a execução da simulação computacional, sendo que esses elementos podem ser capturados, inclusive, por extratores de dados científicos (Subseção 5.2.2). Portanto, observa-se que os dois primeiros conceitos dependem da definição de instância de uma transformação de dados. Além disso, essas análises podem ser do tipo que acessa o conteúdo de apenas um arquivo de dados científicos (instâncias de apenas uma transformação de dados) ou dos tipos que acessam múltiplos arquivos e elementos de dados relacionados, que envolvem consultas mais complexas para investigar o fluxo de arquivos e de elementos de dados em função de instâncias de múltiplas transformações de dados executadas pela simulação computacional. Em outros cenários, as consultas aos dados científicos podem ser mais complexas, exigindo a análise do fluxo de arquivos e de elementos de dados em função de instâncias de diferentes transformações de dados executadas pela simulação computacional. Assim, para que seja possível realizar esse tipo de análise, os elementos de dados dos conjuntos de interesse precisam estar acessíveis (uso das visões de conjunto de dados), assim como o usuário precisa ter conhecimento do encadeamento dos conjuntos de dados para saber como relacionar os conjuntos de dados relevantes (uso da visão dataflows, filtrando apenas as dependências de dados envolvidas no fragmento do fluxo de dados de interesse). Visto que o usuário conheça o encadeamento dos conjuntos e saiba quais conjuntos precisam ter os seus elementos de dados consultados, ele precisa definir quais atributos de junção devem ser utilizados para associar elementos de dados entre dois conjuntos.

Segundo as discussões da Subseção 3.2.4, os rastros de proveniência podem ser de dois níveis, físico e lógico, em que os atributos das instâncias das transformações de dados ou do domínio, respectivamente, são utilizados para associar os elementos de dados presentes nas visões dos conjuntos de dados. De um ponto de vista mais prático, a Figura 29 mostra como os conjuntos de dados podem ser associados utilizando os atributos das tarefas (e.g., campo get_lines_id das visões input_files e lines) ou do domínio (e.g., campo

word das visões occurrences e counts) na simulação de contagem de palavras. Figura 30. Consulta para a análise do fluxo de elementos no exemplo de contagem de palavras.

Operações para a captura e a carga de dados de proveniência e de domínio

Para facilitar as diferentes atividades presentes na nossa metodologia, a DfAnalyzer introduz um conjunto de operações focadas na captura de dados de proveniência prospectiva (i.e., especificação do fluxo de dados) e retrospectiva (i.e., tarefas), na invocação de extratores de dados científicos, e na captura dos dados de domínio produzidos pela simulação computacional. Esta subseção está dividida em três partes com o objetivo de descrever cada categoria dessas operações disponibilizada pela biblioteca de componentes DfAnalyzer.

Operações para a especificação do fluxo de dados

Com o intuito de registrar a especificação do fluxo de dados na base de dados, seguindo o nosso modelo de dados lógico, a DfAnalyzer introduz um conjunto de cinco operações para capturar e armazenar os dados de proveniência prospectiva (Tabela 4).

Dessas operações, algumas são mais gerais ao considerar os conceitos de fluxo de dados, como dataflow, dataset e transformation. Por outro lado, existem operações que proveem metadados adicionais, como os programas de simulação executados pelas transformações de dados (program) e os extratores utilizados para a captura de dados científicos (extractor).

Vale destacar que o termo extrator foi utilizado para descrever, de uma forma mais geral, o processo de captura de dados científicos, considerando o acesso, a extração e, eventualmente, a indexação de dados científicos presentes em arquivos. Figura 31. Exemplo de dependência de dados: t2 depende de t1.

Como cada relação no modelo de dados inicialrelações para os dados de proveniência prospectiva e as relações task e filecorresponde à um conceito da abstração de fluxo de dados, a execução de uma operação de proveniência prospectiva (Tabela 4) implica em adicionar tuplas em uma ou mais dessas relações. Além disso, as operações de especificação do fluxo de dados executam consultas de criação de outras relações para armazenar os dados de proveniência retrospectiva e de domínio (i.e., relações dos conjuntos de dados e dos extratores de dados científicos).

No 

Operação para a captura de dados científicos

Em virtude da necessidade de análises de dados científicos presentes em arquivos, o especialista em ciência da computação, em um trabalho de colaboração com o usuário do domínio científico, frequentemente define extratores de dados científicos na especificação do fluxo de dados. Desse modo, antes de capturar e armazenar os dados de proveniência retrospectiva e de domínio na nossa base de dados, os dados científicos de interesse precisam ser efetivamente extraídos. Para isso, esses usuários precisam realizar ajustes no código fonte dos seus programas de simulação (e.g., script em Python usando Spark) para invocar esses extratores de dados científicos.

Do ponto de vista computacional, um extrator de dados científicos é responsável por acessar o conteúdo presente em arquivos, realizar as análises léxica e sintática desse conteúdo para identificar apenas os dados relevantes, selecionar os conjuntos de dados científicos de interesse, indexar os dados, quando necessário, e prepará-los para serem armazenados na base de dados (Seção 4.3). Assim, pela invocação de um extrator, dados ainda alocados em memória, que necessitam da invocação de tecnologias para o processamento de dados científicos in situ, ou armazenados em arquivos, que necessitam da invocação de programas ad-hoc ou de ferramentas alternativas, podem ser capturados e armazenados na relação desse extrator (Definição 5.2.4).

Como mencionado, esse processo de captura de dados científicos envolve diferentes etapas. As duas abordagens comumente utilizadasextração e indexação de dadoscompartilham do mesmo comportamento na maioria dessas etapas. Assim, esta tese procurou formalizar o comportamento de cada etapa, inspirando-se em operações da álgebra relacional, para, depois, descrever uma operação genérica para a captura de dados científicos. A principal vantagem de associar essas etapas às operações da álgebra relacional consiste no fato dos resultados, vistos como conjuntos de dados na abstração de fluxo de dados, serem representados como uma relação. Consequentemente, os dados científicos capturados já estariam prontos para serem carregados nas relações dos extratores, segundo o nosso modelo de dados lógico (e.g., relação ext da Figura 19). As etapas a serem descritas formalmente são as seguintes:

(1) Acesso aos dados científicos;

(2) Projeção de dados científicos;

(3) Seleção de dados científicos de interesse; e (4) Indexação de dados científicos.

Com o objetivo de obter os dados científicos presentes em um arquivo manipulado por uma instância de uma transformação de dados, o acesso aos dados científicos é caracterizado por duas análises, conhecidas como léxica e sintática, como discutido na Seção 4.2. Em soluções para a análise de dados científicos, o alfabeto para a análise léxica está normalmente presente em um catálogo de dados científicos, que consiste em um conjunto de metadados necessários para a compreensão do alfabeto adotado em cada formato de arquivo ou mesmo em estruturas de dados em memória. A partir dos símbolos gerados na análise léxica, a análise sintática transforma a sequência de caracteres de entrada em uma estrutura de dados conhecida (e.g., número em ponto flutuante). Semelhante à análise léxica, a análise sintática também precisa ter acesso ao catálogo de dados científicos, uma vez que ele contém metadados sobre os atributos e as suas estruturas de dados.

Assumimos também que um arquivo pode conter diversos elementos de dados. Assim, inspirados em uma abordagem relacional, esses elementos de dados seriam equivalentes a tuplas em uma relação. Com o intuito de formalizar essa etapa, esta tese define o acesso aos dados científicos. Em muitos casos, os usuários do domínio científico estão interessados apenas em determinados atributos de interesse. Logo, eles não exigem que todos os atributos presentes nos elementos de dados de um arquivo sejam capturados. Esse comportamento é característico da etapa de projeção de dados científicos, sendo descrito por uma fragmentação vertical da relação de dados acessados. Nesta tese definimos formalmente a projeção de dados científicos, inspirada no operador relacional de projeção.

Definição 5.2.9. (Projeção de Dados Científicos) A projeção de dados científicos é uma operação de fragmentação vertical da relação de dados acessados 𝑟 𝑎𝑐𝑐𝑒𝑠𝑠 de um arquivo para obter apenas um subconjunto de atributos 𝐴 ′ , tal que 𝐴 ′ ⊂ 𝑆𝑐ℎ𝑒𝑚𝑎(𝑟 𝑎𝑐𝑐𝑒𝑠𝑠 ). Após essa operação, uma relação 𝑟 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑖𝑜𝑛 é produzida, de forma que 𝑟 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑖𝑜𝑛 ← 𝜋 𝐴 ′ (𝑟 𝑎𝑐𝑐𝑒𝑠𝑠 ).

Após a captura de apenas alguns atributos de interesse, os usuários do domínio científico definem, em diversas circunstâncias, condições para obterem apenas elementos de dados em regiões de interesse. Logo, eles comumente desejam obter um subconjunto de todos os elementos presentes em um arquivo, sendo esta etapa definida como seleção de dados científicos. Esta tese define formalmente a seleção de dados científicos, inspirandose no operador relacional de seleção.

Definição 5.2.10. (Seleção de Dados Científicos) A seleção de dados científicos é definida pela fragmentação horizontal da relação de dados projetados 𝑟 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑖𝑜𝑛 que produz uma relação 𝑟 𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛 apenas com os elementos de dados que atendem a um conjunto de condições de seleção ∁, de forma que 𝑟 𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛 ← 𝜎 ∁ (𝑟 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑖𝑜𝑛 ).

Além dessas três etapas, quando as relações de dados apresentam grandes volumes de dados ou determinados valores de atributos precisam representar estruturas de dados mais complexas, técnicas de indexação de dados científicos são empregadas para reduzir o espaço de armazenamento da relação de dados e para prover um acesso eficiente aos dados científicos durante o processamento de consultas. Dessa forma, a etapa de indexação de dados científicos (Definição 5.2.11) cria índices para determinados elementos de dados ou tuplas, definindo quais atributos devem ser favorecidos por essa técnica. Embora as etapas para a captura de dados científicos tenham sido apresentadas de uma forma encadeada, apenas a etapa de acesso aos dados científicos é obrigatória. Logo, as outras etapas são vistas como opcionais e podem ter a sua ordem de execução alterada de acordo com o programa de captura de dados científicos. Por uma questão de desempenho, adotamos as mesmas prioridades empregadas pela álgebra relacional para a execução das etapas descritas anteriormente. A partir dessas definições, a DfAnalyzer introduz a operação extract (traduzida como extrair) para permitir a captura de dados científicos baseadas na invocação de programas ad-hoc e de ferramentas alternativas. Embora o seu nome induza a pensar em uma abordagem de extração de dados científicos, na verdade, essa operação permite que ambas as abordagens sejam empregadas, ou seja, tanto a extração, como a indexação de dados científicos.

Em outra perspectiva, essa operação é responsável por invocar um programa ad-hoc 𝜌 que realiza o acesso aos dados científicos presentes em um arquivo 𝜑 de acordo com um catálogo de dados 𝜍, a projeção dos dados científicos para os atributos de interesse 𝐴 ′ e a seleção de valores de atributos segundo um conjunto de condições de seleção 

Assumindo-se novamente o script em Python usando Spark para a contagem de palavras (Figura 14), podemos observar que os seus resultados são armazenados em arquivos binários, e.g., output.bin. Supondo que os usuários do domínio científico desejem analisar determinados valores de atributos presentes nesses arquivos, como a palavra (atributo word) e o seu número de ocorrências em todos os arquivos de entrada (atributo count), a nossa abordagem utiliza, portanto, a operação extract para capturar esses dados científicos de interesse. A Figura 33 apresenta esse exemplo com a especificação dessa operação, em que o programa ad-hoc extractRDF extrai elementos de dados de um arquivo no formato binário para os atributos de interesse (word e count), quando o número de ocorrências de uma palavra é maior que 10 (condição de seleção count > 10). Figura 34. Operação de indexação de dados científicos.

Em cenários reais para apoiar a captura de dados científicos, o usuário do domínio científico precisa realizar ajustes nos seus programas de simulação com a ajuda do especialista em ciência da computação, a fim de que as invocações da operação extract sejam adicionadas. No exemplo de contagem de palavras em arquivos, o script em Python não permite, originalmente, a captura de dados científicos. Por isso, a inserção de apenas uma linha de código foi realizada para apoiar a extração de dados científicos, como mostrado na Figura 23. Esse exemplo corresponde à operação de captura de dados científicos realizada pelo extrator ext da Figura 32, sendo os seus dados armazenados na relação do extrator ext de acordo com o nosso modelo de dados lógico.

Operações para a captura de dados de proveniência retrospectiva e de domínio

Com a especificação do fluxo de dados no nosso modelo de dados lógico e os ajustes realizados nos programas de simulação para a captura de dados científicos, os usuários possuem uma visão geral das transformações de dados e dos conjuntos de dados manipulados. Ademais, eles têm conhecimento de quais arquivos são investigados e como os dados científicos foram capturados. Entretanto, a DfAnalyzer ainda não armazena os dados de proveniência retrospectiva e de domínio na nossa base de dados durante a execução da simulação computacional. Para atender a essa questão, a DfAnalyzer introduz outras quatro operações, como mostrado na Tabela 5, que devem ser invocadas em tempo de execução de acordo com ajustes realizados nos programas de simulação pelo usuário do domínio científico em colaboração com o especialista em ciência da computação. Já a Figura 36(d) apresenta um caso em que a tarefa 𝑡 12 da transformação de dados 𝑑𝑡 2 depende dos dados produzidos por duas tarefas da transformação de dados 𝑑𝑡 1 , mas pertencentes a duas iterações diferentes, isto é, 𝑡 1 1 e 𝑡 2 1 . Dessa forma, a invocação da operação dependency terá apenas uma transformação de dados especificada em transformations (𝑑𝑡 1 ), mas duas iterações de tarefas dependentes para essa transformação de dados no argumento dependentTasks (𝑡 1 1 e 𝑡 2 1), como apresentado a seguir:

dependency(𝑡 1 2 , {𝑑𝑡 1 }, {(1); (2)}).
Por último, a Figura 36(e) mostra um cenário em que duas tarefas de diferentes iterações de uma mesma transformação de dados (𝑑𝑡 2 ), 𝑡 1 2 e 𝑡 2 2 , dependem dos mesmos dados gerados pela tarefa 𝑡 1 1 da transformação de dados 𝑑𝑡 1 , de maneira que duas invocações da operação dependency são realizadas: dependency(𝑡 1 2 , {𝑑𝑡 1 }, {(1)}) e dependency(𝑡 2 mesma transformação (de diferentes iterações) consumindo a mesma coleção de dados não representam um comportamento intuitivo, apesar da sua importância em cenários em que as transformações de dados envolvem a execução de modelos computacionais nãodeterminísticos, pois uma nova iteração (isto é, nova tarefa) pode produzir resultados diferentes a partir de uma mesma coleção de dados de entrada.

Considerando as operações introduzidas nessa subseção, a nossa abordagem favorece a captura de dados de proveniência retrospectiva e de domínio (dados científicos) produzidos pelas simulações computacionais em tempo de execução. Para isso, o usuário do domínio científico trabalha em colaboração com o especialista em ciência da computação para modificar os seus programas de simulação a fim de capturar esses dados no nível de granularidade adequado para as suas análises futuras. Como resultado, a nossa metodologia evita que dados não relevantes sejam armazenados na base de dados ou que dados importantes não estejam disponíveis durante as análises. Ao mesmo tempo, por permitir que os usuários carreguem apenas os dados científicos de interesse, a DfAnalyzer também contribui ao minimizar o custo de captura e de carga dos dados na base de dados.

Componentes da DfAnalyzer

A DfAnalyzer é composta de três camadas, conhecidas como Painéis, Serviços de Fluxo de Dados e Armazenamento, conforme mostrado na Figura 37. Essas camadas apresentam, no total, seis componentes e uma base de dados para armazenar os dados de proveniência e de domínio (dados científicos), sendo representados como retângulos arredondados com a cor de fundo branca.

A camada Painéis disponibiliza dois componentes com recursos gráficos que favorecem a análise dos fluxos de dados gerados pelas simulações computacionais. Já a camada Serviços de Fluxo de Dados apresenta quatro componentes responsáveis pela extração de dados de proveniência e de dados científicos, a indexação de dados extraídos, assim como a submissão de consultas para a sua base de dados. Por último, a camada Armazenamento é responsável por organizar os arquivos de dados científicos e a base de dados no sistema de arquivos utilizado pelo ambiente computacional. De forma mais detalhada, as subseções seguintes apresentam cada componente dessas camadas. Ainda em relação ao funcionamento do PDE, diferentes pacotes foram desenvolvidos em linguagens de programação distintas (e.g., Java, Python e C++) para facilitar a captura de dados de proveniência retrospectiva em programas de simulação por meio de um método genérico, conhecido como capture (que pode ser traduzido para capturar, em português). Esse método realiza a invocação de requisições HTTP para o serviço RESTful do PDE (URL /pde/task) a partir do código fonte modificado dos programas de simulação. Esse método é frequentemente invocado duas vezes: antes e após uma tarefa (ou instância de uma transformação de dados).

Antes da execução da tarefa, o método capture é invocado para indicar o momento em que a tarefa inicializará, consumindo uma coleção de dados específica (i.e., conjunto de elementos de dados de entrada). Após a execução da tarefa, esse método é invocado novamente para indicar o término da tarefa e capturar a coleção de dados produzida. Assim, a invocação do método capture pode ser representada conforme a equação a seguir, em que fluxo corresponde ao rótulo do fluxo de dados; transformação corresponde ao rótulo da transformação de dados; iteração corresponde à iteração da tarefa executada; estado representa o estado da tarefa, que pode ser RUNNING, FINISHED ou FINISHED_WITH_ERRORS; e coleções corresponde às coleções de dados manipuladas pelos conjuntos de dados. As coleções de dados podem ser inicializadas pelo método createDataElement para criar um elemento de dados de acordo com os valores de atributos apresentados pelo usuário. Esses valores de atributo seguem a mesma sequência em que os atributos do conjunto de dados de interesse (primeiro parâmetro desse método) foram definidos.

PDE.capture(<fluxo>, <transformação>, <iteração>, <estado>, <coleções>)

Considerando um programa de simulação real em dinâmica de fluidos computacionais, apresentamos a seguir um exemplo de ajustes no código fonte desse programa, que utiliza a biblioteca libMesh [START_REF] Kirk | libMesh : a C++ library for parallel adaptive mesh refinement/coarsening simulations[END_REF], vista como uma caixa preta pela DfAnalyzer. Nesse exemplo, as duas invocações do método capture ocorrem antes e após a transformação de dados de interesse. Além disso, essas invocações podem ser realizadas diversas vezesou seja, diferentes iterações de tarefas para essa transformação -, pois existe um loop que realiza inúmeras iterações não lineares para simular o comportamento do fluido e dos sedimentos em um tanque ou numa bacia sedimentar.

/for (nli_counter = 0; nli_counter < max_nl_iteractions; ++nli_counter) { // provenance -input dataset to transformation flow solver PDE->capture("sedimentation", "Flow_Solver", taskIter, "RUNNING", NULL); // How many iterations were required to solve the linear system? this->linear_iteractions += flow_system.n_linear_iterations(); // provenance -output dataset to transformation flow solver dataElement = PDE->createDataElement("oflow_solver", t_step, dt, time, r_step, nli_counter, linear_iteractions, flow_system.final_linear_residual(), norm_delta, norm_delta / u_norm, !diverged); PDE->capture("sedimentation", "Flow_Solver", taskIter, "FINISHED", dataElement); } (7) Apesar de não ser apresentado nesse exemplo, as coleções de dados também podem envolver conteúdo específico presente em arquivos ou estruturas de dados alocadas em memória. Nesse cenário, a DfAnalyzer possui dois componentes para apoiar a extração e a indexação de dados científicos presentes em arquivos, conhecidos como Extrator de Dados Científicos (do termo em inglês Raw Data Extractor -RDE) e Indexador de Dados Científicos (do termo em inglês Raw Data Indexer -RDI), respectivamente.

Pelo fato de seguir a arquitetura ARMFUL, as implementações de algoritmos para Somando-se a isso, existem cenários em que as estruturas de dados ou o volume de dados não favorecem a extração de dados científicos em função do custo de carga dos dados em uma base de dados. Nessas circunstâncias, técnicas de indexação são comumente aplicadas para permitir o acesso, de forma eficiente, aos dados científicos. Assim, de forma complementar à extração de dados científicos, o componente RDI foi proposto para gerar índices para os dados científicos acessados. Nesse sentido, três cartuchos foram desenvolvidos: CSV, FastBit e PostgresRaw. O cartucho CSV gera índices posicionais para os dados científicos acessados em arquivos no formato CSV, semelhante à implementação do NoDB [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF]. Já o cartucho FastBit consiste no uso da ferramenta FastBit [START_REF] Wu | FastBit: interactively searching massive data[END_REF] para gerar índices bitmaps para os dados científicos acessados. E, por último, o cartucho PostgresRaw [START_REF] Alagiannis | NoDB: efficient query execution on raw data files[END_REF] consiste no uso da ferramenta alternativa com o mesmo nome para gerar índices posicionais.

Já o componente RDI conta com o método index (do termo, em português, indexar) e os mesmos argumentos do método extract, acrescido apenas dos atributos a serem indexados (argument atributos) e de propriedades extras (argumento extra) para os algoritmos aplicados pelos seus cartuchos. Essas propriedades extras devem ser informadas no formato de invocação por linha de comando adotado por essas ferramentas. Por exemplo, o cartucho FastBit permite definir quais tipos de codificação, de compressão e de precisão podem ser adotados ao gerar os índices.

RDI.index(<extrator>, <cartucho>, <arquivo>, <atributos>, <extra>) (9) No caso do FastBit, o seu cartucho foi resultado de um trabalho em colaboração com o M.Sc. José Vitor Leite, em que se utilizou essa ferramenta alternativa para gerar índices do tipo mapa de bits para dados científicos em uma simulação de dinâmica de fluidos computacionais (SILVA et al., 2017b). Mais especificamente, esse trabalho considerou a exploração das diferentes combinações de algoritmos providos pelo FastBit de acordo com a estrutura dos dados produzidos por essa simulação computacional.

Além da sintaxe contemplar a indexação de dados científicos, o processo de acesso a esses dados por meio dos índices gerados foi implementado para cada cartucho, sendo representado pelo método access (do termo, em português, acessar). Esse método requer como argumentos o cartucho utilizado no processo de indexação (cartucho), os atributos a serem acessados (atributos), os índices (índices) a serem utilizados para acessar os dados científicos, e o caminho para o arquivo de dados científicos (arquivo).

RDI.access(<cartucho>, <atributos>, <índices>, <arquivo>) (10) Após o processo de captura de dados de proveniência e dos dados científicos utilizando os componentes PDE, RDE e RDI, esses componentes realizam a carga dos dados capturados em uma base de dados utilizando o SGBD relacional orientado a coluna MonetDB [START_REF] Boncz | Breaking the memory wall in MonetDB[END_REF]. O MonetDB foi escolhido pelo fato de apresentar algoritmos eficientes de indexação tardia dos dados, favorecendo a carga de grande volume de dados (ideal para o cenário de extração em larga escala); de apoiar a gerência de arquivos de dados científicos por meio da análise sintática de dados científicos; de realizar a carga parcial de dados científicos a partir de arquivos; e de apresentar um mecanismo eficiente de processamento de consultas.

A Figura 39 apresenta o diagrama de sequência para essas duas etapas: offline e online. Na etapa offline, o usuário do domínio científico precisa modelar o fluxo de dados de acordo com as transformações, os conjuntos de dados e as suas dependências de dados envolvidas na simulação computacional. Logo, essa etapa é manual, uma vez que exige desse usuário ajustes nos códigos fontes dos programas de simulação para invocar os diferentes componentes da DfAnalyzer, como o PDE, RDE e RDI. Enquanto isso, a etapa online lida com a extração dos dados de proveniência e dos dados científicos durante a execução dos programas de simulação modificados. Somando-se à extração, essa etapa automática também contempla a carga dos dados extraídos na base de dados da nossa biblioteca de componentes por meio do envio de requisições para os serviços RESTful da DfAnalyzer. Além desses componentes, a DfAnalyzer apresenta o componente Interface de Consulta (do termo em inglês Query Interface e da sigla QI), que auxilia os usuários a submeterem consultas para a base de dados e obtém os resultados das consultas. A DfAnalyzer permite o processamento de consultas por meio do desenvolvimento da consulta em uma sintaxe disponibilizada pelo componente QI com os seguintes argumentos:

(i) nome e identificador do fluxo de dados registrado na base de dados que será analisado, (ii) os conjuntos de dados que serão usados como origem (i.e., conjuntos de dados de entrada) na busca de um fragmento do fluxo de dados, (iii) os conjuntos de dados que serão usados como destino, (iv) o tipo de mapeamento de atributos (físico, lógico ou híbrido, conforme discutido na Subseção 3.2.4), (v) os atributos a serem projetados (i.e., valores de atributos a serem obtidos após o processamento da consulta), (vi) as seleções de atributos a serem consideradas, semelhante ao processo de filtragem de dados, (vii) os conjuntos de dados que serão considerados nos caminhos possíveis do fragmento do fluxo de dados da consulta, e (viii) os conjuntos de dados que serão desconsiderados nos caminhos possíveis.

Nesse caso, as características do QI são mais próximas de um pré-processador de consultas, pois o mesmo não modificou as funcionalidades nativas dos SGBD utilizados ou dos processadores de consultas das ferramentas alternativas, como o FastBit.

Semelhante ao PDE, as funcionalidades do QI foram providas por meio de um serviço RESTful, em que os usuários submetem requisições HTTP para a URL /query_interface/{dataflow_tag}/{dataflow_id} com o método POST acrescido da especificação da consulta (como uma mensagem), conforme apresentado na Tabela 6. Essa URL considera os primeiros argumentos do QI, que consistem no nome e no identificador do fluxo de dados (dataflow_tag e dataflow_id). Enquanto isso, o restante da especificação da consulta deve estar presente na mensagem da requisição. Uma vez submetida a especificação da consulta para o QI, ele é responsável por processar a consulta automaticamente e retornar os resultados da consulta por meio de um ponteiro para um arquivo no formato CSV. Vale ressaltar que o desenvolvimento do QI e os seus resultados experimentais (com exceção do seu serviço RESTful) foram obtidos por meio da orientação dos projetos de graduação do Thiago Barroso Perrotta e da Débora Barbosa Pina. datasetTags contempla os rótulos dos conjuntos de dados que devem ser obrigatoriamente excluídos do fragmento do fluxo de dados a ser analisado Como exemplo de uso do QI em uma simulação de sedimentação (mais detalhes na Subseção 6.1.4), os usuários do domínio de dinâmica de fluidos computacionais comumente desejam analisar a concentração média de sedimentos em uma linha de pontos localizados no fundo de uma bacia sedimentar. A Figura 40 apresenta o fluxo de dados dessa simulação, em que os retângulos representam as transformações de dados e as setas correspondem aos conjuntos de dados. Diante dessa especificação do fluxo de dados, o usuário pode informar ao componente QI que precisa executar uma consulta em que o conjunto de dados de origem é o osolversimulationtransport; os conjuntos de dados de destino são oline2extraction e omeshwriter, pois além dos elementos de dados científicos, os usuários estariam interessados nos arquivos de dados científicos gerados; o tipo de mapeamento de atributos é físico, ou seja, utiliza os identificadores das tarefas para realizar as junções entre os conjuntos de dados; e os dados projetados contemplam o tempo da simulação computacional (atributo time no conjunto de dados osolversimulationtransport), a média da concentração de sedimentos (atributo d no conjunto de dados oline2extraction) e o ponteiro para os arquivos HDF5 gerados (atributo hdf5 no conjunto de dados omeshwriter). Dessa forma, as análises de dados permitidas pelo QI podem relacionar dados de proveniência e elementos de dados científicos, assim como referências para arquivos (i.e., o caminho para os arquivos de dados científicos ou de visualização). Outras análises ao fluxo de dados podem ser realizadas sem o componente QI, em que os usuários utilizam as visões dos conjuntos de dados para relacionar elementos de dados em diferentes conjuntos em função dos identificadores das tarefas (atributos com o sufixo task_id), como discutido na Subseção 5.2.3 da nossa metodologia. 

Armazenamento

Outra camada da nossa solução consiste no armazenamento de dados.

Especificamente, essa camada contempla o armazenamento dos dados científicos produzidos pelas simulações computacionais em arquivos e uma base de dados, que integra os dados de proveniência, os dados científicos extraídos de arquivos e os índices para o conteúdo de arquivos de dados científicos. Em termos de infraestrutura, o MonetDB é instanciado em um nó computacional diferente dos nós computacionais destinados à execução da simulação, a fim de evitar gargalos em termos de desempenho, particularmente associados às operações de leitura e escrita em disco. Entretanto, os serviços RESTful da DfAnalyzer são instanciados no mesmo recurso computacional do MonetDB. Ao mesmo tempo, questões relacionadas à tolerância e à recuperação em casos de falha da base de dados não fazem parte do escopo desta tese. Logo, esta tese assume um cenário de alta disponibilidade dos recursos utilizados pela DfAnalyzer, sem considerar ocorrências de falhas no nível de hardware. Por outro lado, os nossos experimentos consideraram uma análise de desempenho, em que medimos a sobrecarga em termos de tempo ao integrar a DfAnalyzer em uma simulação computacional em larga escala. Esses resultados são apresentados no capítulo de avaliação experimental.

Painéis

Somando-se aos componentes para os serviços de fluxo de dados e a infraestrutura para o armazenamento dos dados, a DfAnalyzer conta com uma camada chamada de Painéis para prover recursos gráficos capazes de facilitar a análise do fluxo de dados. Nesse sentido, a DfAnalyzer disponibiliza o componente Visualizador de Fluxo de Dados, do termo em inglês Dataflow Viewer (DfViewer). Esse componente permite que os usuários consultem as especificações de fluxo de dados já registradas na base de dados por meio de uma interface gráfica, que lista todos os fluxos de dados. Assim, o usuário pode escolher o fluxo de dados de interesse e uma visualização da especificação desse fluxo de dados é apresentada na perspectiva de conjuntos de dados, conforme a Figura 41. Ademais, os usuários são capazes de clicar nos conjuntos de dados para terem acesso aos seus esquemas, isto é, aos nomes e aos tipos dos atributos pertencentes ao conjunto de dados selecionado. Ainda no quesito análise de fluxo de dados, outro componente presente nessa camada consiste no Painel de Consulta (do termo em inglês Query Dashboard). A DfAnalyzer permite o processamento de consultas por meio da edição e submissão da consulta pela interface gráfica do Painel de Consulta e da invocação do componente QI com os seguintes argumentos: (i) os conjuntos de dados que serão usados na análise de um fragmento de dados, (ii) o tipo de mapeamento de atributos (físico, lógico ou híbrido, conforme discutido na Subseção 3.2.4), (iii) os atributos a serem projetados (i.e., valores de atributos a serem obtidos após o processamento da consulta), e (iv) as seleções de atributos a serem consideradas, semelhante ao processo de filtragem de dados. Nesse caso, esse componente utiliza esses argumentos para especificar uma consulta a ser executada pelo componente QI, considerando os dados de proveniência e os dados de domínio extraídos pelos componentes PDE, RDE e RDI. A Figura 42 apresenta uma visualização da interface do Painel de Consulta sendo utilizado em uma simulação de dinâmica de fluidos computacionais.

Figura 42. Interface gráfica para a especificação de consulta.

Capítulo 6-Avaliação experimental

Este capítulo apresenta os resultados obtidos utilizando as implementações da arquitetura ARMFUL, o SCC-A e a DfAnalyzer, para apoiar a captura e a análise de dados científicos. Para isso, quatro simulações computacionais foram modeladas (Seção 6.1) e executadas em três ambientes de Processamento de Alto Desempenho (PAD) (Seção 6.1.5), a fim de gerenciar o fluxo de dados gerado em tempo de execução. Os experimentos (Seções 6.3 e 6.3.6) realizados tiveram o objetivo de analisar os seguintes pontos: (i) custo da extração de dados científicos, variando-se ou não a carga de trabalho; (ii) custo de indexação dos dados científicos; (iii) custo de carga dos dados em uma base de dados usando um Sistema de Gerência de Banco de Dados (SGBD); (iv) custo da captura dos dados científicos, considerando uma abordagem de processamento de dados in situ; e (v) apresentação do apoio ao processamento de consultas na análise exploratória de dados científicos. Esses resultados experimentais foram publicados em diferentes artigos, conforme descrito na conclusão desta tese.

Simulações computacionais

Esta seção descreve as simulações computacionais modeladas e executadas nesta tese. Mais especificamente, apresenta-se quatro simulações computacionais executadas usando o SCC-A e a DfAnalyzer, alternadamente, de acordo com a natureza da aplicação científica utilizada. No caso das simulações computacionais de astronomia (Montage) e de óleo e gás (SyntheticOil&Gas e EdgeCFD), o SCC-A foi utilizado em ambientes de cluster computacional. Enquanto isso, a DfAnalyzer foi empregada na simulação computacional baseada no solucionador libMesh-sedimentation, uma vez que tal programa de simulação já utilizava uma biblioteca para apoiar a execução paralela. O Sistema de Gerência de Workflow Científico (SGWfC) SCC-A não pôde ser utilizado nesta última simulação pelo fato de não permitir a invocação de tarefas (execução de atividades do workflow) em múltiplos nós computacionais.

Montage

A partir do uso de um conjunto de ferramentas conhecido como Montage [START_REF] Jacob | Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking[END_REF], o workflow científico com esse mesmo nome provê aos astrônomos serviços para a construção de mosaicos personalizados no formato de arquivo FITS (do termo em inglês Flexible Image Transport System) [START_REF] Hanisch | Definition of the Flexible Image Transport System (FITS)[END_REF] A segunda transformação de dados (Projection) realiza o cálculo das projeções de acordo com as referências fornecidas pelos arquivos no formato FITS, a fim de que todas as regiões do espaço sejam projetadas em um mesmo plano. Por conseguinte, a transformação de dados Select Projections une todos os arquivos no formato FITS após as projeções em um determinado plano, que atendem à mesma construção de mosaico. A transformação de dados Create Uncorrected Mosaic lida com a criação do mosaico sem correções, ou seja, sem considerar as correções de cor e as interferências de sobreposição de regiões do espaço (presentes nos arquivos de formato FITS) a partir do conjunto de dados de saída da transformação de dados Select Projections.

Como resultado, essa transformação de dados apresenta uma execução consideravelmente mais rápida e gera como resultado uma imagem no formato JPG para representar o mosaico sem correções. Ainda nesse workflow científico, as outras transformações de dados ponderam as interferências das sobreposições de imagens e as correções de cor, a fim de gerar um arquivo no formato JPG como saída que corresponde ao mosaico personalizado com correções.

SyntheticOil&Gas

A segunda simulação computacional é baseada em um workflow científico sintético que reproduz o comportamento de uma execução de modelos reais no domínio de Óleo e Gás, chamada de SyntheticOil&Gas [START_REF] Ogasawara | An Algebraic Approach for Data-Centric Scientific Workflows[END_REF]. Esse workflow científico foi desenvolvido por meio do Scientific Workflow Benchmark (SWB) [START_REF] Chirigati | Evaluating Parameter Sweep Workflows in High Performance Computing[END_REF], um gerador de workflows científicos a serem usados com benchmarks. SWB é capaz de gerar workflows sintéticos baseado em especificações de transformações de dados que determinam o comportamento esperado de uma simulação computacional real. Esse workflow científico sintético é mostrado na Figura 44.

Em relação à composição desse workflow científico, a primeira transformação de dados (conhecida como A) realiza a fragmentação dos dados de entrada de acordo com um fator (termo em inglês split factor) [START_REF] Chirigati | Evaluating Parameter Sweep Workflows in High Performance Computing[END_REF]. Esse fator corresponde ao número de elementos de dados produzidos na saída após o consumo de um elemento de dados pela transformação de dados. Nesta tese, considerou-se um valor fixo de split factor igual a 240. Na sequência, o workflow científico conta com duas transformações de dados, sendo conhecidas como B e C, em que, para cada elemento de dados de entrada, apenas um elemento de dados de saída é produzido. As não linearidades devido ao termo convectivo na equação de Navier-Stokes (descreve o movimento do fluxo viscoso) são tratadas pelo algoritmo Newton-GMRES inexato [START_REF] Guerra | Uncertainty quantification in numerical simulation of particle-laden flows[END_REF]. Na solução desse algoritmo, no começo das iterações não- lineares em cada passo de tempo, o algoritmo calcula passos por meio de tolerâncias mais elevadas, produzindo passos não-lineares mais rápidos. Conforme as iterações progridem em direção à solução, o método não-linear inexato se adapta de acordo com as tolerâncias GMRES para alcançar a acurácia desejada. A tolerância, cujo sistema linearizado é resolvido, conhecido como termo de força, apresenta um papel importante no desempenho numérico desse método. Para melhorar a robustez desses métodos, eles precisam ser empregados com estratégias de globalização, que contemplam procedimentos auxiliares que aumentam a convergência da solução, quando boas aproximações iniciais para a solução não estão disponíveis. O EdgeCFD apresenta quatro alternativas para a definição desse termo de força, ou seja, quatro valores diferentes para o atributo de entrada dessa propriedade.

Como motivação para a escolha desta simulação computacional, esta tese considerou o grande volume de dados manipulados por esse workflow. Para facilitar a carga desses dados em um repositório externo ou uma base de dados, esta tese considerou o uso de ferramentas alternativas, como a biblioteca ParaView (AYACHIT, 2015) e a ferramenta FastBit [START_REF] Wu | FastBit: interactively searching massive data[END_REF], que realizam o acesso aos dados científicos a partir de arquivos com formatos heterogêneos e a geração de índices, respectivamente.

A Figura 45 mostra o workflow EdgeCFD. Nesse workflow, apenas as atividades

EdgeCFD Pre e EdgeCFD Solver usam os programas de simulação binários do EdgeCFD (i.e., programas edgecfdPre e edgecfdSolver, respectivamente), enquanto as outras atividades executam os programas uncompressDataset, preProcessing, e setSolverConfiguration para lidar com conjuntos de dados compactados, arquivos de configuração para executar os binários do EdgeCFD, e dados científicos armazenados em arquivos nos formatos XDMF e HDF516 , respectivamente.

A atividade EdgeCFD Pre consome um conjunto de dados de entrada (i.e., malha representada pelo atributo MESH) e define as propriedades da malha (i.e., fragmentação para permitir o processamento paralelo e a reordenação nodal para melhorar a localidade dos dados) a serem empregadas no solucionador de dinâmica de fluidos computacionais (do termo, em inglês, Computational Fluid Dynamicssigla CFD). Esse solucionador é executado na atividade EdgeCFD Solver. Dessa forma, a atividade EdgeCFD Solver consome os arquivos gerados pela atividade EdgeCFD Pre (após serem organizados pela atividade Set Solver Configuration) e calcula o comportamento de um fluido em uma malha específica ao longo do intervalo de tempo predefinido para essa simulação computacional. Além disso, os usuários podem variar os valores dos atributos de entrada. A execução dessas múltiplas combinações de valores para os atributos de entrada descreve um cenário de varredura de parâmetros [START_REF] Raicu | Many-task computing for grids and supercomputers[END_REF], em que os usuários avaliam as suas hipóteses científicas a partir de ajustes ou "perturbações" nos dados de entrada. O libMesh-sedimentation emprega um método de elementos finitos multi-escala variacional [START_REF] Camata | In situ visualization and data analysis for turbidity currents simulation[END_REF], SILVA et al., 2016a, 2017a), em que uma abordagem escalonada é usada para evoluir em relação ao tempo as equações de fluido-sedimento acopladas. Esse solucionador também permite a adaptatividade no tempo (AHMED e [START_REF] Ahmed | Adaptive time step control for higher order variational time discretizations applied to convection-diffusion-reaction equations[END_REF][START_REF] Valli | Control strategies for timestep selection in finite element simulation of incompressible flows and coupled reaction-convection-diffusion processes[END_REF]. Contudo, a descoberta de quais dados precisam ser analisados e decidir por ajustes finos na simulação pode ser difícil, uma vez que os dados estão frequentemente espalhados em diferentes arquivos e desconectados do passo de tempo correspondente.

A Figura 47 mostra as principais transformações de dados da simulação Os parâmetros do solucionador linear e não-linear são os mesmos do estudo de caso anterior. As condições de contorno de velocidade de não penetração e não escoamento são definidas para as paredes do canal e as paredes do tanque que estão em contato com o canal.

As outras paredes apresentam condições que não investigam o escoamento (do termo, em inglês, free slip condition). Os sedimentos são injetados no canal com uma velocidade de magnitude de 0,1.

Multifísica

Além das simulações computacionais já descritas, esta tese também considera uma aplicação de CSE da área de multifísica que simula as interações entre dois fluidos num sistema inicialmente instável no qual a massa é constante e os fluidos encontram-se inicialmente misturados. O objetivo da aplicação é descobrir a partir de qual instante de tempo os dois fluidos passam a ficar completamente separados. Esse sistema pode ser modelado utilizando a equação de Cahn-Hilliard que descreve um processo binário de separação de fluidos e pode ser resolvida utilizando métodos numéricos, como métodos de elementos finitos. Essa aplicação de CSE utiliza as ferramentas disponibilizadas pelo projeto FEniCS [START_REF] Alnaes | The FEniCS Project Version 1[END_REF], que permite modelar esse sistema físico utilizando a equação de Cahn-Hilliard e os métodos de elementos finitos para resolvê-la. Do ponto de vista de uso dessa simulação computacional, esta tese considerou a execução em um ambiente local, ou seja, em um computador pessoal com um processador Intel Core i7-5500U e 8GB de memória RAM usando o sistema operacional Ubuntu 16.04 LTS.

Ambientes de Processamento de Alto Desempenho (PAD)

As simulações computacionais apresentadas foram executadas em três ambientes de Já no tanque real de batimetria, um script do ParaView Catalyst foi desenvolvido com a opção de prover visualizações quanto ao mapa de depósito durante a execução da simulação computacional, sendo que a frequência de invocação do Catalyst é 50 vezes maior que a frequência para a escrita de arquivos de dados científicos. Semelhante ao estudo de caso anterior, o tanque real de batimetria também considera a extração de quatro linhas de interesse da malha pelo adaptador Catalyst ao longo da execução da simulação computacional.

Avaliação de custos

Nesta tese realizamos seis avaliações experimentais com o propósito de analisar o comportamento da ARMFUL em execuções reais, analisando especificamente os seguintes custos:

• Custo da extração de dados científicos: Medida de custo para extrair dados científicos usando o workflow científico Montage no SGWfC SCC-A. O custo de extração consiste no tempo decorrido no processamento do arquivo de dados científicos, no acesso ao conteúdo do arquivo, na indexação dos dados obtidos e no armazenamento dos dados em uma base de dados de proveniência;

• Cargas de trabalho para a extração de dados científicos: Avaliação do custo da extração de dados científicos usando diferentes cargas de trabalho nos workflows • Custo de captura de dados científicos usando a DfAnalyzer e o noWorkflow:

Análise do custo em termos de tempo para a captura dos dados científicos e dos dados de proveniência durante a execução de simulações computacionais. Nessa análise, a proposta é comparar a sobrecarga de tempo de uma instância da ARMFUL, a DfAnalyzer, com o noWorkflow, ou seja, outro sistema que apoia a captura de dados de proveniência. Considerando as análises exploratórias sobre as simulações computacionais, uma das principais dificuldades encontradas consiste no ajuste fino das configurações durante a geração de fluxos de dados, como a definição de outros atributos e programas a serem 

Tamanho dos arquivos de dados científicos (MB)

Execução de programa de simulação Carga de dados na base de proveniência Execução de programa de extração Considerando-se um cenário de larga escala, ou seja, que um grande volume de dados científicos é armazenado em arquivos, os usuários devem extrair apenas os elementos de dados relevantes para apoiar as análises da simulação computacional. Para isso, condições de filtro (i.e., seleção de elementos de dados) precisam ser definidas para que o custo da extração de dados não seja alto, assim como o custo de carregar os dados de proveniência e os dados científicos na base de dados. Nesse sentido, esse experimento também contemplou a execução do workflow EdgeCFD usando o SCC-A com 240 cores no cluster Stampede para investigar o custo em termos de tempo da extração de dados científicos, da execução das atividades do workflow e da carga de dados na base de dados, ao variar a estratégia de extração de dados.

A execução desse workflow considerou 4.800 combinações de valores de atributos de entrada (e.g., atributos de termo de força e de viscosidade do fluido), que manipulou 86.400 arquivos no formato HDF5 e XDMF e necessitou de aproximadamente 1,09 TB de espaço de armazenamento em disco. Como conjunto de dados de entrada, considerou-se a malha fina para esse workflow, conforme discutido na Subseção 6.1.3. Para comparar os custos em termos de tempo associados ao armazenamento do conteúdo em arquivos de dados científicos em uma base de dados, calculou-se a média do tempo de execução a partir de três execuções de cada versão do workflow.

Ademais, duas abordagens foram propostas para a extração de dados científicos: parcial e total. Os resultados para cada abordagem são apresentados na Tabela 9, assim como o custo em termos do tempo de executar o workflow EdgeCFD sem a extração de dados científicos. Pelos resultados obtidos, pode-se observar que ao aumentar o volume de dados extraídos de arquivos, aumentou-se o tempo para acessar os dados científicos nos arquivos (i.e., tempo de execução do programa de extração). Consequentemente, pelo fato de aumentar o número de elementos de dados extraídos, o custo de carga dos dados no SGBD também aumentou. Portanto, assim como observado no experimento com o workflow SyntheticOil&Gas, os resultados com o workflow EdgeCFD apontaram que os elementos de dados relevantes para o usuário de domínio em suas análises têm fator determinante na sobrecarga da captura de dados científicos, uma vez que determina o volume de dados extraídos dos arquivos e um esforço em termos de processamento computacional para carregar os dados na base de dados de proveniência. A Figura 59 apresenta o custo para as quatros versões do workflow EdgeCFD.

Primeiramente, observou-se que o custo da carga de dados aumenta de acordo que o tamanho da malha também aumenta, já que mais dados de proveniência, de execução e científicos devem ser armazenados na base de dados do SCC-A. Em todas as versões da malha, a versão carga do workflow apresenta a maior sobrecarga na carga de dados, uma vez que ela acessa o conteúdo nos arquivos de dados científicos, converte tais dados em estruturas de dados específicas e carrega os dados estruturados na base de dados de proveniência integrada.

Por outro lado, as versões do workflow baseadas em algoritmos de indexação apresentam estruturas de dados otimizadas para referenciar os dados científicos, como discutido na Seção 2.1. Logo, os resultados experimentais mostram que houve uma redução de 52,55% na sobrecarga de tempo para a carga de dados no SGBD, quando se aplicou a indexação posicional (aproximadamente 44,11 minutos) nesse workflow com malhas finas de entrada, em comparação com a versão carga do workflow. Nessa mesma configuração, a versão carga do workflow apresentou uma sobrecarga de 92,95 minutos. Considerando o cenário de indexação de dados científicos, desenvolveu-se um préprocessador de consultas capaz de consultar os índices gerados na base de dados do SCC-A, acessar os elementos de dados presentes em arquivos por meio dos índices e realizar a junção dos dados com outros resultados obtidos nesse processo. Em relação ao acesso aos elementos de dados em arquivos, utilizou-se os índices obtidos da base de dados do SCC-A e invocou-se um processo inverso ao da indexação de dados científicos, ou seja, de acesso aos dados por meio dos índices. No caso da indexação posicional, desenvolveu-se um método de acesso baseando-se na implementação do RAW [START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF]. Para a indexação bitmap, utilizou-se o mecanismo de processamento de consultas da própria ferramenta FastBit. Além disso, a etapa de junção dos resultados foi responsável por relacionar os dados científicos presentes nos arquivos com os dados de outros atributos projetados na especificação da consulta, que não estavam presentes nos arquivos de dados científicos (ou seja, que não foram indexados).

Baseando-se nessa abordagem, a Tabela 15 apresenta o tempo de processamento de cada uma das consultas para o workflow EdgeCFD, variando-se a abordagem de captura dos dados científicos. Esse tempo de processamento engloba o custo de acessar os dados na base de dados do SCC-A e do repositório externo (e.g., usando o processador de consultas da ferramenta FastBit), e de combinar os resultados obtidos na etapa anterior. Pelos resultados dessa tabela, observa-se que a abordagem de carga dos dados apresentou o melhor desempenho, pois não apresenta a sobrecarga de utilizar os índices gerados para depois acessar os elementos de dados em arquivos, como acontece nas abordagens de indexação posicional (idx-posicional) e bitmap (idx-bitmap).

Tabela 15. Tempo de processamento de consultas de acordo a abordagem de extração e indexação de dados científicos.

Versão do workflow

Tempo de processamento da consulta (em minutos) Por outro lado, a sobrecarga de tempo para processar as consultas usando os algoritmos de indexação (aproximadamente 45,74 minutos no pior caso) é compensada com a sobrecarga de tempo para executar os programas de extração de dados científicos; gerar os índices; e carregar os dados em uma base de dados. Nesse cenário, essa diferença da sobrecarga de tempo (entre a abordagem de carga de dados e de indexação bitmap) é de aproximadamente 192,84 minutos para malhas finas, conforme apresentado nas Subseções Assim, de acordo com a anomalia detectada durante a execução do solucionador, o usuário pode realizar ajustes nos valores dos parâmetros de entrada ou no próprio solucionador, a fim de que essa concentração de sedimentos não ultrapasse o valor de 

Capítulo 7 -Conclusão

Simulações computacionais em larga escala são caracterizadas pela manipulação de grandes volumes de dados pelos seus modelos computacionais. Para validarem ou refutarem uma hipótese científica, os usuários comumente precisam analisar os dados científicos produzidos por esses modelos computacionais, que são armazenados em diferentes arquivos. Em um cenário tradicional, os usuários do domínio científico frequentemente desenvolvem programas ad-hoc para acessar e extrair determinados dados científicos dos arquivos de interesse ou de dados ainda alocados em memória. Em casos mais complexos, eles ainda precisam relacionar elementos de dados presentes em múltiplos arquivos, sem nenhum apoio computacional centrado em dados. Portanto, essa abordagem ad-hoc caracteriza-se por ser custosa do ponto de vista de desenvolvimento, propensa a erros, de difícil reaproveitação, sendo específica para cada análise realizada pelos usuários.

Nesta tese analisamos as abordagens existentes para apoiar a captura e a análise exploratória de dados científicos. Foram identificadas diversas limitações nessas soluções, principalmente no que diz respeito à análise de dados durante a execução e ao relacionamento entre dados dentro de arquivos distintos. Outro problema relacionado está na ausência de apoio à consulta aos dados de proveniência, também durante a execução e junto com os demais dados científicos, o que limita a gerência dos rastros dos dados de proveniência. Finalmente, um dos desafios ao apresentar soluções analíticas de dados de domínio e dados de proveniência está ligado ao desempenho computacional. As aplicações alvo desta tese caracterizam-se por serem em larga escala, demandando forte uso de recursos computacionais ainda que em ambientes de processamento de alto desempenho.

Tais aplicações não podem ser penalizadas por soluções de análise de dados que, em muitos casos, incorram em sobrecargas ainda que da ordem de 5% no tempo de execução do workflow.

Como parte da solução, apresentamos uma abstração para a representação de fluxo de dados baseada em proveniência de dados para apoiar a análise do fluxo de arquivos e de elementos de dados em simulações computacionais em larga escala. Mais especificamente, foi proposto um formalismo para a proveniência de fluxo de dados, em conformidade com o padrão de dados de proveniência segundo o W3C. Para fazer uso dessas abstrações de dados, uma abordagem foi proposta para permitir a captura e a análise de dados científicos durante a execução paralela de aplicações científicas. Tal abordagem foi implementada em um sistema de workflows científicos (SCC-A) e como uma biblioteca de componentes para a análise de fluxo de dados em simulações computacionais (DfAnalyzer). A solução caracteriza-se por ser assíncrona, utilizando recursos de processamento e armazenamento que não competem com a simulação computacional. Essa abordagem permitiu o não comprometimento do desempenho.

Nos experimentos realizados com o SCC-A, observou-se que a carga de dados científicos pode apresentar um gargalo em termos de desempenho ao empregar a extração total dos dados científicos presentes em arquivos. Por isso, a extração parcial e algoritmos de indexação foram aplicados em outros experimentos para destacar a viabilidade de apoiar a análise de dados científicos em tempo de execução, a partir da redução do custo de carga dos dados em nossa base de dados. As implementações dessa abordagem utilizam soluções existentes para a extração e a indexação de dados científicos, como o FastBit e o ParaView Catalyst. Já no cenário de processamento de dados in situ, os resultados experimentais usando a DfAnalyzer destacaram as vantagens do acesso e da captura de dados científicos ainda alocados em memória, além de enfatizar a baixa sobrecarga da nossa proposta para gerenciar os dados de proveniência e de domínio (aproximadamente 0,32% em uma simulação real).

Os resultados obtidos destacaram que:

(i) nos cenários reais, o custo da extração de dados científicos representa um valor percentual pequeno (aproximadamente 3,7% no workflow Montage usando o SCC-A) em relação ao custo de processamento dos programas de simulação;

(ii) a sobrecarga do processo de extração de dados científicos tende a diminuir na proporção que a complexidade dos modelos computacionais aumenta (i.e., maior tempo de processamento computacional);

(iii) o custo de captura dos dados científicos depende diretamente da quantidade de dados obtidos dos arquivos e dos algoritmos utilizados (ou ferramentas alternativas, e.g. FastBit) no acesso, na extração e, eventualmente, na indexação dos dados científicos;

(iv) a indexação de dados científicos apresentou-se como uma alternativa vantajosa na captura de dados científicos, ao reduzir o custo envolvido nos algoritmos de extração de dados. Por outro lado, tal abordagem deve ser bem empregada em estruturas de dados específicas, a fim de reduzir o volume de dados a serem carregados na base de dados de proveniência. No cenário científico, se estruturas de dados mais complexas, como malhas, fossem indexadas, menor seria essa sobrecarga de armazenamento de dados. Os experimentos usando o workflow EdgeCFD comprovam exatamente essa redução do custo de carga dos dados ao aplicar técnicas de indexação em malhas; e (v) o processamento de dados in situ tira proveito de dados ainda alocados em memória. Em nossos experimentos, utilizou-se o cartucho do ParaView Catalyst do componente RDE da DfAnalyzer para apoiar a captura de dados científicos in situ de uma malha em uma simulação de dinâmica de fluidos computacionais.

Em um cenário de larga escala, a sobrecarga para a captura de dados científicos foi de apenas 1,52% em relação ao tempo de execução da simulação, enquanto a gerência dos dados de proveniência apresentou uma sobrecarga de 0,32%.

Tais experimentos nos permitem concluir que o uso da abordagem proposta não compromete o desempenho das aplicações científicas em larga escala. Do ponto de vista do poder analítico, as implementações da ARMFUL, SCC-A e DfAnalyzer são capazes de apoiar os três tipos de consultas para a análise exploratória de dados científicos (Capítulo 2) em todas as simulações computacionais consideradas nos experimentos conduzidos nesta tese. Mais especificamente, consultas foram desenvolvidas em quatro simulações computacionais para apoiar a análise do conteúdo de arquivos de dados científicos, dos arquivos de dados científicos relacionados pelos programas de simulação (ou transformações de dados) e dos elementos de dados relacionados pelas transformações.

Contribuições Alcançadas

Nesta tese apresentamos uma visão geral do cenário das análises exploratórias dos dados científicos, discutindo os tipos de consultas comumente realizados pelos usuários e as suas limitações.

Como contribuições destacamos: Com contribuições secundárias, uma interface gráfica foi desenvolvida como um componente da DfAnalyzer para permitir a análise do fluxo de arquivos e de elementos de dados durante a execução de simulações, sem que seja necessário o uso de linguagens de consulta declarativas, como a SQL.

Trabalhos futuros

A abordagem proposta nesta tese para a captura e a análise exploratória de dados científicos baseada na abstração de fluxo de dados pode ser avaliada como um passo inicial na investigação do grande volume de dados manipulados pelas simulações computacionais, conforme apresentado em [START_REF] Atkinson | Scientific workflows: Past, present and future[END_REF] no contexto de workflows científicos.

Somando-se aos avanços realizados nesta tese, ainda existem desafios relacionados ao processamento de consultas e à visualização de dados científicos (e do fluxo de dados) em tempo de execução. Em relação ao processamento de consultas, pode-se considerar a proposta de um sistema de consultas mais eficiente e que assuma uma solução agnóstica para a estratégia de indexação empregada. Já para a visualização de dados, destaca-se as dificuldades de análise de fluxos de dados complexos produzidos pelas simulações computacionais em larga escala, que apresentam diferentes caminhos possíveis em função da execução de centenas ou milhares de tarefas por transformação de dados, relacionando arquivos e elementos de dados.

Ainda nesse cenário de fluxo de dados complexos, pode-se enfatizar a importância das operações de projeção, seleção e agregação dos elementos de dados ao longo do fluxo de dados, a fim de que os usuários possam investigar apenas regiões de interesse da sua simulação computacional, como discutido no Capítulo 3. Entretanto, ainda existem desafios quanto ao uso de técnicas de aprendizado de máquinas para apoiar a identificação de padrões em execuções de simulações computacionais, tendo como objetivo informar ao usuário do domínio científico eventuais erros ou comportamentos científicos de interesse, como discutimos em [START_REF] Ocaña | Data Analytics in Bioinformatics: Data Science in Practice for Genomics Analysis Workflows[END_REF].

Do ponto de vista da abordagem proposta, podemos enaltecer as contribuições de monitoramento, depuração e análise de dados científicos proporcionadas pelo SCC-A e pela DfAnalyzer. Apesar desses resultados analíticos que favorecem a intervenção durante a execução da simulação computacional, existem oportunidades no que diz respeito à gerência dos dados científicos e das suas intervenções [START_REF] Ferreira Da | A characterization of workflow management systems for extreme-scale applications[END_REF], que poderiam ser explorados, inclusive, com as implementações da ARMFUL [START_REF] Deelman | The future of scientific workflows[END_REF], SOUZA et al., 2016, 2017). Nesse sentido, a dissertação de mestrado do Luciano Silva Leite propõe a captura de dados de proveniência e dados científicos em simulações computacionais usando a DfAnalyzer sem o pré-processamento manual e offline de modelagem do fluxo de dados. Com relação ao SCC-A e à DfAnalyzer, ainda existem oportunidades de uso de sistemas de gerência de banco de dados paralelos e distribuídos, ou mesmo baseados no processamento de dados em memória para reduzir a sobrecarga de operações em disco durante a execução de simulações em larga escala.

Em termos de infraestrutura, a alocação do SGBD MonetDB no mesmo recurso computacional que a aplicação RESTful da DfAnalyzer pode apresentar gargalos em termos de desempenho em simulações computacionais mais complexas. Como a própria complexidade das simulações computacionais tem apresentado um crescimento considerável a cada ano, pode ser que a infraestrutura assumida para essa primeira implementação da DfAnalyzer não se apresente como a mais adequada em cenários futuros, incluindo questões como a tolerância e a recuperação em casos de falha. Além disso, estudos mais aprimorados quando à análise do comportamento de CPU e de operações de entrada e saída na base de dados do MonetDB, ou mesmo na aplicação RESTful, poderiam ser conduzidos em trabalhos futuros.

Figura 3 .

 3 Figura 3. Proveniência de dados no nível (a) físico e (b) lógico.

Figura 4 .

 4 Figura 4. Captura e análise de dados científicos: (a) post mortem; (b) in situ; e (c) in transit. Adaptado de Oldfield et al. (2014). As setas representam a movimentação de

Figura 8 .

 8 Figura 8. Representação em camadas do SCC.

Figura 36 .Figura 56 .Tabela 2 .

 36562 Figura 36. Dependência de dados entre tarefas.

Figura 1 .

 1 Figura 1. Exemplo de simulação de astronomia para a análise de dados científicos.

Tabela 1 .

 1 Mapa de bits para indexação bitmap do atributo X em um exemplo hipotético.

Definição 3 . 1 . 1 .

 311 (Elemento de Dados) Um elemento de dados 𝑒 = (𝑣 | 𝑣 ∈ 𝑉) é composto de uma sequência de valores 𝑉. Definição 3.1.2. (Coleção de Dados) Uma coleção de dados 𝑐 = {𝑒 | 𝑒 ∈ 𝐸} é composta de um conjunto de elementos de dados 𝐸. Definição 3.1.3. (Conjunto de Dados) Um conjunto de dados 𝑠 = (𝐴, 𝐶) é um par composto de uma sequência de atributos 𝐴 | ∀𝑎 ∈ 𝐴: 𝑎(𝑛𝑎𝑚𝑒, 𝑡𝑦𝑝𝑒), e de um conjunto de coleções de dados 𝐶 | ∀𝑒 ∈ 𝐶: 𝑐𝑎𝑟𝑑(𝑒. 𝑉) = 𝑐𝑎𝑟𝑑(𝐴). Definição 3.1.4. (Transformação de Dados) Uma transformação de dados 𝑡 = (𝐼, 𝑂) é um par composto de conjuntos de dados de entrada 𝐼 e de conjuntos de dados de saída 𝑂. Definição 3.1.5. (Dependência de Dados) Uma dependência de dados 𝜑 = (𝑠, 𝑡 𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠 , 𝑡 𝑛𝑒𝑥𝑡 ) é uma tripla composta de um conjunto de dados 𝑠, de uma transformação de dados 𝑡 𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠 e de uma transformação de dados 𝑡 𝑛𝑒𝑥𝑡 , em que 𝑠 ⊆ 𝑡 𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠 . 𝑂 ∧ 𝑠 ⊆ 𝑡 𝑛𝑒𝑥𝑡 . 𝐼. Definição 3.1.6. (Fluxo de Dados) Um fluxo de dados 𝐷 𝐹 = (𝑇, 𝑆, Φ) é uma tripla composta de transformações de dados 𝑇, de conjuntos de dados 𝑆, e de dependências de dados Φ. Definição 3.1.7. (Instância da Transformação de Dados) Uma instância de transformação de dados 𝑡 * = (𝐼 ′ , 𝑂 ′ ), or 𝑂 ′ = 𝑡 * (𝐼 ′ ), consiste em um par com um subconjunto das coleções de dados dos conjuntos de dados de entrada 𝐼 ′ = ⋃ (𝑖 𝑘 . 𝐶 ′ | 𝑖 𝑘 . 𝐶 ′ ⊆ 𝑖 𝑘 . 𝐶) 𝑐𝑎𝑟𝑑(𝑡.𝐼) 𝑘=1 e um subconjunto das coleções de dados dos conjuntos de dados de saída 𝑂 ′ = ⋃ (𝑜 𝑘 . 𝐶 ′ | 𝑜 𝑘 . 𝐶 ′ ⊆ 𝑜 𝑘 . 𝐶) 𝑐𝑎𝑟𝑑(𝑡.𝑂) 𝑘=1

Figura 2 .

 2 Figura 2. Exemplo de fluxo de dados.

Figura 3 .

 3 Figura 3. Proveniência de dados no nível (a) físico e (b) lógico.

  armazenam diretamente em arquivos, em formatos específicos de acordo com o domínio da simulação computacional. Em seguida, as soluções dessa categoria acessam o conteúdo desses arquivos, realizam as análises léxica e sintática, extraem conjuntos de dados científicos relevantes, indexam dados de regiões específicas e preparam esses dados para serem consultados posteriormente. Dessa forma, essa abordagem caracteriza-se por ter, pelo menos, duas vezes a interação com meios de armazenamento não-voláteis, que tendem a ser mais lentos, como apresentado na Figura 4(a).

Figura 4 .

 4 Figura 4. Captura e análise de dados científicos: (a) post mortem; (b) in situ; e (c) in transit. Adaptado de Oldfield et al. (2014). As setas representam a movimentação de dados entre recursos computacionais, enquanto os retângulos unidos correspondem ao uso de dados ainda alocados em memória.

  interesse, ou produzir visualizações. Como exemplo dessa categoria, o SENSEI[START_REF] Ayachit | Performance Analysis, Design Considerations, and Applications of Extreme-scale in Situ Infrastructures[END_REF] consiste em uma interface genérica entre os programas de simulação e as soluções de análise de dados científicos, permitindo o compartilhamento de dados em memória volátil. Para realizar o mapeamento dos dados, o SENSEI requer que o usuário desenvolva um adaptador de dados, responsável por definir quais dados do programa de simulação são relevantes e devem ser mantidos em memória volátil de acordo com a estrutura do modelo de dados do VTK[START_REF] Vtk | Visualization Toolkit[END_REF]. Somando-se a isso, essa solução também requer a especificação de um adaptador de análise que utiliza os dados descritos em objetos do VTK em códigos de programas para analisar dados científicos. O ParaView Catalyst[START_REF] Ayachit | ParaView Catalyst: Enabling In Situ Data Analysis and Visualization[END_REF], o VisIt 5 e o ADIOS[START_REF] Liu | Hello ADIOS: the challenges and lessons of developing leadership class I/O frameworks[END_REF] são exemplos de ferramentas para a análise e a visualização de dados que o SENSEI oferece suporte.

  científicos relacionados ao longo do fluxo de dados. Mais especificamente, este capítulo apresenta uma visão geral da arquitetura baseada em componentes, conhecida como ARMFUL (do termo em inglês, Analysis of Raw data from Multiple Files ou, em português, Análise de Dados Científicos a partir de Múltiplos Arquivos), que lidam com a captura e a análise de dados de proveniência e dados científicos (Seção 4.1). Após essa visão geral da nossa arquitetura, esse capítulo detalha as características de cada componente, considerando o acesso aos dados científicos, a geração de índices, o armazenamento dos dados capturados e o processamento de consultas. Além disso, esse capítulo apresenta o diagrama PROV-Df, que foi proposto para representar os fluxos de dados gerados pelas simulações computacionais, assumindo os dados de proveniência e os dados científicos capturados de arquivos. A arquitetura ARMFUL pode ser instanciada em diferentes ambientes computacionais. Resumidamente, duas instâncias da ARMFUL foram desenvolvidas, sendo elas conhecidas como SCC-A e DfAnalyzer. A primeira instância (Seção 4.7), SCC-A, consistiu em uma extensão do Sistema de Gerência de Workflows Científicos (SGWfC) SCC para apoiar a captura e análise de dados científicos. A segunda instância (Capítulo 5) corresponde à biblioteca de componentes DfAnalyzer para analisar o fluxo de dados gerado por simulações computacionais, que se caracteriza por ser uma implementação da ARMFUL independente de um SGWfC.

Figura 5 .

 5 Figura 5. Camadas da arquitetura ARMFUL. Já os componentes da camada Captura de Dados Científicos são responsáveis por acessar, extrair e, eventualmente, indexar os dados científicos manipulados pelos programas de simulação, que podem estar armazenados em arquivos ou mesmo alocados em memória (processamento in situ). Uma vez que os dados científicos tenham sido capturados, eles podem ser carregados em uma base de dados de proveniência integrada. Vale enfatizar que essa etapa depende bastante da camada Armazenamento de Dados, pois os dados científicos são comumente armazenados em arquivos e o catálogo para esses dados são armazenados em disco (componente Catálogo de Dados Científicos).

Algoritmo 1 .Figura 6 .

 16 Figura 6. Exemplo de extração de dados científicos em arquivos no formato HDF5.

O

  PROV-Df é composto de três partes: a estrutura do fluxo de dados (classes em branco do diagrama de classe), os dados de execução referentes a um fluxo de dados com os dados de domínio (classes em cinza escuro) e as configurações do ambiente computacional (classes em cinza claro). O estereótipo de cada classe corresponde a um componente do PROV-DM. As classes em branco descrevem a especificação do fluxo de dados (classe Dataflow), que é composto de transformações de dados (classe DataTransformation), conjuntos de dados (classe DataSetSchema), atributos (classe Attribute), tipos de arquivos manipulados (classe FileType) e das extrações / indexações de dados realizadas (classe Extractor e ExtractorCombination). Por uma questão de simplificação, não foi apresentada a classe Indexer para expressar a indexação de dados científicos, já que ela apresenta os mesmos tipos de relacionamento que a classe Extractor. As dependências de dados entre as transformações de dados são representadas nesse modelo de dados pelo relacionamento WasAttributedTo entre as classes DataTransformation e DataSetSchema.

Figura 7 .

 7 Figura 7. Diagrama de classe PROV-Df (SILVA et al., 2016c). As classes em cinza escuro descrevem os dados de execução referente a um fluxo de dados (atividade ExecuteDataflow), que considera as propriedades sobre a execução das transformações de dados (atividade ExecuteDataTransformation), os conjuntos de dados instanciados (classe DataSet), as coleções de dados (classe DataCollection) e os elementos de dados a partir de cada conjunto de dados (classe DataElement), os valores de atributos referentes a um determinado elemento de dados, ou seja, os dados científicos (classe AttributeValue), os programas invocados pelas transformações de dados (agente de software Program) e os arquivos consumidos e produzidos (classe File).

  4.7.1) foi preservado. Ao mesmo tempo, como a álgebra de workflows científicos empregada na especificação das atividades usando o SCC não continha operadores algébricos para representar a extração e a indexação de dados científicos, o SCC-A também exigiu a extensão dessa álgebra. Mais especificamente, dois novos operadores algébricos foram propostos, conhecidos como Raw e RawI (Subseção 4.7.2), que permitem extrair e indexar dados científicos de arquivos, respectivamente. Vale ressaltar também que os resultados dessa seção são apresentados por Silva et al. (2017).

4. 7 . 1 .

 71 Modelo arquitetural do SGWfC SCC-A O SGWfC paralelo SCC (apresentado em mais detalhes na Seção 3.3.4) é composto das seguintes camadas, conforme mostrado na Figura 8: Gerência de Workflow, Escalonamento de Workflow, Processamento de Ativação, Invocação de Programa, Invocação de Extrator e Processamento de Dados de Proveniência. Primeiramente, a camada Gerência de Workflow é responsável por controlar a execução paralela dos workflows científicos em ambientes de cluster e nuvem computacional, determinando o momento adequado de executar cada atividade. Esse momento é definido segundo as dependências de dados e a estratégia de execução paralela adotada pelo SCC, que pode variar em duas estratégias de fluxo de dados (FTF e FAF) e duas estratégias de despacho (estática e dinâmica). Tais estratégias são detalhadas em Ogasawara et al. (2011). Abaixo dessa camada, o SCC apresenta a camada Escalonamento de Workflow, que realiza a subdivisão das atividades em unidades de dados autocontidas e a distribuição dessas unidades para os recursos computacionais disponíveis, a fim de favorecer o paralelismo de dados. Cada uma dessas unidades de dados autocontidas é conhecida como ativação, semelhante ao conceito de tarefa (RAICU et al., 2008) em outros SGWfC paralelos. Dessa forma, uma ativação contempla o menor conjunto de dados necessário para executar o programa de simulação de uma determinada atividade.

Figura 8 .

 8 Figura 8. Representação em camadas do SCC.

  Considerando a representação em camadas do SCC, pode-se observar que a contribuição desta tese se concentra nas camadas Invocação de Extrator e Processamento de Dados de Proveniência. Mais especificamente, a abordagem proposta tem o objetivo de permitir o acesso e a indexação de dados científicos para apoiar análises específicas em dados científicos, enquanto que mantém a carga de dados científicos desenvolvida originalmente no SCC. Por isso, o componente de Captura de Dados Científicos da ARMFUL foi instanciado como uma arquitetura baseada em componentes, conhecida como Raw Data Capture (RDC) (em português, Captura de Dados Científicos). A arquitetura RDC é dividida em cartuchos de dois tipos, como mostrado na Figura 9, que realizam a indexação de dados científicos (Indexador de Dados Científicos do termo, em inglês, Raw Data Indexer -RDI) e a extração de dados científicos (Invocador de Extrator do termo, em inglês, Extractor Invoker -EI). Tais componentes são extensíveis, de forma que diferentes cartuchos podem ser desenvolvidos para extrair ou indexar dados científicos no SCC-A[START_REF] Birsan | On plug-ins and extensible architectures[END_REF].

Figura 9 .

 9 Figura 9. Cartuchos implementados na arquitetura RDC.

)

  Diferentemente da álgebra original de workflows científicos, i.e., SciWfA, essa extensão da álgebra também considerou que os operadores Raw e RawI só podem ser especificados em uma certa atividade do workflow, quando um dos outros operadores algébricos (Map, SplitMap, Reduce, Filter e Query) também for definido anteriormente nessa mesma atividade. Essa especificação caracteriza a extração e a indexação de dados como um pós-processamento de dados para uma determinada atividade, a fim de representar os dados produzidos em uma relação de saída.A Figura 10(a) mostra um exemplo de atividade (denominada de A) sem extração de dados, que é composta apenas pelo operador algébrico Map. Enquanto isso, a Figura 10 (b) e a Figura 10(c) mostram atividades, denominadas de Ae e Ai, sendo regidas pelos operadores algébricos Raw e RawI para permitir a extração e a indexação de dados científicos, respectivamente. A extração de dados desse exemplo considera a invocação de um programa externo, conhecido como extractData, enquanto que a indexação de dados é baseada na invocação da ferramenta alternativa FastBit. Os arquivos de dados científicos seguem o formato CSV, sendo especificados como operandos adicionais, enquanto os valores dos atributos a1, a2 e a3 são capturados dos arquivos CSV.Além das contribuições associadas ao formalismo das transformações de dados ao longo da simulação computacional, a extensão da álgebra de workflows científicos apresenta vantagens relacionadas às análises exploratórias de dados científicos. Dado que os operadores algébricos Raw e RawI permitem a captura de dados científicos presentes em arquivos, análises, que levam em consideração o conteúdo específico do domínio, podem ser tratadas a partir do processamento de consultas à base de dados de proveniência. Ao mesmo tempo, estruturas de dados que antes apresentavam um alto custo para o seu armazenamento na base de dados de proveniência por meio da extração de dados, agora podem contar com a extensão da álgebra para aplicar técnicas de indexação. Dessa forma, o uso do operador RawI permite o armazenamento dos índices referentes ao conteúdo desses arquivos na base de proveniência, assumindo um espaço reduzido em comparação com a carga dos valores dos atributos.

Figura 10 .

 10 Figura 10. Atividades usando a SciWfA estendida: (a) sem extração/indexação, (b) com extração e (c) com indexação de dados científicos.

  consumindo e produzindo grande volume de dados. Muitos desses dados são armazenados em diferentes arquivos. Nesse contexto, o usuário do domínio científico comumente precisa analisar o conteúdo desses arquivos para validar ou refutar as suas hipóteses científicas.Com esse propósito, eles frequentemente utilizam programas ad-hoc e ferramentas alternativas para que os conteúdos desses arquivos sejam capturados. Ou seja, esses programas e ferramentas são empregados para acessar os dados científicos presentes em um arquivo, extrair apenas os dados científicos relevantes e indexar os dados científicos quando apenas a extração desses dados pode tornar custosa, ou mesmo impraticável, a carga dos dados em um repositório externo ou em uma base de dados.Além da análise de dados científicos relevantes presentes em um arquivo, esses usuários necessitam investigar dados armazenados em diferentes etapas da simulação computacional e, consequentemente, de diferentes arquivos. Dessa forma, embora os dados científicos estejam acessíveis, eles também precisam estar disponíveis, ou seja, eles precisam seguir estruturas de dados e estar armazenados em um repositório externo de modo que o usuário do domínio científico possa relacionar dados de diferentes arquivos. Ao mesmo tempo, eles necessitam de recursos que favoreçam a modelagem e a execução das suas consultas, assim como a visualização dos dados.Diante dessas questões, observou-se as seguintes limitações no cenário de simulações computacionais em larga escala: (i) a composição explícita dos programas de simulação não é normalmente representada; (ii) a captura de dados científicos é frequentemente realizada após a execução da simulação por meio de programas ad-hoc e ferramentas alternativas, como uma etapa de pós-processamento; e, consequentemente, (iii) existem desafios no apoio à análise exploratória de dados científicos, uma vez que os dados de interesse não estão disponíveis em tempo de execução e, normalmente, não são relacionados pelos diferentes arquivos produzidos ao longo das etapas da simulação computacional. A partir dessas limitações, a DfAnalyzer segue uma abstração de fluxo de dados (Seção 3.1)uma das contribuições desta tesepara tornar explícita a representação das diferentes etapas de processamento em uma simulação computacional (i.e., transformações de dados), que envolvem o consumo e a produção de dados (i.e., conjunto de dados) importantes na análise exploratória de dados científicos.Mesmo com essa abstração de fluxo de dados, ainda não estão claras as diferentes etapas envolvidas na explicitação do fluxo de dados presente em uma simulação computacional, no apoio à extração de dados científicos e no processamento de consultas de acordo com as necessidades do usuário do domínio científico. Nesse sentido, esta tese propõe a extensão de uma metodologia para permitir a captura de dados de proveniência e científicos usando a DfAnalyzer a partir de simulações computacionais que não apresentam o seu fluxo de dados explicitados e não apoiam a proveniência dos dados. Essa metodologia estendida foi baseada na PrIMe[START_REF] Munroe | PrIMe: a software engineering methodology for developing provenance-aware applications[END_REF], uma técnica de engenharia de software amplamente conhecida na comunidade de proveniência para adaptar a modelagem de aplicações a fim de permitir a captura de dados de proveniência. As principais etapas da PrIMe consistem em identificar os tipos de dados necessários para responder às consultas baseadas na proveniência da simulação computacional, em analisar a modelagem da simulação para determinar em quais pontos os dados de proveniência devem ser registrados e em adaptar os programas de simulação para capturar os dados de proveniência de interesse. Motivados por essas etapas da PrIMe, a nossa metodologia é dividida em três etapas: modelagem do fluxo de dados, modelagem dos dados de domínio e modelagem das consultas.Em um primeiro momento, também assumimos que o usuário do domínio científico não conhece o fluxo de dados da sua simulação computacional, pois esse fluxo de dados não está explicitamente definido. Desse modo, a primeira fase da nossa metodologia envolve um trabalho colaborativo entre o usuário do domínio científico e o especialista em ciência da computação para modelar a simulação computacional como um fluxo de dados, semelhante a uma etapa de pré-processamento para depois realizar a execução da simulação.

5. 2 . 1 .

 21 Figura 12. Script em Python usando Spark para a contagem de palavras.

Figura 14 .

 14 Figura 14. Especificação dos conjuntos de dados e das suas dependências em uma simulação computacional.Mais especificamente, a primeira transformação de dados desse script (Obter linhas) consome os arquivos de texto presentes no arquivo input_files.txt, que são representados por um conjunto de dados do Spark, ou RDD (do termo, em inglês, Resilient Distributed Dataset). Como resultado, o conjunto de dados lines é produzido com as linhas de texto obtidas dos arquivos de entrada (atributo line, não apresentado na figura). Para cada linha do conjunto de dados lines, a segunda transformação identifica as palavras existentes e atribui o valor um para a sua ocorrência (ou seja, obtemos dois atributos, nomeados word e occurrence). Como saída dessa transformação, todas as palavras identificadas são armazenadas no conjunto de dados occurrences, mesmo que existam redundâncias de elementos de dados (tuplas com os mesmos valores de atributos). Por último, a terceira transformação de dados agrupa as ocorrências por palavra, gerando o conjunto de dados counts, que apresenta os atributos word (palavra encontrada) e count (número de ocorrências da palavra em todas as linhas analisadas, mesmo que a palavra de interesse esteja presente em arquivos diferentes).

Figura 15 .

 15 Figura 15. Diagrama ER para a especificação do fluxo de dados.

Figura 17 .

 17 Figura 17. Modelo de dados lógico para os dados de proveniência.Quando um relacionamento apresenta cardinalidades máximas 1:n (incluindo relacionamentos 1:1), uma restrição de chave estrangeira é adicionada na relação de destino.Por exemplo, no diagrama ER, o relacionamento entre as entidades Dataflow e Transformation possui cardinalidades máximas 1:n de maneira que um fluxo de dados é composto de um conjunto de transformações de dados. Assim, ao mapearmos esse relacionamento para o modelo de dados lógico, uma restrição de chave estrangeira é criada no campo df_id da relação data_transformation para o campo id da relação dataflow.

Figura 18 .

 18 Figura 18. Script em Python usando as operações da DfAnalyzer para armazenar na base de dados a especificação do fluxo de dados da simulação de contagem de palavras.

  ", ["input_files"], ["lines"], ["GetLines::flatMap()"]) program("IdentifyOccurrences::flatMap()", "/root/word_count") dataset("occurrences", ["word","occurrence"], ["text","numeric"]) transformation("identify_occurrences", ["lines"], ["occurrences"], ["IdentifyOccurrences::flatMap()"])program("CountWords::reduceByKey()", "/root/word_count") dataset("counts", None, None)

  Retomando a primeira etapa que envolvia o trabalho colaborativo entre o usuário do domínio científico e o especialista em ciência da computação para especificar o fluxo de dados de uma simulação, observamos que, nesse momento, esses usuários já haviam definido os conjuntos de dados e os seus esquemas (ou seja, os seus atributos), assim como os extratores de dados científicos. Entretanto, o mapeamento desses conceitos para um diagrama ER não foi realizado e, consequentemente, o nosso modelo de dados lógico não contempla tais dados do domínio científico.

Figura 19 .

 19 Figura 19. Diagrama ER para os dados de domínio a partir do script da Figura 14.

  exemplo, a instância(4,2) indica que o quarto elemento de dados do conjunto occurrences (atributo occurrences_id) foi consumido por uma instância da transformação de dados count_words para produzir o segundo elemento de dados do conjunto counts (atributo counts_id).

Figura 20 .

 20 Figura 20. Instâncias da entidade occurrences do diagrama ER da Figura 19.

(

  do termo, em inglês, tag) do fluxo de dados, de 2 (duas) transformações de dados (campos previous_transformation e next_transformation) e de um conjunto de dados (campo dataset). Por exemplo, a Figura 25 mostra a visão dataflows, assumindo-se que apenas a especificação do fluxo de dados de contagem de palavras (Figura 14) está armazenada na nossa base de dados. Vale enfatizar que, em cenários que a base de dados apresenta mais de uma especificação de fluxo de dados, os usuários precisam selecionar apenas as tuplas correspondentes ao fluxo de dados de interesse, ou seja, com um valor específico para a coluna dataflow a partir da visão obtida.

Figura 25 .

 25 Figura 25. Visão dataflows para a especificação de fluxo de dados da Figura 14. Além disso, os usuários frequentemente analisam os atributos representados em um determinado conjunto de dados. Com esse propósito, introduzimos a definição de visão datasetSchemas, que obtém uma relação com os rótulos dos conjuntos de dados (campo dataset), os nomes e os tipos dos atributos manipulados (campos attribute_name e attribute_types), e os rótulos dos extratores de dados empregados em cada atributo (campo extractor), se aplicável. Considerando o script para contagem de palavras, a Figura 26 apresenta a visão datasetSchemas.

Figura 27 .

 27 Figura 27. Visualização de uma especificação de fluxo de dados na perspectiva de grafo.Ao considerar, inicialmente, as análises baseadas em instâncias de apenas uma transformação de dados, uma definiçao de visão foi proposta para consultar os arquivos e os dados científicos produzidos pela simulação computacional, que são representados em um conjunto de dados. Essa visão contém, portanto, tanto os elementos de dados capturados diretamente da simulação computacional (sem extratores), como os dados científicos obtidos pelos extratores. Dessa forma, uma definição de visão é introduzida para cada

Figura 28 .

 28 Figura 28. Visão counts para a execução do script da Figura 14.

Figura 29 .

 29 Figura 29. Análise do fluxo de elementos de dados pelos rastros de proveniência nos níveis físico (setas laranjas) e lógico (seta verde).Além disso, a Figura 30 mostra a consulta na linguagem SQL que retorna os arquivos de entrada (campo file na visão input_files), as palavras e os seus números totais de ocorrências (campos word e count na visão counts), considerando todos os mapeamentos de atributos apresentados na Figura 29. Vale destacar também que, na nossa metodologia, os arquivos são representados nos conjuntos de dados. Logo, ao apoiarmos a análise do fluxo de elementos de dadosanálises de elementos de dados relacionados -, a nossa metodologia também permite a análise do fluxo de arquivosanálises de múltiplos arquivos

  2.5). No modelo de dados lógico proposto, a especificação dessa junção é armazenada na relação extractor_combination, que apresenta o identificador do conjunto de dados (ds_id), os identificadores dos extratores (outer_ext_id e inner_ext_id), os atributos de junção (keys) e os tipos dos atributos de junção (key_types).Por último, a operação transformation exige que o fluxo de dados, os conjuntos de dados, e os programas de simulação já tenham sido especificados (ou seja, já tenham sido registrados a partir da operação program), uma vez que os seus nomes (ou rótulos) são passados como parâmetros. Vale destacar que esses nomes e rótulos são únicos na nossa metodologia. Em função da composição das transformações de dados, a operação transformation também apresenta um comportamento específico ao ser invocada pela segunda vez (ou posteriormente) manipulando um mesmo conjunto de dados de uma transformação de dados anterior. Esse comportamento contempla a identificação das dependências de dados entre as transformações e o registro dessas dependências de dados na relação data_dependency, como discutido anteriormente.Considerando o fluxo de dados especificado para o script da Figura 14, as operações para o armazenamento dos dados de proveniência prospectiva são mostradas na Figura 32.Essas operações realizam consultas de inserção para adicionar tuplas em relações que representam conceitos da abstração de fluxo de dados e de criação de relações (apenas para as operações dataset e extractor), para que os dados de proveniência retrospectiva e os dados de domínio sejam, futuramente, armazenados durante a execução da simulação computacional. Na Figura 32 mostramos também quais relações são utilizadas ou criadas para algumas operações no modelo de dados lógico. Somando-se a isso, o script original desse exemplo (Figura 14) não apresenta linhas de código para realizar a captura de dados científicos. Por essa razão, esse importante recurso foi adicionado pela DfAnalyzer, sendo discutido em detalhes na Subseção 5.3.2.

Figura 32 .

 32 Figura 32. Mapeamento do fluxo de dados para o modelo de dados lógico.

Definição 5 .

 5 2.8. (Acesso aos Dados Científico)O acesso aos dados científicos em um arquivo 𝜑 é uma operação que identifica os elementos de dados e as estruturas de dados dos seus atributos por meio das análises léxica e sintática, segundo metadados presentes em um catálogo de dados científicos 𝜍. Em uma abordagem relacional, cada elemento de dados pode ser representado por uma tupla em uma relação de dados 𝑟 𝑎𝑐𝑐𝑒𝑠𝑠 . Assim, o acesso aos dados científicos presentes em 𝜑, de acordo com 𝜍, é expresso por 𝑟 𝑎𝑐𝑐𝑒𝑠𝑠 ← 𝐴𝑐𝑐𝑒𝑠𝑠(𝜑, 𝜍).

Definição 5 . 2 .

 52 11. (Indexação de Dados Científicos)A indexação de dados científicos é definida pela execução de uma função 𝑓 para gerar índices a partir de elementos de dados de uma relação 𝑟 𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛 obtidos do arquivo 𝜑. A função 𝑓 pode apresentar argumentos adicionais que definem especificidades da técnica de indexação aplicada, como o argumento Å que especifica quais atributos devem ser indexados. Como resultado, essa etapa produz uma relação de dados 𝑟 𝑖𝑛𝑑𝑒𝑥𝑖𝑛𝑔 , de forma que 𝑟 𝑖𝑛𝑑𝑒𝑥𝑖𝑛𝑔 ← 𝑓(𝑟 𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛 , Å).

Figura 33 .

 33 Figura 33. Operação de extração de dados científicos.Considerando o mesmo exemplo apresentado acima, o usuário pode decidir por indexar os valores dos atributos de interesse, como mostrado na Figura 34. Nesse caso, assume-me que a captura de dados científicos considera a indexação de dados, isto é, a etapa(4). No exemplo da Figura 34, um programa indexRDF é utilizado para gerar um arquivo de índices para cada atributo (i.e., WORD e COUNT), evitando a carga direta dos valores dos atributos na base de dados futuramente. De forma análoga à abordagem de extração de dados, esse extrator com a indexação de dados científico também permite que apenas os elementos de dados relevantes, segundo um conjunto de condições ∁ = {𝑐𝑜𝑢𝑛𝑡 > 10}, sejam indexados. Sendo assim, vale ressaltar que o uso de um programa de indexação também pode gerar índices para apenas alguns atributos presentes no arquivo de dados científicos.

Figura 36 .

 36 Figura 36. Dependência de dados entre tarefas. Assim como nos dois primeiros casos, a Figura 36(c) apresenta um exemplo de dependência de dados com apenas uma iteração, em que a tarefa 𝑡 1 2 da transformação de dados 𝑑𝑡 2 depende de dados produzidos pela tarefa 𝑡 1 1 , da mesma maneira que a tarefa 𝑡 1 3 da transformação 𝑑𝑡 3 depende de dados produzidos pela tarefa 𝑡 1 1 . Logo, duas invocações da operação dependency devem ser realizadas, como mostrado a seguir: dependency(𝑡 1 2 , {𝑑𝑡 1 }, {(1)}) e dependency(𝑡 1 3 , {𝑑𝑡 1 }, {(1)}).

Figura 1 .

 1 Figura 37. Arquitetura da DfAnalyzer.5.4.1. Serviços de Fluxo de Dados

  the difference between this solution and the last // nonlinear iterate. last_nonlinear_soln->add(-1., *flow_system.solution); // Close the vector before computing its norm last_nonlinear_soln->close(); // Compute the l2 norm of the difference const Real norm_delta = last_nonlinear_soln->l2_norm(); const Real u_norm = flow_system.solution->l2_norm();

a

  extração de dados científicos usando o RDE são representadas por cartuchos, que precisam ser especificados pelo usuário. Nesta tese, desenvolveu-se dois cartuchos para o RDE, que extraem (a) dados científicos usando programas ad-hoc (SILVA et al., 2017b); e (b) dados científicos ainda alocados em memória por meio da biblioteca ParaView Catalyst (SILVA et al., 2016a), como mostrado na Figura 38. O cartucho (a) caracteriza-se por invocar programas externos, que são responsáveis por acessar os dados científicos, realizar as análises léxica e sintática, e extrair apenas os dados de interesse.

Figura 38 .

 38 Figura 38. Cartuchos para os componentes de extração e de indexação de dados científicos. Já o cartucho (b) consiste em uma integração do RDE com o ParaView Catalyst. Para isso, os programas de simulação, que desejam realizar a extração de dados in situ, precisam implementar um adaptador Catalyst, conforme especificado em Ayachit et al. (2015). Vale ressaltar que esse adaptador requer um mapeamento das estruturas de dados adotadas pelo programa de simulação para o modelo de dados do VTK (VTK, 2009). Uma vez implementado esse adaptador, o Catalyst pode extrair dados a partir de scripts na linguagem de programação Python, que implementam pipelines de coprocessamento. Para facilitar o desenvolvimento desses scripts em Python, o ParaView conta com um recurso de geração automática desses scripts por meio da sua interface gráfica.

Figura 39 .

 39 Figura 39. Diagrama de sequência para (1) a modelagem do fluxo de dados (etapa offline) e (2) a extração de dados durante a execução da simulação computacional (etapa online).

Figura 40 .

 40 Figura 40. Fragmento do fluxo de dados analisado em uma simulação real de dinâmica de fluidos computacionais.

Figura 41 .

 41 Figura 41. Visualização de uma especificação de fluxo de dados usando o DfViewer.

Figura 43 .

 43 Figura 43. Workflow científico Montage.

Figura 44 .

 44 Figura 44. Workflow científico sintético de Óleo e Gás. Após a execução de C, duas outras transformações de dados, conhecidas como D e E, são executadas em paralelo e apresentam o comportamento de um filtro. Para essas transformações de dados, considerou-se que as seletividades dos filtros (CHIRIGATI et al., 2012) seriam iguais a 60% e 80%, respectivamente. Após a execução de D e E, a transformação de dados F une os elementos de dados dos conjuntos de dados R4 e R5. Por último, a transformação de dados G agrupa conjuntos de elementos de dados de acordo com um atributo de agregação.

Figura 45 .

 45 Figura 45. Workflow científico EdgeCFD. Como resultado, esse solucionador produz diferentes arquivos nos formatos XDMF e HDF5, que apresentam informações sobre a pressão, a velocidade e outras propriedades do fluido nesse intervalo de tempo. Mais especificamente, os arquivos HDF5 contém valores para os atributos de domínio (e.g., velocidade do fluido) e os arquivos XDMF apresentam ponteiros para indicar cada arquivo no formato HDF5 para os diferentes passos de tempo dessa simulação. Por último, as atividades Pre RDC e Solver RDC são atividades com apoio à captura de dados científicos em arquivos (do termo, em inglês, Raw Data Capturesigla RDC), sendo que a estratégia de extração de dados científicos e de geração de índices podem variar nessas atividades.

Figura 46 .

 46 Figura 46. Workflow EdgeCFD: (a) condições de contorno e (b) validação do fluxo da cavidade para número de Reynolds Re=1000.

  computacional utilizando o libMesh-sedimentation. A transformação Configuração do AMR/C é responsável por consumir uma malha de entrada e definir as configurações a serem aplicadas para o refinamento da malha adaptativa. A transformação Configuração da Simulação define propriedades mais gerais do solucionador, como o tempo máximo da simulação e os níveis de tolerância linear e não linear.

Figura 47 . 2 (

 472 Figura 47. Simulação computacional usando o solucionador libMesh-sedimentation. Já as transformações de dados subsequentes estão presentes dentro de um loop que itera a simulação computacional no tempo, ou seja, um passo de tempo avança em cada iteração desse loop até alcançar o tempo máximo definido. Nesse sentido, a primeira transformação de dados dentro desse loop, Reconfigurar Parâmetros de Simulação, apenas apresenta processamento computacional, quando os usuários realizam ajustes nos parâmetros de entrada do solucionador libMesh-sedimentation. Em seguida, o solucionador progride para calcular o comportamento esperado do fluido e dos sedimentos em um passo de tempo específico nas transformações de dados Solucionador do Fluido e Solucionador dos Sedimentos, respectivamente, considerando as configurações mais recentes dos parâmetros de entrada da simulação.

Figura 48 .

 48 Figura 48. Tanque de sedimentação proposto por de Rooij e Dalziel.Outro estudo de caso considera um tanque real de batimetria, conforme o cenário físico mostrado na Figura 49. O mapa de cor dessa figura representa a batimetria em um cenário real, em que as regiões mais fundas apresentam a cor azul escuro. Nesse cenário, uma mistura diluída dos sedimentos é continuamente injetada no canal de forma que os

Figura 49 .

 49 Figura 49. Tanque real de batimetria: cenário físico.A discretização espacial emprega uma malha desestruturada fixada com 7.674.812 tetraedros e 1.418.934 nós. A mistura monodispersa é considerada com velocidade de sedimentação adimensional us = 5,6651 x 10 -3 , Gr = 10 6 e Sc = 1,0. O passo de tempo é fixado como t = 5 x 10 -3 e a análise é realizada a cada 100 unidades adimensionais de tempo.

FDR - 56

 56 Gbs (Hypercube). Além disso, esse cluster computacional apresenta uma partição para armazenamento de dados usando o sistema de arquivo paralelo Intel Lustre, com a capacidade de armazenamento de 500 TB de dados. Para utilizar a DfAnalyzer, a base de dados de proveniência usando o SGBD MonetDB foi instanciada em um nó computacional dedicado para armazenar os dados de proveniência e os dados científicos nesse SGBD. Esse nó computacional com a base de dados possuía 24 processadores. A DfAnalyzer consome as requisições HTTP com os dados de proveniência e os dados científicos por meio dos seus serviços RESTful. Em seguida, por meio da validação desses dados, a DfAnalyzer estabelece uma conexão com a base de dados do MonetDB por meio do driver JDBC para carregar os dados extraídos. Considerando o solucionador libMesh-sedimentation, a Figura 50 mostra a integração do libMesh-sedimentation com o cartucho do Extrator de Dados Científicos (RDE) da DfAnalyzer que utiliza a ferramenta ParaView Catalyst (Subseção 5.4). Esse cartucho permite o apoio à extração e à visualização de dados científicos in situ. Nesse cenário, a invocação do Catalyst consiste em scripts na linguagem de programação Python, que implementam pipelines para extrair e visualizar dados científicos presentes em cada ponto da malha.

Figura 50 .

 50 Figura 50. libMesh-sedimentation usando DfAnalyzer e ParaView Catalyst.Mais especificamente, as invocações para o Extrator de Dados de Proveniência (PDE) estão presentes no código fonte do libMesh-sedimentation para capturar dados de proveniência a cada iteração (como apresentado na Subseção 5.4). Do mesmo modo, as

Figura 51 .

 51 Figura 51. Perfis de concentração dos sedimentos em (a) t = 10 e (b) t = 20 no tanque de de Rooij e Dalziel.

•

  SyntheticOil&Gas e EdgeCFD usando o SGWfC SCC-A. Nessa avaliação consideramos duas análises, uma baseada em diferentes tempos de execução para as transformações de dados de acordo com uma função gama (CHIRIGATI et al., 2012) e outra variando-se o tamanho dos arquivos de dados científicos manipulados pelo workflow científico. A primeira análise considerou apenas o workflow científico sintético, enquanto que a segunda análise contemplou os dois workflows; • Custo da indexação de dados científicos: Avaliação do custo em termos de tempo ao aplicar técnicas de indexação de dados científicos nos workflows SyntheticOil&Gas e EdgeCFD. As técnicas de indexação aplicadas nesses workflows científicos utilizaram os cartuchos desenvolvidos na arquitetura RDC para o SCC-A; Custo da carga de dados científicos: Avaliação do custo em termos de tempo ao realizar a carga dos dados científicos extraídos ou dos índices gerados em uma base de dados relacional. Nesse experimento considerou-se o workflow EdgeCFD usando o SCC-A; e• Custo da captura de dados científicos em uma abordagem in situ: Análise do custo da captura dos dados científicos e dos dados de proveniência em termos do tempo e do volume de dados a serem armazenados, além da análise do custo da carga dos dados em uma base de dados. Esse experimento contempla a execução da simulação computacional baseada no solucionador libMesh-sedimentation usando a biblioteca de componentes DfAnalyzer para apoiar a processamento, a análise e a visualização de dados in situ.

Figura 52 .

 52 Figura 52. Custo da extração de dados científicos usando o workflow Montage.

Figura 58 .

 58 Figura 58. Carga de dados no SGBD do SCC-A usando o workflow EdgeCFD.Outra avaliação realizada baseou-se na investigação do custo de carga dos dados com diferentes cargas de trabalho ainda utilizando o workflow EdgeCFD. Nesse caso, os três tipos de malhas foram considerados, variando-se o número de vértices na malha: grossa, média e fina. Logo, para cada tamanho da malha, analisou-se o custo de carregar os dados na base de dados de proveniência, variando-se o apoio à extração de dados científicos e o uso de um algoritmo de indexação (posicional ou bitmap).

Figura 59 .

 59 Figura 59. Custo da carga de dados com diferentes cargas de trabalho.Considerando a versão idx-bitmap do workflow que utiliza a ferramenta FastBit, apenas o caminho para o arquivo de índice gerado (i.e., catálogo que pode ser utilizado no processamento de consulta) é carregado na base de dado para permitir a redução do tempo de execução da carga de dados e do espaço em disco necessário para a base de dados, como

Figura 62 .

 62 Figura 62. Resultados da consulta da Figura 61.Somando-se a isso, na nossa abordagem, os atributos selecionados podem ser capturados e armazenados em uma base de proveniência integrada (i.e., de acordo com o modelo de dados PROV-Df apresentado na Seção 4.4), enquanto eles estão sendo escritos no arquivo. Nessa perspectiva, diferentemente das soluções existentes para a análise exploratória de dados científicos, a nossa abordagem considera a gerência do fluxo de arquivos e do fluxo de elementos de dados, integrando dados de proveniência, de execução e científicos em uma mesma base de dados.

Figura 65 .

 65 Figura 65. FLUXO_DE_ELEMENTOS -Análise da velocidade do fluido na coordenada x variando o método inexato de Newton para o solucionador. Diante dessa descrição, os usuários podem processar essa consulta para investigar o comportamento do solucionador ao longo da simulação computacional, considerando diferentes combinações de valores para os atributos, como a viscosidade e a densidade do fluido. A Figura 66 apresenta as tabelas da base de dados relacional do SCC-A que apresenta os dados específicos do domínio analisados pela consulta FLUXO_DE_ELEMENTOS. Nesse sentido, as tabelas RPreRDC e RSolverRDC apresentam os dados científicos extraídos de arquivos usando o operador algébrico Raw (apenas extração de dados) ou RawI(extração e indexação dos dados), conforme apresentado na Subseção 4.7.2. Enquanto isso, as setas tracejadas representam os atributos utilizados para relacionar tuplas de duas tabelas.No caso dessa consulta, apenas atributos associados aos identificadores da execução dos programas de simulação (ou tarefas) foram utilizados, como os atributos previoustaskid e

Figura 67 .

 67 Figura 67. FLUXO_DE_DADOS -Análise da convergência da simulação de CFD ao fixar determinados valores de atributos de domínio.

Figura 69 .

 69 Figura 69. DESEMPENHO -Análise de desempenho do solucionador de CFD ao fixar a densidade do fluido e a configuração do solucionador inexato de Newton.

SELECT

  rprerdc.VISC, a.elapsedTime FROM RPreRDC rprerdc, RSSConfig rconf, RECFDSolver rsolv, RSolverRDC rsolvrdc, activation a WHERE rprerdc.nextActivationID = rconf.previousActivationID AND rconf.nextActivationID = rsolv.previousActivationID AND rsolv.nextActivationID = rsolvrdc.previousActivationID AND rsolvrdc.previousActivationID = a.activationID AND rprerdc.DENS = 1 AND rprerdc.ISOLVER = 3;

6. 3 .3 e 6 . 3 . 4 .

 3634 Além disso, técnicas de processamento de consultas de forma adaptativa, como apresentado no RAW[START_REF] Karpathiotakis | Adaptive Query Processing on RAW Data[END_REF], poderiam ser empregadas para reduzir o tempo de processamento das consultas, quando não fosse a sua primeira submissão para o pré-processador de consultas.SEDIMENTAÇÃO.Somando-se ao potencial de análise do fluxo de dados, conforme apresentado nas consultas anteriores, a abordagem proposta nesta tese também apoia o processamento de consultas que visam monitorar, depurar e intervir nas simulações computacionais em tempo de execução. Na simulação de sedimentação utilizando o solucionador libMesh-sedimentation, os usuários estão tipicamente interessados em monitorar o progresso do seu modelo computacional, depurar o desempenho da sua aplicação e, eventualmente, realizar intervenções na execução da simulação por meio de ajustes nos parâmetros de entrada. Sendo assim, as consultas apresentadas para esta simulação consideram essas quatro propriedades: monitoramento, depuração, intervenção, e análise de dados científicos. Vale enfatizar que, apesar de apresentarmos as consultas na linguagem SQL, as mesmas foram obtidas a partir da sua especificação utilizando o componente QI da DfAnalyzer (Capítulo 5). Ademais, todas as consultas foram executadas 10 vezes, desconsiderando-se uma primeira execução para tirar proveito de dados alocados em memória, e nenhuma delas executou em mais de 400 milissegundos.No cenário de monitoramento do fluxo de dados, os usuários de domínio frequentemente submetem a consulta mostrada na Figura 70, que analisa quando a concentração de sedimentos depositados no fundo do tanque (i.e., malha) é diferente de zero. Para isso, dados de uma linha posicionada no fundo da malha são extraídos utilizando o cartucho de extração de dados in situ da DfAnalyzer. Portanto, ressalta-se a necessidade de conhecermos a malha antes da execução da simulação, para que os algoritmos de extração sejam desenvolvidos na linguagem Python para o ParaView Catalyst e, consequentemente, sejam capazes de obter os dados científicos de interesse em tempo de execução. Para essa consulta, utilizou-se a malha referente ao tanque real de batimetria (Subseção 6.1.4) e alguns elementos de dados obtidos, como resultado do processamento dessa consulta, são mostrados na Figura 71.

Figura 70 .

 70 Figura 70. Monitoramento da concentração de sedimentos no tanque de batimetria.

Figura 71 .

 71 Figura 71. Resultado da consulta de monitoramento da concentração de sedimentos.Outra consulta importante, ainda nessa simulação computacional, envolve a depuração do desempenho do solucionador libMesh-sedimentation em tempo de execução, conforme mostrado na Figura 72. Nesse caso, os usuários tipicamente analisam os

FiguraFigura 73 .

 73 Figura 72. Consulta de depuração do solucionador libMesh-sedimentation.

Figura 74 .Figura 75 .

 7475 Figura 74. Consulta para apoiar intervenções nos parâmetros de entrada do solucionador.

  de dados para representar uma simulação computacional como uma sequência de transformações de dados e acompanhar a propagação dos dados de domínio (como conjuntos de dados) ao longo dos programas de simulação em uma granularidade fina (i.e., múltiplos arquivos ou elementos de dados relacionados). Essa definição norteou a gerência do fluxo de dados que é o principal recurso para apoiar a consistência, a reprodutibilidade e o armazenamento de dados de proveniência em uma granularidade fina para consultas. (ii) Modelo de dados de proveniência PROV-Df, compatível com as recomendações do PROV W3C, para representar os dados de proveniência e os dados de domínio envolvidos no fluxo de dados tanto no nível físico, como no lógico. (iii) Metodologia para identificar o fluxo de dados em simulações computacionais, a partir da extensão de uma metodologia já existente que permitia o apoio à captura de dados de proveniência em aplicações computacionais, conhecida como PrIMe. (iv) A arquitetura ARMFUL que detalha como prover a captura e a análise de dados científicos, considerando técnicas de captura de dados científicos e uma interface para o processamento de consultas. Cartuchos foram desenvolvidos nos componentes de extração e de indexação de dados científicos, permitindo o uso de ferramentas alternativas, como o FastBit, o PostgresRaw e o ParaView Catalyst. (v) Implementações dessa arquitetura em um SGWfC, o SCC-A, e como uma biblioteca de componentes, a DfAnalyzer.

  

  

  

  

  

  

  

  

  De forma análoga, o RDataTracker (LERNER e BOOSE, 2015) consiste em uma biblioteca para a captura do fluxo de elementos de dados oriundos da execução de scripts em R. Para isso, o RDataTracker baseia-se em um processo de instrumentação dos scripts,

	al., 2013) e o Wings (GIL et al., 2011), percebe-se que elas não permitem o processamento que pode ter diferentes níveis de intrusão. Em uma abordagem menos intrusiva, o usuário
	de consultas direcionadas ao fluxo de elementos de dados. Como exceção, o LabelFlow assim como as portas de entrada e de saída de cada programa (ou atributos consumidos e precisa especificar no script em que linhas de código se deve começar e finalizar a captura
	(ALPER et al., 2015) permite, por um sistema de anotações, o armazenamento de produzidos), sendo que as dependências de dados (conhecidas como canais pelo de dados por essa biblioteca. Nesse caso, o grafo de proveniência obtido pode ser muito
	metadados quanto à estrutura do fluxo de dados, assim como os dados de domínio YesWorkflow) são inferidas de acordo com a propagação de portas entre os programas. detalhado, dificultando o desenvolvimento das análises requeridas pelo usuário. Assim,
	manipulados pela simulação computacional. Em contrapartida, esse sistema não permite a Ademais, essa ferramenta também conta com três visualizações possíveis de acordo uma abordagem mais intrusiva pode ser realizada, em que apenas os processos (ou
	captura de dados científicos armazenados em arquivos, embora os elementos de dados com o workflow modelado, sendo baseadas (i) nos blocos de programa, (ii) nos atributos transformação de dados em nossa abstração) e os atributos de interesse devem ser
	acessíveis nos programas de simulação (como caixas brancas) possam ser rastreados. especificados. Vale ressaltar que as mesmas limitações observadas para o noWorkflow são
	observadas no RDataTracker.
	2015), o noWorkflow (MURTA et al., 2014) e o RDataTracker (LERNER e BOOSE,
	2015).

3.2, oferecem a abstração de workflows científicos para apoiar a composição, execução, gerência e análise de simulações computacionais. Atualmente, alguns SGWfC têm apresentado funcionalidades para a gerência do fluxo dos elementos de dados, como o Kepler

[START_REF] Bowers | Kepler/pPOD: Scientific Workflow and Provenance Support for Assembling the Tree of Life[END_REF]

, o Panda (IKEDA e WIDOM, 2010) e o SCC, sendo que o último consiste na integração dos SGWfC Chiron

[START_REF] Ogasawara | Chiron: A Parallel Engine for Algebraic Scientific Workflows[END_REF] 

e SciCumulus

[START_REF] De Oliveira | SciCumulus: A Lightweight Cloud Middleware to Explore Many Task Computing Paradigm in Scientific Workflows[END_REF]

. Por outro lado, essas propostas não apoiam a gerência do fluxo de elementos de dados presentes em arquivos de dados científicos, o que limita o seu potencial analítico.

O Kepler define formalmente o encadeamento de atividades como um workflow científico, que corresponderia à simulação computacional com os seus programas encadeados, consumindo e produzindo arquivos com dados científicos. Além de apoiar a gerência de arquivos, esse SGWfC também gerencia o fluxo dos elementos de dados.

Entretanto, o Kepler não permite o acesso e a captura de dados científicos presentes em arquivos de dados científicos, característico da análise exploratória de dados científicos.

Consequentemente, esse sistema não permite consultas ao conteúdo de arquivos de dados científicos e apresenta limitações para as consultas aos elementos de dados relacionados, conforme apresentadas no Capítulo 1.

Com o intuito de gerenciar o rastro do fluxo de arquivos e de elementos de dados produzidos por uma simulação computacional, o Panda propõe um elegante e poderoso formalismo para dados de proveniência (IKEDA e WIDOM, 2010). Todavia, esse sistema também possui a mesma desvantagem do Kepler: o apoio ao acesso aos dados científicos presentes em arquivos ou mesmo alocados em memória. Ao considerar outras soluções existentes que apoiam a gerência da proveniência de dados, como o Pegasus Lite (VAHI et Já o SCC (SciCumulus + Chiron) contempla o uso de uma álgebra de workflows centrada em dados para compor e executar simulações computacionais em ambientes de PAD. Nessa máquina paralela, os workflows são representados e executados como expressões algébricas compostas de operações, que encapsulam programas de simulação e operandos para representar o fluxo de dados. Somando-se a isso, o SCC permite a captura de dados de proveniência e de determinados dados de domínio em tempo de execução.

Portanto, essa máquina paralela de workflows científicos apoia as consultas ao conteúdo de arquivos e a múltiplos arquivos, enquanto que o apoio às consultas aos elementos de dados relacionados (ou fluxo dos elementos de dados) apresentam limitações nessa máquina de workflows.

Portanto, de um modo geral, o uso de SGWfC requer um esforço considerável de aprendizagem por parte dos usuários para modelar as suas simulações computacionais para permitir as análises focadas em dados de proveniência e de domínio. Por esse motivo, outras soluções têm sido propostas com a estratégia de prover recursos para que os usuários não precisem se adaptar a outros ambientes de trabalho (i.e., aprendizado de outra linguagem de programação ou de como modelar um workflow científico) para realizarem as suas análises. Como exemplos dessas soluções temos o YesWorkflow

(MCPHILLIPS et al., Primeiramente, o YesWorkflow (MCPHILLIPS et al., 2015) 

consiste em uma ferramenta capaz de capturar e analisar dados de proveniência prospectiva de scripts desenvolvidos independentemente da linguagem de programação. Para isso, essa ferramenta exige que o usuário adicione anotações em forma de comentários em seus scripts para representar o workflow científico da simulação computacional. Dessa forma, o usuário deve definir os blocos de programa (ou transformações de dados) envolvidos no workflow, consumidos e produzidos por cada programa, e (iii) em ambos, ou seja, apresenta os blocos e os atributos em uma mesma visualização. Mesmo permitindo a investigação da estrutura da simulação computacional executada, o YesWorkflow não permite análises que envolvem uma granularidade mais fina (i.e., proveniência retrospectiva), relacionando o consumo e a produção dos elementos de dados pelos programas. Ademais, o processo de captura dos dados requer uma etapa de ajuste manual dos programas de simulação por parte do usuário.

De forma complementar ao YesWorkflow, o noWorkflow

[START_REF] Murta | noWorkflow: Capturing and Analyzing Provenance of Scripts[END_REF] 

consiste em uma ferramenta que permite a análise dos dados de proveniência prospectiva e retrospectiva em scripts, sem que o usuário precise modificar os seus scripts na linguagem de programação Python. Para isso, o interpretador original do Python foi modificado para permitir a gerência das principais operações dos scripts em tempo de execução, como em métodos de leitura e escrita de dados em arquivos. Outros recursos também são centrados na análise da proveniência retrospectiva por meio da visualização do fluxo dos elementos dados no controle de versões (ou execuções) dos scripts. Entretanto, pelo fato do usuário não especificar as transformações de dados (ou funções em Python) de interesse, o noWorkflow captura os dados de proveniência em uma granularidade muito fina, monitorando informações sobre invocações de funções e atribuições de variáveis que podem não ser necessárias do ponto de vista analítico. Além de ser específica para scripts em Python, essa ferramenta também não considera a captura de dados científicos de arquivos, a execução de scripts de natureza paralela em ambientes de PAD, ou mesmo apresenta uma modelagem da sua base de dados de proveniência que favoreça a análise do fluxo de elementos de dados.

Diferentemente das propostas anteriores, o Tigres

[START_REF] Hendrix | Tigres Workflow Library: Supporting Scientific Pipelines on HPC Systems[END_REF] 

é uma biblioteca na linguagem de programação Python que exige a modelagem da simulação computacional como um workflow científico. Para isso, o usuário precisa especificar as tarefas a serem executadas em cada programa ou transformação de dados do workflow. Em relação à essa especificação, o Tigres propõe um conjunto de padrões para as funções ou transformações de dados a serem executadas (sequence, parallel, merge e split), além de conter uma camada em sua arquitetura focada na adaptação do script em Python para ser executado em diferentes ambientes computacionais, desde em máquinas locais até em ambientes de PAD. Logo, essa biblioteca assume que o usuário comumente executa programas caixas-pretas e precisa especificar, por meio de um script, a estrutura do workflow científico, assim como as tarefas e os dados de entrada para cada tarefa. Por esse motivo, o Tigres requer que o usuário tenha conhecimento da linguagem de programação Python para especificar a execução do workflow em um script; e saiba, a priori, todas as tarefas que serão executadas (e os seus dados de entradas), o que não é trivial em simulações computacionais que envolvam, especialmente, intervenções dos usuários em tempo de execução.

  Enquanto isso, os SGWfC com apoio à captura de dados de proveniência, como o Kepler, o Chiron e o Pegasus Lite, permitem registrar o fluxo de arquivos e o fluxo de elementos de dados produzidos pela execução de simulações computacionais. Contudo, eles apresentam limitações associadas à captura de dados científicos em arquivos. Somando-se a isso, esses SGWfC exigem ajustes nos programas de simulação para que a execução paralela em ambientes de PAD seja gerenciada pelos seus próprios controles de execução.

	Em função dessa limitação dos SGWfC existentes, observa-se mais recentemente o
	surgimento de sistemas focados na captura de dados de proveniência em tempo de
	execução, como o noWorkflow e o RDataTracker. Esses sistemas contribuem tanto em

Nesta tese, seguimos uma categorização dos diferentes sistemas estudados, sendo estes divididos em basicamente três categorias: sistemas tradicionais de análise de dados científicos em arquivos, SGWfC e sistemas de captura de dados de proveniência. Em relação aos sistemas tradicionais de análise de dados científicos, como o FastBit, o FastQuery, o SDS/Q, o PostgresRaw e o AQUAdex, observou-se que essas soluções consideram apenas o acesso e a análise de dados científicos presentes em arquivos de forma isolada. Além disso, esses sistemas apresentam uma sobrecarga relacionada à leitura dos dados dos arquivos, à transformação desses dados em estruturas de dados mais adequadas para o repositório externo ou a base de dados, e à carga dos dados nesse repositório externo. Dessa forma, esses sistemas não estão no mesmo contexto desta tese, que considera a análise de dados científicos durante a execução de simulações computacionais, pois eles consistem em abordagens post-mortem.

manter o ambiente de desenvolvimentos dos usuários do domínio científico ou do próprio desenvolvedor da aplicação, como em prover recursos que não exijam a especificação de quais dados precisam ser capturados durante a execução das aplicações de CSE, por meio de recursos de instrumentação automática de código fonte. Apesar de todo o seu apoio à captura e à análise dos dados, tais sistemas normalmente não são desenvolvidos para apoiar a execução paralela em ambientes de PAD e são dependentes de uma linguagem de programação para o acoplamento dos programas de simulação com esses sistemas.

Definição 3.2.3. (Minimalidade) Assume

  e, nesta tese, adaptamos o seu formalismo para a abstração de fluxo de dados, conforme apresentado a seguir. Assume-se que uma instância da transformação de dados 𝑡 é representada por 𝑐 𝑜 = 𝑡 * (𝑐 𝑖 ). Considerando um elemento de dados de saída 𝑒 ∈ 𝑐 𝑜 , a proveniência𝑐 𝑖 ′ ⊆ 𝑐 𝑖 é correta para 𝑒 com relação à 𝑡 * ,se ∀𝑐 𝑖 ′ ⊆ 𝑐 𝑖 : 𝑒 ∈ 𝑡 * (𝑐 𝑖 ) ⟺ 𝑒 ∈ 𝑡 * (𝑐 𝑖 ∩ 𝑐 𝑖 ′ ). Assume-se que uma instância da transformação de dados 𝑡 é representada por 𝑐 𝑜 = 𝑡 * (𝑐 𝑖 ) e que 𝑒 ∈ 𝑐 𝑜 . Supondo que os subconjuntos 𝑐 𝑖 ′ ⊆ 𝑐 𝑖 e 𝑐 𝑖 ′′ ⊆ 𝑐 𝑖 sejam ambas proveniências corretas para 𝑒 com relação à 𝑡 * , 𝑐 𝑖 -se que uma instância da transformação de dados 𝑡 é representada por 𝑐 𝑜 = 𝑡 * (𝑐 𝑖 ) e que 𝑒 ∈ 𝑐 𝑜 . Supondo que o subconjunto 𝑐 𝑖 ′ ⊆ 𝑐 𝑖 seja uma proveniência correta para 𝑒 com relação à 𝑡 * , 𝑐 𝑖 ′ é mínimo para 𝑒, se não existir uma proveniência correta 𝑐 𝑖 ′′ para 𝑒 com relação à 𝑡 * que seja mais precisa que 𝑐 𝑖 ′ .

	Definição 3.2.1. (Corretude) Definição 3.2.2. (Precisão) ′ é, pelo menos, tão preciso quanto 𝑐 𝑖 ′′ , se 𝑐 𝑖 ′ ⊆ 𝑐 𝑖 ′′ .
	𝑐 𝑖 ′ é mais preciso que 𝑐 𝑖 ′′ , se 𝑐 𝑖 ′ ⊂ 𝑐 𝑖 ′′ .

3.2.3. Proveniência dos elementos de dados

  

	Como proposto por Ikeda et al. (2013), um workflow orientado a dados é composto
	de transformações de dados, considerando alguns conjuntos de dados de entrada e outros
	conjuntos de dados de saída. Do mesmo modo, um fluxo de dados, conforme definido na
	Seção 3.1, pode ser representado por um workflow orientado a dados. Ao assumir que cada
	transformação de dados 𝑡 𝑖 (ou simplesmente 𝑡) contém uma especificação de proveniência
	𝑝𝑟𝑜𝑣 𝑡 , também é possível descrever a proveniência de um elemento de dados de saída
	𝑒 𝜖 𝑜. 𝐶 a partir de instâncias da transformação de dados 𝑡 por 𝑝𝑟𝑜𝑣 𝑡 (𝑒) ⊆ ⋃ 𝑐𝑎𝑟𝑑(𝑡.𝐼) 𝑘=1	𝑖 𝑘 . 𝐶	,
	onde 𝑖 𝑘 representa um conjunto de dados de entrada da transformação 𝑡. Adotando-se esse
	conceito, pode-se definir a proveniência do elemento de dados de uma forma recursiva.	

Definição 3.2.4. (Proveniência do Elemento de Dados) Assumindo

  

			um fluxo de dados 𝐷 𝐹 , a
	proveniência do elemento de dados 𝑒 em 𝐷 𝐹 , denotada por 𝑝𝑟𝑜𝑣 𝐷 𝐹 (𝑒), é um subconjunto de
	elementos de dados de entrada a partir de instâncias das transformações de dados anteriores.
	Considerando que 𝑡 seja a transformação de dados que produz o elemento de dados de saída 𝑒, então
	𝑝𝑟𝑜𝑣 𝐷 𝐹 (𝑒) = ⋃	𝑒′ 𝜖 𝑝𝑟𝑜𝑣 𝑡 (𝑒)	𝑝𝑟𝑜𝑣 𝐷 𝐹 (𝑒′)

Definição 3.2.5. (Esquema do Conjunto de Dados) Um

  conjunto de dados 𝑠 possui um esquema de dados ℛ = 𝑠. 𝐴 ∪ 𝐴 𝑇 ′ , que consiste de uma sequência de atributos de domínio a partir de 𝑠 e de atributos identificadores 𝐴 𝑇 ′ para as instâncias de cada transformação de dados de 𝑇 ′ .

	transformação de dados. Essa condição também implica que a próxima transformação de
	dados precisa que os elementos de dados sejam gerados pela transformação de dados
	anterior para começar a sua execução.
	Desse modo, eles permitem que os usuários do domínio científico realizem
	análises baseadas no fluxo dos elementos de dados (ou das coleções de dados) em diferentes
	transformações de dados. Além disso, o rastro de proveniência pode ser classificado em
	duas granularidades: grossa e fina. O rastro de proveniência em granularidade grossa
	considera a análise dos conjuntos de dados consumidos e produzidos pelas transformações
	ao longo do fluxo de dados. Enquanto isso, o rastro de proveniência em granularidade fina
	define um nível de abstração mais baixo, uma vez que esse rastro é baseado nas
	transformações dos elementos de dados, ou seja, em fragmentos dos conjuntos de dados
	consumidos e produzidos por instâncias das transformações de dados.
	Para apoiar a gerência do rastro de proveniência em granularidade fina, os elementos
	de dados dos conjuntos de dados manipulados pelas transformações de dados precisam ser
	relacionados. Para isso, os esquemas dos conjuntos de dados (Definição 3.2.5) precisam ser
	considerados e as três propriedades seguintes são fundamentais nesse contexto:
	mapeamento de atributo, mapeamento de múltiplos atributos e transitividade nos
	mapeamentos de múltiplos atributos. Esses conceitos foram propostos por Ikeda et al.
	(2013) e foram adaptados nesta tese para a abstração de fluxo de dados, conforme
	apresentado nas Definições 3.2.6 e 3.2.7, assim como no Teorema 3.2.1. As propriedades
	de mapeamento de atributos e de mapeamento de múltiplos atributos definem como os
	atributos de um conjunto de dados de entrada são transmitidos para o conjunto de dados de
	saída. A transitividade em mapeamentos de atributos assume a existência de dependências
	funcionais entre atributos dos elementos de dados de saída referentes à uma transformação
	de dados anterior e atributos dos elementos de dados de entrada de uma próxima

Definição 3.2.6. (Mapeamento de Atributo) Uma

  transformação de dados 𝑡 tem um mapeamento de atributo 𝑖. 𝑎 ′ ↔ 𝑜. 𝑎 ′′ , se ∀𝑥 ∈ 𝑑𝑜𝑚𝑎𝑖𝑛(𝑎 ′′ ) ∧ (𝑎 ′ . 𝑛𝑎𝑚𝑒 = 𝑎 ′′ . 𝑛𝑎𝑚𝑒) ∧ (𝑎 ′ . 𝑡𝑦𝑝𝑒 = 𝑎 ′′ . 𝑡𝑦𝑝𝑒) ∧ (∀𝑖 ′ ∈ 𝑖 ∶ (𝜎 𝑎 ′′ =𝑥 𝑡(𝑖´) = 𝜎 𝑎 ′′ =𝑥 𝑡(𝜎 𝑎 ′ =𝑥 (𝑖´)))).

Definição 3.2.7. (Mapeamento de Múltiplos Atributos) Uma

  transformação de dados 𝑡 tem um mapeamento múltiplo de atributos 𝑖. 𝐴 ′ ↔ 𝑜. 𝐴 ′′ , se 𝑐𝑎𝑟𝑑(𝑖. 𝐴 ′ ) = 𝑐𝑎𝑟𝑑(𝑜. 𝐴 ′′ ) ∧ (∀𝑎 ′ ∈ 𝑖. 𝐴 ′ , ∀𝑎 ′′ ∈ 𝑖. 𝐴 ′′ : 𝑖. 𝑎 ′ ↔ 𝑜. 𝑎 ′′ ).

Teorema 3.2.1. (Transitividade em Mapeamentos de Múltiplos Atributos) Se

  a transformação de dados 𝑡 ′ tem um mapeamento de múltiplos atributos 𝑠 ′ . 𝐴 ′ ↔ 𝑠 ′′ . 𝐴 ′′ , a transformação de dados 𝑡 ′′ tem um mapeamento de múltiplos atributos 𝑠 ′′ . 𝐴 ′′ ↔ 𝑠 ′′′ . 𝐴 ′′′ , e o fluxo de dados 𝐷 𝐹 tem uma dependência de dados 𝜑 = (𝑠 ′′ , 𝑡 ′ , 𝑡 ′′ ), então existe também, por transitividade, o mapeamento de múltiplos atributos 𝑠 ′ . 𝐴 ′ ↔ 𝑠 ′′′ . 𝐴 ′′′ em 𝐷 𝐹 .

	T1_TASKID e T2_TASKID) são relacionados entre os conjuntos de dados 𝑠 1 , 𝑠 2 e 𝑠 3 ,
	respectivamente. Já a Figura 3(b) mostra um exemplo de mapeamentos lógicos em que os
	atributos específicos do domínio (i.e., FILE e WORD) são relacionados pelos conjuntos de
	dados 𝑠 1 , 𝑠 2 e 𝑠 3 .
	Diferentemente de Ikeda et al. (2013), que argumentam que a adição do apoio à
	proveniência física (ou seja, uso de identificadores para as instâncias da transformação de
	dados) adiciona uma sobrecarga de tempo considerável à carga de dados, esta tese apresenta
	uma abordagem que considera o armazenamento de dados, tanto da proveniência lógica
	(i.e., atributos do domínio científico) como da proveniência física (Definição 3.2.5). Ao
	mesmo tempo, Ikeda et al. (2013) também enumeram as limitações relacionadas à
	preservação da precisão e, consequentemente, da minimalidade ao utilizarem uma
	abordagem exclusivamente baseada na proveniência lógica. Por esse motivo, a nossa
	abordagem segue uma proveniência híbrida (ou seja, física e lógica).
	A Figura 3 mostra a diferença entre as abordagens de proveniência física e lógica a
	partir do exemplo de fluxo de dados para a contagem de palavras em arquivos de texto
	(Exemplo 3.1.1). Mais especificamente, a Figura 3(a) mostra um exemplo de mapeamentos
	físicos em que os atributos das instâncias das transformações de dados 𝑡 1 e 𝑡 2 (i.e.,

3.3.2. Sistema de Gerência de Workflows Científicos (SGWfC)

  

	al., 1999). Cada SGWfC pode apresentar um ou mais modelos de computação e a execução
	de um modelo determina como os dados são processados, considerando as restrições de
	especificação do workflow científico.
	Ao considerar a definição de fluxo de dados, os elementos de dados de entrada
	podem ser subdivididos em tarefas, que consomem um subconjunto de elementos de dados
	e processam esses elementos de dados de acordo com a especificação da transformação de
	dados. Assumindo-se que as tarefas tenham sido geradas, elas podem ser distribuídas para
	os recursos computacionais a fim de realizar o processamento dos dados. Dessa forma, esta
	Um workflow científico com essas características é geralmente centrado em dados e tese está direcionada aos estudos de SGWfC que realizam a distribuição de tarefas para
	conduzido por dados ou, como definido por Ogasawara et al. (2011), ele seria um workflow recursos computacionais remotos, ou seja, os que apresentam recursos para a execução
	científico centrado em dados. Ogasawara et al. (2011) afirmam também que tal workflow paralela e distribuída tipicamente requisitada pelos ambientes de PAD.
	centrado em dados pode ser modelado como um grafo direcionado acíclico (conhecido pela
	sigla DAG, do termo em inglês Directed Acyclic Graph), em que os vértices representam
	as atividades e as arestas representam o fluxo de dados entre as atividades.
	Devido à complexidade do volume de dados processados pelos workflows
	científicos em larga escala, observa-se a necessidade de um sistema para gerenciar a sua
	composição (i.e., definição da estrutura do workflow -atividades e dependências de dados),
	execução e análise (e.g., mecanismo para o processamento de consultas ou ferramentas de
	visualização), conforme argumenta Mattoso et al. (2010). Esses sistemas também precisam
	implementar diretivas específicas para lidar com cada ambiente de PAD. Os sistemas com
	essas características são conhecidos como Sistemas de Gerência de Workflows Científicos
	(SGWfC) (DEELMAN et al., 2009). Como exemplos de SGWfC, podemos citar o Pegasus
	(DEELMAN et al., 2015), o Swift/T (ZHAO et al., 2008) e o SCC (SILVA et al., 2014).
	Assumindo-se a abstração de fluxo de dados para workflows científicos, os usuários
	do domínio científico com o auxílio de especialistas em ciência da computação, que
	conhecem um determinado SGWfC, realizam a especificação das transformações de dados
	e as suas dependências de dados usando esse SGWfC. De acordo com a especificação do
	workflow científico, o SGWfC gera um plano de execução respeitando um determinado
	modelo de execução, que também é conhecido como modelo de computação (NAJJAR et

3.3.3. Monitoramento de workflows científicos

  

	(ZAHARIA et al., 2010) é um arcabouço de fluxo de dados que também baseia-se no uso Somando-se a essas abordagens, existem SGWfC que integram o seu mecanismo de
	de arquivos de log para monitorar a execução de aplicações em ambientes de PAD. monitoramento com ferramentas alternativas, a fim de atender a eventuais limitações. Por
	Outra abordagem com apoio ao monitoramento de workflows científicos considera exemplo, o Pegasus é um SGWfC paralelo que não é capaz de capturar o conteúdo de
	a captura de dados de proveniência, que podem apresentar dois níveis de granularidade, arquivos de dados científicos, que podem ser muito relevantes para análises específicas do
	conforme apresentado na Seção 3.2.1. De acordo com o tipo de granularidade adotado, os domínio. Portanto, o uso de soluções para o processamento de consultas em dados
	SGWfC adotam um padrão para a representação dos dados de proveniência. Por exemplo, científicos poderia permitir a captura do conteúdo presente em arquivos e o seu
	a World Wide Web Consortium (W3C) apresentou um conjunto de recomendações armazenamento em uma base de dados. Assim, um processador de consultas poderia ser
	conhecido como PROV (MOREAU e GROTH, 2013) para permitir a interoperabilidade de acoplado ao Pegasus para apoiar as análises de dados científicos, enquanto considera
	dados de proveniência em ambientes heterogêneos, como a própria Web. No contexto de também os dados de proveniência e de desempenho já armazenados na sua base de dados.
	simulações computacionais, a heterogeneidade estaria vinculada à possibilidade de Nesse caso, os próprios especialistas em ciência da computação requerem um conhecimento
	desenvolver workflows científicos em diferentes domínios da ciência, como a técnico para realizar a integração dessas tecnologias com sucesso, dado que esse trabalho
	bioinformática (OCAÑA et al., 2011) e a astronomia (JACOB et al., 2009), enquanto de desenvolvimento não é trivial. Em relação às análises de dados científicos, existem
	apenas um modelo seria capaz de descrever os dados de proveniência em todos os domínios. algumas tecnologias emergentes que poderiam ser empregadas, como o DiNoDB (TIAN et
	Para monitorar a execução de workflows científicos, os SGWfC têm apresentado al., 2014), o RAW, o FastQuery e o SDS/Q. Além disso, os SGWfC também podem ser
	basicamente três propostas para representar informações quanto à estrutura do workflow, à Outro aspecto importante consiste no momento em que ocorre a captura de dados integrados a ferramentas alternativas de outros tipos de dados. Por exemplo, o componente
	sua execução e ao domínio da simulação computacional, sendo as seguintes: arquivos de de proveniência. Nesse sentido, a proveniência pode ser capturada de uma forma offline ou PerfMetricEval (
	log, apoio à proveniência de dados e uso de ferramentas alternativas. Dessas propostas, a online. A captura offline de dados de proveniência consiste em armazenar os dados em um
	maioria dos SGWfC geram arquivos de log durante a execução de workflows científicos. determinado repositório após a execução do workflow científico, como observado nos
	Esses arquivos apresentam, em geral, informações sobre o desempenho ou domínio da SGWfC VisTrails e Kepler. Enquanto isso, a captura online de dados de proveniência
	simulação computacional. Ao mesmo tempo, esses sistemas frequentemente lidam apenas considera a obtenção e o armazenamento dos dados em tempo de execução, conforme
	com operações de escrita nesses arquivos (operações de uma única via), uma vez que não é implementado no Swift/T, Pegasus e SCC (SciCumulus + Chiron).
	trivial desenvolver aplicações para a análise desses arquivos de log, assim como o custo Em função da possível sobrecarga de armazenar os dados de proveniência
	adicional de acessos concorrentes, caso haja o apoio às operações de leitura. concorrentemente com o processamento de programas de simulação, a captura de dados de
	Por outro lado, no cenário científico, os usuários do domínio científico geralmente proveniência online normalmente apresenta um desempenho pior que a proposta offline.
	necessitam avaliar os seus programas de simulação de acordo com questões de desempenho Por fato, essa diferença de desempenho é mais aparente em SGWfC que gerenciam a
	ou mesmo com os resultados obtidos. Logo, esses usuários precisam analisar o conteúdo proveniência em uma granularidade mais fina. Ao mesmo tempo, vale enfatizar o potencial
	dos arquivos de log durante ou após a execução do workflow. Em ambos os casos, os analítico de se capturar a proveniência de forma online, pois os usuários são capazes de
	SGWfC não são capazes de capturar esses tipos de dados, pois os programas de simulação realizar consultas de monitoramento ou mesmo do próprio domínio em tempo de execução.
	comumente escrevem tais dados em arquivos de log da sua maneira, a menos que um padrão Destaca-se também que existem SGWfC com apoio à captura de dados de proveniência em
	de escrita seja imposto pelo SGWfC. VisTrails (CALLAHAN et al., 2006), Kepler e tempo de execução, mas que não são capazes de obter dados do domínio ou de proveniência
	Swift/T são exemplos de SGWfC baseados em arquivos de log. De forma similar, o Spark em uma granularidade fina, como o Swift/T.

Operador Tipos de atividades Operandos adicionais Relação entre os elementos de dados consumidos e produzidos

  

	de nuvens computacionais, considerando, e.g., a elasticidade dos recursos computacionais operador algébrico, um operando adicional 𝛾 também precisa ser definido. Logo, uma
	e o custo financeiro (OLIVEIRA et al., 2012). transformação de dados algébrica pode ser representada pela seguinte expressão:
	Com outra meta, o SCC visa uma maior flexibilidade para o usuário ao modelar, 𝐼 𝑖+1 ⃪ 𝜙(𝑡 𝑖 , 𝛾, 𝐼 𝑖 ) (1)
	submeter, monitorar e analisar workflows científicos em ambientes de PAD (SILVA et al., Um operador algébrico 𝜙 é definido de acordo com a relação entre o número de
	2014). Além disso, o SCC defende a integração de dados da composição do workflow, da elementos de dados consumidos e produzidos para uma determinada invocação da
	sua execução e do próprio domínio em apenas uma base de proveniência, de forma transformação de dados, conforme observado na Tabela 2. Diferentemente do Chiron e do
	semelhante às publicações do Chiron e do SciCumulus (OCAÑA et al., 2015, SciCumulus, o SCC apresenta os operadores que usam expressões algébricas relacionais,
	OGASAWARA et al., 2013). Para o desenvolvimento da solução proposta nesta tese, antes nomeados de SRQuery e MRQuery, implementados como apenas um operador
	utilizou-se a versão mais recente do SCC, que também assume dados de desempenho e de algébrico, conhecido como Query. Tal mudança foi motivada pela redundância semântica
	consumo dos recursos computacionais armazenados na base de dados de proveniência. desses operadores, pois ambos realizavam o processamento de consultas na base de
	Em relação ao seu funcionamento, o SCC é responsável pela gerência de um proveniência. A sua única diferença estava relacionada ao número de conjuntos de dados
	workflow científico e dos dados que são consumidos, transformados e produzidos ao longo de entrada. Nessa circunstância, o operador SRQuery considerava apenas um conjunto de
	de cada atividade constituinte desse workflow. Além disso, as oportunidades de otimização dados de entrada, enquanto o operador MRQuery apresentava múltiplos conjuntos de dados.
	devem ser consideradas tanto na especificação, como na execução paralela de workflows
	científicos. Para lidar com essa questão, Ogasawara et al. (2011) propôs uma abordagem
	algébrica com o intuito de facilitar a definição de workflows científicos, a gerência de dados Map Aplicação Nenhum 1:1
	em paralelo presentes em um fluxo de dados e a otimização de workflows em tempo de SplitMap Aplicação Atributo que referencia arquivo 1:m
	execução. Essa abordagem algébrica caracterizou-se pela extensão da álgebra relacional tradicional, sendo conhecida como Scientific Workflow Algebra (SciWfA), para permitir a Reduce Aplicação Conjunto de atributos de agregação n:1
	otimização e o processamento de consultas em SGBD (ÖZSU e VALDURIEZ, 2011). Filter Aplicação Nenhum 1:(0-1)
	Uma vez que um workflow científico possa ser representado por um fluxo de dados, Query Expressão da álgebra relacional Nenhum n:m
	3 da COPPE / Universidade Federal do Rio de Janeiro e da Universidade então a SciWfA também permite expressar as transformações de dados e como os elementos
	Federal Fluminense (SILVA et al., 2014), o SGWfC SCC consiste na integração dos de dados fluem entre elas. Como principal vantagem, pode-se destacar a adição de
	SGWfC Chiron (OGASAWARA et al., 2013) e SciCumulus (DE OLIVEIRA et al., 2010). semântica às transformações de dados. De acordo com a álgebra proposta por Ogasawara
	Como sistema pioneiro do grupo, o Chiron foi desenvolvido para apoiar a execução de et al. (2011), cada transformação de dados 𝑡 𝑖 ∈ 𝑇 (i.e., atividade de um workflow) é regida
	workflows científicos usando uma máquina paralela dedicada a ambientes de clusters e por uma operador algébrico 𝜙. Portanto, 𝑇 apresenta o conjunto de todas as transformações
	grades computacionais. Já o SciCumulus apresenta as principais características e de dados e 𝜙 ∈ {𝑀𝑎𝑝, 𝑆𝑝𝑙𝑖𝑡𝑀𝑎𝑝, 𝑅𝑒𝑑𝑢𝑐𝑒, 𝐹𝑖𝑙𝑡𝑒𝑟, 𝑄𝑢𝑒𝑟𝑦}. Além disso, 𝑡 𝑖 consome um conjunto
	componentes do Chiron, além de contribuir com algoritmos que tiram proveito de ambientes de dados (ou relação, como é tradicionalmente chamado na álgebra relacional) 𝐼 𝑖 de
	elementos de dados de entrada e produz um conjunto de dados 𝐼 𝑖+1 de elementos de dados
	de saída. De forma similar, um conjunto de dados de saída pode ser o conjunto de dados de
	entrada do operador associado a uma próxima transformação de dados. Dependendo do

Tabela 2. Operações da SciWfA (adaptado de Ogasawara et al., 2011)

  

	captura dos dados de proveniência e para servir como entrada para uma próxima
	transformação de dados. Essa instanciação da execução de uma atividade regida por um
	operador algébrico da SciWfA é chamada de ativação.
	De acordo com Özsu e Valduriez (2011), uma ativação é a menor unidade de
	processamento de dados que não pode ser mais fragmentada, i.e., não pode ser mais
	paralelizada. No Chiron, o núcleo do SCC, uma ativação pode ser simplificada como a
	invocação de uma transformação de dados (i.e., programa de simulação). Ademais,
	Ogasawara et al. (2011) afirmam que ela é um objeto autocontido que apresenta
	informações fundamentais para permitir a execução de uma transformação de dados em
	qualquer recurso computacional. Assim, uma ativação contém qual aplicação é invocada,
	quais dados serão consumidos, quais dados serão produzidos e qual é o esquema dos dados
	produzidos.
	A relação entre os elementos de dados consumidos e produzidos é calculada a partir
	da cardinalidade (i.e., número de elementos de dados) do conjunto de dados de entrada e do
	conjunto de dados de saída. Na execução de um workflow científico, um programa de
	simulação é invocado múltiplas vezes, sendo que cada invocação realiza o consumo de um
	ou mais elementos de dados de entrada e a geração de um ou mais elementos de dados de
	saída. Entretanto, os programas de simulação invocados pelo SCC são normalmente feitos
	por empresas ou grupos de pesquisas que não estão cientes da especificação da SciWfA.
	Consequentemente, cada invocação pode não produzir os elementos de dados de saída
	necessários para o operador algébrico definido, que são importantes para o mecanismo de

  consiste em um processador de consultas a dados científicos que utiliza uma extensão do SGBD PostgreSQL4 , conhecida como PostgresRaw, e respeita as propriedades da categoria post mortem. Assim, por meio desse SGBD, o NoDB permite que, ao invés de realizar a carga

completa dos dados científicos presentes em arquivos, apenas os atributos presentes em consultas submetidas pelo usuário tenham seus valores extraídos dos arquivos.

Consequentemente, o volume de dados carregados no SGBD pode ser menor que as soluções baseadas na extração total dos dados científicos presentes em arquivos.

Semelhante ao NoDB, outras soluções têm empregado técnicas de indexação para reduzir o volume de dados carregados e para favorecer o acesso eficiente (i.e., mais rápido) aos dados científicos, como o FastBit

[START_REF] Wu | FastBit: interactively searching massive data[END_REF] 

e o AQUAdex (

Exemplo de uso do operador algébrico Join. Capítulo 5 -DfAnalyzer: componentes para a análise de dados em simulacões computacionais

  Por exemplo, ao invés de armazenar os valores dos elementos de uma matriz, o operador algébrico pode ser responsável por indexar a posição de início da matriz, o número de elementos e o tamanho de cada elemento de dados. Ao ser necessário utilizar o valor propriamente dito do atributo por uma consulta ou mesmo pela própria máquina de execução paralela, o acesso a esse valor de atributo pode ser obtido por meio dos índices gerados e armazenados na base de dados de proveniência. Como protótipo de índices posicionais desenvolvidos nesta tese, considerou-se as estruturas de índices para os seguintes tipos de dados (Tabela 3): numérico, textual, arquivo, lista, matriz e malha.

	caracterizado pela execução de extratores e/ou indexadores de forma paralela, conforme simulações computacionais em tempo de execução. Para isso, a DfAnalyzer realiza a
	mostrado na Figura 11. Entretanto, a definição de uma atividade pela álgebra de workflows captura de dados de proveniência e de dados científicos presentes em arquivos, assim como
	científicos corresponde a uma transformação de dados, que consome uma relação de entrada o processamento de consultas de forma online -ou seja, durante a execução da simulação
	e produz uma relação de saída (OGASAWARA et al., 2011). Logo, a execução paralela dos Este capítulo apresenta a biblioteca de componentes DfAnalyzer (SILVA et al., -para investigar o fluxo de dados nos níveis físico e lógico (i.e., fluxo de arquivos e de
	extratores produz várias relações de saída, o que contradiz a definição de uma atividade. Ao 2018), a segunda instância da ARMFUL desenvolvida nesta tese, que permite o elementos de dados, respectivamente), conforme discutido no Capítulo 2.
	mesmo tempo, do ponto de vista de uma atividade, os resultados de extração apresentam monitoramento, a depuração e a análise do fluxo de dados durante a execução de simulações Diferentemente do SCC-A (Seção 4.7), a DfAnalyzer consiste em uma instância da
	um significado semântico para o modelo computacional executado pelo operador algébrico computacionais. Para isso, os usuários do domínio científico podem trabalhar em parceria ARMFUL independente de um SGWfC. Logo, ao invés de ter um SGWfC para gerenciar a
	antes dos operadores Raw e RawI. Logo, tais operadores não podem ser separados com o especialista em ciência da computação para modelar as suas simulações como um execução paralela dos programas de simulação, esses programas já apresentam recursos
	Estrutura de dados de análise e visualização de dados científicos com recursos de programação ou de Formato do índice conceitualmente em uma outra atividade. fluxo de dados. Em muitos casos, inclusive, os usuários do domínio já utilizam ferramentas para apoiar o paralelismo de dados ao executar seus modelos computacionais em diversos
	Numérico	[posição_início, tamanho]
	Textual	[posição_início, tamanho]
	Arquivo	[posição_início, tamanho]
	Lista	[posição_início, tamanho, elementos, delimitador]
	5.1. Visão Geral	
	Existem circunstâncias também em que após o processamento de um modelo Como mencionado anteriormente, a biblioteca de componentes DfAnalyzer 11
	computacional, os usuários necessitam extrair dados de diferentes formatos de arquivos e permite o monitoramento, a depuração e a análise dos fluxos de dados gerados pelas
	que, para isso, eles devem utilizar um algoritmo de extração ou de indexação de dados
	científicos para cada formato de arquivo. Assim, o pós-processamento pode ser

Matriz

[posição_início, tamanho, linhas, colunas, delimitador] 

Malha

[posição_início, tamanho, xdepth, ydepth, zdepth, delimitador] 

Tabela 3. Estruturas de dados apoiadas pelo operador RawI.

Destaca-se também que cada estrutura de dados apresenta sua própria construção de índices. No caso de valores numéricos, textuais e arquivos, os índices apresentam a posição de início e o número de posições ocupadas por ele, ou seja, o seu tamanho. Já as estruturas de dados para listas, matrizes e malhas, além de possuírem a especificação da posição inicial e do tamanho de cada elemento, elas apresentam um delimitador e o número de elementos em cada uma de suas dimensões de representação. Ou seja, para uma matriz, duas dimensões são definidas para expressar o número de elementos (e.g., linhas e colunas). Vale ressaltar que assumimos tamanhos fixos para a representação de conteúdos que seguem as estruturas de dados de lista, matriz e malha. Portanto, o segundo elemento (tamanho) no formato do índice não deveria estar presente na representação dessas estruturas de dados. Somando-se a isso, os dados científicos obtidos nos operadores Raw e RawI normalmente estão relacionados. Logo, considerou-se a definição de outro operador algébrico na SciWfA, conhecido como Join, com o objetivo de associar os elementos de dados (i.e., dados científicos) obtidos por mais de um operador dos tipos Raw ou RawI. Logo, esse operador permite que apenas uma relação de saída seja gerada ao término de uma atividade. A Figura 11 mostra um exemplo de atividade com dois operadores de extração/indexação de dados e o uso do operador Join. Para a especificação do operador Join, deve-se informar o algoritmo de junção a ser aplicado (e.g., equi-junção), os atributos de junção (representados como operandos adicionais, e.g., a1) e as relações de entrada (i.e., relações de saída após a execução dos operadores Raw e RawI). Formalmente, o operador Join pode ser definido da seguinte forma:

𝑅𝑒𝑙𝑎çã𝑜 𝑠𝑎í𝑑𝑎 ← 𝐽𝑜𝑖𝑛(𝐴𝑙𝑔𝑜𝑟𝑖𝑡𝑚𝑜 𝑗𝑢𝑛çã𝑜 , { 𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 }, 𝑅𝑒𝑙𝑎çõ𝑒𝑠 𝑒𝑛𝑡𝑟𝑎𝑑𝑎 ) (4) Figura 11. integração com os seus programas de simulação parecidos com a abordagem adotada pela DfAnalyzer. Assim, eles frequentemente apresentam autonomia para utilizar diretamente a DfAnalyzer, sem o auxílio de um especialista em ciência da computação. Diante dessa realidade, introduzimos uma metodologia orientada ao fluxo de dados que visa capturar e analisar os dados de proveniência e os dados científicos presentes em diferentes arquivos ou ainda alocados em memória, que seguem formatos ou estruturas de dados padronizadas de acordo com o domínio da simulação. Assumimos o cenário em que os usuários do domínio científico requerem auxílio dos especialistas em ciência da computação. Mais especificamente, a DfAnalyzer apresenta um conjunto de componentes para apoiar a captura de dados de proveniência, a captura de dados científicos, o processamento de consultas e a visualização das especificações de fluxo de dados. Este capítulo é subdividido em quatro seções, que apresentam uma visão geral dessa biblioteca de componentes (Seção 5.1); a nossa metodologia orientada ao fluxo de dados em simulações computacionais (Seção 5.2); as operações da DfAnalyzer para a captura de dados de proveniência e de dados científicos (Seção 5.3); e os componentes da sua arquitetura (Seção 5.4).

nós computacionais (e.g., em um ambiente de cluster computacional). Como exemplos de tecnologias que são comumente integradas a esses programas de simulação, pode-se citar o

Open MPI 12 , o OpenMP 13 ou mesmo outra biblioteca capaz de executar os métodos computacionais de forma paralela, como a libMesh 14 , sendo específica para métodos de elementos finitos.

Dessa forma, a DfAnalyzer assume que os programas de simulação são caixas cinzas (do termo em inglês, gray boxes), em que um programa caixa cinza apresenta parte do seu código fonte passível de ser instrumentado ou acessado, enquanto que a outra parte envolve um código fonte privado (caixa preta), que pode, por exemplo, realizar invocações a outros programas ou bibliotecas. Mais especificamente, esses programas são comumente baseados em scripts, pois eles apenas apresentam invocações para bibliotecas externas, como MPI, libMesh e ParaView Catalyst (para visualização de dados in situ). Assim, a DfAnalyzer está na categoria de sistemas baseados na invocação de serviços ou bibliotecas, em que as partes do código fonte acessíveis nesses programas de simulação podem ser ajustadas a fim de invocar os serviços disponibilizados pela DfAnalyzer.

Ajuste em um programa de simulação para a extração de dados científicos.

  𝑎 𝑖𝑑 , 𝑎 𝑑𝑎𝑡𝑎𝑠𝑒𝑡 , 𝑎 𝑓𝑖𝑙𝑒 , 𝐴 𝑠𝑐𝑖𝑒𝑛𝑡𝑖𝑓𝑖𝑐 ), em que 𝑎 𝑖𝑑 é o identificador dos dados científicos capturados, 𝑎 𝑑𝑎𝑡𝑎𝑠𝑒𝑡 é o identificador do elemento de dados no conjunto de dados 𝑑𝑎𝑡𝑎𝑠𝑒𝑡, 𝑎 𝑓𝑖𝑙𝑒 é o atributo opcional para o arquivo de dados científicos e 𝐴 𝑠𝑐𝑖𝑒𝑛𝑡𝑖𝑓𝑖𝑐 são os atributos do domínio científico. Uma combinação de dois extratores 𝜓 1 e 𝜓 2 , denotada por 𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑑𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑜𝑟𝑠(Ψ) | Ψ = 𝜓 1 ∪ 𝜓 2 , é uma operação de junção natural entre as relações de dados de cada extrator, denotadas por 𝑟 𝜓 1 = 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝜓 1 ) e 𝑟 𝜓 2 = 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝜓 2 ). De forma simplicada, 𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑑𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑜𝑟𝑠(Ψ) = 𝑟 𝜓 1 ⋈ 𝜉 𝑟 𝜓 2 . Caso Ψ tenha apenas um extrator 𝜓 1 , isto é, Ψ = {𝜓 1 }, então 𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑑𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑜𝑟𝑠(Ψ) = 𝑟 𝜓 1 .

	Apesar desses passos iniciais, o especialista em ciência da computação ainda não dessa circunstância, nós introduzimos o conceito de combinação de extratores na Definição
	possui as informações necessárias para realizar os ajustes nos programas de simulação. 5.2.5, que especifica como os dados científicos capturados por diferentes extratores devem
	Portanto, o especialista em ciência da computação trabalha com o usuário do domínio ser relacionados. Em uma perspectiva de apenas dois extratores, descrevemos que essa
	Logo, o esquema ℛ de uma relação 𝑟 de um extrator de dados científicos 𝜓 é denotado como científico novamente para definir em que trechos do código fonte do programa de simulação combinação de extratores corresponde a uma operação relacional de junção, em que os
	𝑆𝑐ℎ𝑒𝑚𝑎(𝑟) ou 𝑆𝑐ℎ𝑒𝑚𝑎(𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝜓)). as invocações dos programas de extração precisam ser adicionadas. Por exemplo, a Figura predicados de junção seriam os atributos que apresentam o mesmo nome e tipo nos
	Como resultado das modelagens lógicas para os dados de proveniência e os dados 23 mostra a invocação de um programa ad-hoc extractProgram para extrair dados esquemas das relações de dados obtidas pelos extratores. Logo, ao invés de exigir mais um
	de domínio, a DfAnalyzer é capaz de criar uma base de dados relacional que armazena os científicos no script em Python para contagem de palavras usando Spark. Nesse caso, o esforço de especificação pelos usuários, nós inferimos automaticamente os predicados de
	dados de proveniência e de domínio. Vimos também que o modelo de dados lógico sofrerá arquivo output.bin apresenta os dados de domínio presentes no RDD counts. Em termos de junção.
	mudanças apenas em função da especificação dos dados de domínio representados nos Definição 5.2.5. (Combinação de Extratores)
	Já os relacionamentos entre um conjunto de dados e um extrator visam especificar
	como os dados científicos capturados por um extrator correspondem a uma coleção de dados primeiramente a extração de dados científicos, esse comportamento requer a interação entre
	no conjunto. Em termos de mapeamento, um campo com o rótulo do conjunto de dados o usuário do domínio científico e o especialista em ciência da computação para
	acrescido do sufixo "_id" é criado na relação do extrator de dados com restrição de chave identificarem quais arquivos precisam ser investigados, como extrair os atributos de
	estrangeira para o campo id da relação do conjunto de dados. Pelo fato do extrator realizar interesse deles, quais tipos de elementos de dados ele deseja capturar (e.g., filtragem de
	a captura de dados científicos em arquivos, um campo file_id é criado na sua relação. determinados valores de atributo) e qual programa ad-hoc ou ferramenta alternativa, como
	Formalmente, o esquema da relação para um extrator de dados é apresentado na Definição o FastBit, deveria ser utilizado. Como resultado, o especialista em ciência da computação
	5.2.4. saberia como invocar o programa ou a ferramenta para extrair os dados científicos de
	interesse.

Diante dessa modelagem de dados no nível lógico, a DfAnalyzer cria uma base de dados capaz de armazenar os dados de domínio produzidos pela simulação computacional, utilizando ou não um extrator de dados científicos. Formalmente, o esquema da relação para um conjunto de dados é apresentado na Definição 5.2.3. Definição 5.2.3. (Esquema da Relação do Conjunto de Dados) Uma relação de dados 𝑟 de um conjunto de dados 𝑠, também denotada por 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝑠), contém um esquema de dados ℛ = (𝑎 𝑖𝑑 , 𝐴 𝑡𝑟𝑎𝑛𝑠𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛 , 𝐴 𝑠𝑐𝑖𝑒𝑛𝑡𝑖𝑓𝑖𝑐 ) composto de uma tripla com o atributo 𝑎 𝑖𝑑 de identificação do elemento de dados do conjunto, os atributos 𝐴 𝑡𝑟𝑎𝑛𝑠𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛 referentes aos identificadores das instâncias das transformações de dados que envolveram a produção ou o consumo de tuplas em 𝑟, e os atributos 𝐴 𝑠𝑐𝑖𝑒𝑛𝑡𝑖𝑓𝑖𝑐 associados às propriedades do domínio científico que se deseja representar em 𝑟. Logo, o esquema ℛ da relação de dados 𝑟 de um conjunto de dados 𝑠 é denotado como 𝑆𝑐ℎ𝑒𝑚𝑎(𝑟) ou 𝑆𝑐ℎ𝑒𝑚𝑎(𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝑠)). Definição 5.2.4. (Esquema da Relação do Extrator de Dados Científicos) Uma relação 𝑟 de um extrator de dados científicos 𝜓, também denotada por 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝜓), contém um esquema de dados ℛ = (conjuntos de dados ou capturados pelos extratores, uma vez que um novo conjunto de dados (ou extrator) implica uma nova relação e seus relacionamentos no modelo de dados lógico.

Na fase de especificação do fluxo de dados, vimos que os esquemas dos conjuntos de dados apresentam os atributos de domínio, cujos valores são, frequentemente, capturados pelos extratores de dados científicos. Nos casos em que não há o uso de extratores, os dados de domínio são obtidos diretamente de dados estruturados alocados em memória, que podem ser representados como elementos de dados em um determinado conjunto. Todavia, quando os extratores de dados científicos são utilizados, os valores de atributos de interesse são acessados, extraídos, e, eventualmente, indexados de arquivos. Consequentemente, esses dados precisam ser associados a um determinado conjunto.

Em função desses casos, os ajustes nos programas de simulação também consideram esses dois comportamentos, um para a extração de dados científicos e outro para representar os elementos de dados obtidos diretamente dos programas de simulação. Considerando processamento computacional, o programa extractProgram realiza a extração das palavras identificadas e dos seus números de ocorrências. Apesar desse exemplo de extração de dados científicos, vale ressaltar que, em uma implementação usando Spark, a abordagem mais recomendada seria tirar proveito dos elementos de dados alocados em memória pelos RDDs. Figura 23.

Em outros cenários, os usuários precisam capturar dados científicos de dois ou mais arquivos usando diferentes extratores. Como esses dados extraídos poderiam representar elementos de dados em um conjunto de dados específico, os usuários precisariam definir como os dados científicos obtidos por diferentes extratores devem se relacionar. Diante Uma vez que os dados científicos tenham sido capturados por extratores ou obtidos diretamente de estruturas alocadas em memória, esses dados precisam ser representados de acordo com o conceito de coleção de dados da nossa abstração de fluxo de dados (Seção 3.1). Ou seja, esses dados científicos precisam ser vistos como um conjunto de elementos de dados, em que cada elemento corresponde a uma sequência de valores de atributos, sendo que os atributos predefinidos fazem parte da especificação do conjunto de dados. De uma forma mais prática, o especialista em ciência da computação, com o auxílio do usuário do domínio científico, precisa ajustar o programa de simulação para ser capaz de capturar esses dados de domínio e armazená-los na nossa base de dados.

Ademais, a DfAnalyzer apresenta uma operação, conhecida como collection, para permitir a captura e a carga dos dados de domínio como elementos em um conjunto de dados (mais detalhes na

Subseção 5.3.3)

. Por exemplo, a Figura 24 mostra a especificação da operação collection no script de contagem de palavras, assumindo que o valor do atributo word é obtido diretamente de dados alocados em memória, enquanto o valor do atributo count é obtido por um extrator ext. No caso, esse extrator obtém os valores do atributo count de um arquivo binário, cujo conteúdo corresponde aos dados do RDD counts, e os armazena no arquivo ext.data. Nessa invocação da operação collection, o primeiro argumento corresponderia ao nome da transformação de dados (i.e., count_words), o segundo à iteração dessa transformação de dados (ou à tarefa), o terceiro ao rótulo do conjunto de dados (i.e., counts) e o último à uma matriz com os elementos de dados de uma coleção desse conjunto. Vale ressaltar que, ao especificar um extrator de dados, o elemento do conjunto de dados que utilizou esse extrator apresenta um valor de atributo adicional para o arquivo com os dados científicos extraídos (e.g., ext.data).

Figura 24.

Exemplo de representação de dados de domínio em um conjunto de dados.

  𝐴, com as relações de dados dos seus extratores 𝑠. Ψ. De uma forma simplificada, 𝑉𝑖𝑒𝑤(𝑠) = 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛(𝑠) ⋈ 𝑑𝑠_𝑖𝑑 𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑑𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑜𝑟𝑠(𝑠. Ψ), onde 𝐶𝑜𝑚𝑏𝑖𝑛𝑒𝑑𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑜𝑟𝑠(𝑠. Ψ) é uma relação com os elementos de dados capturados pelos extratores 𝑠. Ψ e 𝑑𝑠_𝑖𝑑 é o identificador dos elementos no conjunto de dados, correspondendo ao predicado de junção.

	nas relações do conjunto de dados e dos seus extratores (como no exemplo da Figura 24), o
	usuário do domínio científico pode, de uma forma mais simples, utilizar apenas a visão do
	conjunto de dados. Conjuntamente, essas visões respeitam os esquemas das relações do
	conjunto de dados e dos extratores apresentados nas Definições 5.2.3 e 5.2.4. Mais detalhes
	sobre a nossa metodologia para a modelagem de consultas são apresentados na Subseção
	5.2.3.

Por conseguinte, nós definimos, formalmente, a visão do conjunto de dados (Definição 5.2.6), quando extratores de dados científicos podem ser empregados e dados científicos também podem ser capturados sem o uso de extratores. Assim, ao invés de realizar diversas operações de projeção e junção para relacionar dados científicos presentes Definição 5.2.6. (Visão do Conjunto de Dados) Uma visão de um conjunto de dados 𝑠, denotada por 𝑉𝑖𝑒𝑤(𝑠), é definida pela junção da relação do conjunto de dados 𝑠, considerando os seus atributos 𝑠.

  Semelhante à visão datasetSchemas, a definição da visão programs realiza uma consulta com a cláusula SELECT para obter todos os programas de simulação executados pelas transformações de dados. Mais especificamente, essa visão apresenta os rótulos das transformações de dados (campo transformation), acrescidos dos nomes e dos diretórios dos programas de simulação (campos name e path).

	Com a informação de quais transformações de dados foram executadas, quais
	conjuntos de dados foram manipulados e como as transformações de dados são encadeadas
	em uma simulação computacional, a especificação do fluxo de dados pode ser representada
	por um grafo direcionado acíclico. No contexto desta tese, os usuários estão comumente

interessados nos conjuntos de dados científicos. Logo, a representação de dados adotada segue a Definição 5.2.7, em que os vértices são os conjuntos de dados e os arcos são as dependências de dados entre os conjuntos em função de uma transformação de dados, que consome dados de um conjunto e produz dados em outro conjunto. Definição 5.2.7. (Fluxo de Dados na Perspectiva de Grafo) Um fluxo de dados 𝐷 𝐹 é representado por um grafo direcionado acíclico 𝐺 = (𝑆, Φ ′ ), em que 𝑆 são os conjuntos de dados representados como vértices e Φ′ são as dependências de dados representadas como arcos. Cada arco 𝜑′ ∈ Φ′ é um par ordenado de dois conjuntos de dados (𝑠 1 , 𝑠 2 ), correspondendo ao fato de que uma transformação de dados 𝑡 é responsável pelo consumo do conjunto de dados cabeça 𝑠 1 e pela produção do conjunto de dados cauda 𝑠 2 , de modo que 𝑠 1 𝑑𝑒𝑝 ← 𝑠 2 em função de 𝑡.

  Como primeiro passo, a operação dataflow registra o fluxo de dados, recebendo um rótulo ou nome único para o fluxo de dados representativo da simulação computacional. No exemplo do script para contagem de palavras (Figura 14), o rótulo do fluxo de dados é

	word_count. Depois disso, as outras operações podem ser realizadas, evidenciando uma
	hierarquia para a estrutura desse fluxo de dados. Embora não tenhamos uma operação para
	SELECT DISTINCT file, counts.word, count
	FROM input_files, lines, occurrences, counts os atributos presentes nos conjuntos de dados, a especificação dos atributos está presente
	WHERE input_files.get_lines_id = lines.get_lines_id na operação dataset por meio dos parâmetros attributes (nome dos atributos) e
	AND lines.identify_occurrences_id=occurrences.identify_occurrences_id attributesTypes (tipos de dados armazenados nos atributos, de acordo com a ordem de
	AND occurrences.count_words_id = counts.count_words_id
	AND occurrences.word = counts.word; attributes).
	{𝑠 1	𝑑𝑒𝑝 ← 𝑠 2 , 𝑠 2	𝑑𝑒𝑝 ← 𝑠 3 } ⊨ 𝑠 1	𝑑𝑒𝑝 ← 𝑠 3 .

Tabela 4. Operações para a especificação do fluxo de dados. Operação dataflow(tag) program(name, path) dataset(dataflow, tag, attributes, attributesTypes) extractor(dataset, tag, method, cartridge, attributes, attributesTypes) transformation(dataflow, tag, inputDatasets, outputDatasets, programs) Da mesma forma, as dependências de dados entre transformações não são especificadas como operações. Entretanto, discutimos na Seção 3.1 que duas transformações podem apresentar dependências de dados entre si em função de um conjunto de dados, quando elementos de dados desse conjunto são produzidos por uma transformação e consumidos por outra transformação. Assim, por meio da composição de transformações de dados (uso da operação transformation), as dependências de dados podem ser inferidas de acordo com os conjuntos de dados manipulados pelas transformações. Segundo o exemplo da Figura 31, podemos afirmar que 𝑡 1 𝑑𝑒𝑝 ← 𝑡 2 , consequentemente, existe uma dependência de dados entre 𝑡 1 e 𝑡 2 em relação ao conjunto de dados 𝑠 2 . Além disso, como a dependência de dados contempla propriedades de transitividade, se {𝑡 1 𝑑𝑒𝑝 ← 𝑡 2 }, então

  caso das operações dataflow e program, elas realizam apenas inserções de tuplas nas relações com os seus respectivos nomes. Por outro lado, as operações dataset, extractor para registrar esse novo extrator. Como os dados capturados por um extrator devem ser representados em um conjunto de dados, a integridade referencial em função da restrição de chave estrangeira no campo ds_id precisa ser respeitada. Do mesmo

	modo, a operação extractor registra os atributos capturados pelo extrator ao utilizar os
	parâmetros attributes e attributesTypes, inserindo tuplas na relação attribute. Somando-se
	a isso, para armazenar os dados científicos capturados em tempo de execução, a operação
	extractor cria uma relação com o rótulo do extrator, sendo a especificação do seu esquema
	apresentada formalmente na Definição 5.2.4.
	Entretanto, a maior complexidade da operação extractor está no fato dela ser

e transformation apresentam comportamentos mais complexos. A operação dataset registra um conjunto de dados (inserção de tuplas na relação dataset) para depois adicionar os atributos presentes nesse conjunto de dados (inserção de tuplas na relação attribute), a fim de garantir a integridade referencial no campo ds_id da relação attribute (Figura 17). Mais especificamente, por meio dos parâmetros attributes e attributesTypes, operações de inserção de tuplas são realizadas na relação attribute para registrar os nomes dos atributos e os seus tipos em um determinado conjunto de dados. Somando-se a isso, a operação dataset cria uma relação para o conjunto de dados. Supondo uma operação dataset('occurrences

',{word, occurrence},{text,numeric})

, essa operação terá que adicionar uma tupla na relação dataset com o rótulo (campo tag) 'occurrences' e duas tuplas na relação attribute com os seguintes pares de valores para os campos name e type: (word, text) e (occurrence, numeric). Ademais, essa operação criará uma relação de dados, nomeada como ds_occurrences, para armazenar os elementos de dados capturados nesse conjunto de dados durante a execução da simulação (i.e., dados de domínio). Esse exemplo foi baseado no script em Python usando Spark da Figura 14 e o seu modelo de dados para os dados de domínio é mostrado na Figura 22. Ressalta-se também que, nesse cenário, os valores desses campos (i.e., valores de atributos na abstração de fluxo de dados) não são característicos do uso de extratores de dados científicos.

Para a captura de dados científicos, a DfAnalyzer provê outra operação, denominada extractor, que especifica quais programas ad-hoc ou ferramentas alternativas serão executados para acessar, extrair e, eventualmente, indexar dados científicos presentes em determinados arquivos. Com esse objetivo, ao ser invocada, essa operação insere uma tupla na relação extractor chamada por uma segunda vez (ou posteriormente) para um mesmo conjunto de dados, pois os elementos de dados produzidos pelos dois extratores precisam ser relacionados entre si para representar o conjunto de dados de interesse. Baseado no conceito de junção de dados da abordagem relacional (ELMASRI e NAVATHE, 2010), a nossa metodologia assume que os campos com o mesmo nome e tipo obtidos pelos extratores podem ser associados automaticamente pelo operador relacional de junção (Definição 5.

  ∁, indexando valores da sequência de atributos 𝐴 𝑖𝑛𝑑𝑒𝑥𝑒𝑑 | 𝐴 𝑖𝑛𝑑𝑒𝑥𝑒𝑑 ⊆ 𝐴 ′ . Como resultado, a operação extract produz uma relação de saída 𝑟, em que o seu esquema apresenta um atributo que contém o caminho para os arquivos, representado por 𝑎 𝜑 , os atributos extraídos desses arquivos (𝐴 𝑒𝑥𝑡𝑟𝑎𝑐𝑡𝑒𝑑 | 𝐴 𝑒𝑥𝑡𝑟𝑎𝑐𝑡𝑒𝑑 = 𝐴′ -𝐴 𝑖𝑛𝑑𝑒𝑥𝑒𝑑 ), e os atributos indexados (𝐴 𝑖𝑛𝑑𝑒𝑥𝑒𝑑 ), isto é, a relação 𝑟 apresenta o esquema ℛ = {𝑎 𝜑 , 𝐴′}, ou 𝑆𝑐ℎ𝑒𝑚𝑎(𝑟) = {𝑎 𝜑 , 𝛢′}. De uma forma geral, 𝑟 ← 𝑓(𝜎 ∁ (𝜋 𝑎 𝜑 ,𝐴 ′ (𝐴𝑐𝑐𝑒𝑠𝑠(𝜑, 𝜍))), 𝐴 𝑖𝑛𝑑𝑒𝑥𝑒𝑑 ) a partir da execução de 𝜌. No caso da captura de dados ainda alocados em memória, o esquema da relação de saída não possui o atributo 𝜑 em função da sua volatilidade.

Formalmente, a operação extract é especificada conforme a expressão abaixo. Vale ressaltar que, pelo fato da invocação do programa 𝜌 já conhecer qual catálogo de dados (𝜍) será necessário na extração de dados científicos, quais condições de seleção serão aplicadas (∁) e quais atributos precisam ser extraídos ou indexados, esses argumentos não estão presentes na especificação da operação extract. Da mesma maneira, por conhecer o esquema da relação de saída, a DfAnalyzer já conhece os atributos a serem capturados (𝐴).

𝑟 ← 𝑒𝑥𝑡𝑟𝑎𝑐𝑡(𝜌, 𝜑)

Tabela 5. Operações para a captura de dados de proveniência retrospectiva.

  Na Figura 35, mostramos um exemplo de tarefas executadas para as duas primeiras transformações de dados do script em Python usando Spark da Figura 14. Nesse exemplo, apenas uma iteração da simulação computacional foi apresentada, consumindo o arquivo file_1.txt como elemento de dados de entrada. Para essa iteração, duas tarefas foram executadas (uma para cada transformação de dados) e, consequentemente, duas invocações da operação task foram realizadas. Considerando-se os dados de entrada do conjunto de dados input_files e o comportamento de cada transformação, podemos afirmar que essas duas transformações de dados teriam, em uma representação completa da execução dessa simulação, duas iterações com quatro tarefas executadas (duas tarefas para cada iteração).

	científicos são relevantes nas suas análises. Ou seja, eles são capazes de especificar quais
	atributos devem ser monitorados em cada conjunto de dados.
	Nessa fase, a instância de uma transformação de dados (Seção 3.1) ou tarefa
	apresenta a menor unidade de dados necessária, isto é, menor subconjunto de elementos de
	dados de entrada (ou coleção de dados), para executar uma transformação de dados. Esses
	elementos de dados correspondem aos dados científicos manipulados pelos diferentes
	modelos computacionais que os usuários do domínio científico desejam comumente
	analisar. Assim, a nossa principal operação é definida como task com o objetivo de
	armazenar os metadados associados à execução de uma instância de uma transformação de
	DfAnalyzer não captura os dados de proveniência necessariamente na granularidade mais
	fina e oferece uma solução agnóstica a uma linguagem de programação. Apesar de Ademais, a operação task permite que o estado da execução da tarefa (argumento
	informações valiosas, observa-se que a captura em uma granularidade muita fina status) seja especificado como executando (RUNNING), finalizado (FINISHED) ou Figura 35.
	compromete as análises de dados científicos, tornando complexa, inclusive, a especificação finalizado com erro (FINISHED_WITH_ERRORS). Como argumentos opcionais, os
	das consultas de interesse (especialmente quando uma grande quantidade de atributos ou usuários também podem informar o diretório de execução da tarefa (argumento workspace)
	dados científicos não são relevantes nas análises). Logo, a nossa abordagem visa oferecer e o recurso computacional responsável pela tarefa (argumento resource). Em uma
	autonomia aos usuários, ao permitir que eles sejam capazes de definir quais dados

Operação task(dataflow, transformation, iteration, status [, workspace, resource])

file

(dataflow, transformation, iteration, name, path) 

collection

(dataflow, transformation, iteration, dataset, elements) 

dependency

(dataflow, transformation, iteration, dependentTransformations, dependentTasks) 

Para essas operações, adotamos uma granularidade fina na gerência da proveniência retrospectiva, a fim de permitir, futuramente, a análise dos rastros de proveniência no nível do fluxo de arquivos e dos elementos de dados

(Subseção 3.2.4)

. Ao mesmo tempo, a granularidade dos dados de proveniência está associada aos ajustes realizados nos programas de simulação, fazendo com que a nossa metodologia permita diferentes níveis de granularidade. Diferentemente de outras soluções, e.g., noWorkflow e RDataTracker, a dados. Enquanto isso, as outras operações são dependentes de uma tarefa, evidenciando que uma operação diferente de task (e.g., file) só pode ser executada após a operação task da sua tarefa dependente ter finalizado (especificada por alguns argumentos). Em mais detalhes, a operação task está associada a um fluxo de dados (argumento dataflow, que corresponde ao rótulo do fluxo de dados), uma transformação de dados (argumento transformation, que corresponde ao rótulo da transformação de dados) e uma iteração (argumento iter).

No cenário de análise exploratória de dados científicos, a iteração corresponde a uma combinação dos parâmetros de entrada (ou dos elementos de dados) para validar uma hipótese científica. Em cenários reais, uma simulação computacional pode apresentar diversas iterações, e.g., varredura de parâmetros

[START_REF] Raicu | Many-task computing for grids and supercomputers[END_REF]

, de forma que inúmeras invocações da operação task são realizadas com diferentes valores para o argumento iter (para uma mesma transformação de dados). Como resultado da operação task, o usuário pode monitorar o comportamento de cada iteração em uma transformação de dados ao consultar as tuplas armazenadas na relação task na nossa base de dados. perspectiva geral, portanto, a operação task corresponde ao processamento de uma consulta de inserção de tuplas na relação task da nossa base de dados.

Exemplo de tarefas a partir da execução do script em Python da Figura 14.

  atributo task_id na relação file, a nossa abordagem consulta a relação task para identificar a tarefa informada como argumento, que apresenta os rótulos do fluxo de dados e da transformação de dados, assim como a iteração correspondente à tarefa. Caso exista essa tarefa e esse arquivo ainda não exista na relação file, então a operação file realiza uma consulta de inserção de tuplas na relação file para armazenar o arquivo manipulado pela tarefa. Considerando novamente o exemplo da Figura 35, observamos apenas uma invocação da operação file, para o arquivo file_1.txt. Em uma representação completa da execução dessa simulação computacional para as duas transformações de dados, a operação file seria invocada duas vezes, para os arquivos file_1.txt e file_2.txt. Considerando-se essa definição de coleção de dados, elementos de dados e os seus valores, assumimos que os elementos de dados do argumento elements são especificados como uma matriz, em que cada linha dessa matriz corresponde a um elemento de dados e cada célula dessa matriz corresponde ao valor de um atributo para um determinado elemento de dados. consultas na nossa base de dados com o intuito de inserir tuplas (ou elementos de dados) na relação do conjunto de dados (argumento dataset). A Figura 35 mostra invocações da operação collection para registrar as coleções de dados manipuladas por duas tarefas em um script em Python para a contagem de palavras em um arquivo, como acrescido de um valor de atributo para cada extrator de dados científicos 𝜓 𝑖 ∈ Ψ, em que esse valor corresponde ao diretório para o arquivo com os dados extraídos por 𝜓 𝑖 . Dessa maneira, a operação collection é capaz de armazenar os dados de domínio acessados diretamente nos programas de simulação ou capturados por extratores de dados científicos. Nesse caso, o valor do atributo word foi obtido diretamente do programa de simulação, enquanto o valor do atributo count foi capturado de um arquivo usando o extrator de dados ext. Após a execução do extrator, o dado extraído foi armazenado no arquivo ext.data. Portanto, ao especificar a operação collection, apenas um elemento de dados foi definido no argumento elements com os valores big (dado obtido sem extrator) e ext.data 𝑡 1 3 da transformação de dados 𝑑𝑡 3 depende de dados produzidos pelas tarefas 𝑡 1 1 e 𝑡 1 2 das transformações 𝑑𝑡 1 e 𝑑𝑡 2 , respectivamente (de modo que 𝑡 1

	Outro aspecto importante consiste no monitoramento dos arquivos consumidos e produzidos pelas tarefas. Para esse recurso, a nossa abordagem apresenta a operação file, que registra os arquivos manipulados por uma tarefa (argumento task) com o seu nome file_1.txt file_2.txt input_files.txt science data file_1.txt big data data science file_2.txt file file_1.txt file_2.txt input_files line science data big data data science lines word occurrence science 1 data 1 big 1 data 1 data 1 science 1 occurrences Obter linhas << Transformação de dados >> Identificar ocorrências de palavras << Transformação de dados >> * iter = 1 file file_1.txt line science data * iter = 1 word occurrence science 1 data 1 Armazenamento em disco diretório hdfs:// Fluxo de dados Tarefas para apenas uma iteração task(word_count, get_lines, 1, FINISHED) file(word_count, get_lines, 1, file_1.txt, hdfs://) collection(word_count, get_lines, 1, input_files, { (file_1.txt) }) task(word_count, identify_occurrences, 1, FINISHED) dependency(word_count, identify_occurrences, 1, {get_lines}, { (1) }) collection( , occurrences, { (science; 1); (data; 1) }) collection(word_count, get_lines, 1, lines, { (science); (data) }) Ao mesmo tempo, essa representação matricial possui semelhanças com a abordagem relacional, pois cada linha da matriz pode ser associada a uma tupla de uma relação de dados, enquanto que cada coluna da matriz corresponde a um atributo ou coluna 𝑐𝑜𝑙𝑙𝑒𝑐𝑡𝑖𝑜𝑛(𝑤𝑜𝑟𝑑_𝑐𝑜𝑢𝑛𝑡, 𝑔𝑒𝑡_𝑙𝑖𝑛𝑒𝑠, 1, 𝑖𝑛𝑝𝑢𝑡_𝑓𝑖𝑙𝑒𝑠, {(𝑓𝑖𝑙𝑒_1. 𝑡𝑥𝑡)}) que registra o elemento de dados do conjunto input_files (com o valor file_1.txt para o atributo FILE) a partir da primeira iteração da transformação de dados get_lines do fluxo de dados word_count. Nesse exemplo, as invocações dessa operação só consideram dados científicos obtidos diretamente de estruturas de dados alocadas em memória pelo script, sem o uso de extratores. Na Figura 24 mostramos um exemplo de operação para registrar uma coleção de (diretório para o arquivo com o dado extraído). Na fase de especificação do fluxo de dados no nosso modelo de dados lógico, discutimos também como as dependências de dados entre transformações foram inferidas e, consequentemente, representadas na nossa base de dados (relação data_dependency). De uma forma simplicada, as dependências de dados indicam quais transformações de dados precisam ser executadas, para que outras transformações possam iniciar. permite a gerência dos rastros de proveniência no nível físico, como discutido na Subseção 3.2.4. Como exemplo, a Figura 36 mostra cinco casos de dependências de dados entre tarefas de até três transformações de dados, 𝑑𝑡 1 , 𝑑𝑡 2 e 𝑑𝑡 3 . A nomenclatura adotada para uma tarefa 𝑡 𝑗 𝑖 contempla o identificador i da transformação 𝑑𝑡 𝑖 , como sobrescrito, e a iteração 𝑗, como subscrito. No caso da Figura 36(a), existe apenas uma dependência de dados entre as tarefas 𝑡 1 1 e 𝑡 1 2 (de modo que 𝑡 1 1 𝑑𝑒𝑝 ← 𝑡 1 2 ) e, consequentemente, uma invocação da operação dependency: dependency(𝑡 1 𝑑𝑒𝑝 ← 𝑡 1 3 2 , {𝑑𝑡 1 e 𝑡 1 2 𝑑𝑒𝑝 ← 𝑡 1

(argumento name) e o diretório em que esse arquivo está armazenado (argumento path).

Para garantir a integridade referencial em função da restrição de chave estrangeira do Todavia, em cenários reais, os usuários do domínio científico estão mais interessados nos dados de domínio para validarem ou refutarem as suas hipóteses científicas. Considerando os extratores de dados e os conjuntos de dados manipulados por cada transformação, a DfAnalyzer introduz uma operação, definida como collection, para registrar a coleção de dados (ou os elementos de dados) manipulados por uma tarefa. Como argumentos, essa operação exige a identificação da tarefa (argumentos dataflow, transformation e iteration) e do conjunto de dados (dataset), além dos elementos de dados que fazem parte dessa coleção de dados (elements).

Conforme definido na Seção 3.1, uma coleção de dados 𝑐 = {𝑒 | 𝑒 ∈ 𝐸} é composta de um conjunto de elementos de dados 𝐸. Cada elemento de dados 𝑒 = (𝑣 | 𝑣 ∈ 𝑉) é composto de uma sequência de valores 𝑉, sendo que a ordem dos seus valores está de acordo com a ordem de especificação dos atributos 𝐴 no conjunto de dados 𝑠 ao qual esse elemento de dados pertence, i.e., 𝑒 ⊆ 𝑠. 𝐶 e 𝑐𝑎𝑟𝑑(𝑒. 𝑉) = 𝑐𝑎𝑟𝑑(𝑠. 𝐴). da relação. Consequentemente, essa estrutura matricial favorece a carga dos dados de domínio em uma base de dados relacional. Tirando proveito dessa característica, a operação collection realiza Entretanto, em muitos cenários, os usuários do domínio científico utilizam extratores para acessar, extrair e, eventualmente, indexar dados científicos presentes em arquivos, conforme discutido na Subseção 5.2.2. Nesse contexto, os dados capturados devem ser armazenados em suas relações de acordo com o nosso modelo de dados lógico.

No script em Python da Figura 14, apresentamos um extrator ext para o conjunto de dados counts, em que a carga dos dados científicos capturados é realizada pelo operador collection. Para isso, nos casos em que alguns atributos são obtidos usando extratores de dados científicos, o argumento elements da operação collection apresenta os elementos de dados com seus valores de atributos sem e com o uso de extratores.

Quando os valores dos atributos são obtidos pelo uso de um extrator, assume-se que os dados capturados pela operação extract são armazenados em arquivos e o caminho para esse arquivo é especificado para o valor dos atributos extraídos. Logo, um elemento de dados do conjunto de dados 𝑠 na operação collection, utilizando os extratores de dados científicos Ψ, deve apresentar valores para os atributos obtidos sem extratores (𝑠. 𝐴), dados do conjunto counts produzida por uma tarefa task da transformação de dados count_words.

Consequentemente, na perspectiva de execução da simulação computacional, uma instância de uma transformação de dados (ou tarefa) não tem conhecimento, a priori, de quais são as instâncias das suas transformações dependentes, ou seja, quais instâncias de uma ou mais transformações de dados precisam ser executadas antes.

Diante dessa questão, a nossa abordagem introduz a operação dependency para registrar as dependências de dados entre as instâncias de transformações de dados. Para a sua devida especificação, a operação dependency apresenta uma invocação baseada em cinco argumentos, em que os três primeiros contemplam a tarefa atual (argumento dataflow, transformation e iteration), ou seja, a tarefa cujos metadados estão sendo armazenados; o quarto corresponde a uma lista com os rótulos das transformações de dados dependentes da tarefa atual (argumento transformations); e o último é uma matriz com os identificadores das iterações das tarefas dependentes (de acordo com a ordem dos elementos na lista transformations). Em uma perspectiva formal, essa especificação de dependência de dados 1 }, {(1)}). Por outro lado, a Figura 36(b) mostra um caso em que a tarefa 3 ). Nessa circunstância, apenas uma invocação da operação dependency é necessária: dependency(𝑡

1 3 

, {𝑑𝑡 1 ; 𝑑𝑡 2 }, {(1,1)}).

Tabela 6. Métodos do QI para a especificação da consulta.

  

		Métodos do QI para a	
	Conceito	mensagem de uma	Informação adicional
		requisição HTTP	
	Mapeamento de atributos	mapping(tipo)	tipo = PHYSICAL, LOGICAL ou HYBRID
	Conjuntos de dados de origem	source(datasetTags)	Conjuntos de dados de origem do fragmento do fluxo de dados a ser analisado
	Conjuntos de dados de destino	target(datasetTags)	Conjuntos de dados de destino do fragmento do fluxo de dados a ser analisado
			atributos consiste na sequência de atributos cujos
	Projeção de dados	projection(atributos)	valores são obtidos após o processamento da
			consulta
	Seleção de dados	selection(condições)	condições representa as seleções ou filtros realizados no processamento da consulta
	Inclusão de conjuntos de dados	include(datasetTags)	datasetTags contempla os rótulos dos conjuntos de dados que devem ser obrigatoriamente considerados no fragmento do fluxo de dados a ser analisado
	Exclusão de conjuntos de dados	exclude(datasetTags)	

  . No que diz respeito à geração desses mosaicos, os programas implementados no Montage permitem analisar diferentes sistemas de coordenadas, tamanhos de imagens arbitrários, rotações e todos os mapeamentos de projeções do sistema de coordenadas mundial, conhecido como World

	Coordinate System. Nessa simulação foram consideradas diferentes regiões do espaço no
	processamento computacional usando os programas do Montage a fim de gerar mosaicos
	personalizados.
	Quanto à sua composição, o workflow científico Montage possui nove atividades,
	conforme mostrado na Figura 43. Considerando o seu processamento computacional, a

primeira transformação de dados (List FITS) extrai diferentes arquivos no formato FITS de um arquivo compactado obtido de um repositório externo da astronomia, Two Micron All Sky Survey 15 (2MASS) desenvolvido pela NASA/IPAC. Cada arquivo no formato FITS descompactado apresenta mais de vinte tipos de dados específicos do domínio ou atributos.

  Processamento de Alto Desempenho (PAD). Em mais detalhes, nossos experimentos consideraram dois clusters computacionais, Uranus e LoboC, do Núcleo Avançado de Computação de Alto Desempenho 18 (NACAD) localizado na COPPE / Universidade Federal do Rio de Janeiro (UFRJ); um cluster computacional, Stampede 19 , do Centro de Computação Avançada do Texas (do termo, em inglês, Texas Advanced Computing Center Montage utilizando o SCC-A. Mais especificamente, a Subseção 6.3.1 apresenta resultados experimentais obtidos ao executar o workflow científico Montage com e sem extração de dados científicos. Nesses experimentos, destaca-se como os dadoscientíficos extraídos e carregados em uma base de dados favorecem análises focadas no conteúdo dos arquivos de dados científicos ou no próprio fluxo de elementos de dados, além da sobrecarga em termos de tempo de processamento ao extrair dados científicos durante a execução paralela desse workflow. Grid 5000 apresenta um sistema de arquivos compartilhado para todos os clusters. A especificação do cluster utilizado em nossos experimentos está descrita na Tabela 7. Como o Grid 5000 funciona por meio da virtualização dos recursos computacionais, utilizou-se um arquivo TAR compactado com binários para uma distribuição Linux genérica de 64 bits.No que diz respeito ao repositório de dados de proveniência, tanto na Uranus, quanto no Grid 5000, instalou-se uma versão binária do PostgreSQL Server 9.4 e utilizou-se alguns scripts desenvolvidos pelo nosso grupo de pesquisa para gerenciar as instâncias do SGBD.

	associado ao SGI Performance Suite. Nos experimentos desta tese utilizou-se apenas a fila de 64 CPUs Quad Core Intel Xeon X5355 (Clovertown), que contém 256 cores por uma questão de disponibilidade. Para utilizar o SCC-A, a base de dados de proveniência usando o SGBD PostgreSQL foi instanciada em um nó computacional dedicado para armazenar os dados de proveniência e os dados científicos. Esse nó computacional com a base de dados possuía 8 núcleos de processamento ou processadores. O SCC-A conecta o nó mestre (ou nó central) com o nó da base de dados para obter as tarefas (ou ativações) prontas para serem executadas e para Para utilizar o SCC-A, a base de dados de proveniência usando o SGBD PostgreSQL foi instanciada em um dos nós computacionais disponíveis para armazenar os dados de proveniência e os dados científicos nesse SGBD, exclusivamente. Esse nó computacional com a base de dados usou 16 núcleos de processamento ou processadores. O SCC-A requer uma conexão estável do nó mestre (ou nó central) com o nó da base de dados para obter as tarefas (ou ativações) prontas para serem executadas e para gerenciar os dados de proveniência. o Tabela 7. Recursos computacionais utilizados do Grid 5000. 6.2.4. Cluster LoboC
	gerenciar os dados de proveniência. No código fonte do SCC-A, a conexão entre o SGWfC Cluster / Região Processador #Nós #Processadores por nó Total de processadores Memória por nó Rede O cluster computacional Lobo Carneiro 21 , também conhecido como LoboC, foi
	e o SGBD é realizada por um driver JDBC para o PostgreSQL. Ademais, a extração de dados científicos corresponde a um recurso opcional na Suno / Sophia Intel Xeon X5520 2.26GHz/8MB 45 8 360 Gigabit utilizado nos experimentos envolvendo a simulação computacional baseada no 32 GB Ethernet solucionador libMesh-sedimentation, na segunda instanciação da ARMFUL, que consistiu
	e da sigla TACC) localizado na Universidade do Texas; e uma grade computacional, conhecida como Grid5000, cujos recursos computacionais estão espalhados em diversas cidades da França. Mais detalhes sobre o uso dos recursos computacionais desses ambientes são apresentados nas subseções a seguir. 6.2.3. Cluster Stampede O cluster computacional Stampede foi utilizado nos experimentos com o workflow EdgeCFD na primeira instanciação da ARMFUL, o SCC-A (Seção 4.7). O Stampede consiste de um cluster Linux da Dell baseado em mais de 6.400 nós servidores Dell PowerEdge, cada um com 2 processadores Intel Xeon E5 (Sandy Bridge) e um Avançado do Texas (do termo, em inglês, Texas Advanced Computing Center e da sigla TACC) e localizado na Universidade do Texas. Cada nó computacional contém 32GB de no desenvolvimento da biblioteca de componentes DfAnalyzer (Capítulo 5). O LoboC consiste de uma cluster SGI ICE-X Linux com 504 CPUs Intel Xeon E5-2670v3 (Haswell), totalizando 6.048 processadores, pertencente ao Núcleo Avançado de Computação de Alto Desempenho (NACAD) localizado na COPPE / UFRJ. Cada nó computacional contém 24 processadores (adicional de mais 24 processadores com Hyper-Threading) com 64GB de modelagem do workflow Já o workflow SyntheticOil&Gas permite tanto a extração como a indexação de coprocessadores Intel Xeon Phi (arquitetura MIC), pertencente ao Centro de Computação memória RAM. Os nós computacionais são interconectados com a tecnologia InfiniBand
	6.2.1. Cluster Uranus dados científicos presentes em arquivos gerados em tempo de execução. Tais arquivos memória RAM com um adicional de 8GB de memória em cada cartão do coprocessador
	Os experimentos utilizando os workflows Montage (Subseção 6.1.1) e sintético para seguem formatos com dados binários comumente adotados por aplicações no domínio de Xeon Phi. Os nós computacionais são interconectados com a tecnologia Mellanox FDR
	aplicações de Óleo e Gás (Subseção 6.1.2) foram conduzidos no cluster de nome Uranus, Óleo & Gás. Diante dessa configuração, os experimentos com esse workflow analisam os InfiniBand em dois níveis (processadores e folhas) em uma topologia fat-tree. Todos os
	pertencente ao NACAD da COPPE/UFRJ. O Uranus consiste de uma máquina SGI Altix custos em termos de tempo para a extração, a indexação e a carga dos dados científicos. experimentos realizados nesse cluster não consideraram os coprocessadores Intel Xeon Phi.
	ICE 8400 com 128 CPUs Intel Xeon (640 cores no total) separados em duas filas de 6.2.2. Grade computacional Grid5000 Considerando as condições de contorno da Figura 46(a), os experimentos realizados
	escalonamento de jobs. Esse cluster conta com 1,28 TB de memória RAM distribuída, 72 Enquanto os experimentos iniciais para a extração de dados científicos foram com o SCC-A utilizaram a API na linguagem de programação Python da ferramenta
	TB de armazenamento em disco através da SGI InfiniteStorage NAS e com rede Infiniband realizados usando o cluster Uranus, os resultados preliminares para a indexação posicional ParaView para acessar e extrair dados científicos de uma região de interesse a partir de
	QDR, DDR e Gigabit. O sistema operacional é o Suse Linux Enterprise Server (SLES) de dados científicos foram obtidos a partir de execuções no Grid 5000 20 . Esse ambiente de arquivos nos formatos XDMF e HDF5, após a execução da atividade EdgeCFD Solver.
	PAD é composto de diversos clusters distribuídos por regiões da França. Em cada região, Conforme a especificação dos operadores Raw e RawI implementados nas atividades Pre
	RDC e Solver RDC, o usuário deve especificar o atributo que contém o caminho para o
	arquivo de dados científicos, assim como os atributos a serem extraídos do arquivo. Os
	20 www.grid5000.fr resultados dessa operação são armazenados em arquivos no formato CSV.

6.3.1. Custo da extração de dados científicos

  os programas de extração dos dados científicos, em acessar os dados científicos em arquivos e em gerar os índices no SGBD. Ou seja, esse custo corresponde à execução das atividades do workflow regidas pelo operador algébrico Raw. De forma análoga, se for adicionada uma ferramenta alternativa, como o FastBit, na arquitetura RDC acoplada ao SCC-A para realizar a indexação dos dados (i.e., uso do operador algébrico RawI), ao invés de programas desenvolvidos pelo nosso grupo, espera-se que esse custo de indexação seja semelhante ao da extração de dados científicos. Ao mesmo tempo, a extração e a indexação de dados científicos também apresentam potenciais analíticos, uma vez que permite o processamento de consultas pelo usuário para analisar os dados científicos capturados ou mesmo o fluxo de dados nos níveis físico e lógico.

	executou em 143,15 minutos. Portanto, o acesso, a extração e a indexação de dados
	científicos presentes em arquivos numa base de dados apresentam um acréscimo de
	aproximadamente 3,84% no tempo total de execução desse workflow científico.
	A partir desses resultados, também observamos que a extração de dados científicos
	corresponde a apenas 3,70% do tempo de execução da segunda versão do workflow
	científico Montage (5,30 minutos). Esse custo representa o tempo de processamento
	envolvido em invocar
	Nessa primeira análise modelamos e executamos duas versões do workflow
	científico Montage com 1.585 arquivos de entrada no formato FITS baixados a partir do
	repositório 2MASS. A primeira versão desse workflow científico é modelada sem
	extratores, ou seja, o SCC-A gerencia apenas o fluxo de arquivos e apresenta o
	comportamento da versão original do SCC. Já a segunda versão realiza a extração de dados
	científicos em cada transformação de dados. Consequentemente, nessa versão há a gerência
	do fluxo de dados no nível lógico, ao contrário da primeira versão que se dedica apenas ao
	nível físico. Como a proposta dessa avaliação é identificar o custo da extração de dados
	científicos, comparou-se os tempos de execução para as duas versões do workflow
	científico. Cada uma das versões foi executada três vezes, sendo que consideramos a média
	de todos os tempos como o valor do tempo de execução a ser comparado.
	No que diz respeito aos aspectos da execução desse workflow científico, ele é
	executado em aproximadamente 2 horas e 30 minutos usando 96 cores do cluster Uranus,
	gerencia em torno de 166.000 arquivos e necessita de mais de 500GB para armazenamento
	desses arquivos em disco. A Figura 52 mostra os resultados obtidos para essa avaliação
	experimental. O workflow científico Montage sem extração de dados científicos executou
	em 137,85 minutos, enquanto que o workflow científico com extração de dados científicos

Cargas de trabalho para a extração de dados científicos

  invocados pelas transformações de dados. Nessas circunstâncias, os usuários comumente necessitam modificar os valores dos atributos ou o algoritmo de uma determinada transformação de dados, para que os resultados apresentem a qualidade desejada ou que os programas de simulação não falhem em tempo de execução.Nesse experimento utilizamos o workflow SyntheticOil&Gas, a fim de avaliar o custo da extração de dados científicos ao modificar a complexidade de executar uma transformação de dados e o volume de dados armazenados em arquivos de dados científicos.

	se a isso, fixou-se nessa análise o tamanho dos arquivos de dados científicos,
	consequentemente, a extração de dados científicos apresentou tempos semelhantes em todas
	as configurações.
	De forma análoga, podemos observar na Tabela 8 que DTCF = 5 apresentou o maior
	Para o workflow científico Montage, a modificação de valores de atributos pode custo percentual de extração de dados científicos (2,42%), pois o tempo de execução do
	significar o aumento da precisão das imagens finais ou da complexidade computacional do workflow científico é o menor de todas as configurações consideradas (i.e., menor
	algoritmo, por exemplo, de projeção de imagens. Com isso, aumenta-se o tempo de contribuição percentual no tempo médio de execução do workflow científico). Entretanto,
	execução do workflow científico e, consequentemente, o tempo de extração de dados ao aumentar o valor de DTCF (i.e., aumentar o tempo médio de execução do workflow
	científicos também pode aumentar, pois os arquivos de dados científicos podem apresentar científico), observamos que a extração de dados científicos apresenta uma menor
	mais resultados relevantes armazenados (i.e., maior volume de dados). Na Subseção 6.3.2 sobrecarga percentual, pois o processamento computacional necessário para a extração de
	avaliamos a influência da carga de trabalho no custo da extração de dados científicos, dados científicos continua semelhante (i.e., mesmos dados de saída, ou seja, mesmo volume
	variando-se o tempo médio de execução das transformações de dados e o volume de dados de dados científicos armazenados em arquivos a serem analisados). No cenário de
	armazenados em arquivos de dados científicos. simulações computacionais em larga escala, que levam muito tempo executando modelos
	computacionais complexos (i.e., transformações de dados com DTCF > 7), pode-se destacar que o tempo de extração é menor que 0,50% do tempo total de execução do workflow 6.3.2. Como discutido na Subseção 6.1.2, os fatores de fragmentação dos dados e de filtro foram científico.
	fixados para esse workflow científico. A primeira análise desse experimento avaliou o custo
	da extração de dados científicos ao variar o tempo médio de execução das transformações
	de dados, sendo esse tempo determinado pelo fator de custo da transformação de dados, do
	termo em inglês Data Transformation Cost Factor (DTCF). De acordo com o valor de
	DTCF informado, os tempos de execução das transformações de dados seguem uma
	distribuição gama Γ(κ, θ), em que κ = 2 DTCF e θ = 1, para DTCF ≥ 0.
	A Tabela 8 apresenta os resultados obtidos para os valores de DTCF iguais a 5, 7 e
	8 usando 96 cores no cluster Uranus. As medidas apresentadas nessa tabela foram baseadas
	em três execuções desse workflow científico, sendo todas elas submetidas nas mesmas
	condições. Consideramos também um nível de confiança maior que 95% para o tempo de
	execução do workflow científico. Nessa análise, o tempo de extração dos dados científicos
	pode ser compreendido pelo tempo de processamento computacional para executar os
	programas de extração e carregar os dados científicos na base de proveniência. Somando-

Tabela 8.

Workflow SyntheticOil&Gas considerando diferentes custos para as transformações de dados usando 96 cores. Tempo médio de execução do workflow (DTCF) Média do tempo de execução de uma transformação de dados (em segundos) Média do tempo de execução do workflow científico (em minutos) Desvio padrão para o tempo de execução do workflow científico (em minutos) Tempo de extração de dados científicos (em minutos) Tempo de extração de dados científicos (%)

  Considerou-se os valores 7, 8, 9 e 10 para FSF usando o cluster Uranus com 64 cores. A Figura 53 mostra a contribuição percentual do tempo de execução dos programas de simulação (i.e., barras de cor cinza escuro) e do tempo de extração dos dados científicos, que é composto de dois aspectos: o tempo para invocar os programas de extração (i.e., barras de cor preta) e o tempo para carregar os dados na base de proveniência (i.e., barras de cor cinza claro).Pelos resultados da Figura 53, observamos que a carga de dados na base de proveniência é desprezível em comparação com as contribuições percentuais para executar o workflow científico e invocar os programas de extração de dados científicos. Para a extração de dados científicos, o seu custo está diretamente associado ao tamanho dos arquivos (i.e., quantidade de dados científicos a serem extraídos) e ao programa de extração empregado. Desse modo, ao aumentar o tamanho dos arquivos, observamos um aumento considerável na contribuição percentual da extração de dados. Na nossa abordagem, os dados extraídos foram definidos pelo próprio usuário. Nesse caso foi realizada a seleção de todos os atributos. Ao mesmo tempo, o próprio usuário poderia tanto aumentar como reduzir o processamento computacional envolvido na extração, de acordo com a quantidade de atributos a serem acessados. Além disso, a definição dessa quantidade de atributos está diretamente relacionada às consultas que esse usuário realizará futuramente.

	5	32	40,89	2,39	0,010	2,42
	7	128	122,79	8,53	0,006	0,41
	8	256	242,31	9,36	0,007	0,22
	A segunda análise lida com uma avaliação da extração de dados científicos ao variar
	o tamanho dos arquivos de dados científicos. Nessa análise definimos um valor fixo de
	DTCF = 6 e variamos o volume de dados armazenados em arquivos de dados científicos
	segundo o fator de tamanho do arquivo, conhecido pelo termo em inglês File Size Factor
	(FSF). De acordo com o valor de FSF definido, o tamanho dos arquivos de dados científicos
	em megabytes (𝜕) muda conforme a seguinte equação: ∂ = 2 FSF , para FSF ≥ 0. Figura

53. Workflow SyntheticOil&Gas considerando diferentes tamanhos para os arquivos de dados científicos.

  

	(%)	100,00			
	execução	60,00 80,00			
	Tempo de	20,00 40,00			
		0,00	128	256	512	1024
	Execução de programa de extração	0,11	0,66	13,77	39,35
	Carga de dados na base de proveniência	0,34	0,61	0,89	1,05
	Execução de programa de simulação	99,89	99,34	86,23	60,65

Tabela 9. Workflow EdgeCFD considerando a extração parcial e total de dados científicos. Versão do workflow Tempo total de execução em minutos Execução das atividades do workflow Extração de dados científicos Carga de dados no SGBD Workflow Desvio padrão para o tempo de execução do

  apenas uma transformação de dados regida pelo operador algébrico SplitMap, que simula o comportamento de um programa de simulação no domínio de Óleo e Gás.

	Semelhante aos experimentos anteriores, assumiu-se dois fatores para a carga de trabalho:
	DTCF (tempo de execução do programa de simulação) e FSF (tamanho dos arquivos de
	workflow
	sem extração dados científicos). O fator DTCF apresentou um valor fixo igual a 6, que corresponde a um 37,22 0,00 2,58 39,80 1,35
	extração tempo médio de 64 segundos para a execução do programa de simulação. Por outro lado, o 36,72 2,36 16,52 55,60 3,04 parcial valor de FSF apresentou diferentes configurações para a análise da escalabilidade de cada
	extração total abordagem na captura de dados científicos. Os valores de FSF foram os seguintes: 10, 11, 41,03 6,21 84,36 131,60 3,66
	Outra opção consiste em o usuário não realizar a extração de dados científicos. 12, 13 e 14.
	Logo, os usuários limitariam as suas consultas ao fluxo de arquivos e realizariam apenas
	análises dos dados científicos de forma isolada (i.e., investigação de apenas um arquivo por
	vez). Mesmo assim, os usuários ainda dependeriam dos programas de extração (e.g.,
	ferramentas alternativas como FastBit) para realizar as análises dos dados científicos, o que
	implica dizer que o custo de extração ainda existiria e os usuários não tirariam proveito do
	paralelismo apoiado pelo SCC-A.
	Concomitantemente, esse seria um processo manual, enquanto que a implementação
	da ARMFUL exigiria apenas informações como quais arquivos precisam ser investigados
	e quais atributos de interesse precisam ser capturados. Portanto, a execução do workflow
	científico usando o SCC-A apresenta vantagens quanto ao potencial analítico provido com
	a extração de dados científicos com a ressalva de que os usuários devem definir quais
	coleções de dados (i.e., conjunto de elementos de dados) eles têm interesse em capturar para
	apoiar consultas durante ou após a execução. Com a extração parcial de apenas os elementos
	de dados de interesse, os usuários podem reduzir esse custo de carga de dados na base de
	proveniência (i.e., dependendo da quantidade de dados a serem extraídos) e tirar proveito tamanho do arquivo de dados científicos também aumenta. Tal comportamento é esperado do paralelismo. pelo fato dos arquivos apresentarem mais conteúdo a ser acessado, extraído e,
	6.3.3. Custo da indexação de dados científicos eventualmente, indexado. Ao mesmo tempo, esse workflow científico considera uma
	Além dos experimentos apresentados nas seções anteriores, realizamos uma extração de dados científicos total, ou seja, todos os atributos presentes nos arquivos de
	avaliação experimental para identificar a sobrecarga de duas abordagens diferentes para a formato CSV são acessados e extraídos.
	captura de dados científicos, baseadas (i) apenas na extração e carga de dados científicos

(chamado de carga de dados); e (ii) na captura e indexação de dados científicos (chamado de indexação de dados). Nesse experimento, considerou-se um workflow científico composto de Os arquivos de dados científicos utilizados nesse experimento seguem o formato CSV, sendo que cada linha de um arquivo contém 4 colunas. Nesse sentido, a primeira linha apresenta o cabeçalho (nomes dos atributos) e as linhas subsequentes possuem os valores assumidos pelos atributos. Como entrada desse fluxo de dados, considerou-se um conjunto de dados composto de 256 elementos de dados de entrada. Consequentemente, para a execução do workflow científico com FSF igual a 10, espera-se que 256 arquivos no formato CSV sejam manipulados, produzindo 262.144 elementos de dados no conjunto de saída dessa transformação de dados.

A Figura 54, a Figura 55 e a Figura 56 mostram os resultados obtidos ao executar esse workflow científico no cluster Suno do Grid 5000 com 32 cores. Na Figura 54 mostramos o custo em termos de tempo, em segundos, para capturar os dados científicos usando esse workflow científico sintético para as duas abordagens. Em todas as configurações, observamos que o custo de indexação dos dados é menor que o custo de carga dos dados. Além disso, o custo da captura de dados aumenta de acordo com que o Figura 54.

Comparação dos tempos para executar programa de extração nas abordagens de carga e indexação de dados. Figura 55. Workflow sintético com programa de extração baseado na carga de dados.

  

		4,00				
	(segundos)	3,00 3,50				
	execução	2,00 2,50				
	Tempo de	1,00 1,50				
		0,50				
		0,00	10	11	12	13	14
	Carga de dados	1,43	1,67	2,06	2,94	3,81
	Indexação de dados	0,19	0,30	0,60	0,94	1,74
			FSF (tamanho dos arquivos de dados científicos)
		100%				
		90%				
		80%				
		70%				
	execução (%)	50% 60%				
	de	40%				
	Tempo	30%				
		20%				
		10%				
		0%	10	11	12	13	14
	Execução de programa de extração	18,27	13,24	9,05	5,51	2,03
	Carga de dados na base de proveniência	1,54	2,86	6,05	7,53	9,29
	Execução de programa de simulação	80,19	83,90	84,90	86,96	88,67
			FSF (tamanho		

dos arquivos de dados científicos) Carga de dados Figura 56. Workflow sintético com programas de extração baseados na indexação de dados.

  

		100%				
		90%				
		80%				
	(%)	70%				
	execução	50% 60%				
	Tempo de	30% 40%				
		20%				
		10%				
		0%	10	11	12	13	14
	Execução de programa de extração	2,40	2,08	2,13	1,12	0,47
	Carga de dados na base de proveniência	2,31	4,58	8,09	10,00	11,56
	Execução de programa de simulação	95,29	93,33	89,79	88,88	87,96
	Primeiramente, ao capturar mais dados científicos, maior a sobrecarga para armazenar os
	dados científicos em um determinado repositório (i.e., base de proveniência). Outro fator
	que justifica a redução percentual da extração de dados é o custo de gerar os arquivos no
	formato CSV durante a execução do workflow científico. Esse custo está adicionado ao
	custo de executar o programa de simulação, uma vez que tais programas normalmente são
	os responsáveis pela geração dos arquivos específicos do domínio no cenário científico real.
	Ademais, podemos destacar que ambas as abordagens para o acesso aos dados
	científicos apresentam uma redução do tempo gasto para capturar os dados científicos ao
	considerar o aumento do tamanho dos arquivos em termos de proporção, como apresentado
	em mais detalhes em SILVA et al. (2017b). Por exemplo, ao duplicar o tamanho dos
	arquivos (de FSF igual a 10 para 11), o tempo de extração aumentou 16,78% e o tempo de
	indexação aumentou 57,89%, enquanto que, em um caso linear, o aumento esperado seria

Já a Figura 55 e a Figura 56 mostram que, ao aumentar o tamanho dos arquivos de dados científicos, o tempo de execução necessário para capturar os dados científicos apresenta uma redução da sua representatividade percentual em relação ao tempo total de execução do workflow científico. Esse comportamento pode ser observado por dois fatores.

FSF (tamanho dos arquivos de dados científicos) Indexação de dados de

  100%. Entretanto, o custo de armazenamento dos dados na base de proveniência aumentou significativamente em função da seleção de todos os elementos de dados. Por último, podemos destacar que a abordagem de indexação poderia apresentar resultados melhores se, ao invés de indexar cada valor de atributo no arquivo de formato CSV, a indexação fosse baseada em cada linha (ou elemento de dados) do arquivo no formato CSV. Vale ressaltar também que a versão baseline do workflow EdgeCFD não realiza a extração, a indexação, nem a carga de dados em um SGBD usando o SCC-A, isto é, ela consiste em uma versão sem apoio à captura de dados científicos. Enquanto isso, a versão carga considera a extração de dados científicos de arquivos nos formatos XDMF e HDF5 e a sua carga na base de dados do SCC-A.Ao aplicar algoritmos de indexação, o custo em termos de tempo para gerar os índices internos no SGBD deve ser agregado ao custo para gerar os índices de acesso aos dados científicos em arquivos. Além disso, como a versão baseline do workflow não extrai dados científicos de arquivos, ela também não gera índices via SGBD e, dessa forma, o tempo sequencial é igual a zero para indexar dados científicos. Já a versão carga do workflow apresenta o maior tempo sequencial para indexar dados científicos, quando comparado com os algoritmos de indexação. Nesse caso, essa abordagem é aproximadamente duas vezes (2x) mais lenta que o algoritmo de indexação posicional, quando se considera malhas mais finas, semelhante ao cenário real de simulações computacionais de CFD. Sendo assim, observa-se uma redução de 64,95% e 46,39% na sobrecarga de tempo para a geração de índices, quando se aplicou os algoritmos de indexação posicional e bitmap, respectivamente, ao invés de uma abordagem de extração e carga dos dados científicos em uma base de dados.

	Assim, ao realizar uma consulta, o processador de consultas teria que utilizar o índice e
	identificar o atributo de interesse nos arquivos de dados científicos.
	Outra evidência desse experimento contempla o espaço de armazenamento da base
	de dados de proveniência. Ao utilizar a abordagem de indexação de dados científicos, a base
	de proveniência consumiu mais espaço de armazenamento (aproximadamente 665MB para
	a configuração de FSF=14) que a abordagem de carga de dados (aproximadamente 255MB
	para a configuração de FSF=14).
	Figura

Outra análise foi realizada a partir da execução do workflow EdgeCFD usando o SCC-A no cluster Stampede com 240 cores para investigar o custo da indexação dos dados científicos em arquivos nos formatos XDMF e HDF5, ao variar a carga de trabalho, ou seja, o volume de dados armazenados nesses arquivos. Mais especificamente, essa análise considera o custo da indexação em termos de tempo sequencial ao variar o número de vértices na malha de entrada (i.e., tamanho da malha), assim como o algoritmo de indexação dos dados científicos (índices posicionais e bitmap).

A Figura 57 apresenta os resultados obtidos para as quatro versões do workflow

(baseline, carga, idx-posicional, idx-bitmap)

, sendo que se calculou o tempo médio de geração dos índices a partir de três execuções para cada versão do workflow.

57. Tempo sequencial de geração dos índices com diferentes cargas de trabalho.

  Em função dos diferentes valores assumidos pelos atributos indexados (i.e., domínio grande de valores possíveis para cada atributo) em arquivos de dados científicos, o algoritmo de indexação bitmap gerou um mapa de bits esparso que consiste em uma matriz com muitas colunas e diferentes valores zerados, 4GB a menos que o algoritmo de indexação bitmap com malhas finas ao considerar o armazenamento em disco da base de dados de proveniência. Embora a ferramenta FastBit apresente recursos para permitir que os usuários modifiquem as configurações do algoritmo de indexação, os experimentos realizados não consideraram essas configurações avançadas do FastBit. Nesse caso, o custo de indexação do FastBit poderia ser reduzido, caso o mapa de bits fosse gerado em função de intervalos de valores, ou seja, baseados em inequidades.Dependendo da abordagem de extração ou indexação de dados científicos adotada, o custo em termos de tempo para carregar os dados em um repositório externo ou uma base de dados pode variar. Nesse sentido, o custo da carga de dados foi avaliado a partir da Figura 58 mostra os custos de executar as atividades do workflow, de capturar os dados científicos por meio da extração ou indexação dos dados, e de carregar os dados no SGBD para cada versão do workflow. Nesse caso, observou-se que o custo em termos de tempo de carregar apenas os dados de proveniência prospectiva e retrospectiva foi igual a, Além disso, a versão carga do workflow apresenta uma sobrecarga em termos de tempo para armazenar os dados científicos igual a 69,75 minutos, se desconsiderarmos o custo de armazenamento dos dados de proveniência, que pode ser observado na versão baseline do workflow (que não realiza a extração ou a indexação de dados científicos). Em relação às abordagens de indexação posicional e bitmap, essa sobrecarga foi de 20,91 e 7,37 minutos, respectivamente. Ao mesmo tempo, o custo de executar, no pior caso, o algoritmo de indexação é de aproximadamente 79 segundos, o que representa 0,13% do tempo de execução do workflow. Sendo assim, a carga de dados científicos em um SGBD pode apresentar uma sobrecarga considerável na análise exploratória de dados científicos, mesmo em cenários com a extração parcial dos dados científicos. Por outro lado, o uso de técnicas

	que representam a não ocorrência de um determinado valor para o atributo representativo desse mapa de bits (mais detalhes na Seção 2.1). Portanto, esse algoritmo de indexação demanda mais tempo para gerar os índices e requer mais espaço em disco. Por exemplo, o algoritmo de indexação posicional requer apresenta avaliações mais detalhadas sobre o uso dos algoritmos do FastBit ao executar esse workflow científico. 6.3.4. Custo da carga de dados aproximadamente, 23,40 minutos (versão baseline do workflow que não realiza extração/indexação de dados científicos). Com esses resultados, observou-se que a versão carga do workflow requer 72,20 minutos a mais que a versão baseline, e 24,20 minutos com relação à pior versão que aplica uma técnica de indexação de dados científicos, i.e., idx-4,Como resultado de um trabalho de colaboração, a dissertação do M.Sc. José Vitor Leite posicional.

Ao analisar exclusivamente os algoritmos de indexação, conclui-se que o algoritmo de indexação bitmap, que utiliza a ferramenta FastBit, apresenta um desempenho em termos de tempo pior que o algoritmo de indexação posicional.

execução do workflow EdgeCFD usando o SCC-A no cluster Stampede com 240 cores, ao variar a abordagem de captura de dados científicos. Nesse experimento considerou-se as seguintes abordagens: baseline (sem a captura de dados científicos), carga (extração e carga de dados em um SGBD, sendo que a geração de índices é realizada internamente pelo SGBD), idx-posicional (indexação posicional), idx-bitmap (indexação usando o FastBit para a geração de mapas de bits). Esse workflow foi executado com malhas finas de entrada para representar um cenário real no domínio de CFD. Vale ressaltar que apenas parte dos dados científicos foram capturados dos arquivos gerados, ou seja, consiste em uma abordagem de extração parcial dos dados. A de indexação de dados científicos pode reduzir as sobrecargas em termos do tempo de execução do workflow.

Tabela 10. Armazenamento da base de dados do SCC-A usando o workflow EdgeCFD.

  

	Versão do	Espaço de armazenamento em GB
	workflow	Malhas grossas	Malhas médias	Malhas finas
	baseline	2,88	2,98	3,20
	carga	4,80	5,76	6,40
	idx-posicional	5,44	5,56	5,73
	idx-bitmap	3,01	3,05	3,20
	6.3.5			

. Custo da captura de dados em uma abordagem in situ

  A instrumentação do código fonte demonstra que o custo computacional em termos de tempo para executar o adaptador Catalyst depende da quantidade de filtros aplicados nos scripts em Python e da frequência de invocação do Catalyst. Mais específico

	do Catalyst, a extração de dados demanda mais tempo de execução que a visualização. Além
	disso, o maior custo relacionado ao solucionador consiste no uso de outros componentes do
	libMesh com 33,67% do tempo total da execução da simulação, seguido da solução não-
	linear das equações do fluido, que requer aproximadamente 32,67%, e do refinamento e
	desrefinamento da malha (AMR/C) com 20,70%.
	Essa avaliação experimental analisou o custo da captura de dados em uma
	abordagem de processamento de dados in situ ao executar uma simulação computacional
	baseada no solucionador libMesh-sedimentation. Mais especificamente, analisou-se o custo
	em termos de tempo de realizar a captura de dados científicos ainda alocados na memória
	utilizando o componente RDE da DfAnalyzer, de executar os componentes da biblioteca
	libMesh e de capturar dados de proveniência usando a DfAnalyzer. Nesse sentido, dois
	estudos de caso foram realizados nessa simulação computacional, conforme apresentado na
	Subseção 6.1.4: um tanque de sedimentação de Rooij e Dalziel (DE ROOIJ e DALZIEL,
	2009) e um tanque real de batimetria. Ambos estudos de caso utilizaram 480 cores do
	cluster LoboC.
	A Tabela 11 mostra o tempo de execução de cada etapa dessa simulação
	computacional. O tempo de execução necessário para utilizar as ferramentas de captura e
	análise de dados foi de 6,41% do tempo total de execução da simulação computacional,

sendo que 6,33% corresponde à extração e à visualização de dados científicos em uma abordagem in situ, e o restante (0,08%) é oriundo da captura de dados de proveniência retrospectiva.

Tabela 11.

Tempo de execução para as diferentes contribuições da simulação de sedimentação baseada no tanque proposto por de Rooij e Dalziel. Contribuição em termos de tempo Tempo de execução (em segundos) Custo por invocação Tempo de execução (%)

  

	necessário para armazenar os arquivos de dados científicos, enquanto que os arquivos de
	visualização usam apenas 2,48% desse espaço.			
	Solucionador do Fluido	16.203,71	0,87	32,67%
	Solucionador do Sedimento	2.797,36	0,15	5,64%
	AMR/C	10.268,32	17,11	20,70%
	Escrita de dados em arquivos	453,96	4,93	0,92%
	XDMF/HDF5			
	Extração e visualização de dados in situ	3.137,24	33,73	6,33%
	Proveniência (DfAnalyzer)	38,47	0,01	0,08%
	Outros componentes do libMesh	16.598,00	-	33,67%
	Total	62.171,00		
	Apesar do custo em termos de tempo para extrair e visualizar os dados in situ ser
	maior que a escrita de dados científicos em arquivos nos formatos XDMF e HDF5, as
	operações em disco podem ser uma limitação em função da capacidade de armazenamento
	de dados nessa infraestrutura. Vale ressaltar que o intervalo em número de passos de tempo
	para armazenar os dados em disco é grande o suficiente para não apresentar gargalos em
	termos de desempenho, conforme discutido na Subseção 6.1.4. Enquanto isso, as
	invocações do Catalyst são feitas em uma frequência 50 vezes maior, para que dados
	parciais, não armazenados em arquivos, sejam extraídos em tempo de execução. A Tabela
	12 mostra o espaço em disco necessário para armazenar os dados científicos extraídos, as
	visualizações (i.e., imagens no formato PNG), os dados de proveniência e os arquivos de
	dados científicos produzidos pela execução dessa simulação. A partir desses resultados,
	ressalta-se que a base de dados de proveniência requer apenas 2,96% do espaço em disco

Tabela 12.

Armazenamento de dados para o tanque de sedimentação de Rooij e Dalziel.

  Já o tanque real de batimetria consiste em uma simulação computacional mais complexa no domínio de CFD, requisitando mais que o dobro do tempo de execução com 480 cores no cluster LoboC, quando comparado com o tanque do primeiro estudo de caso.

	Tipo de dados	Espaço de armazenamento (em MB)	Número de arquivos
	Arquivos de visualização	248,00	62
	Dados extraídos	2,48	248
	Proveniência (DfAnalyzer)	296,01	75.696
	Dados científicos armazenados em arquivos XDMF/HDF5	10.000,00	44.254

A Tabela 13 mostra o tempo de processamento de cada contribuição. Além disso, o uso da DfAnalyzer acrescenta uma baixa sobrecarga em relação ao custo de execução da simulação computacional, representando aproximadamente 1,84% do tempo de execução dessa simulação. Tal comportamento está relacionado ao fato dos modelos computacionais requisitarem mais tempo de processamento para avaliar o comportamento do fluido e dos sedimentos no tanque de interesse.

Tabela 13.

Tempo de execução para as diferentes contribuições da simulação de sedimentação baseada no tanque real de batimetria. Contribuição em termos de tempo Tempo de execução (em segundos) Tempo de execução (%)

  

	houvessem limitações em termos da capacidade de armazenamento em disco, o intervalo
	de escrita em arquivos poderia ser aumentado e, como resultado, o volume de dados
	armazenados em disco diminuiria. Ao mesmo tempo, o intervalo de tempo para a extração
	e a visualização de dados in situ usando o adaptador Catalyst poderia ser mantido, a fim de
	que resultados parciais fossem obtidos em tempo de execução. Assim, dados não
	armazenados em arquivos no disco poderiam ser parcialmente consultados na base de dados
	da DfAnalyzer.		
	Solucionador do Fluido	75.523,49	50,71%
	Solucionador do Sedimento	28.000,50	19,58%
	Escrita de dados em arquivos XDMF/HDF5	421,23	0,29%
	Extração e visualização de dados in situ	2.175,16	1,52%
	Proveniência (DfAnalyzer)	451,70	0,32%
	Total	143.029,00	
	No que diz respeito ao armazenamento de dados, a Tabela 14 mostra o espaço em
	disco necessário para armazenar os dados de proveniência, os dados científicos e os
	arquivos nos formatos XDMF e HDF5. Nesse cenário, os arquivos com dados científicos
	representam a maior contribuição em termos de espaço de armazenamento nessa simulação
	computacional, sendo que menos de 3% do espaço em disco são referentes aos dados
	analíticos, como os dados de proveniência e os arquivos de visualização. Entretanto, caso

Tabela 14.

Armazenamento de dados em disco para o tanque real de batimetria.

  

	Tipo de dados	Espaço de armazenamento (em GB)	Dados científicos (%)
	Arquivos de visualização	0,28	1,21%
	Proveniência (DfAnalyzer)	0,38	1,60%
	Dados científicos armazenados em arquivos XDMF/HDF5	23,44	-
	6.3.6		

. Custo de captura de dados científicos usando a DfAnalyzer e o noWorkflow

  

	Outro experimento conduzido no contexto desta tese considerou uma análise
	comparativa do custo de captura de dados científicos usando a DfAnalyzer e o noWorkflow
	ao executar a simulação computacional de multifísica usando as ferramentas do projeto
	FEniCS. Mais especificamente, analisou-se o tempo de execução da simulação (i) sem a
	captura de dados de proveniência, conhecida como a versão baseline, (ii) com a captura de
	dados de proveniência usando a DfAnalyzer e (iii) com a captura de dados de proveniência
	usando o noWorkflow.
	A Figura 60 mostra esses tempos de execução em segundos. Pelos resultados
	experimentais, destaca-se que o noWorkflow apresenta uma sobrecarga em termos de
	tempo para capturar os dados de proveniência significativamente superior à DfAnalyzer
	(aproximadamente 29x mais lento). Além disso, a sobrecarga do noWorkflow é
	impraticável em um cenário que envolva o acompanhamento da execução de simulações
	computacionais, pois a sua sobrecarga é aproximadamente 13x maior que o tempo de
	executar a aplicação de CSE sem captura de dados de proveniência.

Figura 60.

Comparação do custo de captura de dados de proveniência usando a DfAnalyzer e o noWorkflow na simulação de multifísica.

  

	6.4	Execução da simulação de multifísica usando FEniCS
	Tempo de execução (segundos)	50,00 100,00 150,00 200,00 250,00 300,00 350,00		
		0,00	Baseline	DfAnalyzer	noWorkflow
	Proveniência Retrospectiva		0,00	9,22	146,09
	Proveniência Prospectiva	0,00	0,23	126,71
	Processamento Computacional		21,16	21,17	21,18
	Ademais, o custo de armazenamento de dados usando a DfAnalyzer foi de 1,0 MB
	de dados em nossa base de dados relacional, enquanto que o noWorkflow demandou
	aproximadamente 123,6 MB de dados. Diante desses valores, pode-se destacar que a menor
	sobrecarga da DfAnalyzer está relacionada ao fato de especificarmos quais dados científicos
	devem ser capturados e a sua vantagem analítica por disponibilizar apenas dados científicos
	ou valores de atributos que são representativos para as consultas de interesse dos usuários
	do domínio. Por outro lado, a DfAnalyzer exige um esforço a mais na etapa offline, ou seja,
	durante a modelagem das simulações computacionais para apoiarem a captura dos dados de
	proveniência e dos dados científicos.		

Ao mesmo tempo, a sobrecarga da DfAnalyzer também é significativa, representando quase em 50% de sobrecarga de tempo em relação ao tempo de execução da versão baseline. Vale destacar que, pelo fato desse experimento ter sido executado em um ambiente local, os componentes do projeto FEniCS competiram diretamente pelos mesmos recursos computacionais que deveriam ser dedicados à DfAnalyzer para a carga dos dados extraídos. Tal comportamento não ocorreria em um ambiente de PAD, uma vez que dedicamos recursos computacionais para a DfAnalyzer diferentes dos utilizados pelas aplicações de CSE.

. Apoio ao processamento de consultas para a análise de dados científicos

  

	Diferentemente dos experimentos anteriores, que apresentaram execuções das
	simulações computacionais modeladas para capturar dados específicos do domínio a partir
	de arquivos de dados científicos ou de dados ainda alocados em memória, essa seção
	apresenta o potencial analítico da arquitetura ARMFUL e das suas implementações por
	meio do processamento de consultas. Nesse sentido, as seguintes simulações
	computacionais foram consideradas: Montage, EdgeCFD e libMesh-sedimentation.
	Basicamente, executamos diversas consultas com o propósito de demonstrar a abrangência
	da nossa solução na análise exploratória de dados científicos, considerando os três tipos de
	consultas discutidos no Capítulo 2.

MONTAGE.

As primeiras consultas realizadas foram baseadas na análise de dados científicos provenientes de arquivos produzidos por programas de simulação no domínio da astronomia, considerando a execução do workflow Montage usando o SCC-A. Para a extração de dados científicos, considerou-se o uso do operador algébrico Raw. A primeira consulta, mostrada na Figura 61, favorece a análise do conteúdo específico do domínio presente em um arquivo de dados científicos (Seção 2.1). Nessa consulta, obtém-se os valores dos atributos CRVAL1 e CRVAL2, quando o valor de CRVAL1 é maior que 210 (Figura 62). Nesse caso, os dados científicos são extraídos de arquivos no formato FITS, que são gerados por um programa de projeção e carregados na tabela RProjection da base de dados do SCC-A. A tabela RProjection, dessa forma, representa uma visão reduzida do conteúdo original presente nesses arquivos. Figura 61.

Consulta para analisar o conteúdo de um arquivo específico do domínio.

  programa de simulação para a projeção de imagens. Essa característica pode auxiliar o usuário a analisar se a projeção está sendo realizada da forma apropriada, identificar potenciais anomalias, ou observar ajustes finos a serem realizados nas configurações.Assim, o usuário pode, inclusive, observar a necessidade de interrupção da própria execução do workflow científico. Outra característica importante consiste em evitar a análise sintática do arquivo no formato FITS após a sua geração para saber como deve ser o acesso aos atributos, uma vez que contamos com um catálogo para os formatos de arquivos de dados científicos.

	SELECT CRVAL1, CRVAL2
	FROM RProjection
	WHERE CRVAL1 > 210.00;
	De uma forma alternativa, esse tipo de consulta também poderia ser obtido sem
	utilizar o SCC-A, por meio do uso de ferramentas alternativas como o FastQuery e RAW.
	Entretanto, a nossa abordagem apresenta algumas vantagens em relação a essas soluções
	alternativas. Primeiramente, as consultas podem selecionar os atributos presentes nos
	arquivos de formato FITS durante a execução da transformação de dados que utiliza o

  1,00 em nenhum ponto da malha. Ao mesmo tempo, vale ressaltar que os ajustes nos valores dos SELECT f.time_step, t.model_name, amr.c_fraction,

	fconfig. nonlinear_tolerance,
	sconfig. nonlinear_tolerance,
	f.final_linear_residual, f.final_non_linear_residual,
	s.final_linear_residual, s.final_non_linear_residual,
	max(ext.d)
	FROM time_step_control as t,
	amr_config as amr,
	get_maximum_iterations_to_flow as fconfig,
	get_maximum_iterations_to_sediments as sconfig,
	solver_simulation_fluid as f,
	solver_simulation_sediments as s,
	line_extraction_1 as ext

WHERE t.simulation_id = amr.simulation_id AND amr.simulation_id = fconfig.simulation_id AND fconfig.simulation_id = sconfig.simulation_id AND sconfig.simulation_id = f.simulation_id AND f.simulation_id = s.simulation_id AND s.simulation_id = ext.simulation_id;

http://healpix.sourceforge.net

www.lncc.br 

hpcdb.wordpress.com 

https://www.postgresql.org/

https://visit.llnl.gov

https://hpcdb.github.io/armful

https://www.w3.org/TR/prov-dm/

https://hpcdb.github.io/armful/a-chiron.html

https://www.postgresql.org/

https://wiki.duraspace.org/display/ISLANDORA713/FITS+Extractor

https://hpcdb.github.io/armful/dfanalyzer.html

https://www.open-mpi.org

http://www.openmp.org

https://libmesh.github.io

, {𝑑𝑡 1 }, {(1)}). Segundo o formalismo de fluxo de dados, uma transformação determina o uso de um ou mais programas de simulação. Consequentemente, tarefas de uma

https://support.hdfgroup.org/HDF5

https://bitbucket.org/nacadhpc4e/libmesh-sedimentation

www.nacad.ufrj.br 

https://www.tacc.utexas.edu/systems/stampede

http://www.nacad.ufrj.br/pt/recursos/sgiicex

parâmetros de entrada exigem que o solucionador libMesh-sedimentation tenha apoio a adaptações em tempo de execução da simulação, como mostrado na Subseção 6.2.4.