Servidor Pentaho com Vagrant

Em um post anterior eu resenhei um livro da Packt que ensina como usar o Vagrant para criar ambientes de desenvolvimento. Lá eu comentei sobre como Vagrant é interessante, e até como eu tentei montar um servidor, mas não consegui. Ainda tenho muito que aprender sobre Puppet para fazer a coisa tão bem, mas vou dividir com vocês o que eu fiz. Na pior das hipóteses é um ambiente Pentaho pronto, e pode quebrar um bom galho.


Antes de mais nada eu preciso deixar claro que vou falar sobre o Pentaho por mera conveniência. Dá para aplicar tudo que eu vou falar aqui em qualquer plataforma, com quaisquer softwares de BI. Pentaho é do balacobado, mas cada um é livre para montar seu projeto como achar melhor. Eu gosto de software livre, lembram-se? Isso significa liberdade para usar o software que quiser. ;-)


O primeiro post caiu direto no assunto, e ficou meio “seco”. Por isso vou começar revisando a idéia toda com mais cuidado. Depois eu vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)

Processos & Ambientes

Desde sempre, e não apenas hoje em dia, qualquer projeto de BI sempre possuiu duas etapas: colher dados e usar dados.

A parte de colher os dados equivale à montagem de um DW, um Armazém de Dados. Já a parte de usar os dados corresponde a um projeto de Data Mining ou a um projeto que expõe os dados aos usuários por meio de ferramentas de análises.

Quando o projeto é pequeno podemos desenvolver na produção e simplesmente lidar com as consequências dessa bagunça, mas quando os projetos são maiores que um certo porte, esse “simplesmente” não se aplica mais. Precisamos de pelo menos dois ambientes: um de desenvolvimento e um de produção.

O problema é que manter dois ambientes separados acaba por originar discrepâncias entre eles, e aos poucos começam a ficar diferentes um do outro. Depois de um tempo as diferenças são tamanhas, e tão irreconciliáveis, que cada nova versão levada para produção gasta um tempo só ajustando o código para as diferenças.

E é neste ponto que a idéia de infraestrutura como código pode nos ajudar: ao invés de mantermos dois ambientes com configurações manuais, descrevemos cada ambiente com um código-fonte, tal qual um software. Desta forma mantemos um controle muito maior sobre cada configuração e, melhor ainda, podemos comparar ambas e evitar as discrepâncias que acabam por atolar o projeto a cada nova versão.

Softwares como Puppet e Chef cuidam para que as definições desse “código” sejam aplicadas e respeitadas. Sempre que um servidor sofre alguma mudança que o desvia de sua configuração “correta”, esses programas, chamados genericamente de provisionadores, forçam a configuração de volta, apagando as coisas erradas e restaurando as configurações definidas pelo projeto.

O Vagrant é um passo na direção de infraestrutura como código: ao invés de construirmos um servidor, simplesmente definimos um servidor virtual. Associado a provisionadores, conseguimos um projeto cuja configuração é uniforme de ponta-a-ponta. Mais: podemos trabalhar em projetos distintos, tendo um ambiente de desenvolvimento finamente ajustado para cada projeto, se um interferir com outro.

Se durante o desenvolvimento descobrimos que precisamos alterar alguma configuração, essa alteração entra no código que descreve o servidor, ao invés de ficar perdida em um manual qualquer. Por meio de um versionador, como Git, esse código de infra-estrutura entra no projeto e é distribuído para todos os envolvidos. Mais ainda, sendo versionado e propagado para a produção! É um mundo perfeito – ou não? ;-)

Vagrant BA Server

Agora eu vou mostrar para vocês a sequência de ações que eu tomei até construir um Pentaho BA Server apto a atender um projeto simples. Não é o resultado final perfeito, que eu gostaria de obter, pois ele não envolve nenhum provisionador – ainda estou batendo cabeça com isso, e não queria demorar para levar isso a vocês. Esse campo ainda está muito cru, e quanto antes essas idéias começarem a se espalhar por aí, melhor.

O processo é relativamente simples:

  1. Instalar o VirtualBox;
  2. Instalar o Vagrant;
  3. Criar um ambiente Vagrant;
  4. Adequar os parâmetros desse ambiente para o BA Server;
  5. Instalar o Pentaho BA Server.

Eu fiz tudo isso em Ubuntu 16.04-64bits, um Linux, mas deve ser possível repetir esses passos com Windows e Mac, já que eles são suportados.

Todas essas ações são tediosamente sem graça em Ubuntu:

  1. Abri um terminal e comandei sudo apt-get update, para atualizar os repositórios de pacotes;
  2. Instalei o VirtualBox comandando sudo apt-get install virtualbox;
  3. Instalei o Vagrant: sudo apt-get install vagrant;

    O site do Vagrant adverte as versões de repositório normlamente estão bem defasadas em relação ao projeto, e que não raro podem acabar apresentando problemas. Por isso, recomendam eles, baixe o instalador do site (aqui) ou compile o projeto do zero.


  4. Criei um ambiente Vagrant:
    1. Em outro terminal criei um diretório para o novo servidor: mkdir AmbienteVagrant;
    2. Entre neste diretório com cd AmbienteVagrant e criei o arquivo inicial: vagrant init precise32 http://files.vagrantup.com/precise32.box;
  5. Configurei esse ambiente para ter 1.5 GB e expor a porta 8080:
    1. No diretório AmbienteVagrant surgiu o arquivo Vagrantfile, que eu abri com o editor de textos;
    2. Entre as linhas que definem a configuração, Vagrant.configure(2) do e end, inseri esses dois trechos: config.vm.provider "virtualbox" do |vb|
      vb.memory = "1536"
      end
      e
      config.vm.network "forwarded_port", guest: 8080, host: 8080

    Isso vai mudar a memória da máquina virtual para 1.5GB ( = 1024 MB * 1.5), suficiente para um BA Server 5.x, e vai fazer um forward da porta 8080 da máquina virtual para a máquina real.

  6. Ainda dentro daquele diretório, subi o servidor Vagrant com o comando vagrant up. Na primeira execução ele baixou um disco virtual configurado com Ubuntu Precise Pangolin (12.04 LTS) para 32 bits, e só então subiu o servidor.

Voi-là! Agora temos uma máquina virtual pronta para ser configurada com o BA Server. O que precisamos fazer é bem simples: adicionar Java 1.7, baixar e descompactar o BA Server 5.4 e configurar o servidor para subi-lo automaticamente. Vamos nessa:

  1. Acessamos o servidor Vagrant rodando com o comando vagrant ssh. Um terminal se abre diretamente no servidor virtual;
  2. Vamos instalar o Java Oracle: é só adicionar o repositório e rodar um apt-get:
    1. Dentro do servidor Vagrant comandamos sudo apt-get update para atualizar a lista de pacotes disponíveis;
    2. Para adicionarmos a chave do repositório Java WebUpd8 precisamos de alguns pacotes. Instale-os com este comando:sudo apt-get install python-software-properties;
    3. Depois disso estamos preparados para adicionar a chave do PPA:sudo add-apt-repository ppa:webupd8team/java. Apenas bata enter para concluir;
    4. Atualize os repositórios novamente, com outro sudo apt-get update;
    5. Finalmente, comande a instalação do Java 7:sudo apt-get install oracle-java7-installer;

      A instalação do Java por meio de repositório no Ubuntu é um truque: a licença da Oracle não permite empacotá-lo no repositório, então o que realmente baixamos é um programa de instalação que coleta, por meio de um prompt, uma anuência com os termos legais da Oracle, para então baixar os arquivos do Java e configurá-lo. Por isso a série de pontinhos, indicando o download – uma coisa que não acontece com o apt-get ordinário.


  3. Ao final teste o java: comande java -version e veja se volta uma mensagem informando a versão;
  4. Vamos precisar de outro programa: unzip. Comande sudo apt-get install unzip para instalá-lo;
  5. Instale o BA Server:
    1. Ainda no SSH do Vagrant, entre sudo mkdir /opt/pentaho para criar o diretório no qual vamos deixar o servidor;
    2. Para facilitar nossa vida, mude esse diretório para “casa da mãe joana”, comandando sudo chmod 777 /opt/pentaho. Isso vai dar permissão de escrita geral no diretório pentaho;
    3. Mude para ele, cd /opt/pentaho, e baixe o Pentaho BA Server 5.4 a partir do SourceForge:wget http://bit.ly/29gb4ak --output-document=biserver-ce-5.4.0.1-130.zip
    4. Depois que ele terminar de baixar, descompacte-o: comande unzip biserver-ce-5.4.0.1-130.zip;
    5. Terminou de descompactar? O zip não é mais necessário, e você pode removê-lo com rm biserver-ce-5.4.0.1-130.zip. Não precisa, já que isso não vai forçar o tamanho do disco virtual para baixo automaticamente.

Ufa! Quase lá! Primeiro deixe o BA Server pronto para atuação automática:

cd biserver-ce
./start-pentaho.sh

Responda com enter à mensagem e aguarde alguns minutos. Daí teste abrindo seu navegador web e apontando para http://localhost:8080. Se tudo deu certo você verá a tela de login do servidor. Não se esqueça de baixar o servidor antes de prosseguir, com um ./stop-pentaho.sh dentro da caixa Vagrant.


É importante você rodar o BA Server ao menos uma vez manualmente, e assim se livrar do prompt de execução inicial. Caso contrário o servidor pode não subir na inicialização automática.


E o que falta? Bom, queremos que o servidor Vagrant fique pronto com um único comando – vagrant up – sem precisar de mais nada. Então é necessário configurar o servidor para subir e baixar sozinho, na inicialização da máquina.

Configurando o BA Server para Início Automático

O procedimento descrito aqui foi retirado do capítulo 3 do livro Pentaho na Prática. Você pode baixá-lo [deste link][pnpcap3_bitly], e ter um gosto do livro.

  1. Primeiro, garanta que o servidor Vagrant esteja no ar emitindo o comando vagrant up dentro do diretório em que criamos o arquivo de configuração Vagrant (/home/USUÁRIO/AmbienteVagrant);
  2. Faça login no servidor Vagrant com vagranta ssh;
  3. Assuma credenciais de root na caixa Vagrant: sudo su;
  4. Mude para o diretório de scripts de serviço: cd /etc/init.d;
  5. Abra um editor para um arquivo novo, neste mesmo diretório, chamado biserver-ce: nano biserver-ce (pode usar o vim, se quiser;)
  6. Agora precisamos do script de inicialização de servidor, para Linux. Abra este link em uma outra aba do seu navegador e procure o item “Script de Inicialização do BI Server para Linux”. Baixe este script, abra-o e copie tudo para dentro do arquivo do item anterior. Salve, pressionando CTRL+O e batendo enter, e depois saia do editor, pressionando CTRL+X;
  7. Por fim ative a execução automática: ainda no terminal Vagrant, como sudo, comande: (atenção! são dois blocos diferentes!)
