Agile BI?

Em agosto de 2005 eu lancei um mini-curso sobre como fazer levantamento de requisitos para projetos de Business Intelligence. O que diferenciava aquele curso da prática tradicional era ser voltado para projetos ágeis. Você pode ver aquele post clicando aqui, conhecer o curso aqui e assistir ao vídeo promocional seguindo este link.

O assunto é interessante por demais da conta. Nestes dois últimos anos eu tenho me dedicado a estudar como melhorar a implementação de projetos de BI e DW usando técnicas ágeis. Tenho visitado palestras, lido artigos pela web, conversado com inúmeros profissionais. O resultado desse envolvimento todo apareceu na minha palestra do Pentaho Day 2017, BI E.V.A., que teve uma boa recepção junto à comunidade Pentaho.

Hoje eu recebi um e-mail da TDWI, um respeitado instituto de Data Warehousing. O assunto? É óbvio, né?

Agile BI.

E-mail do TDWI convidando para um curso de Agile BI.

Claro que eu tinha que ver do que se tratava. Eis o conteúdo prometido:

  • Agile modeling values and principles
  • Techniques for determining the right level of up-front design
  • How to avoid overbuilding solutions by designing for what is needed
  • Domain modeling
  • Data model patterns
  • Data smells and the impact of technical debt
  • Continuous integration
  • Safe refactoring techniques for making incremental design changes
  • How to determine the right level of design documentation that is needed
  • Effective collaborative modeling practices for cross-functional teams
  • How to minimize the amount of unnecessary rework through reference and conceptual designs
  • How to establish iteration zero as an agile practice that gives teams the runway to start delivering

Hmm… Interessante. Uma das coisas que eu comento no BI E.V.A. é que há muito sendo discutido sobre como se transformar o processo de modelagem de dados, em especial Modelagem Dimensional, em um processo “ágil”. No fundo, o que muito da literatura tem pregado é como incorporar Scrum ao processo tradicional.

Eu já fiz isso, e não adianta.

Pense um pouco: o cerne de ser ágil é prover melhoria contínua. Mas o cerne de um processo de modelagem dimensional é entender a necessidade do cliente. Não é muito evidente, mas o fato é que essas motivações são incompatíveis. Ainda não tenho um argumento finalizado e por enquanto eu recomendo a leitura das notas da apresentação BI E.V.A. – é o melhor que eu consigo no estágio atual.

Ainda não é uma Conclusão

Voltando ao curso do TDWI, o que é que eles oferecem? Uma outra abordagem ao processo de modelagem de dados? Não.

Um outro modelo de dados? Não.

Uma outra forma de tratar os levantamentos de requisito? Não. (Meu curso faz isso.)

Eles propõe “modelar apenas o suficiente para galvanizar o cliente e desenvolvedores ao redor de uma compreensão compartilhada do domínio do problema, arquitetura e modelo de dados”.

Ou seja: adotemos ágil e, na hora de construir o modelo de dados, vamos fazer apenas o mínimo para começar. Do que se depreende que desenvolvimento incremental, aqui, deve ser “uma dimensão por história”, “uma estrela por épico” ou coisa do tipo!

Foi exatamente o que eu tentei. Deu resultado, mas ainda não me permitiu os fantásticos ganhos de produtividade que Scrum normalmente proporciona. Leia “Scrum: a arte de fazer o dobro do trabalho na metade do tempo” para saber do que é que eu estou falando. ;-)

Ganhos fantásticos!

O que eu acabei descobrindo é que o que atrapalha o desenvolvimento ágil – incremental – é a dificuldade de expressar a necessidade do cliente de modo que permita correções e ajustes, o que acabou me levando a rever o problema por outro ângulo.

Então este é o estado do BI Ágil, hoje?

Claro, existe mais sendo feito por aí. Quem leu o Building a Scalable Data Warehouse with Data Vault 2.0, por exemplo, viu uma outra abordagem. Mas ainda não nasceu algo que verdadeiramente habilite a construção de projetos de BI e DW calcados nos fundamentos ágeis – melhoria contínua, incremental, articulada.

A busca continua! :-)

Anúncios

A Culpa é do Cubo!

Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…

Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.


É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.


Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.

E porquê? Por que tão pouco existe sobre BI, com Ágil?

Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.

Por causa do cubo.

Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.

Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.

E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.

Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.

O Mundo Não é um Quadrado em 3D

Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.

Um exemplo fácil é Data Mining

Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.


O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.


Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.

Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.

Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.

Outro exemplo? Claro: painéis.

“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”

É, não posso negar que se dão bem, vocês quase têm razão.

Quase.

Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.

Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.

Diferentes cubos.

Vou escrever ao contrário para ver se fica mais claro:


Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.

Caso isso não seja possível, precisaremos de mais de um cubo.


Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!

É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.


Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!


O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!

O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!

Worlds Collide!

Eis aqui o Manifesto Ágil:


Manifesto para o desenvolvimento ágil de software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

> Indivíduos e interações mais que processos e ferramentas

> Software em funcionamento mais que documentação abrangente

> Colaboração com o cliente mais que negociação de contratos

> Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Esse é precisamente o ponto:

Indivíduos e interações mais que processos e ferramentas

O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!

Por que é que temos tão pouco de Ágil em BI?

Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?

Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:

Ágil e BI na Amazon: livros sobre... DW?
Ágil e BI na Amazon: livros sobre… DW?

Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:

  • Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
  • Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
  • Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
  • Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
  • The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
  • Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
  • Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
  • Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
  • Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
  • Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series)Feb 21, 2013
  • Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013

Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.

Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!

Ágil e BI, segundo o Google: ferramentas?!...
Ágil e BI, segundo o Google: ferramentas?!…

(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)

De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:


Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)


Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.

Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.

Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?

Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.

Colocando de outra forma:


IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.

E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.


Conclusão?

Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.

Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.

Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.

Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?

Confuso? Para mim também. :-(

Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.

Até a próxima! ;-)


  1. Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. 

Data Vault: Como Usar – Errata

Meu grande amigo e co-autor do PnP, Cesar Domingos, me mandou um e-mail com duas dúvidas:

Fala Fábio,

Tudo bem?

Tô vendo uns posts seus sobre Data Vault e fiquei com dúvida em um.

https://geekbi.wordpress.com/2016/05/25/data-vault-como-usar/

Na parte do Modelo Completo, onde tem o desenho, a tabela s_l_empregados_pedidos não deveria estar linkada à tabela h_pedidos? Ou se não for na h_pedidos, não deveria existir uma tabela hub entre ela e a l_empregados_pedidos?

Fiquei meio perdido ali. Você tem algum exemplo com dados?

E uma outra pergunta. O que vai exatamente no campo Record Source? O nome da tabela de origem?

Abraços,

Cesar Domingos
Vida corrida de Cesar Domingos
Consultor Linux e BI
LPIC-3 e RHCE

Fui ver, e ele tem razão. Naquele post, a função da tabela s_l_empregados_pedidos não está clara, até porque existe um erro também. Neste post completo a explicação, explicitando o que eu queria fazer e mostro uma correção possível.

O Problema

A metodologia de modelagem de dados para Data Vault define três tipos principais de tabelas: hub, links e satélites. Hubs registram conceitos de negócio, como vendedor, cliente e produto. Links registram relacionamentos entre conceitos de negócios, ou seja, entre hubs. Por exemplo, se um vendedor cuida de um certo cliente, então podemos definir um link entre os hubs de vendedor e cliente.

Satélites guardam os atributos de hubs e links. Se o cliente é um hub, um satélite de cliente contém, por exemplo, seu endereço, sua data de nascimento, sua ocupação e outros dados.

A figura da qual o Cesar falou mostrava dois hubs, empregados e pedidos, e um link entre os dois:

As tabelas combinadas no modelo.
As tabelas combinadas no modelo.

Além disso, ela também mostra um satélite para hub empregados, e um para o link empregado-pedido. E isso está errado!

Sim, veja: satélites contêm atributos de um hub ou de um link. A tabela s_l_empregados_pedidos é um (s_)atélite pertencente ao (l_)ink empregados_pedidos. Mas olhe que atributos esse satélite tem:

  • data_pedido
  • pagamento_tipo

De quem são esses atributos? Data do pedido é um atributo do… pedido. E tipo de pagamento? Também! Ora, se são atributos do pedido – e não da relação entre pedido e vendedor – então esse satélite é do hub pedido, e não do link empregado-pedido! Por isso esse satélite está errado.

Para estar correto ele precisaria conter algum atributo da relação, do link. Esse modelo não é um bom caso para um exemplo de satélite de link, que era a minha intenção original.

A Solução

A mensagem que eu queria passar precisa de um modelo ligeiramente diferente:

O modelo corrigido.
O modelo corrigido.

Agora temos um novo hub, cliente. Poderíamos ter seu respectivo satélite, mas seria redundante, pois já temos um exemplo de satélite de hub.

Nesta empresa, cada cliente é atendido por um único vendedor ou gerente, que é o dono da conta, como acontece em um banco, por exemplo. Em um banco, todo cliente possui um gerente. Esse relacionamento aparece como um novo link, entre clientes e empregados.

Como dizia uma propaganda de banco, o tempo passa, o tempo voa. Um gerente muda de agência, outro muda de emprego, entram novos gerentes, chegam clientes de outras agências, clientes vão embora… Conforme o tempo passa, a relação cliente-gerente muda. Pior ainda: pode ir e voltar, ou seja, um cliente pode estar com um gerente hoje, outro daqui um mês e daí no ano seguinte volta a estar sob seu primeiro gerente.

O link não possui data de validade. Ele não possui nada além de data de criação e sistema de origem, aliás. Como, então, saber qual é o gerente atual de cada cliente? Ou que gerente teve que clientes durante um certo período?

