GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE...

MODELAGEM DE UM DATA WAREHOUSE DE DADOS

DE PROVENIÊNCIA EM UM AMBIENTE DISTRIBUÍDO

PARA OTIMIZAR EXPERIMENTOS CIENTÍFICOS

Vinícius Neves Motta

Projeto de Graduação apresentado ao Curso de

Engenharia de Computação e Informação da

Escola Politécnica, Universidade Federal do Rio

de Janeiro, como parte dos requisitos necessários à

obtenção do título de Engenheiro.

Orientadora: Profª. Marta Lima de Queirós

Mattoso

Rio de Janeiro

Março de 2015

ii

MODELAGEM DE UM DATA WAREHOUSE DE DADOS

DE PROVENIÊNCIA EM UM AMBIENTE DISTRIBUÍDO

PARA OTIMIZAR EXPERIMENTOS CIENTÍFICOS


PROJETO DE GRADUAÇÃO 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

Autor:

_________________________________________________


Orientador:

_________________________________________________

Profa. Marta Lima de Queirós Mattoso

Coorientador:

_________________________________________________

Prof. Flavio da Silva Costa

Examinador:

_________________________________________________

Prof. Alexandre Assis

Rio de Janeiro – RJ, Brasil

Março de 2015

iii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

iv

DEDICATÓRIA

Ao meu irmão e minha mãe, que me deram o apoio e a base necessários para o

sucesso na realização desse trabalho e durante toda a graduação.

v

AGRADECIMENTO

Agradeço primeiramente à minha mãe e ao meu irmão, que apesar das

dificuldades impostas pela vida, me deram o apoio necessário para que eu pudesse

seguir em frente e concluir esse curso de graduação.

Agradeço à professora Marta Lima de Queirós Mattoso e ao professor Flavio da Silva

Costa, respectivamente orientadora e coorientador, pelos conselhos e orientações que

tornaram esse trabalho possível.

Agradeço ainda aos meus amigos e colegas de faculdade, pelo apoio e ajuda,

durante toda essa jornada de graduação.

vi

RESUMO

À medida que o uso de computadores vem se tornado mais frequente em experimentos

científicos, a utilização de infraestrutura virtualizada tem se tornado uma alternativa aos

custosos investimentos em hardware. Além de processar as simulações precisamos

conceber boas estratégias para armazenar os dados gerados por estas simulações. Isto é

crucial, pois com uma quantidade enorme de dados que são gerados, a solução mais

eficiente, garante ao usuário um melhor desempenho. Como diversas novas soluções

têm surgidos, devemos testá-las para avaliar possíveis ganhos de desempenho e

usabilidade. No nosso trabalho, será avaliado o uso de um data warehouse distribuído,

implementado em nuvem, para armazenar dados de proveniência gerados na execução

de workflows científicos.

Palavras-Chave: Workflow Científico, Bases de Dados Distribuídas, Data Warehouse.

vii

ABSTRACT

The use of computers has been constantly increasing, in the last years. With this

growing user of computer, scientists have been running experiments on virtual

environments more and more. As a consequence, there is a growing need for designing

solutions to store the data generated by these simulations. Because there is an enormous

quantity of data being generated, it is extremely important to choose an efficient

solution, in order to guarantee to the user a better performance. As there are many

solutions being created, the need to test these solutions, searching for a better

performance and usability has being created. On this work, it will be evaluated the use

of a distributed data warehouse on the cloud, to store provenance data that is generated

on the execution of scientific workflows.

Key-words: Scientific Workflow, Distributed Data Base, Data Warehouse.

viii

SIGLAS

UFRJ – Universidade Federal do Rio de Janeiro

SGBD – Sistema de Gerência de Banco de Dados.

SGWfC – Sistema de Gerência de Workflow Científico

DM - DataMart

ix

Sumário

1 Introdução e Motivação

1.1 Motivação: Utilização de Data Warehouse ..............................

1.2 Motivação: Utilização de Bases de Proveniência ....................

1

2

2

2 Datawarehouse

2.1 Modelo Dimensional ................................................................

2.2 Arquitetura ...............................................................................

4

4

6

3 As Bases de Proveniência

3.1 PROV W3C ..............................................................................

3.2 Somente Inserção de Dados .....................................................

3.3 Mais voltado às consultas ........................................................

3.4 Alto volume de dados -> Paralelismo e Distribuição ..............

3.5 Em geral as consultas estão pré-programadas para o cientista

4 Experimentos

4.1 Descrição dos Esquemas .........................................................

4.2 Implementação Física .............................................................

4.3 Descrição das Consultas .........................................................

4.3.1 Consulta 1 ................................................................

4.3.2 Consulta 2 ................................................................

4.3.3 Consulta 3 ................................................................

4.3.4 Consulta 4 ................................................................

4.3.5 Consulta 5 ................................................................

4.3.6 Consulta 6 ................................................................

4.3.7 Consulta 7 ................................................................

4.3.8 Consulta 8 ................................................................

4.3.9 Consulta 9 ................................................................

4.4 Análise de Desempenho .........................................................

8

8

9

10

10

10

12

12

14

16

16

16

16

17

17

17

18

18

18

18

x

5 Conclusão 23

Bibliografia 25

