Feliz Ano Novo!

Engraçado como nosso cérebro roda em círculos, não? Eu pelejei, pelejei, mas não consegui imaginar nenhum nome melhor para este post. Logo, decidi transformar o último post do ano em uma tradição, no qual eu fecho o ano corrente e penso sobre o próximo, e chamá-lo sempre de feliz ano novo.


Quem me acompanha sabe, eu sou pregu… prático. :-) Não consigo inventar nada melhor? Então transformarei minha falta de criatividade em tradição. :-D Né não, Lavosier?


Sacudida

Já basta de preguiça com o título do post. Por isso eu usei “sacudida” ao invés do clássico “balanço”. (Nossa, tá piorando rápido!)

Foi um ano bem variado: teve de Data Vault a painéis, passando por ferramentas e técnicas. Queria ter feito mais, como testar bancos colunares com mais detalhe e estudar pré-agregações, mas estou satisfeito com este resultado.

Foi um ano, também, de interação maior com vocês, meus leitores. Isso é o que mais me animou, o que me supriu de motivação quando eu estava sem idéias.


Obrigado de novo. ;-)


Eu também botei um pé em dois assuntos nos quais eu, definitivamente, ainda sou um novato: BigData e Data Lake. Espero ter contribuído comentários relevantes tanto do ponto de vista concreto, ou seja, para quem precisa se envolver no assunto, como do ponto de vista filosófico, indicando os aspectos que me parecem comerciais de mais e valiosos de menos para os clientes e usuários desse tipo de projeto.

E uma das coisas que eu mais gostei: a palestra na FATEC. Só aquilo já teria feito deste um ano excepcional para mim. Obrigado à Profa. Célia , da FATEC Tiradentes, e ao Prof. Josenyr Santos, da FATEC Zona Sul. Fizeram um menino feliz. ;-)

Aprendendo a Pensar Fora da Caixa

Graças a uma maior “convivência virtual” com próceres do gabarito de Jorge “Kotick” Audy, Arthur Luz’s Data Light e o impagável Rafael Piton, acabei me abrindo para as sobreposições entre BI e toda paisagem de técnicas e filosofias ágeis, novas tecnologias de bancos de dados e formas de se fazer a coisa, e uma visão do mercado profissional de BI – respectivamente.

Vale a pena destacar alguns pontos:

  • Audy: consegui conhecê-lo pessoalmente (!!!) e ainda participei de um dos seus lendários eventos. Não tem muito o que falar: gigante em pessoa, um coração imenso, profissional refinado, profundo, experiente etc. etc. etc. Hoje ele é O cara de Ágil e inovação no Brasil – LEIA-O!! :-)
  • Arthur: uma alma de professor com estilo de um cronista. Um cara que eu leio para ver o que a Microsoft está fazendo – gostem ou não, eles investem em novidades e é imperioso saber para onde estão indo! – e para aprender como se conduz um trabalho completo e bem-feito. Ele tem séries sobre diversos temas da área. Claro que interessa mais a quem vive no mundo Microsoft, mas o estilo dele é leve e gostoso de ler e sempre acaba sobrando algo para todo mundo. Este post, por exemplo, que conta sobre as novidades de uma release do MS SQL Server 2016,  é um desbunde de minúcias, velocidade e abrangência;
  • Piton: um cara que não fala sem embutir valor. Ele usa um bordão muito parecido com o meu – ele fala BI é conceito, não é ferramenta, enquanto que eu digo BI é solução, não é ferramenta – e sempre traz ótimas dicas. Não deixe de ver o vídeo dele sobre como achar centenas de vagas. É VERDADE! Ele mostra um site que eu não conhecia, mas que não vou colocar aqui para pagar o devido tributo ao trabalho dele. Passem lá, deixem um like e naveguem para o link indicado. E assinem a newsletter dele, é bem bacana. ;-)

Preparar, Apontar, Escrever!

E agora? Para Onde?

  • Beltrano S/A, v2.0: consegui organizar as idéias e planejar meus próximos livros sobre Pentaho. O primeiro passo desses novos projetos será redesenhar a base usada no Pentaho na Prática, com processo de carga parametrizado para criar um número arbitrário de linhas, e assim conseguir bases de qualquer tamanhho – milhares, milhões, bilhões de registros – que vão servir para ir mais longe em exercícios de otimização e performance no Pentaho. O projeto continua livre e vou postar as novidades conforme aparecerem;
  • Hadoop: passou da hora de eu escrever algo mais técnico sobre ele. A tecnologia está madura e acredito que agora tenho algumas idéias sobre como posso agregar valor à comunidade. Veremos se eu dou conta;
  • Bancos Colunares: usando o Beltrano 2.0, vou tentar montar um laboratório de dezenas e centenas de milhões de linhas. É o trabalho que eu mais quero fazer!
  • memcached e Hazelcast: Na sequência de grandes volumes, caches externos são obrigatórios para melhorar a performance de consultas. Ainda preciso estudar, mas tenho um amigo que meu deu boas dicas e, no mínimo, isso eu vou tentar trazer;
  • Soluções: ainda não fiquei feliz com a série Soluções Clássicas. Está muito etéreo, muito “é assim, é assado”. Vou tentar achar casos de soluções de BI no mundo real e mostrar aqui.

Mas isso é só uma parte. Instigado por posts como este fantástico Aula de BI, eu vou mirar também em assuntos mais abertos, conceituais e misturados:

  • BI com Ágil: como funciona um projeto assim?
  • {MVP, Design Thinking Etc.} x {BI}: traduzindo, produto cartesiano de BI com MVP, DT, Scrum, Gamefication etc. etc. etc. Quero investigar como ficam as tais soluções clássicas de BI dentro de um framework de criação de produto/valor, envolvendo tudo que eu li neste ano e o que mais aparecer. Será que dá para fazer?

    Valei-me Santo Kotick! Eu vou te alugar, mestre, esteja avisado! :-D


  • Negócios em geral: BI é sobre usar dados e agregar valor. Quero explorar essa interface toda, entre TI, negócios e conhecimento. Quero tentar fazer em BI o que o Audy faz com Ágil. Sem noção? Presunçoso? Sim, claro, porque não? Ou não seria euzinho, hehe. ;-)

Nem sei o que vai sair disso tudo, mas estou rascunhando vários posts em diversos temas. Só esperando uma próxima quarta-feira para saber…

Pentaho – A Nova Série

Este ano acabou representando uma pausa na minhas publicações. Eu precisei deixar o assunto quieto para as idéias maturarem, e chegou o momento de pegar firme de novo.

Sem mais delongas, com vocês minha nova série de livros de Pentaho!


Uaaah, a galera vai ao delírio,
luzes, fogos, explosões, tambores!!!…
:-D


(quem me dera…)

Enfim. ;-)

Mesmo com a (na minha opinião) excepcionalmente boa recepção do Pentaho na Prática, ele é um tijolo com quase seiscentas páginas. Se não fosse a auto-publicação, nunca teria vindo a público em sua totalidade. Isso é ruim por vários lados:

  • Obriga o leitor a levar tudo, mesmo que ele queira só um pedaço;
  • O leitor acaba pagando pelo que não quer, o que dá uma sensação de desperdício – eu sinto isso quando compro esse tipo de livro e imagino que meu leitor sofra o mesmo;
  • É praticamente impossível lançar um livro de papel deste tamanho;
  • Atualização: mesmo que algo mude em uma apenas uma das ferramentas, sem afetar as outras, o livro precisa de uma nova edição inteira. Fazer só uma parte deixaria o trabalho com uma qualidade muito ruim – começaria a parecer uma colcha de retalhos, um caça-níquel, que é o tipo de coisa que eu mais abomino. Fazer por fazer, eu prefiro não fazer.

Por esses e outros motivos eu decidi quebrar o PnP em vários livros. Por enquanto tenho três planejados, separados em função das necessidades que me parecem ser buscadas em conjunto:

  • BA Server: deve ser o primeiro, já que é o pedaço mais desatualizado do PnP. Vai ter o de praxe – instalação, configuração e uso – e mais cache externo e otimização do Mondrian, no mínimo;
  • Apresentações de Dados: como muitos já possuem DWs prontos, acredito que a próxima coisa mais útil seja mostrar coma instalar, configurar e usar as ferramentas de exploração e apresentação de dados, como o PRD, OLAP e painéis;
  • Integração de Dados: o (provavelmente) último a sair será só sobre o PDI, com tudo que eu conseguir colocar e ainda lançá-lo dentro dos próximos trinta anos. :-) Quê?! É coisa pra chuchu!!! E desta vez eu pretendo colocar clusters e bancos colunares – e Hadoop!!!

E cada um custará uma fração do preço do PnP. Acredito que isso dará mais liberdade para o leitor, que poderá investir só no que precisar. Daí, quando – e se – quiser, pode investir nos outros. E não se iludam, isso também é financeiramente mais vantajoso para mim, sem contar que é mais fácil atualizar um volume de cada vez quando ficar obsoleto.


Atenção!

