Férias!

Ah, férias! Aquela época do ano em que, sem um chefe no seu cangote, você trabalha sem parar, até cair de sono na sua cama. É consertar isso, levar aquilo para lavar, cuidar dar crianças, passear com o cachorro…

Enfim, o blog está dando um tempo enquanto eu desfruto desses momentos de inenarrável deleite doméstico. O próximo post será dia 3 de agosto, daqui a duas semanas.

Até lá, para você não achar que perdeu a viagem, fica a dica: todos os livros da Packt estão por US$10,00 hoje – e somente hoje. Eis algumas sugestões:

É perturbador ver tanta coisa, tão barato…

Até a próxima! ;-)

Categorias:Generalidades Tags:,

Promoção de Lançamento do Pentaho na Prática, Segunda Edição

Quase três anos atrás, em 2 de agosto de 2013, o livro Pentaho na Prática apareceu para venda na Amazon.com. Com isso ele ganhou algumas marcas, como ser o primeiro livro sobre Pentaho em Português, e o primeiro livro sobre Pentaho no Brasil.

Essa era minha única meta. Queria que minha esposa tivesse orgulho de mim, e poder apontar aos meus filhos um livro empoeirado na (magra) estante em casa e dizer: “papai escreveu aquele livro”. Tudo que viesse na esteira disso seria um bônus. Algo como nascer, quando estamos pelados, carecas e sem dentes – dali em diante tudo é lucro! :-D

Quando o livro foi tirado do ar por problemas, eu achei que seria o fim da minha carreira literária (ai, que drama! kkk), pois eu tinha cumprido a minha meta. (Se bem que eu preciso pegar o Kindle da minha esposa para mostrar meu livro a eles, mas enfim.)

Graças a meus leitores, e a todo mundo que perguntou pelo livro nestes últimos anos, eu acabei me aplicando na auto-editoração, e agora tenho cinco livros publicados! E o primeiro virou sexto: chegou a segunda edição do PnP.

Sempre que lanço um novo livro ele sai em meio a uma promoção, que eu anuncio primeiro aqui para os leitores do blog, e depois para as listas das quais faço parte.

Antes, porém, uma pausa para um aviso importantíssimo:


O Pentaho na Prática, segunda edição, cobre a versão 4.8 da Suite Pentaho, sem CTools.


Sem maiores delongas, com vocês…

O Pentaho na Prática, segunda edição, está oficialmente lançado!Hoje, 13 de julho de 2016, ele está com 75% de desconto: de R$80,00 por R$20,00. Além disso, meus outros livros também estão com descontos significativos:

  • Autopublicação na Prática: de R$14,99 por R$5,99;
  • Geek BI 2012, 2013 e 2015: de R$5,99 por R$1,99 cada.

Quer ir direto para a Amazon? Eis os links para a loja brasileira:

E aqui para a loja dos Estados Unidos:

Você pode conhecer um pouco mais sobre cada livro seguindo os links no topo da página do blog, nos respectivos nomes.

É um prazer servi-los. ;-)

Categorias:Generalidades Tags:, , ,

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! ;-)

Lago ou Pântano?

Há duas regras que eu procuro respeitar nos meus posts: não publico nada que eu mesmo não gostaria de ler e nunca repito algo que já foi publicado por aí. Entretanto, em alguns casos o assunto que já foi publicado é tão relevante, e está tão bem escrito, que eu me sinto na obrigação de dividir meu achado, e este é o caso do post de hoje.

Eu havia planejado dois posts sobre o conceito de Data Lake, tal qual eu fiz com Data Discovery. Ao começar a pesquisa eu topei com um artigo do Gartner falando justamente sobre esse assunto: Gartner Says Beware of the Data Lake Fallacy. Eles colocaram o problema de uma forma tão simples, clara e lúcida que se meter a querer fazer algo melhor seria uma pretensão muito maior que o meu normal – e olhe que eu sou um cara pretensioso pra chuchu! Devo ser o cara mais pretensioso mundo, mas felizmente minha modéstia também é enorme, o que me salva.

:-DEntão, ao invés de refazer o trabalho eu vou apresentar o artigo do Gartner.