xi

Lista de Figuras

Figura 1. Exemplo de tabela de fatos. .............................................................................. 5 Figura 2. Exemplo de tabela de dimensões. ..................................................................... 6 Figura 3. Modelo de captura de proveniência do SciCumulus. ........................................ 9 Figura 4. Modelo de Dados para o DM Activation......................................................... 13 Figura 5. Modelo de Dados para o DM Workflow ......................................................... 13

Figura 6. Modelo de Dados para o DM Activity. ............................................................ 14 Figura 7. Gráfico comparativo dos tempos de execução da consulta 1. ......................... 19 Figura 8. Gráfico comparativo dos tempos de execução da consulta 2. ......................... 20 Figura 9. Gráfico comparativo dos tempos de execução da consulta 3. ......................... 20

Figura 10. Gráfico comparativo dos tempos de execução da consulta 4. ....................... 20 Figura 11. Gráfico comparativo dos tempos de execução da consulta 5. ....................... 21 Figura 12. Gráfico comparativo dos tempos de execução da consulta 6. ....................... 21 Figura 13. Gráfico comparativo dos tempos de execução da consulta 7. ....................... 21

Figura 14. Gráfico comparativo dos tempos de execução da consulta 8. ....................... 22 Figura 15. Gráfico comparativo dos tempos de execução da consulta 9. ....................... 22

xii

Lista de Tabelas

Tabela 1. Tabela contendo os tempos de execução para cada consulta e para cada

solução. ........................................................................................................................... 22

1

Capítulo 1

Introdução e Motivação

Devido à rápida evolução da tecnologia, a utilização de computadores para o

avanço da pesquisa científica é cada vez mais uma realidade. Em especial na criação e

na execução de experimentos científicos apoiados por computador. A possibilidade de

se fazer simulações em computadores se tornou uma ferramenta cada vez mais poderosa

devido ao rápido crescimento da capacidade de processamento computacional. Para

executar todas as etapas dessas simulações, frequentemente, se utiliza diferentes

softwares. Cada etapa é uma atividade, a qual deve ser executada para que seus

resultados possam ser utilizados por outra atividade, gerando uma dependência entre

elas. Este conjunto de atividades encadeadas é o que chamamos de workflow científico.

O software que possibilita a execução de um workflow científico é chamado de Sistema

de Gerência de Workflows Científicos (SGWfC), sendo responsável pela execução do

workflow científico, assim, garantindo a execução de todas as suas atividades na ordem

correta.

Um workflow científico pode ser executado com diversas configurações e

diversas entradas de dados de forma a procurar a maneira mais eficiente e/ou rápida de

se executar este workflow, ou ainda, qual é a configuração que trará o melhor resultado,

no contexto do experimento em desenvolvimento. Por este motivo, é importante não só

armazenar os resultados gerados pela execução das atividades de um workflow, mas,

também, os dados de execução do mesmo. Com estes dados o cientista é capaz de

determinar qual é a melhor configuração para a execução de um determinado workflow

científico. Estes dados que são gerados sobre a execução de um workflow são chamados

de proveniência. Por executarem o mesmo experimento inúmeras vezes e pelo fato de

cada execução gerar uma grande quantidade de dados, uma opção que pode ser adotada

é utilizar um Sistema Gerenciador de Banco de Dados (SGBD) para armazenar os dados

de proveniência.

Além da complexidade dos experimentos, existe ainda a complexidade de

trabalhar de forma cooperativa em um ambiente distribuído. Pois o usuário nem sempre

tem acesso à proveniência gerada por outro cientista, que já pode ter executado o

2

mesmo experimento que ele. Não só isso, o usuário pode não saber onde acessar tal

informação[13]. Por isso, há uma necessidade de se repensar o modo de armazenamento

dos dados de proveniência, garantindo que os usuários possam, não só ter um acesso

facilitado aos dados de proveniência gerados por outros usuários, mas também saber

que estes dados existem.

Este trabalho tem como objetivo avaliar a utilização de data warehouses de

dados de proveniência por meio da análise do desempenho de consultas representativas

do cenário real. E ainda, avaliar a utilização deste data warehouse em um ambiente

distribuído.

Este projeto de graduação está dividido em 5 capítulos, sendo esta introdução o

primeiro capítulo. O capítulo 2 explicita o conceito de data warehouse e apresenta qual

solução foi implementada. O capítulo 3 trata das bases de proveniência e das suas

características. O capítulo 4 explica detalhadamente o que foi realizado nos

experimentos e como eles foram conduzidos. Por fim, o capítulo 5 apresenta a

conclusão deste trabalho.

1.1 Motivação: Utilização de Data Warehouse

Data warehouses são extensamente usados no meio corporativo para o

armazenamento de enormes quantidades de dados, no entanto, pouco utilizado em

universidades[1]. Considerando-se que execuções de workflows científicos geram

grandes quantidades de dados de proveniência torna interessante o estudo de viabilidade

da utilização de data warehouses para armazenar tais dados.

Existem diversas formas de se desenvolver um data warehouse, utilizando-se de

modelo relacional ou modelo não-relacional de dados. Além disso, data warehouses são

concebidos para armazenamento e o processamento de grandes quantidades de dados de

