Latinoware 2015 – Eu Vou!

Ora, quem diria, eu fui convidado à participar da Latinoware 2015! :-)

Meu perfil no site da Latinoware. Preciso melhorar essa foto...
Meu perfil no site da Latinoware. Preciso melhorar essa foto…

Minha palestra será “Inteligência Institucional para o Governo Digital”:

Minha palestra na grade: 10H00min @ 15/10/15.
Minha palestra na grade: 10H00min @ 15/10/15.

Eu vou mostrar como as tecnologias atuais – com 100% de Software Livre – habilitam a construção de um Armazém de Dados de proporções continentais. Por falta de nome melhor ele chama-se Armazém de Dados Governamental (ADG ou GDW) e pode ser construído para qualquer esfera de poder: municipal, estadual ou federal.

Consegue imaginar 27 ADGs estaduais integrados? É como construir a Matriz: vai estar tudo lá dentro!!

Semana que vem, dia 15/10/2015 às 11H00min (logo após a palestra), a apresentação estará disponível em PDF aqui no blog.

Vejo vocês por lá!

Anúncios

De Agilidade e BI

Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?

Ágil, Não Rápido

Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.

É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.

Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.

É ruim, hein! :-P


O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.


Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.

Inteligência de Negócios Ágil?

E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?

Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.

Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.

Quer dizer, praticamente. Algums detalhes não deram muito certo:

  1. Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
  2. Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
  3. Refactoring: sério, refatorar um banco de dados?? Freaking how??

Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!

Senta que Lá Vem História…

O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.

Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.

Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!

Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?

Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)

Requisitos Para Gestão Ágil

Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.

De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.

E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.

Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.

150827_DAEBI_004

4Shot Agile BI com Pentaho

Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.

150827_DAEBI_001Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)

Eu produzi um vídeo explicando melhor a idéia.

150827_DAEBI_002

Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)

Máquina virtual pré-fabricada, pronta para os exercícios.
Máquina virtual pré-fabricada, pronta para os exercícios.

O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)


Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.


Compre! :-D

Como Um Data Vault Evolui II

Em vários posts (Data Vault Para Quê?, Introdução à DV e Como um DV Evolui) eu falei sobre as vantagens em se ter um Data Vault no miolo do seu projeto de Data Warehouse Corporativo. (E eu também expliquei porque um DW é importante neste outro post.)

Hoje eu vou mostrar uma destas vantagens em ação: como um DV evolui quando a fonte de dados muda.

Cenário

Em julho de 2013 a equipe de desenvolvimento do DW Corporativo do SERPRO estava com um problemão: não conseguiam formular o modelo dimensional adequado à uma necessidade específica do cliente. Me convocaram a trabalhar no projeto e, depois de umas duas semanas apanhando “que nem” cachorro magro, eu consegui resolvê-lo. Ajustei o modelo, repassei os conceitos com a equipe, para evitar novos problemas do tipo, e saí do projeto no início de 2014.

Nessa época a arquitetura do projeto era a mais padrão possível, igual à de qualquer outra empresa:

Arquitetura original.
Arquitetura original.

Ou seja, os vários sistemas de origem eram lidos e partes de seus dados copiados para dentro de um outro banco de dados. Esse banco fazia algumas agregações, algumas integrações e produzia dados combinados. Esse banco não tinha o perfil de um palco (stage), apesar de concentrar dados, e por isso eu prefiro chamá-lo de ODS, ainda que também não se encaixe na perfeita acepção do termo. Finalmente, várias estrelas dimensionais eram populadas a partir da colagem que era esse ODS.

Eu construí a solução para a demanda do cliente em cima desta arquitetura, e percebi mais tarde que o que eu encontrara era, no fundo, a raiz de um modelo do tipo do Data Vault. Animado, eu redobrei meus estudos sobre DV, e no início de 2014 eu pude aplicar o que estava aprendendo para montar um DW na empresa de um amigo. Eu poderia ter feito tudo com Modelo Dimensional, mas seria uma boa chance de testar Data Vault. Deu muito certo: não apenas eu consegui desenvolver tudo em tempo recorde, como ainda criei um conjunto de templates, um processo de modelagem e um processo de desenvolvimento de ETL, que mais tarde foi usado no primeiro curso de Data Vault no Brasil.

Em novembro de 2014 eu voltei a ser alocado ao DW do SERPRO, para atender uma demanda, outra estrela, parada há alguns meses por falta de gente. Só que, desta vez,me deram a liberdade de aplicar meus conhecimentos de Data Vault e não perdi tempo:

Arquitetura com o Data Vault.
Arquitetura com o Data Vault.

Ou seja, meu novo ETL buscava no ODS os dados levados para o Data Vault, e deste um outro ETL partia com os dados para uma estrela de apresentação. Como meu DV foi preparado para se ajustar ao Data Mart Dimensional, eu não precisei refazer nenhuma das dimensões que já existiam. Criei apenas uma nova fato e uma junk, que agregava várias flags e voilà, tudo pronto.

Resumidamente, eu 1) construí o modelo DV, 2) construí o modelo da nova estrela, 3) gerei o ETL do DV automaticamente e 4) criei o ETL para estrela na mão. Levou um mês, mais ou menos, e eu produzi tudo com documentação e processo. Nada de improvisos – não gerei um único débito técnico. Tanto que eu fui embora e deixei-o rodando. Deixei-o não: eu esqueci completamente que ele existia.

Tudo Muda

Eu esqueci, mas o cliente não. Esse “remendo” está funcionando desde então, há mais de seis meses, diariamente, sem ter sofrido uma única parada causada pelo ETL do DV ou dali para o dimensional.


(…)sem ter sofrido UMA ÚNICA PARADA causada pelo ETL(…) Sabe, acabei de me tocar disso e estou profundamente impressionado. Caraca, NUNCA deu pau!! O ETL para o DV parou algumas vezes, mas sempre por causa de problemas gerais, como instabilidade de rede ou pau do banco, nunca por causa de erros imprevistos, e nunca teve nenhuma inconsistência de dados. :-O C-A-R-A-C-A!!…