Se você comprou o PnP, atualizou para a segunda edição e se inscreveu no “Livro Secreto”, então você vai poder comprar todos esses livros a um preço simbólico, e antes de todo mundo. É o mínimo que eu posso fazer para expressar minha contínua gratidão à sua coragem. ;-)

Logo depois, quem está inscrito no GeekBI, meu fiel leitor(a), será avisado e receberá um desconto especial – claro! ;-)

Mas não se preocupe se você não tem paciência pra me aguentar te torrando toda semana: como sempre, os lançamentos serão anunciados na lista Pentaho-BR, também com uma boa oferta. ;-)


Putz! Agora que eu anunciei, vou ter que entregar! Ai… kkkk

Conclusão

Já descontados os que eu não salvei, como vagas de emprego e anúncios em geral (deve dar ai uma meia-dúzia), são quase sessenta posts, escrevendo toda quarta-feira, tendo falhado apenas uma única vez. Gostaram? Foi bom para vocês também? ;-)

Eu estava decidido a não repetir a experiência, mas do nada começou a brotar idéias, assuntos e dúvidas. Então vou assumir o mesmo compromisso em 2017: um post por semana, no mínimo, com começo, meio e fim e uma proposta clara de valor para você, meu fiel leitor. Mas esteja avisado que não haverá repetição ou lugar-comum por aqui, a não ser para desmontá-lo ou desmistificá-lo. (Aaaaiii gostoso!!! Acaba, 2016!!!! kkk)

E livros!!

Últimas palavras?


Já acabou, Jéssica?


Então aqui vai:

FELIZ ANO NOVO!!!

Vejo vocês em fevereiro de 2017, bem mais sério e mais comportado que hoje, prometo. Mesmo, mesmo!

Até lá! ;-)

Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:


Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.


Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)

Exame & BigData

A revista exame publicou, em 5 de março deste ano (2016), um artigo comentando sobre o mercado de trabalho para “Cientistas de Dados”.

Eu sempre implico com nomes “da moda” porque, na minha opinião, eles desvalorizam o profissional sedimentado, experiente, abandonando expressões que funcionam por um palavreado mais colorido. Ocasionalmente a coisa muda, claro, e esses nomes precisam mudar junto, mas em TI há uma competição disfarçada para ver quem vem com a próxima buzzword. No final essa disputa acaba por atrapalhar a vida da TI porque tanta mudança forçada impede a construção de senso comum e de uma cultura particular.

Pergunte a um engenheiro mecânico o que é um carburador, ou se eles usam “camâras adiabáticas para oxiredução explosiva”. Ou para um financista se ele fala juros compostos, ou “taxa de interesse recursiva”.

Entendeu a idéia? Para quê mudar uma expressão se ela adequa-se perfeitamente?

Pior: uma pessoa errada, mas com muita certeza, vai levar outros a errar também. É preciso estar de posse de um conhecimento sólido para poder resistir à pressão do hype corrente.

Big Data, Hiper Hype

Nestas últimas semanas eu tenho escrito sobre BigData, mas ontem eu não tinha assunto. Eu não sabia sobre o que postar, e depois de um dia cheio e tela em branco, eu simplesmente desisti.

Sem inspiração? Que tal tocado como gado?
Sem inspiração? Que tal tocado como gado?

Hoje eu acordei e olhei de novo para minhas anotações e achei este rascunho aqui, sobre a Revista Exame, e vi um bom fechamento para a série. Junte-se a isso que eu repeti minha palestra sobre BigData para a Fatec Zona Sul, cujo foco era desfazer confusões antes de começarem.

Leia a reportagem, é interessante. Entretanto, lá no meio, quando tudo estava indo bem, algo dá errado:


“O big data não se resume a um processo de automação. Seu objetivo é entender melhor o que acontece numa empresa, o que os clientes querem e, assim, modificar o negócio”, diz Jorge Sanz, diretor do Centro de Business Analytics da Universidade Nacional de Singapura, um dos grandes centros de big data da Ásia. Esse processo requer softwares capazes de captar os dados relevantes — e, acima de tudo, pessoas treinadas para interpretá-los.


Eu copiei o parágrafo inteiro como está. Releia. Releu? Entendeu? De novo, devagar:

“O big data não se resume a um processo de automação.”

“O” big data? Agora é uma coisa só, um objeto que anda por aí, e não mais uma tecnologia, mas um objeto. Ok, vamos dar uma colher de chá, já que muitos profissionais ainda chamam BI de “O” BI.

“Não se resume a um processo”: então “big data” é um processo? Se ele diz “não se resume”, então ele já classificou o assunto como um processo; apenas vai adiante e diz que não é apenas um processo – mas implica que é um de qualquer forma. Ou seja, passou de tecnologia-objeto (que demanda o tal do artigo definido masculino singular, “O”) para uma coisa que também é um processo. Mais uma confusão, mas vamos relevá-la de novo, em favor da prosa da reportagem.

“De automação”: e de onde veio isso? Do parágrafo anterior no artigo, onde ele começa associando computadores a automação. Até são coisas relacionadas, mas chamar Hadoop de automação é um pouco demais. Mas mesmo assim, vamos em frente.

E aqui o assunto descarrilha de vez:

“Seu objetivo é entender melhor o que acontece numa empresa”

É um repórter competetente, entrevistando um executivo relevante de uma enorme instituição financeira nacional. Quer dizer, não é um par de manés, não! São profissionais experientes, gabaritados e entendidos no assunto…

… que meteram os pés pelas mãos. Há décadas existe um termo que usa como definição justamente essa frase – Seu objetivo é entender melhor o que acontece numa empresa: Inteligência de Negócios, vulgo BI.

O que ele fez foi chamar uma coisa de outra. Foi vender banana anunciando carambola, já ambas são compridas, amarelas, tem casca, são frutas… Só que não são a mesma coisa! É um esforço feito para dar ribalta a uma expressão da moda, dando um gancho (sigam este link, é hilário!) em outra!

Fora, Inteligência de Negócios! Agora queremos "o big data"!
Fora, Inteligência de Negócios! Agora queremos “o big data”!

Existe uma outra explicação, que é dizer que ele não sabia mesmo do que estava falando, mas isso é um pouco demais para aceitarmos. Afinal, é a maior revista de negócios do Brasil, não um panfleto de bairro. Não atribuiriam a um repórter uma tarefa que ele não conseguisse desempenhar adequadamente. Isso feriria a reputação de ambos – revista e repórter. A menos, claro, que seu público não fosse capaz de perceber a confusão, mas aí é demais para aceitarmos porque estamos falando de um público qualificado, líderes, executivos e profissionais de todos os ramos, conhecedores de assuntos mil…

Entenderam como funciona? Ninguém tem bem certeza do que é algo. Aí a moda vem, avassaladoramente, e sacode tudo junto. No final fica parecendo aquela piada:


O bêbado entra no ônibus, passa a roleta e vai para trás. De lá, grita:

  • Do lado direito todo mundo é palmeirense! Do lado esquerdo todo mundo é corintiano!

Ao ouvir isto, levanta um do lado direito e fala:

  • Eu não sou palmeirense!!!

E todo os passageiros começaram a xingar o bêbado e ameaçando cobri-lo de bolacha. O motorista, para evitar confusão, freia bruscamente e todos caem. Um dos passageiros se levanta, pega o bêbado pelo colarinho e pergunta:

  • Fala de novo, safado! Quem é palmeirense e quem é corintiano?!

  • Agora eu não sei mais. Misturou tudo…


Não dá mais para saber quem é quem, porque o jornalismo especializado misturou tudo.

Conclusão

A reportagem segue nesse mesmo ritmo, dando novos nomes a coisas já estabelecidas. Por exemplo, em certo momento ele diz que os cientistas de dados têm remuneração superior à dos técnicos, que até o surgimento do big data eram os responsáveis por cuidar da manutenção dos bancos de dados. Ele misturou DBAs com analistas de DW/ETL, com Analistas de Data Mining, com Hadoop, com Bancos Relacionais… Em metade de um parágrafo, em menos de 30 palavras, causou-se estrago para pelo menos três áreas:

  • DBAs fazem a mesma coisa que cientistas de dados se você não usar “big data”;
  • Cientistas de Dados são DBAs para “big data”;
  • A manutenção de um Hadoop, uma plataforma de clusterização escrita em Java, é feita por um cientista de dados, enquanto que a de um Oracle, um banco de dados relacional, é feita por um técnico, e são a mesma coisa do ponto de vista funcional;
  • E Data Mining?

Esse tipo de artigo confunde um número de conceitos complexos para uma audiência em geral leiga nestes mesmos tópicos. Por ser um veículo de projeção nacional e respeitado, bem-conceituado, muitos tomam o que sai ali por fato, por verdade canônica. Aos poucos essas confusões tomam o lugar das verdades nas empresas, impactando planejamento, contratações, e até debates. Como é que um cara qualquer, um joão-ninguém como eu pode argumentar com o “repórter da Exame”? A quem acreditam vocês que o público atribui maior conhecimento? :-)

E pior ainda: como é que um profissional recém-formado pode querer colaborar com a empresa, se tudo que ele fala é contestado pelo chefe que viu tudo diferente na revista de negócios mais famosa do Brasil?

