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

As Vantagens do Data Vault

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


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


Uma Nova Categoria

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

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

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

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

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

Continuando, essa categoria já tem alguns nomes internacionais:

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

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

Processos e Problemas

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

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

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

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

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


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

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

A manutenção é incorporada nas sprints.

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

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

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

Ferramentas…

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

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

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

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

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

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

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

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

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

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

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

… e Soluções

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

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

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

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

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

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

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

Conclusão

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

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

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

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

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

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

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

Livro sobre Data Vault.
Livro sobre Data Vault.

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


Até a próxima!

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

Cruel Sucesso

Vou contar uma história usando Scrum, para simplificar. Mas se você conseguir imaginar um projeto Waterfall que dê certo, pode aplicar a mesma história, pois o resultado seria o mesmo.

No começo tudo são flores: o cliente e a equipe constroem o backlog do produto. Neste caso, uma prosaica solução de análise multidimensional, OLAP.

A equipe trabalha duro, sempre em contato com o cliente, e no final da primeira sprint conseguem demonstrar a ferramenta, instalada e funcionando, e uma estrela simples: uma fato com uma métrica de quantidade, e a dimensão Cliente. O usuário consegue, por exemplo, contar a quantidade de clientes por cidade ou estado. “Beleza, mas você vai me dar mais coisas, né?” pergunta o ansioso usuário final. Claro, reassegura-mo-lo, vai ter a sua estrela completa no final da próxima iteração.

Ao final dessa primeira demonstração o PO (Product Owner) e a equipe se reúnem para planejar a segunda sprint. O planejamento praticamente endossa o backlog anterior, com pequenas mudanças pontuais e inconsequentes. A segunda sprint começa, evolui bem e termina em ordem. Nova apresentação é feita para o cliente, agora com a primeira estrela completa. O cliente decide colocar o sistema em produção, mesmo faltando mais duas estrelas, previstas para a próxima iteração.

A apresentação ocorreu de manhã, e a retrospectiva à tarde. No dia seguinte o PO vem para o planejamento da próxima sprint.

É quando a porca torce o rabo.

Pensando Bem…

“… e este”, conclui o Scrum Master, “é o backlog atual.Acredito que vamos manter as mesmas demandas, não? Com isso nós vamos completar a primeira release do OLAP no final deste mês, daqui a duas sprints.”

O cliente olha no fundo dos olhos do SM e diz “Sabe, depois da apresentação ontem, eu voltei e pedi ao Sr. BI que me deixasse testar um pouco mais o sistema.” O Scrum Master olha para o Sr. BI, que olha de volta, inocentemente. “Ele deixou?”, pergunta o SM. Sim, ele havia deixado, e até respondeu algumas perguntas, tanto que ele se atrasou para o começo da retrospectiva. “E você achou algum problema? Quer cancelar a entrada em produção desta estrela?”

– “Não, claro que não. É que, pensando bem… Acho que as próximas estrelas não são bem o que eu preciso.”

Paciente e diligentemente, o Scrum Master e a equipe escutam as novidades, debatem para entender e ajustam o backlog.

Veja: estamos começando a terceira sprint. Da primeira para segunda, tudo certo. No final da segunda o usuário conseguiu usar o produto por umas poucas horas e, antes de começar a terceira ele pediu uma mudança. Tudo dentro do bem-comportado processo do Scrum e, até aí, nada demais.

Sprint 3

E assim a Sprint 3 começou. Como das outras vezes, a equipe buscava o PO para tirar dúvidas e manter o trabalho alinhado com o backlog, mas parece que os selvagens tempos das Cascatas insinuavam-se pelas frestas: o cliente tentou mudar o backlog quase todas as vezes!!

Não era intencional, claro, afinal o cliente sabe que sabotar a equipe de desenvolvimento causa só uma vítima – ele mesmo. Não, muito ao contrário. Ele queria evitar que a equipe entregasse algo pouco valioso. Por isso o cliente sempre estava preocupado em mostrar como, a partir da Estrela 1, que ele estava usando desde sua entrega no final da Sprint 2, ele havia descoberto que a Estrela 2 (e a 3 também) trariam uma dimensão incorreta. O grão dessas duas novas estrelas servia, para a análise que ele achava que precisava fazer, mas não serviriam para a análise que ele descobriu que precisa fazer.

