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.

Introdução à Data Vault

Toda empresa que deseja usufruir das vantagens que projetos de Inteligência de Negócios trazem (como incremento de lucros), precisa investir concomitantemente em Armazéns de Dados.

O primeiro passo é decidir o que se deseja: oferecer relatórios, análises, uma solução do tipo CRM ou Churn etc. Essa escolha vai determinar quais dados são necessários. Esses dados devem ser levados para um Armazéns de Dados (ou DW, do inglês Data Warehouse)  antes de ser consumidos pelo projeto de BI.

Armazéns de Dados são bancos de dados, em qualquer tecnologia, que acumulam os dados da empresa. Um DW, em princípio, acumula todos os dados que a empresa julgar importantes hoje, como aqueles necessários para o projeto de BI, ou acreditar que possam vir a ser importantes no futuro. Os dados são armazenados no DW em sua menor granularidade, para que qualquer pergunta possa ser respondida.

Cada solução de BI implantada na empresa consome dados em formatos específicos. Por exemplo, relatórios e análises OLAP funcionam melhor se os dados estiverem organizados em um Modelo Dimensional. Já uma solução de CRM consome dados em formato “tabelão”, que são adequados a Data Mining. Painéis podem usar os dados de uma estrela dimensional, mas eventualmente pode ser mais producente usar tabelas especiais – simplificam a lógica nos painéis e tendem a reduzir o consumo de hardware. E assim por diante.

Observe sua vida: você usa uma só máquina para tudo? O seu carro passa fax? O seu fax corta grama? O seu barbeador bate bolo? Não, claro. (Caso sua resposta para uma destas perguntas seja sim, entre em contato comigo – vamos ficar ricos!!)

Da mesma forma que no mundo real, o mundo informatizado também usa programas e tecnologias específicas: banco de dados não serve HTTP, Java armazena dados, PHP não oferece cubos OLAP.

Armazéns de Dados não servem para consultas – servem para armazenar dados. Logo, o primeiro erro que precisamos evitar é “one size fits all”: uma tecnologia desenvolvida para resolver um problema não serve para resolver qualquer problema, muito menos todos.

Data Vault

Uma tradução livre do termo é Cofre de Dados: uma tecnologia adequada a acumular dados ao longo do tempo. A partir deste repositório de dados, outros projetos podem se servir do que precisar.

A idéia central de se ter um Data Vault é dispor de um repositório que receba e organize os dados de múltiplas fontes, de tal forma que seja muito fácil incluir ou remover fontes, sem quebrar o repositório e sem virar um pesadelo de manutenção. A partir daí, cada projeto de BI busca do DV os dados que precisa e grava-os em outros repositórios de dados, no formato que precisar.

Apesar de soar como uma camada desnecessária, aparentemente dobrando o esforço (com DV precisamos de dois ETLs no mínimo – um para dentro e outro para fora do DV), adotar um Data Vault reduz o trabalho porque torna o crescimento do DV algo semi-automático, e a criação de fontes secundárias algo padronizado.

Veremos a seguir um DV: seus componentes e como um é modelado. Tudo que será visto pode ser encontrado nos livros abaixo:

Beltrano S/A

Para os exemplos vamos usar o diagrama de dados do banco transacional da Beltrano S/A:

Modelo E-R da aplicação transacional.

Modelo E-R da aplicação transacional.

Leia este link para todos os detalhes sobre a base.

O Modelo de Dados

Um DV tem três componentes básicos:

  1. Hub
  2. Link
  3. Satélite

E mais algumas tabelas acessórias:

  1. Point-In-Time (PIT)
  2. Same-As
  3. Tabelas “dicionário”

Não vou entrar no detalhe das tabelas acessórias, pois elas resolvem problemas específicos que não são necessários para entender o mecanismo geral.

Hub

Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.

Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:

  1. Business Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte da chave de negócios;
  4. Source business key: chave de negócio no sistema de origem.
DV Beltrano S/A: hub Empregados.

DV Beltrano S/A: hub Empregados.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal dos dados. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.

Se a mesma chave existe em vários sistemas, com os mesmos valores, essa tabela automaticamente integra esses sistemas. Por outro lado, se a mesma chave existe em sistemas diferentes, mas com valores diferentes diferentes, então elas devem ser carregadas em hubs separados por sistema. A integração é feita por uma tabela do tipo Same-As entre cada hub.