Um satélite de link, justamente como mostrado na figura anterior, resolve essa situação: cada vez que o link sofre uma atualização, o satélite versiona sua data de validade. Resumindo:


Porque um link pode ter um satélite? Por que a relação entre dois hubs pode mudar ao longo do tempo, e a única forma de saber quais estão ativas, hoje, no sistema de origem é usando um satélite.


Evidentemente, um link pode ter outros atributos além de período de validade. Exemplo? Pense nos itens de um pedido, ou seja, os produtos que o cliente comprou naquele pedido. Esses itens são registrados no DV como um link entre o hub pedido e o hub produto. Agora, os detalhes de cada item, ou seja, a quantidade, o valor pago etc. são registrados como satélites desse link.

Record Source??

Quanto à segunda pergunta, o que vai no campo Record Source? Bom, o campo RSRC recebe o nome do sistema de origem, não da tabela. Como as tabelas, em princípio, fazem a integração dos dados, o campo indica em que sistema foi identificado aquele elemento – hub, link ou satélite – pela primeira vez. Como as tabelas hub e link são carregadas um sistema de cada vez, o campo RSRC indica, no fundo, que sistema foi carregado primeiro, já que ele não é atualizado mesmo que o campo seja encontrado em outro sistema, com o valor idêntico.

Esse campo tem um pouco mais de utilidade para satélites.

Já passei por situações em que era fundamental separar os dados dentro do satélite por sistema de origem. Foi com o Zabbix: um DV foi construído para integrar 11 Zabbixes. Como era tudo igual, tínhamos apenas uma tabela de satélite para cada item. Como o mesmo item podia aparecer em dois ou mais Zabbixes diferentes, o satélite do Zabbix 1 podia ser encerrado se o mesmo item existisse em qualquer outro Zabbix. O mesmo aconteceria com o segundo Zabbix a ser carregado e assim por diante e depois se repetindo desde o início. A única forma de resolver foi filtrando o satélite pelo RSRC, um para cada Zabbix. ;-)

Casos de Uso de Inteligência de Negócios

Inteligência de Negócios é a disciplina que busca a compreensão do funcionamento de uma organização (o conhecimento do negócio) mediante a aplicação do Método Científico. Além de insumo para aplicação do Método Científico, os dados de uma empresa prestam-se a um sem-número de funções, que podem ser realizadas por uma gama de ferramentas.

Algumas das formas de uso são notadas com maior frequência em uma organização ordinária. Vamos descrever algumas destas formas de uso de dados e ferramentas, os chamados Casos de Uso.

Caso de Uso

Um caso de uso (ou CDU para simplificar) é um modo de aplicação ou o propósito – o uso – de algo, como uma ferramentas ou uma técnica.

Como exemplo tome o caso de uso de uma panela de pressão: cozinhar alimentos a temperaturas superiores ao ponto de ebulição da água. Sempre que um alimento precisar de maior temperatura para ser adequadamente cozido, podemos usar uma panela de pressão.

Conversamente, sempre que um alimento pode ser cozido no ponto de ebulição da água, o uso de uma panela de pressão é desnecessário e pode até mesmo comprometer a qualidade do resultado.

A toda ferramenta corresponde um ou mais casos de usos com graus variados de adequação. Aplicar uma ferramenta a situações para as quais ela não possui uma adequabilidade mínima pode comprometer o resultado almejado, ou pior, pode entregar um resultado plausível enquanto oculta alguma falha intrínseca. Basta pensar no velho ditado “para martelo, tudo é prego” e imaginar que uma boa martelada pode engastar um parafuso na madeira: a qualidade da fixação será insuficiente e, mesmo aparentando estar “pregado” bem o bastante, o parafuso pode soltar-se e causar uma falha catastrófica.

Casos de Uso de Dados

Os dados produzidos nos sistemas informatizados de uma organização podem ser consumidos de várias formas e usados para várias finalidades.

Monitoração

Parte do trabalho de qualquer profissional, nos dias de hoje, é acompanhar eventos diários e responder a eles.

Entrou um novo ticket pedindo serviço? Surgiu um defeito? Um sistema sofreu pane?

Manter-se informado dos acontecimentos é parte da tarefa de monitorar o ambiente. Outra parte é examinar a situação, ou seja, os dados correntes, em busca de sinais que prenunciem o surgimento de uma situação específica. O exemplo mais banal é observar o dia no calendário: a aproximação de certas datas, que avizinham vencimentos de prazos, é uma forma de monitoração.

Algumas situações só podem ser monitoradas a partir de um conhecimento prévio, que precisa ser adquirido de antemão. Sabemos que a chance de chover aumenta quando o céu cobre-se de nuvens escuras porque tivemos a oportunidade de testemunhar a correlação entre chuva e céu nublado – com frequência o primeiro segue-se ao último – várias vezes.

Evidência

Situações surgem em que ocorrências passadas são questionadas. A forma mais prática de confirmar fatos é apresentar os dados que evidenciam o que aconteceu.

Por vezes essa evidência é direta, como um relatório de gastos ou uma lista de peças de um lote. Em outras situações a evidência é indireta. Se nenhum sistema registra a entrada do empregado em certo dia, por exemplo, e nenhum arquivo de sua estação de trabalho possui timestamp de acesso naquele dia, então é razoável supor que naquele dia ele não esteve em seu posto.

Análise

Pense no indivíduo que nunca testemunhou uma chuva na vida. Na primeira ocasião em que observar o céu escurecido – resultado da monitoração – ele não presumirá o risco maior de precipitação. Apenas depois de algumas ocorrências céu escuro/chuva é que ele poderá ser levado à concluir que a associação existe.

Essa é uma situação recorrente no funcionamento diário em qualquer organização: se não entendemos a relação entre causa e efeito, monitorar o quê? Se não temos um argumento a ser testado, provar o quê? Esse é o miolo da disciplina de Inteligência de Negócios, a que realmente agrega valor à organização ao produzir conhecimento explicitando a relação (e os parâmetros) entre causa e efeito. Essa é a mesma justificativa para erigirmos um DW, aliás.

Dados, além de servir para monitorar e para demonstrar fatos, ainda podem ser explorados e estudados em busca do conhecimento de negócio. Na minha opinião, essa classificação do uso dos dados em uma empresa explicita a separação entre os usos analíticos e operacionais.

Casos de Uso de Ferramentas de Dados

O termo genérico “ferramentas de dados” significa toda ferramenta que manuseia e/ou apresenta os dados dos sistemas informatizados de alguma maneira. Por exemplo, o próprio sistema informatizado, que produz os dados, é uma ferramenta de dados. Levado ao paroxismo, todo software é uma ferramenta de dados, já que todo software comanda uma CPU para tratar algum dado de alguma maneira. Para o propósito deste documento vamos restringir essa definição aos softwares que lidam com dados de negócio em sua forma operacional. Por exemplo, softwares que tabulam dados ou traçam gráficos.

Relatório

Uma das ferramentas mais simples para o manuseio dos dados é a exibição de listas. Esse CDU é conhecido pelo termo de relatório, pois relata, descreve, apresenta os dados. Um relatório é, por definição, uma lista de dados com rótulos nas colunas, que pode vir acompanhado de outros recursos.

Uma ferramenta de relatório pode incorporar uma quantidade de opções de apresentação, como títulos, cabeçalhos, números de páginas, gráficos ou sub-relatórios (relatórios dentro de relatórios.) Ferramentas de relatórios podem possuir alguma resposta dinâmica, como escolher o formato de saída (HTML, PDF e CSV entre outros), ou a aplicação de algum filtro em tempo de execução e até mesmo embutir URLs (links web) nos campos, tal que clicar sobre eles abrem páginas em navegadores web. Consta como tradicional a possibilidade de imprimir tais listas.

O acesso aos relatórios pode ser por meio do software instalado localmente ou via portal web e algumas soluções combinam a possibilidade de remeter um relatório renderizado diretamente para o e-mail de um usuário.

Painel de Dados

Um passo adiante do simples relatório, painéis são meios eminentemente gráficos, usados para apresentar diversas visões sobre dados em uma única área, em geral com alguma correlação entre si. Tradicionalmente associa-se à esta tecnologia a capacidade de algum tipo de interação. Por exemplo, um painel de vendas pode mudar para exibir os números por UF ao se clicar em um mapa do país.

A promessa dessa tecnologia é comunicar um volume maior de informações por meio de uma diagramação mais inteligente dos dados. Em outras palavras, um painel é a proverbial imagem que vale por mil palavras para a gestão da organização.

Análise Multidimensional

Uma ferramenta de análise multidimensional tem a capacidade de cruzar atributos em linhas e colunas, com os valores nas células resultantes desse cruzamento. Em comparação com uma ferramenta de relatório, uma ferramenta de análise multidimensional possui duas diferenças principais:

  • Exibir cabeçalhos tanto em linhas quanto em colunas, já mencionado;
  • Reorganizar a visão interativamente, com um tempo de espera mínimo.

Enquanto que ferramentas de relatórios estão limitadas a listas, que são renderizadas a partir de consultas, uma ferramenta de análise multidimensional pode criar planilhas, e respondem em segundos. Esse tipo de exploração de dados apóia processos de investigação de causa-raiz (ir de uma visão macro a uma visão micro, até achar a causa de um evento) e de entendimento de correlações entre os dados.

Se relatórios e painéis de dados sobressaem-se na apresentação dos dados, ferramentas de análises multidimensionais ajudam a descobrir o quê é interessante apresentar.

A sigla tradicional para análise multidimensional é OLAP, abreviação em inglês de Processamento Analítico On-Line.