ln -s /etc/init.d/biserver-ce /etc/rc2.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc3.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc4.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc5.d/S99BAServer
 
ln -s /etc/init.d/biserver-ce /etc/rc0.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc1.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc6.d/K19BAServer

É isso. Saia de tudo, pare o servidor Vagrant com vagrant halt e depois reinicie-o com vagrant up. Assim que o prompt voltar, abra um navegador web e aponte para http://localhost:8080/pentaho.


O comando vagrant up pode terminar antes de o servidor Pentaho estar no ar. Dê alguns minutos para tudo acabar de acontecer antes de tentar acessar o BA Server com o navegador web.


Conclusão

Acabei de reler tudo, para fazer a conclusão, e acho que devo um pedido de desculpas: parecia mais fácil na minha cabeça… Se você tiver algum problema, ou dúvida, deixe aqui um comentário, que eu te ajudarei.

Vamos lá, para a conclusão.

Virtualização é uma idéia muito legal. Virtualizar máquinas permite desde jogar antigos arcades a testar sistemas operacionais sem precisar arriscar ferrar a nossa máquina e nossos dados.

No mundo dos desenvolvedores, as coisas ficam cada vez mais complicadas. Uma das complicações mais perniciosas é o duo ambiente de desenvolvimento/produção: a tendência humana em mexer agora e documentar depois acaba bagunçando a situação a tal ponto que cada novo deploy, isto é, a cada entrega de uma nova versão no ambiente de produção, exige muito trabalho para compensar as diferenças entre os ambientes.

Para resolver esse problema surgiram tecnologias englobadas na disciplina DevOps, como os provisionadores, softwares que configuram, e forçam essa configuração em um ambiente, automaticamente. Dois membros desta classe são o Puppet e o Chef, que permitem definir uma infraestrutura como se fosse código, tornando possível até mesmo uma coisa estranha: versionar uma infraestrutura, isto é, guardar todas as configurações que ela já teve ao longo do projeto.

Alguém teve a (óbvia e genial) idéia de combinar essas duas coisas e conseguir uma terceira ainda mais bacana: ambientes de desenvolvimento isolados!

O software Vagrant, sobre o qual a Ed. Packt oferece um livro muito bom, faz exatamente isso: permite a criação de ambientes estanques, configurados ao gosto do projeto. Graças a ele, qualquer equipe pode ter um ambiente de desenvolvimento “limpo” (i.e. exclusivo por projeto), uniforme (igual para todo mundo) e estável (não muda sem querer ou por acidente.)

Em um post anterior eu resenhei o livro da Packt sobre o Vagrant, e hoje eu dei aqui o passo-a-passo para montar um servidor Vagrant para projetos que usem o Pentaho BA Server 5.4.

… ou quase: o ideal teria sido definir a configuração como um script Puppet ou Chef (scref?? kkk) e deixar o provisionador tomar conta. Mas eu ainda tenho muito a aprender e por isso resolvi mostrar o que eu já consegui fazer.

Burning Down the House

Eu seguia feliz da vida estudando o Vagrant, quando, de repente! (kkk), fiz o curso da 4Linux sobre DevOps! Foi quando eu fui obrigado a aprender sobre o [Docker][docker_bitly], algo do que eu vinha escapando deliberadamente (infra não é minha praia.) O Docker leva adiante a idéia de isolamento proposta pela virtualização, mas a um custo de infra menor: enquanto que a virtualização quebra uma máquina real em várias virtuais, o Docker monta várias máquinas “virtuais” compartilhando a mesma infra. Isso tem uma grande vantagens logo de saída: por não virtualizar tudo, mas apenas a parte que interessa, ele é muito mais leve e por isso usa melhor os recursos da máquina. De cara a performance de um container Docker é melhor que a de uma máquina virtual.

Há muita coisa ainda para se evoluir e resolver na tecnologia de containers mas, como colocou o The Register, se virtualização é uma tecnologia importante e valiosa em certos cenários, em outros ela é pesada e ineficiente, e coisas como containers são o futuro.

Uma destas coisas, na minha opinião, é justamente a gestão de ambientes, e não apenas de desenvolvimento! Como um container tem performance nativa, podemos montar servidores reais usando Docker e ainda atingir o grau de isolamento e controle proposto pelo Vagrant. No fundo, é a mesma coisa, mas executada de uma forma diferente.

Por isso eu disse, no começo, que “vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)”: não sei se vou continuar investindo no Vagrant. Ao menos por um tempo, eu definitivamente vou cair de cabeça no mundo do Docker! Eu até comprei um livro da Packt sobre isso, o Learning Docker. Assim que eu acabar de lê-lo vou fazer sua resenha aqui e depois montar o mesmo ambiente de hoje usando Docker.

Docker

Docker

Docker Docker Docker Docker Docker Docker Docker Docker

Já reparou como é viciante falar Docker? Docker Docker Docker Docker

Até a próxima! ;-)

Migrando o Pentaho BA Server +5.x

Até a versão 4.x o Pentaho BI Server usava um repositório que misturava sistema de arquivos com bancos de dados, e era muito prático de mexer. Só tinha um problema: era tosco pra dedéu. A Pentaho aproveitou a reforma geral que deu à luz o BA Server 5.0 e adotou um repositório “profissa”. A partir da versão 5.0 o servidor passou a usar o JackRabbit como repositório oficial.

Eis a definição do projeto pela Apache Foundation, que cuida desse projeto:


O repositório de conteúdo Apache Jackrabbit é uma implementação 100% aderente à API de Repositórios de Conteúdo para Tecnologia Java (JCR especificada nas JSR 170 e JSR 283.)


Logo a seguir dizem que um repositório de conteúdo é “um provedor de armazenamento hierárquivo de conteúdo com suporte para conteúdo estruturado e não-estruturado, busca por texto, versionamento, transações, observação e mais”. Interessante! Será que o repositório do BA Server suporta versionamento? O que é observação? Perguntas para outro post!

Para os usuários do BA Server esse novo formato se traduz em segurança aumentada, mais integração com a plataforma e seus serviços, maior flexibilidade e melhor performance em geral. Uma das mudanças trazidas por esta nova tecnologia é o processo de migração de soluções (do conteúdo gerado no servidor) entre duas versões do BA Server. Antes era só copiar as pastas particulares do diretório ./pentaho-solutions de uma instalação para outra, atualizar o servidor do destino e estava feito.

Ou quase. Na verdade, havia um trabalho meio chato nesse caminho, já que você tinha que levar também as permissões por pasta e objetos e cuidar de alguns outros detalhes. No final das contas, só quem tinha a versão Enterprise (paga) é que tinha um processo de migração mais facilitado.

A adoção do Jackrabbit tornou esse processo de migração mais profissional também para a comunidade. E isso tudo eu escrevi só para dizer que neste post eu vou dividir com vocês o que eu aprendi quando precisei migrar um servidor da série 5.x.


AVISO IMPORTANTE!!!

Mesmo que tenha resolvido meu caso, esse procedimento é experimental!! Estou compartilhando aqui o pouco que eu aprendi para resolver a minha necessidade. Se você decidir aplicá-lo a seu ambiente, o fará por sua conta e risco. Eu não posso ser responsabilizado por nenhuma de suas ações!


Isto posto, terei prazer em ajudar se você tiver algum problema ou dúvida – basta postar um comentário. ;-)

Preparando o Cenário

Para que você aprenda o processo, sem ser atrapalhado por um monte de pequenos detalhes que podem aparecer no caminho, eu sugiro que monte um ambiente simples, no qual você possa testar o processo e praticá-lo à vontade, até aprendê-lo e só então aplicá-lo ao seu ambiente.

Para montar esse ambiente eu sugiro o BA Server 5.4, mas em princípio esse processo deve ser compatível com qualquer versão das séries 5.x e 6.x – mais uma vantagem da adoção de um padrão. Apenas esteja atento para o fato de que o programa que faz a exportação/importação pode ser diferente (pouco ou muito) de uma versão para outra, como, por exemplo, ter um switch a mais ou a menos.

Nosso ambiente terá dois BA Servers, um de origem e outro de destino. Para conseguir isso apenas descompacte o ZIP do BA Server 5.4 para pastas ora com um nome, ora com outro. Neste exemplo o diretório do BA Server de origem chama-se ./biserver-ce e o de destino, ./biserver-ce_DESTINO

Diretório /opt/pentaho/5.4 com dois BA Servers.
Diretório /opt/pentaho/5.4 com dois BA Servers.

Não é possível rodar dois BA Servers simultaneamente sem alterar diversas configurações em pelo menos um deles. Por isso, para manter tudo o mais simples possível e focar só no processo de migração, não vamos rodar os dois ao mesmo tempo, mas apenas um de cada vez: rodamos o de origem, exportamos o repositório, paramos esse servidor, subimos o de destino e importamos o pacote extraído do outro.

Vamos lá!

Exportando o Repositório

Depois de expandir o ZIP do BA Server, suba-o: abra um terminal, mude de diretório e comande ./start-pentaho.sh.


Se você não tem idéia de como fazer isso, bolas, porque está se metendo a migrar a coisa? :-) Mas se você é como eu, que não desiste só porque não está entendendo nada, e quiser experimentar mesmo assim, baixe o capítulo de degustação do meu livro Pentaho na Prática.


