CARACTERÍSTICAS DO AMBIENTE DE TESTES

Como forma de mensurar os resultados, utilizamos uma plataforma única durante toda a realização prática deste trabalho, para evitar diferenças computacionais de processamento e de transferência de dados entre os experimentos. Sendo assim, ambos avaliam toda a distribuição dos dados. Os testes foram realizados sob um cluster de apenas um nó para os dois ambientes de teste; e sob um cluster de dois nós através de duas instâncias do Cassandra que são executadas paralelamente em uma mesma máquina apenas. O artigo que fundamenta a aplicação dos testes pode ser encontrado no site oficial do DataStax17. A máquina utilizada possui um processador Intel Core i7 @2.80GHz, com 24.0 GB de memória RAM e HD SSD Samsung de 256GB, executando Windows 7 Ultimate 64-bit como sistema operacional. Todas as bases de dados foram armazenadas em uma única unidade de disco, e, durante a execução de todas as transformações e consultas, foram utilizados apenas os processos padrões do Windows, além do processo da própria ferramenta. A versão do Java instalada e utilizada é a 1.7.

Para configurar o ambiente de testes do banco de dados no MySQL, instalamos o software MySQL Installer 5.6, que inclui todo o pacote de ferramentas necessárias para a criação e definição de campos e tabelas, assim como a geração dos índices e relacionamentos entre todas tabelas. Estes elementos representam a estrutura física do banco de dados MySQL, que, a partir deste momento, está preparado para a carga dos dados na etapa de ETL.

Uma vez definido o Cassandra como o tipo de SGBD a ser utilizado e comparado com o MySQL, precisamos armazenar os dados e processá-los, para, somente então, responder a todas as consultas necessárias. Foi utilizada uma versão estável do Cassandra neste trabalho de forma a garantir que os erros de projeto fossem minimizados (Apache Cassandra 2.1.5). Definimos, neste momento, o ambiente que vamos utilizar, para que possamos estudar e comparar os resultados das consultas de acordo com as métricas pré-estabelecidas.

Configurar o ambiente Cassandra no Windows é uma tarefa que exige um esforço maior, se comparado ao Linux. Deste modo, o tempo para configuração impactou diretamente no cronograma de desenvolvimento do trabalho.

Conforme o manual disponível no site oficial do Cassandra, o processo de instalação deve seguir algumas etapas estritamente necessárias para que a configuração do cliente/servidor Cassandra esteja correta. Em primeiro lugar, efetuamos o download de uma

versão binária estável do site oficial do Apache Cassandra e, após nos certificarmos de que o Java SDK foi previamente instalado, configuramos as variáveis de ambiente JAVA_HOME e CASSANDRA_HOME.

Com o Java instalado e configurado, estabelecemos o diretório de armazenamento de todas as tabelas do Cassandra no arquivo Cassandra.yaml, da pasta conf. Ao abrirmos o arquivo, procuramos as linhas onde estiver escrito “/var/lib/cassandra”, e alteramos para o caminho da aplicação no Windows, como, por exemplo, “C:/Cassandra”.

Por último, acessamos o diretório C:\Cassandra\bin e abrimos o arquivo cassandra.bat. E, finalmente, após executarmos todos os passos, temos o servidor Apache Cassandra funcionando.

Assim como outros SGBDs NoSQL, o Cassandra não suporta transações ACID, e também não suporta JOINs. Quando um usuário precisa unir duas famílias de colunas, é necessário recuperar e unir os dados separadamente. Este é um processo computacionalmente caro e demorado caso o banco seja muito grande. Por isso, decidimos armazenar a maior quantidade de dados possível em uma mesma linha na tabela fato, de forma a tornar a recuperação mais eficiente. Sendo assim, as consultas foram respondidas da melhor maneira possível.

Ao final dos experimentos, desenvolvemos as visualizações ad-hoc das consultas, tanto no MySQL quanto no Cassandra, de acordo com o que foi proposto pelo projeto MultiLOD, nas bases de dados do modelo multidimensional, no Cassandra. Com isso, fomos capazes de responder a diversas perguntas, no que tange ao desempenho das consultas de acordo com as métricas estabelecidas. Caso o desempenho não se mostrasse satisfatório, deveríamos analisar novamente os relacionamentos feitos entre as tabelas do modelo, e, se necessário, refazer o modelo construído.