Além da organização dos dados e da interatividade, ferramentas OLAP ainda oferecem controle sobre os níveis e o tipo de agregação. Por exemplo, podemos criar uma visão multidimensional mostrando, nas colunas, as UFs, e nas linhas os produtos. Cada célula dessa planilha indica, portanto, o total de venda de um certo produto numa certa UF. Podemos trocar UF por região, e a quantidade de colunas passará de 27 a 5. Mas também podemos manter a UF e fazer uma quebra por região, exibindo simultaneamente o UF e região para cada valor. Uma linha de células no topo (ou no fundo da planilha) pode, então, mostrar as agregações por região.

Data Mining

Esse pode ser considerado uma família de casos de uso mais do que um único CDU, cujo propósito genérico é apoiar o desenvolvimento de algum modelo matemático que “explique” os dados.

Ferramentas desta categoria costumam oferecer, entre outros recursos:

  • Estatísticas básicas: média, mediana, variância etc.;
  • Estatísticas avançadas: distribuições, ajustes de curvas, testes de regressão e hipóteses, por exemplo;
  • Análises sofisticadas, como Análise Baeysiana, clusterização, grafos, previsores como ARIMA e HoldWinters.

Ao contrário das outras ferramentas, as que implementam estes CDUs são voltadas para um público específico, dotado de habilidades específicas no tratamento de dados e construção de modelos empíricos. O nome corrente do profissional apto a aplicar este tipo de ferramenta é “cientista de dados”, mas já foi tratado por analista de data mining ou simplesmente “o estatístico”.

Os resultados de projetos para este caso de uso costumam se apresentar como algoritmos ou equações que, devidamente implementadas nos sistemas transacionais, podem operar decisões autônomas, sem supervisão humana. Um exemplo clássico dessa situação são as ofertas de crédito pré-aprovado exibidas por ATMs.

E o Pentaho?

A suite Pentaho implementa casos de uso de dados através de alguns casos de usos de ferramentas de dados.

O Pentaho oferece a possibilidade Monitorar, Reportar e Analisar dados.

Entre as ferramentas disponíveis na suite temos as capacidades de relatório (Report Designer), Painéis (BA Server) Análises Multidimensionais (Mondrian) e Data Mining (Weka.)

Cada CDU de ferramenta é implementada por um software específico. Cada CDU de dados é resultado da combinação de uma ou mais ferramentas, em geral com o BA Server no centro.

Conclusão

Os casos de uso de dados explicitam uma separação que eu fiz no primeiro post de 2016: o uso dos dados pode ser estratégico ou operacional. O CDU de Dados Análise é o único que realmente se encaixa em BI. Os outros dois podem consumir dados tanto de um DW quanto de bases transacionais, vivas. O CDU de Análise, não. A única forma de determinar a relação de causa e efeito é usando um DW e o Método Científico.

Olhando as demandas por dados que toda empresa experimenta através do ponto de vista de CDUs, podemos notar que a Suite Pentaho é uma solução completa, pois permite implementar todos os CDUs de dados através de todos os CDUs de ferramentas.

Mesmo que pareça o contrário, a intenção do post de hoje não era tecer loas ao Pentaho. Nunca escondi que sou fã da plataforma e se um dia eu decidir rasgar ceda para o Pentaho, eu o farei escancaradamente, sem pudores. Este post nasceu de um relatório que eu terminei hoje, que examinou a adequação de outra ferramenta, o [Spotfire][spotfire_bitly], à comunidade de usos e necessidades de certa empresa real. É justamente o fato de ser baseado em um relatório autêntico, de uma empresa real, que deu esse tom mais austero, mais academicista ao post. Espero que isso não espante vocês. Semana que vem volto ao modo galhofa de sempre. ;-)

Lamentavelmente para essa companhia, o Spotfire não possui uma adequabilidade tão grande às necessidades dela quanto outras ferramentas – como SAS e Pentaho – ainda mais em um patamar de custo benefício significativamente desvantajoso para o Spotfire.

Até a próxima. ;-)

Nadando em Lagos de Dados

Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.

Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.


Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.

Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.


E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.

Despensa, Cozinha e Salão

Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:

Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.

Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):

O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.

No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.

Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.

Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.

Uma Rosa por Qualquer Outro Nome

Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.

Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:

Ilustração do conceito de contexto limitado - bounded context.
Ilustração do conceito de contexto limitado – bounded context.

Agora a definição de bounded context:

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.

Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:

“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”

Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.

Conceito de UoW ilustrado: cada circunferência representa uma "unidade", que se integra a conceitos vizinhos.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.

Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:

  • A Unit of Work defines a correlated set of data;
  • A Unit of Work keep things together;
  • A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
  • UOW should be consistent with the (Enterprise wide) business keys.

Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:


Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.


Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.

Então temos três conceitos:

  • O clássico subject oriented, da área de DW;
  • O bounded context herdado da área de desenvolvimento de sistemas;
  • O misterioso Unit of Work, visto em textos de Data Vault.

E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.

Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)
Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)

Esta bela imagem foi retirada da Wikipedia.

Juliet:

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

W. Shakespeare, Romeu and Juliet

Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.

Mesmo Assim…

… Fowler comete alguns equívocos:

  • Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
  • Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
  • Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.

E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.

Conclusão

É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.

Mas o resultado final do post do Fowler é muito maior que seu conteúdo:

Data Lake Data Vault
Dados crús Dados crús
Precisa destilar para consumir Precisa destilar para consumir
Context bounded Subject oriented

PQP DE RODINHA!!!

O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:


DATA LAKE = DATA VAULT


Só o gênio dele para trazer essa relação à tona.

Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”

;-)


  1. Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. 

A Orquídea, o Pântano e o Jacaré

A Orquídea, o Pântano e o Jacaré

10/08/2016 [Link para o post.][post_bitly]

Mostrei meu post Lago ou Pântano? a um colega de trabalho e ele matou a pau. O comentário dele foi tão interessante que eu resolvi publicá-lo aqui, como uma lição para todos nós.

Mas eu não vou entregar assim de graça, vocês vão ter que ler até lá. ;-)

Data Lake

Você pode ler sobre o conceito direto do pai dele, James Dixon, neste post. Em resumo, DL é uma tecnologia que captura “tudo”, direto para um repositório Hadoop, e que fica disponível para quem quiser usar. Esse paradigma coloca uma série de questões. Por exemplo:

  • Se dados no Hadoop não aceita updates, como lidar com incrementos?
  • Devemos capturar as fontes de dados e seus metadados?
  • Como arquivar as evoluções de layout da origem?
  • Como tratar tempo-real?

E assim por diante. Essas questões, dirão vocês, provavelmente foram resolvidas na cabeça do Dixon, ou então são partes das dores evolutivas de uma nova tecnologia. Não discordo de nenhum destes argumentos. Em TI nada nasce completo, e faz parte do ciclo de vida de cada nova tecnologia se aprimorar e se apurar a cada nova versão.


Estudando para escrever este post eu acabei assistindo este vídeo, que mostra como injetar dados em um Hadoop automaticamente. Preciso admitir que é impressionante. Na verdade, estou morrendo de vontade de testar, mas para um caso de uso muito específico: stage!


O Problema de um Data Lake

Se aqueles detalhes são apenas isso, detalhes técnicos, e não são problemas, quais são os problemas que um Data Lake coloca?

Ora, muito simples. Se ele é mesmo uma réplica de todos os dados de todos os sistemas de uma organização, então ele carrega os mesmos problemas de usar os dados na origem:

  • Sujos;
  • Não-integrados;
  • Não-documentados;
  • Inconstantes.

São exatamente os problemas resolvidos por um projeto de DW, que mira em entregar dados prontos para uso a partir de várias origem. Ou seja, um projeto de DW promete entregar:

  • Dados limpos, prontos para consulta;
  • Integrados;
  • Com uma explicação clara sobre sua função e origem;
  • Imutáveis.

Portanto, ou o projeto de Data Lake incorpora, por definição, um subprojeto de DW, ou o usuário final deve fazer isso tudo sozinho!

Posso ouvi-los cantando meu nome:

“Fábio, Fábio, Fábio, homem de pouca fé! É óbvio que o cliente não está sozinho!”

Não? Então os usuários de Data Lake vão trazer apoio para entender e integrar os dados… De onde? Do sistema de origem, dos próprios DBAs e tals? Bom, se essa é a solução, ok, quem sou eu para desdizer!

Estou zoando, mas a questão é séria. O usuário vai até o DL e, sozinho, escolhe as fontes de dados? Como ele vai saber qual daqueles arquivos contém o dado que ele precisa, ou que é que significa cada uma daquelas colunas e tabelas? E como saber de que forma cada tabela se liga com outras tabelas?

Não tem como se virar sozinho, 100% sozinho, em um curto espaço de tempo. Raramente a informação sobre os dados existe empacotada em algum lugar, à disposição de quem precisar. Geralmente esse conhecimento todo está espalhado em documentos de sistema, na cabeça de DBAs e na cabeça de usuários de cada sistema. Se virar sozinho com o Data Lake implica em gastar muito tempo e, mesmo assim, provavelmente gastaria esse tempo perguntando coisas a quem sabe.

Lembrando que cada novo consumidor deste Data Lake vai repetir os mesmos caminhos. Depois de recuperar os dados, ainda precisa tratá-los de alguma forma – limpando-os e integrando-os – para depois carregar em alguma estrutura que permita a consulta dos dados, o uso destes dados para um propósito qualquer.

É como se trocássemos uma padaria, na qual compramos o que precisamos, por um grande silo que visitamos para comprar o trigo, e depois em casa convertê-lo em pão, macarrão, biscoito etc.


Já pensou que terror??

  • Manhê! Dá um Negresco?

  • Peraí, filhote…

  • Mas mãe, faz duas semanas que você diz “peraí”… Esse biscoito num assa nunca?

  • Assar, até assa, meu filho. E fazer o chocolate para misturar com a farinha para fazer o biscoito, nem foi tão difícil. O diacho é secar o tacho de caldo-de-cana para conseguir o açúcar mascavo para conseguir o açúcar refinado para fazer o recheio com o leite que seu pai trouxe lá da fazenda da Parmalat… E nem pense em pedir bife à parmeggiana de novo!!!