A Questão

Em 2010, James Dixon publicou um post num blog Pentaho apresentando a motivação e o conceito de um Data Lake:


Motivação

James Dixon conversou com várias empresas que usam Hadoop e descobriu que cerca de 80-90% deles usam dados estruturados ou semi-estruturados, mas não “desestruturados”, sendo que a fonte desses dados é quase sempre um só sistema transacional. Mesmo assim nem tudo é dado transacional, e apesar de várias perguntas sobre esses dados serem conhecidas, muitas mais – desconhecidas – podem vir a ser formuladas no futuro. Em geral existe mais que uma ou algumas comunidades de usuários interessados nestes dados, que são gerados ou processados em um passo muito superior ao que um SGBDR aguenta.

Definição

Se você pensar que um data mart como um armazém de água engarrafada, que foi limpa e empacotada para consumo, um Lago de Dados (aka Data Lake) é o corpo de água em um estado mais natural. O conteúdo dos sistemas de origem fluem para dentro do Data Lake, e vários usuários do lago podem vir examiná-lo, mergulhar nele ou levar amostras.


Francamente, para mim é o mesmo que dizer que você pode comprar farinha pronta no supermercado, mas ir até a fazenda comprar grãos direto do armazém. Enfim, adiante.

A partir daí o hype tomou conta do debate, e tudo passou pelo processo de “binguificação corporativa”, que é aquele mecanismo em que os chavões da hora vão parar em tudo que é reunião de estratégia, documento de intenções, briefings, pings para manter as coisas in the loop blá bláh blah yadda yadda yadda.

Resultado? Em 2016 não se acham Data Lakes “na natureza”, nos grandes espaços selvagens do mundo corporativo. Traduzindo: ninguém ainda veio a público dizer que implementou um e que resultados está tirando deles.


Mais ou menos a mesma coisa pela qual passou Mobile BI, Business Discoveryt/Data Discovery, e em boa parcela o mesmo pelo qual BigData ainda passa. Mas BigData é outro assunto, para outro dia, outro post.


Fiat Lux!

E aí vem o artigo do Gartner. Não quero repetir palavra por palavra, do contrário eu prestaria a vocês um serviço melhor só informando o link ao invés de escrever meu próprio post. Vou colocar as minhas críticas e depois o que o artigo do Gartner fala, e então bater os dois.

Seis por Cinco e Meio

Meu primeiro cisma com DL (Data Lake) é o fato de que ele não trazer algo de realmente novo: muitos outros projetos fazem cópias simples dos dados de um sistema para outro repositório. Na verdade, é a abordagem de praticamente todos que assumem um projeto de DW sem estudar o assunto antes. Como não sabem o que vão fazer, começam fazendo o óbvio: copiam tudo, e geram os produtos de dados a partir deste dump.

Vejam o que o Gartner coloca:


Nick Heudecker, research director at Gartner(…) “The idea is simple: instead of placing data in a purpose-built data store, you move it into a data lake in its original format. This eliminates the upfront costs of data ingestion, like transformation. Once data is placed into the lake, it’s available for analysis by everyone in the organization.”

However, while the marketing hype suggests audiences throughout an enterprise will leverage data lakes, this positioning assumes that all those audiences are highly skilled at data manipulation and analysis, as data lakes lack semantic consistency and governed metadata.


Em Português é mais ou menos isso:


Nick Heudecker, diretor de pesquisa no Gartner: “A idéia é simples: ao invés de colocar os dados em uma estrutura construída com especificamente para arquivar os dados, você move-os para dentro do Data Lake em seu formato original. Isso elimina os custos iniciais de ingestão e processamento dos dados de origem. Uma vez que esteja no lago, o dado fica disponível para todos na organização.”

Entretanto, se o hype dá a entender que as comunidades de usuários por toda empresa vão aproveitar um DL, então ele está sugerindo que todas essas comunidades são altamente habilidosas com manipulação de dados e análise, já que um DL não traz consistência, uniformidade e gestão dos metadados.


E nós sabemos que isso não é verdade. Eles vão adiante na questão e terminam (resumindo:)


