Base de Treinamento Beltrano S/A

Meu projeto de soluções livres de BI com Pentaho, Open BI Solutions, acabou de receber mais um item: uma base de dados para treinamentos, a Beltrano S/A.

Baixar & Instalar

O pacote é composto por dois dumps PostgreSQL: uma base OLTP e uma base DW. Eles são dumps textuais, scripts SQL, porque assim são compatíveis com outras versões do Postgres e podem ser migrados para outros bancos mais facilmente – se alguém quiser montar a Beltrano em um MySQL, por exemplo. Baixe-os, descompacte-os (anote o diretório no qual deixou-os) e reserve.

Para restaurá-los você precisa ter um Postgres (9.x preferencialmente) instalado. Crie dois bancos vazios, com o nome que você quiser – eu sugiro beltrano_oltp e beltrano_dw. Como são scripts e não dumps binários, você precisa restaurá-los com o comando \i do psql. Siga as instruções neste post do site companheiro e se tiver dúvida poste um comentário aqui.

Essa era a última seção deste post, depois da história, depois da explicação, depois de tudo, que eu movi para cima em respeito ao seu tempo. Eu não me senti confortável em te obrigar a ler tuuuudo só para chegar ao motivo que o trouxe aqui em primeiro lugar.

Beltrano S/A

A Beltrano é uma empresa fictícia, que desenvolve e vende treinamentos.

Ela tem um catálogo de cursos, que são vendidos em turmas. Assim, quando um cliente compra algo, compra vagas em uma turma (e não vagas em um curso) que é de um determinado curso. Se um curso não tem uma turma aberta, então ele (o curso) não pode ser vendido.

Cada vaga (ou lote de vagas) é comprada por um cliente que pode ser PF ou PJ, e é vendida por um empregado da Beltrano. Cada vaga é comercializada por um preço do catálogo, e pode ter ou não um desconto. Cada curso tem um autor, registrado na tabela de empregados.

Modelo Transacional

Eu idealizei a Beltrano como uma empresa que, como tantas outras, cresceu usando uma aplicação doméstica (i.e. construída em casa) para atender suas necessidades. Estes casos, normalmente, contam com algum sistema que registra as vendas em tabelas mais ou menos bagunçadas, um aspecto que eu tentei embutir no banco. A figura a seguir é o diagrama de dados do “Beltrano ERP” (BERP, para os íntimos), desenhado no Power*Architect:

Diagrama da aplicação transacional (OLTP).

As tabelas são mais ou menos auto-explicativas. Os clientes são registrados em uma estrutura um pouco mais complicada, com duas tabelas: cliente_pf e cliente_pj. Eles compartilham a mesma tabela de cidades, que por sua vez se liga a uma tabela de estados. Veja que o estado não é gravado na “ficha” do cliente (a respectiva tabela), apenas a cidade o é. Quem recupera o estado, para mostrar ao operador, é a aplicação. As tabelas de clientes têm ainda algumas diferenças entre si, como por exemplo as colunas cargo e contato, que só existem na tabela cliente_pj.

Modelo Dimensional

Eu apliquei a técnica de modelagem dimensional do Kimball e cheguei a duas estrelas: Pedidos e Vendas. Elas são o embrião do DW da Beltrano, o “BAD” (Beltrano Armazém de Dados, hehe).

Diagrama do Modelo Dimensional.

Observe como a Dimensão Data cumpre mais de um papel na fato Pedidos. Depois repare que a fato Vendas é uma estrela semelhante à Pedidos, mas com um grão mais grosso:

• Grão Pedidos: Custo da Vaga vs. Quantidade de Vagas vs. Desconto vs. Pedido vs. Cliente vs. Turma vs. Curso vs. Data Pedido vs. Data Turma vs. Tipo de Pagamento vs. Empregado
• Grão Vendas: Total Gasto vs. Pedido vs. Cliente vs. Curso vs. Data Pedido vs. Tipo de Pagamento vs. Empregado

No fundo elas são redundantes, já que todas as perguntas que a fato Vendas responde também podem ser respondidas pela fato Pedidos. Lembre-se que esse banco é para treinamento e por isso há um pouco de forçação de barra.

Se você baixar qualquer um desses diagramas, vai ver que algumas tabelas e campos possuem comentários.

Tamanho & Carga de Dados