Eventualmente a chave de negócio no sistema de origem podem ser uma chave composta (ter mais de uma coluna), mas nunca podemos montar como chave de negócio as colunas 3 e 4.

Link

Links tão tabelas que guardam o relacionamento entre dois hubs.

Uma tabelas link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:

  1. Link Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte do relacionamento;
  4. BK1: business key do hub 1;
  5. BK2: business key do hub 2;
  6. BKn: business key do hub n.
DV Beltrano S/A: link Empregados-Pedidos.

DV Beltrano S/A: link Empregados-Pedidos.

Uma tabela link mantém relacionamentos M para M entre os hubs. Elas não dizem nada sobre a validade desse relacionamento, mas apenas que ele foi detectado no sistema de origem. Uma tabela link pode manter auto-relacionamentos também: um hub empregado, quando um empregado é chefe do outro, usa uma tabela link para registrar o relacionamento pai-filho entre os empregados.

Ela também não sofre atualização: novos relacionamentos são inseridos, antigos são descartados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.

Satélite

Satélites são como tabelas de dimensão: guardam os contextos de hubs e links.

Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, …, An de um hub/link X possui as seguintes colunas, nem mais, nem menos:

  1. Business Key/Link key: chave primária do hub/link
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
  4. Record Source: fonte dos atributos;
  5. A1: atributo 1;
  6. A2: atributo 2;
  7. An: atributo n.
DV Beltrano S/A: satélite Empregados.

DV Beltrano S/A: satélite Empregados.

Ao contrário do hub e link, o satélite não tem uma chave primária própria. Ao invés disso a chave primária é composta pelas colunas 1 e 2 (BK/LK + LDTS.)

De novo ao contrário dos hubs/links, os registros de um satélite possuem validade: a cada carga o processo verifica se os registros do satélite ainda existem na origem. Se não existirem mais, eles recebem um date/timestamp atual na coluna 3 (LEDTS.) A cada carga os satélites mudam e desta forma acumulam histórico do sistema.

DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.

DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.

Os atributos de uma chave de negócio ou relacionamento não precisam estar totalmente contidos em uma única tabela: se os atributos variam em taxas diferentes (como quando alguns mudam todos os dias, enquanto outros apenas de vez em quando), eles podem ser gravados em tabelas diferentes.

Quando um mesmo conceito de negócio existe em dois sistemas, criamos um satélite para cada sistema, com cargas independentes.

Corpo

Hubs são conceitos de negócios, links relacionam estes conceitos entre si e os satélites dão o contexto dessas chaves e relacionamentos.

DV Beltrano S/A: modelo captura que empregado fez que pedido.

DV Beltrano S/A: modelo captura que empregado fez que pedido.

Se compararmos um DV a um corpo humano, os hubs são como ossos, formando um esqueleto, links são ligamentos que unem os ossos e satélites são todos os músculos, orgãos e pele que recobre o esqueleto, dando-lhe forma.

Ah! Existe um código de cores: hubs são azuis, links vermelhos e satélites são amarelos.

As Vantagens de um Data Vault

Um DV oferece três vantagens:

  1. Estabilidade e Isolação
  2. Repetibilidade
  3. Performance

Estabilidade

Basta deter-se um pouco sobre essas explicações e perceber que, se a empresa não muda constantemente de ramo, seus conceitos de negócios são relativamente estáveis. Ou seja, mesmo que a empresa mude a forma como ela processa sua vida diária, poucos conceitos de negócio vão nascer ou sumir ao longo do tempo. Mesmo assim, um novo conceito de negócio é imediatamente associado a um novo hub. A implementação desse novo hub não afeta os que já existem – o impacto por uma novidade em termos de conceito de negócio é zero.

Os relaciomentos entre dois conceitos também são, via de regra, estáveis. Pense em produto e fornecedor: podem surgir novos fornecedores (inseridos num hub “fornecedor”), com novos produtos (inseridos num hub “produto”), ou mesmo novos produtos de um fornecedor já existente. Quando isso acontece, o próprio processo de carga se encarrega de anotar esse relaciomento, automaticamente. Se um novo relacionamento é descoberto, porém, o impacto no DV é zero: basta criar a nova tabela link e produzir o código de carga dela. Nenhuma outra tabela do DV é afetada. Ah, e se um relacionamento “morrer”, basta desativar a carga para ele, e para seus satélites – sem NENHUM impacto no restante do Cofre de Dados.