4.1.2 Características da aplicação

Após a configuração inicial dos dois ambientes de testes, e definidas todas as fontes de dados e suas características, estabelecemos o planejamento, que serviu de base para o ETL e, consequentemente, para a análise e visualização dos resultados. Fez-se necessário colocar a modelagem dos dados como um critério obrigatório nesta etapa de planejamento. Desenhamos o modelo multidimensional em uma ferramenta apropriada, que utiliza uma notação adequada para tal. A notação de modelagem recomendada para os modelos de dados, por padrão, é a IE (Information Engineering ou Engenharia da Informação). Com isso, foi escolhida uma ferramenta CASE (do inglês Computer-Aided Software Engineering) —

EDraw Max 7.2 — como forma de representar a construção dos modelos lógicos, fiéis ao modelo físico do banco de dados. Esta ferramenta simplifica a modelagem, criação e manutenção de bases de dados, data warehouses, entre outros modelos de dados. Ela não apenas permite que o usuário defina as necessidades e regras na forma de um modelo de dados lógico, mas também que as converta em seu equivalente físico para um dos bancos de dados suportados. Neste trabalho, no entanto, não exploramos esta funcionalidade.

Utilizamos também neste trabalho a versão gratuita do software Navicat for MySQL (Windows) 9.1.8 para manipular os dados armazenados nesse sistema de banco de dados, pois, comparado ao MySQL Workbench (uma das ferramentas do MySQL Installer), ele se comportou como uma poderosa ferramenta para a administração e desenvolvimento de todo o banco de dados MySQL. A ferramenta possui amplo suporte para a administração e construção de servidores de banco de dados MySQL, além de ser utilizada por empresas conceituadas, como Google e Apple. Possui, como uma de suas principais características, a de ser um aplicativo sofisticado, voltado a desenvolvedores profissionais, e, ao mesmo tempo, de fácil entendimento para os iniciantes. Durante todas as fases do ETL, alimentamos a base relacional carga_ping com os dados oriundos das diversas fontes de dados mencionadas anteriormente, e, logo em seguida, carregamos todos os dados dessa base para a base multidimensional carga_ping_dwh. Para isso, foi utilizado o software Pentaho Data Integration (PDI) 5.2 também usualmente conhecido como Kettle. Conforme foi descrito no capítulo anterior, este software tem como finalidade realizar soluções de ETL a partir de diversas fontes de dados, sendo eles estruturados ou não.

O Kettle possui quatro programas que são utilizados em diferentes fases de desenvolvimento e deploy: Spoon, Kitchen, Pan e Carte. Nesta etapa, que compreende o ETL, focamos apenas na ferramenta Spoon, que é a IDE do Kettle, e essencial para toda a fase de desenvolvimento de um ETL. Alguns conceitos básicos do Kettle foram definidos antes, para o entendimento do processo de ETL. São eles: transformations ou transformações (que é a nomenclatura utilizada durante o trabalho), steps e jobs.

Uma transformação é o principal elemento do processo de ETL. Em linhas gerais, ela pode ler dados de arquivos ou tabelas, manipular, filtrar e “limpar” esses dados, e inseri-los em uma base de dados ou em um arquivo CSV, por exemplo. A transformação é composta por um ou mais steps. É importante ter em mente que cada step é executado em paralelo em uma transformação.

Um step faz parte de uma transformação, e pode ter diversas funcionalidades, tais como: ler dados estruturados (e.g.: bases de dados relacionais, CSV); ler dados não estruturados

(e.g.: arquivos de texto); executar alterações sobre esses dados; e, também, escrever dados em algum arquivo ou base de dados. Neste trabalho não descrevemos a funcionalidade de cada step. Porém, existe uma enorme variedade de steps que são listados na documentação do Spoon.18

Um job, entre outras funcionalidades, pode executar um conjunto de transformações, capturar qualquer erro que a execução de uma transformação possa gerar, e salvar logs dessas execuções, por exemplo. Um job consiste de diversas entradas de outros jobs e/ou transformações, que podem se equiparar aos steps de uma transformação. Ao contrário das transformações, os jobs são executados respeitando a ordem dos steps.