Tem mais razão e está mais certo que fala com mais convicção? Não, né? Repasso aqui o conselho que dei àqueles alunos das FATECs:

Use sua inteligência para filtrar. Critique e questione tudo. ;-)
Use sua inteligência para filtrar. Critique e questione tudo. ;-)

É isso. ;-)

Full Metal BI Itch

Outro dia assisti um filme de SciFi que eu adorei, No Limite do Amanhã, ou Edge of Tomorrow no original em inglês. (Clique aqui para ver o trailer.)1

Nele o herói “ganha” o poder de resetar o dia, ativado pela morte. Assim, cada vez que ele morre ele volta para o início de um certo dia – sempre o mesmo, sempre na mesma hora. Como o dia recomeçou, as coisas se repetem, sempre as mesmas, desde que ele tome as mesmas decisões. Logo ele percebe isso: os eventos futuros mudam em função das ações dele.

Por exemplo, na primeira “vida” ele é emboscado pelo inimigo logo que chega na praia. Na segunda, ainda sob o choque de ter morrido pela primeira vez, ele morre no mesmo lugar. Na terceira vida, quando ele chega na praia ele já sabe onde o inimigo vai estar, e acerta um tiro em cheio… e sobrevive! Apenas para morrer segundos depois, de novo, e reiniciar o dia pela quarta vez.

E assim ele vai: a cada vida que ele “revive” ele já sabe onde falhou da última, e avança mais um pouco.


Agora que eu parei para pensar um pouco, exatamente como em um video-game!


Amei aquele filme. Adoraria pode esquecê-lo só para poder vê-lo de novo e sentir a mesma emoção que eu senti da primeira vez.

E o que ele tem a ver com BI?

Guenta as pontas aí, já vou amarrá-las. Antes, um pouco sobre…

Técnicas de Garimpagem de Dados

Se você ainda não leu, leia. Esse deve ser o livro de BI mais de BI que existe:

O livro de BI mais de BI que existe. Leia!
O livro de BI mais de BI que existe. Leia!

Em sua introdução ele explica uma coisa chamada “ciclo virtuoso do Data Mining”, na minha tradução livre:


A promessa do data mining é encontrar padrões interessantes dormentes em todos esses bilhões e trilhões de bits jazendo em memórias computacionais. Meramente encontrar esses padrões não é o suficiente. Você deve responder aos padrões e agir sobre eles, em última instância transformando dados em informações, informações em ações e ações em valor. Esse é o ciclo virtuoso do data mining, resumidamente.


Capítulo 1, páginas 9 e 10 da terceira edição física, ou locação 676 para quem tem o livro no Kindle.

Acho que não preciso interpretar o que ele disse, não? É muito óbvio, certo?

Se é tão óbvio, seu projeto de BI deve estar fazendo, não?

Ah, não estão fazendo porque seu projeto é de Inteligência de Negócios, não de Data Mining? Entendi. ;-) Vamos ver o início do capítulo 3, então?

O que é que pode dar errado, não é mesmo?
O que é que pode dar errado, não é mesmo?

Este capítulo do livro vai esmiuçar um problema de Data Mining em suas partes e aspectos gerais e comuns entre várias técnicas. Não vou traduzir tudo que está escrito aqui, exceto por este trecho:


Data Mining is a way of learning from the past in order to make better decisions in the future.


Traduzindo mais ou menos ao pé-da-letra:


Garimpagem de Dados é uma forma de aprender com o passado a fim de tomar melhores decisões no futuro.


The Ultimate Past is The Future!

Vamos voltar ao filme: a cada vez que o herói morre, ele volta para o início do fatídico dia. Naquele momento, o futuro ainda não aconteceu mas, na cabeça dele, já. Ou seja, para ele, o passado é uma história que já aconteceu, e está para se repetir. Ele pode, portanto, usar o que aprendeu na sua “vida anterior” para tomar melhores decisões… no futuro!


Loucura, não? Filmes de Ficção Científica com viagem no tempo são mesmo de dar nós nas nossas cabeças. Enfim, adiante.


A esta altura acho que é impossível você não notar a ligação entre Data Mining/BI e o filme. Falam da mesma coisa!!

Isso não acontece na vida real, claro, mas… E se pudesse acontecer? E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

Você há de concordar comigo que, se pudesse mesmo voltar um ano, muito provavelmente faria alguma coisa diferente. Duvido que você não tenha um único arrependimento sequer. Não? Mesmo? E o dólar?

A-há! Agora percebeu, né? Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

Curiosamente, esse poder de “prever o futuro” existe hoje, mas raros usam-no. Quem dá a uma empresa o poder de prever o futuro é justamente Data Mining, em particular, e Inteligência de Negócios, em geral!

Claro que não é possível prever, com exatidão, o valor que o dólar vai ter amanhã, ou semana que vem, ou… Não se trata disso. Se trata de, sabendo como um negócio funciona, bolar uma equação matemática – um modelo matemático – que ajude a calcular as chances de determinadas situações acontecerem.

Daí, baseados nesse modelo, que é a informação tirada dos dados, podemos tomar decisões com chances melhors de sucesso. Evidentemente não é uma decisão garantida, mas entre optar por um caminho ao invés de outro por pura intuição, ou fazer uma escolha embasado no que já aconteceu, obviamente preferimos apostar no que já vimos acontecer.

O arriscamos no cara-ou-coroa, ou apostamos em algo mais sensato.

Odd Squad

Um bom exemplo de como Data Mining age sobre nossas decisões pode ser vista no seriado infantil Esquadrão Bizarro, episódio “Undercover Olive”.

Sem entrar nos detalhes desse seriado, que é divertido pra chuchu, a história é simples: os vilões roubaram o mapa para o quartel-general dos mocinhos – o tal Esquadrão Bizarro – e vão presenteá-lo a quem vencer o torneio de jan-ken-po do mal. Para impedir que esse mapa caia nas mãos de qualquer vilão, o Esquadrão Bizarro decide mandar uma agente, disfarcada (undercover) para participar do torneio e ganhar o mapa. Eles contam com uma vantagem: Oscar, cientista do grupo, analisou torneios anteriores e fez a contagem de cada movimento (pedra, papel ou tesoura) de cada vilão. Assim, quando a agente Olívia disputa um jogo, o Oscar “sopra” por rádio qual opção ela deve fazer para ter a maior chance de vitória.

O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.
O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.

No começo é fácil: a maioria dos vilões tem algum padrão, e eles usam esses padrões para ganhar. Mas quase no fim aparece um vilão que é aleatório! Ele sempre usa quantidades praticamente iguais de cada movimento, aleatoriamente. Não existe escolha mais provável, e a equipe fica em uma sinuca de bico: chutar qualquer coisa, e arriscar, ou se agarrar ao método que usaram até ali e fazer um chute calibrado?

É como Data Mining: pode ajudar muitas vezes, mas existe sempre o risco de errar pois não é uma previsão exata.


O Esquadrão Bizarro é um programa para crianças, que usa aquele fino humor britânico. É praticamente um Dr. Who para crianças, e usa uma pancada de clichès. Oscar, o cientista do Esquadrão, é obviamente inspirado no Q, o cientista do MI:6, das histórias do James Bond. O sistema de tubos é uma interpretação infantil dos teleportes de Star Trek, e assim por diante. E tem as galinhas-laser, uma birutice que não remete a nada, só piração mesmo. ;-) Meu filho de sete anos (e eu) adora(mos), mas o de dez acha uma chatice.


Ciclo Virtuoso do Conhecimento

Apesar de o livro tratar de Data Mining e por isso usar a expressão Ciclo Virtuoso do Data Mining, na minha opinião o correto seria falar Ciclo Virtuoso do Conhecimento ou Ciclo Virtuoso da Inteligência de Negócios, já que não é a garimpagem de dados que eleva a rentabilidade da empresa, mas sim o conhecimento gerado por meio de um processo de Data Mining que provê as melhorias.

Do início do terceiro capítulo, eis o ciclo:

  1. Identificar o problema;
  2. Transformar dado em informação;
  3. Tomar uma ação;
  4. Avaliar o resultado.

Auto-explicativo, não?

Conclusão

Comprar ferramentas, montar DWs, entregar dúzias de dashboards, etc. etc. etc. são ações tidas como “de BI”. São todas vazias, inúteis e até um desperdício de dinheiro se elas não forem construídas dentro do Ciclo Virtuoso do Conhecimento, no qual todos esses projetos e ferramentas são aplicados na construção de conhecimento, que depois é usado para tomar uma ação. Sem aplicar o conhecimento obtido em uma ação concreta, todo esse esforço terá sido desperdiçado, terá sido em vão.

Volto a frisar:


Se sua empresa não tem um problema para resolver, então não precisa de BI.


E se tem um problema, não começe comprando uma ferramenta bacana, ou subindo um projeto de “Data Lake”, ou coisa que o valha. Não.

Comece pelo começo: identifique o problema.

E sempre tome uma ação. Ou você vai viver todas as suas vidas repetindo os mesmos erros e morrendo no mesmo lugar.

Está sentindo essa coceira por BI?