Com ele no ar, acesse-o (URL http://localhost:8080/pentaho) com usuário admin e senha password e mude alguma coisa. Apague um arquivo, remova um diretório, criei e salve alguma análise com o jPivot etc. Se você não modificar nada, não vai notar o resultado do processo.

Eu removi todos os usuários, menos o admin, e criei alguns novos. Montei uma visão OLAP com jPivot e salvei em admin. Daí criei uma pasta pública chamada Rodas de Aço e movi para lá todo conteúdo das subpastas do Steel Wheels, apagando esta. No final ficou assim:

Origem: note as pastas de usuários e pública.
Origem: note as pastas de usuários e pública.

Pronto para exportar!

  • O servidor deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de origem;
  • Comande:
./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log

Se tudo der certo a saída no terminal vai ser mais ou menos esta:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$ ./import-export.sh --export --url=http://localhost:8080/pentaho --username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip --charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
Export Completed
Response Status: 200
Export written to: /tmp/Repositorio_54_Origem.zip
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$

E você terá um zip, na pasta /tmp, contendo o repositório de arquivos do servidor:

Conteúdo do arquivo de backup do repositório.
Conteúdo do arquivo de backup do repositório.

Note que interessante: ainda existem diretórios ocultos, como o famoso /bi-developers, uma coleção de exemplos de uso do BI Server.

E uma “pegadinha”: parece que nenhum dos diretórios de usuários, que estavam vazios, foram exportados. Isso não é verdade, pois eles aparecem se listarmos o conteúdo do arquivo em um terminal (ou talvez com algum outro programa que não o File Roller):

fabio@pentaho:/tmp$ unzip -l Repositorio_54_Origem.zip 
Archive:  Repositorio_54_Origem.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2016-06-29 13:02   home/
        0  2016-06-29 13:02   home/Everton/
        0  2016-06-29 13:02   home/Fabio/
        0  2016-06-29 13:02   home/Joe/
        0  2016-06-29 13:02   home/admin/
     7052  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot
      186  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot.locale
       62  2016-06-29 13:02   home/index_pt_BR.locale
        0  2016-06-29 13:02   public/
        0  2016-06-29 13:02   public/bi-developers/
(...)
       84  2016-06-29 13:02   public/index.locale
       64  2016-06-29 13:02   public/index_pt_BR.locale
   961634  2016-06-29 13:02   exportManifest.xml
---------                     -------
 10708536                     2014 files
fabio@pentaho:/tmp$

O comando de exportação para Windows tem apenas as diferenças do sistema operaciona: muda de .sh para .bat e tudo que é / vira c:\ :

import-export.bat --export --url=http://localhost:8080/pentaho
--username=admin --password=password
--file-path=%USERPROFILE%\AppData\Local\Temp\Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true
--logfile=%USERPROFILE%\AppData\Local\Temp\logfile_export.log

Ao contrário do Linux, que por padrão tem um diretório /tmp universal, no Windows cada usuário tem seu próprio diretório temp. Ele pode ser referenciado pela variável %USERPROFILE%\AppData\Local\Temp, que usamos acima.


Importando o Repositório

Baixe o servidor de origem e suba o de destino. Pronto?

  • O servidor de destino deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de destino;
  • Comande:
./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip
--logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true

Ele vai passar um tempo “pensando” e depois começar a cuspir a saída do processamento:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_DESTINO$ ./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin --password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip --logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
done response = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Repository Import Log</title>
<style type="text/css">
<!--
body, table {font-family: arial,sans-serif; font-size: x-small;}
th {background: #336699; color: #FFFFFF; text-align: left;}
-->
</style>
</head>
<body bgcolor="#FFFFFF" topmargin="6" leftmargin="6" style="font-family: arial,sans-serif; font-size: x-small">
<hr size="1" noshade>
Log session start time Wed Jun 29 15:00:44 BRT 2016<br>
<br>
<table cellspacing="0" cellpadding="4" border="1" bordercolor="#224466" width="100%">
<tr style="background: #336699; color: #FFFFFF; text-align: left">
<th>Time</th>
<th>Import File</th>
<th>Level</th>
<th>File:Line</th>
<th>Message</th>
</tr>
(...)

Isso vai continuar por mais um monte de linhas, varrendo o arquivo inteiro até o final. As mensagens no final devem ser assim:

(...)
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:53</td>
<td title="Message">Start File Import</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level"><font color="#993300"><strong>WARN</strong></font></td>
<td>Log4JRepositoryImportLogger.java:181</td>
<td title="Message">Public</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:47</td>
<td title="Message">End Import Job</td>
</tr>
</table>
<br>
</body></html>

Na minha contagem, o processo soltou exatas 63636 linhas, incluindo o cabeçalho com mensagens sobre o Java no início – e era um repositório mínimo. :-O

Vamos verificar o resultado? Eis o estado do repositório do servidor de destino antes da importação do backup:

Servidor de destino antes da restauração.
Servidor de destino antes da restauração.

Após fazer a importação usando o import-export.sh temos:

Servidor de destino após a restauração.
Servidor de destino após a restauração.

Observe que não aparece nenhuma das pastas de usuário do servidor de origem, que nós sabemos que existiam no arquivo ZIP, e continuam existindo as pastas que já existiam no destino, ou seja, não foram apagadas.


Volto a frisar: teste o processo algumas vezes para evitar surpresas. Neste exemplo migramos pastas vazias, mas de usuários que não existiam no destino. E se elas não estivessem vazias na origem? Eu fiz o teste: arquivos de diretórios de usuários que não existem no destino, não são importados. Isso é muito importante: arquivos que vêm de diretórios de usuários, na origem, que não existem no destino, são perdidos!! Para funcionar, o usuário precisa existir no destino!


Como Funciona?

É bem simples, na verdade: a Pentaho construiu um programa, import-export.sh (Linux e MacOS) ou import-export.bat (Windows), que chama um “processo” (classe? método?) diretamente no código do servidor. Eis o conteúdo da versão Linux/MacOS (observe a última linha do bloco a seguir:)

#!/bin/sh
DIR_REL=`dirname $0`
cd $DIR_REL
DIR=`pwd`
#cd -
 
. "$DIR/set-pentaho-env.sh"
setPentahoEnv
 
# uses Java 6 classpath wildcards
# quotes required around classpath to prevent shell expansion
"$_PENTAHO_JAVA" -Xmx2048m -XX:MaxPermSize=256m -classpath "$DIR/tomcat/webapps/pentaho/WEB-INF/lib/*" org.pentaho.platform.plugin.services.importexport.CommandLineProcessor ${1+"$@"}

Esse programa possui várias opções e parâmetros. Para ver a lista completa de opções, basta rodar o comando sem nenhum switch:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$ ./import-export.sh
 
(... mensagens de erro por falta de parâmetros ...)
 
usage: importexport
Unified repository command line import/export tool
 -a,--url <arg>                      url of repository (e.g.
                                     http://localhost:8080/pentaho)
 -a_ds,--analysis-datasource <arg>   Analysis datasource description
 -a_xmla,--xmla-enabled <arg>        Analysis XMLA enabled flag
 -c,--charset <arg>                  charset to use for the repository
                                     (characters from external systems
                                     converted to this charset)
 -cat,--catalog <arg>                catalog description
 -ds,--datasource-type <arg>         datasource type
 -e,--export                         export
 -f,--path <arg>                     repository path to which to add
                                     imported files, or to export from
                                     (e.g. /public)
 -fp,--file-path <arg>               Path to directory of files for
                                     import, or path to .zip file for
                                     export
 -h,--help                           print this message
 -i,--import                         import
 -l,--logfile <arg>                  full path and filename of logfile
                                     messages
 -m,--permission <arg>               apply ACL manifest permissions to
                                     files and folders  (import only)
 -m_id,--metadata-domain-id <arg>    Metadata domain ID
 -o,--overwrite <arg>                overwrite files (import only)
 -p,--password <arg>                 repository password
 -params,--params <arg>              parameters to pass to REST service
                                     call
 -r,--retainOwnership <arg>          Retain ownership information  (import
                                     only)
 -res,--resource-type <arg>          Import/Export resource type
 -rest,--rest                        Use the REST (Default) version (not
                                     local to BI Server)
 -u,--username <arg>                 repository username
 -v,--service <arg>                  this is the REST service call e.g.
                                     acl, children, properties
 -w,--withManifest <arg>             Export Manifest ACL file included
                                     (export only)
Common options for import & export using REST ServicesExample arguments
for import:
--import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/public
--file-path=c:/temp/steel-wheels
--logfile=c:/temp/logfile.log
--permission=true
" + "--overwrite=true
--retainOwnership=true
Example arguments for export:
--export --url=http://localhost:8080/pentaho --username=admin
--password=password
--file-path=c:/temp/export.zip --charset=UTF-8 --path=/public
--withManifest=true--logfile=c:/temp/logfile.log
Example arguments for running REST services:
--rest --url=http://localhost:8080/pentaho --username=admin
--password=password
-path=/public/pentaho-solutions/steel-wheels/reports
--logfile=c:/temp/logfile.log --service=acl
 
(... Erros por falta de parâmetro ...)
 
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$

Então, por exemplo, para exportar apenas o diretório do usuário Joe, usando para isso o usuário admin, que possui todas as permissões de acesso, o comando fica:

./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/PastaDoJoe.zip
--charset=UTF-8 --path=/home/Joe --withManifest=true --logfile=/tmp/logfile_export.log

Note que não exportamos simplesmente “Joe”, mas sim “/home/Joe”. Isso porque a pasta do Joe existe dentro de uma outra subpasta, como você pode observar ao notar o atributo Source nesta figura:

Pasta do Joe no diretório /home.
Pasta do Joe no diretório /home.

E é por isso que usamos --path=/ para exportar/importar o repositório inteiro: / é a raiz de tudo.

O processo de importação segue as mesmas regras, só que no sentido inverso: levando o conteúdo exportado para dentro de um repositório.

Não deixe de consultar o Pentaho Infocenter (ou Pentaho Help) para aprender mais sobre isso:

Curiosamente, a página do BA Server 6 fala que o procedimento exporta tudo, incluindo usuários e permissões, mas não consegui encontrar essa informação no arquivo ZIP. O exportManifest.xml, que registra a lista de pastas e arquivos, e seus respectivos donos e permissões, não mostra nada. E só para tirar a cisma, tentei importar no 6 o repositório do 5, mas o seis não registrou nenhum dos usuários que eu criei no cinco. Pode ser que essas páginas estejam se referindo a alguma ferramenta que vai junto da versão Enterprise (paga), indisponível na Community.

Conclusão

Vimos como usar o programa import-export.sh/bat para exportar o repositório de arquivos de um servidor Pentaho e importar em outro. Depois da substituição do mecanismo de repositório que existia até a versão 4.8, esse método é a única forma de fazer a migração entre dois servidores – uma tarefa necessária quando se instala uma nova versão do Pentaho BA Server e queremos levar tudo que nossos usuários já fizeram.

Mostrei um exercício simples, “migrando” o repositório entre duas instâncias da versão 5.4, para que você possa estudar o processo livre de problemas paralelos. Você pode usar o que aprendeu para experimentar uma migração real, levando os arquivos de uma versão 5.x para a 6.x, por exemplo.

Além disso, ainda é preciso levar os usuários e seus papéis, e todas as conexões de dados, metamodelos e esquemas OLAP. Mesmo assim a nova tecnologia Jackrabbit é mais prática (em especial para a versão CE) que o antigo formato, tosco pra dedéu, de filesystem + banco de dados.

Feliz migrações! ;-)

Relatórios com Metamodelos – Complemento

Semana passada eu mostrei como montar um relatatório a partir de um metamodelo. Hoje eu vou encerrar o assunto com mais algumas dicas.

Concepts

Um dos pilares de um bom relatório é a qualidade da apresentação, e nesta qualidade inclui-se a consistência, ou seja, dados do mesmo tipo possuem a mesma aparência, ou no mínimo possuem algum padrão.

Um relatório ordinário, construído a partir de um SQL, tem seus campos formatados livremente. Se por um lado isso é bom, já que dá espaço irrestrito para o autor do relatório passar sua mensagem, por outra é ruim, porque obriga esse mesmo autor a uma formatação tediosa, repetitiva. Fora o aborrecimento de repetir sempre a mesma coisa, ainda podemos acabar esquecendo ou mudando algum detalhe ao longo do tempo.

Um concept, ou conceito, é um padrão de formatação definido dentro do metamodelo e obedecido integralmente pelo PRD. Acesse esta página para obter mais informações sobre concepts.

Vamos fazer um exercício: criaremos um conceito de texto destacado e aplicaremos ao relatório do post anterior. Primeiro, abrimos o PME e carregamos o metamodelo do Beltrano OLTP. Em seguida acessamos o editor de conceitos (concept editor):

Acessando editor de conceitos no PME.
Acessando editor de conceitos no PME.

Nele clicamos sobre o conceito Base e depois clicamos no sinal de + no canto superior direito dessa seção. Uma janela se abrirá, pedindo o nome do conceito – eu eu chamei de Destaque. Como criamos o novo conceito a partir do Base, Destaque herdou as propriedades deste. Caso contrário, se tívéssemos criado um conceito na raiz, ele teria nascido vazio e precisaria receber todos os atributos prentendidos.

Com o conceito Destaque selecionado, clique no elo ao lado do atributo Color of Text. Isso quebra a herança e nos permite redefinir aquele atributo, mantendo o restante:

Novo conceito: destaque (fonte em cor vermelha).
Novo conceito: destaque (fonte em cor vermelha).

Dê ok e, de volta à interface principal do PME, localize um campo na camada de apresentação – Neste exemplo eu selecionei Autor. Clique com o botão da direita sobre ele e selecione Set Parent Concept… para escolher o conceito desejado. Selecione Destaque na janela que se abrirá e Ok para aplicar.

Atribuindo conceito a campo Autor.
Atribuindo conceito a campo Autor.

Feito! Quando o campo Autor for usado no relatório, ele aparecerá em cor vermelha, em destaque:

Conceito entra em ação automaticamente.
Conceito entra em ação automaticamente.

Notou a festa do caqui que está o layout do relatório, na parte de cima da figura? Mas como o PRD vai respeitar o definido no metamodelo, o relatório vai sair arrumadinho, apenas com o nome do autor em vermelho!

Outro exemplo: digamos que precisamos formatar a coluna da direita como um valor monetário, usando a máscara R$ #.###,00. Alteramos ou criamos um conceito no metamodelo, exportamos e reaplicamos o metamodelo à consulta previamente criada:

Altere um conceito para alterar o relatório.
Altere um conceito para alterar o relatório.

Reaplicar o metamodelo a um relatório aberto no PRD é meio chato. Como o PRD não embute o metamodelo no relatório, bastaria purgar o cache ou fechar o relatório e recarregá-lo para forçar o PRD a reler o XMI. Por puro e simples hábito, eu apelo para força bruta: simplesmente apago e recrio a fonte e as consultas (apelando para um copy-paste básico, já que ninguém é de ferro…)

Para relatórios publicados no BA Server não é preciso nada: basta republicar o modelo a partir do PME, ou recarregá-lo no quadro Manage Data Sources e já está valendo. A série 5 do BA Server veio com purga e recarga automática de metamodelos na republicação.


Só essa simplicidade e praticidade, na minha opinião, já é o bastante para fazer valer a pena usar um MQL ao invés de SQL.

Prompts

Um recurso crucial para relatórios são os “prompts”, ou filtros, que permitem ao usuário escolher uma determinada fatia dos dados para apresentação. O PRD oferece esse recurso sob o nome de parameters. Um parameter – ou prompt – é uma variável preenchida pelo usuário em tempo de execução, que entra na consulta como algum tipo de restrição. Por exemplo, a consulta abaixo retorna todos os clientes de um determinado “tipo”, filtrando a consulta pelo conteúdo do prompt tipo_selecionado:

    SELECT cliente, estado, cidade
    WHERE tipo = ${tipo_selecionado}

Não é um mecanismo complicado, mas não é trivial o bastante para eu mostrá-lo aqui completamente. Assistam este vídeo que verão como fazer um prompt.

Quando usamos uma consulta MQL, de metadados, aplicar a restrinção é um pouco mais simples. Os passos são esses:

  1. Construa um relatório com MQL, como o que fizemos no post passado;
  2. Crie uma consulta (MQL, SQL, tanto faz) que retorne a lista de opções que o cliente pode selecionar;
  3. Crie o parâmetro no PRD usando essa consulta como fonte;
  4. Volte para a consulta principal e, usando a interface de criação de consultas, adicione o filtro e insira o parâmetro.

No nosso caso vamos filtrar o relatório de vendas do Alexandre por UF.

Primeiro, construímos uma consulta em MQL que traz a lista de estados:

Lista de UFs criada no construtor de consultas MQL.
Lista de UFs criada no construtor de consultas MQL.

O MQL dessa consulta é:

    <mql>
      <domain_type>relational</domain_type>
      <domain_id>BeltranoOLTP</domain_id>
      <model_id>BV_MODEL_1</model_id>
      <model_name>Beltrano OLTP</model_name>
      <options>
        <disable_distinct>false</disable_distinct>
        <limit>-1</limit>
      </options>
      <selections>
        <selection>
          <view>BC_CLIENTES_PF</view>
          <column>BC_ESTADOS_UF_2</column>
          <aggregation>none</aggregation>
        </selection>
      </selections>
      <constraints/>
      <orders>
        <order>
          <direction>asc</direction>
          <view_id>BC_CLIENTES_PF</view_id>
          <column_id>BC_ESTADOS_UF_2</column_id>
        </order>
      </orders>
    </mql>
    </pre>

Construímos um paramater alimentado por essa consulta, chamado UF:

Novo parâmetro UF, alimentado pela consulta Query 2 do metamodelo.
Novo parâmetro UF, alimentado pela consulta Query 2 do metamodelo.

Depois inserimos esse parâmetro, UF, na consulta que popula o relatório: colocamos a coluna que vai ser filtrada na seção constraints e aplicamos uma igualdade para o parâmetro.

Inserindo o parâmetro na consulta principal com o editor de MQL.
Inserindo o parâmetro na consulta principal com o editor de MQL.

O truque é envolver o parâmetro em chaves, { e }. Com isso o construtor de consultas reconhece que se trata de um parâmetro e não de um valor ordinário, e ajusta a consulta automaticamente. A título de comparação, observe o filtro para pegar apenas as vendas do Alexandre.


Ao adicionar um nome cercado por { e } nos filtros, o construtor de consulta realiza duas coisas:

  1. Define um parâmetro no início da consulta
    <mql>
      <domain_type>relational</domain_type>
      <domain_id>BeltranoOLTP</domain_id>
      <model_id>BV_MODEL_1</model_id>
      <model_name>Beltrano OLTP</model_name>
      <options>
        <disable_distinct>false</disable_distinct>
        <limit>-1</limit>
      </options>
      <parameters>
        <parameter defaultValue="XX" name="UF" type="STRING"/>
      </parameters>
      <selections>
        <selection>
          <view>BC_PEDIDOS</view>
    <...restante da consulta...>        
    
  2. E usa esse parâmetro na seção conditions:
    <...começo da consulta...>
      <constraints>
        <constraint>
          <operator>AND</operator>
          <condition>CONTAINS([BC_PEDIDOS.BC_VENDEDOR_NOME_COMPLETO];"Alexandre")</condition>
        </constraint>
        <constraint>
          <operator>OR</operator>
          <condition>[BC_CLIENTES_PJ.BC_ESTADOS_UF_3] = [param:UF]</condition>
        </constraint>
      </constraints>
    

Ao rodar o relatório o PRD cria e apresenta um controle do tipo drop-down, populado com a lista dos estados. Sempre que um estado é selecionado, o relatório é automaticamente filtrado:

Filtro aplicado em consulta MQL.
Filtro aplicado em consulta MQL.

Um bom uso dessas possibilidades é criar relatórios que se adequam a cada usuário: basta usar o parâmetro pré-definido env::username para filtrar a consulta pelo nome do usuário na plataforma desde que esse usuário possua um nome igual registrado no banco de dados.

Por exemplo, se eu registrar no Pentaho BA Server os vendedores com o mesmo nome que possuem no Beltrano OLTP, eu posso filtrar os dados montando uma constraint do tipo Vendedor CONTAINS {env::username}.

Experimente!

8.3 Segurança

Por fim, mas não menos importante, um metamodelo pode restringir o conteúdo de uma consulta em função das permissões de acesso – controle de segurança – dos dados.

Como sempre, a idéia é simples: definimos um filtro de dados no metamodelo que usa o nome do usuário e, eventualmente, seu papel, para montar um controle de exibição baseado no controle de acesso.

Como fazer:

  1. No Pentaho BA Server, usando o papel de administrador, registre todos seus usuários. Eu fiz isso com os usuários da Beltrano;
  2. Com Pentaho Metadata Editor edite o metamodelo e registre um filtro no nível do modelo de negócio, seção Data Constraints: qualquer consulta contra esse modelo de negócio vai embutir aquele filtro automaticamente. Salve e publique o metamodelo no servidor;

    Registrando filtro no PME.
    Registrando filtro no PME.
  3. No PRD basta remover qualquer filtro local. Por exemplo, eu removi o filtro de usuário “Alexandre”, deixando o relatório trazer dados de todos os vendedores, indistintamente. Salvei e publiquei o metamodelo.

Feito! :-)

Para testar, acessei a plataforma com duas contas: Fábio e Alexandre. Como o relatório consome metadados, e os metadados são completamente filtrados por meio do atributo Data Constraints no Business Model, os dados apresentados já estão filtrados.

Resultado do filtro por controle de segurança.
Resultado do filtro por controle de segurança.

8.4 Conclusão

“Nossa, Fábio! Que maravilha!”, dirão vocês, “e não tem nenhuma desvantagem?”

Sim, tem: justamente adicionar uma outra camada para manutenção. Se usamos apenas SQL, qualquer alteração no banco entra em efeito imediatamente para o relatório. Se usarmos um metamodelo vamos precisar atualizar a camada de metadados antes de poder sequer testar as mudanças no PRD. Fazer uma pequena alteração na formatação pode forçar o analista a quebrar o vínculo do campo com a metaconsulta, perdendo a vantagem do modelo centralizado, ou então obrigar a uma atualização do metamodelo, cascateando a publicação de uma nova versão.

Há uma segunda desvantagem, mas é mais sutil e, talvez, pior: aparentemente não há como fazer UNIONs! Isso não é um problema para modelos bem comportados, mas modelos como o do Beltrano – que nem é tão exótico assim – se quebram quando tentamos fazer certas combinações numa só consulta. Por exemplo, no modelo transacional, não é possível escrever um único SQL que traga todos os clientes PF e PJ. É preciso duas consultas, coladas a posteriori com UNION, para então chegar ao conjunto completo. E eu não achei como fazer isso com MQL.

Ou seja, as vantagens de uso de um metamodelo vêm com um preço: um processo de desenvolvimento com mais alguns passos. Se isso vai compensar no final é uma questão respondida projeto a projeto.

Até a próxima! :-)