Minha meta é construir uma base de exemplo com um milhão de pedidos (me sinto o Dr. Evil…) Isso vai tomar um tempo danado processando, por isso eu comecei com um volume menor, beeem menor. Minha primeira versão tinha 100 pedidos, a segunda 1.000 e a atual tem 10.000 pedidos. Isso se traduz em mais ou menos 50.000 linhas na tabela pedidos_detalhes, e na mesma quantidade de fatos da tabela f_pedidos. Meu próximo passo será – adivinhem! – chegar em 100.000 pedidos.

Meu projeto para gerar um milhão de pedidos envolve montar um cluster de máquinas (eu tenho quatro computadores em casa) para processar tudo. A maior dificuldade, porém, não é máquina, mas sim providenciar um volume de nomes e endereços aleatórios tal que eu tenha um número razoável de clientes fazendo esses pedidos, ao longo de um tempo interessante. Cinquenta mil clientes PF e uns 5.000 PJs, ao longo de 10 anos é um número razoável, porque dá uma média de 1,8 pedidos por cliente, por ano. Isso dá quase dois cursos por ano, o que é algo bem verossímel.

Eu também quero balancear os pedidos. Por exemplo, quero que empresas sejam clientes dez vezes mais assíduos que PFs, e que as PFs não façam mais que 3 pedidos de uma vaga por ano. Coisas assim dificultam o projeto de carga, que é feito em PDI (figura abaixo.)

Job PDI que carrega base Beltrano OLTP.

Isso vai acabar dando um outro post, sobre clusters com PDI, e depois, quem sabe, um sobre Hadoop.

História

Eu desenvolvi o primeiro material de Pentaho para um ciclo de oficinas em um CONISLI, em 2008. Foi uma correria, mas eu tirei lições importantes dessa experiência. Uma delas foi entender que as oficinas, para ser efetivas, teriam que ter uma mensagem clara. O assunto é muito extenso, e pode ser bem profundo também, e por isso eu precisava estabelecer um objetivo claro, com um perímetro bem delineado. No final eu concluí que eu queria que o aluno:

• Ganhasse uma visão de ponta-a-ponta, que ele entendesse que poderia popular um DW, criar um relatório e explorar cubos OLAP com o Pentaho;
• Aprendesse o básico: como instalar e rodar cada programa, como criar, salvar e rodar cada artefato;
• Aprendesse as operações mais importantes de cada ferramenta: dimensionamento para ETL, grupos e gráficos nos relatórios, criar um cubo OLAP completo, fazer um metamodelo com qualquer base.

Acho essa que foi a tarefa mais difícil no desenvolvimento daquelas oficinas.

Eu não teria tempo para ensinar as coisas mais simples, em todos seus detalhes, e por isso eu apostei na idéia de que, ao focar em operações importantes, ainda que complexas, e levá-los passo-a-passo através das dificuldades, eles acabariam preenchendo as lacunas sozinhos. Deu certo, e no final eu aprendi quais pontos precisavam de mais explicação, e quais poderiam ser ignorados.

Para os exercícios práticos eu precisava de uma base de dados, que fosse simples mas completa e fácil de entender. Um amigo rascunhou um modelo de dados para mim, preencheu todas as tabelas com algumas linhas (tinha só 90 clientes e nem 1000 pedidos!) e me deu de presente. Bingo! A base era pequena, simples e completa – tão completa que nem tinha erros nos dados.

BI com Pentaho pela 4Linux

Pouco tempo depois a 4Linux me procurou, para me contratar para elaborar um treinamento para eles. A coisa ficou bem séria: não bastava mais tirar umas dúvidas, ou dar uns exemplos. Se eu assinasse o contrato, eu precisaria criar algo que garantisse o aprendizado dos clientes da 4Linux, além de uma apostila beeem caprichada. Eu fui em frente e assinei com eles. Quatro meses depois marcaram a primeira turma, e o material estava ainda pela metade. Eu tinha os slides, os dois DVDs com máquinas virtuais, exemplos e artefatos, mas a apostila ainda não estava pronta. Eu escrevia freneticamente à noite, mas não foi o bastante e assim eu comecei a primeira turma com o material ainda em produção. Faltava pouco, mas eu precisei trabalhar quase around the clock, indo dormir à uma, duas da manhã, para levantar às 6H00min e continuar. Como a turma leva duas semanas, no final-de-semana eu dei um sprint final e completei a apostila, de modo que no início da segunda semana os alunos receberam a primeira versão dela.

Depois que o curso acabou eu dormi as 4h mais tranquilas da minha vida (meu primeiro filho tinha uns seis meses, de modo que nunca dormia muito, mesmo – hehe.)

Pentaho na Prática

