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

Anúncios

Configurando PDI para Enviar Relatórios

O Pentaho Data Integration (PDI, antigo Kettle) oferece uma quantidade de opções para se comunicar com o “mundo exterior”. Por exemplo, ele permite envio de e-mails tanto em transformações quanto em jobs por meio de passos nativos, ou mensagens por mensageria instantânea (Instant Messaging, IM) através de plug-ins.

Plug-in PDI que envia notificações a smartphones Apple ou Android.
Plug-in PDI que envia notificações a smartphones Apple ou Android.

Um uso clássico dessa capacidade é o envio de algum tipo de notificação ao final de um processo de ETL. O PDI pode mandar um e-mail para todos os interessados, informando se o processo transcorreu em ordem, ou se houve algum erro, e qual é o estado atual dos dados. Essa transformação faz isso:

Transformação que monta e envia e-mail com relatório para uma lista de destinatários.
Transformação que monta e envia e-mail com relatório para uma lista de destinatários.

Foi exatamente essa transformação que eu usei em um projeto recente, e ela funcionou perfeitamente!… Em desenvolvimento. Em outras palavras, rodava beleza quando eu a testava no Spoon, que é a interface gráfica do PDI, mas falhava fragorosamente ao rodar no ambiente de produção, via linha de comando. Depois de um pouco de tentativa e erro eu consegui resolver todos os problemas, soluções que eu divido com vocês no post de hoje.

Mudança de Ambientes

A primeira dificuldade é o fato de os bancos de dados, seus IPs, usuários e senhas serem diferentes em cada ambiente. Se em desenvolvimento o banco chama-se dw_corp, com usuário e senha postgres, em localhost:5432, em produção sem dúvida será diferente – no mínimo a política de segurança da empresa vai cuidar de ter usuário e senha “protegidos”, i.e., que só o gestor do processo em produção sabe qual é.

Resolvemos essa dificuldade parametrizando toda e qualquer referência ao banco de dados (e por extensão a diretórios, servidores de apoio etc.)

Conexão PDI

Parametrizar uma conexão PDI é simples: basta usar variáveis para registrar os valores de parâmetro de uma conexão. A figura abaixo mostra uma conexão com o banco Beltrano OLTP parametrizada:

Conexão PDI parametrizada.
Conexão PDI parametrizada.

Daí é só registrar essas variáveis e seus valores no arquivo kettle.properties, que fica dentro do diretório .kettle, na raiz do usuário. Seu ambiente de desenvolvimento terá valores para o PDI acessar os seus bancos, enquanto que em produção deve existir um arquivo análogo, configurado adequadamente para esse ambiente, pelo próprio gestor da máquina de produção.

Conexão PRD

Eu queria enviar relatórios bonitos, bem formatados, e não um simples arquivo texto com algumas contagens e por isso eu usei o Pentaho Report Designer. Daí, de cara eu sabia que teria o mesmo problema: valores de conexão diferentes para cada ambiente. Infelizmente, porém, o PRD não pode usar as mesmas variáveis que o PDI usa. Não dá para colocar o mesmo ${BELTRANO_OLTP_HOST} da conexão do PDI no PRD, mas dá para usar uma fonte de dados JNDI, que é um tipo de conexão disponível por meio do ambiente Java.


Eu tive sorte em descobrir como usar JNDI. Nem pense em me perguntar o que é ou como funciona…


Definir uma fonte JNDI no PRD é simples: apenas selecione esse tipo e forneça um nome:

Conexão JNDI no relatório PRD.
Conexão JNDI no relatório PRD.

E onde são registradas os parâmetros de uma conexão JNDI? No arquivo default.properties, dentro do diretório /home/<USUÁRI>/.pentaho/simple-jndi, neste formato:

NomeJNDI/type=javax.sql.DataSource
NomeJNDI/driver=org.postgresql.Driver
NomeJNDI/user=postgres
NomeJNDI/password=postgres
NomeJNDI/url=jdbc:postgresql://EnderecoServidor:5432/NomeDoBanco