Relatórios com Metamodelos

Hora de uma pausa na série de artigos sobre conceitos, e ver um pouco de Pentaho. Hoje vou mostrar uma coisa que já me pediram algumas vezes: como criar um relatório usando um metamodelo como fonte de dados.

Sério? Relatórios??

Sim, sério!! Relatórios são o solo fértil no qual germinam as primeiras idéias e hipóteses em BI. É com uma listagem simples que podemos fazer os primeiros testes, sem contar que, bem construídos, são uma excelente ferramenta de apresentação e acompanhamentos.

Um bom relatório tem o peso de um bom argumento. Não há motivo técnico para prescindir de um relatório se ele for o suficiente para seu propósito.

O Pentaho Report Designer

O Pentaho Report Designer (PRD) oferece uma vasta gama de recursos para criar relatórios visualmente atraentes e versáteis. A figura abaixo, por exemplo, mostra um relatório que lista o estoque de uma empresa.

Relatório de estoque, que buscas fotos do produto no Google.
Relatório de estoque, que buscas fotos do produto no Google.

Neste relatório:

  • Cada item é apresentado com seu nome, código de barra e outros atributos;
  • Uma barra colorida, abaixo do item, mostra a quantidade em estoque através do seu tamanho e de um número;
  • A cor da barra, e o fundo da coluna On Hand, indicam por cores se a quantidade em estoque é adequada (verde ou amarelo), ou se é preciso reabastecer com um novo pedido para o fornecedor (vermelho;)
  • As colunas SKU e Name são URLs. Clicar em um deles leva a um outro relatório ou a algo mais. Clicando no item na coluna Name, por exemplo, dispara uma consulta por imagens no Google, abrindo o navegador web padrão para mostrar imagens do produto;
  • A imagem não mostra, mas o relatório possui um filtro por linha de produtos. Veja no canto superior esquerdo o filtro ativo: Line: Classic Cars.