Esse é um problema grave: havia um desalinhamento fundamental entre o backlog prometido no início da Sprint 3 e a realidade do cliente. Quando o cliente começou a usar a Estrela 1, ele começou a “entender” os dados, o negócio e percebeu que havia feito pressuposições, e que essas agora mostravam-se incorretas.

Cuidado Com o Que Deseja…

… por que você pode conseguir.

A maior marca de um projeto de BI de sucesso é o seu aparente fracasso.

Por quê? Porque um projeto de sucesso gera novas perguntas, que geram novas demandas de dados, que faz parecer que o projeto está sempre no início! Mas não! Ele deu tão certo que o cliente avançou e aprendeu – gerou Inteligência do Negócio a partir dos dados.

É nesse caminho que ia nossa história: assim que o cliente começou a usar os dados de uma entrega de sucesso, a compreensão do problema mudou. É uma consequência natural de se aprender mais: novos conhecimentos desafiam nossas antigas visões e percepções. Ainda que isso aconteça em projetos de outros tipos de sistemas, em soluções de Inteligência de Negócios essa dinâmica gera consequências complicadas.

Por exemplo, aonde vai nossa história? Como ela termina? Assim.

O Scrum Master sacou o problema e decidiu convocar um fim abrupto para a Sprint 3. O cliente sentou novamente com a equipe e refizeram o backlog. A Sprint 4 começou e seguiu sem problemas. A demonstração ao final conseguiu recuperar o moral da equipe – estavam de novo na crista da onda, entregando valor para o cliente! Yeah! Touchdown!

Começaram a Sprint 4, que agora ia incluir novas dimensões e estrelas para aumentar a comunidade de usuários. O PO agora eram duas pessoas: o primeiro cliente e um novo usuário do outro departamento. Montaram um backlog para as próximas três sprints e planejaram a Sprint 5. Enquanto isso o novo cliente passou a usar as estrelas que já haviam sido entregues.

E adivinhe o que aconteceu? Isso mesmo: ele percebeu que havia entendido algumas coisas incorretamente. De novo a equipe não conseguia andar na sprint porque o novo cliente não colaborava. Mas desta vez a recusa era hostil!

“Vocês atenderam o outro direitinho! Porque não querem fazer o que eu preciso? Isso que nós combinamos não estava certo! Agora eu percebo isso, e não adianta continuar, eu não vou usar o que vocês estão fazendo!”

Conclusão

Preciso continuar a história? A Sprint 5 foi abortada – de novo – e a sprint 6 e 7 replanejadas. A Sprint 6 saiu redondinha, mas o sucesso deixou uma sensação de desconforto ao invés de alívio. A Sprint 7 foi abortada, virou 8, que deu certo etc. etc. etc.

Estou montando esse cenário na melhor das situações, com equipe funcional e capaz, Scrum Master habilidoso, clientes inteligentes etc. Imagine uma empresa que desenvolva em Waterfall, com feudos departamentais disputando acesso e posse dos dados, usuários mal-preparados ou obtusos…

E esse é um problema ainda mais insidioso porque eu nunca vi ninguém percebê-lo. Por um tempo achei que eu estava viajando! A história acima tem um ritmo acelerado, e talvez a velocidade normal de um projeto seja um impecilho para identificar essa situação. Projetos de BI têm a bagunça da redefinição de requisitos como normal, como consequência da indecisão do cliente. Ainda que haja um nível de indecisão, não acredito que seja esse o responsável por fazer o projeto parecer retroceder periodicamente.

Se você não se identificou com a história, pense um pouco e tente se lembrar: algum de seus clientes parece estar sempre aguardando a próxima versão? Tem algum cliente que sempre volta pedindo alguma mudança? Um novo relatório, uma mudança na dimensão, outra agregação para a mesma métrica? Será que ele não está mudando os requisitos por que está aprendendo?

Da próxima vez que alguém reclamar que o projeto de BI está patinando, erga as orelhas: o projeto pode estar sendo vítima do próprio sucesso!

Até a próxima!


P.S.: eu não sei como lidar com isso. Eu ainda não consegui pegar um caso destes acontecendo claramente, e mesmo que tivesse pego, não sei se saberia o que fazer. Intuitivamente eu diria que precisamos deixar o cliente com o sistema a sós por algum tempo – uma semana? um mês? – antes de planeja a próxima etapa de desenvolvimento, mas duvido que algum cliente toparia isso…

Ué, Cadê o Perry?