Um DL tenta resolver dois problemas, um velho e outro novo. O velho é acabar com silos de dados: ao invés de ter várias fontes controladas de dados, jogamos tudo num só repositório, sem modificações. A consolidação, teoricamente, traria um maior uso dos dados enquanto reduz custos com licenças e servidores.

O novo tem mais a ver com BigData: pela própria disparidade das fontes, nem sempre dá para catalogar o dado na chegada e acomodá-lo em um SGBDR pode limitar futuras análises.

Atacar esses dois problemas com certeza beneficia a TI no curto prazo, no sentido de que reduz o trabalho para acomodar os dados, segundo o Sr. White. Porém, achar valor nestes dados permace tarefa do usuário final. Mas por mais que a aplicação de ferramentas ajude nisso, sem um mínimo de gestão tudo que conseguiremos é um monte de dados desconexos arquivados no mesmo lugar.


Bingo! E logo em seguida ele fala dos riscos de transforma um DL em um pântano se não houver um mínimo de gestão sobre ele. Ou seja, ao trocar um DW normal por um Data Lake arriscamos perder mais que ganhar. Arriscamos? Não, nós vamos perder, se não houver um mínimo de governança em cima desta infra-estrutura.

O Barato Sai Caro

Qualquer um que já passou pela frustrante experiência de manter um projeto de DW baseado em dumps sabe que a promessa de economia de tempo e recursos desse formato nunca se realiza. Fazer um dump pode até ser mais rápido que, por exemplo, desenhar um Data Mart e seu ETL. Porém, mais tarde, esses projetos batem com problemas que desperdiçam muito mais tempo que o rápido início economizou.

Um destes problemas é justamente racionalizar o uso dos recursos para poupar carregar o banco inteiro a cada atualização. A solução que sempre encontram é capturar um “delta”: comparar o sistema de origem com o dump no “DW” e trazer apenas as diferenças.

Mesmo assim há um custo em hardware e tempo inevitável. À esse custo os adeptos do DL respondem com a velocidade de carga do Hadoop, invariavelmente o miolo de DLs.

Outro problema é que a cada demanda do usuário por uma análise ou relatório, um novo ETL pós-dump precisa ser produzido. Até aí tudo bem, porque qualquer projeto de DW enfrenta isso. O problema é que qualquer alteração na origem “quebra” tudo que depende do dump e do nada surge uma montanha de retrabalho.

Ao que os seguidores do DL contrapõe outro argumento: self-service! Só que explorar um Data Lake não é para qualquer por dois motivos:

  • A pilha (stack) de tecnologia necessário é imensa. Um profissional especializado teria dificuldades, imagine um cara do Marketing?!
  • É preciso entender os dados e como eles “funcionam” para poder extrair valor deles. Nem mesmo todos os DBAs de uma empresa costumam saber tudo sobre os dados, quanto mais um leigo… do departamento de Marketing!!!

Entender muito de uma coisa faz com que tendamos a entender menos de outras. Marketing é uma ciência que se aproxima da arte, assim como muitas outras funções em uma empresa, e o custo de saber tanto do negócio da empresa é a tendência a saber menos de coisas como TI e BI. Não tenho nada contra “o Marketing”, só acho um bom exemplo do conflito entre a necessidade da informação e a capacidade de manuseio das ferramentas.


Viram o tanto que eu gastei de letras para explicar a idéia? Olhem e aprendam com quem sabe o que faz:


“The fundamental issue with the data lake is that it makes certain assumptions about the users of information,” said Mr. Heudecker. “It assumes that users recognize or understand the contextual bias of how data is captured, that they know how to merge and reconcile different data sources without ‘a priori knowledge’ and that they understand the incomplete nature of datasets, regardless of structure.”

While these assumptions may be true for users working with data, such as data scientists, the majority of business users lack this level of sophistication or support from operational information governance routines. Developing or acquiring these skills or obtaining such support on an individual basis, is both time-consuming and expensive, or impossible.


Sintético, completo, preciso! Elegante! Em tradução livre:


“A questão fundamental que um DL traz é que partimos de certos pressupostos sobre os usuários da informação”, disse o Sr. Heudecker. “Assume-se que os usuários reconhecem ou entendem o viés contextual de como os dados são capturados, que eles sabem como juntar esses dados e reconciliar diferentes fontes de dados sem um conhecimento prévio e que eles compreendem a natureza de incompletude dos conjuntos de dados, independentemente da estrutura.”

Ainda que esses pressupostos possam ser verdade para usuários que trabalham com dados, como cientistas de dados, a maioria dos usuários de negócios não possui esse nível de sofisticação ou apoio dos procedimentos de governança de informações operacionais. Desenvolver ou adquirir essas habilidades ou obter tal suporte em uma base individual e caro e demorado, ou impossível.


Eles vão no miolo da questão: propor um Data Lake presume que os usuários são de um tipo que quase não existe, e que transformar um usuário comum nesta figura de super-usuário é caro, se não impossível.

Outros Casos

O artigo segue adiante para discutir outros aspectos e riscos presentes em uma iniciativa de DL, mas o fulcro é sempre o mesmo: a falta de gestão do repositório, e a excessiva dependência do usuário final para geração de valor.

A certa altura vem este comentário (tradução livre:)


DL normalmente começa com repositórios de dados sem “governo”. Atender as necessidades de uma audiência mais ampla requer repositórios organizados, controlados, consistentes e com controle de acesso – elementos já disponíveis em um DW.


Conclusão

E o que tiramos disso tudo? O Gartner é bem simpático (tradução livre:)


White: Sempre há valor a ser encontrado nos dados, mas a questão que sua organização deve atacar é esta: “nós permitimos e até encorajamos análises que ocorrem uma única vez, autônomas, de dados que estão em silos ou em um Data Lake, unindo esses dados para aquela análise apenas, ou nós formalizamos esse esforço até certo ponto, e tentamos sustentar as habilidades que geram valor?” Se vamos endossar o herói, o agente solitário, um Data Lake com certeza possui um grande apelo. Se estamos mais tendentes à alternativa, um uso mais formalizado, então é melhor deixar o DL para trás e seguir para adotar uma estratégia baseada em DW.


Eu, bom, eu sou mais marrento mesmo, então as conclusões a que eu chego são:

  • Data Lake parece mais um conceito experimental que um produto ou serviço concreto e acabado;
  • Ainda não existe um caso de uso claro, ou mesmo nublado, que sirva para uma organização decidir-se pela adoção de um DL;
  • O conjunto de riscos e dificuldades associados a um DL supera de longe quaisquer prováveis benefícios.

Eu sempre digo que BI é uma disciplina, mais que ferramentas ou técnicas. Sempre que aparece uma tendência de mercado como o Data Lake (e Data Discovery, Cientista de Dados etc. etc. etc.), eu fico com o pé atrás, pois parece muito mais um tipo de Marketing do que uma tecnologia nova.

Talvez um dia evolua e torne-se uma peça valiosa do arsenal de BI. Mas por enquanto, por mais que adore a Pentaho e o Pentaho (e eu gosto muito dos dois, por enquanto), eu não vejo motivo para investir em um DL. Na verdade, eu vejo um alto risco de um projeto de DL acabar em problemas caros, ou até mesmo fracasso total.

As Soluções Clássicas – Credit Scoring

Credit Scoring é o processo de atribuir uma pontuação – score – ao solicitante de alguma operação de crédito, como um empréstimo ou um parcelamento, e assim oferecer um número, um fato concreto, sobre essa solicitação para apoiar a decisão de concedê-la ou recusá-la. (Note que Credit Scoring é o processo, e Credit Score é o resultado.)

Uma solução de CS é resultado de um projeto de Data Mining, conforme eu expliquei no post inicial desta série, As Soluções Clássicas.

A idéia é simples, mas o processo em si é cheio de nuances, a começar por “score sobre o quê”, indo até o “score sobre quem”, combinando-os em “score para quem fazer o quê?”. Como a proposta é dar a vocês o sentimento de BI aplicado, uma visão geral sobre a solução de negócio, mais que de tecnologia ou Matemática, vou falar em termos genéricos e leigos. E assim como o post CRM, tudo aqui foi tirado em grande proporção de uma Solução SAS para CS e do livro Data Mining Techniques.

