Artigo Modelo de Processo para Criação de BI em Banco de Dados

Modelo de Processo para Criação de BI em Banco de
Dados NoSQL Orientado a Colunas
Leandro Mendes Ferreira
Faculdade de Informática e Administração Paulista
Centro de Pós-Graduação – MBA em Business Intelligence
Rua Olimpíadas, 186 – São Paulo, SP – CEP: 04551-000
[email protected]
Abstract. Business Intelligence applications are widely employed in various
organizations, and main architecture's convergence point is the persistence
Data Warehouse into relational DBMS. This paper proposes an alternative
model for the process of creating a Business Intelligence application based on
Data Warehouse under NoSQL DBMS with the columns model. Processes and
tools are addressed in storage tier, data processing and presentation layer.
Resumo. As aplicações de Business Intelligence são amplamente difundidas
em diversas organizações, e tem como principal ponto de convergência de sua
arquitetura a persistência de dados do Data Warehouse em SGBDs
relacionais. Este artigo propõe um modelo alternativo para o processo de
criação de uma aplicação de Business Intelligence baseada em Data
Warehouse sob SGBD de modelo NoSQL de família de colunas. São abordados
processos e utilização de ferramentas da camada de armazenamento,
processamento de dados e da camada de apresentação.
1. Introdução
Atualmente, as organizações utilizam como parte essencial o Business Intelligence (BI)
para adquirir vantagens competitivas e possuir pleno conhecimento das informações
referentes ao total ecossistema da organização, utilizando as informações internas quanto
dados externos. Com a disponibilização exponencial dos dados, os Data Warehouses
(DWs) vem tornando-se base de dados imensas. Esta demanda traz sérios problemas para
uma plataforma baseada em banco de dados relacionais padrões, pois por natureza o
modelo relacional de dados e as arquiteturas desse tipo de Sistemas Gerenciadores de
Banco de Dados (SGBDs) não foram desenvolvidos para DWs destas grandezas.
Os SGBDs tradicionais possuem problemas de escalabilidade, principalmente em
nível horizontal. Para atender demandas cada vez maiores, vários fornecedores
disponibilizam appliances, que são as arquiteturas robustas que incluem hardware e
software personalizados. Entretanto, estas estruturas customizadas possuem custos
elevados de implantação, manutenção e atualização, não sendo acessível para maioria
das organizações, além de possuírem recursos e escalabilidade finita e limitada a um
parâmetro determinado de tamanho da base de dados.
Em contrapartida, uma alternativa que pode ser utilizada em ambientes de
software e hardware heterogêneos são os Banco de dados NoSQL, pois sua estrutura e
arquitetura foram desenvolvidas para trabalhar com base de dados de terabytes ou
superiores, com alta disponibilidade e escalabilidade horizontal irrestrita.
Diante dos contextos apresentados, o presente artigo apresenta a discussão da
arquitetura de BI, os SGBDs NoSQL além de sugerir um modelo de implementação de
sistema de BI em SGBD baseados em família de colunas. Na seção 2 descreve-se a
arquitetura tradicional de BI. A Seção 3 introduz o conceito de NoSQL e bancos de
dados em família de colunas, exemplificado pelo banco de dados Apache Cassandra. A
seção 4 apresenta a metodologia, a arquitetura de BI com a utilização de banco de dados
NoSQL colunar. Na seção 5 é apresentado um estudo de caso onde é aplicado o modelo
proposto. Por fim a seção 6 traz as considerações finais e perspectivas sobre a
arquitetura de BI sobre banco de dados NoSQL.
2. Modelo Tradicional de Construção de Aplicações de Business Intelligence
Segundo Kimball e Ross (2013) e Inmon (2005), as principais estruturas e processos
para a criação de um modelo tradicional de aplicações BI1 são ordenadas a partir de seis
pontos, que são apresentados em resumo na figura 1.
Figura 1 - Modelo tradicional de construção de aplicações B.I.
Os principais pontos definidos por Kimball e Ross (2013) e Inmon (2005), são:
Data Source (DSs): Refere-se às fontes de dados, que podem envolver arquivos
sequenciais, banco de dados estruturados relacionais de diversas naturezas, sistemas
transacionais e quaisquer outras fontes de dados que possam ser processadas e
incrementadas ao DWs/Data Mart.
Extract, Transformation and Load (ETL): Processo que envolve extrair os
dados dos DSs. Aplicar um processo de transformação que envolve limpeza, adequação
e agregação dos dados, para que estes possam ser convergidos em uma forma universal e
por fim o carregamento destes dados nos seu devido DWs.
1
São também processos do universo do BI os Data Miner (mineração de dados) e o Analytics/Data
Discovery (análises e descobrimento de dados) que não serão abordados neste artigo.
Staging Area \ Operational Data Store (ODS): É uma área temporária onde são
armazenados os dados antes da transformação. A área intermediária (staging area)
geralmente é utilizada para carga dos dados brutos dos DSs para posterior trabalho de
transformação, sendo acessadas por desenvolvedores e responsáveis de ETL. Já a ODS é
utilizadas como área de integração de dados pelos usuários e/ou sistemas transacionais.
Data Warehouse: O armazém central de dados, onde são disponibilizados de
forma corporativa. São bases de dados históricas não voláteis, ou seja, possuem dados
gravados fisicamente que não sofrem alterações e representam diferentes instantes de
tempo sobre a informação.São bases de dados que sofrem processamento massivo de
escrita não sendo utilizado para processamento de visualização de dados.
Data Mart (DMs): Pequenos armazéns de dados com recortes específicos para
atendimento das aplicações e áreas de negócio, com uma enésima parte da totalidade de
dados armazenados no DWs. Por definição é a camada de DM que sofre o
processamento das ferramentas de visualização de dados.
Ferramentas de Visualização de Dados: Responsáveis pela visualização dos
dados contidos nos DMs. São expoentes as ferramentas de On-line Analytical
Processing (OLAP) que apresentam os dados de forma multidimensional. Destacam-se
também ferramentas de relatórios e as de apresentação em Dash Board (painéis de
controle) que apresentam as informações em forma de gráficos, indicadores e tabelas.
O DW de forma clássica é persistido em bases de dados relacionais, orientada a
linhas. Em Kimball e Ross (2013) e Inmon (2005), observa-se que orientam a
modelagem da base de dados do DWs e os DMs, como Schema Star (esquema estrela ou
modelo estrela), apresentado graficamente na Figura 2. Este modelo é uma modelagem
de dados de forma desnormalizada. Os dados que possuem conteúdos que podem ser
mensurados e/ou calculados, ou seja, todos os dados que são traduzidos em métricas são
armazenados em Tabelas Fato. Estas são relacionadas com tabelas que possuem as
dimensões, contendo as informações para segmentação e análise dos dados, chamadas de
Tabelas Dimensão.
Figura 2 - Representação do Modelo Estrela de Kimball e Ross (2013)
3. Sistemas Gerenciadores de Base de Dados NoSQL
NoSQL é um termo que agrupa SGBDs não relacionais, que atendem a grandes volumes
de dados com alto desempenho e alta disponibilidade. Eles são definidos por
apresentarem as seguintes características:
Ausência da linguagem padrão de consulta SQL-ANSI: SGBDs NoSQL em
inglês “Not only SQL” não possuem em sua estrutura a linguagem de consulta comum de
banco de dados relacionais, o Structured Query Language (SQL). Em geral
disponibilizam interfaces de programação de aplicações (APIs) para consulta ou
linguagem própria como o CQL do Cassandra ou MongoQuery do MongoDB.
Escalabilidade horizontal: Capacidade de processamento em diversos nós de
um cluster ou diversos clusters. Permitem que a carga de processamento seja dividida
em diversos agentes, aumentando significativamente a capacidade de processamento do
SGBD. Possui a possibilidade de incluir no mesmo cluster, hardwares heterogêneos de
arquiteturas e configurações distintas.
Schemaless ou Schema Free: Trabalham com esquemas de dados flexíveis ou
totalmente sem esquemas, favorecendo o trabalho com diversos tipos de dados e
aplicações de alta mutabilidade de formatos.
Sharding e Replicação: Replicação de dados em vários nós do SGBD e
compartilhamento (sharding) de dados. Estas características favorecem o processamento
paralelo e em geral alta disponibilidade do sistema.
Consistência Eventual: Trabalham com o paradigma otimista de consistência de
dados, onde inconsistências eventuais e temporárias devem ser aceitas e previstas para
priorizar a alta disponibilidade do sistema. Esta consistência é efetuada em um momento
posterior a transação, como descrito em Gilbert e Lynch (2002) no modelo Basically
Avaliable, Soft State, Eventual Consistency (BASE).
Segundo Lócio et al.(2011), os SGBDs NoSQL são altamente relevantes para
aplicações que “necessitam de uma tecnologia que ofereça suporte ao gerenciamento e
escalabilidade de grandes volumes de dados, de maneira simples e eficiente”. Por
exemplo, as aplicações web que podem produzir volumes de dados imensos. Por estes
motivos empresas focadas em aplicações web como o Google, Facebook, Twitter,
Amazon, LinkedIn desenvolvem e/ou adotam tecnologias de SGBD NoSQL.
Moniruzzaman e Hossain (2013) classificam os atuais SGBDs NoSQL em quatro
tipos básicos de arquiteturas:
Chave-Valor: São normalmente orientados a uma chave alfa-numérica e valores
associados, sendo esses valores simples como texto ou complexos como: listas, tabelas,
imagens entre outros.
Orientados a Documentos: São bases de dados construídas para armazenar
documentos. Esses documentos são representados internamente de uma forma padrão de
troca de documentos como XML e Javascript Option Notation (JSON). Na Figura 3 há
uma representação gráfica da base de dados orientada a documentos.
Figura 3 - Representação de base de dados orientada a documentos de
Moniruzzaman e Hossain (2013)
Família de Colunas: Assim como o modelo chave-valor, ele representa
múltiplos atributos por cada chave, como será visto na Figura 4, com a diferença que os
atributos são representados por tabelas. Gravando cada coluna da tabela separadamente,
armazenando de forma contínua cada atributo referente à chave. São os maiores
exemplos de SGDB de família de coluna o Apache Cassandra, Big Table da Google e o
Apache HBase.
Figura 4 - Representação de tabela de família de colunas de Moniruzzaman e
Hossain (2013)
Orientado a Grafos: São bases de dados desenvolvidas sobre os conceitos da
teoria dos grafos, onde as tabelas são representadas como uma rede orientada a objetos
de nós (objetos conceituais), relações entre nós (arestas) e propriedades (atributos de
objetos de dados chave-valor). Geralmente, são utilizadas em aplicações em que existe
alta complexidade de relacionamentos, como redes sociais e sistemas de recomendações.
Na Figura 5 apresenta-se uma representação gráfica de uma base de dados orientada a
grafos:
Figura 5 - Representação de base orientada a grafos de Moniruzzaman e
Hossain (2013)
3.1. Características de bases de dados de família de colunas e os DWs
As principais vantagens de “bancos de dados de modelo colunar em relação aos de
modelo relacional estão vinculadas à compressão, materialização e bloco de iteração”,
como pode ser visto com mais detalhes em Soares e Boscarioli (2013) e em Abadi et al.
(2009).
Segundo Soares e Boscarioli (2013), o bloco de interação da armazenagem dos
bancos de dados colunares possibilitam um menor número de instruções ao CPU na
execução de consulta de tuplas de dados, já que o “executor de consultas pode operar
sobre o vetor contendo todos os elementos da coluna lida de uma só vez”. Em relação às
consultas de grandes volumes de dados representam uma grande vantagem, pois não é
necessário que todas as tuplas sejam “percorridas e interpretadas uma-a-uma, lendo
atributos de forma desnecessária”, significativo acréscimo de desempenho.
A materialização é a forma que os dados são recuperados de seu armazenamento.
A forma que está propriedade é implementada em SGBD colunares acrescenta uma
grande vantagem para consultas de grandes volumes de dados. Este SGBD utiliza uma
técnica descrita por Abadi et al.(2007) como Late Materialization (LM) ou
Materialização Precoce (em tradução livre), onde é possível reconstruir um menor
número de tuplas de retorno em tempo menor. Em LM, como explica Soares e
Boscarioli (2013), “os predicados da consulta são verificados antes do retorno da coluna,
para que linhas desnecessárias não sejam analisadas”. Abadi et al. (2007) acrescentam
ainda que as materializações em banco de dados colunares “operam diretamente sob a
posição dos dados nas colunas, construindo apenas tuplas relevantes, diretamente sobre
dados compactados orientados à coluna, sob velocidades de iteração de alto valor”.
De acordo com Abadi et al. (2009) uma das mais citadas vantagens dos bancos
de dados do modelo colunar é sua alta efetividade de compactação. Os algoritmos de
compactação são mais eficientes nesse modelo de dados, já que o sistema de
armazenamento de dados em colunas tende a inserir de forma sequencial informações
semelhantes. Esses métodos de compactação são fundamentais para melhora
significativa no desempenho do banco de dados, Soares e Boscarioli (2013). Yaskevich
(2011) relata que a compactação pode ser responsável por um desempenho em leitura de
25% a 35% e em escrita em 5% a 10% maior, além de uma redução em armazenamento
físico na ordem de 2 a 4 vezes de acordo com o método de compactação empregado.
Diante dos pontos mencionados, ressalta-se que as bases de dados orientadas a
colunas são ideais para construção de DWs. Vemos em Carniel et al. (2012) que o DW é
uma “base de dados volumosa, histórica, orientada ao assunto e não volátil”. SGBDs
NoSQL orientados as colunas são “indicados para aplicações que precisam de alto
desempenho em uma operação específica, como o processamento de consultas em dados
não voláteis”. Ainda neste sentido, Soares e Boscarioli (2013) trazem a atenção o fato
que banco de dados colunares são otimizados para operações de leitura (read-optimized),
tornando-se uma “boa alternativa às aplicações que possuem grande densidade de dados
e que são frequentemente requeridos para leitura” como é o caso dos DWs.
3.1. O Apache Cassandra
A distribuição de SGDB NoSQL de famílias de colunas adotada para desenvolvimento
desta pesquisa foi o Apache Cassandra, por se tratar de uma aplicação open source,
estável, amplamente aceita pelo mercado, de alta performance e disponibilidade, de fácil
instalação e com uma ampla documentação disponível.
O Apache Cassandra é uma base de dados desenvolvida inicialmente pelo
Facebook e apresentado através do artigo “Cassandra - A Decentralized Structured
Storage System”. Posteriormente, o projeto foi disponibilizado como open source para
comunidade sobre a guarda da fundação Apache. Conforme informam Lakshman e
Malik (2009), os requisitos para esta plataforma eram a alta disponibilidade,
desempenho, confiabilidade e arquitetura suficientemente escalável para suportar o
crescimento à enorme quantidade de dados produzidas pela plataforma Facebook.
O Cassandra baseou sua arquitetura em dois outros exponenciais SGBD NoSQL,
o Big Table do Google e o DynamoDB da Amazon. Do Big Table utilizou o modelo de
dados colunar e do DynamoDB aproveitou sua arquitetura de replicação e
particionamento de dados.
Segundo a documentação oficial em Datastax (2015) a versão 2.1 do Cassandra
suporta declaração explicita de esquema, tipo de dados simples como alfanuméricos e
numéricos, além de tipos de dados complexos como, bloob (binários), tuplas,
dicionários, listas, além de documentos no formato JSON. Possui também uma
linguagem nativa de consulta o Cassandra Query Language (CQL) com instruções de
Data Definition Language (DDL), Data Control Language (DCL), Data Manipulation
Language (DML) e Data Query Language (DQL).
O Cassandra é orientado a colunas, entretanto internamente trabalha com o
conceito chave-valor. Desta forma, as consultas são feitas através das chaves definidas.
Porém, suporta indexação de colunas secundárias e indexação da chave em range por
faixa de valores de colunas adicionais além da chave principal. A indexação secundária
permite que sejam feitas consultas nestas colunas adicionais indexadas através do CQL.
Atualmente o Cassandra é utilizado em empresas como o Twitter, o Reddit e o
Netflix, que necessitam de SGDBs de alta performance e imensa escalabilidade. No
Netflix, por exemplo, existem casos de uso onde o Cassandra atingiu a marca de mais de
um milhão de escrita por segundo com 288 nós em um cluster EC2 na Amazon Web
Services, mais informações podem ser vistas em Cockcroft e Sheahan (2011).
3.2. O Apache Spark
O Apache Spark é um sistema de processamento de dados em memória, desenvolvido
para acelerar o processamento de grandes quantidades de dados. Sua arquitetura foi
desenhada para processamento paralelo em cluster. Possui API para desenvolvimento
em Java, Scala e Python. Disponibiliza módulos para processamento em streaming,
modulo para criação de algoritmos de aprendizagem de máquina, módulo para consultas
em SQL e módulo para criação de algoritmos baseados em grafos. Com Spark há a
possibilidade de junções em tabelas, baseadas no modelo colunar dos SGBD Apache
Cassandra e Apache HBase, conforme disponível em Spark (2015).
4. Modelo de Construção de Aplicações de Business Intelligence em Banco de
Dados NoSQL Orientado a Colunas
O modelo proposto para construção de BI em base de dados colunares NoSQL baseia-se
nas seguintes camadas:
Data Source: Fontes de Dados quaisquer, tanto estruturadas como base de dados
relacionais e arquivos sequencias, e acrescentam-se neste modelo fontes de dados não
estruturadas como arquivos de logs e dados de redes sociais.
Extration, Load e Transformation (ELT): Diferentemente do ETL tradicional
em que os dados são transformados em tempo de extração, nesse modelo a preocupação
é com a extração das fontes de dados e carregamento na mesma estrutura original na
base de dados NoSQL. Desta forma nenhum dado é perdido ou agrupado. Como o
SGBD NoSQL suporta quantidade de dados ilimitada com baixo custo, a principal
preocupação é o armazenamento inicial da informação, sem necessidade de técnicas de
redução na quantidade de dados carregados. Posteriormente, a informação pode ser
minerada e transformada para uma camada de apresentação. Ferramentas tradicionais de
ETL como o Talend e Pentaho Data Integration que possuem conectores para NoSQL
podem ser utilizadas. Outras ferramentas podem ser adicionadas, como o Apache Kafka
que facilita a extração de diversas fontes não relacionais e o Apache Flume que
possibilita a extração de dados de fontes relacionais. Estas duas últimas ferramentas
podem ser diretamente ligadas à aplicação da camada de processamento em memória em
streaming. Outra abordagem possível é desenvolver programas em linguagens que
possuem APIs para Apache Spark e Apache Cassandra como o Java e o Python.
Processamento em Memória: É adicionada uma camada para o processamento
dos dados em memória. Esta camada é responsável pelo processamento tanto no ato do
carregamento dos dados, quanto no momento de transformação e exibição. Esta camada
também facilita a mineração, descoberta e junção de dados, já que banco de dados
NoSQL não a capacidade de junção de tabelas. A camada de processamento em
memória proporciona esta capacidade, de forma rápida. Seu processamento é
inteiramente em memória, com menor custo de I/O físico. Outras possibilidades também
são adicionadas como o processamento em streaming tonando possível a criação de
plataformas de BI para produção de informações em tempo real. Esta abordagem
depende naturalmente de grandes quantidades de memória disponível em seus nós. Neste
modelo o Apache Spark foi adotado como aplicação para atender esta camada.
Data Warehouse: Neste modelo o DW pode ser representado como camada
lógica ou física que compartilha o mesmo SGBD que a área de carregamento. Neste
trabalho sugeriu-se a criação de esquemas físicos de tabelas, contendo as informações
acessadas pelas ferramentas de visualização de dados, para otimizar o tempo de
processamento e facilitar o mapeamento dos metadados. O DW pode também ter
acrescentada uma camada lógica dentro da área de processamento em memória, ou seja,
meta-esquemas lógicos que mapeiam a forma de apresentação das informações obtidas
diretamente das áreas de carregamento do SGBD. Estes meta-esquemas são chamados
de sandbox (caixa de areia) onde a representação dos dados é lógica, criada em tempo de
execução e descontruída depois de sua utilização. Essas duas abordagens podem também
serem adotadas simultaneamente de acordo com as necessidades da aplicação.
Ferramentas de Visualização de Dados: São aplicadas sobre a camada de
processamento em memória. Desta forma, a camada de processamento em memória, que
também é clusterizada, proporciona velocidade adicional à camada de visualização de
dados. Ferramentas comuns de mercado como Cognos, Microstrategy, Qlikview e até
Microsof Excel podem ser utilizadas para a visualização de dados, já que a camada de
processamento em memória como Apache Spark disponibiliza conectores padrões de
mercado como ODBC e JDBC. Outras ferramentas como o Jaspersoft Server possuem
conectores nativos para Spark. As consultas de dados assim podem ser realizadas
diretamente com linguagem SQL que são traduzidas de forma transparente para a
linguagem do SGBD NoSQL.
No modelo apresentado são suprimidos as staging areas e as ODS, já que não é
necessária uma área de carregamento dados temporária, e a área de processamento
operacional pode ser representada diretamente no SGBD em tabelas ODS ou em uma
representação lógica na memória em sandbox.
Os DMs também são suprimidos, pois não é necessária a separação física dos
dados para cada área de negócio, e o processamento das consultas e das visualizações de
dados podem ser executadas diretamente no DW, pois o SGBD NoSQL distribuído e
clusterizado suporta com eficiência toda carga de processamento. Os DMs podem ser
representados por esquemas físicos de tabelas diretamente no DW ou em sandbox na
área de processamento em memória.
A modelagem em schema star apresentada anteriormente, também é modificada.
Os conceitos de fato e dimensões juntamente com conceitos mais profundos como de
granularidade deve ser considerados para a criação da modelagem de dados, porém não
são representados fisicamente no DW. Os dados de fato e de dimensão devem ser
representados em uma única tabela desnormalizada, que neste trabalho denominou-se
como “Tabela Estrela”. A volumetria dos dados pode ser ampliada de acordo com a
granularidade dos dados, porém este fator deve ser desconsiderado já que na abordagem
NoSQL o custo de armazenagem é infimamente menor que o custo de processamento,
ou seja, a velocidade de processamento é de ordem de importância muito maior e com
menor custo do que a volumetria dos dados.
Na Figura 6 apresenta-se o processo de um modelo de aplicações BI sobre SGBD
NoSQL baseado em coluna com a integração dos principais itens para sua criação,
conforme a proposta de modelo deste artigo:
Figura 6 - Modelo proposto para construção de aplicações B.I.
5. Estudo de Caso e resultados
O modelo apresentado no item quatro deste artigo foi implementado em escala
experimental. Foram utilizados todos os itens descrito nesta seção, com exceção da
implementação de sandbox em memória.
Para este estudo de caso foi utilizado uma arquitetura stand alone não
clusterizada. O hardware utilizado foi um microcomputador Lenovo T440p, com
processador Intel Core i5-4300M 2.8 GHz e 4GB de memória ram. O sistema
operacional utilizado foi o Windows 7 Professional 32bits. O SGBD utilizado foi o
Apache Cassandra na distribuição Data Stax Community Edition versão 2.1.4. Para
camada de processamento em memória foi utilizado o Apache Spark 1.3.0. Para o ELT
foi utilizado como ferramenta o Python 3.4. Na camada de visualização de dados foi
utilizado o sistema Jasper Reports Server Community Edition versão 6.01. Foi
necessário também a instalação da Java Virtual Machine (JVM) e JDK 6.
Para o caso de uso foi processada uma base de dados disponibilizada em Bacen
(2015). Os dados foram baixados no formato CSV. Foram selecionados todos os dados
históricos de ativo classificado por operações de crédito e arrendamento mercantil
líquidas de provisão dos 50 maiores bancos brasileiros.
5.1. Resultados
Todos os itens da arquitetura se integraram conforme o proposto. Houve uma
dificuldade para configuração do Apache Spark em ambiente Windows, mas esta
dificuldade já era esperada, já que os sistemas utilizados são melhores adaptados para
trabalharem em plataforma Unix\Linux.
No presente caso de uso a ELT foi efetuada com scripts em Python informando
comandos de Insert através do Spark. Foram inseridas duas tabelas distintas, uma
contendo as informações de carteiras de crédito e outras contendo informações do tipo
dimensão a respeito das instituições bancárias. Uma terceira tabela, a “tabela estrela” foi
construída por meio de programação em Python diretamente no SGBD Cassandra para
testar as funcionalidades da linguagem CQL.
A camada de visualização de dados conectou a aplicação Spark através de ODBC
que necessitou instalação e configuração prévia. As consultas foram feitas através de
comandos SQL. Foi desenvolvido um relatório em forma de listagem e um dash board
contendo dois gráficos. Os filtros foram feitos diretamente no JasperReport Server e
atingiram a meta esperada. Assim todas as funcionalidades básicas de um BI foram
implementadas e testadas sobre o modelo proposto.
6. Considerações Finais
As aplicações de BI vêm sendo desenvolvida há diversos anos sobre o modelo
sugerido por Kimball e Inmon, que implicitamente é associado com base de dados
relacionais, entretanto a arquitetura relacional de dados possui limitações em
escalabilidade. Como pode-se verificar, a abordagem NoSQL foi desenvolvida para lidar
com os desafios de base de dados grandes e com escalabilidade horizontal. Destaca-se
como solução de SGBD NoSQL para construção de DW as arquiteturas voltadas a
família de colunas. Desta forma, hoje a criação de aplicações de BI em base de dados
NoSQL colunares é uma realidade e esta abordagem pode trazer diversas vantagens
sobre o modelo relacional.
Este trabalho contribuiu para identificar um modelo viável para construção de
uma aplicação robusta de BI. Foram analisadas diversas arquitetura de SGBD NoSQL
bem como outras ferramentas para construção desta arquitetura de BI. Como resultado
foi apresentado à implementação do modelo proposto e verificado que este atende as
funcionalidades padrões de uma aplicação de Business Intelligence.
6.1. Próximos Passos
Para os próximos passos pretende-se efetuar o desenvolvimento de sistemas de
metadados para data warehouse em banco de dados NoSQL, já que o modelo
apresentado não dispõe de nenhuma base de metadados. Outra atividade a ser testada é a
criação de cubos OLAP ou cubos de análise em memória. Por fim, com maiores recursos
pretende-se efetuar medição do desempenho do modelo proposto com volume massivo
de dados em ambiente clusterizado.
6. Referências
Abadi, D. J., Boncz, P. A., Harizopoulos, S. Column-Oriented Database Systems.
Proceedings of the VLB Endowment 2009, v. 2, n. 2, p.1664-1665, 2009.
Abadi, D. J., Myers, D. S., Dewitt, D. J., Madden, S. R., Materialization Strategies in a
Column-Oriented DBMS. In: IEEE 23rd International Conferenceon Data
Engineering, 2007. , p. 466-475. 2007.
Bacen, B. C. B., 50 maiores bancos e o consolidado do Sistema Financeiro Nacional.
2015. Disponível em:http://www4.bcb.gov.br/fis/TOP50/port/Top50P.asp
Carniel, A. C, Sá, A. A.; Brisighello, V. H. P.; Ribeiro, M. X.; Bueno, R.; Ciferri, R. R.;
Ciferri, C. D. A. Query Processing over Data Warehouse using Relational Databases
and NoSQL. XXXVIII Conferencia Latino americana En Informatica (CLEI 2012) p.
1-9, 2012.
DataStax, CQL for Cassandra 2.x Documentation. 2015 – Disponível em
http://docs.datastax.com/en/cql/3.1/pdf/cql31.pdf. Acessado em 11/04/2015.
Cockcroft, A., Sheahan, D., Benchmarking Cassandra Scalability on AWS - Over a
million
writes
per
second.
2011.
Disponível
em:
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
Acessado em: 11/04/2015.
Inmon, W. H. Building the Data Warehouse, 4º Edition. Wiley Publishing, Inc., 2005.
Gilbert, S.,Lynch, N., Brewer’s Conjecture and the Feasibility of Consistent, Avaliable,
Partition-Tolerant Web-Services. ACM SIGACT News, New York, NY,USA, v.33,
n. 2, p.51,59, Junho, 2002.
Kimball, R., Ross, M., The Data Warehouse Toolkit: The Definitive Guide to
Dimensional Modeling, Third Edition. John Wiley & Sons, Inc., 2013.
Lakashman, A., Malik, Prashant., Cassandra – A Decentralized Structured Storage
System.
2009.
Disponível
em:
https://www.cs.cornell.edu
/projects/ladis2009/papers/lakshman-ladis2009.pdf Acessado em: 11/04/2015.
Lócio, B. F., Oliveira H. R., Pontes, J. C. S.,NoSQL no desenvolvimento de aplicações
Web Colaborativas. VIII Simpósio Brasileiro de Sistemas Colaborativos (SBSC
2011), 2011.
Moniruzzaman , A. B. M., Hossain, S. A. NoSQL Database: New Era of Databases for
Big data Analytics - Classification, Characteristics and Comparison. International
Journal of Data base Theory and Application Vol. 6, No. 4., 2013.
Soares, B. E., Boscarioli; C. Modelo de Banco de Dados Colunar: Características,
Aplicações e Exemplos de Sistemas. IX Escola Regional de Banco de Dados (ERBD
2013), 2013.
Spark, A., Apache Spark Documentation. 2015.
Disponível
https://spark.apache.org/documentation.html. Acessado em: 11/04/2015.
em:
Yaskevich, P. What’s new in Cassandra 1.0: Compression.–Disponível em
http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-compression.
Acessado em 11/04/2015, 2011.