UMA INTERFACE PARA A ANÁLISE DE FLUXO DE DADOS EM SIMULAÇÕES COMPUTACIONAIS INTENSIVAS EM DADOS. Débora Barbosa Pina

(1)

UMA INTERFACE PARA A AN ÁLISE DE FLUXO DE DADOS EM SIMULAÇ ÕES COMPUTACIONAIS INTENSIVAS EM DADOS

D´ebora Barbosa Pina

Projeto de Gradua¸cão apresentado ao Curso de Engenharia de Computa¸cão e Informa¸cão da Escola Politécnica da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para a obten¸cão do grau de Engenheiro de Computa¸cão e Informa¸cão.

Orientadores: Marta Lima de Queir´os Mattoso V´ıtor Silva Sousa

Rio de Janeiro Mar¸co de 2018

(2)

UMA INTERFACE PARA A AN ÁLISE DE FLUXO DE DADOS EM SIMULAÇ ÕES COMPUTACIONAIS INTENSIVAS EM DADOS

D´ebora Barbosa Pina

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´os 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 MARC¸ O DE 2018

(3)

Barbosa Pina, D´ebora

Uma interface para a análise de fluxo de dados em simula¸cões computacionais intensivas em dados/Débora Barbosa Pina. – Rio de Janeiro: UFRJ/POLI – COPPE, 2018.

XI, 48 p.: il.; 29, 7cm.

Orientadores: Marta Lima de Queir´os Mattoso V´ıtor Silva Sousa

Projeto (gradua¸cão) – UFRJ/ Escola Politécnica/ Curso de Engenharia Computa¸cão e Informa¸cão, 2018.

Referˆencias Bibliogr´aficas: p. 45 – 48.

1. Análise de Dados Cient´ıficos. 2. Gerência de Fluxos de Dados. 3. Dados de Proveniência. 4. 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¸cão e Informa¸cão. III. T´ıtulo.

(4)

Agradecimentos

Agrade¸co à minha irmã e aos meus pais pelo amor incondicional, pela incansável luta para proporcionar a realiza¸cão dos meus sonhos e por estarem sempre ao meu lado em todas as fases.

Agrade¸co à professora Marta Mattoso e ao V´ıtor Silva, meus orientadores, pela oportunidade e assistência na elabora¸cão deste trabalho, além da orienta¸cão durante meu per´ıodo de Inicia¸cão Cient´ıfica na Universidade Federal do Rio de Janeiro.

