ANÁLISE DO RASTRO DE PROVENIÊNCIA EM SIMULAÇÕES COMPUTACIONAIS EM LARGA ESCALA
Thiago Barroso Perrotta
Projeto de Graduação apresentado ao Curso de Engenharia de Computação e Informação da Escola Politécnica da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação.
Orientadores: Marta Lima de Queirós Mattoso Vítor Silva Sousa
Rio de Janeiro Setembro de 2017
ANÁLISE DO RASTRO DE PROVENIÊNCIA EM SIMULAÇÕES COMPUTACIONAIS EM LARGA ESCALA
Thiago Barroso Perrotta
PROJETO SUBMETIDO AO CORPO DOCENTE DO CURSO DE ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA ESCOLA POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO.
Examinadores:
Profa. Marta Lima de Queirós Mattoso, D.Sc.
Vítor Silva Sousa, M.Sc.
Prof. Alexandre de Assis Bento Lima, D.Sc.
Renan Francisco Santos Souza, M.Sc.
RIO DE JANEIRO, RJ – BRASIL SETEMBRO DE 2017
Barroso Perrotta, Thiago
Análise do Rastro de Proveniência em Simulações Computacionais em Larga Escala/Thiago Barroso Perrotta. – Rio de Janeiro: UFRJ/POLI – COPPE, 2017.
XIV,66 p.: il.; 29, 7cm.
Orientadores: Marta Lima de Queirós Mattoso Vítor Silva Sousa
Projeto (graduação) – UFRJ/ Escola Politécnica/ Curso de Engenharia de Computação e Informação, 2017.
Referências Bibliográficas: p. 63– 66.
1. Workflows Científicos. 2. Análise de Dados Científicos. 3. Gerência de Fluxos de Dados. 4. Dados de Proveniência. 5. Bancos de Dados. I. Lima de Queirós Mattoso, Marta et al. II. Universidade Federal do Rio de Janeiro, Escola Politécnica/ Curso de Engenharia de Computação e Informação. III. Título.
Dedico este trabalho aos meus pais.
Agradecimentos
Agradeço a minha mãe e ao meu pai, por todo o carinho e apoio que recebi, por serem meu exemplo de vida, e por sempre permanecerem presentes ao meu lado, tanto nas fases boas quanto nas ruins.
Agradeço ao Vítor Silva e à professora Marta Mattoso, meus orientadores, por todo o inestimável suporte e atenção nas diversas reuniões de projeto que tivemos, essenciais para o êxito deste trabalho.
Agradeço à professora Márcia Cerioli e ao professor Ricardo Marroquim, pela orientação durante meu período de iniciação científica na UFRJ.
Também agradeço ao Donald Knuth e ao Leslie Lamport, por tornarem a com-posição deste trabalho agradável através do TEX e do LATEX, respectivamente.
Por fim, agradeço à serendipidade e aos meus bons amigos, os quais dia a dia fazem-me crescer e tornar-me uma pessoa cada vez melhor.
M u i t o o b r i g a d o a t o d o s v o c ê s !
“Really pay attention to negative feedback and solicit it, particularly from friends… hardly anyone does that, and it’s incredibly helpful.”
Resumo do Projeto de Graduação apresentado à Escola Politécnica/COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação.
ANÁLISE DO RASTRO DE PROVENIÊNCIA EM SIMULAÇÕES COMPUTACIONAIS EM LARGA ESCALA
Thiago Barroso Perrotta
Setembro/2017 Orientadores: Marta Lima de Queirós Mattoso
Vítor Silva Sousa
Curso: Engenharia de Computação e Informação
Simulações computacionais frequentemente consomem e produzem grandes vo-lumes de dados, parte dos quais é armazenada em arquivos brutos em diversos formatos de acordo com o domínio da aplicação, tal como o HDF5 em simulações de dinâmica de fluidos computacionais. Durante essas simulações, usuários em geral precisam rastrear grandezas de interesse com base em elementos de dados relaciona-dos de vários arquivos, a fim de otimizar o controle de sua execução. No entanto, esse rastreamento costuma ser feito somente ao fim da simulação. Apesar dos formatos de arquivo serem apoiados por diversas bibliotecas, os usuários em geral precisam desenvolver programas ad-hoc para realizarem uma análise em grande escala, a qual pode ser ainda mais custosa se realizada com bancos de dados, pois eles exigem que os dados científicos sejam estruturados e carregados. Nesse cenário, Sistemas de Gerência de Workflows Científicos (SGWfC) com ciência do fluxo de dados têm em-pregado a abstração de workflows científicos para apoiar a execução paralela dessas simulações, em que os dados de proveniência podem favorecer a gerência de elemen-tos de dados relacionados em múltiplos arquivos de dados científicos (i.e., produzi-dos por diferentes programas de simulação). Este trabalho utiliza a arquitetura de componentes ARMFUL, que baseia-se em dados de proveniência para extrair e rela-cionar grandezas de interesse. Mais especificamente, contribui com um mecanismo de processamento de consultas durante a execução de simulações computacionais, considerando-se o fluxo de elementos de dados ao longo das mesmas.
Palavras-Chave: Workflows Científicos, Análise de Dados Científicos, Gerência
Abstract of the Undergraduate Project presented to Poli/COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Computer and Information Engineer.
PROVENANCE TRACING ANALYSIS ON LARGE-SCALE COMPUTER SIMULATIONS
Thiago Barroso Perrotta
September/2017
Advisors: Marta Lima de Queirós Mattoso Vítor Silva Sousa
Course: Computer and Information Engineering
Computer simulations frequently consume and produce lots of raw data files, which usually follow a de facto standard data format established by the application domain, such as HDF5 in fluid dynamics simulations. During these simulations, users often need to track quantities of interest based on elements of related data from several raw files, in order to control the execution as much as possible. Nonetheless, this tracking is usually done only once the simulation ends. Notwithstanding the file formats being supported by several programming languages and libraries, users gen-erally need to develop ad-hoc programs to perform a specific analysis in large scale, which can be even more costly if performed with database systems, because they require the raw data files to be structured and loaded. In this scenario, dataflow-aware Scientific Workflow Management Systems (SWfMS) have resorted to scientific workflow abstractions to support parallel execution of these simulations, in which provenance data can help to manage related data elements in multiple raw data files (i.e., produced by different simulation programs). This work uses the component-based ARMFUL architecture, which is component-based on provenance data to extract and relate quantities of interest. More precisely, it contributes with a query processing mechanism for computer simulations, considering the flow of data elements during its execution.
Keywords: Scientific Workflows, Raw Data Analysis, Dataflow Management,
Sumário
Lista de Figuras xi
Lista de Tabelas xii
Lista de Códigos xiii
Lista de Abreviaturas xiv
1 Introdução 1
1.1 Visão geral e Contextualização . . . 1
1.2 Motivação . . . 2 1.3 Contribuição . . . 3 1.4 Estruturação do Texto . . . 4 2 Referencial Teórico 5 2.1 Simulação Computacional . . . 5 2.2 Fluxo de dados . . . 6 2.2.1 Conceito. . . 6 2.2.2 Transformação de dados . . . 6 2.2.3 Conjunto de dados . . . 6 2.2.4 Atributo de dados . . . 7 2.2.5 Coleção de dados . . . 7 2.2.6 Elemento de dados . . . 7 2.2.7 Dependência de dados . . . 8 2.2.8 Um exemplo . . . 8 2.3 Dados de proveniência . . . 10 2.3.1 Definição . . . 10
2.3.2 Categorias de dados de proveniência . . . 11
2.4 Rastreamento de dados de proveniência . . . 13
2.4.1 Gerência do fluxo de dados no nível físico . . . 13
2.4.2 Gerência do fluxo de dados no nível lógico . . . 13
3 Análise de soluções para consultas a dados científicos 15
3.1 Tipos de consulta . . . 15
3.2 Análise de dados científicos isolados . . . 16
3.3 Análise do fluxo de arquivos . . . 16
3.4 Análise do fluxo de elementos de dados em múltiplos arquivos . . . . 18
4 Arquitetura ARMFUL 19 4.1 Visão geral . . . 19
4.1.1 Banco de dados de proveniência . . . 21
4.1.2 Extração e indexação de dados científicos . . . 21
4.1.3 Ingestão de dados. . . 22
4.1.4 Processamento de consultas . . . 22
4.2 DfAnalyzer: uma instância da arquitetura ARMFUL . . . 23
4.2.1 Visão Geral . . . 23
4.2.2 Provenance Data Gatherer (PDG) . . . 23
4.2.3 Raw Data Extractor (RDE) . . . 23
4.2.4 Raw Data Indexer (RDI) . . . 24
4.2.5 Query Preprocessor (QPP) . . . 24
5 Abordagem para análise de rastros de proveniência 26 5.1 Tipos de rastros de proveniência . . . 26
5.1.1 Físico . . . 27
5.1.2 Lógico . . . 27
5.1.3 Híbrido . . . 28
5.2 Desenvolvimento do Pré-processador de Consultas . . . 28
5.3 Algoritmos utilizados . . . 29
5.3.1 Detecção das últimas transformações de dados . . . 29
5.3.2 Detecção das trilhas de transformações de dados . . . 30
5.3.3 Detecção das trilhas de conjuntos de dados. . . 31
5.3.4 Obtenção de múltiplos mapeamentos de atributos entre dois conjuntos de dados . . . 32
5.3.5 Obtenção dos caminhos entre dois conjuntos de dados . . . . 34
5.3.6 Geração da consulta em SQL . . . 36
5.3.7 Pré-processamento . . . 38
5.4 Um exemplo de consulta . . . 40
5.4.1 Exemplo #1 . . . 40
6 Experimentos 44
6.1 Simulação computacional em sedimentação . . . 44
6.2 Consultas . . . 46 6.2.1 Consulta #1 . . . 47 6.2.2 Consulta #2 . . . 49 6.2.3 Consulta #3 . . . 51 7 Conclusão 56 7.1 Considerações Finais . . . 56 7.2 Trabalhos Futuros . . . 57 A Funções auxiliares 58 Referências Bibliográficas 63
Lista de Figuras
2.1 Exemplo de transformação de dados . . . 6
2.2 Exemplo de especificação de fluxo de dados . . . 9
2.3 Proveniência prospectiva do exemplo de contagem de palavras . . . . 12
4.1 Componentes da arquitetura ARMFUL . . . 20
5.1 Exemplo de fluxo de dados para a seção Seção 5.1 . . . 26
5.2 Exemplo de detecção das trilhas de transformações . . . 30
5.3 Fluxo de dados de exemplo . . . 40
5.4 Caminho obtido na consulta do exemplo #1 . . . 42
6.1 Fluxo de dados D† utilizado nos experimentos . . . 46
6.2 Caminho do fluxo de dados D† rastreado na consulta #1 . . . 48
6.3 Caminho do fluxo de dados D† rastreado na consulta #2 . . . 50
6.4 Caminho do fluxo de dados D† rastreado nas consultas #3A, #3B e #3C . . . 53
Lista de Tabelas
2.1 Exemplo de conjunto de dados com seus atributos de dados . . . 7
2.2 Relação entre coleção de dados e elemento de dados . . . 8
2.3 Atributos de dados do conjunto de dados iinputmesh . . . 10
2.4 Valores dos atributos de dados de iinputmesh . . . 10
2.5 Proveniência retrospectiva do exemplo de contagem de palavras . . . 12
5.1 Atributos de dados do fluxo de dados da Figura 5.1 . . . 27
5.2 Atributos de dados do fluxo de dados D0 . . . 40
5.3 Elementos de dados do fluxo de dados D0 . . . 41
5.4 Argumentos da função generateSqlQuery para o Exemplo #2 . . . . 41
5.5 Resultados obtidos com a consulta em SQL do exemplo #2 . . . 41
5.6 Argumentos da função generateSqlQuery para o Exemplo #1 . . . . 42
5.7 Resultados obtidos com a consulta em SQL do exemplo #1 . . . 43
6.1 Exemplos de alguns atributos de dados de S† . . . 45
6.2 Argumentos da função generateSqlQuery para a consulta #1 . . . . 47
6.3 Argumentos da função generateSqlQuery para a consulta #2 . . . . 49
6.4 Argumentos da função generateSqlQuery para as consultas #3A, #3B e #3C . . . 52
Lista de Códigos
5.1 Detecção das últimas transformações de dados . . . 29
5.2 Detecção das trilhas de transformações . . . 31
5.3 Detecção das trilhas de conjuntos de dados . . . 32
5.4 Obtenção de múltiplos mapeamentos de atributos . . . 33
5.5 Obtenção dos caminhos entre dois conjuntos de dados . . . 34
5.6 Busca em Profundidade (DFS) dos caminhos . . . 35
5.7 Geração da consulta em SQL . . . 37
5.8 Código SQL gerado no exemplo #2 . . . 41
5.9 Código SQL gerado no exemplo #1 . . . 42
6.1 Código em SQL gerado na consulta #1 . . . 48
6.2 Resultados da consulta #1. . . 49
6.3 Código em SQL gerado na consulta #2 . . . 50
6.4 Resultados da consulta #2. . . 51
6.5 Código em SQL gerado na consulta #3A . . . 52
6.6 Versão simplificada dos resultados da consulta #3A. . . 53
6.7 Código em SQL gerado na consulta #3B . . . 54
6.8 Versão simplificada dos resultados da consulta #3B. . . 54
6.9 Código em SQL gerado na consulta #3C . . . 54
6.10 Versão simplificada dos resultados da consulta #3C.. . . 55
A.1 Obtenção das próximas transformações de dados de uma transformação 58 A.2 Contagem dos conjuntos de dados de saída de uma transformação . . 58
A.3 Contagem das próximas transformações de dados de uma transformação 59 A.4 Determinação de se pelo menos uma transformação possui mais de um conjunto de dados de entrada. . . 59
A.5 Contagem dos conjuntos de dados anteriores a uma transformação . . 59
A.6 Obtenção da trilha de transformações de uma transformação. . . 60
A.7 Obtenção das transformações de dados anteriores a uma transformação 60 A.8 Obtenção dos próximos conjuntos de dados de uma transformação . . 60
A.9 Obtenção dos conjuntos de dados anteriores a uma transformação . . 61
A.10 Obtenção dos próximos conjuntos de dados de um conjunto de dados 61 A.11 Obtenção da transformação entre dois conjuntos de dados . . . 62
Lista de Abreviaturas
API Application Programming Interface, p. 18
ARMFUL Analysis of Raw Data from Multiple Files, p. 3, 20
ASCII American Standard Code for Information Interchange, p. 12
DAG Directed Acyclic Graph — Grafo Direcionado Acíclico, p. 2
DFS Depth-first Search (Busca em profundidade), p. 35
FITS Flexible Image Transport System, p. 1
HDF Hierarchical Data Format, p. 1
JSON JavaScript Object Notation, p. 17
NACAD Núcleo Avançado de Computação de Alto Desempenho, p. 20
NetCDF Network Common Data Form, p. 1
PAD Processamento em Alto Desempenho, p. 1
PID Process ID, p. 11
PNG Portable Network Graphics, p. 17
QPP Query Preprocessor — Pré-Processador de Consultas, p. 3
SGBD Sistema de Gerenciamento de Banco de Dados, p. 3
SGWfC Sistema de Gerência de Workflows Científicos, p. 2
SQL Structured Query Language, p. 3
UFRJ Universidade Federal do Rio de Janeiro, p. 20
Capítulo 1
Introdução
Neste capítulo são apresentadas a visão geral e a motivação desta monografia, além da contribuição proposta.
1.1 Visão geral e Contextualização
Simulações computacionais tornaram-se predominantes e omnipresentes no dia-a-dia de cientistas1, sendo necessárias na realização de análises que utilizam modelos
computacionais complexos que lidam com grandes volumes de dados [1]. Isso permite a exploração de dados específicos de domínio para apoiar esses usuários na validação de hipóteses científicas ou comportamentos peculiares.
Essas simulações geralmente envolvem a execução de muitos programas do do-mínio científico, os quais intensivamente consomem e produzem muitos dados. A maior parte desses dados é armazenada em diversos formatos de arquivo também no domínio da aplicação [1], por exemplo, FITS [2] em astronomia, ou HDF5 [3] e NetCDF [4] em dinâmica de fluidos computacionais. Uma grande parte dessas si-mulações computacionais em larga escala leva um longo tempo para ser executada, mesmo em ambientes de PAD (Processamento em Alto Desempenho) [5], onde o poder de computação é amplificado através da utilização de diversos núcleos com-putacionais.
Durante as simulações, usuários com frequência precisam rastrear grandezas de interesse, tais como resíduos, tempo de execução e estimativas de erro, baseadas em elementos de dados relacionados de vários arquivos, a fim de controlar a sua execução ao máximo possível [6]. Contudo, esse rastreamento costuma ser realizado manualmente durante a execução dessas simulações. Nesse caso, a alternativa torna-se realizar estorna-se rastreamento somente ao fim das simulações, o que não é prático para o usuário, já que essas simulações levam um tempo considerável de execução mesmo
em PAD [5]. Além disso, mesmo considerando que os arquivos produzidos sejam tipicamente apoiados por diversas linguagens de programação e bibliotecas, diversos programas ad-hoc precisam ser desenvolvidos a fim de permitir análises em grande escala.
1.2 Motivação
As simulações computacionais podem ser gerenciadas por um SGWfC (Sistema de Gerência de Workflows Científicos) paralelo, tal como o Kepler [7] e o Pegasus [8], o que faz com que se beneficiem da proveniência e do paralelismo de dados entre os diferentes programas que compõem o seu workflow2 [9]. Tais workflows científicos
são composições de tarefas de processamento de dados sequenciais e concorrentes, cuja ordem de execução é determinada com base nas interdependências entre os dados [9]. Eles podem ser modelados através de um fluxo de dados (dataflow) que descreve todos os conjuntos de dados, atributos de dados, transformações de dados e dependências entre os mesmos [5]. Esses fluxos de dados são usualmente especi-ficados na forma de um DAG (grafo direcionado acíclico), em que transformações de dados são representadas como nós, e conjuntos de dados são modelados como arestas direcionadas.
Os SGWfCs são usualmente difíceis de serem configurados e utilizados pelos usuários – alguns deles, tais como o Taverna [10], possuem uma boa ênfase em usabilidade, porém não compensam na paralelização e utilização de recursos com-putacionais distribuídos, perdendo, assim, sua efetividade. Eles facilitam o design, a manutenção, a execução e o monitoramento de workflows científicos. Entretanto, sem suporte ao rastreamento de dados científicos, o desafio é analisar a propaga-ção de dados de conjuntos de arquivos ao longo da execupropaga-ção da simulapropaga-ção, o que é bastante propenso a erros se realizado manualmente [1]. Isso porque são necessá-rios: (i) a nomenclatura de arquivos de forma apropriada; (ii) escrever e gerenciar programas ad-hoc para gerenciar cada transformação de dados e arquivos; e (iii) mapear o fluxo das transformações de dados, assim como dos elementos de dados consumidos e produzidos pela execução de cada transformação de dados.
Silva et al. [1] consideram que existem três tipos básicos de consulta3 que são
rotineiramente utilizadas em simulações científicas: 1. conteúdo de arquivo específico de domínio;
2. múltiplos arquivos relacionados através de transformações de dados / progra-mas de simulação; e
2Em tradução livre, “fluxo de trabalho”. No entanto, daqui em diante continuaremos a utilizar workflow, por ser um termo mais preciso.
3. elementos de dados relacionados de múltiplos arquivos
1.3 Contribuição
Silva et al. [1] observam que a capacidade de realizar todos os três tipos de con-sultas citados ainda é um problema em aberto, sendo especialmente importante em situações de larga escala, onde muitos dados são manipulados intensivamente. Para preencher esse gargalo, Silva et al. [1] propuseram a arquitetura ARMFUL (Analysis of Raw Data from Multiple Files) [5, 6]: com ela, todos os três tipos de consultas podem ser realizados. Todos esses tipos de consultas podem ser apoiadas pela ARMFUL ao oferecer uma base de dados de proveniência, cujo objetivo é guar-dar as referências para os arquivos e os elementos de dados do domínio da aplicação selecionados pelos usuários, para que eles possam ser devidamente rastreados [1].
Dessa forma, os usuários podem submeter consultas para selecionar dados ci-entíficos de suas simulações não apenas após, mas também durante a execução da simulação: o objetivo é a possibilidade de captação dos elementos de dados de in-teresse no momento em que eles são gerados [1]. O benefício dessa abordagem é evitar que a extração (parsing) dos dados tenha que ocorrer por completo, em vez disso, ela pode ser realizada dinamicamente (on-the-fly), sem ter que fazer todo o carregamento dos dados em memória ou em um SGBD (Sistema de Gerenciamento de Banco de Dados) , o que evita a duplicação e a manutenção de dados no SGBD, e também reduz o custo computacional da consulta, que passa a ser realizada em menos tempo.
Apesar da arquitetura ARMFUL ser bem abrangente e eficiente em prover con-sultas envolvendo dados de domínio, de proveniência e de execução, ela oferece um recurso limitado para o usuário submeter consultas dessas três classes. Na verdade, o usuário precisa não apenas conhecer bem a linguagem SQL, mas também os re-lacionamentos necessários para permitir o rastreamento entre múltiplos arquivos de dados. Este trabalho tem por objetivo facilitar essa interação do usuário com a elaboração de consultas analíticas ao utilizar a ARMFUL.
Mais especificamente, a contribuição deste trabalho é uma extensão da arqui-tetura ARMFUL apresentada em [5, 6] com a introdução de um processador de consultas, denominado QPP (Query Preprocessor) . O QPP atua como um compo-nente do ARMFUL que é responsável pela interação do usuário com os conjuntos de dados de suas simulações. A partir dele, o usuário é capaz de escrever uma consulta sem ter que aprender SQL (Structured Query Language), pois ela é representada em alto nível, em um formato que é posteriormente traduzido (convertido) para SQL de forma transparente para o usuário. Isso pode facilitar o uso do sistema, já que o usuário não precisaria ter profundos conhecimentos em SQL e poderia se preocupar
apenas com o domínio da aplicação da simulação computacional e com os dados e grandezas de interesse para as consultas.
Outro benefício é o desempenho atingido com as consultas: o QPP faz o pré-processamento da especificação da simulação computacional — que só precisa ser realizado uma única vez, sempre que o QPP é executado durante uma sessão — em estruturas de dados eficientes em relação aos dados obtidos pelo componente de Captura de Dados de Proveniência (ou, do termo em inglês, Provenance Gatherer) da arquitetura ARMFUL. Desse modo, consultas consecutivas beneficiam-se da pro-veniência já carregada na memória; reduzindo, portanto, o tempo de processamento.
1.4 Estruturação do Texto
A principal contribuição deste trabalho consiste no desenvolvimento do QPP: como ele foi criado, como ele se integra à arquitetura ARMFUL previamente apresentada, e quais são os benefícios — qualitativamente e quantitativamente — que ele acrescenta à mesma.
Assim, ele está organizado da seguinte forma: o Capítulo 2 apresenta o emba-samento teórico, introduzindo e definindo os conceitos, definições e a terminologia que será utilizada ao longo do trabalho. No Capítulo 3 listamos algumas publica-ções relacionadas e recentes, algumas dentre as quais serviram como motivação e base para essa, e também abordamos a diferença entre os tipos de consulta mais comuns em simulações científicas. O Capítulo 4 aborda a arquitetura ARMFUL e apresenta o DfAnalyzer. No Capítulo 5 desenvolvemos a abordagem e mostramos os algoritmos utilizados para analisar rastros de proveniência dos arquivos e dados científicos de simulações computacionais. NoCapítulo 6são abordados os resultados obtidos através do QPP e os experimentos realizados com o mesmo. Finalmente, o
Capítulo 2
Referencial Teórico
Neste capítulo são abordados alguns conceitos e a terminologia utilizada ao longo desta monografia. Parte desse conteúdo é baseado na proposta de tese de doutorado do M.Sc. Vítor Silva Sousa [11], co-orientador deste trabalho.
2.1 Simulação Computacional
Uma simulação computacional, também chamada de simulação científica, é um “método de abstração e sistematização do processo experimental ou parte dele” [11, 12]. Ela emergiu como um meio de executar experimentos científicos em ambientes computacionais [13], e consiste de um ou vários programas de simulação específicos. Tais programas de simulação, em particular, são encadeados para reali-zar o processamento de dados necessários na condução do experimento científico de interesse.
Dessa forma, uma simulação computacional pode ser representada por meio de um fluxo de dados (elucidado naSeção 2.2), no qual “os programas de simulação cor-respondem às transformações de dados e as dependências de dados corcor-respondem ao fluxo de dados entre duas transformações de dados” [11,13]. Uma transformação
de dados é definida como um componente da simulação computacional que é capaz
de executar programas, com parâmetros de entrada e de saída, os quais são utiliza-dos para representar dependências entre cada uma das transformações de dautiliza-dos. Os dados consumidos ou produzidos pelos programas de simulação são representados por conjuntos de dados de entrada ou de saída, respectivamente. Cada conjunto de dados assume um conjunto pré-definido de atributos, enquanto cada elemento de dados desse conjunto apresenta valores para cada atributo pré-definido.
2.2 Fluxo de dados
2.2.1 Conceito
Um fluxo de dados (do inglês dataflow) é modelado como um grafo direcionado acíclico (DAG), no qual os vértices (nós) representam as transformações de dados1
de uma simulação computacional, e as arestas direcionadas representam os conjuntos de dados entre as transformações [5].
Formalmente, uma especificação de fluxo de dados D é definida como
D = (T, S, Φ) onde:
• T = {dt1, dt2, . . . , dtα} é um conjunto de transformações; • S = {ds1, ds2, . . . , dsβ} representa os conjuntos de dados; e • Φ = {φ1, φ2, . . . , φγ} é um conjunto de dependência de dados.
2.2.2 Transformação de dados
Uma transformação de dados dt é caracterizada pelo consumo de um ou mais conjuntos de dados de entrada e pela produção de um ou mais conjuntos de dados de saída. O exemplo daFigura 2.1 ilustra essa definição.
Figura 2.1: Exemplo de transformação de dados, dt, com dois conjuntos de dados
de entrada, ds1 e ds2, e dois conjuntos de dados de saída, ds3 e ds4.
No contexto de simulações computacionais, transformações de dados correspon-dem aos programas de simulação utilizados para executar um modelo computacional.
2.2.3 Conjunto de dados
A especificação de um conjunto de dados ds é dada por
ds = (A, C) onde:
• A = {da1, da2, . . . , daδ} é um conjunto de atributos de dados; e • C = {dc1, dc2, . . . , dcζ} é um conjunto de coleções de dados.
Em simulações computacionais, conjuntos de dados contêm os dados científicos comumente extraídos de arquivos produzidos pelos programas de simulação. Além disso, o termo coleção de dados é especificado formalmente na Subseção 2.2.5.
2.2.4 Atributo de dados
Um atributo de dados é especificado da seguinte forma:
da = (nome, tipo) ∴ tipo ∈ {inteiro, ponto flutuante, texto, arquivo, booleano} O nome do atributo de dados é um identificador que deve ser único em um mesmo conjunto de dados. O tipo do atributo provê um significado semântico ao mesmo. O exemplo daTabela 2.1 ilustra essa definição.
Nome do atributo Tipo do atributo
Nome texto
Idade inteiro
Altura (m) ponto flutuante
Tabela 2.1: Exemplo de conjunto de dados de usuários com seus respectivos
atri-butos.
2.2.5 Coleção de dados
Uma coleção de dados, também chamada de conjunto de elementos de dados, é definida como
dc = {de1, de2, . . . , deη} onde cada de é um elemento de dados.
2.2.6 Elemento de dados
Um elemento de dados é definido como
de = {v1, v2, . . . , vθ} ∴ #(ds.A) = #(de)
onde o i-ésimo v é o valor do i-ésimo atributo de dados da de um conjunto de dados ds. #(ds.A) representa a cardinalidade do conjunto de atributos A, i.e., a quantidade de atributos presentes no mesmo conjunto de dados ds. Note que a
quantidade de atributos do conjunto de dados ds deve ser igual à quantidade de valores presentes no elemento de dados de.
Para exemplificar a relação entre coleção de dados e elemento de dados, considere aTabela 2.2.
Nome Idade Altura (m)
de1 Alice 22 1, 77 ) dc1 de2 Bob 25 1, 79 de3 Charlie 42 1, 85 o dc2
Tabela 2.2: Relação entre coleção de dados e elemento de dados. Estes elementos
de dados são instâncias do conjunto de dados de usuários daTabela 2.1. Cada linha numerada da tabela é um elemento de dados; e existem duas coleções de dados: dc1 = {de1, de2}e dc2 = {de3}.
2.2.7 Dependência de dados
Uma especificação de dependência de dados φ é dada por
φ = (ds, dtprevious, dtnext) onde:
• ds é um conjunto de dados;
• dtprevious é uma transformação de dados que produz coleções de dados para o
conjunto de dados ds; e
• dtnext é uma transformação de dados que consome coleções de dados do
con-junto de dados ds.
2.2.8 Um exemplo
Para ilustrar as definições e especificações da Seção 2.2, vamos utilizar uma pe-quena amostra de um fluxo de dados real em dinâmica de fluidos computacionais. Na Figura 2.2 podemos ver o DAG correspondente a esse fluxo de dados D: ele contém duas transformações de dados, inputmesh e createequationsystems, e três conjuntos de dados, iinputmesh, oinputmesh e ocreateequationsystems, assim como três dependências de dados. Eis a especificação de D:
Figura 2.2: Exemplo de especificação de fluxo de dados, com duas transformações
de dados e três conjuntos de dados.
D = (T, S, Φ)
S = {iinputmesh, oinputmesh, ocreateequationsystems} T = {inputmesh, outputmesh}
Φ=
{(∅, iinputmesh, inputmesh),
(inputmesh, oinputmesh, createequationsystems), (createequationsystems, ocreateequationsystems, ∅)}
Observação: o símbolo ∅ denota nulo, indicando que uma das transformações
de dados correspondente à dependência de dados não existe.
Além disso, podemos ver alguns dos atributos de dados do conjunto de dados iinputmesh na Tabela 2.3, assim como alguns de seus valores na Tabela 2.4. Cada uma das linhas daTabela 2.4 corresponde a um elemento de dados diferente, e todo o conjunto desses elementos de dados compõe toda a coleção de dados do conjunto de dados.
Nome do atributo Tipo do atributo id inteiro mesh_file arquivo dim inteiro simulationid inteiro restart_control booleano
Tabela 2.3: Alguns dos atributos de dados do conjunto de dados iinputmesh. id mesh_file dim simulationid restart_control
1 /sedimentation/necker3d-1.msh 3 1 falso
2 /sedimentation/necker3d-2.msh 3 2 verdadeiro
Tabela 2.4: Alguns dos valores dos atributos de dados de iinputmesh.
2.3 Dados de proveniência
2.3.1 Definição
O dicionário Aulete Digital [14] define proveniência como “lugar de onde alguém ou alguma coisa provém; origem; fonte”. Em simulações computacionais, a proveniência nos ajuda a interpretar e entender resultados. Através da examinação e da cadeia de passos que criaram um certo resultado, nós podemos: (i) verificar que o experimento foi realizado de acordo com os procedimentos aceitáveis; (ii) inspecionar as suas entradas; e, em alguns casos, (iii) reproduzir os mesmos resultados [15].
Questões básicas sobre dados científicos podem ser respondidas por meio do conhecimento e da introspecção de sua proveniência, tais como
1. quem criou o dado, e quando foi essa criação?
2. quem modificou o dado, e quando essa modificação ocorreu? 3. que processo criou o dado?
4. que outros dados foram produzidos a partir dos dados originais?
Um dos componentes mais importantes que podemos obter com proveniência são suas informações sobre causalidade, isto é, a relação de dados de entrada que, associados a um processo, levam a um determinado conjunto de dados de saída [15]. A causalidade pode ser representada através de fluxos de dados e de grafos — onde os nós correspondem a processos e arestas correspondem a dados científicos —, como no exemplo daSubseção 2.2.8.
Um segundo exemplo relevante de componente de proveniência são as infor-mações definidas e providas pelo usuário, as quais não podem ser capturadas au-tomaticamente [15]. Esse tipo de informação é usualmente provido em níveis de granularidade arbitrários através de anotações e observações do usuário.
2.3.2 Categorias de dados de proveniência
Existem dois tipos de dados de proveniência envolvidos na gerência de fluxo de dados: prospectiva e retrospectiva [15,16]:
• A proveniência prospectiva contempla a especificação e a estrutura de uma tarefa computacional — por exemplo, um script, ou um programa de simu-lação — e associa a ela os passos que precisam ser seguidos para gerar um conjunto de dados. Ela corresponde à definição de um fluxo de dados e ao seu grafo, transformações de dados e dados científicos relacionados. Assim, a pro-veniência prospectiva é uma descrição do próprio processo computacional [17]. • Por outro lado, a proveniência retrospectiva captura não apenas os pas-sos executados de uma tarefa computacional, mas também informações rela-cionadas ao ambiente e tempo de execução da mesma - por exemplo, quais parâmetros foram passados aos programas, qual processo (PID) do sistema operacional foi executado, por quem o PID foi executado, qual foi a duração total (incluindo seus instantes de início e de fim) do mesmo, ou quais variáveis de ambiente do sistema operacional estavam definidas. Sua estrutura do grafos respeita à especificação provida pela proveniência prospectiva.
Por meio dos dois tipos citados de dados de proveniência, um sistema de fluxo de dados é capaz de orquestrar e prover diferentes níveis de abstração para a execução de uma simulação científica [16], os quais são inexistentes em programas de simulação, tais como scripts. Como iniciativas para a gerência de dados de proveniência, pode-se citar o NoWorkflow [16], o YesWorkflow [17], o DfAnalyzer [6] e a biblioteca Tigres [18].
Ademais, a captura de dados de proveniência pode ser realizada de duas formas distintas, offline e online [11]. A captura offline consiste em armazenar os dados de uma simulação computacional em um determinado repositório logo após a execução da mesma — por exemplo, como realizado pelo Kepler [7]. Em contrapartida, a captura online consiste na obtenção e no armazenamento de dados em tempo de
execução, como realizado no Pegasus [8] e no Swift/T [19].
Uma simples observação é que o desempenho da captura de proveniência on-line tende a ser ligeiramente pior do que a offon-line, devido à possível sobrecarga do armazenamento de dados de proveniência concorrentemente ao processamento dos programas de simulação. Em outra perspectiva, vale enfatizar que a captura online é mais flexível e tem um potencial analítico maior, pois permite que os usuários realizem consultas mesmo antes do término da simulação, o que possui um valor inestimável, uma vez que simulações computacionais são comumente realizadas em larga escala e, portanto, custosas e demoradas.
Exemplo com dados de proveniência
Para ilustrar a diferença entre os dois tipos de dados de proveniência apresenta-dos, considere o clássico exemplo de contagem de palavras2 (word count), no qual
o conjunto de dados inicial é um arquivo de texto em ASCII. A primeira tarefa de processamento é a leitura e subsequente análise do arquivo de texto a fim de extrair palavras do mesmo. A segunda etapa é realizar a contagem das palavras a partir da lista de palavras obtida no passo anterior. Finalmente, o último passo de processa-mento é ordenar em ordem descrescente a frequência de palavras obtidas no passo anterior.
A proveniência prospectiva desse experimento poderia ser representada através do grafo da Figura 2.3. Por outro lado, a proveniência retrospectiva do último passo (ordenação) poderia ter capturado em tempo de execução algumas das infor-mações presentes na Tabela 2.5. Sendo assim, dependendo das análises desejadas pelos usuários de domínio, a proveniência prospectiva não é suficiente. Além disso, no contexto da análise exploratória de arquivos de dados científicos, os usuários estão comumente interessados em dados de proveniência retrospectiva. Mais es-pecificamente, eles necessitam investigar dados de domínio presentes nos arquivos produzidos pelos programas de simulação.
Figura 2.3: Proveniência prospectiva do exemplo de contagem de palavras.
Timestamp de início 2017-06-25 03:11:05.231 Timestamp de fim 2017-06-25 03:11:09.586
PID 4671
Linha de comando ./sort --order=desc --in=freq-list.csv Variáveis de ambiente PWD=/home/tperrotta;PATH=/usr/bin:/bin
Usuário tperrotta
Tabela 2.5: Proveniência retrospectiva do exemplo de contagem de palavras da
etapa de ordenação decrescente.
2.4 Rastreamento de dados de proveniência
As soluções precisam ser capazes de rastrear e monitorar o fluxo de dados que são consumidos e produzidos por cada transformação de dados (programa de simulação) durante a sua execução. Nesse contexto, dois níveis de abstração existem para tratar a gerência do fluxo de dados: o físico e o lógico [11].
2.4.1 Gerência do fluxo de dados no nível físico
A gerência do fluxo de dados no nível físico, ou rastreamento físico de
dados de proveniência, consiste no apoio às transformações de dados no nível do
sistema de arquivos, i.e., rastreando o fluxo de arquivos. Nessa abordagem, é neces-sário etiquetar cada arquivo com um identificador único, como uma URL (Uniform Resource Locator), dentro do mesmo conjunto de dados [11]. Esse tipo de proveni-ência captura muitos detalhes, os quais podem ser úteis na depuração de simulações computacionais devido à sua gerência dos arquivos consumidos e produzidos por cada transformação de dados [5].
Nesse contexto, as transformações de dados são analisadas apenas no que tange o consumo e a produção de arquivos (e elementos de dados) por cada programa científico, sem considerar dados de domínio da simulação. Assim, essas transforma-ções de dados são análogas a caixas-pretas (do inglês, black box) [5], já não proveem índices ou qualquer tipo de suporte à consulta em termos do conteúdo de domí-nio da simulação. Desse modo, os usuários limitam-se apenas a ponteiros para os elementos de dados nos arquivos envolvidos no fluxo de dados, requerendo-se que os mesmos façam análises individuais de cada arquivo para poder extrair algum significado semântico deles [11].
2.4.2 Gerência do fluxo de dados no nível lógico
Em contrapartida, a gerência do fluxo de dados no nível lógico, ou
rastrea-mento lógico de dados de proveniência, consiste no monitorarastrea-mento de como
os elementos de dados são consumidos e produzidos pelas transformações de dados e programas científicos. Tais elementos de dados apresentam o conteúdo de arqui-vos de dados científicos e, a partir da sua gerência, os seus relacionamentos podem ser utilizados para a reconstrução do fluxo de dados. Dessa maneira, menos da-dos precisam ser armazenada-dos, já que um fluxo de dada-dos costuma ter bem menos transformações de dados do que elementos de dados [11] (nível de granularidade grosso).
No que diz respeito aos usuários, consultas podem ser realizadas de forma di-recionada aos aspectos do domínio da simulação computacional, sem a necessidade
de se fazer uma etapa de análise prévia (diferentemente da gerência no nível físico). Além disso, o rastreamento lógico de dados pode ser automaticamente derivado das especificações das transformações de dados, uma vez que elas já apresentam propri-edades sobre conjuntos de dados consumidos e produzidos [5, 20]. Por outro lado, vale destacar que o custo computacional é maior para a gerência de dados no nível lógico do que no físico, uma vez que nesse tipo de gerência os elementos de dados precisam ser capturados e monitorados em tempo de execução, enquanto que no nível físico esse monitoramento resume-se à utilização de ponteiros de arquivos para os dados científicos, antes mesmo da execução.
2.4.3 Mapeamento de atributos
A seguinte definição foi extraída, traduzida e adaptada de [20]:
Definição(mapeamento de atributo): seja dt uma transformação de dados
com um conjunto de dados de entrada I e um conjunto de dados de saída O. Assume-se também que A é um atributo de I e B é um atributo de O. Diz-Assume-se que dt tem um mapeamento de atributo entre o atributo de entrada I.A e o atributo de saída O.B, denotado por I.A ↔ O.B, se todos os possíveis valores de x ∈ domínio(B) e todas as possíveis instâncias do conjunto de entrada I0 satisfazem
σB=x(T (I0)) = σB=x(T (σA=x(I0)))
Em outras palavras, e de forma simplificada, existe um mapeamento de atributos entre A e B quando:
1. A faz parte de um conjunto de dados de entrada de uma transformação dt, e B faz parte de um conjunto de dados de saída de dt, ou vice-versa;
2. A e B possuem o mesmo tipo; e 3. A e B possuem o mesmo nome.
Por exemplo, considere que temos um conjunto de dados ds1 com dois atributos
x e y do tipo ponto flutuante, representando as coordenadas de um plano, e uma transformação dt que dobra os valores de cada uma dessas coordenadas e é aplicada a ds1, produzindo ds2. Nesse cenário, existem dois mapeamentos de atributos:
Capítulo 3
Análise de soluções para consultas
a dados científicos
Dado que o principal objetivo desta monografia consiste no desenvolvimento de um pré-processador de consultas integrado à arquitetura ARMFUL, abordada no
Capítulo 4, este capítulo aborda alguns trabalhos e publicações relacionados a ela, no que diz respeito às simulações computacionais, aos workflows científicos, aos dados de proveniência e, em especial, aos tipos de consulta que podem ser realizados.
3.1 Tipos de consulta
Conforme introduzimos na Seção 1.2, existem três tipos básicos de consultas que podem ser realizados em uma base de dados de proveniência de uma simulação computacional no cenário de análise exploratória de dados científicos [1, 11]:
1. análise de dados científicos isolados de um único arquivo, envolvendo a extra-ção de conteúdos específicos de domínio, que é abordada na Seção 3.2;
2. rastreamento de fluxos de múltiplos arquivos relacionados através de transfor-mações de dados correspondentes, discutido na Seção 3.3; e
3. rastreamento de elementos de dados relacionados em múltiplos arquivos, que será elucidado na Seção 3.4.
As consultas do Tipo 1 requerem apenas acesso a um único arquivo, enquanto consultas do Tipo 2 e do Tipo 3 necessitam da gerência do fluxo de dados da simulação computacional [1].
3.2 Análise de dados científicos isolados
Consultas do Tipo 1 são caracterizadas pela análise de dados científicos, encon-trados em arquivos que foram produzidos por um programa de simulação, e envolve tipicamente a extração (do inglês: parsing) ou interpretação desses dados de formatos de arquivos que seguem um padrão de acordo com domínio da simulação computacional. Nesse sentido, é necessário conhecer a estrutura e / ou a codificação utilizada nesses arquivos para que seja possível acessá-los e extrair um significado dos dados do mesmo. Além disso, cada formato de arquivo possui programas es-pecíficos para a sua análise e extração. Por exemplo, um arquivo em formato de imagem tal como o PNG (Portable Network Graphics) pode ser analisado (visuali-zado) por um editor de imagens, enquanto que um arquivo em formato de música tal como o WAV (Waveform Audio File Format) pode ser analisado (reproduzido) por um player de áudio. Em particular, destaca-se que a semântica da análise — reprodução, visualização, extração, etc. — é inerente ao tipo de arquivo analisado.
Esses dados e seus respectivos arquivos podem estar ou não em formato binário; por exemplo, um arquivo em formato JSON (JavaScript Object Notation) geralmente contém dados em formato de texto; enquanto que um arquivo FITS (Flexible Image Transport System) [2], utilizado em astronomia, pode possuir parte de seus dados em formato binário, assim como o NetCDF (Network Common Data Form) [4], utilizado em dinâmica de fluidos computacionais, e o HDF5 [3], utilizado em várias aplicações distintas.
Para apoiar a extração de dados científicos, alguns trabalhos têm utilizado téc-nicas de indexação de dados científicos no conteúdo de arquivos e carregado tais dados em repositórios externos (arquivos com índices e dados no formato binário para proporcionar um acesso eficiente) ou uma base de dados, como o NoDB [21], RAW [22], FastBit [23], FastQuery [24] e SDS/Q [25].
Logo, as consultas do Tipo 1 são as mais simples de serem realizadas em relação às outras, pois elas são auto-contidas no que diz respeito aos dados científicos, isto é, apenas a presença desses dados é suficiente para que esse tipo de consulta possa ser realizado: não é necessária a especificação sobre o fluxo de dados da simulação computacional.
3.3 Análise do fluxo de arquivos
Consultas do Tipo 2 são caracterizadas pelo rastro do fluxo de arquivos, que se relacionam através de transformações de dados. Elas são frequentemente apoia-das por sistemas de workflows científicos, tais como o Chiron [13], o Pegasus [8] e o Kepler [7]. Através desse tipo de consulta, que busca informações de proveniência
re-trospectiva, os usuários são capazes de rastrear, em uma míriade de arquivos de uma simulação computacional em larga escala, qual foi o fluxo de arquivos que gerou de-terminados conjuntos de dados finais a partir de quais conjuntos de dados científicos iniciais. Todos os trabalhos relacionados na3.2 apresentam um pré-processador de consultas limitado ao conteúdo de arquivos de forma isolada, ou seja, não permitem relacionar dados de múltiplos arquivos de dados científicos.
Um exemplo de ferramenta que é capaz de realizar consultas do Tipo 2 é o NoWorkflow [16] (do inglês: not only workflow), que captura de forma transpa-rente a proveniência de scripts escritos na linguagem de programação Python. Essa captura é feita a nível de funções (subrotinas) da linguagem e, em particular, cha-madas de sistema do tipo open (=abertura de arquivos) presentes nos scripts são capturadas, assim como os arquivos que lhe são passados como argumentos, que então são armazenados em um banco de dados relacional que identifica as relações (de entrada e de saída) entre esses arquivos. Dessa maneira, o NoWorkflow possui toda a informação de proveniência retrospectiva [26] necessária para possibilitar a consulta do fluxo dos arquivos lidos e escritos durante a execução dos scripts1.
Outra ferramenta que suporta consultas do Tipo 2 é o YesWorkflow [17], que permite que os usuários façam anotações na forma de comentários especiais em seus scripts e subsequentemente extrai e analisa esses comentários, representando os scripts na forma de entidades e relações entre elas, formando e definindo um fluxo de dados. O YesWorkflow pode ser utilizado em qualquer script, não se limitando somente a Python, diferentemente do NoWorkflow. Em contrapartida, requer ano-tações explícitas da parte do usuário, não sendo capaz de extrair informações de proveniência automaticamente como o NoWorkflow [26]. Os comentários etiquetam regiões arbitrárias dos scripts, associando valores a elas, os quais podem correlacio-nar e fazer associações a outras regiões. Desse modo, um conjunto de comentários é capaz de especificar o fluxo de arquivos do fluxo de dados.
Citamos mais um exemplo de ferramenta que é capaz de realizar consultas do
Tipo 2, o Tigres [18], que é inspirado no paradigma MapReduce e suporta a criação de fluxos de dados sequenciais e paralelos. O Tigres é utilizado através de uma API (do inglês, Application Programming Interface) de templates escrita em Python, com a qual o usuário define elementos do fluxo de dados e monitora a execução de programas científicos. Esses templates funcionam como blocos de construção, que executam tarefas sequencialmente e geram informações de dependência e de proveniência entre os mesmos, tanto a nível prospectivo quanto a nível retrospectivo.
1Nesse contexto, um script é análogo a um conjunto de transformações de dados, representando
3.4 Análise do fluxo de elementos de dados em
múltiplos arquivos
Consultas do Tipo 3 envolvem o rastreamento de elementos de dados
relaci-onados em múltiplos arquivos. Nesse sentido, são uma extensão das consultas
do Tipo 2, uma vez que é necessária uma granularidade mais fina para gerenciar o fluxo de dados, no nível de elementos de dados, e não apenas no nível do fluxo de arquivos.
O estado da arte no que diz respeito às soluções para a análise de dados científicos em simulações científicas concentra-se hoje no apoio a consultas do Tipo 1 [3,11,21– 23] e do Tipo 2 [16–18,26], como vimos em alguns exemplos nas seções anteriores. No entanto, algumas soluções para consultas do Tipo 3 foram apresentadas nos últimos anos e vêm se consolidando recentemente.
Por exemplo, o NoWorkflow, mencionado na Seção 3.3, também possui suporte a consultas do Tipo 3, permitindo o rastreamento de elementos de dados em nível de variáveis, de funções e de classes em scripts, porém ele se limita somente a scripts escritos na linguagem Python [16]. Além dele, a biblioteca Tigres também permite a gerência dos elementos de dados ao relacionar os valores de atributos consumidos e produzidos por cada tarefa computacional.
Outro paradigma que suporta consultas do Tipo 3 é o da arquitetura ARM-FUL, que é baseada em componentes e é instanciada, por exemplo, como o DfA-nalyzer em [5]. Como esta monografia concentra-se no desenvolvimento de um pré-processador de consultas no DfAnalyzer, essa ferramenta é abordada detalhadamente noCapítulo 4.
Capítulo 4
Arquitetura ARMFUL
Neste capítulo é apresentada a arquitetura ARMFUL (do inglês: Analysis of Raw Data from Multiple Files; em tradução livre: Análise de Dados Científicos de Múlti-plos Arquivos), introduzida recentemente em [5, 6] pelo Núcleo Avançado de Com-putação de Alto Desempenho (NACAD) da UFRJ (Universidade Federal do Rio de Janeiro). Este capítulo também aborda o DfAnalyzer, uma instância dessa arquite-tura, implementada pelo mesmo laboratório.
4.1 Visão geral
A arquitetura ARMFUL tem suporte à extração de dados científicos, às técnicas de indexação e à análise de dados científicos a partir de múltiplos arquivos [6] com o propósito de permitir o acesso direto a qualquer elemento ou região específica do es-paço do fluxo de dados de uma simulação científica. Em outras palavras, ela permite a execução, off-line e / ou on-line1, de todos os três tipos de consultas apresentadas
na Seção 3.1. Essa flexibilidade e versatilidade na análise existe graças a uma
ar-quitetura de componentes, que utiliza um banco de dados de proveniência para
proporcionar um caminho de acesso entre o fluxo de dados e os dados científicos [5]. A arquitetura ARMFUL funciona do seguinte modo: a gerência de conteúdos científicos é obtida a partir de dados científicos de arquivos. Tais dados são então correlacionados em um repositório que é um SGBD relacional, através de dados de proveniência do seu respectivo fluxo de dados. Essa gerência de dados requer características que são específicas do domínio da simulação científica; por isso, mo-delos de dados de proveniência dessas simulações costumam ser representados em granularidade não-fina, i.e., as tabelas do SGBD possuem um nível de abstração relativamente alto para representar esses dados. Entretanto, consultas de proveni-ência possuem um valor analítico limitado caso não sejam relacionadas a elementos
1I.e., as consultas podem ser realizadas tanto após as simulações científicas, quanto durante as
de dados específicos ao domínio da simulação computacional; contudo, esse relacio-namento exige bastante esforço dos usuários no que diz respeito a desenvolver, para cada domínio, um modelo de dados e programas científicos específicos para acessar, extrair e correlacionar os dados de domínio aos dados de proveniência. Nesse aspecto, a arquitetura ARMFUL contribui diminuindo o esforço necessário para capturar e representar esses dados de proveniência aravés da introdução e divisão de compo-nentes genéricos e auto-contidos que modelam e correlacionam entre si, no mesmo banco de dados, (i) dados científicos específicos do domínio e (ii) proveniência.
Na Figura 4.1, podemos visualizar como é feita a representação e a divisão em componentes da arquitetura ARMFUL, que são os seguintes:
• Banco de dados de proveniência; • Extração de dados científicos; • Indexação de dados científicos; • Ingestão de dados de proveniência; e • Processamento de consultas.
Figura 4.1: Componentes da arquitetura ARMFUL. A cor branca representa as
etapas relacionadas aos dados de proveniência, e a cor cinza tem relação com os dados científicos. Baseada em [5].
Os componentes na cor branca correspondem à captura e ao armazenamento de dados de proveniência em um banco de dados de proveniência. Em contrapartida, os componentes na cor cinza descrevem os passos responsáveis por: (i) extrair dados científicos de arquivos, (ii) gerar índices para os mesmos e (iii) permitir a consulta de proveniência e dados científicos a partir do mesmo banco de dados. Nas próximas subseções os componentes serão detalhados.
4.1.1 Banco de dados de proveniência
O banco de dados de proveniência, que funciona como um repositório para os dados de proveniência, deve ser um SGBD relacional, e é responsável por arma-zenar, gerenciar e correlacionar (i) dados de proveniências e (ii) dados científicos, a fim de se beneficiar do suporte analítico de consultas do fluxo de dados. Além disso, SGBDs possuem solidez, confiabilidade e segurança, oriundas de uma experi-ência de mais de 30 anos de estudos científicos e aplicações no mundo real, provendo estratégias e algoritmos bem conhecidos que garantem atomicidade, consistência, isolamento e durabilidade (ACID) em transações, além de possuir soluções consoli-dadas e robustas no que diz respeito a recuperação de dados e controle concorrente de acesso [27].
4.1.2 Extração e indexação de dados científicos
O componente de extração de dados científicos tem o objetivo de ler o con-teúdo de arquivos científicos, analisá-lo e então recuperar parte do concon-teúdo seleci-onado que é relevante de acordo com os atributos especificados pelo usuário. Para que esse objetivo seja completado, quatro etapas devem ser seguidas:
• leitura do conteúdo: acesso aos arquivos científicos e leitura do seu con-teúdo;
• tokenização: investigação de metadados relacionados à especificação do for-mato de arquivo, visando verificar se os dados científicos obtidos na etapa anterior correspondem ao domínio da simulação computacional processada atualmente;
• filtragem de conteúdo: a especificação do usuário é responsável por definir e restringir o que deve ser analisado e armazenado no banco de dados de proveniência, isto é, essa etapa evita armazenar atributos desnecessários, que não serão utilizados na próxima etapa;
• análise: conversão de cada dado científico filtrado em uma estrutura de dados apropriada para ser armazenada no SGBD.
O componente de indexação de dados científicos é opcional e visa indexar um conteúdo específico dos arquivos científicos a fim de agilizar o tempo de acesso direto a determinadas regiões do espaço de dados científicos através da gerência de metadados correlacionados ao fluxo de dados. A criação de índices é realizada segundo um algoritmo de indexação previamente definido, e.g. indexação por bitmap ou indexação posicional.
O volume de dados científicos que é gerado durante a execução de uma simulação computacional é um fator determinante para a definição da melhor estratégia para a representação desses dados [11]: em simulações que geram um pequeno volume de dados em cada transformação de dados e que possuem poucos atributos, a extração e ingestão (i.e., carga no banco de dados de proveniência) de dados científicos di-retamente com seus próprios valores de dados costuma ser uma abordagem melhor. Em contrapartida, em um cenário no qual um grande volume de dados — com es-truturas de dados complexas — precisa ser capturado, o componente de indexação é fortemente recomendado.
4.1.3 Ingestão de dados
O componente de ingestão de dados é responsável por coletar a proveniência do fluxo de dados, selecionando, manipulando e armazenando (i.e. realizando a carga dos valores assumidos pelos atributos) convenientemente as informações referentes aos arquivos e dados científicos no banco de dados mencionado naSubseção 4.1.1[11]. Em outras palavras, esse componente é responsável por alimentar e popular o SGBD com informações de dados de proveniência que serão posteriormente utilizadas para auxiliar o componente de processamento de consultas, que será discutido na próxima seção. Esse componente interfaceia diretamente com todo item do fluxo de dados.
A captura de dados de proveniência deve ser realizada com uma granularidade fina, de modo a apoiar e capturar os dois tipos de análises exploratórias em arqui-vos de dados científicos mencionadas na Subseção 2.3.2 (proveniência prospectiva e retrospectiva). Além disso, também deve realizar a gerência do fluxo de dados nos níveis físico e lógico.
4.1.4 Processamento de consultas
Uma vez que todos os dados científicos e toda a proveniência sejam devidamente cap-turadas e armazenadas em um SGBD, os usuários poderão consultá-los para apoiar (refutar ou validar) suas hipóteses científicas [11]. Nesse contexto, o componente
de processamento de consultas é responsável por prover um mecanismo de
con-sultas à proveniência e aos dados científicos armazenados em um banco de dados de proveniência compatível com um modelo de dados adequado. O comportamento desse componente é variável, dependendo da estratégia utilizada nos componentes anteriores — de extração e de indexação. As consultas são especificadas em uma linguagem de alto nível, como a linguagem declarativa SQL.
O pré-processador de consultas é um componente bastante importante, já que é a principal interface entre os usuários e uma instância da arquitetura ARMFUL, e todas as consultas ao banco de dados são iniciadas (e especificadas) a partir dele.
4.2 DfAnalyzer: uma instância da arquitetura
ARMFUL
4.2.1 Visão Geral
Como vimos na seção anterior, a arquitetura ARMFUL é uma abstração que define e especifica componentes a fim de prover um mecanismo capaz de realizar consultas a um banco de dados, cujos dados de proveniência, execução e domínio foram oriun-dos de uma simulação computacional. Dito isso, o DfAnalyzer é uma instância
da arquitetura ARMFUL; em outras palavras, ele consiste em uma
implemen-tação dessa arquitetura. Ele foi originalmente introduzido em [6]. Os principais componentes do DfAnalyzer são abordados nas próximas subseções.
4.2.2 Provenance Data Gatherer (PDG)
O Provenance Data Gatherer (PDG) é o componente do DfAnalyzer responsável por capturar dados de proveniência (c.f. Subseção 4.1.3) assim como dados específicos do domínio a partir do código-fonte da aplicação, gerando um arquivo JSON com o conteúdo extraído e as suas respectivas dependências de dados [6]. Após a captura, a proveniência e os dados de domínio são carregados em um banco de dados que é um esquema pré-definido e que é gerenciado pelo SGBD MonetDB [28], que consiste em um banco de dados orientado a colunas compatível com a linguagem SQL.
O motivo do MonetDB ter sido escolhido como o SGBD para a gerência e o arma-zenamento dos dados de proveniência deve-se principalmente ao fato do mesmo ser orientado e otimizado para a consulta de dados através de colunas — diferentemente da maioria dos SGBDs tradicionais, como o MySQL e o SQLite, que são orienta-dos a linhas. Isso é importante pois, em geral, o principal interesse nas consultas das simulações computacionais consiste na obtenção de apenas um subconjunto dos atributos presentes. Além disso, o MonetDB trata suas cláusulas de indexação de forma peculiar e dinâmica: diferentemente de SGBDs tradicionais, essas cláusulas são postergadas, interpretadas meramente como hints, sendo o MonetDB o respon-sável por tomar as decisões finais de manutenção e de criação de índices, visando assim acelerar o posterior acesso aos dados [29].
4.2.3 Raw Data Extractor (RDE)
Uma vez que o PDG especializa-se em coletar proveniência e dados de domínio, o
Raw Data Extractor (RDE) o complementa, sendo o componente responsável por extrair os dados científicos que estão presentes em arquivos científicos (c.f.
Sub-seção 4.1.2). Esses arquivos usualmente mantêm seus dados em formato binário, total ou parcialmente, sendo responsabilidade do RDE a leitura, filtragem e aná-lise do conteúdo desses dados, transformando-os em um formato adequado para ser armazenado nos tipos e tabelas disponíveis no MonetDB. Dependendo da aplica-ção e da simulaaplica-ção científica, o conteúdo desses arquivos científicos pode ser ora armazenado diretamente no SGBD, ora armazenado indiretamente, através de pon-teiros (referências de arquivos), ou estruturas de dados em formatos intermediários de representação.
4.2.4 Raw Data Indexer (RDI)
O Raw Data Indexer (RDI) é o componente do DfAnalyzer responsável por in-dexar dados científicos presentes em arquivos, com o objetivo de permitir o acesso eficiente aos dados durante a execução das consultas pelos usuários, diminuindo o tempo médio delas (c.f. Subseção 4.1.2). O RDI é comumente utilizado para indexar estruturas de dados mais complexas, como matrizes e malhas esparsas, para a carga de dados em uma base de dados. Outro fator para o uso de técnicas de indexação consiste na dificuldade de representar determinadas estruturadas de dados em um SGBD, por exemplo. Entretanto, este trabalho não contempla o uso do RDI nos experimentos realizados, nem requer uma descrição detalhada desse componente, pois a implementação de indexação de dados científicos não foi considerada para o desenvolvimento do pré-processador de consultas deste projeto de graduação.
4.2.5 Query Preprocessor (QPP)
Expressar consultas de proveniência na linguagem SQL é frequentemente incômodo e enfadonho no que diz respeito à construção e composição da consulta em si [30]. Além do mais, essas consultas costumam empregar extensivamente junções relacio-nais e subconsultas, recursos do SQL que estão além da complexidade que a maior parte dos usuários está disposta a aprender. Esse tipo de curva de aprendizado impacta negativamente na usabilidade de sistemas de bancos de dados, exigindo um nível de conhecimento profundo do esquema do SGBD que, aliado à complexidade da programação necessária para expressar consultas utilizando esses esquemas, torna inviável o uso do sistema como um todo.
Nesse cenário, o Query Preprocessor (QPP) é o componente responsável por auxiliar os usuários a submeterem consultas na linguagem SQL ao banco de dados de proveniência [6], realizar a validação dessas consultas — por exemplo, se a sintaxe e / ou se os nomes dos atributos de dados estão corretos — e então finalmente retornar e exibir os resultados das mesmas. Com potencial para facilitar a execução de consultas por novos usuários, sem a necessidade de que eles tenham que
aprender todos os aspectos da sintaxe da linguagem SQL, ou mesmo todos os dados de domínio e esquemas do SGBD que ele opera, uma nova forma simplificada de especificação e de descrição de consultas foi desenvolvida, a qual traduz e converte a consulta do usuário para SQL, e é essa conversão que é enviada ao MonetDB, o qual retorna os resultados para o usuário. Ao mesmo tempo, por meio dos mapeamentos de atributos discutidos no Capítulo 5 para gerenciar os rastros de proveniência, este trabalho permite o desenvolvimento de consultas em SQL, implementando as junções necessárias entre conjuntos de dados (ou tabelas no esquema da base de dados) de forma automática.
O QPP é capaz de realizar todos os três tipos de consultas mencionados anteri-ormente naSeção 3.1: (i) análise de dados científicos isolados de um único arquivo; (ii)rastreamento de fluxos de múltiplos arquivos relacionados; e (iii) rastreamento de elementos de dados relacionados e múltiplos arquivos. A principal contribuição deste trabalho encontra-se especificamente na implementação deste componente, a qual será detalhadamente discutida noCapítulo 5.
Capítulo 5
Abordagem para análise de rastros
de proveniência
Neste capítulo é apresentado o Pré-Processador de Consultas (QPP), juntamente com a sua implementação e seus algoritmos. Além disso, aborda-se a relação entre os diversos tipos de rastros de proveniência existentes e a influência da seleção de um desses tipos na execução do QPP.
Conforme abordado naSeção 2.4, o rastreamento de dados de proveniência em uma simulação computacional é realizado através do mapeamento de
atribu-tos de dados dos conjunatribu-tos de dados. Reitera-se a definição de mapeamento de
atributos da Subseção 2.4.3, destacando que diz-se que existe um mapeamento de atributos entre dois atributos de dados da1 de um conjunto de dados ds1 e da2 de
um conjunto de dados ds2, desde que ambos os atributos apresentem (i) o mesmo
identificador (nome) e (ii) o mesmo tipo, e desde que (iii) ds1 e ds2 sejam adjacentes
no mesmo fluxo de dados, i.e., eles devem possuir uma transformação de dados em comum, sendo um deles a entrada e o outro a saída da mesma.
5.1 Tipos de rastros de proveniência
A fim de ilustrar as definições das próximas subseções, considere o fluxo de dados D∗da Figura 5.1, cujos atributos de dados A∗ estão listados naTabela 5.1.
Conjunto de dados Nome do atributo Tipo do atributo ds1 da1 inteiro ds1 da2 booleano ds1 taskid_dt1 inteiro ds2 da1 inteiro ds2 da2 inteiro ds2 taskid_dt1 inteiro
Tabela 5.1: Atributos de dados A∗ do fluxo de dados D∗ da Figura 5.1.
5.1.1 Físico
O mapeamento de atributos de dados do tipo físico ocorre somente entre pares de atributos de dados (de conjuntos de dados) especiais, que fazem parte de uma mesma tarefa (execução de uma transformação de dados) de uma mesma instância da simulação computacional, sendo denotadas por um identificador cujo nome é da forma taskid_∗, onde ∗ representa um número arbitrário (i.e., um ou mais) de caracteres. O tipo desse atributo necessariamente deve ser um inteiro positivo. O propósito desse atributo é agrupar elementos de dados que foram processados em uma mesma instância de execução / tarefa de uma simulação computacional. No exemplo desta seção, o mapeamento físico dos atributos de D∗ existe somente entre o par de atributos de dados ds1.taskid_dt1 e ds2.taskid_dt1, pois esses são os únicos
atributos do tipo taskid presentes em D∗.
5.1.2 Lógico
O mapeamento de atributos de dados do tipo lógico ocorre entre os atributos de
domínio dos conjuntos de dados de uma simulação científica. Esses atributos de
domínio necessariamente não podem denotar o tipo taskid mencionado na subseção anterior. Sendo assim, o mapeamento lógico permite que as junções, regularmente realizadas pelos usuários ao desenvolver suas consultas, sejam expressas pelos mape-amentos lógicos de atributos. Consequentemente, assim como o mapeamento físico, o mapeamento lógico também pode reduzir o esforço necessário por parte do usuário ao desenvolver suas consultas, já que os principais relacionamentos entre conjuntos de dados poderiam ser expressados pelos mapeamentos de atributos.
No exemplo desta seção, o mapeamento lógico dos atributos de D∗ existe somente entre o par de atributos de dados ds1.da1 e ds2.da1. Note que não existe
mapea-mento lógico entre ds1.da2 e ds2.da2 pois, apesar de possuírem o mesmo nome, esses
atributos de dados possuem tipos de dados diferentes (inteiro e booleano). Além disso, o atributo taskid_dt1 não foi considerado por ser específico do mapeamento físico.
