Relatórios com Metamodelos

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

Sério? Relatórios??

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

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

O Pentaho Report Designer

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

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

Neste relatório:

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

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

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

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

Pentaho Metadata Editor.
Pentaho Metadata Editor.

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

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

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

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


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


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

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

Meta… Meta… Meta…

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

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

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

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

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


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

PRD com Metamodelos

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

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

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

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

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


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


Como Fazer

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

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

Instalar PRD e PME

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

Base de Dados: Beltrano S/A

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

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

Metamodelo Beltrano OLTP

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

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

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

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


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


Registrar Metamodelo como Fonte de Dados

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

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

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

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

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

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


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

Criando uma Consulta MQL

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

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

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

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

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

Montando um Relatório

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

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

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

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

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

Conclusão

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

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

Até a próxima! :-)

Novo Plugin Pentaho BA Server: Self Service BI

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

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

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

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

Uau.

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

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

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

Em resumo:

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

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

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

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

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

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

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

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

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

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


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


:-O

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

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

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

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

3.1 E Agora?

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

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

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

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

Pentaho Seis Saiu!

Acabei de verificar no SourceForge e está lá:

151014_PentahoSeis_01

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

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

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

De Agilidade e BI

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

Ágil, Não Rápido

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

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

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

É ruim, hein! :-P


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


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

Inteligência de Negócios Ágil?

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

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

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

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

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

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

Senta que Lá Vem História…

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

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

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

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

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

Requisitos Para Gestão Ágil

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

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

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

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

150827_DAEBI_004

4Shot Agile BI com Pentaho

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

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

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

150827_DAEBI_002

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

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

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


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


Compre! :-D

Excel vs. MDX

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

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

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

Vamos lá.

O Problema

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


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


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

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

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

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

Reformulando o problema com a SteelWheels, fica:


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


Resolvendo com Excel

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

E para fazer isso nós precisamos:

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

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

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

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

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

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

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

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

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

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


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

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

E salvamos esse resultado em formato texto:

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

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

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

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

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

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

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

Voilá! Problema resolvido!

MultiDimensional eXpressions

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

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

Resolvendo com MDX

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

Conclusão

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

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

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

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

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

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

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

Resposta: volume de dados e complexidade.

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

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

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

É quando MDX passa a ser mais interessante que Excel.

Até a próxima!

Quando Nuton Gritou Eureqa

Eu tento fazer com que todo texto seja fleugmático: interessante, mas controlado, sem deixar a empolgação subir à cabeça. Mas esse aqui vai ser difícil. Quando eu assisti o vídeo eu só conseguia pensar OMGWTFOMGWTF…

Funciona assim.

Data Mining é uma coisa manual. Não é possível fazer uma garimpagem de dados automática, por poucas e boas razões:

  1. Um modelo que represente um negócio (sazonalidade de vendas, por exemplo) é necessariamente muito complexo, e possui, necessariamente, muitas variáveis;
  2. A busca da equação mais adequada é um problema de combinatória: combinar N famílias de equações, parametrizadas por M variáveis;
  3. Dado o número de variáveis e as famílias de equações que podem servir como modelo, o número de combinações explode e a busca, mesmo com supercomputadores (que não estão disponíveis para qualquer um, diga-se de passagem), seria demorada demais para ser útil.

Tradicionalmente o analista de Data Mining faz uma avaliação dos dados, seleciona uma amostra e vira-a de tudo quanto é lado, tentando enxergar alguma possível relação entre as variáveis. A partir daí ele propõe alguns modelos e, paulitanemente, vai limando os menos adequados e melhorando as propostas iniciais. Isso repete-se até que o erro diminua para um patamar definido pelo negócio, e então testa-se o modelo contra o restante dos dados. Se passar, vai para produção, onde ele identificará possíveis clientes, prováveis fraudadores, relacionamentos em atrito etc. etc. etc.

Não dá para automatizar isso e obter um resultado dentro dos próximos milhões de anos, mesmo para pequenos conjuntos de dados, mesmo com problemas simples. Não dá, é uma impossibilidade combinatória. Sempre será necessário algum tipo de guia humano para ajudar a máquina a sair do outro lado.

Um bom programador pode olhar para isso e retrucar que “dá para fazer um programa pré-carregado com os modelos mais comuns e conhecidos”. Isso reduziria a busca no espaço de soluções a um volume muito menor que o espaço inteiro (que pode muito bem ser infinito) e assim semi-automatizar Data Mining. Ok, mas pouco prático, já que cada caso é um caso, e isso reflete-se em cada modelo é um modelo.

Qualquer um que estudou Computação Natural pode olhar para essa situação e intuir a existência de uma solução com Algoritmos Genéticos ou Computação Evolutiva. Eu mesmo, que fui aluno de algumas dessas matérias, cheguei a pensar se não seria possível um motor de Data Mining automático. Nunca levei a idéia a sério, até porque eu sou fraquinho com Matemática.