Figuras, fontes, funções, fórmulas, prompts, saída em HTML, Excel, CSV ou PDF…. o PRD tem tudo, incluindo a pia da cozinha e mais um pouco. E como ele é parte da Suite Pentaho, podemos publicar os relatórios no Pentaho BA Server, onde os usuários conseguem acessá-los, agendá-los ou executá-los em background.

E ainda tem o lado das fontes de dados: o PRD consegue ler desde bancos de dados relacionais a Hadoop, de uma tabela hardcoded no relatório a resultados de scripts em Groovy ou JavaScript, de MDX (consultas OLAP) a SQLs gerados em tempo real com scripts, sem contar transformações, que por si só também permitem ler de qualquer coisa.

Uma destas fontes de dados é o metamodelo, um padrão definido por um consórcio de empresas de BI. A ferramenta da Suite Pentaho que gera esse arquivo é Metadata Editor (PME.)

Pentaho Metadata Editor.
Pentaho Metadata Editor.

Relatórios são construídos, em sua maioria, com SQL, que até que é uma linguagem bem prática. O que quase sempre complica as consultas é o modelo de dados. Raramente podemos deixar nosso cliente construir seus próprios relatórios por dois motivos:

  1. Falta de conhecimento em SQL;
  2. Desconhecimento do modelo de dados.

Se o primeiro item dificulta a construção da consulta em si, o segundo compromete o resultado. Pois mesmo que o cliente consiga montar o SQL que traga a listagem desejada, apenas um conhecimento íntimo dos dados, das tabelas e dos relacionamentos é que pode garantir que a consulta trará o resultado correto. E mesmo conhecendo bem os dados, o risco de uma consulta trazer dados inconsistentes ou incorretos nunca é zero.

Tanto é assim que a principal justificativa para construção de um [Data Mart][datamart_bitly] em formato dimensional (ou [esquema estrela][modim_bitly]) é justamente reduzir a complexidade do modelo on-line a ponto de permitir a exploração dos dados por um profissional não-técnico, que nem domina SQL nem conhece em profundidade o modelo de dados transacional.


Na minha opinião, essa é a única justificativa para construirmos um modelo dimensional.


Outro caminho para superar essas dificuldades é deixar que o computador resolva as consultas para você, algo muito em moda hoje em dia com a onda das ferramentas de Data Discovery.

E esse é justamente o propósito do metamodelo: esconder a complexidade da base de dados e permitir a construção de consultas por usuários de negócio, que sabem pouco ou nada de SQL, e menos ainda de modelos de dados, relacionamentos, chaves estrangeiras etc. etc. etc.

Meta… Meta… Meta…

Criado em 2003, o Commom Warehouse Metamodel é uma proposta para eliminar a complexidade de consultas a bancos de dados por meio de uma camada de relacionamentos (camada de negócio) que senta entre a camada física (bancos de dados) e a camada de apresentação (interface de usuário.)

As camadas de um metamodelo CWM.
As camadas de um metamodelo CWM.

A forma mais comum de consumir esses dados é usando um aplicativo que até pouco tempo atrás vinha embutido no Pentaho BA Server, o Web Ad Hoc Query and Reporting, ou WAQR:

Usando o WAQR para construir um relatório a partir de um metamodelo.
Usando o WAQR para construir um relatório a partir de um metamodelo.

O WAQR ainda está disponível, mas como um plugin sem suporte. A falta de manutenção, aliás, está começando a mostrar seus efeitos – já não é mais possível editar relatórios salvos, por exemplo.


Entre vários recursos incorporados por um CWM, ou um metamodelo, estão o controle de acesso aos dados. Um CWM pode, por exemplo, bloquear o acesso de um determinado usário a um conjunto de tabelas, ou que um grupo de usuários (um papel) veja essas tabelas, mas apenas parte do conteúdo (controle de acesso no nível de linha.) Veja essa página para saber um pouco mais sobre segurança em metamodelos do Pentaho Infocenter.

PRD com Metamodelos

Lembra-se dos motivos para um usuário de negócio não construir seus próprios relatórios? Bom, ao usar um metamodelo como fonte de dados para um relatório, ambas somem!

  1. Falta de conhecimento em SQL: ao contrário de um modelo de dados em banco relacional, que usa SQL, a construção de uma consulta com metamodelo é feita por uma interface gráfica amigável, sem comandos técnicos – escolha os campos, as agregações, ordenações e filtros e pronto! O engine do PRD vai usar o metamodelo para construir a consulta SQL sozinho;
  2. Desconhecimento do modelo de dados: como o metamodelo embute as regras de negócio, uma consulta construída sobre o metamodelo elimina a necessidade de o autor do relatório conhecer e entender bem o modelo e os relacionamentos entre as tabelas. O risco de consultas erradas ou mal-feitas vai virtualmente a zero.

Mas não pára por aí! Ainda teremos:

  • Controle de acesso: todas as regras de acesso implementadas no metamodelo são aplicadas automaticamente nos relatórios do PRD;
  • Padrão de formatação: um metamodelo impõe, e o PRD respeita, um padrão de formatação para a camada de apresentação. Ou seja, se um campo monetário for definido como “Arial-12, Itálico, Verde-Água”, então todos as vezes que esse campo for usado em um relatório ele vai aparecer em Arial itálico, tamanho 12, verde-água, mesmo que o autor do relatório altere o elemento! (Dá para contornar, e não é acidentalmente – é preciso ter a intenção de sair do padrão.)

E você não perde (quase) nenhuma vantagem do PRD: continua podendo usar parâmetros (prompts), gráficos, sub-relatórios, fontes, funções, scripts etc. etc. etc.


Aparentemente, existem duas limitações em consultas MQL (Metadata Query Language) parametrizadas: o controle de calendário não funciona 100% e não é possível filtrar consultas com parâmetros que retornam listas. Eu li en passant sobre isso em uma thread do fórum internacional, mas não achei evidência. Vou testar e voltarei ao assunto quanto tiver informação concreta.


Como Fazer

É simples, muito simples: registre seu metamodelo como uma fonte de dados no PRD, e use-a para construir as consultas. Pré-requisitos:

  • O PRD instalado e funcionando e, é claro, saber usar o básico para construir um relatório;
  • Uma base de dados, com o respectivo servidor de banco de dados no ar, e todas as informações para conexão (string de conexão, IP, usuário e senha;)
  • Um metamodelo sobre a base acima, construído com o Metadata Editor (PME), exportado para um arquivo XMI.

Instalar PRD e PME

Para instalar o PRD e o PME clique aqui, baixe e leia o capítulo de degustação do Pentaho na Prática. Ele foi feito para a baseline 4.8 do Pentaho, mas ainda serve para a série 5 ou 6: troque o Java de 1.6 para 1.7 (baseline 5.x) ou 1.8 (série 6) e fique atento para as diferenças entre as telas.

Base de Dados: Beltrano S/A

Se você não tiver uma base contra a qual construir o seu metamodelo, consulte este post para baixar e instalar a Beltrano S/A. Artigo completo, incluindo instruções para instalar o Postgres no Windows (livro gratuito!) e Linux.

Diagrama de tabelas do sistema transacional (OLTP) da Beltrano S/A.
Diagrama de tabelas do sistema transacional (OLTP) da Beltrano S/A.

Metamodelo Beltrano OLTP

Com um pouco de trabalho construímos um metamodelo a partir do diagrama anterior. A figura abaixo mostra a cara do metamodelo que eu vou usar no exemplo:

Metamodelo sobre banco de dados transacional (OLTP) da Beltrano S/A.
Metamodelo sobre banco de dados transacional (OLTP) da Beltrano S/A.

Daí, usando o comando File -> Export to XMI File no menu do PME, eu gerei o arquivo XMI necessário para o PRD.

Não veremos como montar o metamodelo inteiro, pois é muita coisa. Você pode usar algum que já possua, ou clicar aqui e baixar o metamodelo do Beltrano S/A.