:-D


Até parece Minecraft

Só para constar, o mundo já foi assim. Naquele tempo alguém percebeu que poderia fazer algum dinheiro transformando o trigo em farinha, e outro percebeu que poderia vender macarrão com a farinha do fulano, e assim por diante, até chegarmos neste nosso mundo de Pães de Açúcar, padarias e postos de gasolinha em todas as esquinas.

JÁ PENSOU TER QUE REFINAR PETRÓLEO EM CASA???? :-O

Conclusão

Eis a conversa com meu amigo, regalem-se:

(09:15:36) Fábio: Você entendeu, não?
(09:16:09) Colega/DEPTO: o super-herói precisará entender todas as regras de todas as bases de origem
(09:16:44) Fábio: ISSO!!!!! :-D
(09:17:25) Fábio: É tão bem colocado que eu vou fazer um take dois!
(09:17:26) Colega/DEPTO: vai lá procurar uma orquídea dentro de um pantano!
(09:17:44) Colega/DEPTO: o jacaré vai te comer
(09:17:58) Fábio: quá quá quá!
(09:18:23) Fábio: O nome desse próximo post vai ser A Orquídea, O Pântano e o Jacaré.

Vamos destacar, imprimir e pendurar na parede:


Sobre Data Lakes:

O [usuário] super-herói precisará entender todas as regras de todas as bases de origem. Vai lá procurar uma orquídea dentro de um pântano! O jacaré vai te comer.

Vitor Rosan

Savan Extraordinaire


Falou pouco mas disse tudo! ;-)


10/10/2016 08:10:41Complemento

Cheguei no trabalho, abri meu IM e pulou:


(05-10-2016 17:14:06) Vitor: boa tarde
(05-10-2016 17:14:20) Vitor: está ocorrendo aquilo que você profetizou no seu blog, sobre o datalake
(05-10-2016 17:14:55) Vitor: tem muitas pessoas tentando obter dados da base do dw recorrendo a mim para explicar como achar o caminho no meio do pântano


Reparem que ele comenta sobre a minha “professia” do Data Lake, mas depois fala do DW. Eu não entendi na hora, mas a explicação é simples: ainda nem entrou o Data Lake no ar, nem começou, e o problema de entender os dados já está acontecendo em um DW normal, com gerenciamento insuficiente.

Imagine no Data Lake? :-D

 

Data Vault – Satélites?

No post Data Vault – Como Usar  falei um pouco sobre a motivação, conceitos e arquitetura envolvida em um projeto de DW baseado em Data Vault. Um dos meus leitores colocou algumas perguntas muito interessantes, tão interessantes que eu decidi respondê-las em um post exclusivo. Além de ser um meio mais cômodo que um formulário de comentários, é uma forma de agradecer pela participação e mostrar o quanto eu apreciei. ;-) (Sim, eu sou fã dos meus leitores.)

Perguntas, Perguntas, Perguntas

Eis as perguntas colocadas no comentário:

1) Nos satélites, você cita um campo “Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);”. Neste ponto eu fiquei em dúvida. O ETL para estes satélites poderão realizar operação de update ou não? Ou este campo seria apenas para os casos de atributos que já tiveram uma “vigência fechada” nos OLTP (estou fazendo analogia ao SCD tipo II)?

2) Eu e um colega discutimos se o DV seriam bancos de dados para cada sistema transacional ou todo o DV corporativo estaria em um único banco de dados. Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto? No meu caso, estou falando de SAS e, consequentemente, datasets são tabelas e diretórios são bancos de dados. Então, na falta de um banco relacional como DV, eu inicialmente colocaria todo o DV num “diretório dvault”.

3) Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Vou responder uma por seção. Vamos lá.

LEDTS vs. SCD2

O ETL para estes satélites poderão realizar operação de update ou não?

Não apenas podem, como devem. Satélites guardam histórico e possuem exatamente o mesmo comportamento de uma dimensão de variação lenta do tipo 2. Ele acertou na mosca!

Hubs e links são tabelas que guardam os conceitos de negócio da organização, e as relações entre esses conceitos. Se algum dia um determinado hub ou relacionamento entre hubs existiu, o Data Vault captura e arquiva essa informação. Satélites, por outro lado, dão o contexto desses elementos.

O Cofre: Coleção ou Caverna?

A segunda pergunta é mais complexa:

Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto?

Bom, por um simples questão de integração, deveria estar tudo junto.

Buraco Negro

Até que ponto pode crescer um satélite?

Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Bom, o propósito central de um DV é acumular “todo os dados, para todo o sempre”. Logo, precisamos que a estrutura na qual os dados estão armazenados dê conta disso. Se um relacional não consegue, então precisamos recorrer a algo mais elástico. Inmon chamava essa camada de Near Line Storage, que é um armazenamento de alto volume, mas em uma mídia mais econômica. Em troca pelo preço menor por byte e durabilidade maior, a velocidade de acesso seria menor. No caso original, NLS seriam fitas magnéticas.

Conclusão

A conclusão, desta vez, é minha: do comentário e das perguntas eu posso ver que estou deixando algumas lacunas no assunto de Data Vault. Vou levar essa visão em consideração nos próximos posts sobre o assunto.

Até lá! ;-)

Data Vault – Como Usar

Um dos leitores do blog deixou este comentário em 18/5/16:


Fábio, gostaria de mais instruções sobre o data vault, como aplicar, onde aplicar e como é sua modelagem e arquitetura.


Prometi a ele que o próximo post responderia essa questão. Então aqui está: Data Vault, uma visão geral sobre onde aplicar, como modelar e em que arquitetura colocá-lo.

Do Começo, Por Favor

Data Vault é uma metodologia de desenvolvimento de Armazém de Dados Corporativo (do Inglês EDW), que inclui modelagem e processo de ETL. A versão 1.0 parava aí, já a 2.0 vai adiante, até a camada de apresentação dos dados.

Essa técnica foi inventada e desenvolvida por Daniel Linstedt para um projeto na mítica Lockheed Martin, que faz (fazia?) o mítico Blackbird SR-71, o avião dos X-Men. Baixe a amostra do Building a Scalable Data Warehouse with Data Vault 2.0 e leia o prefácio (do mítico Bill Inmon – isso aqui tá um templo grego de tanto mito!!) para ver essa história.

Perdão, mas eu precisava colocar isso aqui.
Perdão, mas eu precisava colocar isso aqui.

Aplicando Data Vault podemos desenvolver um Armazém de Dados com baixo custo, alta produtividade, baixo retrabalho, com processo de ETL de alta performance e altíssimo MTBF.

Volte Mais!

E porque precisamos de um Armazém de Dados mesmo? Bom, não é o assunto deste post, mas aqui vai, resumidamente:


No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.


Leia meu post Um Ponto Fita o Mundo para ver o argumento inteiro.

Vamos continuar?

Por Quê Adotar DV?

Todo EDW cumpre duas funções básicas:

  • Puxa dados dos vários sistemas da empresa para um repositório central;
  • Integra os dados dos diversos sistemas em uma visão abrangente.

Um EDW precisa puxar os dados de todos os sistemas porque qualquer se não olharmos em todos os dados da empresa nunca teremos a certeza de termos investigado tudo que há para ser examinado. É como perguntar que livro sumiu da biblioteca: só olhando todos vamos saber qual não está lá. Se o gerente financeiro pergunta “quais são todos os gastos da empresa”, precisamos olhar tudo!

Pense: se sua empresa tiver dois sistemas em MySQL, um em SQL Server, um em Postgres e outro em Oracle, como escrever um SQL que percorra todas essas bases? Não dá, não é? Os dados precisam estar em um repositório centralizado por simples limitação das atuais tecnologias de banco de dados: como em geral usamos SQL para fazer essas pesquisas, e um SELECT não consegue consultar – ao menos não de maneira fácil – dois ou três ou mais bancos de tecnologias diferentes ao mesmo tempo.

Os dados precisam estar integrados, o que significa bater os CPFs 012345678-00 com 1234567800. Quando puxamos um relatório do cliente 012.345.678-00 precisamos que ele seja identificado em todos os sistemas, não importando se na origem ele aparece como 1234567800, 012345678-00, 012.345.678-00 ou de qualquer outra forma. Dados não-integrados fornecem respostas erradas. Sem integrar os dados, seu DW não vale o HD no qual está gravado.

Há várias técnicas para construir um DW atendendo essas duas obrigações:

  • Copiar tudo da origem, mantendo os mesmos modelos, e integrar na hora de fazer a consulta. Frágil, trabalhoso e pesado (consome muita máquina;)
  • Copiar tudo da origem, gravando em um novo modelo na Terceira Forma Normal. Mais robusto e de melhor performance que o anterior, mas de evolução e manutenção tão difícil que beira o insano;
  • Copiar a origem em um novo modelo, como no item anterior, mas em um Modelo Dimensional. Não tão robusto, mas de boa performance, com evolução e manutenção práticas e simples no começo, mas tendendo à impossibilidade de manutenção e evolução com o tempo.

E finalmente, o Data Vault, que não sofre de nenhum destes problemas e tem todas as vantagens. Resumindo em figuras:

Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças, agora no arquitetura com DV.
Os impactos das mudanças, agora no arquitetura com DV.

Só para ficar claro: por “nenhum impacto aqui”, no último quadro da figura acima, eu quero dizer “nenhum impacto de manutenção”, já que, obviamente, pode ser preciso criar algo novo. Não haverá impacto no que existe, não será necessário mudar nada.