Já os satélites, que são naturalmente mais voláteis, podem mudar de forma com certa frequência. Digamos que, hoje, o DV coleta todos os hipotéticos atributos do cliente. Algo acontece – inventam um novo tipo de e-mail – e passamos a registrar, no sistema de origem, mais esse atributo. Qual é o impacto disso no DV? A resposta é “depende”:

  1. O caminho mais fácil é simplesmente criar um novo satélite com apenas esse atributo e instalar o novo processo de carga para ele. Impacto zero, mas o custo de recuperar essa informação depois pode ficar muito alto, especialmente se formos preguiçosos o tempo todo. A título de curiosidade, essa abordagem leva a uma coisa chamada Anchor Modeling;
  2. O segundo caminho mais fácil é estancar o satélite atual, mudando seu nome para alguma coisa _ate_data-X,  e criar um novo satélite com o novo atributo, e passar a carregá-lo daí em diante. É uma técnica mais interessante em situações que mais do que um par e tal de novis atributos precisam ser capturados. A derivação dos dados para as fontes secundárias precisa levar em conta as diversas versões da tabela, mas o impacto no DV é próximo a zero;
  3. Finalmente podemos simplesmente aumentar o satélite atual em uma coluna e atualizar a carga dele para levar esse novo atributo. A vantagem é que você mantém o mesmo número de tabelas que existia antes, mas agora seu processo de extração pós-DV precisa saber que esse atributo não vão existir em todas as versões de cada registro do satélite. Impacto para o DV: próximo a zero também.

Repare que o DV tem um impacto na sua atualização, mas esse impacto não se propaga para fora dele: em qualquer um dos casos listados acima, a extração de dados do DV para fontes de dados secundárias não sofre NENHUMA alteração. Mesmo nas opções que mudam as tabelas dos satélites (é indiferente o que acontece aos hubs e links), as alterações vão de nada (ignorar a nova tabela/coluna) a pouca (mudar o nome de uma tabela.)

Veja que se queremos que o novo atributo “saia” para as fontes secundárias, então o impacto vai ser maior.

Lido ao contrário fica:

A incorporação de novas fontes de dados ao Data Vault não perturba os processos de carga das fontes de dados derivadas: o DV pode ser evoluído com um impacto próximo ao desprezível para a carga dos data marts dimensionais, tabelas de painéis etc.

Isolação

Isso é perfeito para DWs que servem mais de um departamento (praticamente todos): mudanças requeridas por um departamento tem impacto desprezível a nulo nos produtos de BI de outros departamentos.

Repetibilidade

Um Cofre de Dados é montado com “pedaços” (tabelas) padronizados. Cada tipo de pedaço – hub, link ou satélite – segue um modelo (um template ou gabarito) e tem um processo de carga idêntico. Para cada nova tabela mudam-se coisas como chaves de negócio ou atributos, mas o processo em si, de desenhar o DV e seu ETL, é 100% repetitivo. Isso significa que criar um novo hub/link/satélite e seu processo de carga é o mesmo que copiar um outro elemento do mesmo tipo já pronto, e mudar os nomes das colunas e tabelas.

Em outras palavras:

O layout das tabelas e o processo de ETL para um Data Vault é 100% baseado em templates. A geração do processo de ETL pode ser automatizada ao ponto de um novo hub/link/satélite poder ser incluído no modelo e colocado em produção em menos de uma hora.

O tempo acima não é um chute: eu brinquei com um sistema real e descobri que consigo criar um hub em menos de 15 minutos, um link em menos de 20 e um satélite em menos de uma hora. O satélite leva muito mais tempo porque tem um número variável de colunas, e isso dá um trabalho extra para testar (a criação mesmo, de todos, é de cinco minutos – o resto é tempo desenho para saber que colunas usar e testar o resultado.)

Performance