Os itens driver e url são particulares de cada banco. O restante é sempre igual.

Parametrizando o PRD no PDI

Com a parametrização do PDI e do PRD eu conseguia montar e rodar processos e relatórios nos dois ambientes sem me preocupar com mais nada, desde que cada um rodasse independentemente do outro. Ou seja, uma transformação executada pelo PDI, e um relatório pelo PRD – no máximo dentro do servidor Pentaho.

Mas eu queria rodar o relatório a partir do PDI!

O primeiro obstáculo foi fácil: onde eu definiria a conexão JNDI do PDI, que – pela simples definição de JNDI – seria repassada a um PRD disparado a partir do PDI? No arquivo jdbc.properties, na pasta ./data-integration/simple-jndi. Basta copiar para ali a definição do outro default.properties, e lembrar de fazer a mesma coisa no ambiente de produção.

Parametrizando o Parametrizador

Ah, se fosse tudo tão lógico e simples!

Foi aqui que a porca torceu o rabo: em desenvolvimento, na interfave gráfica, todas as variáveis eram “vistas” pelo Spoon por default – todas as definições JNDI, por exemplo. Mas ao tentar rodar em produção apareceu uma mensagem nada a ver…

INFO 15-07 09:13:31,507 - Beltrano JNDI Postgres - New database connection defined
ERROR 15-07 09:13:31,534 - Count incomplete revisions - An error occurred, processing will be stopped:
Error occured while trying to connect to the database
java.io.File parameter must be a directory. [/home/users/kettle/CLIENT/simple-jndi]

Depois de cavocar o Google um pouco, eu descobri que, a partir da versão 4.1, o PDI passou a aceitar que o arquivo com as definições JNDI ficasse em qualquer lugar, e não apenas dentro do ./data-integration.

Trecho que chama o Java, dentro dos scripts. Note a variável -DKETTLE_JNDI_ROOT.
Trecho que chama o Java, dentro dos scripts. Note a variável -DKETTLE_JNDI_ROOT.

Para complicar a vida do desenvolvedor, o Spoon preenche essa variável automaticamente, apontando diretamente para o diretório que contém o arquivo de definições, mas o Kitchen e o Pan, não!

Essa modificação precisa ser feita pelo gestor do ambiente de ETL. Para definir a localização do arquivo de propriedades JNDI basta alterar a variável -DKETTLE_JNDI_ROOT,que é definida no final da chamada do Kitchen ou Pan (e até mesmo do Spoon, mas lembre-se que o Spoon faz coisa a mais), setando-o uma linha antes da chamada ao Java, desta forma:

KETTLE_JNDI_ROOT=/opt/pentaho/5.1/data-integration/simple-jndi

Note que eu apontei a variável para o meu diretório-padrão. Você deve inserir o diretório correto para sua instalação, não apenas copiar o exemplo acima, cegamente.

Pronto! Finalmente o PRD passou a rodar, parametrizado, dentro do PDI, tanto em desenvolvimento quanto em produção!


Veja este post no fórum internacional, aqui reproduzido parcialmente para o caso de ter sumido=.)*

Post do fórum Pentaho no qual é solucionado esse problema.
Post do fórum Pentaho no qual é solucionado esse problema.

Conclusão

Uma das eternas promessas da TI é oferecer gestão por exceção. Nesta modalidade, os gestores de alguma coisa são notificados quando esta alguma coisa assume um estado inadequado. Por exemplo, quando os valores de indicadores caem fora de certas faixas, ou quando um erro surge em algum sistema. Na gestão por exceção, o sistema não dá um pio enquanto tudo estiver certo, e dispara notificações quando as coisas saem dos trihos.

Ferramentas de ETL também carregam essa promessa. Dependendo do marketing, ora vende-se a idéia de avisar o gestor do processo de ETL tão cedo ocorra um erro, ou notificar os clientes que os dados foram carregados e estão pronto.

