Instalando A Base Beltrano S/A

Em breve publicarei um post sobre o uso de metamodelos como fontes de dados no PRD. O post de hoje é para ajudá-lo a se preparar, e não traz nada de novo: como instalar Postgres e as bases da Beltrano S/A.

Esse post é uma atualização das instruções de instalação da base de treinamento Beltrano S/A. Você pode seguir este link para conhecer a Beltrano e como ela foi pensada. O texto a seguir apareceu pela primeira no Capítulo 3 do livro Pentaho na Prática.

Instalando e Configurando um Postgres

Para usar as bases OLTP e DW da Beltrano você precisa ter um Postgres instalado e funcionando, bem como conhecer o usuário root e sua senha. Se você já tem um, clique aqui e pule para etapa seguinte. Caso contrário, siga os passos descritos nesta seção para instalar um Postgres em sua máquina.

Se você usa Windows, continue lendo. Se usa Linux, pule para a próxima seção.

Instalar PostgreSQL no Windows XP

As instruções de instalação no Windows estão disponíveis em um e-Book gratuito.

Capa do e-Book Instalando Postrgres 9.0 no Windows.

Capa do e-Book Instalando Postrgres 9.0 no Windows.

Você pode usar o Calibre ou qualquer outro programa leitor de e-Pubs para lê-lo.


Eu tinha uma licença do WindowsXP e resolvi aproveitá-la para fazer esse tutorial. Pelo mesmo motivo (falta de licença) não existe tutorial para Windows mais novos. Entretanto, a uniformidade entre as versões do Windows deve ser o bastante para que você possa seguir praticamente 100% do tutorial em qualquer versão mais recente do Windows.


Instalar PostgreSQL no Linux

Linux é um sistema operacional com n sabores – distribuições – e é virtualmente impossível cobrir todas. Por isso eu não fiz um livro mostrando como instalar Postgres em Linux, mas fiz para Windows. Vamos ver um passo-a-passo para Debian/Ubuntu. Se não for o suficiente, acesse a página de instalação do PostgreSQL para outros Linuxes.

Esse procedimento funciona em qualquer derivado Debian (como o Ubuntu). Existem opções gráficas, mas a linha de comando é universal e relativamente simples.

  1. Abra um terminal de comandos;
  2. Digite,seguido de \[ENTER\]:
    sudo apt-get install postgresql
    
  3. Se perguntado, responda Y ou S. Assim que a instalação acabar você terá um banco instalado, configurado e em operação, mas vazio;Em seguida, altere a senha do usuário-padrão, postgres, para algo fácil de lembrar (e potencialmente inseguro), como postgres. Faça assim:
  4. Entre na conta de usuário Postgres do sistema operacional (aquele que executa o programa do servidor:)
    sudo su – postgres
    

    Esse usuário do sistema operacional (postgres) tem permissão para acessar o servidor PostgreSQL diretamente. Ele é criado pelo processo de instalação do banco e recebe uma senha aleatória, que nunca é mostrada ao usuário final. Como não sabemos nem a senha do usuário nem a senha do root do banco, precisamos fazer login na conta de sistema operacional postgres com sudo. Você até pode modificar a senha desse usuário, mas não há razão para isso.

  5. Agora entre no programa de interface de linha de comando do PostgreSQL, o PSQL, digitando o comando:
    psql
    
  6. Deve aparecer um prompt, esperando comandos, parecido com isso:
    postgres=#
    

    Pronto, você está no prompt do PSQL. Agora altere a senha do usuário do banco (que é diferente do usuário do sistema operacional no qual o banco é executado):

    ALTER ROLE postgres with password 'postgres';
    

    ROLE é o usuário, e entre as aspas simples está a nova senha – postgres. Se deu tudo certo, deve aparece uma mensagem como:

    ALTER ROLE
    postgres=#
    
  7. Saia do PSQL, digitando \q seguido por \[ENTER\];
  8. Faça logout da conta postgres, digitando exit seguido por \[ENTER\].

Agora você tem um servidor PostgreSQL instalado e pronto para ser usado. Sempre que precisar acessá-lo para algo, comande:

    psql postgres -U postgres

Se ele pedir senha, ela será postgres.

Fazer o Postgres Aceitar Qualquer Conexão


Atenção! O procedimento abaixo vai abrir seu PostgreSQL para acesso por qualquer um na mesma rede em que você está! Lembre-se disso ao criar bancos e gravar dados nele. Essa configuração é útil para desenvolvimento, testes, treinamento, mas é perigosa para ambientes de produção ou no caso de dados sensíveis.


  1. Volte à conta do postgres. Em um terminal, entre novamente:
    sudo su – postgres
    
  2. Abra o arquivo de configuração pg_hba.conf para edição com seu editor de textos favorito. Nosso exemplo usa o nano:
    nano etc/postgresql/X.Y/main/pg_hba.conf
    
  3. Vá até o final do arquivo e insira a seguinte linha:
    host all all 0.0.0.0/0 md5
    

    Isso vai fazer com que o servidor aceite conexões de qualquer IP, desde que forneça usuário (postgres) e senha (postgres) para qualquer banco;

  4. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  5. Agora edite o arquivo de configuração do servidor postgres.conf:
    nano etc/postgresql/X.Y/main/postgresql.conf
    
  6. Role o arquivo até encontrar a linha com listen_addresses;
  7. Altere localhost para *. Isso vai fazer com que o servidor passe a ouvir conexões de qualquer IP;
  8. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  9. Re-inicie o servidor:
    /etc/init.d/postgresql restart
    
  10. Finalmente saia da conta de usuário postgres:
    exit
    