O conceito de Data Vault foi feito tendo em mente a idéia de se aproveitar de capacidades de processamento paralelo massivo – MPP. Graças à sua arquiteturua, cada tipo de elemento de um DV podem ser carregados 100% em paralelo: podemos carregar todos os hubs ao mesmo tempo, todos os links ao mesmo tempo e todos os satélites ao mesmo tempo.

Graças a bancos de dados capazes de se espalhar em diversos servidores, e programas de ETL como o Pentaho Data Integration que pode escalonar elasticamente por inúmeras máquinas, o gargalo de carga de um Data Vault passa a ser a própria velocidade de rede e computadores – melhorando esses, reduzimos o tempo de carga

Data Vault 2.0 & BigData

Tudo que este post aborda vem da especificação 1.0 do Data Vault. A especificação do DV 2.0 troca as chaves sequenciais por hashes, o que permite carregar 100% dos elementos em paralelo. Graças à eliminação da dependência de um campo sequencial, um DV 2.0 é adequado para criar DWs diretamente em clusters Hadoop.

A Regra de Ouro do Data Vault

Daniel Linstedt define como a regra de ouro do DV

Carregar 100% dos dados, 100% das vezes

Ele diz, nas apresentações, que chega de chamadas do Centro de Dados de madrugada, avisando que a carga do DW parou. Chega de perder o sono por falhas causadas por dados mal-formatados. Um DV carrega tudo, da forma que vier. Como diz o cowboy, “eu carrego antes e limpo depois”. Bam! Bam! :-)

Conclusão

Sólidos projetos de BI de qualidade constroem-se sobre Armazém de Dados. A melhor tecnologia para construção de um DW é aquela que reduz seu custo e tempo de desenvolvimento, reduz retrabalho e aumenta sua performance.

Data Vault é um modelo de dados criado por Daniel Linstedt em 2000 que atende a todas essas necessidades. A versão 2.0 da especificação traz melhorias que permitem construir um DW diretamente em um cluster Hadoop e com isso baratear ainda mais o processo e a infraestrutura, enquanto aumenta sua performance.

Um Data Vault é o ponto final de um DW, mas um DW é só o ponto de partida para projetos de BI, que devem extrair seus dados do DW, no formato que desejarem, como bem entenderem.

É isso.

A.B.I.M.

Long gone are the years when to have or not a BI Solution (or Decision Support System) was yet an option. A company with choose not to analyze its data today won’t grow beyond a certain point. It has no tomorrow.

To have working BI initiatives is not easy, let alone simple. A sucessfull BI project depends on a lot of factors and to lead one is not a job for the faint of heart. Business Intelligence projects are experience- and knowledge-intensives. Even the customer must control a degree of education to reap the benefits.

A best selling book does not come from anyone armed with a word processor. A new software is not born out of the hands of its final user just because he/she has a point-and-click Java IDE within reach. Business Intelligence Solutions does not either. The whole big world is a complex place with less and less room for amateurs. Go educated or go extinct!

The Agile Manifesto

This was a milestone for the Information Technology Industry. The Agile Manifest broke the shackles tying projects to ever-late schedules in doomed iniatives, and opened up a road of unprecedent success. As a developer and manager I have embraced the A.M. and adopted Scrum as the means to implement AM. I ended using them both to do everything I do, including Teaching and building Business Intelligence projects.

Recently I became aware that, influenced by the A.M., I have brought some of those principles under a BI light, and I am sharing my insights here.

Agile Business Intelligence Manifesto

The highest priority is to help the customer to answer his questions through early and continuous delivery of quality data and tools for its exploration.

Changing requirements are a must because only so data exploration can shape new hypothesys and drive an increase in knowledge.

Deliver working advances on data platforms frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Take part in the customer’s problem: To help the customer answer his questions is to help him formulate them by employing specialized knowledge on tools and techniques.

A customer answering its questions is the primary measure of progress, so he can make new questions.

Conclusion

This list does not stand on itself, but rather extends the Agile Manifesto. It also does not take care of effective delivering the results, which should be achieved by using Scrum and a special, iterative technique for BI projects, soon to be posted here.

Personally I don’t agree that Agile BI is only about tools. It sounds like too little, leaving a lot outside, begining with the very customer.

I didn’t invent the above principles, I more like found them spontaneously sprouted and began guiding my work whilst studying and applying the A.M., Scrum and some other methodologies and strategies to my daily job. The statements I posted above are in fact the Agile Manifest adapted to BI needs as per my point of view. I missed a list like that a lot and as until now nobody made a movent toward them, I did. So, here is my proposal.