forma eficiente, propiciando organização e recuperação rápida dos dados armazenados.

1.2 Motivação: Utilização de Bases de Proveniência

Pelo fato dos cientistas realizarem diversas simulações computacionais em seus

experimentos, muitos dados de proveniência são gerados e armazenados na base de

dados. No entanto, os cientistas tendem a fazer a mesma consulta na mesma base de

dados repetidas vezes, alterando somente os parâmetros da consulta, pois o interesse dos

3

cientistas é analisar as informações geradas pelos experimentos. Do mesmo modo,

SGWfC que fazem uso de proveniência, também rodam consultas com o mesmo

formato, alterando apenas os parâmetros de busca. Além disso, como nas bases de

proveniência só há inserção e consulta de dados, as regras do banco de dados não

precisam ser tão rígidas, pois não há remoção ou atualização de valores nestas bases.

Sendo assim, uma de nossas motivações neste trabalho foi buscar estratégias que

otimizassem o acesso aos dados de proveniência.

4

Capítulo 2

Data Warehouse

Data warehouses são amplamente usados por empresas para armazenar dados.

Isto ocorre, pois há uma produção cada vez maior de informação. Informação esta que

precisa ser armazenada, pois, frequentemente, ela é vital para a empresa. Além disso, há

a necessidade de poder acessar grandes quantidades de dados de variadas maneiras e de

forma eficiente.

Em específico, neste projeto de graduação, os dados de proveniência precisam

ser armazenados e acessados de forma eficiente e de diversas formas. Estes dados são

necessários, pois precisamos analisar o desempenho da execução dos workflows

científicos e tornar mais rápidas e eficientes as próximas execuções. E, com este

objetivo, este projeto de graduação se propõe a avaliar o uso de data warehouses.

Um dos principais objetivos de um data warehouse é armazenar os dados de

forma segura e bem organizada garantindo o acesso otimizado a estes.

Este capítulo irá detalhar o conceito de data warehouse e o modo pelo qual este

pode ser implementado. Primeiramente, explicaremos o modelo de dados utilizado para

a construção de um data warehouse, a arquitetura do mesmo e sua implementação em

um SGBD.

2.1 Modelo Dimensional

O primeiro passo para se construir um data warehouse é a concepção de como

ele organizará os dados armazenados, isto é, como será seu modelo de dados.

Diferentemente da maioria dos bancos de dados, que utilizam um modelo relacional, um

data warehouse utiliza o modelo dimensional. Este modelo, concebido nos anos 70, foi

estruturado de forma dimensional, de modo a atender a necessidade humana de

simplicidade[1].

Esta simplicidade se traduz em tornar simples as operações realizadas em cima

do data warehouse, como, por exemplo, Rollup, Drill-Down, Slice-Dice e Pivot[2].

Estas operações envolvem o agrupamento e detalhamento de certos dados e a filtragem

5

dos mesmos. Num data warehouse estas operações são fundamentais devido à

quantidade de dados armazenados.

Na modelagem dimensional, os dados são organizados em dois tipos de tabela:

Tabelas de fatos e tabelas de dimensões.

As tabelas de fatos são as tabelas que, usualmente, armazenam medidas, sejam

elas medidas do desempenho de um software, como a quantidade de produtos vendidos

em uma transação financeira com um consumidor.

Fatos podem ser numéricos ou não, além de, se forem numéricos, poderem ser

aditivos, semiaditivos ou não aditivos. Fatos aditivos são aqueles que podem ser

somados em qualquer condição, tal qual a quantidade de dólares por venda. Fatos

semiaditivos são aqueles que podem ser somados em determinadas condições. E,

finalmente, fatos não aditivos são aqueles que não podem ser somados em condição

nenhuma. É importante ressaltar que deve se priorizar fatos aditivos, pois raramente o

usuário pede por somente uma linha da tabela de fatos, mas, sim, um conjunto delas[1].

Fatos aditivos são capazes de condensar informações com grande facilidade e me

retornar informações como, por exemplo, o total de dólares obtidos nas vendas do dia.

Além disso, fatos são interseccionados com dimensões, tais como tempo e data,

que definem a granularidade do fato. Quanto maior a quantidade de dimensões

interseccionadas com uma tabela de fatos, com maior detalhamento um fato é

armazenado na tabela, isto é, o fato possui uma maior granularidade.

Apesar de ser possível ter fatos textuais, é importante ressaltar que isto deve ser

evitado ao máximo, pois fatos textuais são mais difíceis de se analisar[1], pois tabelas

de fato normalmente contêm milhões de linhas. É importante notar, também, que a

maioria dos casos em que se encontra fatos textuais, eles podem ser facilmente retirados

da tabela de fatos e serem colocados em uma tabela de dimensões.

Por fim, é importante notar que toda tabela de fatos possui duas ou mais chaves

estrangeiras, pois, usualmente, elas contêm duas ou mais dimensões. Na Figura 1 temos

um exemplo de uma tabela de fatos.

Figura 1. Exemplo de tabela de fatos.

6

A tabela de dimensões é a tabela que contém a descrição textual do “negócio”.

Normalmente, contém muitas colunas ou atributos, que descrevem uma linha em uma

tabela de dimensões[1]. Diferentemente das tabelas de fatos, as tabelas de dimensões