Voltando: desde de o ano passado que esse ODS vem sendo desativado, pois ele é complexo demais e seu ETL sofre paradas demais (sem contar inconsistências de dados, quando o ETL vai até o final.) Uma nova iniciativa de DW corporativo foi montada (pfff…) e começaram de novo (eu já vi essa história antes…). Decidiram não fazer nenhum modelo: se antes o ODS fazia alguma integração, agora teríamos um palco persistente (PSA, de Persistent Staging Area.) A partir desse PSA as estrelas de consulta eram populadas. Ou seja, se antes a integração acontecia na entrada do ODS, agora ela acontece na saída do PSA. Enfim…

Como disse Otis, as coisas mudam, sempre mudam. Há uns dois meses chegou a hora de desativar o pedaço do ODS que servia de fonte para meu DV. Era preciso migrar o meu Data Vault do ODS para os sistemas de origem, e precisava ser uma migração à quente, sem parar de rodar e sem refazer nada. Não seria possível, por exemplo, analisar as tabelas dos sistemas de origem que compunham o ODS e refazer quaisquer hubs, links ou satélites.

Vem Quente…

A arquitetura após a migração da fonte ficaria assim:

Alteração de fonte do Data Vault.
Alteração de fonte do Data Vault.

Aqui há outro problema embutido: as tabelas que existem nesse ODS são quase as mesmas que existem nos sistemas de origem. Ou seja, se no sistema de origem existe uma tabela produto, no ODS vai existir uma tabela tb_pro_produto. Se essa tabela, na origem, possui 10 campos, no ODS vai possuir 9 ou 11 ou 30 campos. Grosso modo, porém, o conteúdo do sistema de origem existe no ODS quase intacto. Logo, para usarmos os sistemas de origem no lugar do ODS é preciso analisar a correspondência entre as tabelas.

Para cada tabela do ODS que o Data Vault consultava haviam três possibilidades:

  1. Equivalência direta: no máximo o nome da tabela (ou de uma de suas colunas) muda;
  2. Praticamente a mesma coisa: sem contar o nome da tabela, o conteúdo era praticamente o mesmo. As diferenças seriam um nome de coluna diferente, uma coluna a mais ou a menos, mas o mesmo grão: se na origem existissem 1000 registros, o ODS teriam 1000 registros, equivalentes um a um;
  3. Tabelas equivalentes: meu Data Vault usava uma tabela no ODS que era resultado da combinação de duas ou mais tabelas do sistema de origem.

O melhor caso é o primeiro, pois a mudança no Data Vault resumir-se-ia a trocar os parâmetros de conexão para apontar para o novo banco e, talvez, mudar um nome de tabela ou coluna.

O segundo caso também não seria difícil: para cada link, hub ou satélite que usasse esse tipo de tabela bastaria reescrever um único SQL, e mudar a conexão do ODS para o novo banco, e as transformações estariam migradas.

Já o terceiro caso seria o pior. Haveriam duas situações possíveis:

  1. A tabela equivalente dentro do ODS derivava de várias tabelas de uma única fonte de dados. Ou seja, é possível construir um SQL, ou talvez uma procedure mais complexa, que remonta a antiga tabela a partir das tabelas do sistema de origem. Esse novo e complexo SQL seria o novo SQL de cada transformação de hub, link ou satélite, que junto com a mudança de fonte de dados completaria a migração;
  2. A tabela equivalente dentro do ODS derivava de várias tabelas, de duas ou mais fontes de dados. Ou seja, como um SELECT (ordinariamente) não cruza as fronteiras de bancos, e muito menos de tecnologias de bancos, não seria possível construir um SQL para replicar a tabela do ODS. Seria necessário uma transformação intermediária, que unisse esses dados e entregasse-os para as transformações de carga de hubs, links e satélites.

Na pior das piores hipóteses, poderíamos criar uma tabela intermediária, em um palco, e usá-la para carregar o DV.


A migração de fonte de dados de um DV vai de algo tão simples como mudar um IP e uma senha, na conexão com um banco de dados de origem, a algo complexo e trabalhoso como reconstruir parte do DV ou criar etapas de carga intermediárias. Em qualquer situação, porém, sempre haverá uma saída e ela nunca vai quebrar o downstream, o lado do cliente.


…Que o DV Está Fervendo!

Fizemos – a equipe de desenvolvimento do DW e eu – uma áudio-conferência há umas três semanas atrás. Em menos de duas horas eu expliquei o que era DV, o básico de como se construir um e como o trecho do DV funcionava. Depois expliquei exatamente os mesmos pontos acima, mostrando que, quanto mais complexa for a origem do DV, maior vai ser o trabalho de migração.

Bom, o trabalho de migração (já!) acabou! O pior caso foi o de umas tabelas que combinavam coisas de um mesmo sistema, mas sem alterar o grão, de modo que mesmo o pior caso foi muito fácil de fazer.

Não estamos esquecendo de nada?…

Sim! E o data mart populado pelo DV? Você consegue chutar o que deve ter acontecido com ele, e com o ETL do DV para a estrela?

Simples, não aconteceu absolutamente nada. Veja, apenas alteramos as entradas do Data Vault, e nada mais. Assim, o ETL que rodava sobre o DV para popular a estrela que o cliente usava continuou como estava!!

Conclusão

Um Data Vault carrega grandes promessas:

  • Carregar 100% dos dados, 100% das vezes (regra de ouro do DV;)
  • Acomodar qualquer mudança dos sistemas de origem, sem quebrar;
  • Permitir exploração dos dados como o cliente quiser, sem quebrar;
  • Reduzir o trabalho de desenvolvimento e manutenção, automatizando sempre que possível;
  • Reduzir e até eliminar retrabalho;
  • Grande velocidade de carga.

O primeiro artigo, Como um Data Vault Evolui, mostrava o que acontece com um DV quando uma premissa inicial se mostrava incorreta, e como ele se acomoda elegantemente os ajustes necessários. Este post mostrou de que forma uma mudança profunda como a troca de fonte de dados é tratada por um DV. Ainda que tenhamos tido sorte com um ODS que não era complexo demais, todas as mudanças ocorreram em questão de semanas, sem quebrar o dia-a-dia do cliente.