What is your opinion?


To my English speaking fellows a note: In Portuguese the generic third person is the male form – he/him/his etc. So when we say “he” as the meaning of “anyone” we also refers to women as well. So, I am not confortable with using “one” or “he/she” when refering to an unknown person, what led me to using “he/him” above in the place of a generic “customer”. Please! I have a lot of intelligent women as friends besides my own wife, and I would never downplay the importance of them! I just wanted to sweep the ethnical differences aside so not to taint the discussion or raise any wrong criticism. Right criticism is welcomed <grin>.

M.I.N.A.

Há anos Inteligência de Negócios deixou de ser uma opção. A empresa que não usa BI, hoje e no futuro, simplesmente não irá crescer além de certo ponto.

Inteligência de Negócios não é fácil, muito menos simples. Um projeto de BI de sucesso depende de muitos fatores, e não é uma tarefa para leigos. Projetos de Inteligência de Negócios são intensivamente dependentes do conhecimento dos gestores, dos desenvolvedores e do cliente. O cliente de um projeto de BI precisa estar educado para poder usufruir dele.

Um best-seller não nasce de qualquer um que disponha de um editor de textos. Um novo software não nasce a partir das mãos de um usuário com um produto point-and-click. Soluções de BI também não. O mundo é um lugar complexo e tem cada vez menos espaço para amadorismo e ignorância. Go educated or go extinct!

Manifesto Ágil

Esse foi um documento que dividiu as águas da indústria de artistas que são os desenvolvedores e criadores das tecnologias de TI, incluindo programadores, projetistas de hardware e software e um sem-número de outros profissionais. Apreender o M.A. quebrou os grilhões dos cronogramas atrasados, dos projetos destinados ao fracasso e me permitiu trilhar caminhos de sucesso sem precedentes.

Meu credo como desenvolvedor e gestor é o Manifesto Ágil, e Scrum é o método que eu adotei para implementá-lo. Eu os uso como ferramentas para tudo que faço, incluindo e especialmente Ensino e Inteligência de Negócios.

Eu descobri que, influenciado pelo M.A., tenho seguido alguns destes princípios para projetos de Inteligência de Negócios, e vim dividi-los com vocês.

Manifesto de Inteligência de Negócios Ágil

A maior prioridade é ajudar o cliente a responder suas perguntas, através da entrega contínua e cedo de dados e interfaces para sua exploração.

Mudanças nos requisitos são obrigatórias porque só assim a exploração cognitiva toma forma e novas hipóteses podem nascer.

Entregar avanços nas plataformas de dados frequentemente, entre semanas e meses, com preferência para o intervalo menor.

A principal medida de sucesso é o cliente encontrar resposta à suas perguntas, para que possa fazer novas perguntas.

Participar do problema do cliente: ajudá-lo a responder suas perguntas para ajudá-lo a formulá-las através do emprego de conhecimento especializado de técnicas e ferramentas.

Conclusão

Essa lista não se sustenta sozinha, mas sim estende o Manifesto Ágil. Ela também não executa o desenvolvimento, isso é feito por Scrum e uma técnica especial para BI, que eu postarei aqui em breve.

Não concordo que Agile BI seja apenas sobre ferramentas. É muito pouco, e deixa muito de fora – a começar pelo clientes.

Eu não inventei esses princípios. Depois de estudar o Manifesto Ágil, Scrum e várias outras técnicas, e aplicá-las ao meu dia-a-dia profissional, eu descobri que esses princípios surgiram espontâneamente e vêm norteando minha prática profissional. Eles são praticamente o Manifesto Ágil adaptado para BI – algo do qual eu sinto uma falta tremenda. Como ninguém ainda propôs nada, eis a minha proposta.

O que você acha?

Review: Pentaho BA Cookbook

Packt Ed. has released on August 2014 a new member of their Cookbook library, by Sérgio Ramazina: Pentaho Business Analytics Cookbook, first edition.