Adotar Data Vault como metodologia para desenvolvimento de um DW vai evitar os problemas que costuma comprometer os DWs da 3FN e Dimensionais.


Hoje vamos deixar só com essa afirmação, porque este é um post de visão geral, mas você pode seguir os links apresentados até agora para ler o (extenso) argumento explicando porque é assim.

Como Aplicar?

De fato, não há segredo na aplicação de Data Vault. A técnica meio que se resume em:

  • Quebrar o trabalho em “histórias”: quero medir isso, quero analisar aquilo;
  • Daí, para cada uma:
    • Identificar as tabelas na origem que respondem essas perguntas
    • Expandir o modelo de dados do DV com hubs, links e satélites;
    • Gerar automaticamente ETL de carga do DV;
    • Desenhar o ETL para a área de apresentação.

Existem padrões e técnicas para cada atividade, e a metodologia casa-se como uma luva à gestão ágil. Meu método preferido é o Scrum, e chega a ser surpreendente ver como DV adequa-se tão perfeitamente ao Scrum.


Veja meu post De Agilidade e BI para alguns comentários sobre o levantamento de requisitos para projetos ágeis.


Como É a Arquitetura?

Você já deve ter intuido a forma geral da arquitetura em uma das figuras anteriores. Reorganizando e renomeando as partes daquela figura temos uma visão mais clara:

Arquitetura Data Vault.
Arquitetura Data Vault.

Ou seja:

  1. Um ETL (gerado automaticamente) traz os dados de cada origem;
  2. Um banco de dados (preferencialmente relacional, mas um Hadoop does too) recebe e, graças ao modelo de dados do DV, integra tudo “na entrada”;
  3. A partir deste banco um segundo processo de ETL popula as soluções;
  4. Essas soluções podem ser de todo tipo: análises multidimensionais (OLAP), Data Mining (CRM etc.), painéis, relatórios etc. etc. etc.

Cada uma destas soluções após o segundo ETL têm suas arquiteturas particulares. No fundo a arquitetura de um DV são dois ETLs com um banco com modelo de dados DV no meio, mais nada. A partir daí, tudo fica igual à qualquer outro projeto de BI.

Modelagem

A modelagem de um Data Vault é relativamente simples, e você pode ler um pouco mais sobre ela neste post. Grosso modo, porém, resume-se ao seguinte:

  • Identificar chaves de negócio e criar hubs;
  • Encontrar relacionamentos entre chaves de negócio e criar links;
  • Escolher os atributos de hubs e links e criar os satélites.

Hubs

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:

  • Business Key: chave primária, um inteiro sequencial;
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Record Source: fonte da chave de negócios;
  • Source business key: chave de negócio no sistema de origem.
Uma tabela hub.
Uma tabela hub.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal do modelo. 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.

Links tão tabelas que guardam o relacionamento entre dois hubs. Uma tabela link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:

  • Link Key: chave primária, um inteiro sequencial;
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Record Source: fonte do relacionamento;
  • BK1: business key do hub 1;
  • BK2: business key do hub 2;
  • BKn: business key do hub n.
Uma tabela link.
Uma tabela link.

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

Satélites

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:

  • Business Key/Link key: chave primária do hub/link
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
  • Record Source: fonte dos atributos;
  • A1: atributo 1;
  • A2: atributo 2;
  • An: atributo n.
Uma tabela satélite.
Uma tabela satélite.

Modelo Completo

A coleção dessas tabelas e seus relacionamentos dão o modelo completo:

As tabelas combinadas no modelo.
As tabelas combinadas no modelo.

A etapa seguinte é construir o ETL para dentro do DV, e depois do DV para a camada de apresentação/consumo de dados.

ETL

Um DV possui duas vantagens “matadoras”: integração dos dados no modelo, ao invés de no ETL como é o mais comum, e um ETL padronizado. Graças à essa padronização o ETL de um DV inteiro pode ser gerado automaticamente: a partir de alguns gabaritos de SQL podemos construir o processo que lê e grava todos os hubs, links e satélites.

Eu sempre uso o Pentaho Data Integration (PDI) para processos de ETL, e meu curso de DV entrega ao aluno um gabarito de projeto completo – é só tirar da caixa e usar. A última versão dele traz até os SQLs para criar as tabelas no Data Vault.

Isso para o primeiro ETL, para dentro do DV. O segundo ETL, saindo do DV para a camada de apresentação, é mais particular, e não há como automatizar sua geração. Por outro lado, como todos os pontos de partida não são mais os sistemas de origem mas sim o DV, a “forma” geral desse segundo processo é mais uniforme, e alguns padrões acabam por facilitar seu desenvolvimento.

Por exemplo, dimensões são quase sempre construídas a partir de um hub e seus satélites, e tabelas fatos originam-se de links. Construídos os SQLs que lêem isso no DV (e nisso eles seguem um padrão de JOINs bem cadenciado), o passo seguinte é fazer trocas de chaves naturais por delegadas e, em caso de necessidade, limpar os dados.

Conclusão

Adoro quando um leitor pede algo, pois escolher o tema do próximo post, para mim, é como escolher roupa para sair: muito, muito difícil – e se não gostarem? e se ficar ruim? e se eu falar besteira por saber pouco? E se?…

Vimos que um Data Vault é uma metodologia que habilita a realização da visão de Bill Inmon, a Corporate Information Factory. A [CIF][cif_bitly] (até o advento do DV, outro mito) é como uma linha de produção, que ingere todos os dados da empresa e “fabrica” produtos de dados conforme as necessidades vão surgindo.

Data Vault é uma metodologia composta por uma modelagem, um processo de geração automática de ETL e outros elementos (como padrões e nomenclaturas.) O EDW se completa com um segundo processo de extração, que leva os dados para as áreas de apresentação, em formato dimensional ou não. Tudo em um processo de desenvolvimento que nasceu para ser tocado com gestão ágil (Scrum, na minha preferência), boa parte automatizada e com baixo ou nenhum retrabalho.


Não deixe de ver o post As Vantagens do Data Vault para mais sobre como um DV pode ajudar seu projeto de EDW.


É claro que nada é 100% a prova de falhas, defeitos ou problemas e eu mesmo já enfrentei minha cota de surpresas, dificuldades e maluquices nesse caminho que venho trilhando há alguns anos. Mesmo assim, hoje em dia, um Data Vault é a coisa que mais se aproxima de um método perfeito.

Fora essa babação no final, acredito que era isso. ;-)

As Vantagens do Data Vault

Semana passada, 6/5/16, eu assisti uma palestra sobre uma empresa chamada Attunity, e suas ferramentas para Business Intelligence. Vendo as promessas do representante brasileiro eu me dei conta de que já escrevi bastante sobre DV, mas nunca escrevi especificamente sobre as vantagens trazidas pela adotação de Data Vault. Vamos corrigir isso hoje, partindo desta apresentação.


Você pode pular direto para a lista de vantagens clicando aqui.


Uma Nova Categoria

Estamos em 2016 e já lá se vão cerca de 40-50 anos desde que Bill Inmon começou o debate sobre Armazéns de Dados, e 24 anos desde seu livro Building the Data Warehouse. Muita água passou embaixo da ponte e todas suas idéias estão sedimentadas, firmes, sobre as quais se assenta a moderna indústria de DW. Um destes conceitos é a Corporate Information Factory, que agrupa as fontes de dados e seus consumidores como uma linha de produção.

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

Tal qual a revolução industrial fez com a manufatura, graus de automação sucessivamente maiores estão acelerando e simplificando o desenvolvimento, manutenção e gerenciamento de Data Warehouses. Instrumental para essa revolução foram tecnologias aparentemente irrelevantes, como modelos de dados e metodologias de desenvolvimento.

Metodologias como Scrum, Continuous Integrations e DevOps agem para diminuir a intervenção e variabilidade da ação humana, enquanto que outras, como Modelagem Dimensional e Data Vault, domam a confusão dos sistemas OLTP e permitem a criação de algoritmos. E é justamente essa criação de algoritmos que permite automatizar o processo de desenho, desenvolvimento e manutenção de DWs.

Uma nova categoria de ferramentas brotou desse fértil ambiente: ferramentas de automação de gestão de DW. Ainda não vi esse ramo ser tratado por um acrônimo, nem mesmo ter um nome mais comum, mas acho que, em Inglês, seria algo Data Warehouse Management Solutions, ou DWMS. Já sabem: se virem por aí, apareceu no GeekBI primeiro. ;-)

Continuando, essa categoria já tem alguns nomes internacionais:

Fazia tempo que eu não visitava o BI Ready, empresa de Ian Nicholson com quem já troquei umas idéias no LinkedIn. Surpresa! Ela foi adquirida pela Attunity e agora são um nome só. Não é à toa que, na apresentação, a Attunity declarou pertencer a essa turma – ela comprou “metade” das empresas dessa área!

Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.
Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.

Processos e Problemas

Um projeto de DW que hoje é chamado de “tradicional” (i.e., feito com metodologias de mais de 15 anos atrás) envolvia as seguintes etapas:

  1. Levantar os requisitos;
  2. Estudar os dados de origem;
  3. Desenhar o modelo dimensional;
  4. Desenhar o processo de ETL;
  5. Colocar em produção;
  6. Dar manutenção: propagar as mudanças dos sistemas de origem e adequar às novas necessidades do cliente.

Esse projeto em geral era tocado dentro de uma moldura PMI (a.k.a. Waterfall). Era um método tão certeiro e determinístico que até hoje todo mundo sabe que, feito assim, sempre falha.

Os problemas de um DW 'clássico'.
Os problemas de um DW ‘clássico’.

DW feito por cópia dos bancos de origem é a pior escolha possível, a menos que seja para uma padaria, uma farmácia, uma banca de jornais etc. ;-) Veja que não estou falando de palco (stage), mas de montar o DW como uma coleção de réplicas. Um modelo dimensional é o mínimo necessário para sobreviver aos problemas que serão apresentados ao final desta seção.