O PDI pode executar a tal gestão por exceção: basta incutir-lhe a lógica de notificação e os mecanismos de comunicação adequada. Como vimos neste post, dá para desenhar um relatório de alta qualidade, renderizá-lo em PDF e transmiti-lo por e-mail para um ou mais destinatários, sempre que uma condição desejada é atingida.

Colocar isso tudo para rodar, porém, são outros quinhentos. Neste post vimos como parametrizar tanto o relatório PRD quanto os artefatos PDI para garantir que o processo funcionará em desenvolvimento e em produção.

Até a próxima!

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!

Resenha de Livro – Como Criar Ambientes com Vagrant

No post anterior eu comentei sobre as possibilidades que existem para melhorar a produtividade de um projeto de BI. Especificamente, falei de ferramentas que automatizam diversas tarefas, como testar o projeto e configurar ambientes.

O idéia para essa discussão veio de um livro que eu acabei de ler:

Creating Development Environments with Vagrant, pela Editora Packt.
Creating Development Environments with Vagrant, pela Editora Packt.

Acredito que a Packt dispensa apresentações – é uma das mais prolíficas editoras técnicas do mundo, com centenas de títulos, sobre os mais variados assuntos técnicos. Oferecem de livros sobre PHP a vídeos sobre BI, passando por “livros de receitas” (cookbooks) sobre tudo quanto é assunto – robótica, linguagens de programação, BPMS, BI (90% dos livros de Pentaho no mercado são deles), quase todos os Softwares Livres (ao menos quase todos daqueles que se estabeleceram) e muitos softwares propritetários, uma lista interminável. Todos de alta qualidade, excelente acabamento e muito cuidado na edição. Ou seja, se eles tiverem o livro que você precisa, compre. Dificilmente você vai encontrar algo tão bom quanto ou melhor.

Foi neste livro que eu comecei a entender as atividades de GCS que existem em um projeto de BI, e como elas tomam tempo. Vou falar um pouco sobre o conteúdo do livro e depois mostrar exemplos de como as coisas funcionam.

Resenha Creating Development Environments with Vagrant

Este é um daqueles livros da Packt que se encaixam na categoria de hands on. Há exercícios e coisas para fazer desde o início, sempre embasado com uma explicação que contextualiza a atividade e mostra os caminhos que existem a partir dali. Vamos por partes:

  • O livro tem sete capítulos e um apêndice, fora as partes que fazem o padrão Packt (prefácio, acesso ao material do livro, sobre o autor etc.)
  • Os sete capítulos tratam de como usar o Vagrant, e o apêndice mostra um exemplo completo, passo-a-passo, de como montar um servidor LAMP.

Os capítulos são os seguintes (os títulos são traduções livres, sem relação com o nome original:)

  1. Introdução: a idéia de ambientes de desenvolvimento é debatida, e o conceito do Vagrant é apresentado. Na prática esse capítulo apenas prepara o caminho.
  2. Gerenciando boxes Vagrant: neste capítulo efetivamente aprendemos a criar uma “caixa” (ou box) Vagrant, que é a gíria para máquina. Ele é auto-suficiente o bastante para que os apressadinhos pulem o capítulo 1 e caiam diretamente aqui (desde que tenham instalado o VirtualBox e o próprio Vagrant;)
  3. Puppet: o Puppet é um aplicativo para gerenciamento e “patrulhamento” (enforcement) de configuração. Por assim dizer, podemos controlar o ambiente de uma máquina inteira apenas descrevendo o que ela deve conter em termos de softwares e arquivos. Um dos usos do Puppet é garantir que uma máquina não tenha sua configuração alterada: se alguém apagar ou mudar algo, ou adicionar um novo programa, o Puppet vai lá e reseta a máquina para o estado definido;
  4. Chef: igual ao capítulo anterior, mas agora com um “concorrente” do Puppet, o Chef;
  5. Vagrant com provisionadores: provisionador é o nome genérico de softwares como Puppet e Chef. Este capítulo mostra como usar o Vagrant para acionar os provisionadores vistos nos capítulos anteriores e conseguir uma máquina tal qual desejarmos;
  6. Multimáquinas: até o capítulo 5 é mostrado como construir ambientes com uma só máquina virtual. Claro que se parasse ali seria muito pouco, pois não raro temos ambientes com uma máquina para cada pedaço do sistema. Aqui vemos justamente como construir um ambiente de desenvolvimento com mais de um servidor, aproveitando a capacidade de rede virtual fechada do VirtualBox;
  7. Uma caixa para chamar de sua: até aqui livro inteiro mostrou como usar boxes pré-fabricadas, mas um dos recursos básicos e mais importante do Vagrant é a capacidade de criar um padrão de máquina. No último capítulo do livro aprendemos como construir uma máquina adequada ao nosso ambiente e exportá-la, tal que possa ser usada em qualquer outro projeto.