Quando o livro Pentaho na Prática se firmou na minha cabeça, eu vi que aquela base não seria o suficiente para minhas pretensões, e decidi que era hora de tirar o pó de um antigo projeto – a base de treinamento. E foi o que eu fiz: antes de começar a escrever o livro eu repensei toda aquela base e fiz meu dever de casa:

• Defini meu caso de negócio: escolhi um ramo e um nome para empresa (mentira: o nome veio no fim, quase na hora de lançar o livro);
• Criei um diagrama em Power*Architect, com os objetivos de simplicidade e um leve amadorismo em mente;
• Desenhei as transformações que carregavam cada tabela (empregados, clientes, pedidos, produtos etc.);
• Amarrei tudo em um job, parametrizado pelo número de pedidos;
• Consegui uma lista de cidades e estados do Brasil;
• E finalmente montei listas de dados de apoio, como nomes de pessoas, endereços etc.

Apesar de não ser uma parametrização muito firme, ela era o bastante para trabalhar. Primeiro montei uma base com 100 – cem cliente, cem pedidos etc. Vi que o conceito funcionava e ampliei minhas listas para 1000 pedidos. Nisso precisei criar nomes de cursos (não dava para gerar aleatoriamente, como eu fazia com os nomes de clientes e endereços), nomes de instrutores, montei um quadro de empregados para a empresa etc. etc. etc. (Nossa, estou abusando do et coetera… mas tinha detalhe pra chuchu; daria até para escrever um outro livro, pequeno, sobre a história desse banco – teve até mapa mental!!!)

Finalmente o processo começou a operar, mais ou menos bem. Demorava bastante para carregar porque eu iterei uma transformação pelo número de pedidos, e isso é um overhead e tanto – repetir mil vezes a mesma transformação, que até era pequena, consumia coisa de duas horas.

Beleza, quase lá! Mil pedidos (com 1000 clientes PF e 1000 PJ) era pouco. O legal seria ter 100.000 pedidos, pelo menos, ou um milhão – aí sim, seria do balacobaco! Fiz alguns ajustes: mudei o número de clientes PF para 5000 e mantive os PJs em 1000, pois eu queria que a base refletisse a idéia de que há mais pessoas que empresas. Incrementei as listas de nomes e endereços para poder gerar 6000 nomes e endereços únicos (ou a chave primária das tabelas de PF e PJ seria violada), sem precisar me preocupar em checar repetições (o que tornaria as transformações mais complicadas.)

Cometi só um erro: criei poucos cursos. Deveria ter criado uns 20, 30, mas eu esqueci desse detalhe e rodei a carga de 10.000 pedidos com uns 10 cursos. Eu poderia ter adicionado mais e reiniciado o processo, mas neste ponto o livro estava parado, esperando a base, que tinha levado dois fins-de-semana para completar. No primeiro deu pau ai pela metade e eu descobri alguns bugs, depois de vários pequenos detalhes que eu ainda ajustei, coisas que eu precisei mudar e por aí foi. No segundo final-de-semana eu botei meu micro para rodar na sexta-feira à noite, planejando desligá-lo na manhã do sábado. Veio o sábado, foi-se o sábado, começou o domingo… Bom, encurtando: deu pau algumas vezes e eu precisei restartar na mão, adaptando as transformações para começar do pedido seguinte ao último antes da interrupção anterior e teria sido uma perda muito grande de tempo reiniciar só para colocar mais cursos.

Finalmente, a base ficou pronta e pudemos acabar o livro. Ufa! Depois de todo esse trabalho, teria sido um desperdício jogar a Beltrano fora, ou mantê-la apenas para nós, ainda mais quando nós mesmos chegamos onde chegamos graças ao compartilhamento de idéias e softwares.

Resolvemos abrir, e o resto é história.

Até a próxima!

O que é Business Analytics

Na minha cabeça, todo bom trabalho começa com um bom entendimento do problema. Se isso sair errado, todo restante fica comprometido.

Comecei a ler o Mondrian in Action. Passei o prefácio, introdução, blá, blá, blá e cheguei no capítulo 1. Primeira sentença:

Business analytics is a process for gaining insight into business performance based on the analysis of historical data.

Caraca, isso é gênio puro! Eu sonho em um dia poder começar um trabalho escrevendo uma coisa tão simples, concisa e precisa! Nunca mais eu vou gastar minutos explicando o qué análise de negócios (ainda não achei uma boa tradução para Business Analytics). A partir de hoje eu só vou dizer:

Análises de Negócios (BA) é o processo de obter percepções acerca do estado dos negócios baseado na análise de dados históricos.

Mondrian in Action, 2013