Introdução

Vamos do início, e no caso canônico: bancos emprestam dinheiro a clientes, que pagam de volta (ou não.) O processo em si não é muito complicado:

Ciclo de vida de um novo pedido de empréstimo.

Ciclo de vida de um novo pedido de empréstimo.

Um cliente (um prospecto na verdade, pois cliente ele será se o pedido for aceito) entra com o pedido de crédito, o banco avalia e decide se concede ou não.

Se o banco recusar o empréstimo a coisa acaba ali mesmo. Se conceder, o prospecto vira cliente, recebe o dinheiro e começa a pagar as parcelas. Daí ele entra em outro ciclo de vida:

Ciclo de vida de um empréstimo em andamento.

Ciclo de vida de um empréstimo em andamento.

Se durate a vigência do empréstimo (o contrato) ele deixar de pagar uma parcela, ele entra em recuperação. Pode ser apenas um pagamento atrasado alguns dias, um pagamento que ele “esqueceu” (deixou de pagar uma parcela, mas continua pagando as outras), ou passou a pagar com atraso, e assim por diante. Na situação limite, quando o cliente acumula sucessivos atrasos e a recuperação empaca, o cliente é encerrado, e a recuperação passa para a esfera jurídica, na qual o banco vai tentar reaver qualquer dinheiro possível e minimizar as perdas.

Se o processo de recuperação dá certo o cliente volta a efetuar os pagamentos e o andamento do processo retorna ao normal, seguindo até seu encerramento. Depois disso o ciclo pode recomeçar, com o agora ex-cliente pedindo um novo empréstimo.

Trabalho de Formiguinha

Imagine-se na posição do gerente do banco que recebe um pedido de crédito. Via de regra, até certo valor, todo gerente possui uma autonomia para decidir sobre a concessão desse pedido. Acima desse ponto o processo “sobe” para outras instâncias do banco, melhor capacitadas a avaliar os riscos do pedido.

E como um gerente, um profissional técnico do ramo, decide sobre esse pedido? Ele precisa descobrir se esse prospecto tem algum histórico de bom pagador ou caloteiro, por exemplo. E mesmo não tendo um bom histórico, ou apesar de tê-lo, o pedido faz sentido? O destino prometido ao dinheiro é um negócio saudável? Ou parece algum “esquema”, alguma coisa suspeita ou boa demais para ser verdade?

Não é uma tarefa simples. Meu pai foi gerente de banco antes, durante e depois da explosão da informatização bancária, e eu testemunhei em primeira mão (ou quase, hehe) as mudanças causadas nessa transição. Ele sempre foi muito reservado sobre o trabalho dele, mas alguma coisa sempre escapava. Como eu sou muito curioso e enxerido, acabei entendendo como ele fazia essas avaliações: ele visitava o cliente, aprendia sobre o negócio dele, sobre o destino do empréstimo e depois fazia a lição de casa, que consistia em levantar o histórico do cliente no banco, se existisse, depois no SERASA (ou coisa que o valhesse durante as décadas 70 a 90) e finalmente conversava com as “fontes” dele, profissionais que ele conhecia neste ou naquele segmento e que poderiam saber de algo a mais, saber como o mercado estava reagindo etc. Isso tudo além de ler Veja, Isto É, Exame, Manchete, Estadão e Gazeta Mercantil (ele já estava aposentado quando saiu o Valor.)

Só que, no final, não raras vezes ele tinha que apostar na própria intuição. Em certos casos ele dizia que “tinha uma sensação estranha” ou que “algo estava incomodando-o”, que “tudo estava certo, e isso era estranho” e assim por diante. Eu me lembro claramente de um dia ele chegar em casa e falar com minha mãe: “sabe o sujeito que pediu empréstimo e eu recusei? Eu não disse que era estranho? Acabaram de descobrir que ele deu estouro na praça”. Estouro na praça é o jargão bancário para estelionato: o cara tinha apresentado um lindo projeto de abatedouro e levantou crédito em vários bancos, crédito que ele embolsou e sumiu. Meu pai negara, baseado no “faro”, ele dizia, e foi o que salvou o pescoço dele.