Aquilo não é uma espada, é uma hélice de helicóptero!
Aquilo não é uma espada, é uma hélice de helicóptero!

Até a próxima! ;-)


  1. Há uma ligação entre o título do post e o filme. Assista-o e descubra. ;-) 

Santa Inquisição, Batman!

Um ex-aluno mandou um e-mail com uma pergunta simples, fácil até:


Olá professor como vai?
Fui seu aluno da última turma da 4linux de Pentaho e estou interessado em
usar o PDI como webservice e também em usá-lo para fazer stream de arquivos.
Você tem alguma referência sobre isso?


Uau, eu ministro esse curso há 7 anos e sempre aprendo coisas novas com meus alunos! PDI para stream? Quem pensaria nisso?

E porque ele pensou? Bom, eu respondi:


Vou bem, obrigado, e você? Tudo em riba? :-)

O PDI, especialmente combinado com um ESB ou mesmo com o BA Server, pode se tornar um provedor de webservices. Existe literatura sobre isso aqui e aqui.

Agora, sobre streaming é mais complicado. Já vi um exemplo de ler uma stream contínua do Twitter, mas nunca ouvi falar de servir streaming com o PDI. Procurei um pouco, mas não vi nada…


Só que não é assim que funciona. Veja, ninguém chega a um médico e pergunta “doutor, o ácido acetilsalicílico pode ser usado contra angina?”

Meu complemento:

Qual é, exatamente, seu caso de uso, sua necessidade?

E veio a resposta dele:


A questão do stream seria para transmitir arquivos entre servidores. Pensei em um webservice em C# que seria consumido pelo PDI, que enviaria arquivos através dessa sessão! O que acha? Ou usar um daqueles componentes de post para tentar enviá-los! Não sei bem ainda como pensar.


WTF?! Se você está coçando a cabeça, imagine eu.

O que eu consegui entender dali foi que existe um problema e ele imaginou que passar um arquivo por streaming resolveria esse problema. Note que já fomos do “dá para fazer X com Y?” para “preciso fazer Z, mas não sei bem como”.

Minha resposta:


Veja, transferir arquivos é o que você quer fazer. A questão é: que problema você resolve ao fazer isso? Qual é a “dor” que te motivou a buscar esse “remédio”? ;-)

É que, devido às normas de segurança, eu não posso usar métodos normais como compartilhamento entre máquinas ou sftp. Esses arquivos serão transmitidos pra outro servidor e redirecionados por email! Voce tem alguma outra sugestão? Eu pensei em stream porque lembrei daqueles servidores do Kazzar de transferência de música! A ideia era transmitir via stream e da memória mesmo, do outro servidor, passar por email.

É muita viagem? Heheheh


Sim, meu caro aluno, bastante! :-D Mas eu admito que foi muito criativo.

Notaram como agora estamos mais perto do problema, mas ainda não chegamos lá?

Pois foi o que eu disse:


Estamos chegando lá!

Pelo que você contou, o problema que você tem em mãos é resolvido com a transferência de arquivos, que não dá para ser feito por métodos mais ordinários, simples. Que problema é esse? Que necessidade é essa, que vai ser resolvida pela transferência de arquivos?

Transferir os arquivos, em si, é só a operacionalização da solução, não a solução do problema. O problema não é “como transferir arquivos”, mas sim o que requer que arquivos sejam transferidos.

Confuso? Vai melhorar, apenas pense um pouco mais. ;-)


Eu estou editando nossa correspondência para ficar mais clara e sucinta, mas confesso que eu mesmo não tenho bem certeza do que eu queria dizer naquele final… Enfim… ;-/

O fato é que surtiu efeito:


A necessidade é a seguinte professor!

Estou montando o BI aqui na empresa e temos muitos requisitos de segurança devido à norma PCI1.

Preciso prover relatórios por e-mail, o que é muito tranquilo de se fazer com Jobs e Transformations do PDI. O problema é que os arquivos serão gerados em uma máquina “interna”, que tem acesso ao banco de dados, mas essa máquina não pode falar com o servidor de e-mail, que está em um servidor “externo”, com acesso à Intranet.

A solução é enviar os arquivos de relatórios renderizados para um servidor intermediário, que daí os enviará por e-mail. Seria fácil se pudesse usar SFTP (que inclusive é um componente PDI), mas ainda não consegui a liberação para isso.

Por isso a ideia do stream: eu controlaria a transmissão do webservice a partir do “lado de fora”, onde montaria o e-mail com anexo para então enviar aos usuários.


U-la-lá! Envio de relatórios por e-mail, prejudicado por causa do bloqueio da rede por conta de normas de segurança! ESSE é o problema.

Meu comentário:


Ah! Agora sim! :-) Esse é o problema.


Foi o que eu disse…

No fundo o caso dele é uma situação complicada mais por conta da norma PCI1 que dos dados ou da tarefa em si. Na verdade, e se você ler a norma PCI vai entender isso, provavelmente o PDI vai poder fazer pouco por ele. É uma questão mais de administração e aderência a regras que ferramentas em si.

Por Quê Até Sangrar a Língua

O que eu queria trazer para divir com vocês era um caso real da dinâmica que rola em todo processo de levantamento de requisitos em BI. O mesmo ocorre em outros cenários, mas em BI isso é crítico: o cliente chega pedindo a receita do remédio para ele ir até a farmácia, comprá-lo e tomar sozinho. O cliente não está se reunindo com o analista de requisitos com quem vai ao médico e coloca uma situação, descrevendo os detalhes e perguntando o que fazer.

Não!

O clientes vão para sala de reunião dizer o que eles querem, e em 90% dos casos assumem que já bolaram a melhor solução, e que cabe ao projeto apenas implementá-la. Poucos carregam humildade o bastante para questionar a própria opinião ou, melhor ainda, oferecer o problema e pedir orientação.

Esse pequeno exercício de vai-e-vem, de abrir caminho no cipoal de achismos e “viagens” até pisar no cerne da questão, é o feijão-com-arroz do levantamento de requisitos em BI. Se você quer ajudar mais seu cliente, sofrer menos no desenvolvimento e passar menos frustrações, aprenda a perguntar porquê até não sobrar nada, até a língua sangrar!

Fábio, drama queen

:-D

Claro que a coisa precisa ser feita com um mínimo de tato e inteligência, ou vai virar uma patetada digna do Chaves.

Chamam isso de técnica dos “cinco porquês”, pois ao perguntar “por quê?” pelo menos cinco vezes chegamos à raiz de qualquer coisa. Este blog tem um texto mais detalhado.

Por Que Sim!

Fui vendedor de soluções de BI e depois de algum tempo percebi que 100% dos clientes pediam coisas que achavam que solucionariam o problema deles, mas que se eu vendesse o que eles pediam nunca daria certo.

Para entender o problema do cliente e descobrir o que resolve – ou seja, qual é a Solução de BI que ele precisa – é preciso um tempo de relacionamento, uma alma insatisfeita e muita paciência. Raramente você vai conseguir perguntar porquê? cinco vezes, de cara, na mesma reunião ou telefonema e sair com algo útil.

Por quê?…

Por que nem sempre o cliente tem paciência para isso.

?…

Por que ele sempre acha que já te respondeu e que você está sendo um chato.

?…

Por ele demora um tempo até perceber quão vazias são as respostas que ele está te dando – porque leva um tempo até a ficha cair.

?…

Por que raramente ele espera que o profissional de BI ajude com o problema dele.

?…

Por que quase todos clientes acham que vendedor de BI vende software, e não solução! ;-)

Até a próxima! ;-)

Por quê? Por que sim, pô! :-P


  1. PCI vem de Payment Card Industry Data Security Standard, ou padrão de segurança de dados da indústria de cartões de pagamento. 

ROI de Projetos de BI

Eu já falei um pouco sobre ROI de BI em dois posts:

O ponto nos dois casos era o mesmo: dinheiro voando pela empresa que foi recuperado com o uso de Inteligência de Negócios, comparado com o custo de cada solução. Como sempre, o ROI de projetos de BI é astronômico, é fora de escala. O primeiro se pagou em algumas semanas, e o outro deu um retorno de dezenas de vezes. Um exagero nos dois casos, não se importa como se examine a questão.

Em 8/8/16 (8+8=16! :-O ) meu grande amigo Rômulo me mandou um SMS:


Perguntas recorrentes: como avaliar o sucesso de uma implantação de ferramentas analíticas (BI); como medir, nesse caso, o ROI?


Eu prometi a ele responder com um post no blog, já que o assunto é extenso, interessante (e relevante) demais para um SMS.

Return On Investment

Em bom português, ROI significa “retorno do investimento”. Via de regra, ROI pode ser definido como, por exemplo, o tempo para um projeto pagar a si próprio ou o impacto do projeto sobre o faturamento ou o lucro anual.

E isso é óbvio, não é?

Toda Estrada Tem um Retorno Invisível

Pare um pouco. Respire, tire os olhos desta tela e olhe ao seu redor. De onde veio tudo que está por aí?

Do retorno esperado.

Por que você come quando está com fome? Porque espera que, em retorno ao seu ato de mastigar e ingerir, desapareça o incômodo da fome.