Deixe um comentário se não conseguir ou se tiver alguma dúvida. Faz tempo que eu montei esses arquivos e algo pode estar desregulado.


Registrar Metamodelo como Fonte de Dados

Abra o PRD e crie um relatório vazio. No lado direito da interface há duas abas: Structure e Data. Selecione a aba Data e clique com o botão da direita sobre o cilindro amarelo. Escolha Metadata no menu que vai aparecer.

Criando uma fonte de dados para metamodelo.
Criando uma fonte de dados para metamodelo.

Vai aparecer a janela abaixo. Use o botão Browse ao lado do campo XMI File para localizar e selecionar o arquivo XMI do metamodelo. Informe um nome para domínio (campo Domain Id/BI-Server Solution Name.)

(A consulta que aparece na imagem é resultado do exercício. Já, já mostro como ela apareceu.)

Fonte de dados baseada em metamodelo registrada.
Fonte de dados baseada em metamodelo registrada.

Se você prentende publicar os relatórios em um BA Server, certifique-se de usar o mesmo nome de domínio no PRD e no BA Server (isso é feito no momento da publicação via PME ou na importação em Manage Data Sources no BA Server.) Caso sejam diferentes, executar o relatório no BA Server vai gerar uma mensagem de erro sobre “fonte de dados inexistente”.


Pronto! A fonte de dados está configurada e, a partir daí, vida normal: crie uma consulta e desenhe um relatório.

Criando uma Consulta MQL

A figura anterior mostra uma consulta já criada. Eis como chegaremos até ali:

  1. Clique no botão + (verde) que fica ao lado do texto “Avaliable Queries” na janela de conexão;
  2. Aparecerá uma Query 1 na lista de consultas. Clique nela para selecioná-la;
  3. Clique no ícone de lápis (destacado por uma seta vermelha) para abrir a janela de construção de consultas. Consulte esta página do Infocenter para mais informações sobre o “construtor de consultas de metadados”;
  4. Veja a figura a seguir: cada um dos campos desejados no relatório foi selecionado e transferido para a seção Selected Columns clicando-se na primeira seta verde, de cima para baixo;
  5. Um filtro foi definido transferindo-se para a segunda seção, Conditions, o campo que filtrará os dados. Usamos a Comparison (comparação) “contains” (contém) e Alexandre na coluna Value;
  6. Finalmente definimos a ordem de listagem desses dados: por Vendedor, por Curso, ambos em ordem alfabética crescente (ASC), na seção Order By.

Ao clicar no Ok volta-se para a janela anterior, e consulta aparece na seção Static Query. Neste ponto você pode testá-la, clicando em Preview, ou só clicar em Ok e voltar para o relatório.

Construir uma consulta em MQL é muito fácil e simples!
Construir uma consulta em MQL é muito fácil e simples!

Note que acabamos de cumprir as duas promessas: criamos uma consulta sem saber nada de SQL ou do modelo de dados.

Montando um Relatório

O relatório é desenhado da mesma forma que se usássemos uma consulta SQL: inclua os elementos que deseja (como títulos e gráficos), arraste os campos da consulta para a lona, posicione-os, configure os detalhe e salve.

Um relatório baseado em metamodelo pode ter qualquer recurso.
Um relatório baseado em metamodelo pode ter qualquer recurso.

Pressione o ícone de olho ou o botão de play para renderizar seu relatório. O meu ficou assim:

Vendas do Alexandre Costa, Beltrano S/A.
Vendas do Alexandre Costa, Beltrano S/A.

Uma última dica! O PRD vai aplicar, aos campos trazidos da consulta, as regras de formatação definidas no metamodelo e você não vai conseguir alterá-las na mão, no PRD. Se você quiser forçar a formatação de um campo, use um elemento do tipo Message ao invés do tipo padrão que o PRD escolher para o campo. A forma mais fácil de entender como funciona esse tipo de campo é arrastar da consulta um campo qualquer para a lona, selecioná-lo e, no menu Format do PRD, acionar a opção Morph -> message-field. A partir daí o campo vai aceitar qualquer formatação que você aplicar.

Conclusão

Sentiu a facilidade da coisa? Uma vez que um metamodelo seja criado, usá-lo para construir um relatório é muito fácil e, muito importante, tem altíssima produtividade, já que todo trabalho de escrever e testar a consulta SQL foi passado para o motor de metadados.

Indo um pouco além, suponha que seu banco de dados, que serve de fonte para o metamodelo, sofreu alguma alteração. O usuário não precisa saber de nada: apenas atualize o metamodelo e distribua a nova versão. Se não houver acontecido nenhuma mudança drástica, tudo que existia continuará funcionando e ainda terá consistência com as alterações da base!

Até a próxima! :-)

Novo Plugin Pentaho BA Server: Self Service BI

Semana passada, precisamente dia 21 de janeiro de 2016, meu grande amigo Gerson Tessler me ligou. “Cara”, ele veio falando, “você viu o plugin de self-service BI da SPEC INDIA?”

Eu tinha visto os dois até, para ser sincero, mas ainda não havia testado nenhum:

Os dois plugins da SPEC INDIA no Marketplace.
Os dois plugins da SPEC INDIA no Marketplace.

“Instala e me liga!” Ok, Gerson, fica frio, eu vou instalar. Que agitação, só um plugin…

Uau.

A primeira coisa que nós pensamos foi “deve ter uma licença limitada, que expira e depois precisa pagar para continuar usando”, ou então que tinha alguma pegadinha. Não era razoável supor que fosse gratuito, na boa, sem “letras miúdas” na licença.

O Self Service BI Plugin, da SPEC INDIA, é um editor de dashboards para o BA Server que imita o Dashboard Designer da versão enterprise do Pentaho. Sua qualidade mais notável é dispensar (quase) completamente qualquer tipo de conhecimento baixo nível para começar a usá-lo. Por exemplo, eu levei menos de 20 minutos entre instalar o plugin, fuçar um pouco e criar esse painel:

Meu primeiro painel com o plugin: facilidade análoga à versão enterprise.
Meu primeiro painel com o plugin: facilidade análoga à versão enterprise.

Em resumo:

  • Crie consultas OLAP com o Saiku, e salve-as;
  • Crie um novo pinboard acessando o novo menu Self Service BI. Pinboard é a gíria da SPEC INDIA para dashboards;
  • Usando a engrenagem no canto esquerdo superior do novo pinboard, defina o layout dos quadros do painel;
  • Em cada painel clique no ícone de lápis e selecione as consultas Saiku. Escolha o tipo de gráfico e salve;
  • Depois… mais nada, era só isso mesmo.

O resultado é um painel estático, mas mesmo assim, para quem, como eu, ainda não é fera em CSS e HTML, é um feito e tanto! E o plugin oferece muito mais recursos que só isso: prompts, gráficos independentes, parâmetros, consultas SQL etc. etc. Você também pode criar um pin individual e salvá-lo, para reaproveitar em outros pinboards. Na boa, é um avanço e tanto para a comunidade de usuários do Pentaho! É injusto comparar o trabalho deles com outros da comunidade, até porque o deles só foi possível graças aos esforços de muitos outros grandes personagens da comunidade, mas com certeza a SPEC INDIA estabeleceu um novo marco na história do Pentaho. É uma boa notícia saber que eles são parceiros da Pentaho!

Mas nem tudo são rosas – ou eram. O Gerson me procurara não só para mostrar como esse plugin era legal, mas também porque estava dando pau: os pinboards salvos não estavam abrindo. Conseguíamos criar um novo painel, configurá-lo bonitinho, mas ao gravá-lo algo acontecia e não dava mais para abrir o painel nem para editar, nem para rodar. Bug chaaato…

Bom, eu fiz o que qualquer cara sem noção faria: acessei o site deles, achei o botão “contact us” e mandei um e-mail, perguntando educadamente como eu poderia conseguir suporte. A resposta foi tri-bacana:

Ketul Sheth é um cara de ação.
Ketul Sheth é um cara de ação.

Sendo um sujeito dolorosamente franco, eu expliquei à ele que não daria para fazermos negócio:

A voz da verdade nunca fez caridade. Grande Barão Vermelho!
A voz da verdade nunca fez caridade. Grande Barão Vermelho!

E não é que o Ketul é mesmo um homem de ação?

Ele sugeriu um WebEx dia 25, que eu recusei porque era feriado em São Paulo, e sugeri o dia seguinte, 26/jan. Não deu: era feriado na Índia (Dia da República Indiana!) Acabou ficando para quarta-feira, 28 de janeiro, 8H30min em São Paulo, 16H30min na Índia.

Montamos o WebEx e a primeira pergunta que eu fiz, depois de agradecer profusamente, foi: porquê? Por quê criaram esse plugin? Uso interno? Vão vender?


“Nós vimos que, das opções livres atualmente à disposição, nenhuma era tão fácil de usar quanto o Dashboard Designer (enterprise), e resolvemos contribuir com a comunidade oferecendo esse plugin.”


:-O

Eles vão usar o plugin para entregar os próprios projetos e tal, o Ketul falou, mas a meta é mesmo entregar um novo plugin para a comunidade Pentaho.

Passado o choque, caímos no trabalho. Compartilhei minha tela com eles que – A MEIO MUNDO DE DISTÂNCIA, DA ÍNDIA – assumiram o controle e fizeram alguns testes. Ao final, salvaram um pinboard, que eu exportei do BA Server e mandei por e-mail para eles. Isso foi quarta-feira de manhã. Ontem, quinta-feira dia 28/01/2015, antes do meio-dia aqui no Brasil (quase 20H00min na Índia), veio este e-mail:

Hey, man! All done, man! Try it again!
Hey, man! All done, man! Try it again!

Arre égua! Duplo arre égua! Subimos o servidor novamente, atualizamos o plugin diretamente no Marketplace, rebootamos o BA Server e voi-là! Funcionou!

3.1 E Agora?

Eu sugeriria, a vocês que apreciaram o esforço deles, que instalem e testem esse plugin no seu BA Server. Se não pela curiosidade, então para não deixar de conhecer um excelente produto. Lembrem-se apenas que é uma das primeiras versões, e novos bugs ou problemas podem aparecer.

Se tudo der certo, por favor, visitem a página da SPEC INDIA e deixem-lhes uma notinha de incentivo, ou comentário de agradecimento ou pura e simplesmente um breve reconhecimento do trabalho deles. Se você não sabe inglês, não se grile: escreva em português mesmo e cole este link no começo da sua resposta https://bit.ly/1Trd9hM. É um post em inglês, aqui no blog, explicando que eles receberam uma nota de gratidão de alguém da comunidade brasileira de Pentaho.