Como vocês podem imaginar, não era um trabalho rápido. Uma parte dos casos eram novas linhas de créditos para clientes estabelecidos, e esses saiam rapidamente, mas os novos negócios demoravam algum tempo.

Com o advento de computadores e armazenamento cada vez mais poderosos e baratos, e as novas possibilidades abertas pelo acúmulo cada vez maior de dados (soa familiar? era década de 70, indo para 80, e ainda hoje temos a mesma conversa!!), aos poucos a importância do trabalho de analista feito por profissionais como meu pai, chamados eufemisticamente de linha de frente, foi diminuindo. O banco foi se tornando capaz de emitir análises cada vez mais rápidas e mais precisas sobre cada pedido, e paulatinamente a autonomia dele, o tamanho do empréstimo que ele podia decidir sem recorrer à central do banco, dimiuia. Cada vez mais pedidos, de valores cada vez menores, eram remetidos eletronicamente para a central de processamento de dados do banco, e uma análise mandada de volta em cada vez menos tempo.


Eu não me lembro exatamente de qual sistema era, mas dos meus quinze anos eu me lembro de ele usando uma coisa parecida com o sistema 3790 da IBM:

Sistema IBM 3790 de computação distribuída: pioneirismo vintage!

Sistema IBM 3790 de computação distribuída: pioneirismo vintage!

Me lembro do meu espanto ao ver meu pai, um “velho” de mais de cinquenta anos, entusiasta da computação, pressionando pela a informatização da agência inteira. Mas velhos não resistem à tecnologia??


Essa tendência seguiu firme e forte, até o momento em que todo caixa eletrônico (ATM) passou a oferecer crédito na hora.

Na Passarela, o Modelo!

Mas como, afinal, a informatização conseguiu substituir o pé na rua, a investigação em pessoa e a intuição?

Resposta: não conseguiu. O processo de tomada de decisão manual, por assim dizer, depende de se obter certas informações. O processo de decisão automatizado, que é uma aplicação de Data Mining, não pode contar com o mesmo tipo de conhecimento consumido no processo manual e por isso precisa apelar para outros recursos, outros caminhos.

Assim, ao invés de avaliar um prospecto pelo que sabemos sobre ele, o processo automatizado atribui uma nota – um score – ao prospecto a partir do que se sabe sobre os clientes que se parecem com ele.

Funciona assim: um especialista no assunto analisa uma massa de dados de clientes, isto é, de quem já contratou crédito. Essa massa possui algumas característias como, por exemplo, ser apenas uma parcela da base de dados, ao invés de ser a base inteira. Por outro lado, ela contém uma certa proporção dos vários tipos de clientes e situações, refletindo a distribuição da base inteira. E são dados limpos, que foram tratados para remover as incertezas e dubiedades. E por aí vai.

Essa amostra de dados é então dividida em algumas partes, como a base de treinamento e de avaliação. Sobre uma destas partes o especialista, que é um Analista de Data Mining, vai rodar alguns testes, e depois de um pouco de trabalho vai chegar a algumas expressões matemáticas que dizem qual é a chance de um determinado cliente pagar ou não pagar o empréstimo. Essas expressões são o que se chama modelo matemático, e leva esse nome por que ele mostra como a realidade se comporta, tal qual uma maquete representa um prédio.

E como confiar que este modelo de fato representa a realidade? Aplicando-se este modelo contra as outras partes da amostra inicial e medindo o quanto ele está certo ou errado.

Gráfico de avaliação e comparação de modelos. Quem "ajusta" melhor?

Gráfico de avaliação e comparação de modelos. Quem “ajusta” melhor?


Os termos técnicos não são “certo” e “errado”, mas sim coisas como sensibilidade, discriminação, lift, ganho etc. Eu estou simplificando esse jargão em prol da comunicação.


O processo volta ao início e é repetido algumas vezes, até que o modelo ganhe um grau de certeza que atenda a demanda da empresa, isto é, até que ele entegue as respostas buscadas, dentro de uma faixa de certezas. Neste momento o modelo (matemático, lembre-se! Não é modelo de bancos de dados!) está pronto e pode ser usado para estimar o risco de conceder crédito a um prospecto.

