PAPER - Modelo de Processo Para Criação de BI Em Banco de Dados

[1] São também processos do universo deBI,os DataMiner (mineração de dados) e o Analytics/Data Discovery (análises e descobrimento de dados) que não serão abordados neste artigo.

Conferência Ibero-Americana de Computação Aplicada 2015 (CIACA 2015)

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]

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ções de ferramentas da camada de armazenamento, processamento de dados e da camada de apresentação.

Palavras Chaves. Business Intelligence, SGBDs, NoSQL, Banco de Dados Colunar, Data Warehouse

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 bancos de dados NoSQL, pois sua estrutura e arquitetura foram desenvolvidas para trabalharem com base de dados grandes, proverem 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

[2] http://docs.datastax.com/en/cql/3.1/cql/cql_intro_c.html [3] http://docs.mongodb.org/manual/tutorial/query-documents/


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 6(seis) pontos, que são apresentados em resumo na figura 1.

Figura 1 - Modelo tradicional de construção de aplicações BI

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 aos DWs/Data Mart.

Extract, Transformation and Load System (ETL): Processo que envolve extrair os dados dos DSs. Aplicar um processo 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 a carga destes dados nos seus devidos DWs.

Stanging Area\Operational Data Store (ODS): É uma área temporária onde são armazenados os dados antes da transformação. A área intermediária (stagin area) geralmente é utilizada para carga dos dados brutos dos DSs para trabalhos posteriores de transformação, sendo acessadas por desenvolvedores e responsáveis de ETL. Já a ODS é utilizada como área de integração de dados pelos usuários e/ou sistemas transacionais.

Data Warehouse (DW): 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. O DW de forma clássica é persistido em bases de dados relacionais, orientada a linhas.

Data Mart (DM): 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 nos DWs. Por definição é a camada de DM que sofre o processamento das ferramentas de visualização de dados.

Ferramentas para Visualização de Dados: Responsáveis pela visualização dos dados contidos nos DMs. Entre as principais ferramentas destacam-se: On-line Analytical Processing (OLAP) que apresenta os dados de forma multidimensional. Adicionalmente, ferramentas de relatórios e a Dash Bord (painéis de controle) que apresenta as informações em forma de gráficos, indicadores e tabelas.

Em Kimball e Ross (2013) e Inmon (2005), observa-se que orientam a utilização da modelagem de dados de forma desnormalizada em Star Schema (esquema estrela ou modelo estrela) para as bases de dados dos DWs e os DMs. Os dados que possuem métricas que podem ser mensurados e/ou calculados 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 de dados, chamadas de Tabelas Dimensão.

3. SISTEMAS GERENCIADORES DE BASE DE DADOS NOSQL

Segundo Moniruzzaman e Hossain (2013), NoSQL é um termo que agrupa SGBDs não relacionais, que atendem aos grandes volumes de dados com alto desempenho e alta disponibilidade. Apresentando as seguintes características:

Ausência de 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

[2] http://docs.datastax.com/en/cql/3.1/cql/cql_intro_c.html [3] http://docs.mongodb.org/manual/tutorial/query-documents/


(em inglês APIs) para consulta ou linguagem própria como o Cassandra Query Language2 (CQL)ou MongoQuery3.

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 Free Schema: 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 alfanumé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).

Família de Colunas: Assim como o modelo chave-valor, ele representa múltiplos atributos para cada chave, 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.

Orientado a Grafos: São bases de dados desenvolvidas sobre os conceitos da teoria dos grafos, onde as tabelas são representados 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.

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 em Soares e Boscarioli (2013) e em Abadi (2008).

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 esta 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 Late Materialization, como explica 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 aposiçã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 (2008) 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. Os 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 bases de dados orientadas a colunas são ideais para construção de DWs. Em Carniel et al. (2012) é visto 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 ao 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.2. O Apache Cassandra

A distribuição de SGDB NoSQL de família de colunas adotada para o desenvolvimento desta pesquisa foi o Apache Cassandra, por se tratar de uma aplicação open source, estável, aceita pelo mercado, de alta performance e disponibilidade, de fácil instalação e com documentação disponível.

O Apache Cassandra é uma base de dados desenvolvida inicialmente pelo Facebook e apresentada a partir do artigo “Cassandra - A Decentralized Structured Storage System”. Posteriormente, o projeto foi disponibilizado como open source para comunidade sobre a responsabilidade 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.

