O Que É Data Discovery – Interregno

Esta não é a parte dois da série, mas apenas um comentário no meio.

Recentemente foi lançado um livro sobre QlikView. Excelente notícia, já que conhecimento destilado é o combustível do sucesso. Sendo um autor, eu valorizo ainda mais pois sei do trabalho inclemente e ingrato que é escrever um livro. Parabéns ao autor!

O que eu achei interessante, e muito pertinente na discussão em busca da resposta à pergunta “o que é DD?”, é que o site destaca um capítulo como mais importante. Veja na figura:

Conteúdo do livro sobre QlikView.

Conteúdo do livro sobre QlikView.

Viram lá, no capítulo 3? “O segredo” de um app Qlik Sense é (rufem os tambores) a carga dos dados, transformações e modelos.

Hmm… Como é? Li corretamente? O segredo está na preparação dos dados?

Estou sendo chato, eu já sabia disso. Na verdade, esse detalhe sempre foi bem propagandeado: ele usa uma ferramenta interna, tipo linguagem script, para extrair, transformar e carregar em memória os dados. O que a propaganda não reforça é a importância que isso tem: o livro Qlik for Developers explica que quanto mais arrumados os dados estiverem, melhor e mais fáceis serão os resultados.

O presente lançamento reforça isso.

Que conclusão tiramos? Ora, que se você quer explorar seus dados, faça um favor a você mesmo: invista em um DW.

“Ah, mas DW são velharias, é um conceito fracassado, dá muito trabalho e nenhum resultado etc. etc. etc.”

É mesmo? Permita-me e re-frasear: se você não tem um bom modelo de dados, cedo ou tarde vai ter que construir um – seja com uma ferramenta especialista, como ODI ou PDI, seja com uma linguagem script (ai, ai…) Não importa como: no final, são os dados que importam e são eles que terão que ser tratados. Não é a ferramenta, são os dados.

Os dados.

É isso. ;-)

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.

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

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 88 outros seguidores