Toda empresa que deseja usufruir das vantagens que projetos de Inteligência de Negócios trazem (como incremento de lucros), precisa investir concomitantemente em Armazéns de Dados.
O primeiro passo é decidir o que se deseja: oferecer relatórios, análises, uma solução do tipo CRM ou Churn etc. Essa escolha vai determinar quais dados são necessários. Esses dados devem ser levados para um Armazéns de Dados (ou DW, do inglês Data Warehouse) antes de ser consumidos pelo projeto de BI.
Armazéns de Dados são bancos de dados, em qualquer tecnologia, que acumulam os dados da empresa. Um DW, em princípio, acumula todos os dados que a empresa julgar importantes hoje, como aqueles necessários para o projeto de BI, ou acreditar que possam vir a ser importantes no futuro. Os dados são armazenados no DW em sua menor granularidade, para que qualquer pergunta possa ser respondida.
Cada solução de BI implantada na empresa consome dados em formatos específicos. Por exemplo, relatórios e análises OLAP funcionam melhor se os dados estiverem organizados em um Modelo Dimensional. Já uma solução de CRM consome dados em formato “tabelão”, que são adequados a Data Mining. Painéis podem usar os dados de uma estrela dimensional, mas eventualmente pode ser mais producente usar tabelas especiais – simplificam a lógica nos painéis e tendem a reduzir o consumo de hardware. E assim por diante.
Observe sua vida: você usa uma só máquina para tudo? O seu carro passa fax? O seu fax corta grama? O seu barbeador bate bolo? Não, claro. (Caso sua resposta para uma destas perguntas seja sim, entre em contato comigo – vamos ficar ricos!!)
Da mesma forma que no mundo real, o mundo informatizado também usa programas e tecnologias específicas: banco de dados não serve HTTP, Java armazena dados, PHP não oferece cubos OLAP.
Armazéns de Dados não servem para consultas – servem para armazenar dados. Logo, o primeiro erro que precisamos evitar é “one size fits all”: uma tecnologia desenvolvida para resolver um problema não serve para resolver qualquer problema, muito menos todos.
Data Vault
Uma tradução livre do termo é Cofre de Dados: uma tecnologia adequada a acumular dados ao longo do tempo. A partir deste repositório de dados, outros projetos podem se servir do que precisar.
A idéia central de se ter um Data Vault é dispor de um repositório que receba e organize os dados de múltiplas fontes, de tal forma que seja muito fácil incluir ou remover fontes, sem quebrar o repositório e sem virar um pesadelo de manutenção. A partir daí, cada projeto de BI busca do DV os dados que precisa e grava-os em outros repositórios de dados, no formato que precisar.
Apesar de soar como uma camada desnecessária, aparentemente dobrando o esforço (com DV precisamos de dois ETLs no mínimo – um para dentro e outro para fora do DV), adotar um Data Vault reduz o trabalho porque torna o crescimento do DV algo semi-automático, e a criação de fontes secundárias algo padronizado.
Veremos a seguir um DV: seus componentes e como um é modelado. Tudo que será visto pode ser encontrado nos livros abaixo:
- O livro-texto: Supercharge your Data Warehouse, Dan Linstedt;
- Exemplo prático no Apêndice V: Pentaho Kettle Solutions, Matt Casters, Roland Bouman, Jos van Dongen.
Beltrano S/A
Para os exemplos vamos usar o diagrama de dados do banco transacional da Beltrano S/A:
Modelo E-R da aplicação transacional.
Leia este link para todos os detalhes sobre a base.
O Modelo de Dados
Um DV tem três componentes básicos:
- Hub
- Link
- Satélite
E mais algumas tabelas acessórias:
- Point-In-Time (PIT)
- Same-As
- Tabelas “dicionário”
Não vou entrar no detalhe das tabelas acessórias, pois elas resolvem problemas específicos que não são necessários para entender o mecanismo geral.
Hub
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.
DV Beltrano S/A: hub Empregados.
Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal dos dados. 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.
Se a mesma chave existe em vários sistemas, com os mesmos valores, essa tabela automaticamente integra esses sistemas. Por outro lado, se a mesma chave existe em sistemas diferentes, mas com valores diferentes diferentes, então elas devem ser carregadas em hubs separados por sistema. A integração é feita por uma tabela do tipo Same-As entre cada hub.
Eventualmente a chave de negócio no sistema de origem podem ser uma chave composta (ter mais de uma coluna), mas nunca podemos montar como chave de negócio as colunas 3 e 4.
Link
Links tão tabelas que guardam o relacionamento entre dois hubs.
Uma tabelas 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.
DV Beltrano S/A: link Empregados-Pedidos.
Uma tabela link mantém relacionamentos M para M entre os hubs. Elas não dizem nada sobre a validade desse relacionamento, mas apenas que ele foi detectado no sistema de origem. Uma tabela link pode manter auto-relacionamentos também: um hub empregado, quando um empregado é chefe do outro, usa uma tabela link para registrar o relacionamento pai-filho entre os empregados.
Ela também não sofre atualização: novos relacionamentos são inseridos, antigos são descartados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.
Satélite
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.
DV Beltrano S/A: satélite Empregados.
Ao contrário do hub e link, o satélite não tem uma chave primária própria. Ao invés disso a chave primária é composta pelas colunas 1 e 2 (BK/LK + LDTS.)
De novo ao contrário dos hubs/links, os registros de um satélite possuem validade: a cada carga o processo verifica se os registros do satélite ainda existem na origem. Se não existirem mais, eles recebem um date/timestamp atual na coluna 3 (LEDTS.) A cada carga os satélites mudam e desta forma acumulam histórico do sistema.
DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.
Os atributos de uma chave de negócio ou relacionamento não precisam estar totalmente contidos em uma única tabela: se os atributos variam em taxas diferentes (como quando alguns mudam todos os dias, enquanto outros apenas de vez em quando), eles podem ser gravados em tabelas diferentes.
Quando um mesmo conceito de negócio existe em dois sistemas, criamos um satélite para cada sistema, com cargas independentes.
Corpo
Hubs são conceitos de negócios, links relacionam estes conceitos entre si e os satélites dão o contexto dessas chaves e relacionamentos.
DV Beltrano S/A: modelo captura que empregado fez que pedido.
Se compararmos um DV a um corpo humano, os hubs são como ossos, formando um esqueleto, links são ligamentos que unem os ossos e satélites são todos os músculos, orgãos e pele que recobre o esqueleto, dando-lhe forma.
Ah! Existe um código de cores: hubs são azuis, links vermelhos e satélites são amarelos.
As Vantagens de um Data Vault
Um DV oferece três vantagens:
- Estabilidade e Isolação
- Repetibilidade
- Performance
Estabilidade
Basta deter-se um pouco sobre essas explicações e perceber que, se a empresa não muda constantemente de ramo, seus conceitos de negócios são relativamente estáveis. Ou seja, mesmo que a empresa mude a forma como ela processa sua vida diária, poucos conceitos de negócio vão nascer ou sumir ao longo do tempo. Mesmo assim, um novo conceito de negócio é imediatamente associado a um novo hub. A implementação desse novo hub não afeta os que já existem – o impacto por uma novidade em termos de conceito de negócio é zero.
Os relaciomentos entre dois conceitos também são, via de regra, estáveis. Pense em produto e fornecedor: podem surgir novos fornecedores (inseridos num hub “fornecedor”), com novos produtos (inseridos num hub “produto”), ou mesmo novos produtos de um fornecedor já existente. Quando isso acontece, o próprio processo de carga se encarrega de anotar esse relaciomento, automaticamente. Se um novo relacionamento é descoberto, porém, o impacto no DV é zero: basta criar a nova tabela link e produzir o código de carga dela. Nenhuma outra tabela do DV é afetada. Ah, e se um relacionamento “morrer”, basta desativar a carga para ele, e para seus satélites – sem NENHUM impacto no restante do Cofre de Dados.
Já os satélites, que são naturalmente mais voláteis, podem mudar de forma com certa frequência. Digamos que, hoje, o DV coleta todos os hipotéticos atributos do cliente. Algo acontece – inventam um novo tipo de e-mail – e passamos a registrar, no sistema de origem, mais esse atributo. Qual é o impacto disso no DV? A resposta é “depende”:
- O caminho mais fácil é simplesmente criar um novo satélite com apenas esse atributo e instalar o novo processo de carga para ele. Impacto zero, mas o custo de recuperar essa informação depois pode ficar muito alto, especialmente se formos preguiçosos o tempo todo. A título de curiosidade, essa abordagem leva a uma coisa chamada Anchor Modeling;
- O segundo caminho mais fácil é estancar o satélite atual, mudando seu nome para alguma coisa _ate_data-X, e criar um novo satélite com o novo atributo, e passar a carregá-lo daí em diante. É uma técnica mais interessante em situações que mais do que um par e tal de novis atributos precisam ser capturados. A derivação dos dados para as fontes secundárias precisa levar em conta as diversas versões da tabela, mas o impacto no DV é próximo a zero;
- Finalmente podemos simplesmente aumentar o satélite atual em uma coluna e atualizar a carga dele para levar esse novo atributo. A vantagem é que você mantém o mesmo número de tabelas que existia antes, mas agora seu processo de extração pós-DV precisa saber que esse atributo não vão existir em todas as versões de cada registro do satélite. Impacto para o DV: próximo a zero também.
Repare que o DV tem um impacto na sua atualização, mas esse impacto não se propaga para fora dele: em qualquer um dos casos listados acima, a extração de dados do DV para fontes de dados secundárias não sofre NENHUMA alteração. Mesmo nas opções que mudam as tabelas dos satélites (é indiferente o que acontece aos hubs e links), as alterações vão de nada (ignorar a nova tabela/coluna) a pouca (mudar o nome de uma tabela.)
Veja que se queremos que o novo atributo “saia” para as fontes secundárias, então o impacto vai ser maior.
Lido ao contrário fica:
A incorporação de novas fontes de dados ao Data Vault não perturba os processos de carga das fontes de dados derivadas: o DV pode ser evoluído com um impacto próximo ao desprezível para a carga dos data marts dimensionais, tabelas de painéis etc.
Isolação
Isso é perfeito para DWs que servem mais de um departamento (praticamente todos): mudanças requeridas por um departamento tem impacto desprezível a nulo nos produtos de BI de outros departamentos.
Repetibilidade
Um Cofre de Dados é montado com “pedaços” (tabelas) padronizados. Cada tipo de pedaço – hub, link ou satélite – segue um modelo (um template ou gabarito) e tem um processo de carga idêntico. Para cada nova tabela mudam-se coisas como chaves de negócio ou atributos, mas o processo em si, de desenhar o DV e seu ETL, é 100% repetitivo. Isso significa que criar um novo hub/link/satélite e seu processo de carga é o mesmo que copiar um outro elemento do mesmo tipo já pronto, e mudar os nomes das colunas e tabelas.
Em outras palavras:
O layout das tabelas e o processo de ETL para um Data Vault é 100% baseado em templates. A geração do processo de ETL pode ser automatizada ao ponto de um novo hub/link/satélite poder ser incluído no modelo e colocado em produção em menos de uma hora.
O tempo acima não é um chute: eu brinquei com um sistema real e descobri que consigo criar um hub em menos de 15 minutos, um link em menos de 20 e um satélite em menos de uma hora. O satélite leva muito mais tempo porque tem um número variável de colunas, e isso dá um trabalho extra para testar (a criação mesmo, de todos, é de cinco minutos – o resto é tempo desenho para saber que colunas usar e testar o resultado.)
Performance
O conceito de Data Vault foi feito tendo em mente a idéia de se aproveitar de capacidades de processamento paralelo massivo – MPP. Graças à sua arquiteturua, cada tipo de elemento de um DV podem ser carregados 100% em paralelo: podemos carregar todos os hubs ao mesmo tempo, todos os links ao mesmo tempo e todos os satélites ao mesmo tempo.
Graças a bancos de dados capazes de se espalhar em diversos servidores, e programas de ETL como o Pentaho Data Integration que pode escalonar elasticamente por inúmeras máquinas, o gargalo de carga de um Data Vault passa a ser a própria velocidade de rede e computadores – melhorando esses, reduzimos o tempo de carga
Data Vault 2.0 & BigData
Tudo que este post aborda vem da especificação 1.0 do Data Vault. A especificação do DV 2.0 troca as chaves sequenciais por hashes, o que permite carregar 100% dos elementos em paralelo. Graças à eliminação da dependência de um campo sequencial, um DV 2.0 é adequado para criar DWs diretamente em clusters Hadoop.
A Regra de Ouro do Data Vault
Daniel Linstedt define como a regra de ouro do DV
Carregar 100% dos dados, 100% das vezes
Ele diz, nas apresentações, que chega de chamadas do Centro de Dados de madrugada, avisando que a carga do DW parou. Chega de perder o sono por falhas causadas por dados mal-formatados. Um DV carrega tudo, da forma que vier. Como diz o cowboy, “eu carrego antes e limpo depois”. Bam! Bam! :-)
Conclusão
Sólidos projetos de BI de qualidade constroem-se sobre Armazém de Dados. A melhor tecnologia para construção de um DW é aquela que reduz seu custo e tempo de desenvolvimento, reduz retrabalho e aumenta sua performance.
Data Vault é um modelo de dados criado por Daniel Linstedt em 2000 que atende a todas essas necessidades. A versão 2.0 da especificação traz melhorias que permitem construir um DW diretamente em um cluster Hadoop e com isso baratear ainda mais o processo e a infraestrutura, enquanto aumenta sua performance.
Um Data Vault é o ponto final de um DW, mas um DW é só o ponto de partida para projetos de BI, que devem extrair seus dados do DW, no formato que desejarem, como bem entenderem.
É isso.
0 comentários:
Postar um comentário