A arquitetura do Cassandra foi baseada 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 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.3. 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 existe 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 de aplicações BI sobre SGBD NoSQL baseado em coluna com a integração dos principais itens para sua criação são apresentadas na figura 2. A seguir apresenta-se a descrição das camadas do modelo.


Figura 2 - Modelo proposto para construção de aplicações BI

Data Source: Fontes de Dados quaisquer, tanto estruturadas como base de dados relacionais e arquivos sequenciais. Acrescenta-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 tem 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 tornando 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 desconstruí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 Tableau, 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ário 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ário 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 star schema 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.

5. METODOLOGIA E RESULTADOS Com o modelo de estrutura de dados baseado em colunas desenvolvido foi possível realizar os seguintes procedimentos: integração do SGBD, camada de processamento em memória, conectores e camadas de apresentação. A seguir apresenta-se os materiais e os detalhes do desenvolvimento dos procedimentos:

Para utilização de uma arquitetura standalone clusterizada, utilizou-se três servidores em nuvem do provedor DigitalOcean. Cada servidor apresenta 4GB de memória, 60GB de armazenamento SSD e com 2(dois) núcleos de processamento.

O sistema operacional utilizado foi o Linux Ubuntu Server 15.04x64bits. O SGBD utilizado foi o Apache Cassandra versão 2.2.1 para persistência dos dados. Para camada de processamento em memória foi utilizado o Apache Spark 1.5. O Python 2.7 foi utilizado como ferramenta para ELT e tratamento dos dados. Na camada de visualização de dados foi utilizado o sistema JasperReports Server Community

Edition versão 6.01. Adicionalmente, como pré–requisito para instalação e configuração deste modelo são necessário os

seguintes softwares: Oracle Java 7, Scala 2.10, SBT 0.13, Git2. 1.. Cabe salientar que se necessitou de conectores, tais como: spark-cassandra-connector 1.5, pyspark-

cassandra 0.1.1 para conexão entre o Cassandra, Spark e Python além do Simba Spark ODBC 64bits para conexão do Apache Spark com JasperReports Server.

Para realização da validação do modelo utilizou-se uma base de dados disponibilizada em BACEN (2015). Os dados foram obtidos no formato CSV.

A implementação desenvolvida foi em escala experimental, apenas para demonstração que a arquitetura teórica proposta é possível de construção de forma prática.

5.1. Resultados

Todos os itens da arquitetura se integraram conforme o proposto. Dentro da implementação do protótipo houveram dificuldades em relação à quantidade de memória necessária para o processamento dos dados. Na documentação oficial do Apache Cassandra (DataStax, 2015) e Apache Spark (Spark, 2015) é informado que para desempenho real em produção é requisito mínimo pelo menos 8GB de memória para cada aplicação em cada nó. Como cada nó possuía uma aplicação do Apache Cassandra juntamente com um Apache Spark, desta forma cada nó necessitaria pelo menos 16GB. Sendo assim não se considerou neste trabalho os tempos de consulta, inserção e atualização de dados nas aplicações, já que este resultados estão diretamente relacionados ao tamanho da base, quantidade de nós implementados além da arquitetura de hardware.

O hardware utilizado para construção do protótipo desta pesquisa possui especificação menor do que a sugerida na documentação oficial das aplicações, entretanto, mesmo com hardware de baixo custo e com especificações menores, foi possível a implementação do modelo. É interessante notar também que o


protótipo foi totalmente implementado em computação em nuvem. Todos os softwares foram instalados e configurados em apenas uma máquina virtual. Em seguida, o estado físico dos softwares desta máquina virtual foi salvo através de um snapshot e replicados aos demais nós. Sendo assim para funcionamento da aplicação nos demais nós após replicação do snaptshot, era necessário apenas a alteração da informação de IP em um arquivo de configuração respectivamente para Apache Cassandra e outro para o Apache Spark. Foi criado um shell-script que alterava essas informações de IP nos arquivos de configuração na inicialização de cada nó, desta forma, após a replicação, cada nó entrava em funcionamento no cluster automaticamente.

No presente caso de uso a ELT foi efetuada com scripts em Python informando comandos de insert diretamente no SGBD Cassandra. Foram inseridas duas tabelas distintas, uma contendo as informações de carteiras de crédito e outra contendo informações do tipo dimensão a respeito das instituições bancárias. Posteriormente, essas tabelas foram transferidas para Data Frames no Spark, ou seja, réplicas das tabelas completas em formato sandbox em memória. Sobre esses Data Frames foi criada uma junção gerando uma terceira tabela, a “tabela estrela”. A junção foi efetuada com SQL-ANSI com conexão via Python. Esta tabela com a visão final foi posteriormente persistida no SGBD Cassandra.

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. A tabela utilizada pela camada de aplicação foi o Data Frame em memória, desta forma todas as consultas foram realizadas diretamente com os dados em memória. Assim, foram implementados a sugestão da arquitetura proposta de criação de in-memory sandbox. É importante ressaltar que para atualização dos dados em memória é necessário um processo de submissão dos dados persistidos no SGDB para a aplicação em memória. Assim em produção esse processo precisa ser repetido periodicamente.

As consultas realizadas na aplicação de visualização foram feitas através de comandos SQL-ANSI. Foi desenvolvido um relatório em forma de listagem e um dashboard 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 teórico 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 possuem limitações em escalabilidade. Como pode-se verificar, a abordagem NoSQL foi desenvolvida justamente 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 à 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.

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. Assim umas das 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 em Soares e Boscarioli (2013) e em Abadi (2008).

Em aplicações de banco de dados no modelo colunar não existe problema de escalabilidade da aplicação. Como visto em Cockcroft e Sheahan (2011), podem ser implementados clusters com centenas de nós atendendo a mesma aplicação. No protótipo desenvolvido neste trabalho a criação de novos nós se deu de forma praticamente instantânea, assim diferentemente da arquitetura de BI clássica que necessita de grandes projetos de implementação e substituição de hardware e software para crescimento de capacidade, como no caso dos appliances oferecidos por grandes fornecedores de aplicações de BI, na arquitetura proposta são necessários apenas acréscimos de mais nós de processamento.

Existe também a possibilidade de diminuição de custos na implementação de uma aplicação em BI. Lakashman e Malik (2009) mostram que uma arquitetura NoSQL como o Cassandra pode ser implementada sem a necessidade de um hardware especifico de alto custo, antes, um dos predicados para a criação do Cassandra se deu que ele fosse capaz de trabalhar em hadwares heterogêneos de baixo custo, o que implica a diminuição no custo com hadware. Outro fator que pode contribuir para redução de custos é o fato todos os softwares utilizados na arquitetura proposta serem open-source, desta forma custos com licenciamento podem ser diminuídos drasticamente.

Outro fator importante considera foi que em determinados projetos de BI podem ser considerados uma grande vantagem no modelo é o fato dos SGBD NoSQL possuírem esquemas de dados totalmente flexíveis. Desta forma a complexidade dos modelos de dados pode ser reduzida, diminuindo também a quantidade de trabalho necessário para criação da aplicação do BI. O fato de podermos trabalhar com uma


abordagem ELT em contrapartida do clássico ETL pode também se enquadrar nesta mesma característica. É importante lembrar que esta vantagem vem em detrimento do controle dos metadados. Desta forma para que esses fatores sejam realmente uma vantagem é necessário um trabalho intenso sobre a criação e manutenção dos metadados da aplicação de BI.

Como grande vantagem no modelo apresentado à possibilidade de trabalhar com grandes volumes de dados com total integração com aplicações de Big Data. As ferramentas apresentadas foram desenvolvidas no ambiente de Big Data, desta forma possuem integrações nativas com ferramentas como Apache Hadoop, que é largamente utilizada para ambientes de Big Data. Além disto, o Apache Spark, utilizado com camada de processamento em memória, é uma aplicação que traz todas as possibilidades para criação de uma ambiente de Data Science e Analytics (Spark 2015), podendo assim ser facilmente implementado uma camada adicional estatística e preditiva ao BI descritivo apresentado.

Assim, este trabalho contribuiu para identificar um modelo viável para construção de uma aplicação robusta de BI. Foram analisados 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 Inteligence.

7. 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 InternationalConferenceon 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 Latinoamericana Em 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/2014.

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.

J. Han; Haihong, E.; G. Le; J. Du; "Survey on NoSQL database," Pervasive Computing and Applications (ICPCA 2011), 6th International Conference on, pp.363-366, 2011.

Kimball, R., Ross, M., The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, Third Edition. John Wiley & Sons, Inc., 2013.

Lakashman, A., Prashant, M., 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 atabases for Big data Analytics - Classification, Characteristics and Comparison. International Journal of Database Theoryand 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 em: https://spark.apache.org/documentation.html. Acessado em: 11/04/2015.

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.

PAPER - Modelo de Processo Para Criação de BI Em Banco de Dados

Documents

Transcript of PAPER - Modelo de Processo Para Criação de BI Em Banco de Dados