E ele continua rodando sem parar há seis meses! :-D

Novo Livro de Data Vault

Boas notícias! Daniel Linstedt, criador do Data Vault, anunciou a data de lançamento de um novo livro, seguindo a linha do Super Charge Your Data Warehouse:

Anúncio feito em lista do LinkedIn. (Em 20/05/2015)
Anúncio feito em lista do LinkedIn. (Em 20/05/2015)

É claro que eu não perdi tempo:

Posso contar para todo mundo? Posso? Posso? Diga que sim, por favor, ah, vai diga que sim, siiiiiiim???... (Em 21/05/2015)
Posso contar para todo mundo? Posso? Posso? Diga que sim, por favor, ah, vai diga que sim, siiiiiiim???… (Em 21/05/2015)

Então é isso: dia primeiro de Setembro de 2015 (segundo o autor – a editora informa que será um mês depois, em primeiro de Outubro) será lançado o livro Building a Scalable Data Warehouse with Data Vault 2.0! Sairá pela Morgan-Kaufmann, um selo da Elsevier, já que a Wiley caiu na bobagem de dispensá-lo. Eis a capa, que já foi confirmada:

Capa do novo livro.
Capa do novo livro.

Show!! :-)

Big Fragging Gun!

O problema que define a nossa época corrente, em BI, é o grande volume de dados. Parece que todo o restante é um problema secundário quando alguém joga as palavras BigData na sala.

Como reinar sobre eles? Como manter uma vida pessoal, ser um profissional de BI de sucesso e mesmo assim conseguir atender às necessidades gasgantuescas de acúmulo de dados e – pior ainda – análise desses?

Conseguindo uma Big Fragging Gun for BI. ;-)

BFG

Quem é velho (ou novo) o bastante para ter jogado muito video-game vai se lembrar de um jogo chamado Doom. Nele havia uma arma, a Bio Force Gun, ou BFG, que disparava o tiro mais poderoso do jogo. Ninguém nunca a chamava de Bio-Force Gun, mas sim de Big F****** Gun, por que ela arrasava (hehe) tudo no caminho. Nada resistia à ela.

Big Fragging Gun!
Big Fragging Gun!

Quando você tem um problema muito grande, você o resolve com ferramentas ainda maiores.

Em 28/04/2015 eu proferi uma palestra no SERPRO exatamente sobre isso: como resolver um problema do tamanho do governo federal brasileiro?

Usando uma ferramenta maior. >:-)

O Tamanho da Bagaça

A IBM é uma das maiores empresas do mundo, e tem cerca de 400.000 empregados em 2015. A esfera federal do governo brasileiro emprega mais de 1.900.000 pessoas.


Permitam-me frisar: UM MILHÃO E NOVECENTAS MIL pessoas. Dá quase cinco IBMs (e olhe que uma IBM existe no mundo inteiro. Estamos falando de quase cinco dessas, circunscritas ao Brasil.)


Se cada uma dessas 1.9M pessoas gerar duas linhas de dados por dia, dá quase quatro milhões de dados só sobre o próprio governo, por dia.

Quatro milhões? Pff, dirão meus leitores, que sabem que eu chamo fato com 10 milhões de linhas de pequena (pequena, para mim, era um milhão, mas é um número tão carne de vaca – qualquer coisinha já gera um milhão de linhas – que eu precisei atualizar esse meu patamar.)

Bom, uma parte considerável desse contingente todo – quase 2 milhões de pessoas – opera os sistemas que movem o governo federal, e que fazem o governo federal mover as coisas no Brasil. É um mundaréu de gente e dados: começa por orgãos como a Receita Federal, o Tesouro Nacional e o Ministério do Planejamento, que detêm o grosso do trabalho informatizado, vai até fundações como a Biblioteca Nacional e diversos museus, e passa por universidades, hospitais, todas as forças-armadas, ONGs etc. etc. etc.

Não há Teradata que aguente, na boa.

O Tamanho do Problema

Preciso dizer mais?? Cada empresa já sofre um parto para montar um punhado de estrelas para análises, imagine cruzar dados entre empresas! E fazer isso oferece capacidade real e imediata de ganhos para nós, pagadores de impostos.

Se um ministério tem um custo de infra-estrutura, e todos os ministérios tem custos semelhantes, temos muito a ganhar em gestão entendendo esses gastos e buscando oportunidades de economia. Aproveitando um tema que anda pela moda, o potencial de terceirização – com ganhos de produtividade, qualidade e custos – são gigantescos!

Mas não compre ainda!

Como uma mega-instituição, complexa, pesada, coisas mais sutis passam completamente despercebidas! Você consegue imaginar a quantidade de perdas, desperdícios, erros e fraudes que pode acontecer em um sistema composto por tantos sistemas, e cada um com sabe-se lá quantas partes móveis? Todos esses dados, consolidados, integrados e deduplicados, se analisados com critério, podem mostrar muitas oportunidades de melhorias.

E se pudéssemos integrar os dados financeiros aos dados do DNIT? E se pudéssemos colocar lado-a-lado os dados das polícias de todo país e dos hospitais? Pense nos dados dos ministérios da Saúde, do Trabalho, da Fazenda, unidos! O que isso não poderiam nos dizer?

Como se não bastasse, de onde saem os parâmetros para definição de políticas? De onde tiramos que um projeto social está dando o resultado desejado, ou uma política de estado está tendo o efeito planejado?

Para arrematar, no meio de todos esses dados operacionais do Governo Federal existem os nossos dados, aos quais a Lei de Acesso nos granjeia acesso livre e imediato.

Conseguem ter uma noção da monstruosidade que é coletar e integrar todos esses dados, quiçá analisá-los??

Inteligência Institucional