Agrade¸co `a minha psic´ologa que soube me entender e dizer aquilo que eu preci-sava na reta final da universidade, quando tudo parecia mais dif´ıcil.

Por fim, agrade¸co aos amigos que estiveram ao meu lado nesta trajetória e que estão comigo nesta jornada que é a vida.

(5)

Resumo do Projeto de Gradua¸cão apresentado à Escola Politécnica/COPPE/UFRJ como parte dos requisitos necessários para a obten¸cão do grau de Engenheiro de Computa¸cão e Informa¸cão.

UMA INTERFACE PARA A AN ÁLISE DE FLUXO DE DADOS EM SIMULAÇ ÕES COMPUTACIONAIS INTENSIVAS EM DADOS

D´ebora Barbosa Pina

Mar¸co/2018 Orientadores: Marta Lima de Queir´os Mattoso

V´ıtor Silva Sousa

Curso: Engenharia de Computa¸c˜ao e Informa¸c˜ao

Simula¸cões computacionais são caracterizadas pelo consumo e produ¸cão de grande volume de dados, que são, geralmente, armazenados em arquivos em diferen-tes formatos, como FITS na astronomia. Com os avan¸cos da tecnologia, simula¸cões computacionais que antes levavam até meses para finalizar, agora são executadas em menos tempo quando usamos um ambiente de Processamento de Alto Desempenho (PAD). Para controlar a execu¸cão da simula¸cão, os usuários podem realizar análises sobre os dados cient´ıficos, rastreando grandezas que são de seu interesse. Porém, em muitos sistemas, esse rastreamento só é poss´ıvel após o fim da simula¸cão. Ademais, programas ad-hoc s˜ao desenvolvidos pelos usuários para extrair dados cient´ıficos de interesse presentes em arquivos. Portanto, para lidar com diferentes formatos de arquivo e para acessar o conteúdo de interesse armazenado nesses arquivos de dados cient´ıficos, sistemas têm sido desenvolvidos para auxiliar o usuário na extra¸cão e na análise de dados de proveniência e de dom´ınio, permitindo o rastreamento dos ele-mentos de dados cient´ıficos. Ainda assim, o usuário encontra dificuldade de realizar as suas análises nesses sistemas, pois elas exigem o conhecimento de linguagens de consultas espec´ıficas. Para apoiar a análise exploratória de dados cient´ıficos, esta monografia introduz uma interface gráfica para permitir a visualiza¸cão das especi-fica¸cões de fluxos de dados armazenadas anteriormente e o rastreamento do fluxo de dados por meio do processamento de consultas, sem a necessidade do usuário especificar as análises via sintaxe de linguagens de consulta.

Palavras-Chave: An´alise de Dados Cient´ıficos, Gerˆencia de Fluxos de Dados, Dados de Proveniˆencia, Bancos de Dados.

(6)

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.

AN INTERFACE FOR DATAFLOW ANALYSIS IN DATA-INTENSIVE COMPUTER SIMULATIONS

D´ebora Barbosa Pina

March/2018

Advisors: Marta Lima de Queir´os Mattoso V´ıtor Silva Sousa

Course: Computer and Information Engineering

Computer simulations are characterized by the consumption and production of large amounts of data, which are usually stored in files in different formats such as FITS in astronomy. With advances in technology, simulations that used to take months to finalize, now run in less time when we use a High Performance Com-puting (HPC) environment. To control the execution of the simulation, users can perform analysis on the scientific data, tracking quantities of interest. However, in many systems, such tracing is only possible at the end of the simulation. In ad-dition, ad-hoc programs are developed to extract scientific data of interest present in files. Therefore, to deal with different file formats and to access the content of interest stored in these scientific data files, systems have been developed to assist the user to extract and analyze provenance and domain data, allowing the tracking of scientific data elements. Even so, analysis in theses systems can be difficult, since they require a specific background in query languages. To support the exploratory analysis of scientific data, this work introduces a graphical interface to allow visu-alization of previously stored dataflow specifications and dataflow tracking through query processing without the user having to specify the analysis via query language syntax.

Keywords: Raw Data Analysis, Dataflow Management, Provenance Data,

(7)

Sum´

ario

Agradecimentos iv Lista de Figuras ix Lista de Tabelas xi 1 Introdu¸cão 1 1.1 Contexto . . . 1 1.2 Motiva¸cão . . . 2 1.3 Contribui¸cão . . . 3

1.4 Organiza¸c˜ao deste documento . . . 4

2 Referencial Te´orico 5 2.1 Simula¸c˜ao Computacional . . . 5

2.2 Abstra¸c˜ao de Fluxo de dados . . . 5

2.2.1 Atributo de dados . . . 6

2.2.2 Elemento de dados . . . 6

2.2.3 Conjunto de dados . . . 6

2.2.4 Transforma¸c˜ao de dados . . . 6

2.2.5 Fluxo de dados . . . 7

2.2.6 Dependˆencia de dados . . . 8

2.2.7 Exemplo . . . 8

2.3 Dados de proveniˆencia . . . 9

2.3.1 Defini¸c˜ao . . . 9

2.3.2 Tipos de proveniˆencia . . . 10

2.4 Rastreamento de dados de proveniˆencia . . . 11

2.4.1 Gerˆencia do fluxo de dados no n´ıvel f´ısico . . . 11

2.4.2 Gerˆencia do fluxo de dados no n´ıvel l´ogico . . . 11

(8)

4 DfAnalyzer 15

4.1 Vis˜ao geral . . . 15 4.2 Modelo arquitetural . . . 16 4.2.1 Provenance Data Extractor (PDE) . . . 17 4.2.2 Raw Data Extractor (RDE) e Raw Data Indexer (RDI) . . . . 17 4.2.3 Dataflow Viewer (DfViewer) . . . 18 4.2.4 Query Interface (QI) . . . 19

5 Interface gráfica para a análise do fluxo de dados em simula¸cões

computacionais 23

5.1 Visualiza¸c˜ao do fluxo de dados . . . 24 5.2 Especifica¸c˜ao da consulta . . . 25 5.3 Processamento de consulta . . . 28

6 Resultados obtidos 30

6.1 Simula¸cão computacional em dinâmica de fluidos computacionais . . 30 6.2 Uso dos recursos gráficos . . . 32

7 Conclus˜ao 43

(9)

Lista de Figuras

2.1 Exemplo de transforma¸c˜ao de dados t com conjunto de dados de

entrada i e conjunto de dados de sa´ıda o. . . 7

2.2 Exemplo de fluxo de dados, com transforma¸c˜oes de dados t1 e t2 e conjuntos de dados s0, s1 e s2. . . 7

2.3 Exemplo de especifica¸cão de fluxo de dados D, com duas trans-forma¸cões de dados e três conjuntos de dados. . . 8

4.1 Arquitetura DfAnalyzer . . . 16

4.2 P´agina com lista de especifica¸c˜oes de fluxos de dados da ferramenta DfAnalyzer [1] . . . 18

4.3 Visualiza¸c˜ao da especifica¸c˜ao do fluxo de dados clothing [1] . . . 19

4.4 Fragmento do fluxo de dados a ser analisado [1] . . . 22

4.5 Resultado ap´os o processamento da consulta [1] . . . 22

5.1 Aba para especifica¸c˜ao da consulta . . . 26

6.1 Fluxo de dados D utilizado no experimento do Cap´ıtulo 6 . . . 31

6.2 Caminho do fluxo de dados D rastreado na consulta #1 . . . 33

6.3 P´agina inicial da interface gr´afica . . . 34

6.4 Fluxo de dados da simula¸c˜ao computacional em sedimenta¸c˜ao . . . . 35

6.5 Escolha do conjunto de dados osolversimulationtransport . . . . 35

6.6 Escolha do conjunto de dados oline0extraction . . . 36

6.7 Resultados da consulta A com o atributo time do conjunto de dados osolversimulationtransport e s, points0, points1 e points2 do conjunto de dados oline0extraction . . . 37

6.8 Resultados da consulta B com o atributo time do conjunto de dados osolversimulationtransport e s, points0, points1 e points2 do conjunto de dados oline0extraction . . . 38

6.9 Resultados da consulta C com o atributo time do conjunto de dados osolversimulationtransport e s, points0, points1 e points2 do conjunto de dados oline0extraction . . . 39

(10)

6.11 Resultados da consulta #2 com o atributo dt do conjunto de dados ogetmaximumiterationstotransport, time do conjunto de dados osol-versimulationtransport e s, points0, points1 e points2 do conjunto de dados oline0extraction . . . 42

(11)

Lista de Tabelas

2.1 Exemplo de atributo de dados . . . 6

4.1 Especifica¸c˜ao da consulta utilizando QI . . . 21

5.1 Especifica¸c˜ao de parˆametros . . . 28

6.1 Exemplos de alguns atributos de dados de S . . . 32

6.2 Argumentos do Query Interface para a consulta #1 . . . 32

(12)

Cap´ıtulo 1

Introdu¸

c˜

ao

Este cap´ıtulo apresenta o contexto, a motiva¸cão e as contribui¸cões deste trabalho. Além disso, a organiza¸cão desta monografia é descrita no final desta introdu¸cão.

1.1 Contexto

Simula¸cões computacionais têm o objetivo de ratificar uma hipótese cient´ıfica. Fre-quentemente, essas simula¸cões são complexas, com resultados mais detalhados e as suas execu¸cões vêm se tornando cada vez mais eficientes devido aos avan¸cos na computa¸cão, como os ambientes de Processamento de Alto Desempenho (PAD), que possibilitam a execu¸cão paralela das simula¸cões [2, 3]. Nesse contexto, essas simula¸cões envolvem a execu¸cão de uma sequência de programas cient´ıficos, em que dados cient´ıficos (i.e., dados do dom´ınio cient´ıfico) gerados por um programa são consumidos por outro, formando um fluxo de dados [4]. Por conta de sua caracter´ıstica exploratória e do n´ıvel de detalhamento dos resultados obtidos, as simula¸cões computacionais envolvem a gera¸cão de um grande volume de dados.

Para viabilizar a análise desses dados cient´ıficos durante a execu¸cão da simula¸cão, algoritmos têm sido desenvolvidos de maneira a acessar os dados em suas fontes de dados, que podem ser estruturas de dados ainda alocados em memória ou arquivos. Porém, o desenvolvimento desses programas para acessar ou analisar os dados ci-ent´ıficos presentes em fontes de dados consiste em uma tarefa que consome bastante tempo e suscet´ıvel a erros, já que os arquivos podem apresentar diferentes formatos (ex.: FITS para astronomia) ou mesmo os dados podem assumir diversas estruturas [2].

Além da extra¸cão dos dados cient´ıficos dos arquivos, esses programas podem preparar os dados para o processamento de consultas definidas e realizadas por especialistas do dom´ınio durante ou após a simula¸cão computacional [2]. Porém, em ambos os casos, as consultas s˜ao ad-hoc, isto ´e, cada programa de análise de dados cient´ıficos resolve apenas um tipo de consulta e dependendo do resultado

(13)

que o especialista do dom´ınio recebe do processamento da consulta, pode haver a necessidade de modifica¸cões na especifica¸cão da consulta e, consequentemente, no programa de análise.

Nesse cenário, a análise exploratória de dados cient´ıficos abrange diferentes tipos de consultas aos dados cient´ıficos, que visam acessar (i) dados cient´ıficos pontuais (resultados parciais ou finais) presentes em arquivos de dados cient´ıficos, (ii) o fluxo de arquivos, e (iii) elementos de dados consumidos e produzidos pela sequˆencia de programas cient´ıficos executados (fluxo de elementos de dados) [2]. Considerando o estado da arte, as principais solu¸cões existentes baseiam-se em análises realizadas ao final da execu¸cão da simula¸cão computacional, o que, em cenários de larga escala, leva semanas ou meses. Diferentemente dessas solu¸cões, essa monografia baseia-se em uma abordagem baseada na análise de dados cient´ıficos em tempo de execu¸cão [4].

1.2 Motiva¸

c˜

ao

Uma forma de viabilizar a gerência e o monitoramento do desempenho em tempo de execu¸cão consiste em modelar a simula¸c˜ao computacional como um workflow ci-ent´ıfico [5]. Assim, Sistemas de Gerência de Workflows Cient´ıficos (SGWfC) são desenvolvidos para modelar, executar e monitorar os workflows cient´ıficos. Alguns desses SGWfC permitem a execu¸cão paralela dos programas e gerenciam a distri-bui¸cão dos dados nos recursos computacionais dispon´ıveis. Dessa forma, um SGWfC consiste em um sistema que executa aplica¸cões cient´ıficas cuja ordem de execu¸cão é definida por uma representa¸cão digital da l´ogica do workflow [6], baseada na de-pendência de dados.

Os SGWfC registram a execu¸c˜ao do workflow por meio dos dados de pro-veniência, que são informa¸cões sobre o processo de transforma¸cão dos dados, o que é essencial para preservá-los e determinar sua qualidade, reproduzi-los, assim como interpretar e validar os resultados gerados [3]. Além dos dados de proveniência, os especialistas também necessitam de dados espec´ıficos do dom´ınio, o conteúdo de arquivos que são produzidos e consumidos pelos programas cient´ıficos, que são essenciais para investigar comportamentos em um determinado dom´ınio da ciência [3].

Muitos dos SGWfC existentes, como o Pegasus e o Swift/T, gerenciam tanto a execu¸c˜ao do workflow em ambientes de PAD quanto capturam os dados de pro-veniˆencia correspondentes ao workflow [3]. Entretanto, as solu¸c˜oes baseadas na abs-tra¸c˜ao de workflow cient´ıfico apresentam limita¸c˜oes quanto ao potencial anal´ıtico, pois não consideram o acesso e a extra¸cão dos dados cient´ıficos presentes em fontes de dados, ou mesmo a análise do fluxo de elementos de dados cient´ıficos, conforme

(14)

discutido nos três tipos frequentes de consultas para a análise exploratória de dados cient´ıficos. Ou seja, do ponto de vista anal´ıtico, as análises comumente desejadas pelos especialistas do dom´ınio estão focadas no fluxo de dados cient´ıficos pelos pro-gramas cient´ıficos.

Entre as solu¸cões existentes que apoiam análises em fluxos de dados podemos citar o SQLShare que n˜ao tem a extra¸cão de dados brutos e apresenta dificuldade em lidar com muitos dados cient´ıficos. Portais como esses oferecem funcionalidades para a realiza¸cão de análises do fluxo de dados em simula¸cões computacionais através do processamento de consultas previamente definidas, ou seja, não é poss´ıvel editá-las. Além disso, a maioria desses sistemas permite apenas que os usuários analisem os dados após a execu¸cão da simula¸cão [7]. Ademais, a especifica¸cão de consultas sobre uma base de dados exige conhecimentos em linguagem do tipo SQL (Structured Query Language), SPARQL ou Prolog.

Considerando facilitar a análise do fluxo de dados impl´ıcito em simula¸cões com-putacionais, esta monografia prop˜oe o uso da ferramenta DfAnalyzer [8] para realizar a extra¸cão de dados cient´ıficos e o registro de dados de proveniência em uma base de dados, assim como uma extensão dessa ferramenta para oferecer recursos anal´ıticos. Especificamente, esta monografia introduz uma interface gráfica capaz de prover visualiza¸cões das especifica¸cões de fluxos de dados armazenados na base de dados, além da submissão e execu¸cão de consultas na base de dados em tempo de execu¸cão da simula¸cão computacional, sem a utiliza¸cão de uma linguagem declarativa para o processamento de consultas, como SQL.

1.3 Contribui¸

c˜

ao

Diante desse contexto e dessa motiva¸cão, para evitar que o especialista do dom´ınio tenha que se afastar de sua pesquisa para dominar técnicas de computa¸cão, esta mo-nografia contribui com a análise do fluxo de dados cient´ıficos em tempo de execu¸cão. Além disso, ao aliar a abstra¸cão de fluxo de dados com os conceitos de proveniência de dados, essa solu¸cão permite a rastreabilidade, a reprodutibilidade e a confiabi-lidade dos dados produzidos. Com o apoio à captura de dados de proveniência, consultas ao fluxo de elementos de dados [4] podem ser realizadas, apresentando uma abordagem intuitiva para o usuário e uma forma versátil de avaliar e reavaliar os resultados parciais e finais obtidos pelas simula¸cões computacionais.

Assim, a abordagem descrita nesta monografia permite que os especialistas do dom´ınio investiguem os dados referentes ao dom´ınio da simula¸cão, por meio da análise de dados cient´ıficos extra´ıdos de fontes de dados e do fluxo de elementos de dados pelos programas cient´ıficos encadeados. Do ponto de vista da usabilidade, desenvolveu-se uma interface gráfica que permite os usuários definirem apenas os

(15)

atributos e as condi¸cões de valores de atributos de interesse, assim como os conjuntos de dados envolvidos na análise de um fragmento do fluxo de dados. Desta forma, a importância desta monografia está relacionada com a possibilidade de que hipóteses propostas pelos especialistas do dom´ınio sejam devidamente analisadas e avaliadas por meio da interface gráfica, que facilita a especifica¸cão das consultas de interesse e a visualiza¸cão dos resultados cient´ıficos.

1.4 Organiza¸

c˜

ao deste documento

Esta monografia está organizada em outros 6 cap´ıtulos além desta introdu¸cão. O Cap´ıtulo 2 apresenta a fundamenta¸cão teórica necessária para melhor compreensão desta monografia. O Cap´ıtulo 3 apresenta os trabalhos relacionados a esta mono-grafia quanto a análise exploratória de dados cient´ıficos. O Cap´ıtulo 4 descreve a ferramenta DfAnalyzer utilizada no desenvolvimento desta monografia. No Cap´ıtulo 5 apresentamos decisões quanto a implementa¸cão e a interface gráfica desenvolvida. O Cap´ıtulo 6 discute o resultado obtido através da interface desenvolvida utilizando uma simula¸cão computacional. Finalmente, o Cap´ıtulo 7 conclui a monografia com perspectivas de trabalhos futuros.

(16)

Cap´ıtulo 2

Referencial Te´

orico

Este cap´ıtulo tem como finalidade apresentar as principais defini¸cões para melhor compreensão desta monografia. Por isso, os conceitos de fluxo de dados, proveniência e rastreamento são definidos formalmente. Destaca-se que os conceitos apresentados foram retirados de [2].

2.1 Simula¸

c˜

ao Computacional

Uma simula¸cão computacional contempla a execu¸cão de modelos computacionais cada vez mais complexos com o objetivo de avaliar um determinado comporta-mento cient´ıfico. Normalmente, uma simula¸cão computacional é caracterizada pela execu¸cão de diversos programas cient´ıficos encadeados. No cenário de larga escala, o volume de dados manipulados por esses programas comumente exige o uso de um ambiente de Processamento de Alto Desempenho (PAD) [9], a fim de tirar proveito do paralelismo de dados. Além disso, os dados cient´ıficos produzidos, consumidos e propagados pelos programas encadeados em uma simula¸cão computacional podem ser modelados como um fluxo de dados, conforme explicado na Se¸cão 2.2. Nessa abstra¸cão, os programas cient´ıficos e as dependências de dados são representados por transforma¸cões de dados e fluxos de dados entre duas transforma¸cões de dados (isto é, conjuntos de dados), respectivamente [9].

2.2 Abstra¸

c˜

ao de Fluxo de dados

Esta monografia segue a abstra¸cão de fluxo de dados apresentada em [10], que visa re-presentar como os elementos de dados são consumidos, produzidos e propagados por diferentes transforma¸cões de dados em uma simula¸cão computacional. Entretanto, para o seu melhor entendimento, alguns conceitos importantes para a defini¸cão de fluxo de dados são apresentados antes, como conjunto de dados e transforma¸cão de

(17)

dados.

2.2.1 Atributo de dados

Um atributo de dados é uma caracter´ıstica que descreve o conjunto de dados. Ade-mais, um atributo de dados é composto por um rótulo (do termo em inglˆes, tag) e um tipo. O rótulo funciona como um identificador para o conjunto de dados, de forma a apresentar um valor único. O tipo pode assumir diferentes estruturas de dados, como texto, booleano, inteiro, ponto flutuante ou arquivo.

Um exemplo para a defini¸c˜ao de atributo de dados ´e o que segue na Tabela 2.1.

Tabela 2.1: Exemplo de atributo de dados

R´otulo do atributo Tipo do atributo

Nome Texto

Idade Inteiro

2.2.2 Elemento de dados

Um elemento de dados ´e definido como e = (v1, v2, ...vz), em que o i-´esimo v em

e ´e o valor do i-´esimo atributo de dados a de um conjunto de dados s. Percebe-se que a quantidade de atributos do conjunto de dados s deve ser igual `a quantidade de valores presentes no elemento de dados e [11].