Por que compramos uma mesa, uma TV, pagamos um curso ou convidamos alguém para sair?

Por que trabalhamos? Por que uma empresa surge? Por que montamos projetos?

Fazemos tudo isso para obtermos um retorno, algo que vai aplacar uma vontade ou atender uma necessidade.

Tudo que fazemos, e por extensão tudo que uma empresa realiza, gera um retorno. É por isso que, às vezes, perceber o retorno de uma determinada ação é muito difícil, especialmente se é algo que pouco afeta sua realidade. Às vezes, o retorno de uma determinada ação só pode ser percebido quando aquela ação deixa de ser feita, como quando perdemos o emprego, ou quebra-se uma linha de produção. Neste momento vemos como é importante ter um salário, ou como uma peça que representam 10% dos custos de uma empresa pode ser responsável por mais da metade do dinheiro que entra.

Uma situação comum em que o ROI não é tão facilmente calculável é justamente a modernização de um recurso ou a manutenção de uma situação. Vamos bolar um cenário para um caso clássico, o ROI de um treinamento, e examinar algumas coisas.

Imagine um banco. Estamos em 2016 e nosso banco é uma empresa já estabelecida, operante. Fazemos uma pesquisa de opinião e descobrimos que nossos atendentes não gozam de boa reputação com a clientela. Ser mal-visto é ruim, e queremos diminuir essa percepção negativa. Decidimos, então, aplicar um treinamento de “atendimento qualidade total”.

Como medimos o ROI desse treinamento? Fácil: rodamos uma nova pesquisa e verificamos se a reputação melhou, certo?

NÃO! Errado!

É de ROI que estamos falando, de DINHEIRO, não de percepção subjetiva do atendimento pessoal.

Uma coisa é observar se o projeto – o treinamento – deu resultado. Outra, bem diferente, é descobrir quanto dinheiro ficou a mais com o banco por causa dessa capacitação!

Pense em outro cenário no mesmo negócio, o banco: um novo sistema interno vai entrar em operação, e a certa altura do roll-out é feito um treinamento no uso desse sistema. Seis meses mais tarde, com 100% dos usuários do novo sistema treinados e aprovados nas avaliações, a capacitação deu resultado? E o ROI, de quanto foi?

Talvez vocês conheçam essa anedota:

Ouvido na conversa entre dois empresários:

- Eu decidi que não vou treinar meu novo empregado. Imagine se eu invisto nele, preparo-o, e ele resolve ir embora?!

Ao que responde o outro empresário:

- É? E o que acontece se você não treiná-lo, e ele decidir ficar?

Vêem onde eu quero chegar?

Certos projetos oferecem uma dificuldade extra para calcular o ROI porque o retorno do projeto serve apenas para manter as coisas como estão, para evitar que piorem. Só conseguimos avaliar o quanto nos custaria não investir, como na anedota. Por extensão, podemos supor que o ROI desse tipo de projeto depende desse custo de não investir, do chamado custo de oportunidade.

Quadridimensional

Lá no começo dissemos que ROI pode ser, por exemplo, o dinheiro que o projeto gerou a mais, e aqui em cima mostramos que esse retorno pode não ser a mais e sim evitar uma perda, evitar um dinheiro “a menos”. Para fechar o assunto vamos apresentar umas equações simples, para ancorar o conceito na Matemática.

Uma das formas de calcular ROI é esta:

 

Definição simples de ROI.
Definição simples de ROI.

 

Aqui considera-se o ganho total de um investimento, contra seu custo. É uma fórmula válida para quando compramos ou vendemos alguma coisa, mas não quando mudamos algo na vida da empresa.

Quando um projeto é conduzido para mudar algo, precisamos considerar o impacto deste projeto ao longo do tempo. Basta pensar um pouco para entender o porquê: ao prevenir a interrupção da produção, por exemplo, você garante que o dinheiro vai continuar entrando. Se o projeto custa mais caro do que, digamos, um mês de produção, o ROI definido acima vai ser negativo se considerarmos o ganho do investimento apenas durante um mês, ou menos. Agora, este mesmo ROI se torna positivo – e cada vez maior – se considerarmos esses números a cada mês, ou dentro de um ano, por exemplo.

O chato de ver a questão sob este ponto de vista é que tudo passa a ter ROI, e não raro um grande ROI:

  • Se eu deixar de pagar meus empregados, eles param de trabalhar e eu paro de faturar. Então há um ROI aqui, que equivale a tudo que eu faturo!
  • Se eu deixar de pagar a eletricidade, ou a água, ou telefone, ou…, ou…, ou…, de novo, o dinheiro não vai entrar. Então, pagar tudo isso tem um ROI que é, de novo, igual a tudo que a empresa ganha!
  • Se eu deixar de investir na melhoria da empresa, meus clientes podem me abandonar, piorando meu faturamento. Logo, investir em melhorias tem ROI!

E asssim por diante. Esse raciocínio vai dar muita confusão se o levarmos adiante e por isso vamos manter o foco apenas nos projetos limitados no tempo. Esses projetos têm início e fim (um custo determinado), e normalmente mudam ou acrescentam algo na empresa (um impacto limitado.)

Ao considerarmos projetos e tempo, definimos o ROI como um retorno dentro de um período. Ou então como o tempo que o projeto leva para se pagar, em função de quanto esse projeto agregou de valor. Sob estas condições, a fórmula fica assim:

 

Definição de ROI com tempo.
Definição de ROI com tempo.

 

Leia: o ROI do projeto é medido em períodos, calculado como a razão entre o custo do projeto e quanto de dinheiro o projeto traz a mais. Se dissermos que período é mês, estamos calculando quantos meses o projeto leva para se pagar.

Essa é a fórmula de ROI que eu usei no post R$20M, e é o que nos interessa para responder a pergunta do Rômulo:


Em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”


Ganha um bombom quem percebeu que essa é a fórmula para o famoso “vai levar X anos para se pagar”. ;-)

Só para completar, podemos calcular um percentual de retorno por período, deixando a equação semelhante à definição inicial:

Definição de ROI percentual, com tempo.
Definição de ROI percentual, com tempo.

Projetos de BI

Agora temos uma definição para ROI, e sabemos que o retorno pode ser tanto uma melhoria nos resultados quanto a prevenção de uma piora destes.

Antes de continuarmos, deixe-me esclarecer uma coisa sobre o meu amigo.


O Rômulo mora em uma cidade no estado do Rio de Janeiro e foi aluno meu numa das turmas de BI da 4Linux, à distância. Ele é muito gente fina e um dia, ao vir para um congresso em São Paulo, entrou em contato comigo e marcamos uma pizza. Conversa vai, conversa vem eu percebi que não era um aluno típico de BI. Ele estava terminando o doutorado e precisou de uma ferramenta de integração de dados, de relatórios etc. e por isso foi atrás do Pentaho. Daí optou pelo EAD da 4Linux etc. etc. etc.

Foi um certo choque para mim, quase tão grande quanto ter dado aula para o Prof. Fidelis – que ensina Data Mining há mais de 20 anos – e para o Grimaldi, do BI Com Vatapá, outro gigante nacional. Dar aulas para caras muito mais gabaritados do que eu me dá um tanto de medo, mas enfim.


Então quando o Rômulo faz perguntas, ele coloca a coisa em outro nível. Ele não diz simplesmente “ROI de BI”. Ele é preciso: “ROI da implantação de ferramentas analíticas”. E não faz isso por pedantismo ou para se exibidir – ele é gente fina, lembrem-se! – mas sim porque é precisamente essa a expressão.

O que é um projeto de “implantação de ferramentas analíticas”? É o que popularmente chamamos de “BI”, e mais recentemente de “Data Discovery”: é a disponibilização de dados, para análises ad hoc, por meio de alguma ferramenta de análise multidimensional.

Não BI, Mas Sim Ferramentas Analíticas

Quase lá!!

E o quê um projeto de “implantação de ferramentas analíticas” entrega? O que ele cria na instituição, na empresa? Que retorno ele traz?

Depende.

É isso mesmo que você leu: d-e-p-e-n-d-e. ;-)

Imagine que estivéssemos falando de Data Mining. O que um projeto de Data Mining entrega é um modelo matemático que vai ser usado para tomar decisões automaticamente. Esse tipo de projeto tem uma meta clara desde o começo. São sempre coisas como “aumentar X% as vendas”, “reduzir em 100 clientes/mês de perda por atrito”, “economizar K dinheiro na distribuição” e tals.

Mas e um projeto que coloca, nas mãos dos empregados, uma ferramenta para montar “relatórios”?

Depende: para que eram necessários esses “relatórios”?

Pode ser que sejam usados apenas para substituir um trabalho braçal feito todo mês, como consolidar o balanço da empresa.

Ou talvez o usuário esteja tentando bolar uma estratégia de cobrança para recuperar dinheiro de caloteiros.

Ou talvez para desafogar a TI, que gasta muito tempo só fazendo consultas triviais nas bases, servindo a empresa inteira.

Róidebiai

Esse subtítulo parece “pedro bial”, se lido bem rápido… :-)