The Good

Gostei da organização do livro. Na minha opinião, ele consegue manter um equilíbrio no ritmo de apresentação de funcionalidades com conceitos, e nunca pressupõe que você saiba algo que seja importante para avançar. Tanto é assim que os capítulos 3 e 4 são completamente dedicados a ferramentas que, por si só, já merecem outro livro. Mesmo assim ele não se perde em coisas desnecessárias, nem corta o assunto pela metade, sempre apresentando o necessário para aproveitamento do Vagrant e indicando como se aperfeiçoar, ou destacando o que é mais importante ou menos.

Também gostei muito da prosa do autor. Ele não é prolixo, floreando demais, nem é seco a ponta das frases ficarem telegráficas. Isso, aliás, é um traço dos livros da Packt: raramente vemos um texto tacanho ou enfadonho. Alguns são difíceis, mas difilmente mal-escritos.

Se você não tem muito tempo, os dois primeiros capítulos já matam o essencial. Eles te dão uma visão encorajadora do assunto e mostram exemplos fáceis, que servem para despertar o gostinho pela coisa, enquanto apresenta os comandos mínimos e o passo-a-passo para criar e subir seu primeiro ambiente. Só com isso já para arquitetar sua vida.

The Bad

Bom, como dizer? Há uma grande diferença entre entender como funciona e realmente fazer funcionar. “Ah, uma máquina Pentaho é um Ubuntu, com Java 7, Postgres e o BA Server.” Simples, não? Para entender como criar a máquina é suficiente ir até o capítulo 2. Para conseguir que ela tenha Postgres, por exemplo, um pouco de Puppet/Chef resolve. Mas é só falar de colocar Java, e depois o BA Server, que tudo começa a cair em casos especiais.

Trocando em miúdos, há um bom aprendizado de Puppet/Chef no meio do caminho até você conseguir produzir, sozinho, um servidor Pentaho básico. Ou seja, se por um lado o livro cobre bem Vagrant, chegando a ambiente multi-máquinas e criação de boxes próprios, por outro é preciso bem mais que Vagrant para esculpir um ambiente adequado, que dizer otimizado.

The Ugly

Eu gostei muito do livro. Raramente eu me enamoro por tecnologias de infra-estrutura, mas o Vagrant é tão bacana que é impossível – IMHO – não gostar dele. E como o livro é bem escrito e bem-feito, também seus problemas não são um incômodo.

E quais são esses problemas?

Em primeiro lugar ele abre muitos caminhos paralelos para tratar de cada assunto. Por exemplo, quando ele começa a criar o primeiro ambiente, ele não vai até o final e sobe tudo, mas sim discorre sobre os aspectos mínimos de cada configuração, comando, opções etc. Como eu disse, isso não chega a atrapalhar – não quebra o ritmo da leitura, nem prejudica a compreensão. Mas eu sou um cara mais linear, que gosta de ir até o fim em cada trilha, e depois percorrer os caminhos laterais. Coisa de macaco velho de RPG, que evita sair mergulhando no primeiro desvio e faz tudo sistematicamente (não sobrevivi a quase todos os Final Fantasy, Chrono Trigger e Dragon Quest correndo que nem um louco. ;-) )