Aqui tem dois vídeos para ajudá-los a testar o plugin:

Guys, keep the excelente job! We own you one! :-D

Pentaho Seis Saiu!

Acabei de verificar no SourceForge e está lá:

151014_PentahoSeis_01

Você pode conferir pessoalmente, clicando aqui, mas eu entrei em todos os diretórios e confirmei: a versão seis está disponível para download:

Lista de pastas: Pentaho BA Server 6 ainda com poucos downloads.
Lista de pastas: Pentaho BA Server 6 ainda com poucos downloads.

Ladies and gentlemen, start your download engines! :-)

De Agilidade e BI

Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?

Ágil, Não Rápido

Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.

É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.

Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.

É ruim, hein! :-P


O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.


Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.

Inteligência de Negócios Ágil?

E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?

Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.

Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.

Quer dizer, praticamente. Algums detalhes não deram muito certo:

  1. Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
  2. Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
  3. Refactoring: sério, refatorar um banco de dados?? Freaking how??

Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!

Senta que Lá Vem História…

O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.

Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.

Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!

Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?

Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)

Requisitos Para Gestão Ágil

Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.

De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.

E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.

Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.

150827_DAEBI_004

4Shot Agile BI com Pentaho

Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.

150827_DAEBI_001Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)

Eu produzi um vídeo explicando melhor a idéia.

150827_DAEBI_002

Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)

Máquina virtual pré-fabricada, pronta para os exercícios.
Máquina virtual pré-fabricada, pronta para os exercícios.

O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)


Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.


Compre! :-D

Excel vs. MDX

Não me entenda mal: não quero começar uma guerra santa entre usuários de Excel e de MDX, até porque eu provavelmente pertenceria ao exército santo do Excel.

Mas a verdade é que, quando alguém precisa tabular dados, a primeira escolha é sempre o Excel. Ele é simples e fácil de usar, e dá resultados mais ou menos intuitivos.

Neste post eu vou mostrar um caso típico de uso do Excel – comparar valores de dois períodos – e como fazer o mesmo usando MDX. Daí eu vou tirar algumas conclusões e, espero, te convencer da importância de investir no estudo de MDX.

Vamos lá.

O Problema

Eu recebi um e-mail de um ex-aluno com o seguinte problema:


(No meu cubo) tenho uma coluna de valor faturado e, estou fazendo um comparativo entre os anos de 2014 e 2015, por empresa, pois somos um grupo de empresas. A minha métrica é o valor faturado. Então, como proceder se eu tiver que dividir um valor pelo o outro?


Quantas vezes não precisamos fazer isso? Comparar um ano com outro, uma linha de produtos com outra, faturamento em estado com outro… Qual é a primeira idéia que nos ocorre para tratar esse problema?

Montar uma planilha eletrônica – um Excel. É ou não é?

Vamos fazer isso aqui: vamos pegar o problema que meu ex-aluno trouxe e resolvê-lo, primeiro no Excel e depois como uma consulta MDX.

Para facilitar a compreensão do raciocínio, eu vou alterar ligeiramente o problema trazido pelo aluno. Ao invés de considerarmos os dados da empresa dele, que são sigilosos e relativamente complexos, vamos usar o cubo de vendas da SteelWheels, que é a empresa usada na demonstração do Pentaho BA Server.

Reformulando o problema com a SteelWheels, fica:


Estou fazendo um comparativo entre os anos de 2004 e 2005, por linha de produto. A minha métrica é o valor vendido (Sales). Como proceder se eu tiver que dividir um valor (Sales em 2005) pelo o outro (Sales em 2004) para cada linha de produto?


Resolvendo com Excel

Para resolver esse problema usando uma planilha eletrônica (nome genérico do Excel, que serve para designar não apenas o Excel, mas o Calc, do LibreOffice, o Lotus 1-2-3 etc.), precisamos primeiro extrair os dados para um arquivo, que vai ser importado pelo Excel e só então aparecer como uma planilha. Normalmente, para bancos de dados relacionais, fazemos isso exportando para CSV o resultado de uma consulta SQL, e depois importando esse CSV para dentro da planilha eletrônica.

E para fazer isso nós precisamos:

  1. De uma ferramenta que permita rodar SQL contra a base e exportar o resultado para arquivos CSV;
  2. Conhecer a base de dados, entendendo que tabelas possuem os dados que queremos, e como elas se relacionam entre si; e finalmente,
  3. Saber SQL o bastante para escrever uma consulta válida.

Vamos começar por entender os dados. Eis abaixo o esquema do banco, construído no Power*Architect:

Esquema que alimenta o cubo SteelWheels Sales.
Esquema que alimenta o cubo SteelWheels Sales.

Montei esse diagrama fazendo engenharia reversa no esquema Mondrian (que por sua vez foi retirado do servidor Pentaho) e na base de dados.

Como queremos os dados das vendas feitas por ano, por linha de produto nos interessam as tabelas PRODUCTS, ORDERFACT e DIM_TIME. O SQL que retorna a lista de valores vendidos por linha de produto, por ano é:

SELECT
  PRODUCTS.PRODUCTLINE AS PRODUCTS_PRODUCTLINE,
  DIM_TIME.YEAR_ID AS DIM_TIME_YEAR_ID,
  SUM(ORDERFACT.TOTALPRICE) AS SALES
FROM PUBLIC.PRODUCTS PRODUCTS
INNER JOIN PUBLIC.ORDERFACT ORDERFACT
  ON PRODUCTS.PRODUCTCODE = ORDERFACT.PRODUCTCODE
INNER JOIN PUBLIC.DIM_TIME DIM_TIME
  ON ORDERFACT.TIME_ID = DIM_TIME.TIME_ID
GROUP BY PRODUCTS_PRODUCTLINE,
         DIM_TIME_YEAR_ID