contêm poucas linhas, apesar de cada linha conter muita informação.

Este tipo de tabela, normalmente, é o mais importante para buscas com filtros,

tais como datas, computadores, empresas, produtos. Tabelas de dimensões bem

construídas são a chave para a usabilidade e a legibilidade de um data warehouse [1].

Por isto, é importante que se tome grande cuidado ao construir uma tabela de

dimensões.

Ao se construir uma tabela de dimensões, é importante que todos os atributos

tenham nomes que os descrevam bem. É por meio destes atributos que a maioria das

buscas com filtro serão feitas. Então, é importante que o usuário consiga saber

facilmente qual atributo ele vai utilizar como restrição para obter os resultados

desejados em uma consulta. É importante, também, evitar o uso de abreviações ao

escolher o nome para um atributo, pois nem todos os usuários serão especialistas no

assunto. Por fim, quanto mais se trabalha para se encontrar nomes adequados para os

atributos de uma tabela de dimensões, mais legível fica o data warehouse, acarretando

em melhor usabilidade do mesmo.

Os valores que cada atributo pode assumir pode ser tanto numérico, quanto

textual. No caso dos valores numéricos, é importante analisar corretamente se este valor

numérico é um fato ou uma característica de uma dimensão do data warehouse, isto é

crucial para melhorar sua usabilidade..

Por fim, na Figura 2, mostramos um exemplo de tabela de dimensões.

Figura 2. Exemplo de tabela de dimensões.

2.2 Arquitetura

Há variadas arquiteturas utilizadas para projetar um data warehouse, uma das

mais utilizadas, atualmente, é a chamada arquitetura bottom-up apresentada por

Kimball[1][2]. Esta arquitetura é preferida, pois o desenvolvimento do data warehouse

7

é feito de forma incremental, evitando quaisquer problemas relacionados a necessidades

novas que surjam no caminho.

Primeiramente, é necessário entender como é organizado um data warehouse.

Um data warehouse, usualmente, é composto por Data Marts(DM). Os DMs são

subconjunto de dados do data warehouse. Cada DM contém um subconjunto de dados

direcionado a um tipo de usuário final. Isto é vantajoso, pois permite o acesso

descentralizado ao data warehouse, além de conseguir garantir um melhor atendimento

à demanda do usuário final[2].

A arquitetura bottom-up procura explorar as vantagens do uso de DMs para

construir um data warehouse. Esta arquitetura permite a construção incremental do

data warehouse por meio de DMs independentes. Além disso, isto permite um

desenvolvimento mais acelerado do data warehouse, pois é possível o desenvolvimento

de vários DMs ao mesmo tempo. Também é importante destacar que facilita o enfoque

na construção de um data warehouse que atenda as necessidades principais do problema

em questão.

No entanto, apesar da facilidade de desenvolvimento do data warehouse por

meio desta arquitetura, ela facilita a criação de um data warehouse com redundância de

dados. Por isso, é importante atentar para a conformidade das tabelas de dimensões dos

DMs[1], a qual garante que não haja redundância de dados a medida que se constrói

novos DMs. Na prática, a conformidade das tabelas de dimensões se traduz na

utilização da mesma tabela de dimensões para datas em diferentes DMs, o que evita a

redundância de dados.

Para garantir esta conformidade das tabelas de dimensões entre DMs foi criada

uma ferramenta chamada Data Warehouse Bus Matrix. Esta ferramenta é uma tabela na

qual as linhas são os nomes dos DMs e as colunas são as tabelas de dimensões

existentes no data warehouse. Nesta tabela, marca-se quais tabelas de dimensões cada

DM contém, o que é importante para verificar quais tabelas podem ser utilizadas por

mais de um DM e quantas tabelas de dimensões cada DM tem.

8

Capítulo 3

As Bases de Proveniência

A palavra proveniência, segundo o dicionário Aurélio [9], significa: “1. Lugar

de onde alguma coisa provém: procedência. 2. Fonte, procedência, origem.”.

Com essa definição em mente caracterizamos uma base de proveniência como

uma base de dados cuja fonte, procedência ou origem vem de informações de

experimentos científicos.

As bases de proveniência, no que diz respeito a esse trabalho, são aquelas

criadas no intuito de armazenar as informações relativas à execução de um

determinado workflow científico. Com essas informações é possível validar os

resultados obtidos ou utilizar os dados referentes às configurações de execuções

anteriores como parâmetro para novas execuções.

A base de proveniência cujas consultas foram utilizadas nesse trabalho foi

oriunda do SciCumulus [10]: uma solução computacional para atender as fases do

ciclo de vida de um workflow executado em nuvem.

3.1. PROV W3C

A W3C (World Wide Web Consortium) [11] é uma comunidade internacional

onde as organizações membros, profissionais em tempo integral e o público

trabalham juntos para desenvolver padrões para a Web.

A W3C possui uma família de especificações para modelar uma base de dados

de proveniência, a PROV. De acordo com [12], proveniência é informação sobre

entidades, atividades e pessoas envolvidas na produção de um conjunto de dados ou

coisa, que podem ser usadas para formar avaliações sobre a sua qualidade,

confiabilidade ou confiança.