2.2.3 Conjunto de dados

Supondo um conjunto de dados s. s consiste em um conjunto de elementos de dados E = {e1, e2, ...ex}, sendo x o n´umero de elementos de dados. Cada elemento de

dados ´e composto por atributos predefinidos A = (a1, a2, ..., ay), sendo y o n´umero

de atributos.

2.2.4 Transforma¸

c˜

ao de dados

Supondo uma transforma¸c˜ao de dados t. t ´e caracterizada pelo consumo de um ou mais conjuntos de dados de entrada i e produ¸c˜ao de um ou mais conjuntos de dados de sa´ıda o, conforme a Figura 2.1. Logo, o = t(i).

(18)

Figura 2.1: Exemplo de transforma¸c˜ao de dados t com conjunto de dados de entrada i e conjunto de dados de sa´ıda o.

2.2.5 Fluxo de dados

Considerando duas transforma¸c˜oes de dados t1 e t2. A composi¸c˜ao t1 o t2 ´e uma

transforma¸c˜ao que primeiro aplica t1 ao conjunto de dados de entrada s0 de maneira

a obter um conjunto de dados intermedi´ario s1. A seguir, a transforma¸c˜ao t2 ´e

aplicada ao conjunto de dados intermedi´ario s1 para obten¸c˜ao do conjunto de dados

de sa´ıda s2. É importante notar que a composi¸cão é uma propriedade associativa,

logo a composi¸c˜ao linear de n transforma¸c˜oes de dados ´e denotada como tno tn− 1 o

... o t1. Portanto, pode-se definir a composi¸c˜ao de n transforma¸c˜oes de dados como

um fluxo de dados D. Assim, s2 = (tn o tn− 1 o ... o t1)(s0) ou D(s0), onde s0 ´e o

conjunto de dados de entrada desse fluxo de dados. Esse fluxo de dados é mostrado na Figura 2.2. Além disso, um fluxo de dados pode ser modelado como um grafo direcionado ac´ıclico (DAG), no qual os vértices (nós) representam as transforma¸cões de dados de uma simula¸cão computacional, e as arestas direcionadas representam os conjuntos de dados entre as transforma¸cões.

Figura 2.2: Exemplo de fluxo de dados, com transforma¸c˜oes de dados t1 e t2 e

(19)

2.2.6 Dependˆ

encia de dados

Uma especifica¸c˜ao de dependˆencia de dados l ´e dada por l = (s, tprevious, tnext) onde:

• s ´e um conjunto de dados;

• tprevious´e uma transforma¸c˜ao de dados que produz elementos de dados para o

conjunto de dados s;

• tnext ´e uma transforma¸c˜ao de dados que consome elementos de dados do

con-junto de dados s.

2.2.7 Exemplo

Para elucidar as defini¸cões e as especifica¸cões da Se¸cão 2.2, apresentamos um fragmento de fluxo de dados produzido por uma simula¸cão computacional real no dom´ınio de dinâmica de fluidos computacionais. Na Figura 2.3 podemos ver o DAG correspondente a esse fluxo de dados D composto por trˆes conjuntos de dados, iinput-mesh, oinputmesh e oioconfig, duas transforma¸cões de dados, inputmesh e ioconfig, e três dependências de dados.

Figura 2.3: Exemplo de especifica¸cão de fluxo de dados D, com duas transforma¸cões de dados e três conjuntos de dados.

Logo a especifica¸c˜ao de D ´e: D = (S, T, L)

S = iinputmesh, oinputmesh e oioconfig T = inputmesh, ioconfig

(20)