Com o advento do Manifesto Ágil e Data Vault, um projeto de DW moderno é tocado assim:

  1. Levantar os requisitos da próxima entrega (30 dias;)
  2. Estudar os dados de origem até encontrar o estritamente necessário para próxima entrega;
  3. Desenhar o DV;
  4. Gerar automaticamente o processo de ETL;
  5. Derivar dados para apresentação;
  6. Colocar em produção e reiniciar o ciclo.

A manutenção é incorporada nas sprints.

Veja que, grosso modo, o processo em si não mudou muito: de projeto waterfall passamos para Scrum, de modelo Dimensional no miolo do DW passamos para um Data Vault e o ETL principal é gerado automaticamente.

Os problemas que existem (existiam e vão continuar existindo) são:

  1. Integração: sem integrar e limpar 100% dos dados, todas as respostas são suspeitas. Ou você confiaria nos números sabendo que algo pode ter ficado de fora?
  2. Historiamento: não adianta montar um armazém que não guarda histórico. Fazer isso é cuidar de dados operacionais e jogar a água fora com o bebê – o maior valor dos dados está no histórico;
  3. Mudanças na origem: sistemas transacionais representam os processos que a empresa executa. Se a empresa muda, forçosamente os OLTPs precisam mudar, e o DW vai ter que ser adequado, sempre;
  4. Performance de ETL: a menos que a empresa esteja definhando, ela sempre vai crescer, sempre vai querer mais dados. O hardware para ETL sempre acaba ficando obsoleto, por um motivo ou outro, cedo ou tarde. O truque é extrair tudo que ele pode dar, e não desperdiçar nada;
  5. Velocidade de mudança: por fim, em cima de todos os problemas apresentados, temos o fato de que as coisas não estão ficando mais calmas, mais lentas, e sim mais rápidas, com mais demandas e mais complexidade.

Ferramentas…

As novas ferramentas de automação de DW se propõem a resolver esses problemas.

O Attunity propõe resolver um DW em dois passos:

  1. Usando o Attunity Replicate os dados são trazidos de diversas fontes de dados para um repositório centralizado;
  2. Daí, com o Attunity Compose, um DW é desenhado e carregado automaticamente.

Há um bom grau de magia negra envolvida (=coisas que acontecem sem entendermos claramente como), mas tudo faz um bom sentido. O Replicate se conecta aos bancos de dados de origem e fazem uma engenharia reversa total. Com essas informações ele vai ao banco de destino e recria o banco de origem, respeitando as diferenças de tecnologias. Por exemplo, ele pode replicar bancos MS SQL Server e Oracle para dentro de um único Postgres. Depois ele faz uma transferência inicial, em que replica as origem(ns) inteira(s) no(s) destino(s). A partir do final desta carga, o Attunity Replicate passa a ler o log de commits dos bancos de origem e replicar no destino, em tempo real.

Quem leu meu post Analítico ou Operacional? sabe que essa replicação não é um DW, e que fazer isso “não é BI”.

A Attunity também sabe, e dá o passo final em direção ao DW através do Compose. O que essa ferramenta faz é mais magia negra que a outra:

  1. Através de engenharia reversa e algoritmos especiais, o Compose “descobre” os relacionamentos entre as várias colunas de todas as tabelas das origens;
  2. Usando esse conhecimento, a ferramenta monta um DW – desenha um modelo de dados – automaticamente;
  3. Em seguida constrói (sempre automaticamente) o ETL para esse DW;
  4. Na última etapa ele monta uma área de apresentação de dados, seguindo indicações de que dados o cliente quer explorar.

A ferramenta ainda permite customizações e correções feitas pelo time de DW, de modo que qualquer interpretação incorreta pode ser ajustada.

Ou seja, ele automatizou 100% do processo moderno de desenvolvimento de DWs!!!! E digo mais: !!!!. Mas não pára por aí:

  • Esse DW guarda histórico;
  • A área de apresentação pode expor estrelas multidimensionais, com até mesmo SCDs tipo 2;
  • Ele detecta mudanças nas origens e ajusta o DW e o ETL;
  • Todas essas ferramentas são clusterizáveis, ou seja, podem ser escalonadas horizontalmente.

Isso são coisas que ouvi ou que perguntei durante a apresentação. Há coisas que eu não perguntei, mas presumo que também estejam no pacote, como tratamento de erros de ETL e monitoramentos diversos. Aliás, a parte de monitoramento é muito bacana, também – aprendi um negócio chamado “hot data, cold data”, sobre o qual vou fazer uns experimentos e, eventualmente, vou postar sobre.

… e Soluções

E como o Data Vault se encaixa nesse cenário? Simples: ele oferece tudo que as ferramentas oferecem, sem o custo monetário. Digo monetário explicitamente porque não existe almoço grátis, sempre precisamos pagar por algo. Se não é em dinheiro, vai ser em treinamento e capacitação, por exemplo, ou simplesmente mais trabalho.

DW 'moderno', re-organizado segundo DV.
DW ‘moderno’, re-organizado segundo DV.

Eis a lista de vantagens (ou problemas resolvidos) trazidos pela adoção de Data Vault no miolo do EDW:

  1. Velocidade de desenvolvimento: usar DV corta o tempo necessário para desenvolver e entregar em algumas ordens de grandeza. Por exemplo, coisas que levariam meses saem em dias;
    1. Modelo de dados: o diagrama de dados do Data Vault é construído através de regras simples, que capturam o negócio no modelo. Assim, uma vez que tenhamos a lista de esquemas, tabelas e colunas do sistema de origem, o ato de desenhar um DV é trivial e leva algumas horas, contra algumas semanas de outros formatos;
    2. Processo de ETL: usando o Pentaho Data Integration, o processo de ETL é gerado automaticamente, a partir do modelo elaborado anteriormente. Ainda é preciso juntar as partes (as diversas transformações) dentro de um job (pré-fabricado), mas isso é uma tarefa de minutos. O ETL inteiro sai em menos de um dia;
  2. Integração: o modelo de dados do Data Vault já arquiva os dados de maneira integrada. Ou seja, a integração ocorre via modelo, no momento em que os dados aterrisam no DV;
  3. Historiamento: 100% dos dados de um DV são historiados, automaticamente e por definição;
  4. Mudanças na origem: evidentemente não são tratadas automaticamente – um software pode fazer isso, não uma metodologia. Entretanto, esse impacto é mínimo:
    1. Qualquer mudança na origem não quebra o processo de ETL, ao contrário de DWs baseados em outros modelos;
    2. Mudanças na origem são resolvidas por um algoritmo simples, e qualquer manutenção leva praticamente o mesmo tempo de repetir o desenvolvimento (horas ao invés de semanas, portanto;)
    3. Nenhuma mudança na origem quebra a área de apresentação. A área de apresentação é reformada apenas em casos que afetem-na. Graças a esse fato, o impacto sobre a área de apresentação causada por mudanças nas origens é de mínimo a inexistente;
  5. Performance de ETL: várias vantagens ao usar um DV;
    1. Alta velocidade: por tratar apenas deltas (i.e., as diferenças) por meio de comparações simples, o processo é muito rápido;
    2. Paralelização: graças ao formato do ETL, todas as operações podem ser maciçamente paralelizadas, possibilitanto uso de hardware barato (COTS;)
    3. Resistente a erros: o ETL de um DV é auto-reinicializável por definição, e só é interrompido por falhas graves (hardware ou dados muito corrompidos;)
  6. Velocidade de mudança: é a mesma da velocidade de desenvolvimento – muito rápida.

Como vantagem extra, pelo fato de DV permitir atacar o problema por pedaços, ele se presta à:

  1. Modularização em sprints;
  2. Paralelização do desenvolvimento.

Por ser baseado em processos automatizados e algoritmos, a quantidade de erros é substancialmente menor, gerando projetos de qualidade maior, e mais padronizado.

Conclusão

Já há alguns anos a indústria de BI vem incorporando tecnologias que habilitam novas soluções de problemas complexos, como a construção, gerenciamento e manutenção de Armazéns de Dados. Essas tecnologias surgem como técnicas/metodologias e softwares.

Um software representante desta nova categoria é o Attunity, especificamente os módulos Replicate e Compose. O primeiro copia dados de diversas origens para um mesmo (ou vários) destino(s). O segundo modela um DW e cria o processo de ETL automaticamente a partir da réplica. Não sei com que qualidade, precisão e velovidade o Attunity entrega os resultados, mas a promessa é fantástica, para dizer o mínimo.

Esse produto é resultado de evoluções anteriores. Uma destas é a metodologia Data Vault, que oferece essa lista de vantagens:

  1. Alta velocidade de desenvolvimento: entrega em dia o que levava meses;
  2. Processo de ETL gerado automaticamente – maior velocidade, qualidade e padronização, com menos erros;
  3. Integração: dados são integrados na entrada;
  4. Historiamento: 100% dos dados de um DV são historiados;
  5. Mudanças: resiliente a mudanças na origem, processo de ETL não pára e impacto global (tanto ETL quanto usuários) é de mínimo a irrisório;
  6. ETL de alta performance, imune à erros, restartável e 100% paralelizável (é possível executar simultaneamente todas as etapas da carga do DV;)
  7. Adequado à processos de desenvolvimento ágil;
  8. Desenvolvimento do modelo (dada ferramenta adequada) e do ETL paralelizável.

Com um Data Vault podemos obter os mesmos resultados prometidos pelo Attunity, com menos automação, e com um custo diferente (menor?)

Clicando aqui você vê a lista dos meus posts marcados com Data Vault. Eis links para alguns do meus posts sobre o assunto:

E se você quiser ler sobre o assunto, o livro é este:

Livro sobre Data Vault.
Livro sobre Data Vault.

Só para não deixar vocês pendurados: eu ofereço os dois cursos, Requisitos Ágeis e Data Vault. Fazer essa propaganda dá impressão que eu montei um post para me auto-promover, mas juro que não é o caso deste aqui. Acredito no valor que esses cursos agregam e sentiria que estaria prejudicando você, meu leitor, ao evitar contar que eles existem. Quem me acompanha sabe que quando eu vou vender algo aqui, eu aviso no começo. ;-)


Até a próxima!

As Soluções Clássicas – CRM

Semana passada começamos a nova série no GeekBI: As Soluções Clássicas. Clique aqui para acessar aquele post.

Hoje veremos a primeira destas soluções: Gerenciamento do Relacionamento com o Cliente, ou em inglês Customer Relationship Management. Sim, você leu corretamente: C R M. O bom e velho, famigerado CRM.


Boa parte do que eu vou trazer aqui pode ser visto no livro Data Mining Techniques, seminal sobre CRM e Data Mining em geral. Se você quer estudar o assunto, esse é o livro.


Relacionamento com o Cliente

Direto ao ponto: antigamente todo mundo comprava tudo – comida, roupa e outras coisas – ao vivo. Ia-se a uma loja, apontava-se o produto, dava-se o dinheiro e saia com ele pela porta. Simples assim. Olhávamos todos uns nas caras dos outros. Íamos a uma loja e não na vizinha porque gostávamos mais desta que da outra. Víamos o dono por ali, conhecíamos os atendentes, confiávamos na procedência dos produtos.

Essa convivência acabava por criar um relacionamento. Você sabe, aquela coisa que sua cara-metade discute ocasionalmente contigo, em uma sessão DR. ;-)

Aos poucos o fornecedor passava a conhecer os gostos do cliente, e este passava a confiar no fornecedor. Esse relacionamento trazia vantagens para ambos: o cliente recebia um atendimento melhor, personalizado, e o fornecedor fidelizava o cliente, tendo mais facilidade para planejar seu negócio e mais oportunidades de vendas. Resumindo, o cliente podia contar com o fornecedor para suprir suas vontades, e o fornecedor via seu faturamento e sua lucratividade aumentar graças à fidelidade do cliente.

Lembram-se como falava-se (ainda se fala?) em fidelizar o cliente? Em atendimento personalizado?

Aos poucos o mercado cresceu e sofisticou-se, e a distância entre o consumidor e o fornecedor foi aumentando. A quantidade de clientes ficou maior, a variedade dos gostos aumentou e a complexidade da linha de produtos acompanhou essa tendência.

Décadas atrás isso era um problema: mesmo na década de 80, o mero volume de clientes e a efemeridade do seu contato eram tamanhos que ficou difícil saber quem era esse cliente, e como atendê-lo melhor. Pense um supermercado, uma padaria, um posto de gasolina etc. São negócios que envolvem um volume considerável de clientes, que recebem um atendimento rápido: pega-se o produto, enche-se o tanque, paga-se e vai-se embora. Não raro esses negócios – que são apenas um exemplo – têm mais de um caixa. É muito difícil para um gerente conhecer os seus clientes nesse ambiente. Não temos mais tempo para jogar conversa fora, ou demorar muito escolhendo os produtos. É vapt-vupt.

Agora pense em redes de supermercados, padarias e postos de combustíveis. Jogue nisso tudo a Internet e a explosão do comércio eletrônico. Se antes o contato com cliente era fugaz, ao menos era físico. Com o e-commerce (precedido pelas onda das vendas por catálogos), o cliente nem mesmo aparecia mais na loja. Nem sequer temos mais uma “loja” no sentido de coisa de tijolos e cimentos!

Como construir um relacionamento com um ser quase mítico, que para todos os efeitos é invisível e que se move à velocidade da luz?

Customer Relationship

Com Data Mining.

Antes de continuar vamos abrir um parênteses sobre a terminologia.

A idéia de “gerenciar” o relacionamento é usar o conhecimento sobre a clientela para tornar cada contato uma nova oportunidade de aumentar a proximidade/fidelidade do cliente, de fazê-lo consumir de você e não do seu concorrente, ao menos na maior parte das vezes.

O conceito de “gerenciamento de relacionamento” não é trivial. Pense no gerenciamento de recursos humanos: atribuir tarefas a pessoas, deslocar e direcionar times para as atividades da empresa e tudo mais. Troque “recursos humanos” por “relacionamento com o cliente” e estamos falando de reforçar um tipo de contato (por e-mail, chat, telefone) ou enfraquecer outro, de injetar dinheiro para propaganda neste e naquele segmento sobre este e aquele produto, ao invés de abrir um comercial na TV. De usar uma oportunidade de contato para incrementar as vendas ou a satisfação do cliente conosco.

Ou forma de pensar que ajuda a entender o termo é “alavancar”: através do gerenciamento dos relacionamentos com os clientes podemos alavancar (ajudar, empurrar) o crescimento da empresa. Usamos as interações para criar ações que movem a organização para mais próximo dos seus objetivos, da sua visão.

Depois de um tempo a frase parece fazer sentido, mas só com um pouco de familiariedade com uma grande operação voltada ao consumidor é que podemos abarcar completamente o conceito.


Continue pensando, uma hora sai! ;-)


Se você entendeu a idéia na seção anterior, que era aprender sobre o cliente para atendê-lo melhor, e com isso maximizar suas vendas, basta transpor isso para o mundo do cliente sem rosto, mas que interage com a empresa. Cada interação é uma oportunidade de conhecer melhor quem está do outro lado do balcão.

CRM = Data Mining

Vejamos: temos muitos clientes, muitos produtos e, mesmo que não individualmente falando, muitos contatos de clientes. O que são esses contatos?

  • Uma compra;
  • Uma re-compra (o cliente voltou para mais;)
  • Uma reclamação;
  • Um pedido de serviço;
  • Etc.

Cada vez que um cliente interage com a empresa, ele deixa um pouco dos seus dados – identificação, localização, interesses, valores, etc. São esses dados que, agregados e acumulados, dá uma montanha de dados que esconde um ouro. Ouro esse que pode ser desencavado com Data Mining. (Mais cliché impossível.)

E Aí?

Que resultados nos traz uma solução de CRM? O que ela consome?

Insumos

Uma solução de CRM analisa dados de todos os sistemas da empresa que tenham alguma interação com o cliente – e mesmo alguns que não têm. Os mais valiosos são aqueles que dão informação direta sobre o cliente: caixas (por isso é importante pedir o CPF, já que permite saber quem é o cliente), reclamações, trocas. Canais de atendimento, como call centers, também são valiosos (por isso que a maioria pede alguma identificação de quem liga.)

Os dados não precisam ser coletados em um DW – surpresa! – mas ajuda muito fazê-lo. Coletar dados históricos, integrá-los e limpá-los são os primeiros passos de qualquer projeto de Data Mining, e por isso mesmo são os primeiros passos do projeto de CRM. Se a empresa decide por uma iniciativa de coleta de dados isolada, estanque, descartando um DW, desperdiça boas oportunidades e gera alguns problemas:

  • DW é uma tecnologia estável, e projetos profissionais de DW consomem menos recursos, com melhores resultados. Nem preciso dizer que projetos amadores, de qualquer coisa, sempre dão dor-de-cabeça, né?
  • Gera retrabalho/duplicação de esforços: se apenas o projeto de CRM coleta e organiza os dados dos clientes, qualquer um que queira usar esses mesmos dados na empresa precisa atrapalhar o projeto de CRM, ou duplicar o trabalho em outro lugar;
  • Seria mais caro: a idéia de evitar o DW é – imagino – poupar o gasto com profissionais “do ramo” e ambientes especiais. Trocar um projeto profissional por outro amador tende a causar atrasos e dificuldades;
  • CRM é uma boa âncora para DWs corporativos. Como DWs podem ser usados pela empresa inteira, ter um bom argumento a favor de um DW – como o CRM – é um bom argumento para vender a idéia do DW;
  • CRMs tendem a dar bons resultados e ajudam a melhorar a imagem de todas as tecnologias de BI na empresa, facilitando a mudança de cultura necessária (um dia aborarei isso.)

E isso é parte do ponto de vista da tecnologia. A outra parte deste lado seriam as máquinas, que podem ser muito grandes em função dos volumes de dados envolvidos, e os softwares, que podem ser Software Livre ou proprietário, mas definitivamente são escolhas secundárias.

Olhando para o lado dos recursos humanos, um projeto de CRM requer um Analista de Data Mining com experiência em CRM. Como esse profissional é um bocado caro para ter na folha de pagamentos (primeiro pela especialização, segundo pelo uso relativamente limitado de suas maiores habilidades), o mais comum é recorrer a uma boutique de Data Mining para trazer esse especialista para o projeto, temporariamente. O time do projeto é completado, via de regra, por gente da casa, com membros da TI para ajudar na parte de coleta e tratamento dos dados, e gente do negócio para ajudar na priorização e construção dos modelos.

Entregáveis

Eu adoro dizer que o entregável de um projeto de Data Mining é dinheiro, muito dinheiro!!, mas isso costuma não colar. Pena. :-) A próxima melhor definição dos resultados entregues por uma solução de CRM é “incrementar o valor do cliente”, que é feito através de ações planejadas com o auxílio da inteligência obtida da análise dos dados. Mas com o que se parece, o que é essa “inteligência”? Qual é, concretamente, o entregável do projeto, qual é o produto?