Eis um fluxo de Data Mining: note o particionamento dos dados e a avaliação dos modelos.

Eis um fluxo de Data Mining: note o particionamento dos dados e a avaliação dos modelos.

Só Isso?

Até agora falamos como um modelo matemático pode ser usado para estimar o risco de um novo negócio. Vimos no início, porém, que o ciclo de vida do cliente vai além da venda do crédito: ele passa por todo o período em que o empréstimo é quitado. Nesse período muita coisa pode acontecer, como perdermos algum dinheiro com caloteiros contumazes, mas recuperar outro tanto de clientes que passaram por dificuldades financeiras.

Grosso modo, a solução de Credit Scoring cria modelos de riscos que dão respostas às seguintes perguntas:

  • Contratação de crédito: qual é o risco de um determinado solicitante se mostrar um mau (ou bom) pagador?
  • Falha de pagamentos: que cliente possui o maior risco de deixar de pagar o empréstimo, em parte ou totalmente?
  • Recuperação: quanto de recuperação de valores em atraso podemos esperar da base de clientes?

Ou seja, podemos ter modelos que tratam o cliente desde antes de ele receber o crédito, até depois de ele quitá-lo (avaliando quando sugerir um novo empréstimo), passando por avaliações de risco de atrasos, perdas e recuperações destas perdas!

Felicidade É…

… um crediário nas Casas Bahia, já diziam os Mamonas Assasinas!

Se você acompanhou o raciocínio até aqui deve estar achando Credit Scoring uma solução muito específica, voltada para um segmento relativamente pequeno – empréstimos por bancos. Na verdade, essa solução aplica-se em um sem-número de situações e indústrias. Quer ver?

Crediário

Toda loja que vende a crédito pode usar essa solução. As Casas Bahia são um exemplo para lá de manjado, tanto que dizem que o negócio deles é crédito pessoal, que por acaso é feito dentro de uma loja onde podemos gastar esse empréstimo.

Limites

Já se perguntou como é que sua operadora de cartão de crédito estipula seus limites? Ou porque é que seu limite aumentou de repente? E cheque especial? De onde o banco tira coragem para te deixar gastar a descoberto??

Todos esses exemplos, caso você não tenha notado, são empréstimos temporários. A solução de Credit Scoring dá uma forma de calcular que valores podem ser deixados à disposição do cliente, pré-aprovado, para uso rápido – para fluxo de caixa.

Hipotecas

Essa é ótima: pedimos um empréstimo, e em contra-partida oferecemos um imóvel como lastro para o empréstimo. Esse tipo de operação, chamada de hipoteca ou hipotecagem, tende a oferecer juros menores porque representam um risco menor. Mas quão menores ainda serão vantagem ou seguro para a instituição que oferece o crédito?

Seguros & Prêmios

Não. Talvez você até atenha se perguntado se CS não seria uma boa opção para estipular prêmios de seguros ou custos destes mesmos seguros. Bom, apesar de esses números poderem ser calculados com uma solução de Data Mining, não é a solução de Credit Scoring que faz isso, mas sim a de Cálculo Atuarial – assunto do próximo post da série!

Conclusão

Voltando um pouco à história do meu pai e do banco, ao contrário do que o senso comum pode nos levar a pensar, meu pai não se revoltou com essa “perda de poder”. Longe disso! Ele abraçou essa idéia com fervor. Pudera, a lógica dele ela cristalina: esse trabalho de formiguinha roubava tempo que ele poderia usar para ir atrás de quem precisava de dinheiro, mas não ainda não tinha ido até o banco. Mais do que isso: se ele trouxesse um novo negócio, ele mesmo precisaria avaliar o cliente, precisando ficar sentado mais um tempo até processar os novos prospectos, e só então poderia sair para buscar outros… e a vida virava um arrastar sem fim, um sai-cria-negócio-pára-recomeça. Com a automação do processo de decisão de concessão de crédito, ele ficaria livre para se dedicar continuamente a abrir novas frentes de negócios, sendo pró-ativo, deixando o maçante trabalho de autorizar ou não para um time mais eficiente e mais preparado que ele. Ele gostava era de por o pé na rua para vender! :-)