Mas não é que algém levou? E é isso que o Eureqa, da empresa Nutonian, faz: ele gera uma série de possíveis modelos, aleatoriamente, e evolue-os até um certo erro pré-definido. Nada mais óbvio, nada mais simples. Mas eles fizeram!!!!

Assistam os vídeos deste link para ter uma idéia de como funciona. O exemplo dado no primeiro vídeo (Through the Wormhole with Morgan Freeman) é o mais claro. Eu ainda acho que ele usou um caso muito simples, muito banal (um pêndulo duplo), mas mesmo assim é impressionante!

Pode parecer pouca coisa, ou besteirol científico, mas o simples fato de já existir um produto que faz isso torna a possibilidade de Data Mining automático muito mais próxima da realidade!

Uau!

Ler mais

Testando o Vertica

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

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

O Experimento

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

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

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

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

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

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

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

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

Legal.

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

A Conclusão…

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

E eu aposto que é.

Feliz Ano Novo!!

Ué, Cadê o Perry?

Quem tem filhos pequenos (e usa-os como desculpa para assistir desenhos animados) conhece essa: o Phineas anuncia ao Ferb que “já sabe o que vamos fazer hoje”, olha para os lados e diz “ué, cadê o Perry?” O telespectador já sabe: segundos antes o Perry se esgueirou e sumiu por alguma passagem secreta, em direção à sua próxima missão contra o mais recente -inator do Dr. Doofenshmirtz – só o Phineas e cia. bela é que ainda não tinham notado.

O mundo está cheio destes momentos: “ué, cadê os números romanos?”, “ué, cadê a máquina de escrever?” e assim por diante. (Sério, os números romanos demoraram centenas de anos para sumir de vez.)

O que caracteriza esse momento ué-cadê-o-perry, na minha opinião, é o instante em que ele sai, mas ninguém no desenho notou ainda. É quando uma novidade que vai mudar a cara do mundo apareceu, mas ninguém ainda se deu conta dela, ou de que ela já mudou o mundo.

Tantas Opções, Tão Poucos Projetos…

Então, já repararam na quantidade de novos bancos de dados que apareceram recentemente? Hadoop é o mais vistoso, mas temos coisas como VoltDB, Vertica, MongoDB, InfiniDB, Infobright etc. etc. etc. E note bem: nenhum deles veio para ser um Hadoop-me-too ou um novo Postgres. Cada um deles oferece recursos específicos para tarefas específicas.

Com esse monte de opções, e com um entendimento mais claro de como um Data Warehouse Corporativo (ou EDW) pode ser arquitetado, vemos que não precisamos mais de um Banco de Dados Relacional para montar um DW. Com isso sabemos que um Sistema Gerenciador de Bancos de Dados Relacional pode se dedicar a tarefa que faz melhor (executar transações) e deixar soluções de BI usar outros softwares.

Arquitetura Típica de EDW

Um EDW deve acumular dados por um tempo a fio, sem final em vista. Até hoje, em quase quinze anos nesta indústria fundamental, eu nunca vi um modelo de dados mais adequado a um EDW que Data Vault.  Acredito que a melhor técnica para um EDW é um modelo de dados DV montado sobre um Hadoop. Graças tanto à flexibilidade e resiliência do DV, quanto a escalabilidade do Hadoop, um arranjo desses pode se sustentar durante anos a fio sem problemas.

Mas como DVs são bons para acumular e péssimos para apresentar (e não é por causa do Hadoop, que por acaso também tem o mesmo problema), a exploração não pode acontecer dentro do EDW. Neste ponto notamos que precisamos de Data Marts.

Esses Data Marts são trechos do EDW colocados ao alcance do usuário final. Disparado, a melhor organização para atender essa necessidade é um Modelo Dimensional.

Então temos dados extraídos dos sistemas de origem carregados em um EDW Hadoop+DV, e deste arranjo dados para exploração pelo cliente são carregados em Data Marts Dimensionais. Como Data Marts prestam-se, principalmente, à análise multidimensional e relatórios, a melhor opção para guardar esse extrato de dados é uma tecnologia que privilegie essa função. Não é uma discussão encerrada, mas há uma seção inteira de bancos de dados analíticos (ou colunares) dedicados a atender exatamente esse tipo de demanda. Exemplos dessa turma são o proprietário gratuito (até 1TB) Vertica, o livre InfiniDB e o fantástico (e caro, proprietário) SybaseIQ.

Ué, Cadê o SGBDR?

Colocando em uma figurinha simples, temos:

Soluções de BI sem Bancos de Dados Relacionais
Soluções de BI sem Bancos de Dados Relacionais

Ué, cade o banco de dados relacional em BI?

Não tem, sumiu. Enquanto ninguém olhava, ele esgueirou-se em direção às novas missões transacionais, e deixou esse nicho ser (adequadamente) preenchido por tecnologias mais apropriadas a BI.