Em segundo lugar, ele ensina sobre o Vagrant, e até bastante sobre o Vagrant. Só que é preciso saber mais coisas para preparar um bom servidor. Por exemplo, como é que instalamos e configuramos um programa qualquer? Resposta: usando o Puppet/Chef apt-get etc. E um Java? Uma configuração? Ou uma ação menos ortodoxa? O livro poderia trazer algumas receitas mais banais, para que o vagranteer incipiente não precise continuar estudando um bocado até começar a se virar. Só para comentar como isso afeta o meu caso especificamente (Pentaho), basta notar que o livro dá uma boa visão de gestão de usuários e grupos nas máquinas virtuais, mas não tão boa na parte de transferência e alteração de arquivos. Como muito das configurações do Pentaho BA Server são feitas por arquivos, eu vou ter que estudar mais para conseguir o mínimo.

Resumindo, e isso não é falha do livro, um uso proficiente do Vagrant requer um certo conhecimento paralelo, que não é muito fácil de conseguir. Uma melhoria interessante para a segunda edição seria entregar um pouco mais, como algumas “receitinhas”-padrão com Puppet/Chef. (Quanto aos caminhos meio tortuosos, podem não ser o máximo, mas não atrapalham. Eu deixaria como está.)

Ambiente Pentaho BA Server com Vagrant

Claro que eu não poderia terminar o post sem contar como foram minhas experiências com o Vagrant. E eu conto: foi muito boa. As coisas aconteceram exatamente como o livro mostrou – mais um ponto para ele! – e eu não fiquei perdido, como normalmente fico quando vou aprender alguma coisa nova do zero. Comparado com meu aprendizado do Git, por exemplo, foi muito mais fácil!

A porca torceu o rabo, porém, quando eu comecei a tentar titerear meu ambiente.


Titereiro(a) é a pessoa que mexe os fantoches – puppets – por meio de cabos e travessões. O ato de controlar as marionetes é chamado de titerear.


Falando claramente, me enrolei todo quando eu tentei escrever um script Puppet (scrupet?? kkkk.) No final das contas eu desisti e apelei o bom e velho vagrant ssh, acessando a máquina e instalando tudo na mão. Obviamente essa é a maneira mais burra de se gerenciar o ambiente Vagrant, mas deu para ter um gostinho de como pode ser.

A empresa que cuida do Vagrant, HashiCorp, oferece um repositório de caixas prontas. É um tributo à elegância do Vagrant o fato de que basta executar vagrant init com o nome do box e depois vagrant up para o programa fazer tudo sozinho. Já existe até mesmo dois ambientes Pentaho: Pentaho 4.8 e Pentaho 5.4. Eu tentei testá-los, mas não tive tempo até o fechamento deste post. No próximo post trarei minha experiência completa de configuração de um Pentaho BI Server 5.4 com Vagrant.

Conclusão

Vagrant é uma ferramenta muito bacana e com potencial para melhorar muito a qualidade do seu processo de desenvolvimento, seja de soluções de BI, seja de softwares tradicionais. A Packt oferece um excelente livro para isso, o Creating Development Environments with Vagrant.

Com o que o livro ensina eu consegui montar um ambiente Pentaho BI Server. Ainda não é o melhor servidor, porque, para conseguir isso, eu precisaria aprender ao menos um pouco sobre outra ferramenta: um provisionador chamado Puppet (ou Chef, mas eu gostei mais do Puppet.) Outro livro da Packt ajudaria: Puppet 3: Beginner’s Guide.

Puppet 3: Beginner’s Guide.
Puppet 3: Beginner’s Guide.

Aliás, eles oferecem vários sobre Puppet. Você pode consultar este artigo, da própria Packt, para algumas opções.

Existe um outro livro sobre Vagrant, mas de outra editora: Vagrant: Up and Running

Este livro é recomendado diretamente do site do Vagrant.
Este livro é recomendado diretamente do site do Vagrant.

Sabe brinquedo novo? Então, estou me sentindo assim com o Vagrant, tanto que estou dando um tempo na Soluções Clássicas! :-D