O cálculo do retorno do investimento de um projeto de BI, em geral, ou de implantação de ferramentas analíticas, em particular, vai depender muito da clareza de objetivos do gestor que patrocinou o projeto.

Há um sério problema na indústria de BI hoje em dia porque nem todos entendem como usar os dados para gerar valor. Quando entendem do assunto, gestores patrocinam projetos de Data Mining, com metas claras e portanto ROI fácil de se calcular, ou então apoiam projetos que visam equipar a força de trabalho da empresa com um ferramental necessária para o trabalho diário. Neste caso, especificamente, a meta não é aumentar um faturamento, mas sim reduzir o esforço do trabalho como um todo, aliviar uma dificuldade sistêmica, azeitar melhor as engrenagens que mantém a organização eficiente, produtiva.

Calcular um ROI desse tipo de meta não é fácil, isso quando não é impraticável. É exatamente o caso de um projeto que não impacta criando algo novo, mas impedindo que se perca algo que já se tem, ou se tem pouco.

Assim, medir o ROI da implantação de ferramentas analíticas equivale a medir a produtividade dos beneficiados com essas ferramentas. Pode ser a redução do trabalho para gerar informações, pode ser uma maior velocidade na solução de problemas ou qualquer outra melhoria marginal, difusa pela empresa!

E, claro, temos casos pontuais no qual o cálculo do ROI é mais prático. Por exemplo, digamos que a tal ferramenta analítica foi trazida para um conjunto pequeno de profissionais, para resolver um problema pontual. Um projeto desses vai entregar alguma coisa muito definida, que facilita a medida de ROI.

Conclusão

Rômulo, você queria saber, em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”

Depende! Que problema essa implantação mirava resolver? Resolveu? Agregou dinheiro ou apenas impediu o desperdício?

Essa é uma regra geral de BI que eu sempre reforço:


Projetos de Inteligência de Negócios resolvem problemas. Se sua instituição não tem um problema para resolver, então você não tem nenhuma necessidade de BI, não importa o que os vendedores de ferramenta digam em contrário.


Implantar recursos de Inteligência de Negócios sem ter claro que problema você vai resolver é uma coisa bem pouco inteligente. Se está muito difícil calcular o ROI do seu projeto de BI, pense duas vezes: precisa mesmo? Para fazer o quê? Para resolver que problema? Pode ser que você esteja no camiho errado!

Até a próxima! :-)

 

 

Ladyvaulk – O Feitiço de Dataváulquila

Faz uns dois anos, e começou assim: minha mão estava coçando para testar Data Vault. Eu tinha feito alguns experimentos, tinha implementado um caso pequeno, mas ainda queria explorar mais. Queria um volume maior, mais complexidade, algo mais difícil.


Cuidado com o que você deseja, porque pode conseguir.


E eu consegui. Quem mandou desejar? Um dos softwares que o SERPRO usa é o Zabbix. Resumidamente, ele server para monitorar ativos, como roteadores, servidores e hubs, coletar métricas do parque informatizado e assim por diante. Consulte a página do projeto Zabbix para saber mais.

Como o SERPRO é uma coisa imensa, tudo está sempre no limite, no máximo, no maior volume, no mais complicado. São milhares de máquinas, dezenas, se não centenas de redes e sub-redes, kilômetros de cabos e tudo mais. Não vou entrar em detalhes técnicos para não correr o risco de falar besteira mas, resumidamente, o povo super-criativo conseguiu botar o esquema todo para a funcionar dentro do que era possível e desejável. Há um vídeo com uma apresentação sobre esse assunto neste link, feita por um dos empregados do SERPRO.

Uma das soluções adotadas passava por uma concentração de dados, que era atualizada periodicamente e servia para apresentar certos dados coletados pelo Zabbix.

Enter Linstedtman!

A pessoa responsável por essa necessidade foi aluna em um dos meus treinamentos de Pentaho, e veio me procurar imaginando se o PDI não poderia ajudar nesse caso. Afinal, consolidar dados é justamente a função dele.

As atualizações precisavam ocorrer a cada 30 minutos, no máximo, ou idealmente a cada 5 minutos ou menos. Apesar do grande espalhamento do sistema, como o volume dos dados capturados era, em si, até modesto, a baixa latência do refresh não era um problema.

O que realmente dava trabalho era a integração dos dados. Poderíamos, por exemplo, modelar os dados em uma estrela dimensional, definindo os atributos de interesse como dimensões e adotar uma fato artificial para correlacionar os dados entre si. Daria certo mas, depois de algumas mudanças nas fontes dos dados, as tabelas dimensionais acabariam ficando complicadas demais. Ou seja, logo no início do projeto daríamos de cara justamente com o ponto fraco da metodologia – a dificuldade de manutenção. Não era uma opção.

Poderíamos simplesmente replicar o layout de origem, mas isso implicaria em capturar os dados em uma granularidade confusa e, de novo, na primeira alteração na origem, quebraria todo histórico.

Não havia alternativa. Eu não queria admitir que estava usando os problemas como justificativa, mas no final, os problemas justificaram mesmo a escolha óbvia.

Usar um Data Vault. :-)

The Curse

Como havia uma certa urgência, trabalhamos em equipe: eu analisava os sistemas de origem para desenhar o Data Vault, e ia tirando dúvidas sobre os conceitos de negócio com os especialistas. Em pouco tempo (duas semanas, se não me falha a memória), foi montado o diagrama de tabelas, os modelos de transformação PDI e, com isso, um processo de ETL completo, de cabo a rabo, saiu do nada.

Como não era um grande volume de dados, a primeira carga levou coisa de uns trinta minutos, um pouco menos que isso. A partir da segunda carga, o processo de ETL terminava em menos de um minuto, graças ao fato de o DV usar CDC para tudo. Quando a rede está muito lenta, leva quase três minutos. Finalmente, por garantia, decidiu-se manter uma latência de 30 minutos (i.e. meia-hora), que dá uma boa margem para falha e recuperação, e ainda atende a necessidade.

E isso tem funcionado nesses últimos dois anos, sem parar, sem falhas, sem soluços, liso como gelo. De vez em quando aparece uma situação nova, e toca lá eu ir atrás de entender como usar Data Vault para resolver.

Um dia destes, batendo-papo e conversando sobre o projeto, a minha ficha caiu.

Sabe, eu não implementei esse lance – eu apenas desenhei um template, um gabarito de transformações para hubs, links, satélites e satélites de links. Nem tampouco desenhei o diagrama de dados: passei as regras de modelagem para a pessoa e deixei-a desenhar sozinha. Eu revisava tudo e corrigia os erros cometidos, mas eu mesmo não pus um dedo no processo de ETL!

É verdade que eu montei a configuração do PDI, configurei a captura de logs de cada transformação, e ainda montei um job que chama tudo. Mas de novo: montei na minha máquina, mandei para o projeto, expliquei como instalar no servidor e não fiz mais nada.

E tudo ia crescendo, ganhando tabelas, coletando dados… E a coisa rodando, e o monstro ficando maior, e maior e novos problemas aparecendo e eu só dizendo o que fazer. No máximo eu examinava os dados remotamente, para descobrir porque isso ou aquilo não estava dando certo, diagnosticava e, quando muito, corrigia os templates. A pessoa do projeto regerava as transformações problemáticas e tudo ia em frente.

Vocês não perceberam ainda né? Eu também demorei:


O projeto foi completamente, totalmente, 100%-mente construído, implementado e está sendo gerenciado por um profissional que não criou nada daquilo.

O projeto foi completamente, totalmente, 100%-mente construído, desenhado e planejado por um profissional que não implementou uma única transformação!


Sacaram? Eu não repeti a mesma frase duas vezes, leiam de novo.

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


O grau de automação do desenvolvimento foi tão grande, e em nível tão detalhado e profundo que a construção do modelo de dados e processo de ETL foi feito por um profissional que ignorava quase que completamente a técnica (DV) por trás.

E mais: a flexibilidade e resiliência da Metodologia de Data Vault é tão grande que foi possível desenvolver tudo – modelo e ETL – entendendo quase nada do negócio!


Nossa ignorância mútua dos problemas um do outro só não era total porque aos poucos fomos pegando partes da coisa – eu entendendo um pouco de Zabbix e o outro lado um pouco de DV e PDI. Mas nunca precisamos explicar nada sobre os detalhes de nada um ao outro!!!!!!!

:-O

Conclusão

Na esbórnia cultural que foi a década de 80, um dos filmes mais aclamados foi Ladyhawk, que contava a história de um casal amaldiçoado por um sacerdote malévolo. A maldição jogada nos dois fazia com que nunca se vissem, a não ser por uns breves segundos ao anoitecer e ao raiar do dia. Esse era o tal “Feitiço de Áquila”, que o nome do lugar: durante o dia a mulher era um gavião, e durante a noite, quando ela voltava à forma humana, o cara virava um lobo.

Preciso pedir perdão a vocẽs, porque foi mais forte que eu. Não deu para resistir.

Eu tive que brincar com isso.