Como eu já coloquei em outro post, o entregável de um projeto de Data Mining são modelos matemáticos. Cada um destes modelos automatiza o processo de decisão em relação à próxima interação com o cliente. Há tantos modelos possíveis que eles são agrupados em várias categorias: Sales Promotion, Survival Analysis, Churn Prevention etc. etc. etc. Vamos ver alguns dos modelos mais famosos.

Para começar, um dos modelos mais interessantes é o Lifetime Value do cliente, que é uma estimativa do valor do cliente por todo seu relacionamento ao longo do tempo, ou dentro de um horizonte, como alguns meses ou anos. De posse dessa estimativa podemos avaliar com mais clareza se vale a pena ou não manter um determinado freguês. Suponha que certo cliente peça um desconto. Vale a pena dar esse desconto para ele? Se fôssemos o dono da loja, sabendo tudo de tudo, seria fácil decidir:

  • Cliente novo?
    • Sim. Parece do tipo que dá lucro?
      • Sim: dê o desconto;
      • Não: recuse o pedido;
    • Não. Cliente valioso?
      • Sim: dê o desconto;
      • Não: ofereça um desconto menor.

Agora, como ajudar a moça do call center da Americanas.com a decidir? Montando o mesmo script baseado no Lifetime Value!

A saída dessa ação pode ser encaixada com os resultados dados por outros modelos, como os que atuam no incremento das vendas. Imagine se ao invés de recusar o desconto, ou simplesmente concedê-lo, a tal atendente ainda tenha no script ramificações para:

  • Up-selling: vender algo mais caro ou mais valioso (com maior lucratividade;)
  • Cross-selling: fazer o cliente comprar alguma outra coisa, não aparentemente relacionada;
  • Recomendações: recomendar algo mais do mesmo tipo, para aproveitar o desconto.

Cada uma destas ideias é um modelo que o CRM pode gerar.

E que estratégia a organização deve perseguir? Adquirir clientes, ou se esforçar para aumentar a lealdade dos já existentes? (Pegadinha: clientes novos custam muito mais caro que os já adquiridos, por isso é sempre importante investir na manutenção da sua clientela.) Um projeto de CRM ajuda a desenhar estratégias oferecendo modelos para:

  • Campanhas de retenção, para evitar perder o cliente para a concorrência;
  • Estímulo de uso, para fazer o cliente se lembrar que possui um serviço, ou se lembrar de voltar a nos procurar;
  • Programas de fidelidade, que estimulam o cliente a decidir por nós ao invés de pela concorrência;
  • Redução de atrito: já é difícil segurar o freguês, então pelo menos vamos tentar não empurrá-lo para longe, que é o objetivo deste modelo, de Churn Reduction.

E mesmo quando temos alguns desertores, há modelos que apoiam iniciativas reparadoras. Uma dessas chama-se Customer Reactivation que, como o nome mesmo diz, tenta motivar um freguês que não nos procura a voltar a entrar em contato. Um modelo mostra que cliente é mais propenso a ser recuperado por esta ou aquela ação.

Falando em problemas como clientes, outro conjunto de modelos lidam com o risco que um cliente representa e como manter baixo esse risco. Coisas que o departamento financeiro sempre quer saber como quem tem tantos porcento de falhar no pagamento? Dos clientes que estão atrasando ou deixando de pagar, quais têm maior propensão a pagar alguma coisa, e quanto?


Sempre que eu menciono um destes exemplos você pode tentar imaginar o que estaria acontecendo na proverbial lojinha. A reativação, por exemplo, pode ser uma visita ao cliente, só para bater papo, ou para levar algo que ele gosta. Um pouco de tato pode evitar vender fiado para quem sabemos que vai dar trabalho, e a redução de atrito pode ser um pedido de desculpas por uma burrada. E o estímulo ao uso? Que tal um brinde, que ele aproveitaria melhor se comprasse algo? Não estou brincando: o programa Cliente Mais do Pão-de-Açúcar me deu, uma vez, uma tigela para comer cereal. Fofo, não? (Deu certo, só para constar – por algum tempo eu passei a comprar cereais com mais regularidade.)


Não é Para o Meu Bico

Uma espécie de regra geral para projetos de Data Mining é “precisa de grandes volumes de dados”. Ainda que grande seja uma coisa relativa, hoje em dia nunca é menos de milhões de linhas – milhões de linhas de vendas, de interações com clientes, de produtos, de acessos etc. Isso é uma coisa natural, por que a maioria desses métodos são de inferência: fazem estimativas a partir de um comportamento observado. É como o caso da moeda: não dá para saber se ela é viciada com apenas um arremesso. Precisamos de uma quantidade que mostre a tendência para sair mais cara ou mais coroa, ou então termos uma certeza razoável de que é uma moeda “normal”. Quanto mais dados, menor ou mais delimitado é o erro em relação a uma estimativa. Inversamente, quanto menos dados, maior a incerteza da estimativa.

Essa necessidade de um certo volume de dados não é motivo para barrar análises com menos dados. O erro será maior, mas alguma informação sempre é melhor que nenhuma. Projetos de Data Mining, em geral, e de CRM em particular, podem ser encetados por sua organização mesmo que você não disponha de montanhas e montanhas de dados. Apenas seja mais precavido em relação às iniciativas que vão usar os resultados para alavancar o crescimento da empresa.

Para demonstrar isso, eu deixo vocês com um caso real. Há vários anos, numa das minhas turmas da 4Linux, tive um aluno dono de um supermercado, de São Carlos. Ele queria dispor de relatórios e análises sobre seus dados (principalmente dos caixas) e, como era muito caro contratar um projeto, decidiu fazer tudo ele mesmo. Eu fiquei impressionado, afinal ele era o dono do supermercado (acho que tinha algum sócio, não me lembro), que não era uma loja pequena. Assumir um projeto técnico com uma empresa inteira para tocar, não importa quão pequena, é um desafio e tanto. Bom, ele terminou o curso, e voltou para São Carlos.

No começo de 2015, estimulada pelo Caio Moreno, o Prof. Coruja, a comunidade de Pentaho de São Paulo se juntou para um Meetup. Qual não foi minha surpresa ao reencontrar esse empresário lá?! Já fiquei impressionado de vê-lo se deslocar para um encontro num final de dia, começo de noite, de uma quarta-feira em São Paulo, mas eu fiquei de queixo caído quando ele falou o que estava fazendo: não apenas implantou BI no supermercado, como agora estava atrás de Data Mining para fazer CRM!!! :-O A meta dele era simples, modesta até, mas mesmo assim seria capaz de melhorar a rentabilidade do negócio: se eu não me engano, ele queria reduzir perdas por vendas a prazo. O simples fato de passar da administração do risco de manual para automática já teria impacto positivo no negócio dele.

Nunca mais falei com ele, infelizmente, mas não tenho a menor dúvida que conseguiu, e que hoje deve estar fazendo mais alguma coisa surpreendente e inteligente.

Customer Intelligence

CRM é um termo que ficou meio desgastado – sabe, como OLAP, metadados e o próprio BI. Como o conceito de “gerenciamento do relacionamento” não é algo transparente, imediatamente apreensível, muitas empresas se apoderaram dele para usar em qualquer coisa e surfar a onda do mercado (de novo.) Daí hoje em dia temos CRM que maneja envio de e-mails (mala-direta), CRM que recebe/dispara teleatendimentos (call center), CRM que monitora redes sociais (social-thingamajig) blá blá blá. Nenhum destes casos responde pela “coisa”. Para se livrar desses mal-entendidos, a empresa líder de BI, o SAS, renomeou o campo como Customer Intelligence (“excelente” abreviação: SAS CI – entenderam? Sasci, Saci. Kkkk…)


Bom, o SAS já renomeou quase tudo de BI (incluindo BI, que virou BA), por isso não há nenhuma novidade aqui. Para mim, porém, o termo Customer Intelligence é tão opaco quanto Customer Relationship Management, o que sempre me conduz à mesma conclusão: a ideia não é ajudar, é ser dono exclusivo de buzzwords. SAS, SAS, tsc, tsc… Adiante.


A solução SAS é completa, com planejamento, estratégia, gerenciamento de campanhas, medida de eficiências etc. Não vou entrar nela porque o post é sobre CRM e não sobre o SAS e seus produtos, mas vale a pena conhecê-la. Se quiser ver um pouco mais da cara do resultado de um projeto de Data Mining, que fica por trás de um projeto de CRM, pode ler um pouco sobre o SAS/Enterprise Miner.

Conclusão

Uma forma de entender a disciplina BI é como uma ferramenta de apoio à decisão, ou de automação da decisão. Neste sentido, projetos de Data Mining produzem recursos empregados na automação das decisões de uma empresa, melhorando a precisão dessas decisões e aumentando a velocidade com que são tomadas. Em uma empresa moderna, que dependa de computadores no seu métier diário, minguém consegue manter tudo dentro da cabeça para conseguir entender o que precisa ser feito, e como. Só BI consegue isso, através de Data Mining, em geral, e CRM, em especial, no aspecto da clientela.

Gerenciamento do Relacionamento com Clientes, ou CRM, é um projeto que busca entender o Cliente para melhor atendê-lo.

Um projeto de CRM entrega modelos matemáticos que alimentam desde o planejamento estratégico até a implementação de iniciativas e ações na empresa, sempre com o objetivo de maximizar o valor do cliente, enquanto ajuda a organização a prestar um serviço de maior qualidade. Em outras palavras:


Um projeto de CRM dá ao cliente um atendimento melhor, personalizado, e ao fornecedor a maximização do valor de cada cliente.

Projetos de CRM são ganha-ganha.


Porque tão poucas empresas investem em Data Mining, para mim, é um mistério. Que quase nenhuma tenha um projeto de CRM, então, é um mistério envolto em um enigna.

No próximo post (que não será semana que vem): Credit Scoring. Até lá! ;-)