Eu diria que ser um Governo Eletrônico é ser capaz de fazer mais que informatizar e automatizar os processos. Ser um Governo Eletrônico é ser capaz consumir esse planeta de dados para melhorar a si mesmo e para entregar serviços melhores. (Oceano de dados agora me parece uma coisa muito pequena. Já, já eu vou estar falando de Sistema Solar de Dados, ou Pequena Nuvem de Magalhães de Dados, hehe.)

Malgrado as dificuldades do mundo real, conseguir a capacidade de acumular e analisar esses dados é um imperativo para qualquer instituição, e um imperativo ainda mais forte para uma instituição tão central a um nação quanto seu Governo Federal.

Soluções

Tradicionalmente, uma solução de BI que analise os dados da empresa inteira tem esta aquitetura:

Arquitetura tradicional de EDW.
Arquitetura tradicional de EDW.

Ou seja, existe um banco de dados (relacional, quase sempre) que serve como Enterprise Data Warehouse (EDW ou Armazém de Dados Corporativo.) Quase sempre, também, esse EDW armazena os dados em um modelo dimensional, composto por uma coleção de estrelas (conjuntos de tabelas dimensão ligadas a uma fato.) Cada estrela representa um assunto dentro da empresa, e as estrelas são integradas via um barramento de dimensões conformadas.

Finalmente, um processo de ETL cuida de ler os dados na origem, limpá-los, arrumá-los, integrá-los e finalmente depositá-los no banco de dados, no EDW.

Uma empresa de porte médio, talvez até grande, pode conseguir viver com um EDW assim. Mas o modelo dimensional funciona bem para analisar, para explorar os dados, não para armazená-los eternamente, muito menos para integrá-los. Tanto é assim que a integração é feita pelo processo de ETL.

A partir de um certo ponto, essa estrutura colapsa sobre o próprio peso e se torna impossível de receber manutenção. Em bom informatiquês, torna-se imanutenível.

E esse não é o único galho dessa abordagem, não senhor! Que tamanho você acha que um banco de dados relacional, por mais parrudo que seja, consegue atingir? Você consegue imaginar uma tabela em um Postgres ou Oracle ou Teradata recebendo gigabytes e gigabytes diariamente, por meses, anos, décadas?? Nem eu!

Mas há soluções para cada um destes problemas.

A mais fácil é o volume de dados. Um cluster Hadoop consegue armazenar uma quantidade razoavelmente (petabytes) grande de dados, com performance de consulta aceitável, a um custo viável por gygabyte. Não vou entrar em detalhes aqui pois há muito sobre isso na web.

Sobrou a outra ponta: acumular e integrar esses dados.

A solução não fácil, ou mágica, mas existe: Data Vault. Veja essa arquitetura:

Arquitetura de EDW adequada a mega-empresas.
Arquitetura de EDW adequada a mega-empresas.

Ela propõe um EDW baseado em Data Vault, armazenado em um cluster Hadoop.

Isso resolve dois grandes problemas de uma vez:

  1. Integração: o modelo de dados de um Data Vault integra os dados. Quando uma nova fonte é incorporada ao EDW do Governo, o GDW (Government-sized Data Warehouse), os dados redundantes já entram nas tabelas pré-existentes e apenas os dados novos entram em tabelas novas. O processo de ETL, por outro lado, passa a ser completamente “burro”, pois vai apenas mover os dados novos dos sistemas de origem para dentro do EDW;
  2. Manutenção: a inclusão, alteração e remoção de fontes de dados, bem como a integração entre as fontes, passa a ser uma atividade padronizada, organizada e repetível. Acaba o pesado de inconsistência entre dimensões “parecidas mas diferentes”, comuns em DWs dimensionais.

Fábrica de Dados

A minha proposta nada mais é que a reedição do conceito de Fábrica de Informações Corporativas do Bill Inmon, com um Data Vault no meio, e com dados gravados em um cluster Hadoop. Isso mesmo: nada de novo. Já poderia ter sido feito há anos. Talvez até há mais de uma década, já que outra vantagem do Data Vault é a relativa facilidade de migração de fontes de dados. Ainda teria havido um bom retrabalho passar de um Data Vault 1.0, típico em bases relacionais, para o Data Vault 2.0, adequado ao Hadoop, mas nada teria sido intransponível.

Lei de Acesso à Informação

E como fica o atendimento à Lei de Acesso à Informação neste cenário?

Consideravelmente mais simples:

  • Ao invés de cada orgão ter que atender à demandas em separado, um único centro de dados do Governo faria isso;
  • Novas demandas de inclusão passam a ser tratadas uma única vez, em um único ponto: se um orgão pode atender seus pedidos de acesso à dados com dados já capturados por conta de outra demanda dos mesmos dados;
  • O pedido de novos dados, ainda não coletados, entra em uma linha de produção muito mais previsível e estável que a loucura tradicional de montar um serviço para cada demanda, em cada orgão.

E é claro, essa integração daria um poder fantástico ao gestor público.

Conclusão

Você pode baixar o PDF da apresentação clicando aqui e ver um pouco mais de argumentação. Esse material nunca foi aproveitado para nada dentro do SERPRO, e foi criado por mim mesmo por puro diletantismo, em meus períodos de lazer. Eu cheguei a propor como um produto, mas haviam outras coisas mais interessantes ou urgentes.

Pensando um pouco, acho que essa solução não precisa se limitar à esfera federal. Seria relativamente simples construir o mesmo em esferas estaduais e municipais, e integrá-las.

Re-Estimando Projetos de ETL

Em 2012 eu escrevi um post sobre como eu estimava o tempo gasto em projetos de ETL. Editorando a coletânea do GeekBI 2012 eu o reli, e fiquei horrorizado com os meus parâmetros: uma mísera estrela dava três meses! Tudo bem que eu incluía o tempo para implantação, estabelecimento do ambiente de desenvolvimento etc., mas mesmo assim é muito tempo para rodar a primeira iteração de um projeto. Em minha defesa, naquela época eu não via o mundo tão Scrum, e pensava ainda no formato cascata.