Segundo [10], o modelo de captura de proveniência do SciCumulus segue as

recomendações do W3C e é apresentado abaixo na Figura 3.

9

Figura 3. Modelo de captura de proveniência do SciCumulus.

Do modelo de dados acima, as principais entidades são: Atividade, Workflow e

Cloud Activity. Estas entidades guardam os dados mais importantes de proveniência,

que são os dados de tempo de execução de workflow, atividades do workflow e

ativações de atividade, dados de quais execuções já foram terminadas, etc. Estes

dados são importantes para a melhoria do desempenho de uma simulação que seja

feita novamente por um usuário.

3.2. Somente Inserção de Dados

Enquanto o workflow está em execução, os seus dados de proveniência estão

sendo inseridos na base de dados. Os dados são apenas inseridos ou consultados,

não havendo atualizações ou remoções dos valores dessa base de dados realizada

10

pelo programa que está executando o workflow ou pelos cientistas que a utilizam.

Essa característica promove a necessidade de regras não tão rígidas quanto as

impostas pelos bancos relacionais.

3.3. Mais voltado às consultas

Como citado na subseção anterior, a base de dados sofre apenas inserção e

consultas de dados. Porém, enquanto os dados para cada workflow são inseridos

apenas uma vez, os dados referentes a ele podem ser consultados diversas vezes, por

vários cientistas. Logo, o número de consultas realizadas sobre essa base de dados

de proveniência é bem maior que o número referente às inserções feitas nela.

3.4. Alto volume de dados Paralelismo e Distribuição

Os sistemas que gerenciam as execuções dos workflows podem gerar grandes

volumes de dados, fazendo com que a base de dados gerenciada pelo SGBD possa

crescer muito. Para trabalhar com essa grande quantidade de informação é

interessante que as consultas possam ser realizadas de forma paralela em um

ambiente otimizado, para que o tempo de resposta das mesmas seja reduzido,

utilizando a presença de vários processadores e discos trabalhando paralelamente.

Não só isso, mas também há o fato de que, usualmente, pesquisas não são

conduzidas somente por um cientista ou por um grupo de pesquisa [13]. Por isso, a

concepção de um armazenamento distribuído desses dados é bastante atraente. Não

só por promover uma maior agilidade no trabalho de um grupo de pesquisa, mas

também, por promover a possibilidade do uso da proveniência da execução da

mesma simulação de outro grupo de pesquisa, podendo otimizar as execuções desta

simulação, o que agiliza o trabalho de pesquisa.

3.5. Em geral as consultas estão pré-programadas para o cientista

As consultas executadas pelos cientistas, em muitos casos, já se encontram

prontas, uma vez que eles querem sempre as mesmas informações referentes às

execuções de seus workflows. Elas são executadas por eles alterando apenas os seus

parâmetros, para que os dados retornados por elas correspondam aos workflows

escolhidos. Do mesmo modo ocorre nos SGWfC baseados no uso de proveniência

tais como o SciCumulus. Assim, não há a necessidade de que o sistema gerenciador

11

de banco de dados possua suporte ao SQL (Structured Query Language), uma vez

que as consultas podem ser respondidas com auxílio de linguagem de programação

ou outro tipo de banco de dados sem SQL. Além disso, o modelo usado para

armazenar os dados poderia ser melhorado em função das consultas que já se

encontram prontas, usando um banco de dados não relacional que não possua uma

forma rigorosa para criar o modelo de dados.

12

Capítulo 4

Implementação

Neste capítulo serão apresentadas e descritas todas as informações relevantes

sobre o processo da criação e execução dos experimentos. Como o objetivo do trabalho

é avaliar o desempenho de um data warehouse distribuído que armazene os dados de

proveniência, analisando o tempo de execução das consultas que foram desenvolvidas

para serem executadas originalmente no PostgreSQL[3].

4.1 Descrição dos esquemas

No capítulo 3, foi descrito o esquema usado para armazenar os dados de

proveniência do SciCumulus. Nesta seção, será descrita a criação do esquema do data

warehouse a ser utilizado nos experimentos.

No capítulo 2, foi explicitado como se constrói um data warehouse utilizando-se

uma arquitetura bottom-up e modelo dimensional. Para o nosso DW, foram

desenvolvidos 3 DMs: Activation, Workflow, Activity.

No primeiro DM, são armazenadas as informações relativas a execução de

ativações, ele contém cinco tabelas: Activation Executions, Date, Workflow, Activity,

Time, Computer, a Figura 4 mostra como foi modelado o DM.

No segundo DM, são armazenadas as informações relativas à execução de

workflows, ele contém quatro tabelas: Workflow Executions, Workflow, Date, Time, a

Figura 5 mostra como foi modelado o DM.

No terceiro, e último, DM, são armazenadas as informações relativas a execução

de atividades, ele contém cinco tabelas: Activity Executions, Activity, Workflow, Time,

Date, a Figura 6 mostra como foi modelado o DM.

Estes 3 DMs foram desenvolvidos de forma incremental e compõem o data

warehouse.

13

Figura 4. Modelo de Dados para o DM Activation

Figura 5. Modelo de Dados para o DM Workflow

14

Figura 6. Modelo de Dados para o DM Activity.