The today aging Pentaho Solutions was the first authoritative source of Pentaho Platform information, but it was far from practical no matter how good. Even those already into the platform had to scratch their heads a little to translate all that knowledge into action. A lot of us simply need much more than was made available. We needed pretty-a-porter how-to’s with which solve our daily paings with each Pentaho Suite component. And that’s the niche Packt has been neatly filling out: they are running into the HUNDREDS of published Cookbooks, on a lot of topics. Yeah, I know, it is starting to sound an unintended pun “we’ve got IT covered.” <chuckles>

This new book covers a lot of the newest Pentaho Suite version (v.5) recipes. Except for PDI (which already featured a dozen Packt books), the book comes into almost everything else: BA Server, Metadata Editor, Schema Workbench, PRD, and some Enterprise Edition operations, besides a bit of C*Tools.

The Good

It is a relativelly complete compendium of everything that deserves atention on the Pentaho Plaform:

  • BA Server: how to set up data sources (JNDI, Analysis, Metadata etc.), how to tie it to an LDAP server and manage users/roles;
  • Metadata: it is the first place to seriously show how to use “concepts”, an importanta metadata ahn… concept. Also, there are a lot of important tips on metadata modeling, like complex join and calculated fields;
  • OLAP: how to create cubes with Schema Workbenche, with calculate members, how to publish it and generate OLAP views with Saiku;
  • PRD: very complete, with recipes to build prompts, sub-reports, charts (including the tricky sparkline), besides having a PDI transformation for report source.

Were it not enough Mr. Ramazinas goes on to show recipes on less searched for things like interface customization and C*Tools (CDE) introduction, always with hands on, detailed examples.

Raising the bar, the book offer recipes on the Pentaho Enterprise Edition. Although Pentaho Community Edition abbility to offer everything the Enterprise Edition does, Enteprise Edition adoption is on the rise and a lot of its resources rest unusedor not fully explored by its customers. Being usefull for the sheer amount and coverage of the recipes, the book becomes even more interesting for the EE recipes it brings:

  • Analyzer: operations with OLAP client;
  • Dashboard Designer: dashboard editing made easy;
  • Interactive Report: ad hoc reporting, the heir to the gone WAQR;
  • Mobile: the inedit iPad and smart phones interface.

More than just helping those with Pentaho EE, the book opens it to those who have not bought it. IMHO, this is an excelent opportunity to get acquainted with Pentaho EE, a high quality yet cheap (very cheap for what it offers!!) versatily BI product.

Also, more than offering an extensive list of how-to’s, Packt’s cookbook format makes it for a very understandable experience for it tells not only how to do each of its recipes, but also why it works and how it does and what else there is to see. Every recipe has at least an image. Even in the grayscale Kindle all of them have a good look.

For its detailed content, its broadness (lots of things on both CE and EE) and its usability, Pentaho BA Cookbook is another must-have volume on the Pentaho Platform practioner library, and even more for a casual dabbler.

The Bad

Ok, the book shines – it is very good, have no question about it. But…

  • Kindle (Touch – my device) version (the one I reviewed) does not stop at the chapters divisions when one sweeps the finger vertically across the screen. Instead it jumps to the beggining. Annoying;
  • Some recipes are too trivial. If the user really needs somebody telling it, then he also needs help on how to setup the software, which the book does not do – and of course not! Recipe books show recipes, now how to cook or who to buy and setup a cooktop;
  • I missed some important recipes, like how to setup BA Server with other databases. There are instructions on how to do that at Pentaho’s Infocenter. However there are some other recipes which have Infocenter how-to’s too, but they’re in the book nonetheless;
  • I missed performance tunning recipes, like setting an external cache or turning on and using aggregated tables;
  • The subjects does not look like well separated. For instance, the schedulling is part of the Pentaho BA Server, but it makes a full chapter in the fartest corner of the book, chapter away from the BA Server chapter. Maybe it would make more sense to have one after another, if not totally made into a single chapter;
  • Plugins: Pentaho Marketplace’s plugins are growing by the day, but the book says little about them. It only briefs mention two of them (Saiku and Logs), besides internationalization.

None of those things diminishes the book value, however.

The… Italian