Hoje, quase três anos depois, eu já aprendi um monte sobre Scrum e Data Vault e não sou mais tão pessimista. Eu achava que não havia como algo não dar errado, e pior ainda, eu tinha certeza que construir as dimensões e fatos eram uma profissão de fé! Eu estava às voltas com coisas tão complexas, tão enroladas que eu realmente estava levando algumas semanas para construir uma transformação para carregar uma mera dimensão. Fatos, então, eram coisas aracnóides, de tantos ramos e ligações entre passos…

Vou refazer aquele mesmo processo, que eu continuo usando aliás, à luz dessas novidades. Vamos ver o que é que vai sair.

Introdução

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Depois de alguns anos eu fiz uma nova auto-análise e separei passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

Antes eu ignorava intencionalmente a necessidade do cliente e encarava como parâmetro apenas a quantidade de dimensões e fatos – afinal elas traduzem fielmente a necessidade do cliente. Só que, à luz do Data Vault, descartar esse conhecimento “rouba” informações importantes, que são úteis para estimar o tamanho do projeto.

Por isso hoje eu começo coletando outras informações: uma maquete da necessidade do cliente (veja a figura abaixo.)

Descrevendo a necessidade do cliente.
Descrevendo a necessidade do cliente.

A função dessa maquete é ilustrar que dados serão puxados dos sistemas de origem. Essa informação dá números importantes: a quantidade de hubs e satélites necessários, bem como a provável quantidade de links entre cada hub. Apenas para facilitar: entre dois hubs costuma haver pelo menos um link.

Daí eu procuro descobrir o seguintes:

  1. Quantos analistas você terá dedicados integralmente a construir o DW;
  2. Quantas fontes de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.;
  3. Quantas fatos e quantas dimensões o MD precisa ter atender para atender a demanda inicial.Esse item, no primeiro post, era o mais propenso a erros. Eu discutia como estimar a quantidade de dimensões e fatos a partir dos processos de negócio da empresa, pois eu acreditava que um DW Corporativo deve ser montado como estrelas ligadas a um barramento dimensional. Minha visão mudou, e agora eu entendo que o DW Corporativo deve ser a combinação dos dados historiados em um Data Vault e explorados em estrelas dimensionais. Graças a isso agora é muito fácil estimar a quantidade de dimensões e fatos a partir do protótipo: cada hub (e seus atributos) representam uma dimensão, e cada conjunto de métricas implica em uma tabela fato.No nosso exemplo parecemos ter uma dimensão (Item, com três atributos: Nome, Tipo e Origem) e uma fato, com uma métrica (veja mais adiante);
  4. Volume de dados. Pode ser o tamanho de todas as bases de origem, em bytes, e quanto essas bases crescem por dia ou mês. Preferencialmente, pode ser a quantidade de linhas iniciais e os incrementos regulares (por dia ou por mês);
  5. Se os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
  6. Se os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Completando o Cenário

Para nosso exemplo precisamos completar a história. A partir da figura anterior podemos supor que existe pelo menos um hub (Item) e um satélite (de onde tiramos Nome, Tipo e Origem.) Usando essa informação podemos supor que o diagrama abaixo representa um Data Vault que atenderia essa demanda:

150325_ReEstimandoProjetosDeETL_02
Provável Data Vault para a necessidade anterior.

Veja esse post para saber mais sobre esses objetos de um Data Vault.

Um Data Vault serve para acumular dados, não como fonte para análises. Se queremos analisar os dados que estão em um DV devemos primeiro levá-los a uma forma mais amigável ao usuário final. Isso significa construir um tabelão ou uma estrela com os dados que o cliente quer ver. A estrela do diagrama abaixo, derivada do Data Vault acima, atende a necessidade do cliente:

150325_ReEstimandoProjetosDeETL_03
Provável estrela deste caso.

O Processo de Estimativa

Pelo que eu tenho visto, em média:

  1. Uma equipe entrosada monta o ambiente de desenvolvimento (servidores, programas de desenvolvimento, repositórios, bases de dados etc.) em uma semana. Uma equipe desconexa leva mais ou menos o dobro;
  2. Uma equipe pode levar até uma semana a mais para montar a linha de produção de um Data Vault;
  3. Os elementos do Data Vault têm um teto de 1h/artefato;
  4. A partir de um Data Vault, um desenvolvedor PDI proficiente leva até uma semana por dimensão ou fato;

Da primeira vez eu considerei que a quantidade de fontes de dados acrescentaria mais alguns dias nesse número. Esse impacto tende a sumir quando usamos Data Vault porque os dados já entram integrados, e a fonte de dados é tratada automaticamente na linha de produção do ETL de carga do DV. Eu diria que mesmo dados originados em arquivos ou via webservices podem ser intermediados por um banco relacional, e assim cair de volta ao caso mais simples.

Há duas técnicas de carga de dados em dimensões e fatos: trunca-e-recarrega ou carga incremental. Truncar e recarregar exige menos trabalho de desenvolvimento e mais do ambiente de ETL, enquanto que a carga incremental tende a custar mais em termos de desenvolvimento e menos em termos de infra-estrutura. Eu aventava a possibilidade de o processo levar mais tempo no caso de ser necessário desenhar essa a carga incremental. De novo, com o Data Vault na parada esse fato tende a ser minimizado por quê podemos postergar o desenvolvimento da carga incremental até que uma limitação de infra-estrutura nos obrigue. Podemos começar usando trunca-e-recarrega e, quando a infra-estrutura não suportar mais isso, refatoramos o projeto para carga incremental.

Você pode argumentar que isso troca “seis” por “três mais três”, pois no final acabamos fazendo “6”. Bom, o fato é que uma carga incremental nem sempre é necessária. Quando montamos o DW com outro modelo que não o Data Vault, essa decisão via de regra precisa ser tomada antes, porque a refatoração é cara demais ou até mesmo inviável. A refatoração é fácil se temos um Data Vault, e postergar decisões não-críticas passa a ser uma boa estratégia.

