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 simulaçã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 conjuntos 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.
5.1.3 Híbrido
Existe também cenários em que o usuário precise considerar os mapeamentos de atributos físico e lógico. Nesse cenário, o mapeamento de atributos de dados do
tipo híbrido consiste na combinação — ou, mais precisamente, na união — de
ambos os tipos de mapeamentos de atributos anteriores: o físico e o lógico.
Sendo assim, por meio da definição desses três tipos de mapeamentos de atribu- tos, o usuário poderia especificar que tipos de relacionamentos são importantes de serem expressos / considerados ao realizar análises nos resultados obtidos em simu- lações computacionais. Esses relacionamentos, por exemplo, poderiam ser conside- rados ao longo de toda a simulação computacional (entre todos os relacionamentos entre transformações de dados) ou em determinadas transformações de dados.
Assim, no exemplo desta seção, esse mapeamento envolve os seguintes atributos: • ds1.da1 e ds2.da1 (lógico); e
• ds1.taskid_dt1 e ds2.taskid_dt1 (físico).