Conclusão

O título original deste post era “Fim de Uma Era”, mas achei pomposo demais e muito ordinário. Isso, porém, não muda o fato de que a era dos SGBDs Relacionais usados para Soluções de BI realmente acabou. Ainda vamos ver empresas investindo nessa tecnologia para montar EDWs porque temos uma inércia em tudo que fazemos, e ainda estamos na curva ascendente de criação de mão-de-obra especializada em Hadoop et. al.

Mas tão logo a oferta mão-de-obra cresça o bastante, o sinal da equação vai mudar e a dobradinha de bancos NoSQL + Analíticos passará a a ser mais barata e eficiente que bancos relacionais, quando então teremos aquele momento:

Ei, cadê o Perry?
Ei, cadê o Perry?

É isso. ;-)

ERP BI Solutions

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

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

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

O que é Data Discovery?

Ouço falar de Data Discovery há alguns anos. Estando na indústria de BI eu vejo como minha obrigação saber, no mínimo, o que é qualquer uma das buzzwords. Como eu já tentava descobrir o que era DD “de verdade” há mais de ano, eu decidi que daria cabo da tarefa de uma vez por todas. Não estava mais aguentando ouvir DD em todo canto sem saber o que era.

Neste um tanto quanto longo demais post eu vou relatar a minha jornada em busca desse conhecimento. Não é um artigo científico, não foi uma busca sistemática. Foi mais uma luta para achar alguma informação, anormalmente rara na minha opinião.

Definição? Eu Acho que Não…

Se você procurar, com o Google, Data Mining, Data Warehouse ou mesmo BI, vai achar uma renca de definições. Data Discovery, por outro lado, é um termo curiosamente “ralo”. Veja o screenshot do Google para Data Discovery:

Googling por Data Discovery: é só isso??
Googling por Data Discovery: é só isso??

Nota: que pese em defesa do DD que o Google já sabe todas as minhas preferências e enviesa todas as minhas buscas. Tente na sua máquina, em casa e no trabalho, e me mande um screenshot dos resultados. Tenho curiosidade em saber quão viciadas estão minhas buscas.

Para comparar, veja os resultados para Data Mining (figurinha carimbada) e para Anchor Modeling (coisa praticamente alienígena):

Um termo histórico, a busca por Data Mining traz muito mais resultados.
Um termo histórico, a busca por Data Mining traz muito mais resultados.

 

Sabe o que é Achor Modeling? Um termo desconhecido para a maioria, mas não para o Google. Dica: o último link é muito bom!
Sabe o que é Achor Modeling? Um termo desconhecido para a maioria, mas não para o Google. Dica: o último link é muito bom!

Sentiram o drama? Bom, vamos adiante. Acessei o verbete Data Discovery na Wikipedia para ver apenas isso:

... e isso é tudo que há sobre DD na Wikipedia.
… e isso é tudo que há sobre DD na Wikipedia.

Eis a definição inteira:

(1) Data discovery is a Business intelligence architecture aimed at interactive reports and explorable data from multiple sources. According to Gartner “Data discovery has become a mainstream architecture in 2012”.

Definition

(2) Jill Dyche calls Data discovery ‘Knowledge discovery’ and defines it as: “[…]the detection of patterns in data. […] These patterns are too specific and seemingly arbitrary to specify, and the analyst would be playing a perpetual guessing-game trying to figure out all the possible patterns in the database. Instead, special knowledge discovery software tools find the patterns and tell the analyst what–and where–they are.” [2]

As the current (2013-2014) SAS Vice-President for Best Practices her definition not surprisingly resembles the definition of Data mining:

“Data mining (…) an interdisciplinary subfield of computer science, is the computational process of discovering patterns in large data sets involving methods at the intersection of artificial intelligence, machine learning, statistics, and database systems. The overall goal of the data mining process is to extract information from a data set and transform it into an understandable structure for further use. Aside from the raw analysis step, it involves database and data management aspects, data pre-processing, model and inference considerations, interestingness metrics, complexity considerations, post-processing of discovered structures, visualization, and online updating.”

It can also be referred to as Business Discovery.

De quebra ainda achamos a definição de Business Discovery: segundo esse artigo, é a mesma coisa.

Vamos analisar as duas partes destacadas.

(1) Data discovery is…

Em tradução livre, DD é uma arquitetura de BI voltada para relatórios interativos e dados exploráveis a partir de várias fontes.

Ou seja, em primeiro lugar, DD não é um produto mas uma arquitetura. Absolutamente nenhum detalhe, por mais geral ou genérico que seja, é dado sobre essa arquitetura no restante do artigo. A busca no Google já não trouxe muita coisa, mas uma busca por architecture data discovery traz menos coisas ainda:

Outra tentativa: se DD é uma arquitetura, será que agora eu acho mais informações? Hmm ...
Outra tentativa: se DD é uma arquitetura, será que agora eu acho mais informações? Hmm …

A segunda parte da frase, “relatórios interativos e dados exploráveis de várias fontes” dificilmente é alguma coisa particular à Data Discovery. Afinal, a ferramenta mais básica de BI é um gerador de relatórios. O conceito mais básico dentro de BI é um DW, que é por natureza “dados exploráveis de várias fontes em um único lugar”.

Conclusão: nenhuma. É, nenhuma! Por este trecho da definição na Wikipedia, DD é só uma buzzword, uma repaginação de “relatórios em cima de um DW”.

Mas o artigo da Wikipedia não acaba ali. Vejamos a segunda parte.

(2) Jill Dyche calls Data discovery…

Jill Dyche chama Data Discovery de ‘Descoberta de Conhecimento’  e define isso como: “[…]a detecção de padrões nos dados.” Uma nota de rodapé aponta para um artigo na Harvard Business Review no qual consta essa definição. Ao final deste artigo descobrimos quem é Jill Dyche:

Jill Dyche

Jill Dyché é a Vice-Presidente de Thought Leadership no SAS, onde ela é responsável por estratégias para clientes-chave e análise de mercado nas áreas de governança de dados, BI, MDM e BigData. Ela escreveu três livros sobre o valor de negócios trazido pela informação.

O culpado da tradução atroz sou eu mesmo, e por isso aqui vão algumas explicações:

  • Thought Leadership é algo como lider intelectual, no sentido de quem pensa muito e lidera (não como o Cérebro gostaria;)
  • Valor de Negócios trazido pela informação: o quão importante um conhecimento (uma informação) é para o negócio, e não o quanto a mais se fatura graças a uma informação. Mais do que saber para qual cliente vender, mais informação sobre o negócio traz mudanças e mais negócios.

A mulher não é fraca, não. Poucas personalidades em TI tem a prerrogativa ou a sorte de definir, sozinha, uma buzzword. Ela está no mesmo nível do Bill Inmon, Pai do DW: Jyll Diché, Mãe do Data Discovery.

Bom, mas e então: o que tiramos desta definição?

De novo: nada. Sim, nada. Porquê? Oras, caramba, por que “a detecção de padrões nos dados” é a mera definição de Data Mining!

Data mining (…), an interdisciplinary subfield of computer science(…) is the computational process of discovering patterns in large data sets(…)

Conclusão: uma vice-presidente do SAS (a multinacional de BI,  uma empresa Thought Leader em Data Mining) define Data Discovery como Data Mining. Ou seja, uma nova buzzword para (re)definir uma antiga buzzword.

Na verdade, esse é um movimento clássico do SAS. Periodicamente eles colam um novo jargão para tentar se descolar da concorrência. O SAS tem um grande problema de propaganda (eles não fazem, e se orgulham disso) e por isso volta e meia se saem com uma dessas. Eu me lembro de um GUSAS (2009, acho) em que eles vieram com essa de BA – BI estava morto, o lance agora seria BA, Business Analytics.

Mais Alguém?

Ok, então em termos de definições formais isso é (praticamente) tudo que temos: um artigo circular da Wikipedia montado sobre um post de uma VP do SAS.

Eu venho repetindo essa pesquisa por definições formais há mais de um ano, e sempre chego mais ou menos aos mesmo artigos e aos mesmos lugares, mesmas pessoas e mesmos conceitos. Pode ser um erro de vício meu, pode ser incompetência minha em usar o Google,  mas se um profissional do ramo repetidamente procura por um assunto, fuça e nunca encontra muito mais que só isso, então provavelmente isso é que o tem para ser encontrado. Mas nem de longe é tudo que existe.

Há outra fonte de informação e conhecimento sobre assuntos de BI: os próprios fornecedores. Essa é uma fonte que não pode ser menosprezada, já que frequentemente novos conceitos surgem de necessidades do mercado que um fornecedor foi inteligente o bastante para identificar e atender. Isso quando uma encomenda direta não é o motivador. Um caso recente das duas situações é Ruby (encomenda direta) e Rails (um resultado colateral.)

Quem é famoso por Data Discovery? Tableau e QlikView me vêem imediatamente à cabeça. Eu também bati um papo com o CEO da Panorama sobre o Necto, que na minha opinião entra na categoria.

Depois eu forcei umas buscas com o Google e achei também SAS, MicroStrategy, Teradata, IBM e SAP (Lumira.) Também achei a Hitachi, mas era um “nada a ver” – coisa de encontrar arquivos em NAS.

Não posso examinar tudo, pois mataria vocês de tédio. Vou destacar os mais importantes (de novo, na minha opinião.) O critério para escolher o mais importante foi bem prático: que empresa se marketeia como “de Data Discovery”. Depois eu vou comentar um pouco sobre os outros fornecedores.