Neste data warehouse, as tabelas Activity Executions, Workflow Executions e

Activation Executions são as tabelas de fatos, e as tabelas Time, Date, Workflow, Date e

Computer são as tabelas de dimensões.

4.2 Implementação Física

Nesta seção será descrita quais foram os passos para a implementação do

datawarehouse distribuído na nuvem.

Inicialmente, o datawarehouse foi implementado no PostgreSQL[3], que está

hospedado em um servidor da Amazon[4]. A implementação, neste caso, não foi

distribuída, mas, somente, em um servidor.

15

Após a implementação inicial no servidor da Amazon, prosseguiu-se para a

implementação de um datawarehouse distribuído. Houve a tentativa de fazer esta

implementação em várias soluções de SGBDs paralelos em busca de uma que atendesse

aos requisitos. Isto se deu, pois o ambiente da nuvem torna a implementação de um

banco de dados distribuído mais complexa. As soluções de paralelismo existentes nem

sempre são adaptáveis para serem usadas na nuvem, o que motivou a procura por

diversas soluções, como irá ser demonstrado abaixo.

A primeira alternativa, foi procurar uma solução para paralelismo já oferecida

pelo PostgreSQL. No entanto, até o presente momento, só é possível ter um banco de

dados paralelo com o uso de software externo desenvolvido por si mesmo [5].

A segunda alternativa, foi o plugin PgPool-II [6], que pode ser integrado ao

PostgreSQL para a criação de bancos de dados paralelos, só necessitando de ter os

bancos de dados criados em cada servidor que será utilizado para a criação do banco de

dados paralelo. No entanto, o plugin se mostrou incompatível com o PostgreSQL (pelo

menos para nuvem) e incompleto, apresentando diversos problemas mesmo quando

somente implementando o banco de dados mostrado no tutorial.

A terceira alternativa, foi o software Postgres-XC [7], que é uma versão do

PostgreSQL com recursos para paralelismo. No entanto, ela só oferece o recurso da

replicação de bancos de dados em diferentes servidores.

A quarta alternativa, foi o software SQL Server [8], que é um SGBD oferecido

pela Microsoft. É um SGBD robusto, oferecendo bom desempenho para consultas em

Bancos de Dados com enormes quantidades de dados. No entanto, este SGBD não

oferece solução para bancos de dados paralelos na nuvem. O único paralelismo utilizado

neste SGBD é no momento de fazer uma consulta ao banco de dados, utilizando-se dos

núcleos do processador para paralelizar a execução desta consulta.

Por fim, foi utilizado o software NuoDB [14], que oferece uma solução de

paralelismo na nuvem. Este software é um SGBD com suporte a paralelismo,

oferecendo o uso de banco de dados paralelos em 2 ou mais servidores. Todas as

operações a serem feitas no NuoDB podem ser feitas por uma interface web. Foi

necessário implementar o data warehouse novamente no NuoDB devido ao fato de não

ser integrado ao PostgreSQL e por ter pequenas diferenças na hora da criação de

tabelas. É possível, também, modificar o banco de dados paralelo de qualquer dos

servidores usados por ele.

16

4.3 Descrição das Consultas

As consultas escolhidas foram apontadas pelos especialistas como sendo um

conjunto representativo do universo de consultas utilizadas. Cada uma delas apresenta

ao cientista informações sobre os experimentos, que são sinalizados para as consultas

por meio de parâmetros, gerando assim uma espécie de relatório sobre os mesmos.

As consultas escolhidas seguiram o critério de determinação de consultas

representativas do universo de consultas utilizadas apresentado em [15]. O que torna a

análise de desempenho destas consultas uma análise representativa do caso real.

4.3.1 Consulta 1

SELECT a.tag, a.description

FROM hactivity a, hworkflow w

WHERE a.wkfid=w.wkfid

and w.tag like '%Scimultaneous%'

Esta consulta lista o nome e a descrição das atividades de um determinado

workflow. Como pode ser visto, o parâmetro w.tag é quem filtra o resultado por nome

de workflow.

4.3.2 Consulta 2

SELECT a.tag, t.taskid

FROM hactivation t, hactivity a, hworkflow w

WHERE w.wkfid = a.wkfid

and a.actid = t.actid

and w.tag ='SciPhy'

ORDER BY a.tag

Esta consulta lista as ativações de cada atividade de um workflow especificado

pelo usuário. Como pode ser visto, o parâmetro w.tag é quem filtra o resultado por

nome de workflow.

4.3.3 Consulta 3

SELECT a.actid, a.tag, a.status



and w.tag like '%SciPhylomics%'

and a.status<> 'FINISHED'

17

Esta consulta lista as atividades que não terminaram de ser executadas, seja por

estarem ainda sendo executadas ou por sua execução ter sido interrompida

inesperadamente. Como pode ser visto, o parâmetro w.tag é quem filtra o resultado por

nome de workflow e o parâmetro a.status é quem filtra o resultado por status de

execução.

4.3.4 Consulta 4

SELECT a.actid, a.tag, date_part('epoch',endtime - starttime )*1000 as duracao


WHERE a.wkfid=w.wkfid and a.status= 'FINISHED'

and w.tag like '%SciEvol%'