De novo, isso te soa familiar? “Automatizar processos repetitivos e liberar os trabalhadores para funções mais nobres.” Essa é a eterna promessa da automatização, feita por TI!

A concessão de crédito é um processo que pode ser resolvido tanto analisando-se caso a caso, quanto em lote. A solução de Credit Scoring é uma automação do processo de decisão, em que usamos o que sabemos sobre o pretendente, seu histórico de comportamento e o contexto, para qualificá-lo desta ou daquela maneira e assim tornar a análise um processo objetivo, automatizável até. E tanto isso é possível que temos aí os caixas-automáticos oferencendo crédito em qualquer esquina do país, vinte e quatro horas por dia, 365 dias por ano.

All hail Business Intelligence! All power to the knowledge!E o pessoal se matando para comprar ferramentas de dashboards… :-)


No próximo post teremos a última solução integrante da SAStíssima trindade de BI, outro assunto que também é praticamente sinônimo de BI e Data Mining: a Solução Atuarial, vulgarmente conhecida como “Seguros”.


 

Data Vault – Satélites?

No post Data Vault – Como Usar  falei um pouco sobre a motivação, conceitos e arquitetura envolvida em um projeto de DW baseado em Data Vault. Um dos meus leitores colocou algumas perguntas muito interessantes, tão interessantes que eu decidi respondê-las em um post exclusivo. Além de ser um meio mais cômodo que um formulário de comentários, é uma forma de agradecer pela participação e mostrar o quanto eu apreciei. ;-) (Sim, eu sou fã dos meus leitores.)

Perguntas, Perguntas, Perguntas

Eis as perguntas colocadas no comentário:

1) Nos satélites, você cita um campo “Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);”. Neste ponto eu fiquei em dúvida. O ETL para estes satélites poderão realizar operação de update ou não? Ou este campo seria apenas para os casos de atributos que já tiveram uma “vigência fechada” nos OLTP (estou fazendo analogia ao SCD tipo II)?

2) Eu e um colega discutimos se o DV seriam bancos de dados para cada sistema transacional ou todo o DV corporativo estaria em um único banco de dados. Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto? No meu caso, estou falando de SAS e, consequentemente, datasets são tabelas e diretórios são bancos de dados. Então, na falta de um banco relacional como DV, eu inicialmente colocaria todo o DV num “diretório dvault”.

3) Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Vou responder uma por seção. Vamos lá.

LEDTS vs. SCD2

O ETL para estes satélites poderão realizar operação de update ou não?

Não apenas podem, como devem. Satélites guardam histórico e possuem exatamente o mesmo comportamento de uma dimensão de variação lenta do tipo 2. Ele acertou na mosca!

Hubs e links são tabelas que guardam os conceitos de negócio da organização, e as relações entre esses conceitos. Se algum dia um determinado hub ou relacionamento entre hubs existiu, o Data Vault captura e arquiva essa informação. Satélites, por outro lado, dão o contexto desses elementos.

O Cofre: Coleção ou Caverna?

A segunda pergunta é mais complexa:

Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto?

Bom, por um simples questão de integração, deveria estar tudo junto.

Buraco Negro

Até que ponto pode crescer um satélite?

Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Bom, o propósito central de um DV é acumular “todo os dados, para todo o sempre”. Logo, precisamos que a estrutura na qual os dados estão armazenados dê conta disso. Se um relacional não consegue, então precisamos recorrer a algo mais elástico. Inmon chamava essa camada de Near Line Storage, que é um armazenamento de alto volume, mas em uma mídia mais econômica. Em troca pelo preço menor por byte e durabilidade maior, a velocidade de acesso seria menor. No caso original, NLS seriam fitas magnéticas.

Conclusão

A conclusão, desta vez, é minha: do comentário e das perguntas eu posso ver que estou deixando algumas lacunas no assunto de Data Vault. Vou levar essa visão em consideração nos próximos posts sobre o assunto.

Até lá! ;-)

Categorias:Conceitos, DW Tags:, , ,
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 157 outros seguidores