L = (iinputmesh, null, inputmesh), (oinputmesh, inputmesh, ioconfig), (oioconfig, ioconfig, null)

A palavra null em L significa nulo, indicando que uma das transforma¸c˜oes de dados correspondente à dependência de dados não existe.

2.3 Dados de proveniˆ

encia

Com o aumento da complexidade das simula¸cões computacionais, especialistas do dom´ınio cient´ıfico estão cada vez mais interessados em informa¸cões relacionadas à execu¸cão das simula¸cões. Isso se dá por conta da possibilidade de obten¸cão de informa¸cão sobre as fontes e transforma¸cões aplicadas aos dados durante a simula¸cão. O conhecimento obtido com essas informa¸cões propiciam a avalia¸cão da qualidade dos dados, observa¸cão dos processos de transforma¸cão e até uma reexecu¸cão da simula¸cão omputacional [12]. Nesse cenário, a proveniência de dados corresponde a um conceito essencial, discutido em mais detalhes a seguir.

2.3.1 Defini¸

c˜

ao

O dicionário Michaelis [13] define proveniência como “lugar de onde algo provém; o local de origem ou o primeiro histórico conhecido de algo”. A proveniência vem sendo estudada em diferentes campos, como arte, medicina, ciência e tecnologia [14]. Na ciência da computa¸cão, dado de proveniência é descrito como informa¸cões obtidas sobre processos e conjuntos de dados utilizados na produ¸cão de um resultado final. Assim, dados de proveniência representam informa¸cões a respeito de uma si-mula¸cão computacional, ou seja, sobre o comportamento da execu¸cão dos progra-mas cient´ıficos, possibilitando o rastreamento do fluxo de dados [15]. Mais ainda, dados de proveniência facilitam a análise das simula¸cões computacionais por parte dos especialistas do dom´ınio, já que possibilita a verifica¸cão de dados de dom´ınio, da origem dos dados e da forma como eles foram processados em cada etapa da simula¸cão, além de apoiar a reprodutibilidade e a valida¸cão dos resultados obtidos. Com todas essas defini¸cões percebemos que com dados de proveniência somos capazes de responder certas perguntas, como:

• De que processo um determinado dado foi obtido; • Quando um dado foi criado;

• Em quais transforma¸c˜oes um determinado elemento de dado foi utilizado; • Quais foram os conjuntos de dados de entrada utilizados em determinada

(21)

• Qual crit´erio foi aplicado para gerar certo dado.

Nesse contexto, podemos destacar um importante componente da proveniência que é a causalidade, que pode ser descrita como a sequência de etapas, que quando combinada com os dados de entrada e parâmetros definidos nos levam a um resultado final [15]. Essa causalidade é refletida no conceito de fluxo de dados apresentado na se¸cão anterior, sendo que cada etapa corresponde a uma transforma¸cão de dados (vértice) e os dados processados correspondem aos conjuntos de dados (aresta).

Assim, a proveniência de dados é vista como componente fundamental para a análise de simula¸cões computacionais, já que provê informa¸cões sobre os dados de origem e os processos pelos quais esses dados passaram. Entretanto, para um enten-dimento adequado e o uso desses dados de maneira efetiva na análise, são necessários mecanismos que facilitem esse recurso.

2.3.2 Tipos de proveniˆ

encia

Tendo definido dados de proveniência na Subse¸cão 2.3.1, agora apresentamos os dois tipos de proveniência que existem na gerência do fluxo de dados: prospec-tiva e retrospecprospec-tiva. A proveniˆencia prospectiva descreve a estrutura da simula¸c˜ao computacional e, abstra¸c˜ao de workflow cient´ıfico representa o encadeamento de ati-vidades [16], relacionando-se à especifica¸cão das tarefas computacionais e aos passos que devem ser seguidos para gerar um conjunto de dados final. Em outras pala-vras, a proveniência prospectiva registra a especifica¸cão do fluxo de dados de uma simula¸cão computacional, com as transforma¸cões de dados e as suas dependências de dados.

Já a proveniˆencia retrospectiva refere-se `a captura dos passos executados du-rante a simula¸cão computacional [16, 17], assim como as informa¸cões sobre o ambi-ente computacional utilizado e o tempo para a execu¸cão da simula¸cão computacional. A proveniência retrospectiva é constru´ıda utilizando informa¸cões coletadas durante a execu¸cão, incluindo transforma¸cões de dados e valores de parâmetros, conjuntos de dados produzidos, tempo de in´ıcio e fim da execu¸cão [17]. Ou seja, a proveniência re-trospectiva determina propriedades sobre a execu¸cão da simula¸cão, como o diretório da execu¸c˜ao ou o host do servidor da base de dados.

Encontram-se dispon´ıveis no mercado diversos sistemas que apoiam esses tipos de proveniˆencia. Entre eles podemos citar noWorkflow [18], YesWorkflow [18], Taverna [19], VisTrails [20], Pegasus [21], Kepler [22], e FlashView [23].

Além disso, a análise de dados de proveniência pode acontecer de dois modos, offline e online. O modo offline permite o processamento de consultas somente ap´os o término da simula¸cão computacional, impossibilitando assim a investiga¸cão de resultados parciais enquanto a simula¸cão ainda terminou, como acontece no HubZero

(22)

[24]. Enquanto isso, no modo online, a an´alise dos dados de proveniência pode ser realizada durante a execu¸cão da simula¸cão, como no Chiron [25].

2.4 Rastreamento de dados de proveniˆ

encia

As solu¸cões disponibilizadas devem capturar os dados de maneira a permitir tanto o rastreio quanto o monitoramento do fluxo de dados em rela¸cão aos conjuntos de dados que são consumidos e produzidos em cada transforma¸cão de dados durante a execu¸cão da simula¸cão computacional. Nesse sentido, a gerência do fluxo de dados pode ser abordada de duas maneiras diferentes: f´ısica ou lógica.

2.4.1 Gerˆ

encia do fluxo de dados no n´ıvel f´ısico

A gerência do fluxo de dados no n´ıvel f´ısico consiste do suporte às transforma¸cões de dados no n´ıvel do sistema de arquivos. Nesse caso, a análise às transforma¸cões de dados são realizadas em rela¸cão aos arquivos que são consumidos e produzidos por cada programa envolvido na simula¸cão computacional, sem levar em conta o conteúdo dos arquivos que são especificamente do dom´ınio da simula¸cão. Nota-se que nesNota-se n´ıvel de gerência, os arquivos são considerados caixas-pretas, visto que não há ´ındices ou suporte a consulta para acessar os conteúdos espec´ıficos de dom´ınio [2, 10]. Assim, os especialistas do dom´ınio estão restritos a análises com ponteiros para arquivos envolvidos no fluxo de dados, criando a necessidade de analisar cada arquivo separadamente ou desenvolver programas espec´ıficos para a extra¸cão e a indexa¸cão do conteúdo do dom´ınio [10].

2.4.2 Gerˆ

encia do fluxo de dados no n´ıvel l´

ogico

A gerência do fluxo de dados no n´ıvel lógico trata do monitoramento de como os elementos de dados são consumidos e produzidos pelos programas de simula¸cão [2]. Esses elementos de dados podem ser tanto dados dos arquivos cient´ıficos, quanto dados que são propagados na cadeia dos programas de simula¸cão. Com o monito-ramento do consumo e da produ¸cão dos elementos de dados, seus relacionamentos podem ser utilizados para recompor o caminho do fluxo de elementos de dados [2, 10]. Na perspectiva dos especialistas, é poss´ıvel consultar dados de dom´ınio sem a necessidade do próprio especialista do dom´ınio desenvolver programas espec´ıficos para a extra¸cão de dados cient´ıficos. Entretanto, é importante ressaltar que o custo computacional de uma simula¸cão computacional é maior para a gerência do fluxo de dados no n´ıvel lógico, já que os elementos de dados devem ser extra´ıdos e moni-torados em tempo de execu¸cão, enquanto que, no n´ıvel f´ısico, esse monitoramento se resume a ponteiros para os arquivos de dados cient´ıficos [2, 10]. Considerando a

(23)

gerência do fluxo de dados em ambos os n´ıveis (lógico e f´ısico), destaca-se que os es-pecialistas precisam capturar e armazenar dados de proveniência sobre a composi¸cão da simula¸cão computacional com as dependências de dados e dados cient´ıficos ex-tra´ıdos de arquivos em cada etapa de simula¸cão [10].

(24)

Cap´ıtulo 3

Trabalhos Relacionados

Dado que o principal objetivo desta monografia consiste no desenvolvimento de re-cursos gráficos para apoiar a visualiza¸cão da especifica¸cão do fluxo de dados e o pro-cessamento de consultas usando a ferramenta DfAnalyzer (introduzida no Cap´ıtulo 4), este cap´ıtulo aborda trabalhos e interfaces relacionados que consideram o rastre-amento do fluxo de dados em simula¸cões computacionais intensivas em dados. Atu-almente, existem na literatura, diversas ferramentas de visualiza¸cão que propõem o apoio à análise exploratória de dados, como FlashView [23], SQLShare [26], HUBzero [24] e FireWorks [27]. Essas ferramentas oferecem GUIs (Graphical User Interface) focadas na usabilidade. Porém, a maioria delas não fornece suporte à resposta inte-rativa em tempo de execu¸cão.

O SQLShare, por exemplo, é um servi¸co de banco de dados que tem como mo-tiva¸cão a remo¸cão de obstáculos que podem ser empecilhos no uso de bancos de dados relacionais, como instala¸cão, configura¸cão do ambiente, defini¸c˜ao de schema, tuning, ingest˜ao de dados, entre outros. Nessa ferramenta, o usuário deve carregar seus dados e imediatamente pode come¸car a consultá-los através de consultas SQL, sem a necessidade de instala¸cão e configura¸cão de um sistema para gerenciar os dados. Uma vantagem do SQLShare é a possibilidade de salvar o resultado de uma consulta para usá-lo como entrada em uma outra consulta. Apesar da facilidade trazida por esta ferramenta por conta de excluir a dificuldade do uso de um Sistema de Gerência de Banco de Dados (SGBD), o fato de o próprio especialista precisar escrever as consultas SQL pode ser inconveniente para aquele que não tem conhe-cimento apronfundado. Além disso, o SQLShare apresenta dificuldade ao lidar com dados cient´ıficos para um mesmo conjunto e não apresenta funcionalidades para a extra¸cão de dados cient´ıficos armazenados em arquivos, sendo uma grande limita¸cão da ferramenta, já que esses dados são importantes na análise exploratória de dados cient´ıficos.

J´a o FlashView apoia consultas aos dados cient´ıficos. FlashView ´e um sistema que auxilia os especialistas de dom´ınio a entenderem rapidamente as caracter´ısticas

(25)

dos dados e depois, então, a carregarem apenas os dados de interesse para as suas análises. Para promover essa rapidez, FlashView omite o processo de carregamento consultando diretamente os dados cient´ıficos (sem considerar a extra¸cão de dados) e aplica uma técnica de aproxima¸cão de processamento de consultas para obter resultados de consulta em tempo real. Em rela¸cão à interface gráfica proposta no FlashView, os dados são divididos e organizados como um conjunto de subconjuntos hierárquicos. Ademais, o FlashView combina os resultados de uma consulta anterior com a próxima, além de permitir que os usuários fragmentem e filtrem os dados de interesse. Além disso, os usuários podem adicionar um número fixo de consultas a uma espécie de lista de observa¸cão, e o estado, os gráficos e os parâmetros referentes `