A partir de agora qualquer cliente PostgreSQL pode se conectar ao seu servidor.


Dica: se você for adotar o PostgreSQL como banco para sua empresa, contrate suporte especializado e treine pelo menos um DBA. Você faria isso com Oracle e MS SQL Server, porque vai deixar de fazer com PostgreSQL (ou MySQL)?


Instalando as Bases

Primeiro, instale as bases:

  1. Baixe-as destes links (clique nos nomes dos bancos:)
    1. Beltrano (OLTP) (arquivo beltrano_oltp_10k_pedidos.backup.zip;)
    2. Beltrano DW (arquivo beltrano_dw.backup.zip;)
    3. Beltrano Log (arquivo beltrano_log.backup.zip;)
  2. Descompacte-as em um diretório conhecido e sem espaços no path. Por exemplo, C:\ no Windows e /opt/beltrano no Linux.
  3. Se você usa Linux, não se esqueça de mudar as permissões dos arquivos (já descompactados) com um chmod 777 *.backup.Usando o PSQL (interface de linha de comando do Postgres), conecte-se ao servidor, crie um banco vazio para cada base e restaure-as neles:
  4. Rode o PSQL:
    1. Windows: rode o programa SQL Shell, que fica em Menu Iniciar -> Programas -> Posgtres <Versão> -> SQL Shell (psql);
    2. Linux: abra um terminal e comande psql -U postgres. Isso vai conectar você ao servidor localhost, porta 5432, banco postgres, com usuário postgres;
  5. Crie o novo banco de dados, comandando:
    1. Beltrano OLTP: CREATE DATABASE beltrano; (inclua o ponto-e-vírgula!);
    2. Beltrano DW: CREATE DATABASE beltrano_dw; (não se esqueça do ponto-e-vírgula!);
    3. Beltrano Log: CREATE DATABASE beltrano_log; (já sabe, não? Ponto-e-vírgula incluso!);
  6. Conecte-se a cada uma das bases recém-criadas e restaure-as. Ou seja, ainda no psql, comande (pressionando \[ENTER\] ao final de cada linha:)
    \c beltrano
    \i /opt/beltrano_oltp_10k_pedidos.backup
    \c beltrano_dw
    \i /opt/beltrano_dw.backup
    \c beltrano_log
    \i /opt/beltrano_log.backup
    

    Cada um destes comandos terá uma resposta. Os comandos \i efetivamente populam o banco, processando cada linha do script, e por isso resulta em uma lista maior de respostas – uma para cada comando do arquivo de backup.


Esse script é para Linux!


Windows: entre os mesmos comandos acima, mas use o caminho c:\, com barra contrária, ao referenciar o arquivo. Por exemplo:

  • \i c:\beltrano_oltp_10K_pedidos.backup
  • \i c:\beltrano_dw.backup
  • \i c:\beltrano_log.backup

Voilà! Bases instaladas e prontas para os exercícios. Você pode comprovar usando o pgAdmin para examinar os bancos e verificar o conteúdo das tabelas.

Bases restauradas (pgAdmin III do Windows.)

Bases restauradas (pgAdmin III do Windows.)

Coletânea Geek BI 2012 – Lançamento Oficial

Em 1/5/2015 a coletânea de posts do blog foi publicado como um e-book na Amazon.com:

Página do Geek BI 2012 na Amazon.com.br

Apesar de já fazer algum tempo, estou marcando hoje, dia da minha palestra no Pentaho Day 2015, como lançamento oficial! E para marcar a data eu programei uma promoção especial: hoje e amanhã (dias 15 e 16 de maio de 2015) o livro estará disponível gratuitamente na Amazon.com.br!


Você pode ler o livro em qualquer dispositivo – não é necessário possuir um Kindle!


Capa da coletânea.

Capa da coletânea.

Esta página do blog conta um pouco mais sobre as coletâneas do Geek BI. Se ainda não for o bastante para te deixar com curiosidade, você pode baixar uma amostra gratuita e sem compromisso – como qualquer outro e-book lá.

Compre! ;-)

CategoriasGeneralidades Tags:, ,

PentahoDay 2015 – Sopa de Letrinhas

Em função do falecimento do meu pai hoje, 14/5/15, minha palestra de amanhã foi cancelada. Eis o post que estava programado para amanhã.


Conforme prometido durante a minha apresentação de hoje no PentahoDay 2015, eis aqui o PDF para download.

Arquivo PDF da Apresentação do PentahoDay 2015

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

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…

Pentaho Day 2015: Eu Vou!

LogoPentahoDay2015

Semana passada eu tive a honra de ser convidado pela organização do Pentaho Day 2015 para apresentar uma palestra no evento. Este ano a coordenação está sob liderança de Márcio Vieira, da Ambiente Livre, e o evento será em Curitiba, dias 15 e 16 de maio.

Ontem eu recebi a confirmação que minha proposta foi aceita:

http://www.pentahobrasil.com.br/eventos/pentahoday2015/blog/fabio-de-salles-pentaho-day/

O tema é Introdução à Inteligência de Negócios – Nadando na Sopa de Letrinhas de BI.

Você pode se inscrever através do Eventbrite – basta clicar aqui.

Nos vemos lá! :-)

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 114 outros seguidores