ORDER BY DIM_TIME.YEAR_ID ASC,
PRODUCTS.PRODUCTLINE ASC`

(Eu não sou esse mago do SQL. Eu consegui essa expressão usando o SQLeonardo. E não, não existe o SheldonQL.)

O SQLeonardo já seria o bastante para exportar os dados, mas eu resolvi usar a grande dica do Rômulo, e montei uma conexão com o banco usando uma interface gráfica padrão do HSQLDB:

Conexão do cliente HSQLDB com o SampleData.
Conexão do cliente HSQLDB com o SampleData.

O HSQLDB é o banco de dados portátil, usado pelo Pentaho BA Server.


Depois da conexão feita, rodamos a consulta acima:

Resultado da consulta que traz o dados que desejamos.
Resultado da consulta que traz o dados que desejamos.

E salvamos esse resultado em formato texto:

Arquivo texto resultado do comando 'File -> Save Result'.
Arquivo texto resultado do comando ‘File -> Save Result’.

Depois de um pouco de escovação, finalmente aparece como uma planilha eletrônica:

Colocando os anos lado-a-lado na planilha.
Colocando os anos lado-a-lado na planilha.

Pronto, podemos nos dedicar a montar a resposta ao problema. Primeiro, rearranjamos a planilha para colocar os anos lado-a-lado:

Colocando os anos lado-a-lado na planilha.
Colocando os anos lado-a-lado na planilha.

Agora ficou fácil: basta calcular a razão (=divisão) entre quaisquer colunas e inserir o resultado em uma nova coluna. Do enunciado do problema sabemos que queremos a divisão de 2005 por 2004. Assim, apaguei a coluna de 2003 e coloquei uma nova coluna, 2005/2004, contendo a fórmula que divide uma pela outra. Formatei como porcentagem e finalmente temos (com destaque para a fórmula):

Calculando 2005 dividido por 2004, como uma porcentagem.
Calculando 2005 dividido por 2004, como uma porcentagem.

Voilá! Problema resolvido!

MultiDimensional eXpressions

MDX é a linguagem que a Microsoft criou para seu produto OLAP, o MS SQL Server Analysis Services, ou SSAS, como é conhecido. O SSAS é uma base multidimensional real, o que significa que ele guarda cada célula de um cubo OLAP como um registro físico, assim como um banco relacional guarda registros em disco. Em comparação, o Mondrian é um servidor OLAP, que monta o cubo em memória a partir de um banco de dados relacional tradicional, conforme processa comandos MDX. Em comum, SSAS e Mondrian têm exatamente isso: a linguagem MDX.

A meta da Microsoft com o SSAS era popularizar BI, e nisso o MDX era instrumental. A idéia por trás do MDX era viabilizar justamente o tipo de manipulação que fazemos com o outro produto da MS – o Excel – mas para grandes e complexas massas de dados. O livro Fast Track to MDX traz um histórico, simples mas muito valioso, de como o SSAS (e o MDX) nasceu e cresceu.

Resolvendo com MDX

Para resolver esse mesmo problema com MDX usamos um Pentaho BA Server (eu usei a versão 5.4, mas funciona com qualquer uma – mesmo!) Depois de subir o servidor, acessamos o endereço http://localhost:8080, fazemos login com usuário admin e senha password e criamos uma nova visão OLAP:

Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.
Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.

Assim que você seleciona o esquema SteelWheels e o cubo SteelWheelsSales e clica em Ok, a visão inicial do cubo se abre:

Visão inicial do cubo de vendas da SteelWheels.
Visão inicial do cubo de vendas da SteelWheels.

Usando o primeiro ícone do jPivot, Cube Navigator, e mudando o tipo de drill para Drill Replace (ícone de setas vermelhas), chegamos a uma visão análoga à da planilha:

Cubo rearranjado para mostrar a mesma visão de planilha.
Cubo rearranjado para mostrar a mesma visão de planilha.

Neste ponto, quando usamos o Excel, criamos uma nova coluna e colocamos a fórmula nela. Vamos fazer exatamente a mesma coisa aqui, mas com MDX.

Até agora manuseamos os dados em uma interface gráfica. Vamos ver o que existe de MDX por trás disso. Clicando-se no botão MDX do jPivot, vemos a consulta que construímos enquanto lapidávamos o cubo:

SELECT NON EMPTY Crossjoin( {[Measures].[Sales]},
              [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Em MDX-zês, uma “nova coluna” equivale a uma métrica calculada (bom, tecnicamente falando, é um membro calculado, mas como é um membro do conjunto de métricas, fica sendo uma métrica calculada mesmo.) Essa métrica calculada pode ser definida, em português, assim:

    COM O NOME "Razao_2005_2004" USE A FORMULA ([2005,Categoria]/[2004,Categoria]), <OPÇÕES>

O truque todo está na fórmula: pense no cubo OLAP como uma mega-planilha, na qual toda métrica pode ser referenciada com um conjunto de coordenadas, exatamente como em uma planilha Excel. A diferença é que as coordenadas não são colunas e linhas, como na fórmula da figura anterior, mas sim membros dos conjuntos das dimensões!


Outro detalhe importante: se você não explicitar uma dimensão, assume-se que a fórmula vale em todas as “coordenadas” daquela dimensão. Ainda apelando para a analogia do Excel, é como fazer referência à planilha: a menos que você indique uma célula em outra planilha, a fórmula Excel vai assumir que a coluna/linha indicada é na mesma planilha (o “membro atual”, do inglês current member – essa noção é importantíssima!!), e se você copiar essa fórmula para outra planilha, o mesmo vai continuar valendo.

Trocando o Português por MDX castiço, a fórmula fica:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"

O format_string serve para que os valores calculados apareçam como porcentagens. Sem ele ali, os valores seguiriam a formatação da métrica original.

Agora vamos colocar essa fórmula no nosso MDX anterior:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin({[Measures].[Sales]},
               [Time].[All Years].Children) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Se você testar essa consulta no jPivot, copiando-a e colando-a, vai ver que nada de novo aparece, mas também não dá erro. Isso acontece porque, apesar de termos definido a nova métrica, ela não está sendo usada na consulta. É preciso incluir a nova métrica na consulta para que ela apareça no cubo. Fazemos isso alterando o termo logo depois de SELECT NON EMPTY Crossjoin:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin(
          {[Measures].[Sales],[Measures].[Razao_2005_2004]},
           [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Notou que o nome da nova métrica, definida no WITH MEMBER, agora aparece na consulta? Se tudo deu certo para você, seu cubo agora deve se parecer com este aqui:

Cubo com a nova métrica calculada.
Cubo com a nova métrica calculada.

Algumas coisas ficaram esquisitas: a coluna se repetiu, com o mesmo valor, para os três anos. Essa visualização é estranha, e não ajuda muito. Se você pensar um pouco, verá que a fórmula que calculamos opera sempre apenas sobre 2005 e 2004. Logo, não há sentido em mostrar o ano


Ao remover a dimensão Ano da grade OLAP, a métrica Sales passará a ser agregada para todos os anos, e não veremos mais as duas colunas para 2004 e 2005. Precisamos aprender um pouco mais de MDX para saber como mostrar a métrica Sales em 2004, em 2005 e, em uma terceira coluna, a métrica calculada – mas aí já é outra história. Entretanto, se você quiser procurar, a solução para este caso passa por NAMED SETS (NS).


Grade agora mostra só a métrica calculada.
Grade agora mostra só a métrica calculada.

Tudo isso parece um pouco confuso no início, mas eu posso dizer algumas coisas para ajudar:

  • É uma fórmula que resolve esse o problema atual, e nenhum outro. Em outras palavras, não é uma solução genérica e geral, mas sim uma bem específica;
  • Pense sempre como uma planilha Excel: para calcular a metade do valor da célula F4, você coloca “=F4/2” na célula G4. Certo? Em MDX é a mesma coisa, mas uma “célula” é o cruzamento das dimensões e uma ou mais métricas. Para calcular uma nova relação, construímos uma nova coluna, e assim por diante;
  • Logo, a solução de outros problemas demandam outras consultas MDX. Preparamos uma nova solução sempre que tivermos uma nova necessidade.

Conclusão

Meu modesto objetivo era mostrar como uma conta feita em planilha pode ser replicada com MDX. Ou seja, eu queria mostrar que MDX pode ser encarado como uma outra forma de se manusear planilhas de dados. Por favor deixe sua opinião nos comentários: eu consegui?

Se você pensar um pouco, vai ver a mesma situação acontece com bancos relacionais e SQL: em busca de uma resposta específica, podemos escrever um programa (Java, Kettle, PHP etc.) que itera sobre as linhas de uma tabela – para calcular uma média por exemplo, ou podemos tentar escrever uma consulta SQL. Em geral, a consulta SQL vai ser mais enxuta, poderosa, rápida e flexível, porque ela foi pensada para fazer bem certos tipos de trabalho.

Com MDX temos a mesma situação: podemos montar uma planilha, ou podemos escrever uma consulta MDX sobre um cubo OLAP. Em geral, MDX vai ser mais enxuto, poderoso, rápido e flexível, porque ele foi pensado para resolver problemas analíticos.

Há algumas outras coisas dignas de nota em nossa breve aventura com planilhas e OLAP:

  • Ambos os métodos partem da existência de um banco de dados pronto para consulta. Criar esse banco já é um trabalho considerável, dependendo da empresa e das complexidades (negócios, dados etc.) envolvidas;
  • Uma vez que você consiga montar esse banco, ainda precisa escrever o SQL para poder chegar à planilha;
  • Se você optar por montar um cubo OLAP, precisa mapear o banco com um esquema Mondrian, e depois construir o MDX que resolve seu problema.

Ou seja, por qualquer caminho que peguemos (MDX ou Excel), sempre vamos precisar “escrever” algo (um SQL ou um MDX), mesmo que para isso usemos uma ferramenta visual.

Bom, se pelos dois caminhos temos o mesmo trabalho, se não maior no caminho MDX, porque então vale a pena usar MDX? Porque não ficamos só com Excel?

Resposta: volume de dados e complexidade.

Veja como tínhamos poucas linhas e poucas colunas para manusear em uma planilha eletrônica. Conforme o volume de dados e a complexidade desse volume aumenta, cresce a complexidade das operações necessárias para montar a planilha. Nosso exemplo usa apenas anos e linha de produto. Como ficaria para Mês/Ano e Produto com Cliente? Com duas dimensões conseguimos “ver” a planilha numa boa, mas e com três, quatro, cinco?…

Mais ainda: para cada visão em planilha, o comando SQL precisa mudar para tratar das agregações nos níveis corretos!

O livro OLAP Solutions desenvolve esse argumento melhor, mas o ponto que eu quero destacar é que planilhas podem ser práticas e muito úteis apenas até certo ponto! A partir daí, as operações para montar e explorar as planilhas ficam sobejamente complexas.

É quando MDX passa a ser mais interessante que Excel.

Até a próxima!

Testando o Vertica

Já há alguns anos eu quero testar um banco de dados colunar. Desde o Pentaho Day 2014 eu fiquei muito curioso para brincar com o HP Vertica, mas não tinha tido o tempo (nem um banco com volume) suficiente para todo o trabalho que isso implica.

No final de 2014 eu consegui instalar uma máquina virtual com o Vertica 7.1.1 (em um Ubuntu Server 14.04.1.) Construí uma dúzia de transformações que copiaram todos os cubos de um DW em Postgres para esse Vertica. Configurei um BI Server 5.1 com as duas fontes de dados, e um esquema Mondrian para cada uma dessas fontes. Ontem em consegui fazer e tabular um experimento simples: usando o jPivot, abri o maior dos cubos (14.095.514 de linhas) e fiz uma exploração simples: abri e fechei cada uma das seis dimensões principais. Todas elas tinham entre um e três membros no nível hierárquico superior, exceto por uma dimensão data, que tinha 11 membros no nível do ano.

O Experimento

Fiz essas navegações logo após o boot do servidor, com cache vazio, e com um esquema (=banco) de cada vez. Capturei o log MDX e SQL do Mondrian para cada caso. Elas foram tão idênticas que foi possível comparar até mesmo o SQL gerado entre os dois experimentos. Como o Vertica é um Postgres colunar, o SQL era idêntico até a última vírgula, e isso facilitou a comparação.

Veja, eu não estava fazendo um estudo milimetricamente planejado. Eu só queria obter um sentimento da relação de performance entre as duas tecnologias. Logo, o resultado vai refletir o preparo do experimento. A informação será mínima, binária: em plataformas de hardware parecidas, qual base é mais rápida?

Tempo total para fazer a mesma coisa.
Tempo total para fazer a mesma coisa.

É o Vertica, sem sombra de dúvida. A máquina virtual do Vertica tinha 2GB de RAM e uma CPU – um quarto do meu i7 2.4GHz. A máquina do Postgres é a minha máquina real, com 16GB de RAM além de toda a CPU disponível. A máquina virtual estava desligada, de modo que minha CPU não estava particionada no momento do teste do Postgres.

O gráfico anterior mostra o tempo total para repetir a mesma operação com o mesmo cubo, usando bases diferentes. Já o gráfico abaixo compara cada uma das operações – que por acaso são 15 – usando uma escala logarítmica no eixo Y.

Tempo por operação nas duas tecnologias.
Tempo por operação nas duas tecnologias.

Curiosamente, e talvez até previsivelmente, o Vertica teve um desempenho uniformemente melhor que o Postgres em todas as operações que levavam mais tempo, mas perdeu feio nas operações M e N, que duraram menos de 50 ms. Destas operações, a M é o pior resultado do Vertica: 42 ms a 0 ms para o Postgres. Ou seja, uma operação que durou mais de 40 ms no Vertica foi tão rápida no Postgres que o log do Mondrian não conseguiu medir.

Lendo a documentação do Vertica eu vi um tópico que discute exatamente isso: consultas menores tendem a ter um overhead proporcionalmente maior que bancos relacionais.

Legal.

Em compensação, o Vertica foi mais rápido em tudo que levou mais de 50 ms. Em alguns casos, como o O, ele chega a ter mais de uma ordem de grandeza de vantagem – 22 vezes mais rápido no caso da operação O.

A Conclusão…

… é óbvia: o Vertica parece ser muito interessante para exploração OLAP de fatos com milhões de linhas. Sendo um cientista, eu estou perfeitamente ciente do risco que seria generalizar essa conclusão para um “logo ele será bom para tudo”. Existe um caso de uso no qual eu estou particularmente interessado, um relatório (PRD) tabular construído sobre esse mesmo cubo. Meus próximos testes vão tentar determinar se é uma vantagem usar Vertica ou não.

E eu aposto que é.

Feliz Ano Novo!!

ERP BI Solutions

E esse é o mundo de hoje: quando você pensa em fazer algo, alguém já fez. Conheçam ERP BI Solutions, primo do OpenBI Solutions:

ERP BI Solutions provides business intelligence solutions for popular open source ERP systems including PostBooks and XTuple ERP. Solutions are designed using data warehousing best practices and are built on best-of-breed open source BI technology giving you cost effective, innovative business intelligence.

Assim como o OpenBI Solutions oferece soluções de BI para softwares comuns (como o atual Apache) e de treinamento (Beltrano S/A), o ERP BI Solutions oferece soluções de BI com Pentaho para ERPs Open Source. A última publicação é de janeiro de 2014 e atende aos ERPs PostBooks e XTuple. Imagino que a coisa ande devagar, pois mais difícil que criar esses projetos é mantê-los em par com os respectivos ERPs.