Quem tem filhos pequenos (e usa-os como desculpa para assistir desenhos animados) conhece essa: o Phineas anuncia ao Ferb que “já sabe o que vamos fazer hoje”, olha para os lados e diz “ué, cadê o Perry?” O telespectador já sabe: segundos antes o Perry se esgueirou e sumiu por alguma passagem secreta, em direção à sua próxima missão contra o mais recente -inator do Dr. Doofenshmirtz – só o Phineas e cia. bela é que ainda não tinham notado.

O mundo está cheio destes momentos: “ué, cadê os números romanos?”, “ué, cadê a máquina de escrever?” e assim por diante. (Sério, os números romanos demoraram centenas de anos para sumir de vez.)

O que caracteriza esse momento ué-cadê-o-perry, na minha opinião, é o instante em que ele sai, mas ninguém no desenho notou ainda. É quando uma novidade que vai mudar a cara do mundo apareceu, mas ninguém ainda se deu conta dela, ou de que ela já mudou o mundo.

Tantas Opções, Tão Poucos Projetos…

Então, já repararam na quantidade de novos bancos de dados que apareceram recentemente? Hadoop é o mais vistoso, mas temos coisas como VoltDB, Vertica, MongoDB, InfiniDB, Infobright etc. etc. etc. E note bem: nenhum deles veio para ser um Hadoop-me-too ou um novo Postgres. Cada um deles oferece recursos específicos para tarefas específicas.

Com esse monte de opções, e com um entendimento mais claro de como um Data Warehouse Corporativo (ou EDW) pode ser arquitetado, vemos que não precisamos mais de um Banco de Dados Relacional para montar um DW. Com isso sabemos que um Sistema Gerenciador de Bancos de Dados Relacional pode se dedicar a tarefa que faz melhor (executar transações) e deixar soluções de BI usar outros softwares.

Arquitetura Típica de EDW

Um EDW deve acumular dados por um tempo a fio, sem final em vista. Até hoje, em quase quinze anos nesta indústria fundamental, eu nunca vi um modelo de dados mais adequado a um EDW que Data Vault.  Acredito que a melhor técnica para um EDW é um modelo de dados DV montado sobre um Hadoop. Graças tanto à flexibilidade e resiliência do DV, quanto a escalabilidade do Hadoop, um arranjo desses pode se sustentar durante anos a fio sem problemas.

Mas como DVs são bons para acumular e péssimos para apresentar (e não é por causa do Hadoop, que por acaso também tem o mesmo problema), a exploração não pode acontecer dentro do EDW. Neste ponto notamos que precisamos de Data Marts.

Esses Data Marts são trechos do EDW colocados ao alcance do usuário final. Disparado, a melhor organização para atender essa necessidade é um Modelo Dimensional.

Então temos dados extraídos dos sistemas de origem carregados em um EDW Hadoop+DV, e deste arranjo dados para exploração pelo cliente são carregados em Data Marts Dimensionais. Como Data Marts prestam-se, principalmente, à análise multidimensional e relatórios, a melhor opção para guardar esse extrato de dados é uma tecnologia que privilegie essa função. Não é uma discussão encerrada, mas há uma seção inteira de bancos de dados analíticos (ou colunares) dedicados a atender exatamente esse tipo de demanda. Exemplos dessa turma são o proprietário gratuito (até 1TB) Vertica, o livre InfiniDB e o fantástico (e caro, proprietário) SybaseIQ.

Ué, Cadê o SGBDR?

Colocando em uma figurinha simples, temos:

Soluções de BI sem Bancos de Dados Relacionais
Soluções de BI sem Bancos de Dados Relacionais

Ué, cade o banco de dados relacional em BI?

Não tem, sumiu. Enquanto ninguém olhava, ele esgueirou-se em direção às novas missões transacionais, e deixou esse nicho ser (adequadamente) preenchido por tecnologias mais apropriadas a BI.

Conclusão

O título original deste post era “Fim de Uma Era”, mas achei pomposo demais e muito ordinário. Isso, porém, não muda o fato de que a era dos SGBDs Relacionais usados para Soluções de BI realmente acabou. Ainda vamos ver empresas investindo nessa tecnologia para montar EDWs porque temos uma inércia em tudo que fazemos, e ainda estamos na curva ascendente de criação de mão-de-obra especializada em Hadoop et. al.

Mas tão logo a oferta mão-de-obra cresça o bastante, o sinal da equação vai mudar e a dobradinha de bancos NoSQL + Analíticos passará a a ser mais barata e eficiente que bancos relacionais, quando então teremos aquele momento:

Ei, cadê o Perry?
Ei, cadê o Perry?

É isso. ;-)

A.B.I.M.

Long gone are the years when to have or not a BI Solution (or Decision Support System) was yet an option. A company who choose not to analyze its data today won’t grow beyond a certain point. It has no tomorrow.

To have working BI initiatives is not easy, let alone simple. A sucessfull BI project depends on a lot of factors and to lead one is not a job for the faint of heart. Business Intelligence projects are experience- and knowledge-intensives. Even the customer must control a degree of education to reap the benefits.

A best selling book does not come from anyone armed with a word processor. A new software is not born out of the hands of its final user just because he/she has a point-and-click Java IDE within reach. Business Intelligence Solutions does not either. The whole big world is a complex place with less and less room for amateurs. Go educated or go extinct!

The Agile Manifesto

This was a milestone for the Information Technology Industry. The Agile Manifest broke the shackles tying projects to ever-late schedules in doomed iniatives, and opened up a road of unprecedent success. As a developer and manager I have embraced the A.M. and adopted Scrum as the means to implement AM. I ended using them both to do everything I do, including Teaching and building Business Intelligence projects.

Recently I became aware that, influenced by the A.M., I have brought some of those principles under a BI light, and I am sharing my insights here.

Agile Business Intelligence Manifesto

The highest priority is to help the customer to answer his questions through early and continuous delivery of quality data and tools for its exploration.

Changing requirements are a must because only so data exploration can shape new hypothesys and drive an increase in knowledge.

Deliver working advances on data platforms frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Take part in the customer’s problem: To help the customer answer his questions is to help him formulate them by employing specialized knowledge on tools and techniques.

A customer answering its questions is the primary measure of progress, so he can make new questions.

Conclusion

This list does not stand on itself, but rather extends the Agile Manifesto. It also does not take care of effective delivering the results, which should be achieved by using Scrum and a special, iterative technique for BI projects, soon to be posted here.

Personally I don’t agree that Agile BI is only about tools. It sounds like too little, leaving a lot outside, begining with the very customer.

I didn’t invent the above principles, I more like found them spontaneously sprouted and began guiding my work whilst studying and applying the A.M., Scrum and some other methodologies and strategies to my daily job. The statements I posted above are in fact the Agile Manifest adapted to BI needs as per my point of view. I missed a list like that a lot and as until now nobody made a movent toward them, I did. So, here is my proposal.

What is your opinion?


To my English speaking fellows a note: In Portuguese the generic third person is the male form – he/him/his etc. So when we say “he” as the meaning of “anyone” we also refers to women as well. So, I am not confortable with using “one” or “he/she” when refering to an unknown person, what led me to using “he/him” above in the place of a generic “customer”. Please! I have a lot of intelligent women as friends besides my own wife, and I would never downplay the importance of them! I just wanted to sweep the ethnical differences aside so not to taint the discussion or raise any wrong criticism. Right criticism is welcomed <grin>.

M.I.N.A.

Há anos Inteligência de Negócios deixou de ser uma opção. A empresa que não usa BI, hoje e no futuro, simplesmente não irá crescer além de certo ponto.

Inteligência de Negócios não é fácil, muito menos simples. Um projeto de BI de sucesso depende de muitos fatores, e não é uma tarefa para leigos. Projetos de Inteligência de Negócios são intensivamente dependentes do conhecimento dos gestores, dos desenvolvedores e do cliente. O cliente de um projeto de BI precisa estar educado para poder usufruir dele.

Um best-seller não nasce de qualquer um que disponha de um editor de textos. Um novo software não nasce a partir das mãos de um usuário com um produto point-and-click. Soluções de BI também não. O mundo é um lugar complexo e tem cada vez menos espaço para amadorismo e ignorância. Go educated or go extinct!

Manifesto Ágil

Esse foi um documento que dividiu as águas da indústria de artistas que são os desenvolvedores e criadores das tecnologias de TI, incluindo programadores, projetistas de hardware e software e um sem-número de outros profissionais. Apreender o M.A. quebrou os grilhões dos cronogramas atrasados, dos projetos destinados ao fracasso e me permitiu trilhar caminhos de sucesso sem precedentes.

Meu credo como desenvolvedor e gestor é o Manifesto Ágil, e Scrum é o método que eu adotei para implementá-lo. Eu os uso como ferramentas para tudo que faço, incluindo e especialmente Ensino e Inteligência de Negócios.