Alguns modificadores:

  1. Obviamente, à medida que essa experiência aumenta, o tempo cai, e vice-versa. Assim, dominar a ferramenta, conhecer o modelo e os dados e já ter executado algumas iterações é o máximo da proficiência. Na ponta oposta está o novato com o software, começando o primeiro projeto de DW com dados que ele nunca viu mais gordos;
  2. Sujeira nos dados. Esse é o fator mais selvagem. Tradicionalmente ele afeta a entrada dos dados no DW e tende a aumentar a complexidade do processo de ETL.Só que um Data Vault aceita tudo, inclusive sujeira, sem sofrer nenhum impacto no ETL. Devido a isso, os dados precisam ser limpos apenas na saída para a base que vai servir para exploração. Meu sentimento é que dados muito sujos podem até dobrar o tempo de desenvolvimento da carga de uma fato ou dimensão. Mas de novo, podemos começar aceitando dados sujos para exploração, e limpar à medida que o usuário demandar isso.Como o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo, eu descarto esse fator para estimativas.

Finalmente, e só para ter um número para fazer as contas, vamos supor que um desenvolvedor seja capaz de entregar 4H de trabalho útil por dia. Vamos dizer que o modelo de dados (de DV e Dimensional) já estejam diagramados, faltando apenas serem levados ao banco.

Estimando…

Então, para nosso exemplo, estimando pelos tetos e arredondando para cima, temos:

  • 1 semana para iniciação do projeto;
  • 1 semana para estabelecimento da linha de produção do Data Vault;
  • ETL do Data Vaul: ( 1 hub + 1 satélite ) * 1 hora = 2 horas -> arredondando, 1 dia;
  • ETL do Data Mart (trunca e recarrega): (1 dimensão + 1 fato) * 1 semana = 2 semanas.

Total: 1 semana + 1 semana + 1 dia + 2 semanas ~ 4 semanas

Parece muito, e é. Veja que a carga da dimensão e a fato que usamos de exemplo precisam de muito pouco trabalho, e não devem levar uma semana cada. Eu diria que a complexidade do exemplo dá um dia para cada um. Mantendo a inicialização do projeto em duas semanas (estamos sendo muito precavidos aqui), o desenvolvimento mesmo levaria três a 5 dias, ou uma semana aproximadamente. Novo total: três semanas de trabalho. Tamanho da equipe: um desenvolvedor (e seu eventual gerente.)

Lembrando que para isso já tivemos levantamento de requisitos e primeiro desenho do modelo de dados – estamos tratando apenas do ETL!

No post anterior eu estimava como três semanas o tempo para dois analistas. Eu não dava tantos detalhes do cenário, e na minha cabeça era um caso mais complexo – e por isso era mais “cara”.

A melhor parte vem na iteração seguinte, quando o custo de inicialização já ficou para trás.

Estimando Mais Adiante

Suponha agora que o cliente pediu mais duas estrelas (duas fato), envolvendo um total de 9 dimensões, e que todas serão construídas a partir de um Data Vault com trunca-e-recarrega.

Se cada dimensão equivale, grosso modo, a um hub mais um satélite, e há links entre diversos hubs, então o diagrama abaixo representa o nosso caso:

150325_ReEstimandoProjetosDeETL_04
Diagrama DV para nova necessidade.

Cada hub aparece ligado ao “vizinho” por meio de um link, isto é, temos um link para cada par de hubs.

Exemplos:

H1 – H2 = Link 1-2

H2 – H3 = Link 2-3

etc.

Há oito links óbvios: L12, L23, L34, L45, L56, L67, L78 e L89. Para encorpar o problema vamos supor que há um link os hubs 3 e 6 (L36) e entre os hubs 3 e 9 (L39).

Isso dá (1 hub + 1 satélite) * 9 + 10 Links = 28 objetos.

E quanto ao modelo de dados que o cliente vai explorar? Nele temos 9 dimensões e 2 fatos.

Finalmente nossa origem é um único banco relacional, nossos dados são 100% limpos e teremos dois analistas (mais um gerente).

Estimando:

28 Objetos DV * 1H/objeto = 28 horas -> 28/40 Semana = 0,7 Semana
9 Dimensões = 9 Semanas
2 Fatos = 2 Semanas

Isso é o tempo gasto por um desenvolvedor só: cerca de 12 semanas ou três meses. Como a criação do ETL de cada dimensão é um processo independente de outros desenvolvimentos, podemos paralelizar a criação das dimensões. Assumamos, para simplificar, que desenvolver o processo de carga de uma fato depende da existência do processo de carga das dimensões usadas. Trocando em miúdos, o ETL para as fatos pode ser desenvolvido em paralelo, mas apenas depois do ETL para as dimensões.

Com dois desenvolvedores o tempo estimado cairia de 3 meses para aproximadamente um mês e meio.

No primeiro post eu ainda triplicava minha estimativa inicial porque eu via esse fator se concretizando nos meus projetos. Tendo desenvolvido um pouco com Data Vault, eu não sinto necessidade de incluir essa gordura. Muito pelo contrário, como o desenvolvimento de dimensões a partir de um Data Vault é um treco repetitivo, eu acho que esse tempo é até demais. Eu não vou cortar a estimativa, mas eu vou dizer que agora (com Data Vault) eu sinto mais previsibilidade nos projetos.

Finalmente, um overhead de gerenciamento continua existindo. Eu colocaria um mês para esse fator – nunca subestimo a capacidade de a burocracia nos amarrar!

Conclusão

E esse é meu chute, atualizado em função do que eu aprendi usando Data Vault. Lembre-se que estou descontado o levantamento de requisitos, documentação etc. e que mesmo achando que minha precisão melhorou, eu nunca ignoro o fato que estou tratando de uma estimativa, e nunca de uma medida – variáveis desconhecidas podem mudar tudo completamente, de uma hora para outra.

Continua valendo a mesma sugestão que encerrava aquele post: a quantidade de variáveis desconhecidas e incertezas berram pela adoção de Scrum como técnica de gestão. A propósito, eu adotaria três semanas como tamanho inicial das sprints, simplesmente porque rodei durante um tempo com sprints de duas semanas e me senti pressionado demais, o tempo todo.