De uma só tacada ele envolve o rendimento e o estado (performance) dos negócios com temporalidade (dados históricos) e a busca de conhecimento (análises.)

Eu não sabia o que era BA. Agora eu sei.

Data Vault Para Quê?

Quem me acompanha aqui no GeekBI viu meus posts sobre DV e sabe que eu sofro de uma grave insegurança acerca da hamletiana questão DV or Not DV. Bom, eu sofria.

Todo DW Deve Usar DV

Mas todo mesmo??? Não, nem todos. Ele não é necessário se seu DW é de testes, sua empresa é muito pequena (só tem dois departamentos e faz controle de pedidos em Excel) etc. Caso contrário, sim, todo DW deve usar DV, e meu objetivo hoje é tentar explicar porquê.

(In)Definição funcional de DW

Ok, de novo: o que é um DW? A definição clássica do Bill Inmon é:

Um armazém de dados é uma coleção de dados não-voláteis, historiados, integrados e orientados por assunto para suporte do processo decisório dos gestores.
A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process.

Bill Inmon

Existe uma outra, mas ela não é declarada explicitamente. Ela é advogada por Ralph Kimball e pode ser escrita mais ou menos assim:

O Data Warehouse Corporativo é a coleção de Data Marts integrados através do barramento corporativo de dados.

Ralph Kimball

Uma coisa interessante sobre a definição do Kimball é que ele estressa o fato de que o DW é uma ferramenta de análise de dados. Seu modelo dimensional é tão adequado a isso que o próprio Bill Inmon escreveu, em 2000, que se ele precisasse desenhar um Data Mart, ele não consideraria usar outra coisa que não um Modelo Dimensional (Star Schema – The Complete Reference, Christopher Adamson, Inmon’s Corporate Information Factory, p. 18.)

Já a definição do Inmon vai no sentido oposto: o DW acumula os dados, mas não deve ser consultado pelo cliente. Para consultas, Data Marts devem ser populados a partir do DW.

Necessidade de Dados para BI

Existem duas necessidades de dados para Inteligência de Negócios que são atendidas por DWs.

Armazenamento

Se uma empresa decide armazenar dados sobre seus processos e operações, ela deveria armazenar a maior quantidade possível, com o maior detalhamento possível. Afinal, o que hoje não é importante pode sê-lo amanhã. Se a empresa armazena apenas o que entende importante hoje, ela pode sentir falta de algo no futuro. Claro, essa lacuna sempre pode ser preenchida daquele momento em diante, mas o passado – com todo seu valor – terá sido perdido.

• Do tamanho da empresa;
• Tudo que já existiu;
• Sempre aumenta.

Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!

Análise

Uma vez que o dado foi resgatado das entranhas dos sistemas transacionais e separados, podemos analisá-los – responder perguntas de negócio, estimar, prever e extrapolar tendências. Dados brutos raramente entregam algum conhecimento, e por isso é necessário “massagear” os dados até que eles ofereçam alguma interpretação possível. Isso é tão importante que, depois de décadas ocultos em projetos de Data Mining, estatísticos, matemáticos e físicos estão ganhando notoriedade com a invenção da buzz word Data Scientist (Cientista de Dados – como se algum cientista não lidasse com dados, hehe.)

• Do tamanho de pessoas;
• Só o relevante;
• Renova-se.

Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.

Armazéns de dados usados para análise

Pausa para epifania:

O que acontece se você tenta criar um Data Warehouse Corporativo (EDW) para análise?

Se você tentar forçar todos os dados da empresa em um formato adequado ao “consumo” por analistas terá um DW que:

• É do tamanho da empresa;
• É usado por pessoas;
• Acumula tudo;
• Expõe tudo;
• É consumido em partes.

Resposta: ele não seria nem uma coisa, nem outra.

Armazém + Supermercado = WTF???

Olhem as figuras: elas mostram como é um armazém puro, como é um supermercado, e como fica um armazém quando você dá para o cliente um carrinho de compras e diz “se vira aí.” Podemos descrever essa situação como “atacado no varejo” – uma antítese, uma definição contraditória.

Model Wars

E é por isso que você precisa de um Data Vault: para armazenar seus dados corporativos crús, de maneira integrada e acumulativa, sem compromissos quanto ao volume, à taxa de armazenagem ou ao conteúdo. Caso contrário, se você arquivar seus dados em outro modelo, você vai acabar em um beco sem saída.

O DW foi “inventado” (descrito formalmente pela primeira vez acho que é mais o termo) por Bill Inmon, que propôs um modelo de dados para montar um DW.

Corporate Information Factory

Visão da arquitetura típica de um CIF.