as consultas pertencentes a essa lista s˜ao atualizados continuamente.

Diferentemente, o HubZero permite o processamento de consultas apenas após a execu¸cão da simula¸cão, impossibilitando análises em tempo de execu¸cão, enquanto o FireWorks apoia análises baseadas nos rastros de proveniência gerados a partir da execu¸cão, além de permitir que os especialistas do dom´ınio realizem ajustes ou interven¸cões durante a execu¸cão. Porém, o FireWorks se restringe às consultas já definidas pelo sistema.

(26)

Cap´ıtulo 4

DfAnalyzer

Neste cap´ıtulo apresentamos a ferramenta DfAnalyzer [10], uma ferramenta para a análise de fluxo de dados em simula¸c˜oes computacionais. A DfAnalyzer foi proposta pelo Núcleo Avan¸cado de Computa¸cão de Alto Desempenho (NACAD) da Univer-sidade Federal do Rio de Janeiro (UFRJ) e mais detalhes são apresentados neste cap´ıtulo.

4.1 Vis˜

ao geral

No cenário de análise exploratória de dados cient´ıficos [4], o especialista do dom´ınio cient´ıfico frequentemente necessita acompanhar a execu¸cão da sua simula¸cão compu-tacional, a fim de rastrear as quantidades de interesse (ou seja, os dados cient´ıficos) para controlar o máximo poss´ıvel a sua execu¸cão. Entretanto, anomalias podem ocorrer durante a execu¸cão dos modelos computacionais. Dependendo da severi-dade das anomalias observadas, o especialista do dom´ınio pode observar que os resultados finais não serão capazes de validar a sua hipótese cient´ıfica e, assim, ele precisa interromper a execu¸cão da simula¸cão antes do seu término.

Nesse sentido, com o intuito de permitir o monitoramento, a depura¸cão, a análise e a interven¸cão do fluxo de dados gerado por simula¸cões computacionais em tempo de execu¸c˜ao, a ferramenta DfAnalyzer oferece um conjunto de recursos para apoiar a captura e a análise de dados de proveniência e de dados cient´ıficos presentes em arquivos. Al´em disso, a DfAnalyzer mant´em o controle da execu¸cão paralela dos modelos computacionais na própria simula¸cão, ao mesmo tempo em que permite o registro do fluxo de arquivos e de elementos de dados gerados em tempo de execu¸cão.

(27)

4.2 Modelo arquitetural

Como mencionado anteriormente, a ferramenta DfAnalyzer permite a extra¸c˜ao de dados de proveniência e de dados cient´ıficos em simula¸cões computacionais inten-sivas em dados. A Figura 4.1 apresenta uma vis˜ao geral da arquitetura da DfA-nalyzer. Basicamente, n´os temos os programas cient´ıficos comumente utilizados nas simula¸cões e as consultas do dom´ınio no n´ıvel mais alto de abstra¸cão. Em seguida, interfaces de acesso foram desenvolvidas para facilitar o acoplamento dos recursos da ferramenta DfAnalyzer nos programas de simula¸cão. Nesse n´ıvel, a Interface Gráfica representa a principal contribui¸cão desta monografia, uma vez que contempla todos os recursos gráficos desenvolvidos para facilitar a especifica¸cão e o processamento de consultas que investigam fragmentos do fluxo de dados gerado por uma simula¸cão computacional.

Por ´ultimo, o terceiro n´ıvel corresponde aos recursos disponibilizados pela DfA-nalyzer. Assim, a DfAnalyzer apresenta dois componentes para a extra¸c˜ao e a in-dexa¸c˜ao de dados cient´ıficos, conhecidos como Raw Data Extractor e Raw Data Indexer, e trˆes servi¸cos RESTful para permitir a extra¸cão de dados de proveniência (componente Provenance Data Extractor ) e a an´alise do fluxo de dados (componen-tes Dataflow Viewer e Query Interface). Do ponto de vista da an´alise do fluxo de dados, o componente Dataflow Viewer permite apenas a an´alise de dados de pro-veniência prospectiva, pois ele considera apenas análises baseadas na estrutura do fluxo de dados, ou seja, na especifica¸cão das transforma¸cões de dados, dos conjuntos de dados e das dependˆencias de dados. Por outro lado, o componente Query Inter-face permite an´alises também baseadas nos dados de proveniência retrospectiva e nos dados cient´ıficos extra´ıdos de arquivos ou de estruturas de dados alocados em memória [8, 10].

(28)

4.2.1 Provenance Data Extractor (PDE)

O componente Provenance Data Extractor (PDE) ´e responsável pela coleta e registro de dados de proveniência, além dos dados espec´ıficos do dom´ınio da aplica¸cão. Com esse conteúdo, ´e gerado um arquivo JSON (JavaScript Object Notation) contendo os dados e suas dependências. Todos os dados de proveniência e os espec´ıficos de dom´ınio coletados são carregados em uma base de dados que segue o diagrama Entidade Relacionamento do PROV-Df [10]. Essa base de dados é implementada no SGBD orientado à coluna MonetDB [28]. A escolha do MonetDB para a cria¸cão dessa base de dados foi motivada pelo fato desse SGBD conseguir trabalhar de forma eficiente com grande volume de dados e apresentar os dados de uma mesma coluna armazenados no mesmo bloco de disco, favorecendo as consultas mais frequentes na análise de dados cient´ıficos, que utilizam o operador de Sele¸cão da álgebra relacional.

4.2.2 Raw Data Extractor (RDE) e Raw Data Indexer

(RDI)

Diferentemente do PDE, o componente Raw Data Extractor (RDE) tem como ob-jetivo acessar o conteúdo dos arquivos cient´ıficos e extrair os dados cient´ıficos re-levantes de acordo com os atributos selecionados pelo usuário. Durante o acesso aos dados cient´ıficos, verifica-se se esses dados obtidos correspondem ao dom´ınio da atual simula¸cão computacional. Em seguida ocorre a filtragem dos dados, que leva em considera¸cão o que foi definido pelo usuário sobre quais dados e quais valores devem ser capturados e armazenados na base de dados de proveniência. Logo, esse passo evita que atributos que não são relevantes para o usuário sejam armazenados. Por último, como nem sempre os dados se encontram em um formato aceito pelo SGBD, os dados são convertidos para a estrutura de dados mais apropriada. Como passo adicional ao RDE, o componente Raw Data Indexer (RDI) contempla a in-dexa¸cão de dados cient´ıficos encontrados nos arquivos, de maneira a aperfei¸coar o acesso direto a regiões espec´ıficas do espa¸co de dados, permitindo uma localiza¸cão mais rápida de um registro quando efetuada uma consulta. Em geral, apesar de per-mitir a representa¸cão de estruturas de dados mais complexas, o RDI introduz um custo adicional do ponto de vista anal´ıtico, pois os ´ındices precisam ser acessados na base de dados para depois serem utilizados no acesso aos dados cient´ıficos em arquivos. Por esse motivo, essa monografia não considera as técnicas de indexa¸cão de dados cient´ıficos, sendo discutidos em mais detalhes em [10].