Aviso: tudo que virá a seguir é uma FORTE manifestação da minha opinião pessoal.

Não é uma análise técnica, e não necessariamente eu endosso qualquer um dos produtos a seguir, muito menos detrato-os. Tenho minha cabeça formada e respondo por minha opinião. De novo, este post relata minha saga para tentar entender um conceito, e por isso é uma história totalmente enviesada por meus pontos-de-vista. Se não gostar de algo, esteja à vontade para reclamar.

QlikView

Eis o Thought Leader em DD, na minha opinião. Pelo que eu testemunhei nestes últimos anos, foi a QlikTech que lançou a moda e surfou (e ainda surfa) essa onda. Eles têm um excelente produto, tanto que são adorados pelos clientes. Tive oportunidade de ler o livro QlikView 11 for Developers e ganhei algum entendimento de como ele funciona.

O que eles têm a dizer sobre DD?

Business Discovery is a whole new way of doing things that puts the business user in control. Unlike traditional BI, where just a few people are involved in insight creation, Business Discovery enables everyone to create insight. It’s about workgroups, departments, and entire business units having access to the data they need to make better decisions. With QlikView, businesses can take insight to the edges of their organization, enabling every business user to do their jobs smarter and faster than ever. QlikView enables all users to create tailored insights that meet their unique business needs and timelines.

Putz, acho que chegamos tarde demais: não existe mais DD, agora é Business Discovery. Bom, vai ter que servir. Aqui tem uma mensagem interessante: nada sobre gráficos bonitos e rápidos, mas sim sobre todos na empresa poderem acessar os dados. No final da página tem uma lista de white papers, e um deles é o pote de ouro: um manifesto sobre Business Discovery!! Eles realmente encamparam o assunto!

Só que eu não consegui baixá-lo do site. Uma busca ligeira no Google e voi-lá, manifesto BD! A mensagem é muito boa:

  • Informação pode mudar o mundo;
  • Eles querem tornar o nosso trabalho mais fácil;
  • Negócios estão sendo impactados por pessoas;
  • Merecemos mais que uma bela interface;

Graças ao que eu li no livro QV 11 for Developers eu acho que consegui entender parte da mensagem. Se eu entendi corretamente, BD (que deve ser o mesmo que DD) é uma ferramenta de BI com gráficos beirando o divino de tão bonitos e animados, que busca os dados diretamente dos sistemas de origem.

Parece que o acesso direto a dados é algo importante, mas definitivamente o lance são os gráficos bonitos. Eis um excerto do manifesto, no qual eu destaco em negrito as menções a “coisas bonitas e legais”:

QlikView (…) seductively slick and intuitive dashboards are easy to navigate and fun to use. We support rich colors and robust graphics. We encourage data to speak for itself in vivid shapes and colors. We’ve got style in spades. (…) QlikView is gorgeous — but it’s also genius. We bundle the best of Business Discovery into one application. It allows you to access all your data sources, create your own dashboards, ask your own questions, and get answers instantly from a blazing fast associative technology. Untethered from traditional business intelligence, you can slice and dice data and drill in, out, up, down, and sideways. You can tweak, improve, improvise, and innovate to your heart’s content.

Curioso, não? Segundo o manifesto, sem os fios que te prendem ao BI tradicional (o que é isso???), você pode fatiar e picar furar e deslizar e dançar nos dados como quiser. Curioso porque essa é a promessa do OLAP, é velha, já foi feita por muitas outras empresas e não tem nada, realmente, de novo. Agora, o que é BI tradicional? Seria muito legal se eles fossem mais específicos ou mais claros. Enfim, o manifesto é deles, eles se manifestam como quiserem.

Bom, o suco até agora é: DD já era, o lance é BD, que é melhor que BI tradicional porque é mais livre.

Talvez Business Discovery não seja algo tão diferente: se agora o QV é uma ferramenta de BD, um dia foi de BI antes de ser de DD. O site QuickIntelligence registrou o momento em que a QlikTech tentou se desligar de BI abraçando DD em um post de abril de 2011:

QlikTech has recently shifted their marketing message very slightly to position QlikView as a Data Discovery tool, moving away from the Business Intelligence tag.

Eu não estava lá quando isso aconteceu, mas se o post acima for minimamente verossímel (e tudo indica que seja), a ferramenta não parece ter sofrido mudança, mas apenas um “reposicionamento” através de “uma mudança de mensagem de marketing”. Em miúdos: o QlikView “virou” uma ferramenta de DD só porque eles passaram a se definir desta forma. Talvez a mudança para Business Discovery seja, na verdade, só uma nova mensagem de marketing.

Resumindo: se QlikView é Data Discovery, então Data Discovery e Business Discovery 1) são a mesma coisa e 2) DD diz respeito a montar belos e atraentes e divertidos gráficos com os dados. De acordo com o livro mencionado anteriormente, porém, acessar os dados diretamente não é um objetivo, mas antes uma possibilidade: se precisar, o QV acessa diretamente, mas o ideal, mesmo, é ter um modelo dimensional com os dados prontos para consulta.