Uma CIF, ou Fábrica Corporativa de Informações, é um banco dados e processos de ETL associados com algumas características particulares:

• O modelo de dados é na 3NF (3a Forma Normal);
• O dado é armazenado integrado e limpo;
• Sem acesso direto do cliente ao dados do DW;
• O consumo de dados pelo cliente é feito por Data Marts Dimensionais, derivados da CIF.

Era uma idéia natural, dado que a 3NF é uma maneira eficiente de se guardar dados relacionados entre si. Só que ele tem alguns problemas:

• O dado gravado no DW não é o mesmo que existe no sistema de origem;
• A 3NF é um modelo de dados muito bom para aplicações transacionais, mas muito ruim para DW por que é um método complexo e difícil, especialmente se precisar ser extendido;
• Apesar de Inmon afirmar o contrário, CIFs tem grande custo/demora inicial, manutenção complexa
• Para esses dias de Scrum, CIFs não são uma arquitetura apta a ser “agilizada”.

Dimensional Enterprise Data Warehouse

Como dito no começo deste post, Ralph Kimball advoga algo que agora podemos chamar de “atacado no varejo”:

• O EDW é uma coleção de Data Marts (assuntos), que são “estrelas” Fato-Dimensão;
• A integração dos dados é feito via barramento de dimensões;
• O dado é armazenado integrado e limpo;
• O cliente final tem acesso direto ao EDW, normalmente por alguma ferramenta gráfica, como Microstrategy ou PIR/Analyzer.

O Barramento Dimensional Corporativo (interpretação artística acima e exemplo de documentação abaixo.)

Ele resolveu muitas dificuldades da CIF:

• Modelo dimensional é resiliente e flexível:
  • Acomoda mudanças de negócio;
  • Bom para análise por pessoas;
  • Bom para armazenamento por bancos;
• Projeto modular, bottom-up
  • Começa pequeno e cresce organicamente;
  • Manutenção simples;
  • Apto a ser “agilizado”.

Mas mesmo assim ainda tem suas fraquezas:

• Assim como na CIF, o dado gravado não é o mesmo que existe no sistema de origem;
• O modelo de dados depende do processo de negócio e do entendimento deste processo (pelo cliente ou pelo desenvolvedor). Se o negócio ou seu entendimento muda, o modelo precisa mudar junto;
• Mesmo sendo resiliente, essa resiliência tem limite;
• Mesmo sendo bom para integrar dados, a integração depende de dimensões comuns que nem sempre existem, o que causa aumento de dimensões “iguais mas diferentes”.

CIF x EDW-D

Além de suas limitações particulares, ambos tem algumas fraquezas intrínsecas:

• Dado é mascarado: ele é alterado e depois carregado;
• ETL frágil: pode parar por “dado ruim” e re-início é complexo;
• ETL pode ficar pesado e afetar janela de tempo.

Truco!

E agora? A proposta de Inmon é complexa e tende a matar o EDW sob seu próprio peso. A do Kimball espana em projetos grandes demais – e nos dias de hoje, grande demais é o novo médio. Não que eles sejam totalmente inadequados. As abordagens CIF e EDW-D respondem muito bem, até, para uma boa gama de problemas e necessidades. Elas apenas têm limitações que tornam tudo mais difícil (mas apenas em poucos casos impossíveis.)

Apresentando Daniel Linstedt & Seu Maravilhoso Data Vault

O cara é uma figura. Assista o vídeo dele aqui. Eu tomei contato com suas idéias através do Kettle Solutions, mas se eu tivesse assistido o vídeo antes, eu nem teria lido o material – sério. Tudo que ele faz – palestra, vídeo, aula etc. – parece coisa de Shop Time!!! Mas não compre ainda! Se você adotar Data Vault e adquirir o divertidíssimo curso on-line Mega-Promo, você ainda ganha uma fantástica empresa altamente produtiva!!

O fato é que a metodologia/técnica/teoria/coisa que ele inventou resolve todos esses problemas, muito bem. Claro que ela também tem suas limitações, mas até as limitações são coisas complicadas de se entender, de tão eficiente que DV é.

Eu sabia disso – eu consegui entender que DV é o modelo de dados ideal para uma CIF, que depois popula Data Marts dimensionais usados pelos clientes. Essa não era a minha dúvida. O problema era outro.

Como é que mais Trabalho…

Quando implementamos um DV, dobramos o tamanho do EDW.

Arquitetura do EDW Dimensional típico.