(29)

4.2.3 Dataflow Viewer (DfViewer)

Depois da inicializa¸cão do PDE, com os dados de proveniência e os dados espec´ıficos do dom´ınio da aplica¸c˜ao armazenados na base de dados, a ferramenta DfAnalyzer disponibiliza o recurso DfViewer, que consiste em uma interface gráfica que fornece uma visão da perspectiva do conjunto de dados a partir da especifica¸cão do fluxo de dados armazenada na base de dados, de forma a apoiar a visualiza¸cão da pro-veniência prospectiva. Essencialmente, o DfViewer provê uma lista de fluxos de dados registrados na base de dados de proveniência e o usuário pode escolher qual a especifica¸cão de fluxo de dados gostaria de visualizar.

Para tal, o usu´ario deve utilizar um navegador web, como o Google Chrome ou Mozilla Firefox, e acessar a URL http://localhost:22000 para usufruir das funcio-nalidades do DfViewer ou o host para conex˜oes externas. Com isso, o usu´ario tem acesso a uma lista de especifica¸c˜oes de fluxos de dados armazenados no banco de dados da DfAnalyzer, como mostrado na Figura 4.2.

Figura 4.2: P´agina com lista de especifica¸c˜oes de fluxos de dados da ferramenta DfAnalyzer [1]

Depois de ter escolhido uma especifica¸cão de fluxo de dados para visualizar, o usuário deve clicar no bot˜ao View, por exemplo, para analisar a especifica¸c˜ao do fluxo de dados com o r´otulo clothing mostrado na Figura 4.2. Com isso, a p´agina web apresentada na Figura 4.3 ´e exibida para o usuário. Essa visualiza¸cão consiste de uma perspectiva do conjunto de dados da especifica¸cão do fluxo de dados, onde os usuários podem investigar os conjuntos de dados, as transforma¸cões de dados envolvidas no consumo e na produ¸cão de um conjunto, nas dependências de dados, assim como os atributos de cada conjunto de dados. Destaca-se também que o componente DfViewer foi desenvolvido no contexto desta monografia e consiste em uma das suas principais contribui¸cões.

(30)

Figura 4.3: Visualiza¸c˜ao da especifica¸c˜ao do fluxo de dados clothing [1]

4.2.4 Query Interface (QI)

Uma vez que os dados estejam armazenados e, consequentemente, dispon´ıveis na base de dados, os especialistas de dom´ınio podem submeter consultas para realizar as suas análises. Para auxilar os especialistas nessas submissões de consultas SQL à base de proveniência, considerando também a valida¸cão das consultas e a exibi¸cão dos seus resultados, a DfAnalyzer conta com o componente Query Interface (QI). Do ponto de vista de implementa¸cão, esse componente oferece uma forma alternativa de interface (não gráfica) para execu¸cão de consultas por parte de especialistas do dom´ınio cient´ıfico sem conhecimento da linguagem SQL, já que ele considera uma forma simplificada de especifica¸cão e descri¸cão das consultas, como proposto em [11]. Por conseguinte, a partir dessa especifica¸cão simplificada da consulta, o QI converte a consulta descrita textualmente para SQL, envia a consulta SQL para o MonetDB, obtém os resultados e os retorna em um arquivo no formato CSV.

A convers˜ao da consulta descrita textualmente para SQL ocorre considerando que:

• A cl´ausula SELECT ´e populada de acordo com as proje¸c˜oes definidas pelo especialista;

• A cl´ausula WHERE opera como um filtro recuperando apenas os elementos de dados que correspondem as condi¸c˜oes definidas pelo especialista;

(31)

• A cl´ausla FROM cont´em os conjuntos de dados de onde os atributos de dados especificados na cl´ausula SELECT e as condi¸c˜oes especificadas na cl´ausula WHERE fazem parte.

Os argumentos necessários para a conversão de texto para SQL que devem ser informados pelo especialista do dom´ınio, de acordo com o apresentado em [1], são:

• D: o fluxo de dados a ser analisado (incluindo o r´otulo e o identificador do fluxo de dados, detalhados no Cap´ıtulo 5);

• dsOrigins: os conjuntos de dados utilizados como origem para o algoritmo de obten¸c˜ao de caminho;

• dsDestinations: os conjuntos de dados utilizados como destino para o algoritmo de obten¸c˜ao de caminho;

• type: o tipo de gerência do fluxo de dados, que pode ser lógico, f´ısico ou h´ıbrido, como explicado na Se¸cão 2.4;

• projections: os atributos escolhidos para a cl´ausula SELECT ;

• selections: condi¸c˜oes para filtragem dos resultados da consulta, correspondente a cl´ausula WHERE ;

• dsIncludes: conjuntos de dados que devem estar presentes no caminho encon-trado pelo algoritmo de obten¸c˜ao de caminho do QI;

• dsExcludes: conjuntos de dados que n˜ao devem estar presentes no caminho encontrado pelo algoritmo de obten¸c˜ao de caminho do QI.

Tendo esclarecido os parâmetros necessários para a defini¸cão da consulta SQL e posteriormente a conversão textual para SQL, o especialista deve utilizar a API RESTful disponibilizada pela DfAnalyzer para submeter a consulta. Essa submiss˜ao da consulta ocorre através de uma requisi¸cão HTTP com o m´etodo POST. Ent˜ao, o especialista deve utilizar a URL http://localhost:22000/query interface/{dataflow -tag}/{dataflow id} e adicionar uma mensagem contendo os parˆametros a serem con-siderados na especifica¸cão da consulta. A Tabela 4.1 mostra a especifica¸cão da mensagem de acordo com o modelo apresentado em [1].

Nesta monografia, propomos uma extensão do componente QI para apresentar uma maneira alternativa de submeter consultas para a análise exploratória de dados cient´ıficos, em que os especialistas contam com recursos gráficos para especificar e submeter as suas consultas, assim como para visualizar os resultados das consultas, já que, mesmo não sendo em SQL, o QI exige uma especifica¸cão textual que pode ser

(32)

uma tarefa complicada para o especialista do dom´ınio. Nessa perspectiva, as consul-tas consideram dados de proveniência e dados cient´ıficos gerados pelas simula¸cões computacionais intensivas em dados, sendo que mais detalhes da interface gráfica proposta nesta monografia são apresentados no Cap´ıtulo 5.

Tabela 4.1: Especifica¸c˜ao da consulta utilizando QI

Conceito M´etodo Informa¸c˜ao Adicional

Type mapping(type) type = PHYSICAL, LOGICAL,

HY-BRID dsOrigins source(datasetTags)

dsDestinations target(datasetTags)

dsIncludes include(datasetTags)

Conjuntos de dados a serem inclu´ıdos no fragmento do caminho do fluxo de dados

dsExcludes exclude(datasetTags)

Conjuntos de dados a serem exclu´ıdos no fragmento do caminho do fluxo de dados

Projections projection(attributes)

Argumento attributes define que atri-butos devem ser obtidos ap´os o proces-samento da consulta, ex.: attributes = table1.attr1;table2.attr2

Selections selection(conditions)

conditions filtra apenas os elementos de dados relevantes, ex.: table1.attr1 < 100

Exemplo

Considerando o fluxo de dados apresentado em [1], esta se¸cão propõe um exemplo de análise do fluxo de dados usando o QI. Nesse caso, os usuários desejam realizar a an´alise do fluxo de elementos de dados do conjunto de dados de entrada icloth -item para o conjunto de dados de sa´ıda oaggregation, quando a probabilidade de um cliente comprar um item da se¸cão de roupas é maior que 0,50. Especificamente, queremos saber quais itens da se¸cão de roupas estão nessa situa¸cão e quantos deles serão vendidos. A Figura 4.4 apresenta o fragmento do fluxo de dados analisado por essa consulta.

(33)

Figura 4.4: Fragmento do fluxo de dados a ser analisado [1]