E agora, o que você achou? Deixe seu comentário!


Washignton, liberado para dizer que este post é muito complicado! ;-)

Um Ponto Fita o Mundo

Sua empresa precisa de um Armazém de Dados? Vocês decidiram adotar Data Discovery, então seu primeiro impulso é esnobar respondendo “não, porque a ferramenta não precisa disso”. (Estou sendo sarcástico. ;-) )

Já faz algum tempo que eu publiquei um post sobre o assunto, no qual eu apresentava um argumento definitivo (na minha opinião) a favor da adoção de Armazém de Dados por qualquer empresa que deseje investir em BI. Não tenho nada acrescentar àquele argumento, mas recentemente cheguei a uma outra interpretação e pensei se não seria bacana dividi-la com vocês.

Eu sou formado em Física. Um dos jargões que aprendemos na faculdade é o verbo “fitar”, um estrangeirismo a partir do verbo inglês to fit. Em português podemos usar ajustar ou encaixar mas, como bons brasileiros, falamos fitar e boas.

Em Física queremos explicar a Naturza e por isso boa parte do nosso trabalho é, a partir da observação de um fenômemo, escolher uma função matemática para descrever esse fenômemo – esculpir um modelo matemático da realidade – e tentar encaixar a função nos dados experimentais. Quando nossa função – nosso modelo – encaixa-se sobre os dados, sabemos que ela serve para explicar a realidade, até onde nossos dados experimentais chegam. Todas as fórmulas da Física que você aprendeu na escola são resultado desse trabalho. Seja a Lei da Gravitação Universal, seja o Princípio da Conservação da Energia ou as Leis de Maxwell, tudo, tudo decorrente do teste de modelos matemáticos contra a realidade.

Tentar encaixar a função nos dados experimentais é, você adivinhou, fitar uma curva. A figura abaixo é um exemplo clássico: uma reta fitando os pontos.

Exemplo de uma reta "fitando" os pontos. Será que não existe nada melhor?
Exemplo de uma reta “fitando” os pontos. Será que não existe nada melhor?

E cá entre nós, ô fitizinho ruim! Me parece que uma Gausiana e uma reta modulando uma quádrica dá mais certo… Não acham? ;-)

BI vs. To Fit

Bom, na minha opinião (sempre!), Inteligência de Negócios é a administração científica de uma empresa, é o processo de levantar hipóteses e testá-las, e usar o resultado para decidir entre uma ação ou outra.

Uma forma diversa de falar “testar hipóteses” é “encaixar uma fórmula a um conjunto de pontos”. Em bom fisiquês, é fitar uma função num experimento. Se você quiser ir mais longe ainda, é a criação de um modelo matemático para explicar a realidade. Mas aí também é pedir demais da TI…

Voltando, pergunta retórica: que função você pode fitar em um experimento que coletou a medida de apenas um ponto?

Um ponto não fita nada. Ou melhor: fita tudo!
Um ponto não fita nada. Ou melhor: fita tudo!

Esse ponto pode ser qualquer coisa, medida instantâneamente. Ou seja, uma medida no momento e mais nada. Como as vendas de hoje, ou o total de pedidos de suporte, o quantos chamados um empregado abriu… Qualquer grão, mas em um único momento no tempo.

Oras, se você mediu seu experimento apenas uma vez – uma única vez – então você tem apenas UM ponto. Quem lembra das aulas de geometria deve se lembrar do lema “uma reta é determinada por dois pontos”. Com um só ponto você não define nada, absolutamente e rigorosamente NADA. Qualquer uma das funções ilustradas pelas linhas coloridas no gráfico acima pode ser ajustadas para passar sobre o ponto medido. Não podemos afirmar nada sobre aquele pontinho.

E este é precisamente o fulcro: como é que vamos testar uma hipótese contra um conjunto de dados que possui uma só medida? Não vamos! Não é possível fitar nada a um conjunto que tenha só um ponto!

Colocada de outra forma, pode-se dizer que é possível fitar um mundo de teorias e hipóteses em um ponto! Não dá para negar nenhuma delas em favor de outra! Qualquer modelo pode explicar aquele ponto!

Agora, se formos adiante e, de tempos em tempos, repetirmos o experimento e coletarmos um novo ponto, teremos uma evolução daquela variável (ou conjunto de) ao longo do tempo. Podemos ver o que aconteceu até agora e tentar enter como aconteceu dessa forma, e talvez o que vai acontecer a seguir.

Agora sim: com mais pontos podemos ver como o sistema se comporta.
Agora sim: com mais pontos podemos ver como o sistema se comporta.

O gráfico acima conta o final da história: para entender o que está acontecendo no meu sistema eu preciso de mais pontos. Só acumulando medidas do sistema ao longo do tempo é que podemos testar e descartar ou confirmar hipóteses.

E um Armazém de Dados é o sub-sistema da disciplina BI que resolve essa demanda por informação temporal. DW é mais que um banco de dados ou um cluster Hadoop: é uma técnica de coleta organização de dados com vistas a análises futuras. Por isso usamos um DW para soluções de BI: para não ter que reinventar a roda e cometer todos os erros de novo, só para sair com um conjunto temporal de dados do outro lado.

Tempo Não É Tudo

Alguém menos informado pode sentir-se tentado a argumentar que não é preciso coletar dados ao longo do tempo se as variáveis de interesse não incluem o tempo. Por exemplo, “que perfil de mutuário tem mais chance de não pagar o empréstimo?” Basta eu montar o perfil dos Mutuários em atraso hoje para descobrir isso.

Bom, esse argumento tem dois grandes furos:

  1. Sem uma análise da relação ao longo do tempo você não pode dizer que variável causou que consequência. Em termos técnicos, a ausência do tempo proíbe quase sempre a determinação do nexo causal;
  2. Sem uma análise ao longo do tempo você não tem como dizer se o valor medido é um outlier ou é o valor normalmente encontrado para aquela variável.