Packt is a trully global enterprise. Their writers come from all over the world and in fact most of them write in a foreign language – English. Well, Mr. Sérgio Ramazina is itallian and as every good latin (just like me, brazillian), tends to thing in a more literall English. Reading the book you almost can hear his accent in phrasings like “This is the idea that stays behind the concept of(…)” (locus 2028.) The English-born speaker would rather have a simpler “(…) the idea behind the concept(…)” Mr. Ramazina quite used up his quota, but it never impairs the reading. It is kind of easier for me, in fact, because as a Brazillian I also tend to think on that style of English. Maybe it might be stranger for a, say, Japanese reader (as it is a bit awkward for me to read Japanese writers in English.)

Anyway, I just though of making a note so you know what to expect. The book is good and the reading flows ok, just a bit… creatively. <grin>

Conclusion

Have installed Pentaho BA Server 5 and know not where to begin with? Were commited to migrate a legacy 4.8 BI Server to 5? New to Report Designer 5 or banging head against the wall with some JNDI configuration and metadata editing? Wait no further, Packt’s new Pentaho BA Cookbook is your book: a wealth of immediatelly usefull how-to’s (recipes), well layd-out and explained in details. Lots of topics on both the BA Server and its clients, as well as some topics on the Enterprise Edition. Even if it does need some improvent, this is the book to go after for Pentaho Suite 5!

Resenha: Pentaho BA Cookbook

A Editora Packt lançou em agosto de 2014 um novo membro da família de “cookbooks”, por Sérgio Ramazina: Pentaho Business Analytics Cookbook, primeira edição.

O hoje defasado Pentaho Solutions foi a primeira fonte oficial de informações sobre a plataforma, mas ele não era um livro prático, ainda que bom. Mesmo que já conhecia e usava a plataforma precisava bater um pouco a cabeça para aproveitar o conhecimento ali depositado. Muitos de nós precisávamos mais do que aquilo. Nós precisávamos de receitas prontas para resolver os nossos problemas e dificuldades com cada componente da Suite Pentaho. Esse é o nicho que a Editora Packt vem preenchendo diligentemente: já são CENTENAS de “cookbooks” – literalmente “livros de receitas” – cobrindo todo tipo de necessidade de TI.

Neste volume estão cobertas várias receitas a versão 5.0 da Suite Pentaho, hoje a mais nova. Excetuando o PDI, que já tem uma boa meia-dúzia de livros na Packt, ele aborda praticamente tudo o restante: BA Server, Metadata Editor, Schema Workbench, PRD, e algumas operações com a Enterprise Edition além de um pouco de C*Tools.

The Good

É um compêndio relativamente completo de tudo que merece atenção na plataforma:

  • BA Server: como configurar fontes de dados JNDI, integrar com LDAP e gerenciar fontes de dados;
  • Metadados: é o primeiro lugar que mostra como usar “concepts”, além de outras dicas importantes (como criar campos calculados e junções complexas);
  • Schema Workbench: como criar um cubo, como membros calculados e tudo;
  • PRD: muito completo, com receitas para construir relatórios com prompts e sub-relatórios, incluindo o uso de “sparklines”, além de usar transformações do PDI como fontes de dados.

Não bastasse a grande quantidade de receitas, todas úteis, o livro ainda vai além disso e oferece receitas de coisas menos buscadas, como customização da interface e introdução ao CDE (C*Tools) – sempre com exemplo prático.

A obra também traz receitas sobre o Pentaho Enterprise Edition, o que leva seu nível a um outro patamar. Apesar de a versão comunitária ser capaz de oferecer todos recursos, a adoção da EE está crescendo, e muitos recursos ainda restam por ser plenamente utilizados por esses clientes. Se o livro já é útil pela simples qualidade e pela variedade de receitas, ele se torna ainda mais interessante com receitas que cobrem:

  • Analyzer: cliente OLAP;
  • Dashboard Designer: editor de dashboards
  • Interactive Report: para criação de relatórios ad hoc via web (parente do Saiku Reporting e do finado WAQR);
  • Mobile: a interface para iPad e celulares.

Mais do que ajudar quem possui o EE, o livro mostra grandes detalhes do produto a quem não o possui. Na minha opinião isso é excelente, porque dá a chance de conhecer de perto as vantagens do EE – que é um produto de alta qualidade e (muuuuito) baixo custo.