A narrativa épica de um projeto de sucesso na era ágil! Quem projetou o ETL não implementou, e não sabia nada do negócio, enquanto que quem entendia tudo do negócio não sabia nada nem do modelo de dados, nem do ETL que estava  implementando com as próprias mãos (e um monte de processos automatizados!)

Uma equipe que nunca se vê, um projeto conhecido metade por cada um, que ninguém sabe por inteiro! Essa é a história de…

Ladyvaulk – O Feitiço de Dataváulquila!!!

Preciso concluir?? Não é à toa que existem, hoje, ferramentas como Wherescape e Attunity! Data Vault é uma coisa tão bombástica que um só “arquiteto”, como eu, pode cuidar de muitos projetos ao mesmo tempo, cada qual com UM – permita-me frisar: UM! – profissional de dados do outro lado.

AI MEUS SAIS!
AI MEUS SAIS!

Traduzindo: uma equipe de arquiteto mais alguns implementadores pode cuidar de muitos Data Vaults. É uma eficiência simplesmente impensável em qualquer outra metodologia!!

Claro que a realidade não é tão rósea. Para começo de conversa, os dados precisam ser extraídos do Data Vault, preparados e só então consumidos. Isso dá trabalho, mas mesmo assim nem de longe é o mesmo trabalho que dá construir um ETL para um modelo dimensional carregado diretamente a partir da fonte.

É isso. Até a próxima! :-)


Eu rio toda vez que falo Dataváulquila em voz alta. Vamos, tentem! Não me deixem pagando este mico sozinho!… :-D

Servidor Pentaho com Vagrant

Em um post anterior eu resenhei um livro da Packt que ensina como usar o Vagrant para criar ambientes de desenvolvimento. Lá eu comentei sobre como Vagrant é interessante, e até como eu tentei montar um servidor, mas não consegui. Ainda tenho muito que aprender sobre Puppet para fazer a coisa tão bem, mas vou dividir com vocês o que eu fiz. Na pior das hipóteses é um ambiente Pentaho pronto, e pode quebrar um bom galho.


Antes de mais nada eu preciso deixar claro que vou falar sobre o Pentaho por mera conveniência. Dá para aplicar tudo que eu vou falar aqui em qualquer plataforma, com quaisquer softwares de BI. Pentaho é do balacobado, mas cada um é livre para montar seu projeto como achar melhor. Eu gosto de software livre, lembram-se? Isso significa liberdade para usar o software que quiser. ;-)


O primeiro post caiu direto no assunto, e ficou meio “seco”. Por isso vou começar revisando a idéia toda com mais cuidado. Depois eu vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)

Processos & Ambientes

Desde sempre, e não apenas hoje em dia, qualquer projeto de BI sempre possuiu duas etapas: colher dados e usar dados.

A parte de colher os dados equivale à montagem de um DW, um Armazém de Dados. Já a parte de usar os dados corresponde a um projeto de Data Mining ou a um projeto que expõe os dados aos usuários por meio de ferramentas de análises.

Quando o projeto é pequeno podemos desenvolver na produção e simplesmente lidar com as consequências dessa bagunça, mas quando os projetos são maiores que um certo porte, esse “simplesmente” não se aplica mais. Precisamos de pelo menos dois ambientes: um de desenvolvimento e um de produção.

O problema é que manter dois ambientes separados acaba por originar discrepâncias entre eles, e aos poucos começam a ficar diferentes um do outro. Depois de um tempo as diferenças são tamanhas, e tão irreconciliáveis, que cada nova versão levada para produção gasta um tempo só ajustando o código para as diferenças.

E é neste ponto que a idéia de infraestrutura como código pode nos ajudar: ao invés de mantermos dois ambientes com configurações manuais, descrevemos cada ambiente com um código-fonte, tal qual um software. Desta forma mantemos um controle muito maior sobre cada configuração e, melhor ainda, podemos comparar ambas e evitar as discrepâncias que acabam por atolar o projeto a cada nova versão.

Softwares como Puppet e Chef cuidam para que as definições desse “código” sejam aplicadas e respeitadas. Sempre que um servidor sofre alguma mudança que o desvia de sua configuração “correta”, esses programas, chamados genericamente de provisionadores, forçam a configuração de volta, apagando as coisas erradas e restaurando as configurações definidas pelo projeto.

O Vagrant é um passo na direção de infraestrutura como código: ao invés de construirmos um servidor, simplesmente definimos um servidor virtual. Associado a provisionadores, conseguimos um projeto cuja configuração é uniforme de ponta-a-ponta. Mais: podemos trabalhar em projetos distintos, tendo um ambiente de desenvolvimento finamente ajustado para cada projeto, se um interferir com outro.

Se durante o desenvolvimento descobrimos que precisamos alterar alguma configuração, essa alteração entra no código que descreve o servidor, ao invés de ficar perdida em um manual qualquer. Por meio de um versionador, como Git, esse código de infra-estrutura entra no projeto e é distribuído para todos os envolvidos. Mais ainda, sendo versionado e propagado para a produção! É um mundo perfeito – ou não? ;-)

Vagrant BA Server

Agora eu vou mostrar para vocês a sequência de ações que eu tomei até construir um Pentaho BA Server apto a atender um projeto simples. Não é o resultado final perfeito, que eu gostaria de obter, pois ele não envolve nenhum provisionador – ainda estou batendo cabeça com isso, e não queria demorar para levar isso a vocês. Esse campo ainda está muito cru, e quanto antes essas idéias começarem a se espalhar por aí, melhor.

O processo é relativamente simples:

  1. Instalar o VirtualBox;
  2. Instalar o Vagrant;
  3. Criar um ambiente Vagrant;
  4. Adequar os parâmetros desse ambiente para o BA Server;
  5. Instalar o Pentaho BA Server.

Eu fiz tudo isso em Ubuntu 16.04-64bits, um Linux, mas deve ser possível repetir esses passos com Windows e Mac, já que eles são suportados.

Todas essas ações são tediosamente sem graça em Ubuntu:

  1. Abri um terminal e comandei sudo apt-get update, para atualizar os repositórios de pacotes;
  2. Instalei o VirtualBox comandando sudo apt-get install virtualbox;
  3. Instalei o Vagrant: sudo apt-get install vagrant;

    O site do Vagrant adverte as versões de repositório normlamente estão bem defasadas em relação ao projeto, e que não raro podem acabar apresentando problemas. Por isso, recomendam eles, baixe o instalador do site (aqui) ou compile o projeto do zero.


  4. Criei um ambiente Vagrant:
    1. Em outro terminal criei um diretório para o novo servidor: mkdir AmbienteVagrant;
    2. Entre neste diretório com cd AmbienteVagrant e criei o arquivo inicial: vagrant init precise32 http://files.vagrantup.com/precise32.box;
  5. Configurei esse ambiente para ter 1.5 GB e expor a porta 8080:
    1. No diretório AmbienteVagrant surgiu o arquivo Vagrantfile, que eu abri com o editor de textos;
    2. Entre as linhas que definem a configuração, Vagrant.configure(2) do e end, inseri esses dois trechos: config.vm.provider "virtualbox" do |vb|
      vb.memory = "1536"
      end
      e
      config.vm.network "forwarded_port", guest: 8080, host: 8080

    Isso vai mudar a memória da máquina virtual para 1.5GB ( = 1024 MB * 1.5), suficiente para um BA Server 5.x, e vai fazer um forward da porta 8080 da máquina virtual para a máquina real.

  6. Ainda dentro daquele diretório, subi o servidor Vagrant com o comando vagrant up. Na primeira execução ele baixou um disco virtual configurado com Ubuntu Precise Pangolin (12.04 LTS) para 32 bits, e só então subiu o servidor.

Voi-là! Agora temos uma máquina virtual pronta para ser configurada com o BA Server. O que precisamos fazer é bem simples: adicionar Java 1.7, baixar e descompactar o BA Server 5.4 e configurar o servidor para subi-lo automaticamente. Vamos nessa:

  1. Acessamos o servidor Vagrant rodando com o comando vagrant ssh. Um terminal se abre diretamente no servidor virtual;
  2. Vamos instalar o Java Oracle: é só adicionar o repositório e rodar um apt-get:
    1. Dentro do servidor Vagrant comandamos sudo apt-get update para atualizar a lista de pacotes disponíveis;
    2. Para adicionarmos a chave do repositório Java WebUpd8 precisamos de alguns pacotes. Instale-os com este comando:sudo apt-get install python-software-properties;
    3. Depois disso estamos preparados para adicionar a chave do PPA:sudo add-apt-repository ppa:webupd8team/java. Apenas bata enter para concluir;
    4. Atualize os repositórios novamente, com outro sudo apt-get update;
    5. Finalmente, comande a instalação do Java 7:sudo apt-get install oracle-java7-installer;

      A instalação do Java por meio de repositório no Ubuntu é um truque: a licença da Oracle não permite empacotá-lo no repositório, então o que realmente baixamos é um programa de instalação que coleta, por meio de um prompt, uma anuência com os termos legais da Oracle, para então baixar os arquivos do Java e configurá-lo. Por isso a série de pontinhos, indicando o download – uma coisa que não acontece com o apt-get ordinário.


  3. Ao final teste o java: comande java -version e veja se volta uma mensagem informando a versão;
  4. Vamos precisar de outro programa: unzip. Comande sudo apt-get install unzip para instalá-lo;
  5. Instale o BA Server:
    1. Ainda no SSH do Vagrant, entre sudo mkdir /opt/pentaho para criar o diretório no qual vamos deixar o servidor;
    2. Para facilitar nossa vida, mude esse diretório para “casa da mãe joana”, comandando sudo chmod 777 /opt/pentaho. Isso vai dar permissão de escrita geral no diretório pentaho;
    3. Mude para ele, cd /opt/pentaho, e baixe o Pentaho BA Server 5.4 a partir do SourceForge:wget http://bit.ly/29gb4ak --output-document=biserver-ce-5.4.0.1-130.zip
    4. Depois que ele terminar de baixar, descompacte-o: comande unzip biserver-ce-5.4.0.1-130.zip;
    5. Terminou de descompactar? O zip não é mais necessário, e você pode removê-lo com rm biserver-ce-5.4.0.1-130.zip. Não precisa, já que isso não vai forçar o tamanho do disco virtual para baixo automaticamente.