Em um Data Warehouse Corporativo Dimensional temos um processo de ETL que lê das origens e grava em um modelo de dados dimensional, a partir do qual a bancada de exploração é montada. Quando incluímos um Data Vault na jogada, não nos livramos do ETL dimensional, mas tão somente o alteramos:

Arquitetura de um EDW extendida com um Data Vault entre as fontes e os Data Marts.

Louco, voces estão pensando, mas vocês já sabiam disso, não é?

…dá menos Trabalho?

Simples: tornando viável o impossível, e o difícil, fácil.

Quais são os maiores problemas de uma CIF? Modelo de dados e evolução complexas. Se você optou pela CIF no seu EDW, um DV te dá um modelo de dados simples, de evolução muito fácil.

Quais são os maiores problemas de um EDW Dimensional? As mudanças: sempre que o cliente pede algo novo, como incluir uma nova fonte de dados, não apenas o modelo de dados precisa passar por uma revisão e eventual ajuste, mas o processo de ETL também precisa ser revisto.

A Minha Experiência

Atualmente estou envolvido em um projeto de DW relativamente simples: municiar o cliente com cubos OLAP para que ele possa monitorar o desempenho da área em suas atividades. Temos só duas fontes de dados, mas em breve uma delas será desativada e tudo ficará na outra. Logo, nada muito complexo.

Adotamos uma gestão de projetos Scrum, que se baseia em iterações curtas (algumas semanas) para entrega de uma lista de objetivos reduzidos, previamente combinados com o usuário.

Não tenho nenhum problema em nenhum aspecto do projeto: ambientes ok, ferramentas ok, equipe nota 10, cliente fantástico. É o projeto dos sonhos de qualquer um – meu, inclusive.

Só tenho uma dificuldade: o modelo de dados. De tanto eu pestear meus chefes na empresa em que trabalho, eles me deixaram modelar o DW (ou Data Mart, melhor dizendo, já que há muita coisa da empresa que não entra nesse banco) e desenvolver o ETL, que eu comecei a fazer da forma que eu sempre disse que deveria ser feita.

Provei do meu próprio remédio – ele é muito bom, mas tem efeitos colaterais perigosos.

Métricas Misturadas

Espanei logo na primeira estrela.

Fiz tudo de acordo com o figurino: eu escolhi o processo de negócio e o grão, as métricas e as dimensões. Mas eu não fiquei satisfeito e refiz. Ficou ruim e refiz de novo. Voltei ao primeiro arranjo, mudei de novo, tentei outra coisa… Não conseguia chegar a um acordo sobre as métricas. Elas ficavam… estranhas, acho.

No dia seguinte, descansado, eu me toquei do que acontecera. A métrica que o processo de negócio comportava não era a métrica que o cliente queria explorar. Ora, que tolinho, dei mancada de amador, pensei eu.

Há!

Grão Grilado

Voltei ao início e ajustei a definição do processo de negócio para incluir mais coisas, e daí o grão, as métricas e as dimensões. Ficou melhor, mas ainda não resolveu. O novo entendimento sobre o processo de negócio que meu cliente queria analisar ainda não era suficiente. Pensando sobre o caso eu vi que, se ampliasse e ampliasse, até encampar tudo, o modelo ficaria estropiado.

Eu já estava há quase uma semana desenhando e redesenhando o modelo, testando alguns protótipos. Minha expectativa era fazer um ou dois protótipos, refinar meu entendimento do problema, do sistema de origem e da necessidade do cliente, e então jogá-los fora e redesenhar certo.

Aconteceu isso, mas não como eu esperava. Eu não convergia, não conseguia achar o “corte” do negócio que desse o que o cliente pedia.

Supernova

Sabem quando acende aquela lâmpada na cabeça do Patolino? Bom, sobre a minha cabeça acendeu uma supernova – foi o tal momento da epifania que eu descrevi acima. De repente ficou claro que eu não conseguia achar o corte certo porque simplesmente não existia corte certo. Era como se eu estivesse tentando temperar e fritar filé mignon para conseguir hambúrguer com fritas (com pão, queijo, tomate e maionese, tudo.) O cliente precisava de uma “visão” dos dados que não era disponível em um só processo de negócio. Eu ainda não tenho certeza se entendi bem o porque disso – se é um grande processo com várias etapas, ou se a análise do cliente é muito alto nível – mas o fato é que eu consegui andar quando eu quebrei os dados nos vários processos de negócio. Cada um passou a trazer um pouco do que o cliente queria, como uma fato atômica (sem divisão, mínima ou essencial.) Daí eu pude determinar os grãos, dimensões e métricas das várias estrelas necessárias. No final, eu desenhei uma estrela “Análise” que reunia as métricas contra as dimensões pedidas pelo cliente.