Eu descobri que, influenciado pelo M.A., tenho seguido alguns destes princípios para projetos de Inteligência de Negócios, e vim dividi-los com vocês.

Manifesto de Inteligência de Negócios Ágil

A maior prioridade é ajudar o cliente a responder suas perguntas, através da entrega contínua e cedo de dados e interfaces para sua exploração.

Mudanças nos requisitos são obrigatórias porque só assim a exploração cognitiva toma forma e novas hipóteses podem nascer.

Entregar avanços nas plataformas de dados frequentemente, entre semanas e meses, com preferência para o intervalo menor.

A principal medida de sucesso é o cliente encontrar resposta à suas perguntas, para que possa fazer novas perguntas.

Participar do problema do cliente: ajudá-lo a responder suas perguntas para ajudá-lo a formulá-las através do emprego de conhecimento especializado de técnicas e ferramentas.

Conclusão

Essa lista não se sustenta sozinha, mas sim estende o Manifesto Ágil. Ela também não executa o desenvolvimento, isso é feito por Scrum e uma técnica especial para BI, que eu postarei aqui em breve.

Não concordo que Agile BI seja apenas sobre ferramentas. É muito pouco, e deixa muito de fora – a começar pelo clientes.

Eu não inventei esses princípios. Depois de estudar o Manifesto Ágil, Scrum e várias outras técnicas, e aplicá-las ao meu dia-a-dia profissional, eu descobri que esses princípios surgiram espontâneamente e vêm norteando minha prática profissional. Eles são praticamente o Manifesto Ágil adaptado para BI – algo do qual eu sinto uma falta tremenda. Como ninguém ainda propôs nada, eis a minha proposta.

O que você acha?

Data Vault Para Quê?

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

Todo DW Deve Usar DV

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

(In)Definição funcional de DW

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

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

Bill Inmon

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

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

Ralph Kimball

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

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

Necessidade de Dados para BI

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

Armazenamento

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

  • Do tamanho da empresa;
  • Tudo que já existiu;
  • Sempre aumenta.
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!

Análise

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

  • Do tamanho de pessoas;
  • Só o relevante;
  • Renova-se.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.

Armazéns de dados usados para análise

Pausa para epifania:

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

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

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

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

Armazém + Supermercado = WTF???
Armazém + Supermercado = WTF???

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

Model Wars

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

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

Corporate Information Factory

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

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

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

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

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

Dimensional Enterprise Data Warehouse

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

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

Ele resolveu muitas dificuldades da CIF:

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

Mas mesmo assim ainda tem suas fraquezas:

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

CIF x EDW-D

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

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

Truco!

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

Apresentando Daniel Linstedt & Seu Maravilhoso Data Vault

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

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

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

Como é que mais Trabalho…

Quando implementamos um DV, dobramos o tamanho do EDW.

Arquitetura do EDW Dimensional típico.
Arquitetura do EDW Dimensional típico.

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

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

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

…dá menos Trabalho?

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

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

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

A Minha Experiência

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

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

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

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

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

Métricas Misturadas

Espanei logo na primeira estrela.

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

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

Há!

Grão Grilado

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

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

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

Supernova

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

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

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

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

Lixo, Lixo, Lixo

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

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

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

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

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

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

Re-Retrabalho

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

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

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

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

DV To The Rescue!

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

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

Conclusão

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

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

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

Estimando Projetos de ETL

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

Coletando os Parâmetros

A minha mecânica para estimar o trabalho de desenvolvimento do ETL de um DW é relativamente simples. Eu procuro descubrir os seguintes números:

  1. Quantos analistas você terá dedicados integralmente a construir o ETL. (Além dos analistas você vai precisar de um gerente.)
  2. Quantas origens 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 deve ter. É impossível responder essa pergunta com precisão antes de o MD ser efetivamente construído, mas você pode estimar esse número:
    1. Qual é a quantidade de processos automatizados pelo seu sistema transacional? Cada um equivale grosso modo a uma fato.
    2. Quais são os parâmetros que provavelmente filtrarão as análises? Daí conte o número de atributos que têm a resolução mais fina. Por exemplo, se você vai filtrar por ano, mês e dia, a maior resolução é obtida com dia. Ignore os outros atributos e conte um atributo só. Se as análises serão feitas contra bairro, cidade, estado, o atributo que dá a maior resolução é bairro. Como cidade e estado são do mesmo tipo (geográfica), conte mais um atributo. No final você vai ter uma lista inicial de dimensões.
    3. Exemplo: se quisermos analisar o tempo de atendimento de balcão, você precisará medir a data e hora inicial (DHi), a data e hora final (DHf), posto (cidade-bairro-posto), atendente (sexo-idade-escolaridade-nome-cpf-etc.), demanda, resolução (resolvido/pendente), tipo (reclamação/elogio/pagamento/negociação/etc.), cliente (PF ou PJ, cada qual com sua lista de atributos). Temos uma fato (atendimento) e 8 dimensões (se cliente virar uma tabela só, ou 9 se for em duas.)
  4. Volume de dados. Pode ser o tamanho de todas as bases em bytes e quanto ela cresce por tempo (dia ou mês), ou (preferível) quantidade de linhas iniciais adicionadas regularmente (dia ou mês) às fontes de dados.
  5. Os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
  6. 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.)

