Page 1
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
Page 2
ii
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 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:
_________________________________________________
Vinícius Neves Motta
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
Page 3
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).
Page 4
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.
Page 5
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.
Page 6
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.
Page 7
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.
Page 8
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
Page 9
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
Page 10
x
5 Conclusão 23
Bibliografia 25
Page 11
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
Page 12
xii
Lista de Tabelas
Tabela 1. Tabela contendo os tempos de execução para cada consulta e para cada
solução. ........................................................................................................................... 22
Page 13
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
Page 14
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
Page 15
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.
Page 16
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
Page 17
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.
Page 18
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
Page 19
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.
Page 20
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.
Page 21
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
Page 22
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
Page 23
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.
Page 24
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.
Page 25
13
Figura 4. Modelo de Dados para o DM Activation
Figura 5. Modelo de Dados para o DM Workflow
Page 26
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.
Page 27
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.
Page 28
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
FROM hactivity a, hworkflow w
WHERE a.wkfid=w.wkfid
and w.tag like '%SciPhylomics%'
and a.status<> 'FINISHED'
Page 29
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
FROM hactivity a, hworkflow w
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
FROM hactivity a, hworkflow w
WHERE a.wkfid=w.wkfid
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'
Page 30
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
WHERE a.wkfid=w.wkfid
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)
Page 31
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.
Page 32
20
Figura 8. Gráfico comparativo dos tempos de execução da consulta 2.
Figura 9. Gráfico comparativo dos tempos de execução da consulta 3.
Figura 10. Gráfico comparativo dos tempos de execução da consulta 4.
Page 33
21
Figura 11. Gráfico comparativo dos tempos de execução da consulta 5.
Figura 12. Gráfico comparativo dos tempos de execução da consulta 6.
Figura 13. Gráfico comparativo dos tempos de execução da consulta 7.
Page 34
22
Figura 14. Gráfico comparativo dos tempos de execução da consulta 8.
Figura 15. Gráfico comparativo dos tempos de execução da consulta 9.
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.
Page 35
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
Page 36
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.
Page 37
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].
Page 38
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.