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

Anúncios

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

Projeto de Sucesso

Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.

Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.

Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?


Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?


Sucesso Não Existe

Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.

O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.


Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.


O Caminho para o Sucesso

Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:


Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.


Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!

Decisões, Decisões, Decisões

Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”

Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!

Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.


Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)


O Que Funciona?

E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?

Armazéns de Dados

Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.

Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.

Equipes

Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.

Processos

Há dois grupos de processos dentro de um projeto de BI, especificamente:

  • Processos de Desenvolvimento;
  • Processos de Atendimento.

O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.

O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.

Processo de Desenvolvimento

Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.

Processo de Atendimento

De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.

Soluções

Todo projeto de BI usa quatro tipos de soluções:

  • Apresentações;
  • Relatórios;
  • OLAP;
  • Data Mining.

As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.


E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.


Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.

Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.

Conclusão

Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.

Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.

Diagrama da Fábrica Corporativa de Informações.
Diagrama da Fábrica Corporativa de Informações.

Outro nome para essa abordagem é BICCBusiness Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.

Não é um BICC, mas dá uma idéia de como funciona a tal "linha de produção".
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.

O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.

É isso, até a próxima. ;-)