Esta consulta lista a duração da execução das atividades que já tiveram sua

execução completa de um determinado workflow. Como pode ser visto, o parâmetro

w.tag é quem filtra o resultado por nome de workflow e o parâmetro a.status é quem

filtra o resultado por status de execução.

4.3.5 Consulta 5

SELECT a.actid, a.tag, starttime



and w.tag like '%Scimultaneous%' and a.status='RUNNING'

Esta consulta lista o instante de início de execução das atividades que não

tiveram sua execução completa de um determinado workflow. Como pode ser visto, o

parâmetro w.tag é quem filtra o resultado por nome de workflow e o parâmetro a.status

é quem filtra o resultado por status de execução.

4.3.6 Consulta 6

SELECT x.taskid, date_part('epoch',x.endtime - x.starttime )*1000 as duracao

FROM hactivity a, hactivation x

WHERE a.actid=x.actid

and a.tag='raxml'

and x.status='FINISHED'

18

Esta consulta lista a duração da execução das ativações que já tiveram sua

execução completa de uma determinada atividade. Como pode ser visto, o parâmetro

a.tag é quem filtra o resultado por nome de atividade e o parâmetro x.status é quem

filtra o resultado por status de execução.

4.3.7 Consulta 7

SELECT x.taskid, x.exitstatus, x.terr

FROM hactivity a, hworkflow w, hactivation x


and a.actid=x.actid

and (w.tag like '%scievol%' or w.tag like '%SciEvol%')

and x.exitstatus<>0

Esta consulta lista as mensagens de erro das ativações que tiveram um erro em

sua execução para um workflow determinado. Como pode ser visto, o parâmetro w.tag é

quem filtra o resultado por nome de workflow e o parâmetro x.exitstatus é quem filtra o

resultado por status de execução.

4.3.8 Consulta 8

SELECT w.wkfid, w.tag from hworkflow w

WHERE exists (select 1 from hworkflow w2, hactivity a

where w2.wkfid = w.wkfid

and w2.wkfid = a.wkfid

and a.tag = 'modelgenerator')

Esta consulta lista todos os workflows que contém uma atividade específica.

Como pode ser visto, o parâmetro a.tag é quem filtra o resultado por nome de atividade.

4.3.9 Consulta 9

SELECT w.wkfid,w.tag,a.tag,t.exitstatus,t.processor,t.workspace,t.status, 3799,5809

t.endtime,t.starttime,

extract ('epoch' from (t.endtime-t.starttime))||',' as duration

FROM hworkflow w, hactivity a, hactivation t

WHERE w.wkfid = a.wkfid

and a.actid = t.actid

and not exists (select * from hactivation a2

where a2.actid = a.actid

and a2.exitstatus <> 0)

19

Esta consulta lista, por ordem crescente de execuções dos workflows, as datas e horas

de início e término, nomes dos workflows e suas descrições, bem como o nome de todas

as atividades associadas a todas as execuções dos workflows que foram executados e

que não contenham nenhuma ativação que executou com erro.

4.4 Análise de Desempenho

Nesta seção, serão expostos os resultados das consultas no banco de dados

relacional, no data warehouse e no data warehouse distribuído, com o objetivo de

analisar o desempenho das consultas nas diferentes soluções.

Os computadores utilizados como servidores têm as seguintes configurações:

Windows Server 2008 R2, processador intel i7 1.67 GHz, 8 GB de memória RAM e 50

GB de HD.

Nas Figura 7, Figura 8, Figura 9, Figura 10, Figura 11 e Figura 12, temos os

gráficos mostrando de forma comparativa os resultados de cada consulta. É interessante

notar que nos casos em que a diferença de desempenho é pequena, esta diferença

continua sendo importante, pois estas consultas são executadas muitas vezes seguidas, o

que significa que uma diferença de 0,1s em uma execução de consulta, pode se tornar

100s se executarmos esta consulta 1000 vezes.

Figura 7. Gráfico comparativo dos tempos de execução da consulta 1.

20




21




22



Na tabela abaixo, estão expostos os resultados para todas as consultas, para uma

análise quantitativa.

Consultas Banco de Dados Relacional Datawarehouse Datawarehouse distribuído

Consulta 1 0,71s 0,16s 0,09s

Consulta 2 3,3s 0,20s 0,11s

Consulta 3 0,51s 0,25s 0,19s

Consulta 4 0,70s 0,16s 0,08s

Consulta 5 0,62s 0,21s 0,10s

Consulta 6 0,70s 0,16s 0,10s

Consulta 7 0,82s 0,24s 0,12s

Consulta 8 0,82s 0,32s 0,20s

Consulta 9 5,1s 0,52s 0,23s

Tabela 1. Tabela contendo os tempos de execução para cada consulta e para cada solução.

23

Capítulo 5

Conclusão

O objetivo deste trabalho foi analisar o desempenho de um data warehouse

distribuído e implementado na nuvem, utilizando o tempo de resposta das consultas para

verificar a viabilidade do uso dessa tecnologia para armazenar os dados de

proveniência. A tecnologia para a implementação escolhida, foi o software NuoDB

Uma vez definido como seriam armazenados os dados no data warehouse e

escolhido o software a ser utilizado para implementar o data warehouse distribuído,