Baseado nessa an´alise de fluxo de dados, uma requis˜ao HTTP deve ser enviada `

a API RESTful com a URL http://localhost:22000/query interface/clothing/2 e a mensagem como apresentado no Código 4.1. Como resultado, a API RESTful re-torna um arquivo em formato CSV, como mencionado anteriormente nesta mesma se¸cão, com o conteúdo apresentado ne Figura 4.5 após o processamento da consulta.

C´odigo 4.1: Especifica¸c˜ao de consulta enviado ao QI 1 mapping(logical)

2 source(icloth item) 3 target(oaggregation)

4 projection(icloth item.description;oprediction.probability;oaggregation.quantity) 5 selection(oprediction.probability > 0.50)

(34)

Cap´ıtulo 5

Interface gr´

afica para a an´

alise do

fluxo de dados em simula¸

c˜

oes

computacionais

Nesta se¸cão apresentamos o processo de desenvolvimento dos recursos gráficos para a visualiza¸cão do fluxo de dados pelo DfViewer, assim como para a especifica¸cão e submiss˜ao de consultas pelo QI. O front-end e o back-end da interface gr´afica foram implementados em JavaScript, associado a HTML e CSS, e Java, respectivamente. Para a gerˆencia do servidor utilizamos servi¸cos RESTful com o Spring Boot para a configura¸cão da aplica¸cão [29]. Além disso, os dados de proveniência considerados nesta monografia foram persistidos no banco de dados MonetDB [28]. Já para a visualiza¸c˜ao utilizou-se os vis.js [30], uma biblioteca de visualiza¸c˜ao dinâmica projetada para lidar com grande volume de dados e para a manipula¸cão e a intera¸cão com os dados.

Como apresentado no Se¸cão 2.3.2, a proveniência prospectiva está associada à especifica¸cão do fluxo de dados, com seus conjuntos de dados e transforma¸cões. O objetivo principal do QI, ferramenta proposta na DfAnalyzer, ´e possibilitar que não haja a necessidade de o especialista do dom´ınio conhecer todos os aspectos da sintaxe da linguagem SQL. Com isso, para submeter uma consulta à base de dados, ao invés de utilizar uma consulta em SQL, o especialista deve informar, por intermédio de requisi¸cão HTTP com o m´etodo POST, o tipo da consulta que deseja realizar, quais os conjuntos de dados de origem e destino, além das condi¸cões que devem ser levadas em conta na consulta. Nesse cenário, para auxiliar os especialistas do dom´ınio na an´alise dos dados capturados e armazenados pela DfAnalyzer durante a execu¸c˜ao de uma simula¸cão computacional, esta monografia disponibiliza uma outra maneira de utilizar o QI, com a especifica¸cão das consultas através de recursos gráficos com a visualiza¸cão do fluxo de dados por meio de um grafo direcionado.

(35)

5.1 Visualiza¸

c˜

ao do fluxo de dados

Para apoiar o especialista na escolha dos conjuntos de dados antes de finalmente analisar os resultados, faz-se necessária a visualiza¸cão do fluxo de dados. Para tal, nos baseamos na representa¸cão da especifica¸cão do fluxo de dados como um grafo direcionado ac´ıclico (DAG), que pode ser visualizado por meio de redes dinâmicas customizáveis da biblioteca vis.js. Assim, o usuário visualiza os conjuntos de dados, as transforma¸cões de dados, as dependências de dados e os atributos presentes em cada conjunto.

Para a defini¸cão de quais são os vértices do DAG e quais são as arestas, a interface gráfica automaticamente estabelece duas listas, uma para cada objeto (vertices e arestas, como mostra o Código 5.1.

Código 5.1: Código em JavaScript para defini¸cão de vértices e arestas 1 vertices = [{id: 1, label: ‘‘Vertice 1’’}, {id: 2, label: ‘‘Vertice 2’’}, {id: 3, label: ‘‘

,→ Vertice 3’’}] 2

3 arestas = [{id: 1, from: 1, to: 2, label: ‘‘Aresta 1’’}, {id: 2, from: 1, to: 3, label: ‘‘ ,→ Aresta 2’’}]

Como já mencionado anteriormente, o fluxo de dados é definido pelo conjunto de dados e pela transforma¸cão de dados, no qual, usualmente, os vértices (nós) repre-sentam as transforma¸cões de dados de uma simula¸cão computacional, e as arestas direcionadas representam os conjuntos de dados entre as transforma¸cões. Porém, como na especifica¸cão da consulta o especialista do dom´ınio está interessado em elementos de dados presentes em conjuntos de dados, esta monografia assumirá que os vértices do DAG correspondem aos conjuntos de dados entre as transforma¸cões e as arestas direcionadas representam as transforma¸cões de dados. Além disso, essa representa¸cão do fluxo de dados assumida nesta monografia se aproxima da defini¸cão do Modelo Entidade Relacionamento, que descreve as entidades envolvidas em um dom´ınio, com seus atributos e como elas se relacionam entre si. Assim, os conjuntos de dados funcionam como entidades que possuem seus atributos e as transforma¸cões de dados os relacionamentos.

A defini¸cão de arestas e vértices para entendimento por parte do vis.js se dá atrav´es da estrutura de array, de maneira que, no caso do array de arestas, cada aresta assume uma posi¸c˜ao do array e no caso dos v´ertices cada vértice uma posi¸cão do array de v´ertices. Para declara¸c˜ao do array de arestas, ´e definido de qual vértice a aresta deve partir e em qual vértice ela deve chegar através dos r´otulos from e to, respectivamente. Isso ´e feito atrav´es do id que ´e automaticamente definido pela

(36)

interface gr´afica para o v´ertice no array de v´ertices.

O processo de visualiza¸cão citado acima é feito automaticamente quando o usuário escolhe um determinado fluxo de dados na interface gráfica, isto é, o usuário não precisa definir nada para visualizar o fluxo de dados. Como explicado detalhada-mente na Se¸cão 4.2.4, ao iniciar a interface gráfica proposta nesta monografia, uma página inicial é exibida com todas as especifica¸cões de fluxo de dados já armazena-das, identificando cada uma pela tag identificadora. Assim, o usu´ario pode escolher qual especifica¸cão de fluxo de dados deseja analisar clicando no bot˜ao View (Figura 4.2). Em seguida, uma requisi¸cão HTTP é feita `a URL ’/api/dataflows/{id}’, que, por sua vez, realiza uma consulta a base de dados de maneira a obter informa¸cões sobre como se dá o relacionamento das transforma¸cões de dados entre os conjuntos de dados. Essa URL retorna um ObjectNode contendo o array de vértices e o array de arestas presentes no grafo que representa o fluxo de dados, bem como os atributos de cada transforma¸cão de dados, que aqui são os vértices. Tendo essas estruturas bem definidas, utilizou-se o comando network = new vis.Network(container, data, options) da biblioteca vis.js para criar a rede, sendo que data cont´em as informa¸cões do grafo, vértices e arestas, e atributos dos vértices. Consequentemente, o fluxo de dados pode ser exibido na página em HTML.

5.2 Especifica¸

c˜

ao da consulta

A execu¸cão da consulta através do QI, sem a utiliza¸cão de recursos gráficos, exige que alguns parâmetros sejam passados manualmente pelo usuário na requisi¸cão HTTP para o mapeamento da consulta. Esses parâmetros são o tipo de rastro dos dados de proveniência (f´ısico, lógico ou h´ıbrido), os conjuntos de dados de origem e de destino, o conjunto de nomes de atributos a serem selecionados referentes aos conjuntos de dados e as condi¸cões de sele¸cão. Assim, a especifica¸cão e o processamento da consulta não consistem em um processo trivial, além de ser suscet´ıvel a erros.

Nesta monografia propomos que o especialista do dom´ınio especifique a consulta através da própria visualiza¸cão do fluxo de dados (uso da interface gráfica), com o processamento da consulta ainda sendo realizado pelo QI, já que o mesmo consiste na interface da DfAnalyzer para o processamento de consultas focadas na an´alise do fluxo de dados. Dessa forma, assim como a execu¸cão realizada de forma direta pelo QI exige parâmetros definidos pelo especialista, a realiza¸cão da consulta através da interface gráfica demanda essa mesma defini¸cao, de maneira que o QI possa definir e executar a consulta.

Com a visualiza¸cão do fluxo de dados disponibilizada pelo DfViewer, o usuário pode tirar proveito dessa visão de todos os conjuntos para especificar a sua consulta de interesse. Dessa forma, o usuário deve selecionar o conjunto de dados (vértice)

(37)

que deseja analisar, clicando uma vez nele. Com o clique, é mostrado uma aba lateral para que o usuário possa especificar aquilo que espera saber sobre aquele conjunto, ou seja, quais atributos do conjunto de dados devem ser mostrados no resultado final. Um exemplo dessa aba lateral para uma especifica¸cão de fluxo de dados é mostrado na Figura 5.1.

Figura 5.1: Aba para especifica¸c˜ao da consulta

Seguindo o que é mostrado na Figura 5.1, o usuário deve escolher qual o tipo de rastreamento de dados de proveniência deseja realizar, como discutidos previamente na Se¸cão 2.4. Para essa escolha, são apresentados as caixas de sele¸cão (do inglês checkbox) com as op¸cões Physical e Logical, correspondentes aos tipos f´ısico e l´ogico, respectivamente. O usuário deve selecionar a op¸c˜ao Physical caso queira o rastre-amento no n´ıvel f´ısico e a op¸c˜ao Logical para o n´ıvel l´ogico. Para o rastreamento h´ıbrido, o usuário deve selecionar ambos.