Hoje, meu processo de ETL tem três etapas:

• Atualização das dimensões;
• Carga dos novos fatos “atômicos”;
• Carga da estrela Análise a partir das estrelas atômicas.

Ou seja, de uma forma ou de outra, eu acabei estabelecendo um Data Warehouse que acumula os dados, e uma estrela para análise, como um Data Mart.

Lixo, Lixo, Lixo

Esse projeto lidava com um tipo de sistema de origem que eu nunca havia trabalhado. Eu brinquei um tempo com vendas (usando a base de dados que evoluiria para a Beltrano S/A), algumas coisas com finanças e um projeto para uma empresa de telefonia, além de todos os outros que eu conheci, que envolviam banco, marketing, televisão etc. O sistema de origem desse projeto é um software de gestão de projeto, completo, com tudo, inclusive a pia da cozinha.

Eu não conhecia os tipos de fato necessário, e tinha só uma idéia do que seriam as dimensões. Por isso eu liguei para um grande amigo, dono de uma empresa de consultoria e treinametno em DW (ele cursou os treinamento do Kimball Group com o Kimball em pessoa) e discuti algumas idéias com ele. Melhor dizendo: admiti que estava perdido e não sabia por onde começar e ele me deu um caminho, que funcinou perfeitamente.

Mas houve uma consequência engraçada: uma das fatos era do tipo snapshot (foto), e acumula dados sobre projetos – coisas como data, cliente, líder, departamento etc. Um dos atributos dessa fato era o ID do projeto, que tipicamente vira uma dimensão degenerada. Outros dois eram o título do projeto e a descrição. Claro que daria para fazer uma dimensão Projeto para guardar esse campos, mas haviam vários outros atributos textuais que se ligavam aos dados de projeto, como estado, tipo de projeto, tipo de processo etc. Como essas coisas evoluem ao longo do tempo – não, pior: vão e vem, avançam de estado e retrocedem para depois avançar de novo, sem padrão – montar uma dimensão seria uma péssima idéia, porque ela cresceria com a fato.

Eu poderia adicionar os atributos diretamente na fato, degenerando tudo e mantendo coisas como empregados, departamentos e datas em dimensões regulares. Só que adicionar campos de texto à fato é garantia de destruir a performance. A tabela em questão é pequena, e cresce à taxa de milhares de linhas por dia, ou seja, quase nada. Mas há outras fatos do mesmo tipo (cheia de atributos textuais), uma das quais crescendo à (por enquanto) +30.000 linhas/dia.

A solução recomendanda por meu amigo, e que eu acatei, foi levar esses atributos para uma dimensão Junk (“lixo”), que eu acabei por fazer uma para cada atributo ou no máximo par de atributos (como título e descrição.) No final eu acabei com uma Junk Dimension Título, uma Junk Dimension Tipo, uma Junk Dimension Estado e assim por diante.

A minha estrela de acumulação estava ficando cheia de atributos descritivos que nunca entrariam em um barramento dimensional corporativo, que lembrava cada vez mais um arranjo hub-link-satellite (os elementos de um DV.)

Re-Retrabalho

Depois dos percalços iniciais eu consegui divisar um padrão no modelo dimensional e dividir com a equipe, para que mais gente pudesse entrar no projeto que até então estava inteiramente comigo.

Conforme o modelo foi ganhando forma, as extrações sendo desenhadas e o resultado apresentado ao cliente (Scrum, lembre-se), o cliente foi entendendo melhor sua necessidade e pedindo mudanças, sempre dentro das restrições impostas pelo Scrum. Mesmo assim, o modelo precisou ganhar uma fato que inicialmente não se acreditava necessário, redesenhar a dimensão Empregado pelo menos uma vez, sem contar os ajustes (além de mais duas mudanças programadas para breve), alterar algumas regras e adicionar vários filtros e correções para dados mal-comportados.

Bom, o suco da história é que o modelo ainda está crescendo (normal), mas também mudando o que já foi feito (anormal). Quero dizer, não é anormal mudar, mas não deveria ser comum precisar rever coisas demais. O ritmo de mudanças em coisas estabelecidas está caindo e deve tender a zero…

… mas e se não? E todas as vezes que precisamos truncar o histórico já acumulado para poder implementar um conceito refinado, uma regra revista? E quantas vezes mais isso vai acontecer?

DV To The Rescue!

Falo baseado em minha intuição, claro, mas estou certo que teria tido menos dificuldades iniciais e o impacto do retrabalho teria sido menor se eu tivesse adotado um DV desde o início. Coisas que teriam sido melhor incluem:

• Início rápido: como os elementos do DV têm regras claras, nas duas primeiras semanas eu já teria colocado no ar no mínimo os cubos (minha tradução para hubs, como cubos de roda), elos (links) e satélites necessários para a primeira visão do cliente;
• Histórico mais cedo: nas duas semanas seguintes, enquanto a carga do DV seguisse acumulando dados em produção, acredito que teria conseguido um modelo dimensional e uma extração para levar os poucos dados já no DV para uma estrela de análise, útil ao meu cliente;
• Menos retrabalho: se eu notasse falta de algo no DV, em menos de uma hora eu conseguiria adicionar esse pedaço em produção, para seguir desenhando o Dimensional;
• ETL simplificado para o DV: como eu uso o PDI, meu trabalho é medido com a dificuldade de construir uma transformação para fazer algo. O DV usa transformações-padrão para cubos (são sempre as mesmas, basta mudar os nomes da tabela e da chave), um gabarito (template) para elos e outro para os satélites (não há padrão xerocável, mas há um padrão de processo de desenvolvimento). Essas transformações são muito mais simples que as necessárias para carregar uma dimensão e mais simples ainda que uma que carrega fatos;
• ETL simplificado para os Data Marts Dimensionais: ao contrário da situação em que o EDW Dimensional é carregado a partir do sistema de origem, agora ele seria carregado a partir do DV. As transformações que geram dimensões a partir do DV são praticamente padronizadas. É só copiar, colar e alterar o que for preciso – o processo muda pouco. A transformação para fato ainda serão mais complexas que para as dimensões, mas, de novo, por contar com uma fonte padronizada (o DV), ficariam mais simples e mais padronizadas;
• Preservação do histórico: se for preciso refazer algo do dimensional, eu poderia jogar fora o modelo dimensional inteiro se fosse preciso, sem me preocupar em perder nenhum dos dados acumulados até então. Seria possível incluir no DV até mesmo coisas ainda não necessárias, e no futuro dispor imediatamente do histórico inteiro em novos Data Marts.

Conclusão

Como Bill Inmon propôs, ao definir um DW, um Data Warehouse é um depósito de dados corporativos, que acumula tudo que possa ser importante para a empresa, e os clientes da corporação que precisarem analisar esses dados devem fazê-los a partir de data marts preparados para tal. Ralph Kimball patronizou a popularização do BI através do desenvolvimento da Modelagem Dimensional.
Finalmente, Daniel Linstedt completou a visão de Bill Inmon com a criação da metodologia Data Vault.

Pelas implicações práticas e lógicas, e a partir da experiência que estou passando, afirmo que um Data Vault é uma necessidade de todo EDW porque torna possível o crescimento suave, progressivo do DW, simplificando o desenvolvimento dos processos e sua gestão.

Espero ter trazido alguma novidade ao compartilhar aqui minha experiência e minha percepção do problema de criar e evoluir um DW em uma empresa. Apreciaria muito ouvir/ler críticas, dúvidas e sugestões.

Mondrian in Action

Como dizem em inglês, I’m a sucker for new books. Eu recebi um código promocional da Pentaho para compra do novo livro sobre Mondrian, o Mondrian in Action e caí dentro!

Capa do livro

A entrevista dos autores foi decisiva para comprá-lo sem avaliá-lo antes:

2. What is the main goal if the book? What do you aim to bring across?

Bill:  I wanted to create a single resource that people can turn to answer their questions about Mondrian.  This includes understanding how it is used by organizations to analyze their business data, how it is used by various tools, such as Pentaho Analyzer and Reporting, and how to integrate Mondrian into a user’s application.

Nick: The goal of the book was to bring together practical knowledge, from 3 of the top practitioners who have worked with Mondrian at over a hundred customers.  The mix of skills between the 3 authors meant we got diverse topics to make a comprehensive and practical book.  Julian is the code expert, Bill knows the integration/Pentaho aspects, and I have extensive customer modeling/configuration experience.  Readers should benefit from our varied experience with Mondrian!

5. What’s next?

(…)Julian: First of all, I am working on the next Mondrian release. There are lots of new features and architectural improvements, most of which are described in the book. The whole Mondrian dev team is really excited to get it to market.

Agora, ler! Como eu comprei a versão eletrônica, ela já está aqui – tanto que a imagem da capa foi tirada diretamente da minha cópia, na minha máquina. Postarei minha opinião assim que formá-la, mas dificilmente vai ser alguma coisa que não “muito bom!”