Finalmente, o livro não apenas tem uma lista extensa de como-fazers, mas o formato de livro de receitas da Packt traz a receita em si e explicações de como e porque as coisas acontecem, e orientação sobre que direção seguir para obter mais informações, ou o sobre o que mais há para aprender. Todas as receitas têm ao menos uma figura, e todas as figuras são claras e bem definidas. O formato Kindle (no qual eu li o livro) sempre piora um pouco as imagens, mas mesmo assim ainda ficou muito bom.

Pelo detalhismo do conteúdo, sua amplitude (incluindo muitas coisas de CE e EE) e a usabilidade de todas as receitas, o Pentaho BA Cookbook mostra-se mais um volume indispensável para quem usa a Plataforma Pentaho no seu dia-a-dia, para o estudante eventual e mesmo para o iniciante.

The Bad

Que não reste dúvida: o livro é muito bom e muito útil. Se você precisa aprender sobre a Plataforma Pentaho, versão 5, esse é o livro.

Isto posto, há um bocado de coisas que ainda não estão 100%:

  • A versão Kindle não tem as divisões de capítulo: se você arrastar o dedo na tela, o livro pula para o início ao invés de para o capítulo seguinte/anterior;
  • Algumas das receitas são muito triviais. Se o leitor precisa daquela receita, então ele precisa de ajuda também para instalar os programas, mas o livro não mostra isso (claro: livros de receita não ensinam a comprar fogão e a ligar o fogo!)
  • Senti falta de receitas importantes, como instalar o BA Server CE com outros bancos de dados. Essa orientação existe no Pentaho Infocenter, e por isso talvez não tenha sido incluída. Mas algumas outras coisas existem no Infocenter e mesmo assim entraram no livro;
  • Senti falta de receitas de performance, como instalação de cache externo e aplicação de tabelas pré-agregadas;
  • Há um pouco de mistura de assuntos, e a separação ainda pode ser melhorada. Por exemplo, há um capítulo só com receitas da nova interface do BA Server, bem no início, e um outro com receitas sobre agendamento quase no final. Como é tudo assunto do BA Server, talvez fizesse mais sentido estarem juntas ou no mínimo subsequentes;
  • Plugins: a quantidade de plugins no Pentaho Marketplace vem crescendo a olhos vistos, mas o livro aborda apenas dois plugins (Saiku e Logs), além da internacionalização;

Nenhuma dessas coisas atrapalham o livro, mas elas estão lá (ou não) de qualquer forma.

The… Italian

A Packt é uma editora internacional, verdadeiramente global e seu elenco de escritores reflete isso: eles têm gente literalmente do mundo todo e o fato é que todos precisam escrever em, no mínimo, inglês. Há essa multitude de culturas e línguas forçosamente enquadradas em uma língua (para o autor) estrangeira. Resultado: uma presença maior ou menor de expressões curiosas, atípicas do inglês falado por nativos.

O Sérgio Ramazina é italiano e como bom latino (assim como nós, brasileiros), tende a pensar em inglês mais literalmente. Por exemplo, quase dá para ouvir seu sotaque em expressões como “This is the idea that stays behind the concept of(…)” (locus 2028.) Um nativo escolheria uma frase mais sintética, com outro verbo:  “This is the idea behind the concept of(…)”

O autor meio que esgotou a cota dele desses regionalismos, mas isso não chega a atrapalhar a leitura. Com certeza causam alguma estranheza em quem esteja mais acostumado ao inglês escorreito, mas para mim, latino com o Sérgio, essas expressões são transparentes porque fazem sentido em português. Talvez leitores de outras nacionalidades sintam alguma dificuldade – como quando eu preciso reler trechos escritos por japoneses, por exemplo.

Conclusão

Instalou a versão 5 da suite Pentaho? Migrou e agora precisa fazer o que já fazia? Quer começar com Pentaho, baixou o produto mas agora está em dúvida sobre como realizar cada tarefa?

Então o Pentaho BA Cookbook é o seu livro: rico em receitas úteis, detalhadas e bem explicadas. Ele aborda assuntos variados, todos relevantes, sobre o servidor e alguns dos clientes Pentaho. Ainda que precise de algumas melhorias (e nestas não se incluem as idiossincrasias de autor), e não traga absolutamente tudo que existe (o que seria um exagero de qualquer forma), esse é o livro sobre a versão 5.0!

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

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 86 outros seguidores