Depois disso, o usuário deve escolher, através de sele¸cão de caixas de sele¸cão, os atributos que deseja recuperar no processamento da consulta. É válido mencionar que os atributos mostrados na aba são relativos a cada conjunto de dados, isto é, cada conjunto de dados tem seus atributos. Então, ao contrário do tipo de consulta que é escolhido para a consulta como um todo, os atributos são escolhidos para cada conjunto de dados separadamente. Logo, os atributos selecionados estão relaciona-dos ao operador de proje¸cão na álgebra relacional e à cl´ausula SELECT em SQL para a constru¸cão da consulta.

Além disso, o usuário deve especificar textualmente quais são as condi¸cões de filtragem a serem consideradas na consulta. Essa especifica¸cão deve seguir a regra: atributo operador valor, em que o atributo ´e o nome do atributo que se deseja filtrar e o operador pode ser >, <, etc. Caso queira colocar mais de uma condi¸c˜ao, o usuário deve separar as condi¸cões com a utiliza¸cão de ponto e v´ırgula (;). Em SQL, essas

(38)

condi¸cões correspondem a cl´ausula WHERE e na ´algebra relacional, se referem ao operador de sele¸cão que selecionará as tuplas que satisfazem as condi¸cões impostas. Depois de especificar as propriedades de interesse em um conjunto de dados, o usuário deve salvar essas modifica¸c˜oes clicando em Save changes. Ao clicar em Save changes, todas as sele¸c˜oes e modifica¸cões realizadas pelo usuário são salvas e uma mensagem Saved ´e mostrada para o usuário. Lembrando que o usuário deve repetir essa opera¸cão para todos os conjuntos de dados que deseja realizar opera¸cões de proje¸cão/sele¸cão e salvar. Dessa maneira, ao finalizar a especifica¸cão, o usuário deve submeter esses dados selecionados à execu¸c˜ao clicando em Run Query.

Ademais, a especifica¸cão da cl´ausula FROM ocorre automaticamente. Sempre que atributos e/ou condi¸cões são colocadas para um determinado conjunto de dados e o usuário os salva, o nome desse conjunto de dados é adicionado ao conjunto de dados de origem ou de destino (dsOrigins e dsDestinations, respectivamente) e que, consequentemente, serão adicionados à cl´ausula FROM. Al´em disso, de acordo com o fragmento do fluxo de dados a ser analisado, outros conjuntos de dados são adicionados à cl´ausula FROM.

Para o armazenamento dos conjuntos de dados selecionados e suas respectivas especifica¸c˜oes utilizamos o armazenamento local da Web Storage API [31] atrav´es do m´etodo Window.localStorage. Dessa forma, no caso da sele¸c˜ao de um segundo conjunto de dados, as informa¸cões relacionadas ao primeiro conjunto de dados seleci-onado não são perdidas. Além de guardar os dados selecionados e especificados pelo usuário para a execu¸cão da consulta, a interface gráfica deve identificar quais são os conjuntos de dados de origem e de destino a serem considerados na consulta. Para realizar essa identifica¸cão, utiliza-se o algoritmo de busca em largura (Breadth-First Search - BFS, em inglês) largamente utilizado em problemas de grafos, que realiza uma busca em n´ıveis de todos os vértices vizinhos a partir de um vértice raiz em um grafo.

Dessa forma, para que dsOrigins e dsDestinations estejam sempre atualizados, mant´em-se uma estrutura de dados de formato array para o armazenamento de todos os conjuntos de dados selecionados, `a qual chamaremos de selected. A cada vez que o usu´ario clica em Save changes para salvar as modifica¸cões, essa estrutura selected ´e atualizada acrescentando-se o id do conjunto de dados selecionado (ou seja, do vértice selecionado) a ela. Porém, caso o usuário queira apenas que o conjunto de dados seja considerado como parte do fluxo de dados e, eventualmente, um vértice de origem ou destino, o usuário deve clicar no bot˜ao Save changes sem selecionar atributos ou colocar condi¸cões, e ent˜ao, o id do conjunto de dados selecionado (ou seja, do vértice selecionado) ´e adicionado a selected. Depois disso, para cada v´ertice em selected, com exce¸cão do que acaba de ser inclu´ıdo, executa-se duas BFS: (i) do vértice que acaba de ser inclu´ıdo (raiz) para todos os outros v´ertices em selected, (ii)

(39)

de cada v´ertice de selected (raiz) para o que acaba de ser inclu´ıdo. Se a BFS retornar verdadeiro, isto é, confirmar que existe um caminho de um vértice a outro, então o id da raiz ´e adicionado à estrutura de dados responsável por salvar os conjuntos de dados de origem e o id do v´ertice em que existe um caminho entre a raiz e ele é adicionado à estrutura de dados responsável por salvar os conjuntos de dados de destino. Caso o retorno seja falso, nada é feito.

5.3 Processamento de consulta

Nesse ponto, a interface gráfica possui todos os parâmetros necessários para a sub-missão da consulta e o seu processamento pelo QI, sendo esses parâmetros apresen-tados na Tabela 5.1.

Tabela 5.1: Especifica¸c˜ao de parˆametros

Parˆametro Definido por

Tipo de rastreamento Usu´ario ou Especialista do dom´ınio Conjuntos de dados de origem Query Interface

Conjuntos de dados de destino Query Interface

Proje¸cão Usuário ou Especialista do dom´ınio Sele¸cão Usuário ou Especialista do dom´ınio

Agora, para a submissão da consulta para o processamento pelo QI, o usuário deve clicar em Run Query. Para o processamento da consulta, deve haver uma re-quisi¸cão que identifique a especifica¸cão do fluxo de dados que o QI deve analisar, como o rótulo da especifica¸c˜ao do fluxo de dados (dataflow tag) e a vers˜ao do fluxo de dados (dataflow id). Isso nos leva a uma requisi¸c˜ao que consiste numa URL que segue o formato: http://localhost:22000/query interface/{dataflow tag}/{dataflow -id}, como na Se¸cão 4.2.4, sendo dataflow tag e dataflow id especifica¸c˜oes recebidas no controle do servi¸co RESTful. Nessa requisi¸cão, é enviada também uma mensa-gem com a discrimina¸cão da consulta, cujo conteúdo é o mesmo do apresentado no exemplo da Subse¸cão 4.2.4.

Depois disso, é feita a chamada ao QI, em que devem ser passadas as informa¸cões capturadas: tag e vers˜ao do fluxo de dados e a mensagem. O QI mapeia, processa e submete a consulta a base de dados utilizando suas otimiza¸cões, retornando o resul-tado em um arquivo CSV que é mostrado em uma forma tabular na página HTML. Além disso, a op¸cão de fazer download deste arquivo é disponibilizada na interface gráfica proposta nesta monografia, caso o usuário ou especialista do dom´ınio queira analisar em outras ferramentas. Vale ressaltar que o uso dos argumentos dsIncludes

(40)

e dsExcludes para a especifica¸c˜ao de consultas pelo QI n˜ao faz parte do escopo desta monografia.

(41)

Cap´ıtulo 6

Resultados obtidos

De acordo com a interface proposta nesta monografia (Cap´ıtulo 5), este cap´ıtulo apresenta os resultados obtidos com o uso interface gráfica desenvolvida para a análise exploratória de dados cient´ıficos. Para isso, utilizamos um fluxo de dados monitorado pela DfAnalyzer em uma aplica¸c˜ao de dinâmica de fluidos computaci-onais (do termo, em inglˆes, Computational Fluid Dynamics, ou da sigla CFD), que visa resolver um problema de sedimenta¸cão [8].

6.1 Simula¸

c˜

ao computacional em dinˆ

amica de

fluidos computacionais

Neste cap´ıtulo, analisamos uma aplica¸cão de sedimenta¸cão usando a ferramenta DfAnalyzer, que tem como finalidade simular a turbidez e perturba¸c˜ao de correntes de fluidos normalmente encontradas em processos geológicos [11]. Os sedimentos que são transportados devido à dinâmica e ao movimento dos fluidos computacionais são descritos como um modelo matemático derivado da combina¸cão de diferentes equa¸cões.

Considerando a complexidade das simula¸cões dessa aplica¸cão, os especialistas do dom´ınio devem rastrear diferentes quantidades de interesse (como res´ıduos, es-timativas de erros, etc.) de forma a controlar o máximo poss´ıvel a execu¸cão [8]. Porém, nem sempre analisar grandezas é suficiente, sendo necessário analisar os da-dos cient´ıficos de diversos arquivos, que foram gerada-dos em diferentes momentos da execu¸cão da simula¸c˜ao computacional. Nesse sentido, a DfAnalyzer provˆe o mo-nitoramento do fluxo de dados, enquanto que a interface gráfica proposta nesta monografia oferece recursos para visualizar resultados de consultas online relaciona-das aos dados de proveniência e aos dados cient´ıficos contidos nos arquivos [11]. A Figura 6.1 mostra o fluxo de dados D gerado por essa simula¸cão de sedimenta¸cão, cujos dados foram armazenados no SGBD MonetDB.