Imagine a consequência de conceder mais empréstimos justamente para o maior caloteiro, só por que, por acaso, conseguiu pagar a dívida em dia no mês passado, enquanto que o melhor pagador se atrasou para chegar ao banco!

Não há escapatória: até mesmo para saber que uma relação é constante no tempo é preciso analisá-la ao longo do tempo.

Conclusão

Resumindo, você precisa armazenar histórico dos dados da sua empresa porque “um ponto não fita nada!”

Explicar para alguém porque um DW é necessário em projetos de BI, usando só uma frase, é uma coisa bem difícil. Primeiro precisamos entender que BI é, resumidamente, a tomada de decisão a partir do teste de hipóteses. Se aceitarmos esse fato (nem todos aceitam), ainda temos que entender que o teste de hipóteses é, na verdade, um trabalho de encaixar uma explicação matemática a uma realidade mensurada.

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.

Se alguém te disser que você não precisa de DW para “fazer” BI, você vai acreditar?


Ah, em português fitar significa olhar fixamente.

Porque Data Vault, Segunda Tomada

Já tem algum tempo que eu superei a – oh! – dúvida cruel acerca de adotar ou não um Data Vault. Para você não ter que ler minha epifania, que é longa pra dedéu, eu finalmente concluí que sim, adotar um Data Vault traz muitas vantagens reais. Com isso superado eu segui adiante e comecei a implantar Data Vaults em pequenos projetos experimentais e a ajudar amigos a implantar DVs em suas empresas. Até mesmo produzi um treinamento inédito para criar DVs usando apenas Software Livre.

Como todo bom neurótico, eu sempre acho que não fui muito claro, que sempre dá para melhorar – ou ao menos para simplificar. E olhem só o que eu encontrei: um vídeo sobre uma ferramenta muito interessante, o BIML. Neste vídeo, antes da demonstração do BIML propriamento dito (que é uma linguagem markup para BI), aparece um slide aí pelos 4’40”:

Snapshot do vídeo mostrando os bullets sobre Data Vault.
Snapshot do vídeo mostrando os bullets sobre Data Vault.

Ele sumaria os pontos que respondem à minha (antigamente eterna) – oh! – dúvida cruel: adotar ou não adotar um DV, e por quê, eis a questão.

Eu transcrevi e tentei traduzir os bullets acima:

Usando-se um modelo Data Vault, o Data Warehouse:

  • Absorve mudanças mais prontamente (mais ágil;)
  • Responde bem ao surgimento de novas origens de dados (construção incremental;
  • Gerenciamento histórico em fatias temporais inato (historiamento;)
  • Provê rastreamento completo até a fonte dos dados (auditabilidade;)
  • Cresce e adapta-se com impacto mínimo, sem silos (TCO reduzido;)
  • Integra, alinha e reconcilia os dados (integração corporativa;)
  • Rastreia, gerencia e reporta sobre situações excepcionais (provê um loop para feedback.)

Eu não consegui traduzir tudo – sobrou o “loop de feedback”. Eu achei que laço de retroalimentação não estaria ajudando. Mas enfim…

Cada um destes bullets precisaria ser provado para ser aceito, para ser válido, mas minha experiência nestes últimos 10 meses com Data Vault provou para mim todos esses pontos: tudo fica mais fácil, mais rápido, com mais qualidade e mais resiliente. Ainda não achei uma boa maneira de dividir essa prova com vocês, mas vocês sabem como são os neuróticos: uma hora eu vou descobrir, e voltar aqui para contar.

Até a próxima!

Primeiro Curso de Data Vault no Brasil

Bom, notícias primeiro:

Em setembro de 2014 a IT4Biz aplicou a primeira turma de Data Vault com Pentaho do Brasil (e, considerando-se o “com Pentaho”, talvez até do mundo.) O cliente da IT4Biz mostrou-se contente com o resultado e comentou que DV tornou-se uma peça importante de sua estratégia, e que vai seguir para implementação de um projeto inicial.

Estou dando a notícia porque o curso foi desenhado e ministrado por mim mesmo. O cliente da IT4Biz é uma empresa brasileira de grande porte. Ela não é a filial de uma multinacional no Brasil, mas uma empresa do Brasil, que aliás é uma multinacional. Ou seja, não é uma empresa de fundo-de-quinta, uma farmácia ou uma padaria.É uma empresa grande, complexa e com um número enorme de variáveis e fatores.

Apesar de o curso ter ocorrido há quase dois meses, eu estava esperando para ver como o material seria usado – ou se ao menos seria usado. Em outras palavras, eu esperei para saber o real impacto que esse novo conhecimento teve para eles:

(…) avançamos bastante. Só pra ter uma ideia, conseguimos chegar no modelo dimensional com um dia de trabalho (+/- 8h), gerando o DV, fatos, dimensões e o cubo preliminar. É claro que precisa de ajustes no modelo. (…)

Em outras palavras: a partir do conteúdo e do material do curso (que inclui templates de transformações, documentos de modelagem e documentação de requisitos etc.), eles conseguiram passar a primeira etapa do projeto em um dia. Isso mesmo: um DW começado em UM DIA, já com uma estrela, com dimensões e tudo. Dê um desconto de duas semanas para revisar e finalizar e me diga se é ou não algo muito poderoso. ;-)

Deep Impact

Bom, como dizia o filme, teve um impacto profundo: entrou como uma dos componentes da arquitetura. Não apenas adotaram, mas estenderam o que foi passado. Claro que eram alunos excepcionalmente competentes e inteligentes, mas não teriam feito nada se o assunto não fosse relevante para eles.

Eu entrei como professor freelancer e como o cliente não é meu, eu não posso dar nenhum outro detalhe. Se minha palavra vale, nesse tempo todo o cliente aplicou o material do curso (que inclui templates de transformações, documentos de modelagem e documentação de requisitos etc.) com maestria e obteve os resultados que buscava.

Se o mercado demandar, talvez a IT4Biz abra outras turmas. Se você tem interesse, manifeste-se para eles: http://www.it4biz.com.br/.