Definindo o Processo de Estimativa

Daí eu apela para a minha experiência. Supondo que um desenvolvedor seja capaz de entregar 4-5H de trabalho por dia: (alta produtividade!)

  1. Um desenvolvedor PDI proficiente leva de uma a duas semanas para cada dimensão ou fato.
  2. A medida que essa experiência cai, o tempo aumenta. Uma dimensão pode levar até mesmo um mês para ficar pronta se o analista começar o projeto sem conhecimento da ferramenta (ou mesmo com um curso.) Isso ocorre por que cada processo demanda um conjunto de truques particular, e o analista leva um tempo para internalizar a ferramenta e desenvolver seu repertório de macetes – como em qualquer outra ferramenta, aliás. Como passar do tempo esse número melhora, graças ao acúmulo de experiência do analista.
  3. A quantidade de fontes de dados acrescenta mais alguns dias nesse número: de nada a alguns dias (até uma semana) a mais por fonte de dados. Isso ocorre por que pode ser necessário algum estudo para integrar as origens (pior caso) ou apenas um join pode ser suficiente (melhor caso.)
  4. Volume de incremento no tempo: mais dois ou três dias para desenhar uma mecânica de tratamento de incrementos, que pode ser aplicada em todas as cargas. Esse tempo tende a sumir, diluído entre todos os processos de carga de dimensões e fato.

Sujeira: esse é o fator mais selvagem. Ele pode até dobrar o tempo de encerramento do desenvolvimento, a depender da quantidade de erros e sujeiras na base, e a capacidade do cliente em lidar com erros no DW (às vezes a sujeira não afeta a análise, às vezes a torna impossível.) Normalmente o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo e por isso não é usado para estimativas.

Estimando…

Então, para nosso exemplo com 8 dimensões, uma fato, com um banco relacional como única origem, dados 100% limpos e dois analistas (mais um gerente) você tem:

9 x 1 semana (cinco dias) / 2 analistas = 22,5 dias (~3 semanas).

É seguro triplicar esse número, para incluir todas as dificuldades não-previstas e adicionar um mês de overhead no início do projeto. Então temos 9 semanas + 1 mês = 13 semanas, o que dá uns três meses, mais ou menos, até a primeira versão beta do processo. Leva-se mais um ou dois meses entre ajustar o processo para produção e homologá-lo (controle de qualidade.)

Lembre-se que você vai precisar, também, estimar o tamanho da plataforma para entregar o refresh na latência requisitada por seu cliente.

Escrevendo na Pedra

Isso é só um parâmetro inicial, descontado o levantamento de requisitos, documentação etc. Com esse número em mãos eu reviso tudo que eu sei sobre o projeto antes de ele começar e uso minha intuição para ajustá-lo. Não raro eu entrevisto os analistas para entender o fator tarimba de cada um e verificar se eu fui otimista ou pessimista. Porém, esse número nunca é uma medida, mas sim apenas um chute elaborado (ou em bom inglês, um educated guess)  – variáveis desconhecidas podem mudar tudo completamente.

Quem é do ramo já deve ter percebido que o volume de variáveis desconhecidas e incertezas sugerem o uso de Scrum para gerenciar o projeto. Como o tamanho de uma transformação é de duas ou três semanas,  possivelmente eu adotaria isso como tamanho inicial das sprints, para fazer com que cada uma equivalha a entrega de uma transformação por analista. Após uma ou duas sprints a precisão desse número pode melhorar bastante.

O que você achou? Bate com o que você faz? Deixe seu comentário!