Tableau

Não conheço produto. O descobri porque toda vez que procurava DD no Google, anúncios do Tableau apareciam – daí concluí que eles se posicionam como ferramenta de DD.

O site é muito bonito, e todo alinhado com as buzzwords do momento:

Tableau é o bicho! Buzzwords, Buzzwords, Buzzwords! (Cadê o "belos gráficos"??)
Tableau é o bicho! Buzzwords, Buzzwords, Buzzwords! (Cadê o “belos gráficos”??)

Clicando em Products, a mensagem abaixo da bela figura diz:

Our breakthrough products let you create rich analyses and share your insights with colleagues in seconds.

Um termo diferente: “ricas análises”. É bem diferente de “ricos gráficos” ou “belas análises” – intuitivamente eu diria que sugere análises caprichadas e bem feitas. Junto a isso, a vantagem de “compartilhar com seus colegas em segundos”.

Outros termos que se destacam lendo mais a página de produto aparecem Fast, Easy, Any Data, Share. Notadamente nenhuma menção a belos gráficos. Remarkable!

Eu li as páginas dos produtos, diagonalmente, e eles sempre batem na mesma tecla: análises sofisticadas (ricas). O produto existem em versões desktop (incomum – e com uma opção gratuita, chamada Public) e web (com uma opção SaaS, chamada Online) e em nenhum lugar existe uma única menção a coisas bonitas e atraentes.

Eu queria dizer o Tableau é o “me too” do QlikView, ou seja, a empresa que viu o sucesso do vizinho e decidiu pegar o vácuo, mas não consigo. Eles não usam a mesma chamada de vendas, e nem sequer as mesmas buzzwords. Se bem que o QlikView não fala muito em nuvem nem análises ricas…

Enfim, do Tableau eu não consegui aprender nada sobre o que porventura seja Data Discovery.

Necto

Yeah! Acertei em cheio! Olhem só a frase de abertura:

Best of Enterprise BI and Visual Data Discovery – Combined

Se QlikTech é Business Discovery (== Data Discovery.newBuzzword(); ), com um certo desprezo pelo BI tradicional (??), o Necto é o melhor da soma dos dois! Talvez eles tenham alguma opinião ou definição sobre DD. (Opa! Eles disseram DD? Putz, também ficaram para trás… <grin>)

A Panorama é a alegria do repórter de BI. Da mesma página linkada acima:

Panorama Necto is advancing Business Intelligence 3.0 to the next level, bringing together the very best of Enterprise BI with Visual Data Discovery, providing enterprises with new ways to collaborate and create unique contextual connections.

Necto 14 is the first BI solution to provide business users with personalized, intuitive, and interactive analytics, delivered through a highly visual and understandable infographic format. Business users can use Panorama Necto 14’s self-service data discovery and visualization capability to uncover hidden insight, present vital data, and track performance using interactive infographics that dynamically reflect business changes.Necto 14 improves every step of your business decision making process.

BI 3.0? Enterprise BI, formato infográfico altamente visual, self-service Data Discovery!!! MEUSANTODEUSÉMUITABUZZWORDJUNTA!!!! (ROFL!) Se eu tivesse pintado as buzzwords de vermelho ao invés de fazê-las negrito, o texto acima pareceria a bandeira do Flamengo!

Uma coisa que eu gostei é que eles escrevem muito. Há vários textos e white papers sobre o que eles fazem, o que é BI 3.0 e porque são diferentes. Entretanto, eles tomam DD como uma coisa já assimilada e nunca discutem o conceito em si.

Por outro lado, tem tanta buzzword em toda essa informação que fica difícil dizer do que eles estão falando. Eu tive chance de trocar umas palavras (via LinkedIn) com o CEO deles, mas o que realmente me ajudou foi assistir alguns vídeos, especialmente aqueles nos quais eles demonstram a visão do produto, mas não consegui achar o mesmo vídeo de novo.

A idéia é boa: somar Facebook com QlikView e conseguir gente para analisar um problema via uma ferramenta colaborativa.

Enfim, segundo eles, Data Discovery é o bicho se for com o produto deles, claro, já que nenhum outro oferece tantas coisas legais em tão pouco espaço de tela. (Still ROFLing from BW OD!) Mas nada sobre o que é DD. Ou seja, “better me too”: quis fazer um QlikView melhor que o QlikView e inventou outras coisas. Gostei da idéia de times adhoc para análises de dados. Me parece pouco útil para empresas de médio porte ou menores, mas pode muito bem ser o futuro para empresas de grande porte. Vou ficar de olho!

Os Outros

Pausa para uma piada:

Um dia um grande especialista em vermes foi convidado, por um zoológico, para fazer uma palestra sobre elefantes. A oportunidade era boa, mas ele não sabia nada sobre elefantes. Ele aceitou, e sua palestra começava assim: “Os elefantes são grande animais, que possuem quatro membros, uma tromba e uma uma cauda, semelhante a um verme. Os vermes subdividem-se em…”

Moral: todo mundo só fala do que sabe. ;-)

Os fornecedores a seguir lembram um pouco essa piada: eles já estavam no mercado quando a moda pegou, então eles deram um jeito de entrar nela. Os destaques vão para a Teradata, que patrocina um livro, DD for Dummies, masapesar disso o produto não tem uma única menção a “Quickly build beautiful visualizations with just a few clicks”, e para a SAP, gigante alemã do ramo de ERPs, cujo produto inteiro é só “Quickly build beautiful visualizations with just a few clicks”.

SAS

A empresa de BI por excelência, e a cunhadora do termo. Tem um produto específico chamado (adivinhe!) SAS Visual Data Discovery. O sales pitch (a chamada de vendas) é “acesso visual às avançadas capacidades analíticas do SAS, que permite interagir visualmente com dados para clarear o entedimento e alavancar a ação”. Um clássico, sem dúvida. Deve ser caro para dedéu, como tudo do SAS, mas eu não apostaria no SAS contra o QlikView. Não que o SAS não deva ter um bom produto, mas o foco do SAS – a especialidade dele – é solução de BI (que é o que realmente interessa), e por isso todos os outros produtos existem para oferecer competição nos nichos.

MicroStrategy

Não existe um produto chamado explicitamente de Data Discovery. Procurando por microstrategy data discovery no Google voltam alguns links que levam para esta página. Nela a MicroStrategy mostra um produto chamado Visual Insight e tem a seguinte apresentação inicial:

A Faster Way to Visualize Your Data

MicroStrategy Visual Insight empowers you to discover insights from your data using compelling visualizations. Quickly and easily explore any data contained in personal spreadsheets, databases, or Hadoop. Investigate and analyze the data further by defining new metric calculations, zooming into details with filters, and color-coding the results with thresholds. Create multiple visualizations to get additional insights and perspectives that enhance data comprehension. Combine your findings into a dashboard you can save and share with your colleagues.

Eis os elementos clássicos (ou típicos) da mensagem de DD: obter insights, visual atraente, rápido e dados vindos de qualquer tipo de fonte. Ou seja, mais um “me too”. O curioso, aqui, é que a MicroStrategy tradicionalmente faz exatamente isso – belas visualizações de dados, com alta performance. A parte “de qualquer tipo de fonte” é universal, já que qualquer ferramenta faz isso se jogada sobre um DW. Não sei se ele oferecem Data Blending (outra buzzword – mas isso fica para outro post.)

Repare que, ao contrário do SAS, não existe menção a funções analíticas sofisticadas ou avançadas – só visualizações e gráficos bonitos, rápidos e avançados.

Finalmente, eles oferecem uma lista de outras fontes de informação, muito curiosa:

  • Whitepaper: Checklist for Achieving BI Agility
  • Whitepaper: Enabling Data Discovery
  • Whitepaper: Three Reasons Why Data Discovery Falls Short (segundo eles, DD é útil, mas não é tudo)
  • Webcast: 7 Steps for Achieving BI Agility (que inclui um caso de DD com MicroStrategy)
  • Webcast: A Guide to Governed Data Discovery

Hmm… Eles entraram na onda ou não??

Teradata

O produto da Teradata, a empresa de big data antes do BigData, dos bancos de dados gigantescos e de altíssima performance (não tem tera no nome à toa) chama-se Aster, que oferece “poderosos insights através de uma solução integrada, otimizada para todos os dados, múltiplas análises e velocidade, com um esforço mínimo”. Não achei que o Aster responde por DD, mas como tanto via Google quanto via search field, os resultados são iguais, entendi que essa é a mensagem que a Teradata quer passar. Na minha opinião, faltaria a parte de visualização, mas ei, talvez DD não tenha mesmo nada a ver com visualização.

IBM

Tudo com a IBM é tão vasto, completo e complexo que até buscar produtos de DD deles, no Google, é uma tarefa difícil. O primeiro site que eu encontrei, depois de algumas tentativas, foi o VizWorld. O autor do post discute a nova oferta de produtos da IBM para DD na nuvem, e menciona um tal de projeto Neo, em beta ainda em novembro de 2013. Hm, sei, projeto Neo. Nem fui atrás.

Tentei o Google de novo e fui para um resultado que eu dispensei inicialmente: InfoSphere Discovery – eu confundira com WebSphere. InfoSphere é a linha de BI da IBM. Cavando um pouco cheguei a muitas outras coisas, mas em resumo, se existe DD para a IBM, ela se resume em três coisas: visualization, visualizationvisualization (Balmer ficaria orgulhoso.) Eles tem um motor de visualização adaptativa (RAVE), uma comunidade de especialistas de visualização (Many Eyes) etc. etc. etc.