Ufa! Quase lá! Primeiro deixe o BA Server pronto para atuação automática:

cd biserver-ce
./start-pentaho.sh

Responda com enter à mensagem e aguarde alguns minutos. Daí teste abrindo seu navegador web e apontando para http://localhost:8080. Se tudo deu certo você verá a tela de login do servidor. Não se esqueça de baixar o servidor antes de prosseguir, com um ./stop-pentaho.sh dentro da caixa Vagrant.


É importante você rodar o BA Server ao menos uma vez manualmente, e assim se livrar do prompt de execução inicial. Caso contrário o servidor pode não subir na inicialização automática.


E o que falta? Bom, queremos que o servidor Vagrant fique pronto com um único comando – vagrant up – sem precisar de mais nada. Então é necessário configurar o servidor para subir e baixar sozinho, na inicialização da máquina.

Configurando o BA Server para Início Automático

O procedimento descrito aqui foi retirado do capítulo 3 do livro Pentaho na Prática. Você pode baixá-lo [deste link][pnpcap3_bitly], e ter um gosto do livro.

  1. Primeiro, garanta que o servidor Vagrant esteja no ar emitindo o comando vagrant up dentro do diretório em que criamos o arquivo de configuração Vagrant (/home/USUÁRIO/AmbienteVagrant);
  2. Faça login no servidor Vagrant com vagranta ssh;
  3. Assuma credenciais de root na caixa Vagrant: sudo su;
  4. Mude para o diretório de scripts de serviço: cd /etc/init.d;
  5. Abra um editor para um arquivo novo, neste mesmo diretório, chamado biserver-ce: nano biserver-ce (pode usar o vim, se quiser;)
  6. Agora precisamos do script de inicialização de servidor, para Linux. Abra este link em uma outra aba do seu navegador e procure o item “Script de Inicialização do BI Server para Linux”. Baixe este script, abra-o e copie tudo para dentro do arquivo do item anterior. Salve, pressionando CTRL+O e batendo enter, e depois saia do editor, pressionando CTRL+X;
  7. Por fim ative a execução automática: ainda no terminal Vagrant, como sudo, comande: (atenção! são dois blocos diferentes!)
ln -s /etc/init.d/biserver-ce /etc/rc2.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc3.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc4.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc5.d/S99BAServer
 
ln -s /etc/init.d/biserver-ce /etc/rc0.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc1.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc6.d/K19BAServer

É isso. Saia de tudo, pare o servidor Vagrant com vagrant halt e depois reinicie-o com vagrant up. Assim que o prompt voltar, abra um navegador web e aponte para http://localhost:8080/pentaho.


O comando vagrant up pode terminar antes de o servidor Pentaho estar no ar. Dê alguns minutos para tudo acabar de acontecer antes de tentar acessar o BA Server com o navegador web.


Conclusão

Acabei de reler tudo, para fazer a conclusão, e acho que devo um pedido de desculpas: parecia mais fácil na minha cabeça… Se você tiver algum problema, ou dúvida, deixe aqui um comentário, que eu te ajudarei.

Vamos lá, para a conclusão.

Virtualização é uma idéia muito legal. Virtualizar máquinas permite desde jogar antigos arcades a testar sistemas operacionais sem precisar arriscar ferrar a nossa máquina e nossos dados.

No mundo dos desenvolvedores, as coisas ficam cada vez mais complicadas. Uma das complicações mais perniciosas é o duo ambiente de desenvolvimento/produção: a tendência humana em mexer agora e documentar depois acaba bagunçando a situação a tal ponto que cada novo deploy, isto é, a cada entrega de uma nova versão no ambiente de produção, exige muito trabalho para compensar as diferenças entre os ambientes.

Para resolver esse problema surgiram tecnologias englobadas na disciplina DevOps, como os provisionadores, softwares que configuram, e forçam essa configuração em um ambiente, automaticamente. Dois membros desta classe são o Puppet e o Chef, que permitem definir uma infraestrutura como se fosse código, tornando possível até mesmo uma coisa estranha: versionar uma infraestrutura, isto é, guardar todas as configurações que ela já teve ao longo do projeto.

Alguém teve a (óbvia e genial) idéia de combinar essas duas coisas e conseguir uma terceira ainda mais bacana: ambientes de desenvolvimento isolados!

O software Vagrant, sobre o qual a Ed. Packt oferece um livro muito bom, faz exatamente isso: permite a criação de ambientes estanques, configurados ao gosto do projeto. Graças a ele, qualquer equipe pode ter um ambiente de desenvolvimento “limpo” (i.e. exclusivo por projeto), uniforme (igual para todo mundo) e estável (não muda sem querer ou por acidente.)

Em um post anterior eu resenhei o livro da Packt sobre o Vagrant, e hoje eu dei aqui o passo-a-passo para montar um servidor Vagrant para projetos que usem o Pentaho BA Server 5.4.

… ou quase: o ideal teria sido definir a configuração como um script Puppet ou Chef (scref?? kkk) e deixar o provisionador tomar conta. Mas eu ainda tenho muito a aprender e por isso resolvi mostrar o que eu já consegui fazer.

Burning Down the House

Eu seguia feliz da vida estudando o Vagrant, quando, de repente! (kkk), fiz o curso da 4Linux sobre DevOps! Foi quando eu fui obrigado a aprender sobre o [Docker][docker_bitly], algo do que eu vinha escapando deliberadamente (infra não é minha praia.) O Docker leva adiante a idéia de isolamento proposta pela virtualização, mas a um custo de infra menor: enquanto que a virtualização quebra uma máquina real em várias virtuais, o Docker monta várias máquinas “virtuais” compartilhando a mesma infra. Isso tem uma grande vantagens logo de saída: por não virtualizar tudo, mas apenas a parte que interessa, ele é muito mais leve e por isso usa melhor os recursos da máquina. De cara a performance de um container Docker é melhor que a de uma máquina virtual.

Há muita coisa ainda para se evoluir e resolver na tecnologia de containers mas, como colocou o The Register, se virtualização é uma tecnologia importante e valiosa em certos cenários, em outros ela é pesada e ineficiente, e coisas como containers são o futuro.

Uma destas coisas, na minha opinião, é justamente a gestão de ambientes, e não apenas de desenvolvimento! Como um container tem performance nativa, podemos montar servidores reais usando Docker e ainda atingir o grau de isolamento e controle proposto pelo Vagrant. No fundo, é a mesma coisa, mas executada de uma forma diferente.

Por isso eu disse, no começo, que “vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)”: não sei se vou continuar investindo no Vagrant. Ao menos por um tempo, eu definitivamente vou cair de cabeça no mundo do Docker! Eu até comprei um livro da Packt sobre isso, o Learning Docker. Assim que eu acabar de lê-lo vou fazer sua resenha aqui e depois montar o mesmo ambiente de hoje usando Docker.

Docker

Docker

Docker Docker Docker Docker Docker Docker Docker Docker

Já reparou como é viciante falar Docker? Docker Docker Docker Docker

Até a próxima! ;-)

Projeto de Sucesso

Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.

Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.

Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?


Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?


Sucesso Não Existe

Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.

O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.


Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.


O Caminho para o Sucesso

Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:


Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.


Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!

Decisões, Decisões, Decisões

Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”

Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!

Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.


Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)


O Que Funciona?

E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?

Armazéns de Dados

Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.

Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.

Equipes

Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.

Processos

Há dois grupos de processos dentro de um projeto de BI, especificamente:

  • Processos de Desenvolvimento;
  • Processos de Atendimento.

O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.

O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.

Processo de Desenvolvimento

Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.

Processo de Atendimento

De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.

Soluções

Todo projeto de BI usa quatro tipos de soluções:

  • Apresentações;
  • Relatórios;
  • OLAP;
  • Data Mining.

As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.


E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.


Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.

Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.

Conclusão

Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.

Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.

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

Outro nome para essa abordagem é BICCBusiness Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.

Não é um BICC, mas dá uma idéia de como funciona a tal "linha de produção".
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.

O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.

É isso, até a próxima. ;-)

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. ;-)