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

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

Cenário

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

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

Arquitetura original.
Arquitetura original.

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

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

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

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

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

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

Tudo Muda

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


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


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

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

Vem Quente…

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

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

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

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

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

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

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

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

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

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


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


…Que o DV Está Fervendo!

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

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

Não estamos esquecendo de nada?…

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

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

Conclusão

Um Data Vault carrega grandes promessas:

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

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

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

Anúncios

Um comentário sobre “Como Um Data Vault Evolui II

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s