E tem o Cognos, que a IBM comprou há algum tempo. Diferentes nomes, mesmas funções.

Agora eu me lembro porque eu nunca vi nada de BI da IBM – é tudo tãããooo difícil e abstrato…

SAP

SAP é outro mundo do tamanho da IBM. Eles têm produtos próprios de BI, relatórios, DW etc. Entre outras coisas, eles compraram um dos antigos nomes de BI, o Business Objects (BO.) Mas eu fiz uma pesquisa no Google por SAP data discovery e não veio nada disso. Veio um tal de SAP Lumira. Eis o que aparece no site deles:

Quickly build beautiful visualizations with just a few clicks. Combine data sources and get the big picture and granular details together. Visualize large volumes of data without having to sacrifice performance. Maximize data knowledge and drive immediate outcomes.

Preciso dizer mais? “Big Bad German Business Me Too”.

Excel

A Microsoft não reposicionou o Excel como ferramenta de BI, mas no fundo o Excel é o proverbial “lápis e papel” de BI. Excepcionalmente versátil, imensamente útil, o Excel é a ferramentra de BI por excelência. É nele que baixamos os dados para “fazer uma contas e ver se os números estão batendo”. Ele está muito longe de ser capaz de oferecer uma solução de BI, mas em princípio, está tudo lá.

Eu decidi incluir o Excel na lista porque a QlikTech o faz parecer uma ferramenta de DD: ele pode acessar uma enorme gama de dados e produzir fácil e rapidamente uma gama de boas (e até belas) visualizações de dados.

Claro que eu estou usando a palavra Excel como usamos Bombril: tanto poderia ser o Calc, do LibreOffice, quanto o próprio Excel. A categoria é Planilha Eletrônica. Mas ninguém compra palha de aço Brilhante – compramos Bombril mais barato!

Pentaho

Rapaz, a Pentaho é outro SAS. Tem muita coisa, e faz tudo mas (curiosamente) resolveu não investir no jargão DD. Eles criaram o deles (ah, tão SAS…), Data Blending (que eu também estou apanhando para captar, mas enfim, o problema aqui sou mesmo eu – ainda não parei para ir atrás.)

Seguindo a definição da QlikTech, por outro lado, o Pentaho BI Server EE é uma ferramenta de DD pois facilmente produz belos gráficos a partir de qualquer fonte de dados, sem intervenção do departamento de TI. O Pentaho CE também pode fazer isso, mas dá um pouco mais de trabalho. Além disso, também acessa qualquer fonte de dados. (Banco de dados 100% em memória não foi mencionado, mas o Pentaho também pode usar um se precisar.)

Finalmente, podemos juntar uma ferramenta de webmeeting, como o BigBlueButton ou OpenMeetings, para ter os times adhoc. Se o Pedro conseguir trazer para o CDE a facilidade do Pentaho EE Dashboard Designer, então o BI Server poderá oferecer infográficos adhoc. Isso completaria a visão de BI 3.0 da Panorama. O que também é uma opção para qualquer outra ferramenta. Nada mal.

Conclusão

O que é Data Discovery? Na minha opinião:

  1. Segundo a Wikipedia, é só uma nova buzzword do SAS, criada para substituir Data Mining;
  2. Segundo o mais importante player da área, a QlikTech, é uma ferramenta de análise de dados capaz de gerar belos gráficos;
  3. Segundo os outros fornecedores, incluindo a Pentaho, é folder fodder – só encheção de linguiça.

Por enquanto, a minha despretenciosa e ordinária pesquisa – a que qualquer um poderia fazer – chegou à conclusão que Data Discovery se trata de um termo específico da área, criado para diferenciar um fornecedor de outro no lotado mercado de ferramentas de BI. Em jargão castiço, Data Discovery é só uma buzzword.

Por inferência, a mesma conclusão espalha-se para Business Discovery.


A Seguir: O Que É Data Discovery, Parte 2 – Discussões no LinkedIn

Ok, então eu esgotei o que a minha parca competência de googlador profissional consegue me trazer. É hora de jogar a toalha e buscar o conselho dos meus pares da indústria de BI. É hora de postar a mesma pergunta no LinkedIn.

Semana que vem eu publicarei a resenha do livro Pentaho BA Cookbook, e depois (talvez) um post sobre o que destaca uma solução de BI de uma mera ferramenta. Daí, na semana seguinte, se eu conseguir, eu publicarei a segunda parte.

Tentem não me linchar – eu estou só compartilhando os meus pensamentos sobre a aventura que tem sido essa busca. Nada aqui tinha a menor intenção de ser minimamente formal ou definitivo, nem elogiar ou detratar ninguém. Se você discorda de algo que eu escrevi, é bem-vindo para comentar educadamente.

Até lá!