foram implementadas todas as consultas a serem feitas no data warehouse.

Para fazer a avaliação das consultas, foram obtidos os tempos de resposta por

meio de testes no banco de dados relacional, no data warehouse e no data warehouse

distribuído.

Os tempos obtidos com a execução de consultas no data warehouse distribuído

foi consideravelmente melhor que os obtidos com a execução no banco de dados

relacional. Em média, foi um ganho de 50% ou mais de desempenho, significando uma

execução mais rápida de um SGWfC, pois ele pode consultar metadados mais

eficientemente. Comparando-se a execução do data warehouse com o data warehouse

distribuído, houve uma pequena melhora de desempenho no distribuído, no entanto, é

importante ressaltar que esta pequena melhoria faz uma grande diferença, pois a mesma

consulta pode ser executada muitas vezes seguidas. Além disso, é importante notar que

o data warehouse não foi distribuído em muitos computadores, o que pode significar

que esta melhoria de desempenho pode ser maior num ambiente distribuído com mais

computadores.

Os testes mostraram, também, que a modelagem do data warehouse

proporcionaram uma melhora maior no caso em que deixou-se de usar subconsultas

para fazer consultas com junção de tabelas somente.

A conclusão geral do trabalho é que o data warehouse distribuído, mesmo não

sendo utilizado de forma tradicional, apresentou excelentes resultados. Além de deixar

aberta a utilização de outros recursos de modelagem de data warehouse.

Além disso, para trabalhos futuros, pode-se pensar na utilização de uma maior

quantidade de computadores para o data warehouse distribuído, visando um

aproveitamento maior do paralelismo das consultas. Por fim, refinar o modelo de dados

24

de forma a aproveitar mais as características do modelo dimensional utilizado na

implementação de data warehouse e obter melhor desempenho na recuperação de dados

do data warehouse.

25

Bibliografia

[1] KIMBALL, R., ROSS, M., The Datawarehouse Toolkit, Nova Iorque, John Wiley &

Sons, 2002.

[2] SOARES,V. J. A., Modelagem Incremental No Ambiente De Data Warehouse,

M.Sc. dissertation, Universidade Federal do Rio de Janeiro, Dezembro 1998.

[3] “PostgreSQL: The world’s most advanced open source database”,

http://www.postgresql.org/, 2014, (Acesso em 19 Fevereiro 2015).

[4] “AWS | Amazon Elastic Compute Cloud(EC2)” http://aws.amazon.com/pt/ec2/,

2014, (Acesso em 19 Fevereiro 2015).

[5] “Parallelism in PostgreSQL Comes to Life”,

http://blogs.enterprisedb.com/2014/06/18/parallelism-in-postgres-comes-to-life/,

2014, (Acesso em 23 Fevereiro 2015).

[6] “pgpool-II User Manual”, http://www.pgpool.net/docs/latest/pgpool-en.html, 2014,

(Acesso em 23 Fevereiro 2015).

[7] “Postgres-XC 1.1 Documentation”, http://postgres-

xc.sourceforge.net/docs/1_1/index.html, 2014, (Acesso em 23 Fevereiro 2015).

[8] “Explore SQL Server 2012-2014 | Microsoft”, http://www.microsoft.com/en-

us/server-cloud/products/sql-server/, 2014, (Acesso em 23 Fevereiro 2015)

[9] de H. Ferreira , A.,, Novo dicionário Aurélio da língua portuguesa. Editora

Positivo, 2004.

[10] Oliveira, D., “Uma Abordagem de Apoio à Execução Paralela de Workflows

Científicos em Nuvens de Computadores”, D.Sc. thesis,Universidade Federal do Rio de

Janeiro, 2012.

[11] “World Wide Web Consortium (W3C)”. http://www.w3.org/, 2014. (Acessado

em 24 Fevereiro 2014).

[12] Moreau, L., Missier, P., , “PROV-DM: The PROV Data Model”, abr-2013.

[Online]. Available at: http://www.w3.org/TR/2013/REC-prov-dm-20130430/.

[Acessado: 24-fev-2014].

http://www.postgresql.org/

http://aws.amazon.com/pt/ec2/

http://blogs.enterprisedb.com/2014/06/18/parallelism-in-postgres-comes-to-life/

http://www.pgpool.net/docs/latest/pgpool-en.html

http://www.microsoft.com/en-us/server-cloud/products/sql-server/

http://www.microsoft.com/en-us/server-cloud/products/sql-server/

http://www.w3.org/

26

[13] Mattoso, M., Oliveira, D., Costa, F., “Towards an Adaptative and Distributive

Architecture for Managing Workflow Provenance Data”, In: 10th

IEEE

International Conference on e-Science, São Paulo, 2014.

[14] “NewSQL | Cloud Database | Distributed Database | Scale-Out | NuoDB”,

http://www.nuodb.com/ , 2014, (Acessado em 24 Fevereiro 2015)

[15] Silva, V., Costa, F., Oliveira, D., A. C. S. O., Kary, Mattoso, M., “Towards

Supporting Provenance Gathering and Query in Different Database Approaches”,

In: 6th

USENIX Workshop on the Theory and Practice of Provenance, Cologne,

2014.

GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE...

Documents

Transcript of GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE...