Business Intelligence Tutorial

Trabalhando com Business Intelligence

Business Intelligence se refere ao conjunto de conceitos, métodos e recursos tecnológicos que habilitam a obtenção e distribuição de informações geradas a partir de dados operacionais e históricos, visando proporcionar subsídios a tomada de decisões gerenciais.

Uma característica fundamental de um processo de BI é que nele os dados são copiados da base de dados transacional e de outras fontes, para a base de dados analítica, o que permite que as informações sejam extraídas desta última sem que a performance do sistema transacional seja prejudicada e da forma mais eficiente, eficaz e visualmente agradável possível, sempre focada na tomada de decisão.

Os dados podem, na sua origem, estar estruturados ou não, ou seja, podem vir de um sistema de informação com dados organizados e corretamente normalizados em tabelas e colunas, e podem ainda serem extraídos de sites da internet como texto puro, áudio, vídeo ou outros formatos. Apesar disso, em ambas as situações eles devem ser tratados e gravados em um formato que facilite a extração de informações e apoie as decisões dos gestores.

Neste artigo serão apresentadas as técnicas básicas envolvidas na criação de um data warehouse, na modelagem da base multidimensional, no processo de ETL, na modelagem e publicação da parte lógica do cubo (metadados) e, por fim, na visualização dos dados em uma ferramenta OLAP.

Ao longo da década de 90 vivemos a descoberta da internet, ocasião em que a rede mundial de computadores revelou-se um ótimo mercado, surgindo a partir daí o e-commerce, os portais de notícias, de músicas e, o que vem revolucionado o mundo, as redes sociais.

Concomitante à corrida pela visibilidade na internet, com o custo do hardware cada vez menor, as empresas investiram em seus sistemas de informação, que se tornaram imprescindíveis. Desde panificadoras até a montagem robotizada de veículos automotivos, todos necessitam de um software especializado para gerir as etapas de seus processos.

Entretanto, seja pela dificuldade enfrentada pelas empresas em criar software sob medida para suas necessidades, seja pela complexidade envolvida em manter uma equipe interna de TIC (Tecnologia da Informação e Comunicação), seja pelos custos elevados da terceirização desse desenvolvimento, a maioria adquire vários produtos de terceiros para gerir diversas áreas da empresa como o RH, Financeiro, Gestão de Projetos, Gestão de Clientes, Ensino à Distância, entre outros, o que acarreta em dados redundantes, descentralizados e em Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDRs) distintos, ao invés de serem armazenados em uma única base de dados, corporativa, normalizada e íntegra.

Diante da situação criada pela descentralização e heterogeneidade dos dados, o grande desafio do momento é integrá-los, interpretá-los e transformá-los, de alguma forma, em informação relevante ao seu negócio, possibilitando, com a devida análise, a criação de conhecimento.

O conhecimento pode, muitas vezes, ser o diferencial de uma empresa, pois possibilita ressaltar os seus pontos fortes e mitigar os riscos envolvidos nos pontos fracos. Tendo um retrato fiel da realidade, uma empresa consegue, em muitos casos, com base nos dados históricos, fazer uma previsão bastante assertiva do futuro e utilizá-la como embasamento para suas decisões.

Com base nisso, nesta primeira parte da série serão considerados os conceitos mais relevantes da Business Intelligence (BI), seguidos da apresentação da suíte Pentaho, capaz de contemplar no case proposto, todos os requisitos e regras de negócio elencados por uma empresa fictícia, com diversas filiais. Analisando a base origem e levando em conta os requisitos e regras de negócio, será descrito o raciocínio necessário para a modelagem da base destino, em formato estrela. Por fim, dando início ao tutorial propriamente dito, tem-se o passo a passo para a instalação e configuração do Pentaho Data Integration.

BI não é um bicho de sete cabeças

O termo Business Intelligence provoca arrepios em muita gente. Atualmente, afirma-se que as grandes vendedoras de soluções proprietárias e seus especialistas pintam um “bicho de sete cabeças” para justificar as altas cifras envolvidas. Esta é uma atividade altamente especializada e exige, em suas diversas etapas, profissionais treinados com uma gama muito grande de conhecimentos. Entretanto, o processo de BI propriamente dito é bastante simples.

Em 1992, o Gartner Group definiu Business Intelligence como o “conjunto de conceitos, métodos e recursos tecnológicos que habilitam a obtenção e distribuição de informações geradas a partir de dados operacionais e históricos, visando proporcionar subsídios a tomada de decisões gerenciais”. O termo pode ser traduzido como inteligência empresarial ou inteligência de negócios.

Gartner Group

O Gartner é uma empresa de consultoria fundada em 1979, por Gideon Gartner, com sede nos Estados Unidos, em Stamford, Connecticut. Atualmente conta com 5.300 associados, incluindo 1.280 consultores e analistas. Referência por ser formadora de opinião, trabalha em pesquisas de mercado e vende seus relatórios com incrível valor agregado para empresas privadas e para o governo de 85 países.

Uma característica fundamental de um processo de BI é que nele os dados são copiados da base de dados transacional e de outras fontes, para a base de dados analítica, o que permite que as informações sejam extraídas desta última sem que a performance do sistema transacional seja prejudicada e da forma mais eficiente, eficaz e visualmente agradável possível, sempre focada na tomada de decisão.

Os dados podem, na sua origem, estar estruturados ou não, ou seja, podem vir de um sistema de informação com dados organizados e corretamente normalizados em tabelas e colunas, e podem ainda serem extraídos de sites da internet como texto puro, áudio, vídeo ou outros formatos. Apesar disso, em ambas as situações eles devem ser tratados e gravados em um formato que facilite a extração de informações e apoie as decisões dos gestores.

Base de dados OLTP – Transacional

A maioria dos sistemas de informação se enquadra na categoria dos Online Transaction Processing(OLTP), também chamada de processamento de transações em tempo real. Um sistema deste tipo exige uma base de dados modelada para otimizar a inclusão e alteração de dados, obedecendo a padrões rígidos de normalização, evitando redundâncias, permitindo a integridade referencial e outras consistências.

Base de dados OLAP – Analítica

As soluções para análise de grandes volumes de dados, sob diversas perspectivas, exigem uma base de dados multidimensional, chamada de Online Analytical Processing (OLAP), modelada para otimizar a extração de informações e normalmente armazenada em servidores diferentes dos utilizados pela aplicação OLTP.

A Figura 1 ilustra as etapas de um ciclo de BI, que é repetido com certa periodicidade. Como pode ser observado, os dados seguem da sua origem até o seu destino e fornecerão insumos para as saídas aos usuários finais. A primeira etapa deste ciclo consiste na captação dos dados, oriundos de diversas fontes e em distintos formatos. Na maioria dos casos, no entanto, os dados são lidos da base transacional, OLTP.

A segunda etapa é a Extract, Transform and Load, que consiste em ler os dados, fazer as adequações para torná-los de fácil interpretação e pré-calcular os totalizadores desejados, gravando-os no Data Warehouse.

Extract, Transform and Load – ETL

O processo de ETL é dividido em três etapas:

• Extraction(extração): Consiste na leitura dos dados a partir de uma ou mais fontes, como, na obtenção de todos os registros adicionados ou alterados depois do último processo de ETL executado, na leitura de páginas da web, de web services, xml, xls, csv, json, além de formatos Big Data, como Hadoop, Cassandra, MongoDB e HBase.
• Transformation (transformação): Consiste na alteração da forma ou do conteúdo do dado, para que se encaixe a estrutura da base destino. A transformação ocorre, por exemplo, ao se fazer um lookup pelo nome da cidade para armazenar o seu código, ao ajustar o nome do bairro a partir do seu CEP, ao invalidar um registro por ter CPF ou e-mail inválidos, ao fazer decodificações, renomeações, cálculos, agregações, etc.
• Load (carga): Consiste na gravação dos dados em seu destino, independente do seu formato, que pode ser em um arquivo, em uma tabela da base transacional, em uma dimensão ou tabela fato de um cubo ou em formato Big Data.

A ETL é uma das etapas do processo de Business Intelligenceque visa a criação de um grande armazém para os dados (Data Warehouse). Para que o processo de Business Intelligence se tornasse viável, foi necessário o desenvolvimento de ferramentas especialistas, capazes de executar todas as tarefas exigidas pela atividade. Devido à grande facilidade proporcionada, a adoção destas ferramentas para outros processos, como a migração e a sincronização de dados entre sistemas, passou a ser apenas uma questão de tempo. Hoje em dia essas ferramentas são utilizadas para atividades como garimpagem de dados, leitura e análise de conteúdo das redes sociais e bolsas de valores, envio de e-mail marketing, etc.

A terceira e última etapa do ciclo de BI é a da saída dos dados, que pode acontecer em diversos formatos. Os relatórios, o formato mais usual, têm layout pré-definido, aceitam uma gama de filtros e geram documentos em pdf, xls, etc. Outra forma de saída de dados são os dashboards, que têm a finalidade principal de permitir o acompanhamento de indicadores em tela, de forma gráfica e interativa. Já as análises são feitas por meio de uma ferramenta de navegação OLAP, pelo próprio usuário final, que pode manipular os cubos criados, além de salvar e compartilhar suas consultas analíticas. Outras formas usuais de saída são os E-mails e Posts, que podem ser disparados para sinalizar a ocorrência de um evento ou para alertar que determinado indicador atingiu um nível crítico.

Normalmente o processo de ETL se repete uma vez ao dia, de madrugada, refletindo todas as alterações do dia anterior, mas a periodicidade deve ser ajustada de acordo com a necessidade, em cada situação.

Pentaho Business Analytics

Com essa enorme demanda, muitas soluções de BI foram criadas. Inicialmente o foco das empresas desenvolvedoras era apenas em grandes mercados e, por isso, cobravam valores estratosféricos pelos softwares, consultorias e claro, pelo hardware, que ainda hoje, não raro, vem embutido na maioria das propostas.

O advento do software livre possibilitou que ótimas alternativas às soluções proprietárias fossem criadas. Em 2004, na Flórida, Estados Unidos, formou-se uma equipe de executivos de grande experiência em BI que analisou diversas soluções Open Source do mercado, selecionando as mais interessantes em cada especialidade. A equipe, que foi acrescida dos principais líderes dos projetos escolhidos, fez algumas pequenas adaptações para que as suas ferramentas fossem todas compatíveis entre si, criando assim a suíte de aplicativos Pentaho Business Analytics. Esta suíte segue as políticas de desenvolvimento, distribuição e suporte dos softwares open source, que são flexíveis, independem de sistema operacional e de fornecedores, o que garante alta confiabilidade, segurança e escalabilidade. Também por isso, o código fonte, baseado em padrões do mercado (J2EE e AJAX), é aberto e liberado para distribuição e modificação sem qualquer custo de licenciamento.

A versão 4.8 do Pentaho, lançada em novembro de 2012, conta com uma das principais novidades dos últimos anos, o Pentaho Marketplace, que é um repositório que permite a instalação, atualização e remoção de plugins, pela interface web.

Outro ponto positivo do Pentaho é que muitas pessoas estão envolvidas nas melhorias acrescentadas às ferramentas da suíte. Uma delas merece especial destaque, o português Pedro Alves. Ele é o responsável pela criação das ferramentas C, batizadas de C*Tools, todas disponíveis no Pentaho Marketplace, que englobam diversas ferramentas extremamente úteis, como o Community Dashboard Framework (CDF), Community Dashboard Editor (CDE), Community Data Access (CDA), Community Cluster Cache (CCC), entre outras.

Cabe destacar também o plugin Saiku Analytics, que será demonstrado nesta série e que traz um front end em jQuery que permite a criação de análises OLAP com grande facilidade, por meio de recursos de drag and drop.

É importante ressaltar que o Pentaho, apesar de ser um software livre, conta também com uma versão comercial, com o nome de Pentaho Enterprise Edition. Basicamente o software é o mesmo, mas acrescenta alguns recursos que permitem maior facilidade na sua configuração, gestão e análise de dados, além do suporte técnico oferecido. Esta versão tem um modelo semelhante aos outros distribuidores de BI, que levam em conta o número de servidores, processadores e núcleos, mas com valores irrelevantes quando comparados. A versão livre, chamada de Pentaho Community Edition é suficiente para se iniciar um projeto e, caso haja a necessidade, a versão paga pode ser contratada a qualquer momento, sem a necessidade de ajustes nas soluções já criadas.

A parte servidora da suíte é formada por dois serviços web. O primeiro é o BI-Server, executado no servidor Tomcat. Além de se encarregar de executar todas as ETLs, possui uma interface web para disponibilizar ao usuário final as soluções criadas, chamada de Pentaho User Console (PUC). O segundo serviço é o da interface de administração, executado no servidor light de aplicações Jetty, e chamado de Pentaho Administration Console (PAC). É neste serviço que os usuários, seus grupos, conexões JNDI e agendamentos de ETLs são mantidos e os caches dos diversos componentes podem ser limpos.

Com os conceitos apresentados, têm-se subsídios para iniciar o desenvolvimento de uma aplicação analítica, utilizando software livre. A primeira etapa de qualquer projeto de TIC é o levantamento de requisitos e de regras de negócio, que é fundamental para delimitar o que se espera como resultado deste trabalho e como ele será validado. Com projetos de Business Intelligence não é diferente. Para exemplificar as etapas do processo de desenvolvimento de BI, a seguir apresentam-se os requisitos e regras de negócio do case proposto para esta série de artigos.

Requisitos e regras de negócio do case proposto

Para apresentar os conceitos relevantes para esta série de artigos, bem como para exemplificar o uso de algumas das ferramentas da suíte Pentaho Business Analytics, suponha que o diretor da Magazine Setorial, uma grande empresa fictícia de e-commerce, contrata os serviços de Business Intelligence de uma empresa especializada e explica, nos itens a seguir, as características e necessidades do projeto:

1. A empresa tem a necessidade de acompanhar a evolução de certos indicadores de venda, sem degradar o desempenho do sistema transacional, que gerencia as vendas efetuadas pelo site e por todas as filiais do Brasil;
2. A visualização dos dados deve ser possível pela internet, por meio de computadores, tablets ou celulares;
3. A solução deve ser criada sem custo algum com software;
4. A solução deve rodar em servidores com qualquer Sistema Operacional;
5. A solução deve ser funcional, mesmo em hardware com configurações “discretas”;
6. A solução deve permitir computar as vendas efetuadas até o dia anterior, medindo quantidade, valor de compra, valor de venda e valor do lucro totalizados por ano, trimestre, mês ou dia da venda;
7. A solução deve permitir totalizar os valores, em qualquer ordem ou combinação, pelos seguintes atributos: filial, vendedor, cliente, nota fiscal, produto e categoria do produto;
8. Um vendedor, ao executar uma venda, estará sempre atrelado a uma filial, mas pode mudar a filial em que trabalha a qualquer momento.

Normalmente os requisitos de um case real são repassados ao analista de BI de forma sucinta, tal como foram, propositadamente, descritos neste case. A análise dos requisitos é fundamental para que as perguntas corretas sejam formuladas e respondidas, ainda que mentalmente, para que então a solução seja modelada.

Na Figura 2 é apresentado o Modelo de Entidade-Relacionamento (MER ou ER) da base que armazena os dados do sistema transacional, em MySQL. Esta estrutura armazena dados referentes às filiais e seus vendedores, além dos dados dos clientes e suas notas fiscais, com os produtos de cada compra. Percebe-se, além disso, que os produtos são sempre de uma categoria (gênero ou tipo) de produto, pois a tabela de produtos tem uma chave estrangeira apontando para a de categoria de produtos, sem aceitar nulos.

Base de dados multidimensional – OLAP

Após a análise da base origem do processo de ETL e o confronto com os requisitos elencados, percebe-se que a criação de um cubo para totalizar os dados com toda a flexibilidade solicitada será a melhor alternativa, uma vez que esta solução contempla todos os requisitos e o usuário terá todos os resultados em uma única tela, com uma ferramenta OLAP.

Para armazenar os dados do cubo, uma base multidimensional é necessária. Muito embora existam mitos sobre a dificuldade na modelagem de dados multidimensional, o conceito é simples. Independente das diferenças doutrinárias de Ralph Kimball e William Inmon, dois dos precursores do BI, entende-se que a maioria das necessidades apresentadas pelos usuários são contempladas por meio do esquema estrela (star schema), defendido por Kimball e que consiste em uma “tabela fato” e suas várias “dimensões”. A outra vertente, útil em muitos casos e defendida por Inmon, prega o modelo floco de neve (snow flake), onde modelagens mais complexas (com maior normalização) são utilizadas para armazenar os dados.

Este case adota o esquema estrela que, tal como salientado, é utilizado na grande maioria dos casos e atende a todos os requisitos elencados aqui. Para tanto, abordar-se-á a seguir alguns conceitos importantes.

Um data warehouse pode ter um ou mais data marts, que seriam um conjunto de tabelas que armazenam os cubos multidimensionais de um mesmo assunto, como por exemplo, “vendas”. Cada dimensão permite analisar os fatos por uma determinada visão, seja por “filial”, “categoria de produto”, “data da venda”, etc.

As dimensões podem ser basicamente de dois tipos, Simples e SCD. No primeiro tipo, o processo de ETL não versiona os dados na base analítica. Isso significa que, por exemplo, caso o telefone de um cliente fosse alterado na base transacional, o telefone antigo seria sobrescrito na dimensão de clientes no processo de ETL. Este comportamento para o caso do telefone é perfeito, mas para analisar informações temporais, não.

Imagine que para o seu negócio, a UF em que o cliente mora é de suma importância e um determinado cliente se mudou para outro estado. Todo o histórico dele, quando ele morava no primeiro endereço, é extremamente relevante e por isso não deve ser perdido, ou seja, quando analisados os dados das vendas efetuadas na época em que ele morava no primeiro endereço, estes devem ser computados nas estatísticas da primeira UF, e os dados das vendas efetuadas depois da mudança devem entrar nas estatísticas da nova UF.

Para resolver esse problema existem as dimensões do tipo Slowly Changing Dimension (SCD), que guardam o histórico dos dados caso tenham seu valor alterado. O histórico pode ser criado de algumas formas, mas a principal é versionando o registro. Isto quer dizer que cada registro tem datas de início e fim da sua vigência, e uma coluna para indicar o número da versão. Deste modo, apenas um registro será vigente em um determinado momento. No exemplo do telefone alterado, o registro teria sua data de fim de vigência alterada do valor default, que é “01/01/2199”, para a data e hora atuais e seria incluído um novo registro vigente com o número da versão acrescido em um. Muitos autores dizem que esta característica é um divisor de águas entre as “verdadeiras” ferramentas de BI e as “falsas”. Isto porque, muitas soluções proprietárias de relativo sucesso no mercado não oferecem esta funcionalidade, limitando-se apenas a oferecer os dados atuais, desprezando toda a riqueza que o histórico tem a oferecer.

Dando continuidade aos importantes conceitos, a chave primária que as dimensões recebem é chamada de Surrogate Key ou “chave substituta”, daí o prefixo “SK_” em seus nomes. Outra nomenclatura utilizada é Technical Key, com o prefixo “TK_”.

Como boa prática, o primeiro registro de toda dimensão deve ter em seus atributos valores nulos. Isso porque, este registro será utilizado nos casos em que a ETL da tabela fato não encontra, nas dimensões, o registro procurado. Dessa forma, a tabela fato sempre apontará para um registro da dimensão, mesmo que com valores nulos, garantindo a integridade relacional e deixando evidenciado que aquela informação não foi encontrada. Isto permite que o processo de ETL, em um caso de não conformidade dos dados, siga sua execução normalmente, sem disparar erro algum.

Outra boa prática é utilizar colunas de auditoria nas dimensões, como a data de inserção e a data de alteração do registo. Mas evite criar estas colunas com valores default no banco de dados, pois assim, todo o controle fica com o Pentaho e o comportamento das tabelas é sempre o mesmo, independente do SGBDR envolvido.

A partir destes conceitos, têm-se subsídios para iniciar efetivamente a modelagem da base de dados analítica. Como primeira tarefa, devem-se verificar os dados da base origem e definir qual é o fato que será analisado a partir do cubo criado. Neste case são as vendas de produtos. Isto já define a origem dos dados da tabela fato e, pela padronização sugerida neste artigo, o seu nome. Como os dados virão da tabela “notafiscal_produto”, que contém uma linha por produto vendido, a tabela Destino será chamada de “ft_notafiscal_produto”, que teve seu nome formado pelo prefixo “ft_” e pelo nome da tabela origem.

Analisando os requisitos, percebe-se que o de número 7 orienta a definição de algumas dimensões, sendo, a princípio, uma para cada conceito tratado (filial, vendedor, cliente, nota fiscal, produto e categoria do produto), enquanto o requisito de número 8 diz que filial e vendedor podem ser armazenadas em uma mesma dimensão, explicando que um vendedor sempre estará ligado a uma filial, e terá o nome “dim_vendedor”, obtido concatenando o prefixo “dim_” com o nome da tabela origem. Como um vendedor pode mudar de filial, esta dimensão deve guardar o histórico dos seus dados.

Com o objetivo de facilitar a venda, bem como a gestão dos produtos, estes são agrupados conforme o gênero, de modo que um produto como o “Ipad” está atrelado à categoria “Eletrônicos”, simulando a experiência de estar em uma loja com diversos corredores. Neste contexto, um produto raramente muda de categoria e, em ocorrendo tal hipótese, pode-se simplesmente sobrescrever, na dimensão do produto, o valor antigo da categoria, mantendo o novo valor. Assim, a dimensão “dim_produto” deve ter também as informações da categoria do produto, além das informações referentes ao produto, e não precisa das colunas para o versionamento (número de versão e datas de vigência do registro).

Na prática, o que diferencia o tipo da dimensão é a presença ou ausência dessas colunas, pois nenhuma alteração na nomenclatura das tabelas é recomendada para indicar se a dimensão é uma SCD ou Simples. Isto porque, a qualquer momento pode-se optar por versionar ou deixar de versionar os registros de uma tabela, e a nomenclatura pode se tornar um obstáculo considerável, pois com o nome da tabela alterado, os metadados do cubo deveriam também refletir esta alteração e ser republicados.

Ainda analisando os produtos, uma característica que merece especial atenção é a de que os valores de compra e venda também vão para a tabela fato. Isto porque um servidor OLAP tem a incumbência de traduzir as consultas feitas por meio de queries multidimensionais (MDX) em simples queries SQL para obter os valores das suas diversas Medidas. Estes cálculos são sempre feitos levando em conta os dados da tabela fato de cada cubo, por meio da utilização de agregadores como soma, média, quantidade total, valor máximo e valor mínimo, etc. Entretanto, nada impede que os valores também sejam armazenados e versionados na “dim_produto”. Apesar disso, estes valores seriam apenas ilustrativos e não seriam utilizados nos cálculos.

Para que sejam possíveis análises levando em conta o cliente, a dimensão “dim_cliente” é fundamental e terá os atributos para versionamento, pois neste caso as informações são todas relevantes ao negócio. Outra dimensão necessária e presente em praticamente todas as aplicações de BI é a dimensão tempo, aqui chamada de “dim_data”.

Neste case serão computados dados com as granularidades de Ano, Trimestre, Mês e Dia, de acordo com os requisitos, mas poderíamos ter uma dimensão para as horas e minutos, por exemplo, o que permitiria análises sobre o horário em que cada compra foi efetuada. A dimensão “dim_data” terá um registro para cada dia e terá atributos para representar também o ano, trimestre e mês referentes ao dia em questão, sem a necessidade dos atributos de versionamento. Por exemplo, o registro do dia “01/01/2008” tem o atributo dsAno com o valor “2008”, o atributo dsMes com valor “Janeiro” e nrTrimestre com valor igual a “1”.

O processo com a finalidade de popular esta dimensão com seus dados deve gerar registros suficientes que abranjam as datas em que os fatos analisados no case ocorreram ou ocorrerão. Por exemplo, desde 01/01/2000 até 01/01/2020. Armazenamos dias suficientes para que a aplicação não exija a geração destes registros em um curto espaço de tempo. Datas mais avançadas também serão úteis para análises preditivas e por este motivo deve-se gerar linhas suficientes para se contemplar esta análise.

O modelo de dados multidimensional apresentado na Figura 3 segue o modelo estrela, defendido por Kimball, e será a base Destino do processo de ETL, criando assim o Data mart de Vendas. Na hipótese deste case ser proposto a diversos profissionais da área de Business Intelligence, as bases de dados por eles modeladas não seriam muito diferentes desta figura.

Com relação à performance do banco de dados, para este case foi selecionado o SGBDR MySQL com a engine MyIsam, que é otimizada para a leitura de dados. As Foreign Keys representadas na Figura 3 não serão criadas efetivamente, pois a engine MyIsam não conta com este recurso. Em outros SGBDRs, no entanto, a utilização das chaves estrangerias de integridade referencial é recomendada.

MySQL Engines Vs Bancos colunares

No que tange à performance na leitura de dados, alguns autores defendem que a engine InnoDB já atingiu maturidade suficiente para competir com a engine MyIsam, enquanto outros autores, visando melhor performance nesta leitura, defendem a utilização do MySQL com a engine MariaDb, ou então a utilização de bancos de dados colunares como Cassandra ou MongoDB. Entretanto, este assunto exige um novo estudo e foge do escopo deste artigo.

Saiba mais: Curso de MongoDB

Cumpre registrar que estão disponíveis para download, no site da SQL Magazine, as bases de dados Origem e Destino, os arquivos do PDI capazes de executar toda a ETL e o arquivo com os metadados do cubo de vendas.

Assim, para dar início ao processo de ETL descrito a seguir, baixe os arquivos fornecidos e execute os dois arquivos SQL em uma ferramenta cliente do MySQL. O arquivo DumpMagazineSetorial.sql cria a base origem, já com seus dados, e o arquivo CriaBaseDestino_OLAP.sql cria a base destino, pronta para receber os dados migrados pelo processo de ETL.

Pentaho Data Integration (Kettle)

O Pentaho Data Integration (PDI), uma das ferramentas da suíte open source Pentaho Business Analytics, é comumente chamado pelo nome do projeto que lhe deu origem, o Kettle. Ele é composto por quatro componentes, sendo o mais importante o Spoon, uma interface gráfica que será utilizada neste case para a criação do processo de ETL, enquanto os componentes Pan, Kitchen e Carte se destinam à execução, via linha de comando ou requisições HTTP, dos processos criados no Spoon. Como possibilitam chamadas remotas aos processos, estes componentes permitem a criação de clusters para a execução das ETLs e também a fácil utilização de processos Pentaho por softwares de terceiros.

Com a adoção do PDI, passa a ser indiferente para a aplicação qual é o SGBDR Origem e o Destino. Eles são apenas datasources, que fornecerão os dados que passarão por processos de validação, higienização, formatação, normalização, sincronização, etc.

O PDI tem conectividade com praticamente todos os bancos de dados do mercado e pode ainda acessar web services ou fazer chamadas HTTP, além de ler e gerar arquivos xml, json, csv, excel, hadoop fs, etc.

Download, Instalação e Configuração do PDI

Para a concretização do case proposto neste artigo, foram utilizados os softwares Pentaho Data Integration, Pentaho Schema Workbench e Pentaho Business Intelligence Server. Todos são executados em máquinas virtuais Java, daí a necessidade da prévia instalação do Java Runtime Environment (JRE) e da posterior instalação dos drivers JDBC em cada uma das ferramentas Pentaho. Os caminhos para download dos softwares referidos estão destacados na seção Links.

Para iniciar as atividades, faça o download da versão mais recente do PDI e descompacte o arquivo, disponibilizado em formato .zip. Feito isto, instale e execute o aplicativo realizando as etapas apresentadas a seguir:

• Para o caso do OS X, execute dentre os arquivos descompactados anteriormente, o Data Integration 64-bit ou o Data Integration 32-bit;
• Em SOs Linux, instale o JavaRuntime Environment (JRE) com o Path apontando para a pasta $JAVA_HOME/bin, digite no terminal ou inclua no etc/profile a configuração “export PATH=$PATH:/usr/java/jdk1.6.0_07/bin“ e então execute, dentre os arquivos descompactados anteriormente, o .\spoon.sh;
• Caso o SO seja o Windows, instale o JavaRuntime Environment (JRE) e configure as variáveis do sistema “JAVA_HOME” e “Path”. Para isto, acesse o Painel de Controle, Sistema e Segurança e, por fim, Sistema. Ao abrir a janela, selecione Configurações avançadas do sistema e na aba Avançado, clique em Variáveis de Ambiente. Nas Variáveis do sistema, clique em Novo e, na janela Nova Variável de Sistema, em Nome da variável, digite “JAVA_HOME”. Em Valor da variável, preencha com o caminho para a pasta do JRE da sua instalação do Java, por exemplo: “C:\Program Files\Java\ jre7”. Para finalizar a configuração no Windows, selecione Path, ainda em Variáveis do sistema, e clique em Editar..., completando o valor de Path com um ponto e vírgula e com o caminho para a pasta jre7\bin. Além disso, acrescente “;C:\Program Files\Java\jre7\bin” e execute, dentre os arquivos descompactados anteriormente, o Spoon.bat.

Drivers JDBC

Com o PDI instalado e em execução, a primeira tarefa é conferir se ele, em sua configuração inicial, já possui conectividade com os SGBDRs envolvidos. No PDI, a conexão aos bancos de dados é feita via JDBC, e cada banco de dados deve ter um driver JDBC correspondente para ele. Dessa forma, basta que o .jar do driver JDBC seja salvo em data-integration\libext\JDBC e o PDI seja reiniciado.

Para este case, em que é utilizado o MySQL, foi utilizado o driver mysql-connector-java-5.1.17.jar. O caminho para download deste driver se encontra na seção Links, ao final do artigo.

Saiba mais: Curso Completo de MySQL

Organização das ETLs

O PDI permite armazenar todas as ETLs em banco de dados, entretanto para isso seria necessária a criação do repositório do Pentaho. Neste case, utilizaremos a opção de salvar as ETLs em arquivos, e para a organização destas, foi criada uma pasta chamada SQLMagazine-DW, onde estes arquivos serão salvos.

Ao longo desta série, será criado um arquivo .ktr para cada transformação. Cada qual será composta por uma série de componentes chamados de steps, ligados entre si por meio de hops, que são as flechas indicativas da direção do fluxo dos dados.

Uma transformação pode ser executada individualmente ou fazer parte de um Job, que permite a execução de várias transformações ou até mesmo de outros Jobs em sequência, armazenados em arquivos .kjb.

Tanto os arquivos .ktr quanto os .kjb são gravados no formato XML, sem criptografia.

Criando a Conexão Origem

Para obter acesso aos dados da base origem, há a necessidade de criar uma conexão com o banco de dados. Esta configuração é feita uma única vez e a conexão será compartilhada entre todas as transformações. Isto gera uma flexibilidade muito grande, permitindo que as ETLs sejam criadas acessando uma base de desenvolvimento e, depois de efetuados os testes, com uma única modificação nesta configuração, todas as transformações passem a apontar para a base de dados de produção, por exemplo. Com o objetivo de demonstrar esta flexibilidade, será criada uma transformação e uma conexão para a base Origem, em MySQL, conforme os passos a seguir:

1. Inicie o PDI, clique no ícone New file para criar um novo arquivo, selecione Transformation e clique no ícone Salvar;
2. Selecione a pasta SQLMagazine-DW e salve a transformação com o nome “1-Testa_Conexoes”;
3. Na interface do PDI, ao lado esquerdo, tem-se a barra de componentes (steps) organizados por categorias. Arraste para a área de programação do PDI o step Table input, que fica na categoria Input, cuja finalidade é buscar dados via SQL. Com um duplo clique no step criado, abra a tela de edição;

Como achar um objeto na barra de ferramentas

O PDI possui duas abas no frame esquerdo. Na primeira, chamada View, estão todos os objetos utilizados, enquanto na segunda, chamada Design, estão todos os componentes disponíveis para utilização. Ambas contam com, na parte superior, a conveniência de um campo de busca pelo nome do componente.

4. Na tela exibida a partir da realização do passo anterior, clique em New... e preencha os campos da nova conexão com os dados da base de Origem, em MySQL, conforme a Figura 4;
5. Na sequência, clique em Test para se certificar que a conexão está correta e então em OK;
6. Para criar automaticamente a query do select, necessária para a recuperação dos dados referentes aos vendedores, clique em Get SQL select statement e, no componente Table input, selecione com um duplo clique a tabela vendedor, como indica a Figura 5;
7. Superado o passo anterior, o usuário deverá responder à seguinte questão: Do you want to include the field-names in the SQL? Clique em Yes para que o PDI gere a query com os nomes das colunas, ao invés do “perigoso” SELECT *;
8. Na continuidade, clique em Preview e em OK para visualizar as primeiras 1000 linhas;
9. Em seguida, clique em Close para fechar o Preview;
10. Na etapa Table input, em Step name, escreva um nome que não deixe dúvidas da sua funcionalidade, como: “Lê vendedor”;
11. Por fim, clique em OK para fechar o step e salve o arquivo.

Criando a Conexão Destino

Com a conexão para a base Origem configurada, criar-se-á a conexão para a base destino conforme as especificações a seguir:

1. Arraste para a área de programação do PDI o step Table output, que fica na categoria Output;
2. Crie uma seta de ligação (hop) entre os dois steps. Para isto, clique no primeiro step, mantenha a tecla Shift pressionada e arraste a seta até o step Table output, tal como se visualiza na Figura 6;

<

3. Com um duplo clique em Table output, que tem a finalidade de persistir os dados, informe em Step name o nome “teste”;
4. Na tela exibida a partir da realização do passo anterior, clique em New... e preencha os campos com os dados de conexão da base destino, conforme a Figura 7;
5. Na sequência, clique em Test para se certificar que a conexão está correta e então em OK;
6. Voltando à tela de edição do step Table output, em Target table, escreva “teste”;
7. Ainda nesta tela, clique em SQL e visualize a DDL para criação da tabela chamada teste no banco destino, com todos os campos do resultset;
8. Feito isso, clique em Execute e receba a mensagem de retorno do banco de dados, informando que a tabela “teste” foi criada com sucesso;
9. Em seguida, clique em OK e feche o step;
10. Para testar efetivamente as conexões, execute a transformação que está sendo desenvolvida, “1-Testa_Conexoes”, acessando o menu Action > Run;
11. Superadas estas etapas, a tela apresentada na Figura 8 será visualizada, onde será possível, mas não necessário neste case, configurar alguns parâmetros para a sua execução;
12. Em seguida, clique em Launch e acompanhe a execução, como exibido na Figura 9;

Com isso, a primeira ETL foi efetivada. Ela busca dados da tabela “vendedor” do banco Origem e os grava na tabela “teste” do banco Destino. Para verificar a execução desta transformação, observe os resultados obtidos diretamente no banco de dados. A correta execução desta transformação comprova a eficácia do driver JDBC de conexão com o MySQL, dos encodes, das permissões do banco de dados e da rede;

Para que as conexões criadas possam ser utilizadas por todas as transformações, no PDI, clique na aba View e depois em Database Connections. Em cada uma das duas conexões criadas, clique com o botão direito e depois em Share, como expõe a Figura 10.

Com as conexões criadas, torna-se transparente ao usuário do PDI quais são os bancos de dados manipulados, pois para esta ferramenta, os dados podem ter origens e formatos diversos. Além da facilidade de acesso aos dados, a ferramenta conta com uma longa lista de steps, cada qual com uma atribuição bem específica. Alguns destes steps executam as mesmas tarefas que os comandos SQL, mas nem por isso o conhecimento desta linguagem deixa de ser relevante, pois seu uso repercute, muitas vezes, em ganho de produtividade.

Conclusão

Neste artigo foram abordados os principais conceitos de Business Intelligence, e para exemplificá-los, foi proposto o case de uma loja de departamentos fictícia, formada por diversas filiais e com a necessidade de analisar os dados de suas vendas. Em seguida, foi apresentada a suíte Pentaho, capaz de contemplar os requisitos e regras de negócio elencados. De volta ao exemplo, a base de dados Origem foi analisada, de forma que o raciocínio necessário para a modelagem da base Destino, em formato estrela, pudesse ser descrito. Por fim, as etapas para a configuração do Pentaho Data Integration foram realizadas.

Os resultados desse trabalho darão subsídios para que, na segunda e última parte deste artigo, o processo de ETL seja criado, juntamente com os metadados do cubo, sua publicação no servidor web e a análise dos dados em uma ferramenta OLAP.

Continue lendo: Business Intelligence com Pentaho