>
>
>
Enterprise Data Warehouse>
Com a abordagem EDW, os dados são carregados em uma Área de Aterragem transitória, após a qual uma série de processos ETL são usados para carregar os dados em um terceiro armazém de dados da empresa de forma normal. Os dados são posteriormente extraídos em marcas de dados dimensionais para análise e relatório.
As desvantagens mais significativas desta abordagem incluem:
- Time to Market: O Enterprise Data Warehouse deve primeiro integrar os dados de cada um dos sistemas fonte em um repositório central de dados antes de estar disponível para relatórios, o que adiciona tempo e esforço ao projeto.
- Complexidade e Habilidade: Um data warehouse pode precisar integrar dados de uma centena de fontes, e projetar um modelo de dados em toda a empresa para suportar um ambiente de negócios complexo é um desafio significativo que requer especialistas altamente qualificados em modelagem de dados.
- Falta de Flexibilidade: Um terceiro modelo de formulário normal tende a modelar as relações de dados existentes, o que pode produzir uma solução relativamente inflexível que necessita de um retrabalho significativo à medida que são adicionadas fontes adicionais. Pior ainda, os especialistas em modelagem de dados com excesso de zelo frequentemente tentam superar isso, fornecendo modelos genéricos muito complexos que são quase impossíveis de entender.
Abordagem de Projeto Dimensional
O diagrama abaixo ilustra uma arquitetura de dados potencial para um projeto clássico de Data Warehouse Dimensional.
A abordagem acima dispensa o EDW para entregar rapidamente resultados aos usuários finais. Utilizei esta técnica em 2008 num banco de investimento tier one sediado em Londres para fornecer avaliações de risco de crédito aos utilizadores empresariais dentro de semanas após o início do projecto. Se tivéssemos esperado para construir um armazém de dados tradicional, teríamos ido à falência antes de entregarmos qualquer coisa útil.
Inicialmente, os utilizadores empresariais ficaram entusiasmados com a velocidade de entrega; contudo, com o tempo, encontrámos muitos desafios que se tornaram cada vez mais dolorosos de lidar. Estes incluem:
1. Aumentando a complexidade do código: O código ETL (Extract, Transform, and Load) estava se tornando tão complicado que não podia mais ser gerenciado. Substituir a ferramenta ETL (Informatica) por scripts Oracle ajudou, (à medida que simplificávamos a solução), mas isso não era a raiz do problema. Estávamos a tentar reestruturar os dados recebidos, deduplicar, limpar e conformar os dados, e aplicar regras de negócio em mudança ao longo do tempo. Fazer todos esses passos em uma única base de código foi muito difícil.
2. Falta de dados brutos: Como a área de desembarque era puramente transitória (apagada e recarregada a cada vez), não tínhamos nenhum registro histórico de dados brutos. Isso tornou difícil para os analistas descobrir novas e valiosas relações de dados, e a crescente importância da Data Science, que (acima de tudo) precisa de dados brutos, foi simplesmente ignorada.
3. Gerenciando o Histórico: Como não tínhamos histórico de dados brutos e só carregávamos os atributos necessários para análise, tornou-se difícil retropopular dados adicionais.
4. A linhagem era um desafio: Como tanto a lógica técnica quanto a lógica de negócios eram implementadas em camadas sedimentares cada vez maiores de código fonte, era quase impossível rastrear a linhagem de um item de dados do relatório de volta ao sistema fonte.
O negócio adorava a velocidade inicial de entrega. Entretanto, com o passar do tempo, tornou-se cada vez mais difícil manter o ritmo à medida que a solução se tornava cada vez mais complexa, e as regras de negócio mudavam com o tempo.
Data Vault Architecture
O diagrama abaixo mostra uma arquitetura de dados potencial usada pela metodologia Data Vault.
Embora, à primeira vista, pareça muito semelhante à arquitetura do Data Warehouse corporativo acima, tem algumas diferenças e semelhanças significativas, que incluem:
- Carregamento de Dados: Como os dados são carregados da Área de Aterragem para o Cofre de Dados Brutos, o processo é puramente de reestruturação do formato (e não do conteúdo) dos dados. Os dados originais não são limpos nem modificados, e poderiam ser inteiramente reconstruídos sem problemas.
- Separação de Responsabilidade: O Cofre Bruto contém os dados brutos não modificados, e o único processamento é totalmente técnico, para reestruturar fisicamente os dados. As regras comerciais fornecem tabelas e linhas adicionais para estender o Cofre em bruto com um Cofre de Negócios. Isso significa que as regras de negócio são derivadas e armazenadas separadamente dos dados brutos. Esta separação de responsabilidade facilita a gestão das alterações de regras de negócio ao longo do tempo e reduz a complexidade geral do sistema.
- Regras de negócio: Os resultados das regras de negócio, incluindo a deduplicação, resultados conformes e até mesmo cálculos são armazenados centralmente no Business Vault. Isso ajuda a evitar cálculos duplicados e possíveis inconsistências quando os resultados são calculados para dois ou mais data marts.
- Data Marts: Ao contrário do método Kimball, no qual os resultados calculados são armazenados em tabelas de Fatos e Dimensões nas Data Marts, usando a abordagem Data Vault, as Data Marts são muitas vezes efêmeras e podem ser implementadas como vistas diretamente sobre o Business Vault e o Raw Vault. Isto significa que ambos são mais fáceis de modificar ao longo do tempo e evita o risco de resultados inconsistentes. Se as visualizações não fornecem o nível de desempenho necessário, então existe a opção de armazenar resultados em uma tabela.
Vantagens do Data Vault
O Data Vault aborda as dificuldades inerentes tanto ao 3o Formulário Normal do Data Warehouse Empresarial quanto à abordagem de Projeto Dimensional, combinando os melhores aspectos de ambos em uma única abordagem híbrida. As vantagens incluem:
1. Entrega incremental: Embora seja sensato construir qualquer Data Warehouse dentro do contexto de um modelo empresarial global, o Data Vault suporta entrega totalmente incremental. Assim como a abordagem Dimensional Design do Kimball, você pode começar pequenas e incrementalmente adicionar fontes adicionais ao longo do tempo.
2. Flexibilidade: Ao contrário da abordagem de modelação do 3º Formulário Normal, que pode ser inflexível, Data Vault não requer retrabalho ao adicionar fontes adicionais. Como o Data Vault armazena os dados derivados do Negócio e do Raw separadamente, ele suporta mudanças nas regras de negócio com facilidade.
3. Complexidade Reduzida: Como o Data Vault é construído em uma abordagem de dois passos, ele separa a reestruturação dos dados técnicos da aplicação de regras de negócios, o que ajuda a isolar esses estágios potencialmente complexos. Da mesma forma, a limpeza de dados é considerada uma regra de negócio e pode ser gerenciada independentemente do esforço inicial de carga de dados.
4. Dados Brutos Incluídos: Registrar os dados brutos no Data Vault significa que é possível fazer o back-população da área de apresentação com atributos históricos que não foram inicialmente disponibilizados. Se as Marcas de Dados forem implementadas como vistas, isto pode ser tão simples quanto adicionar uma coluna adicional a uma vista existente.
5. Elegantemente suporta mudanças ao longo do tempo: Semelhante à dimensão de mudança lenta na abordagem Kimball, Data Vault suporta elegantemente as mudanças ao longo do tempo. Ao contrário do Desenho Dimensional puro, no entanto, Data Vault separa os dados derivados do Raw and Business e suporta alterações resultantes tanto do sistema fonte como das regras de negócio.
6. Lineage and Audit: Como o Data Vault inclui metadados que identificam os sistemas-fonte, ele facilita o suporte a linhagem de dados. Ao contrário da abordagem Dimensional Design na qual os dados são limpos antes do carregamento, as alterações do Data Vault são sempre incrementais, e os resultados nunca são perdidos, o que fornece uma trilha de auditoria automática.
7. Cargas Paralelas de Alto Desempenho: Com a introdução das teclas de Hash no Data Vault 2.0, as dependências de carga de dados são eliminadas, o que significa que é possível carregar dados quase em tempo real, além de cargas paralelas de terabytes a petabytes de dados.
8. Possível de automatizar: Enquanto tanto a Modelagem de Relacionamento de Entidade quanto o Desenho Dimensional requerem tempo e experiência para construir habilidades, o Data Vault tende a ser mais fácil de automatizar, e há várias ferramentas (listadas abaixo) para ajudar a entregar a solução.
As desvantagens do Data Vault
O Data Vault não é a solução perfeita para todos os data warehouses, e ele tem algumas desvantagens que devem ser consideradas. Estes incluem:
1. A curva de aprendizagem: Da mesma forma que o 3º Formulário Normal, Modelagem de Relacionamento de Entidade e Desenho Dimensional são habilidades específicas que levam tempo para serem dominadas, existe uma curva de aprendizado com Data Vault. Embarcar em um projeto de transformação de Data Warehouse vem com riscos significativos, e adicionar Data Vault pode aumentar o risco, especialmente se isso a equipe não tiver experiência com Data Vault. Certifique-se de ter aconselhamento e suporte especializado, além de treinamento para indivíduos-chave.
2. Muitas Entradas: Um design mal concebido do Data Vault irá produzir um grande número de tabelas derivadas do sistema de origem, mas mesmo uma solução bem concebida multiplica a contagem das tabelas de origem por um factor de 2 ou 3. O número de tabelas e, portanto, de uniões pode parecer complicado e levar a condições de união complexas. Isso pode, no entanto, ser resolvido com o uso correto de tabelas bridge no Business Vault, e como em qualquer solução, é um trade-off de aparente complexidade e flexibilidade.
Onde usar o Data Vault?
Data Vault requer algum rigor no fornecimento de um bom design e aderência aos princípios do Data Vault 2.0. Como o Enterprise Data Warehouse, ele foi projetado para integrar dados de várias fontes de dados e pode, portanto, ser exagerado em algumas situações.
Em resumo, se você tiver um requisito analítico de pequeno a médio porte, com uma pequena (menos de 10) equipe de arquitetos, designers e engenheiros fornecendo uma solução com dados provenientes de alguns sistemas, então o Data Vault pode ser inadequado para as suas necessidades.
Se, no entanto, você tiver um grande projeto com 30 ou mais sistemas de origem levando a um enorme desafio de integração de dados e estiver preparado para assumir as habilidades e o rigor de uma nova metodologia, então o Data Vault pode potencialmente agregar um enorme valor ao projeto.
Outros Recursos e Ferramentas
Os seguintes recursos podem ajudar a avaliar e entender o método Data Vault:
- Kent Graziano (certificado Data Vault Master) tem um resumo do Data Vault que vale a pena ler.
- A Academia Genesee (Treinamento) fornece uma boa introdução aos princípios principais do Data Vault.
>
- Cofre de Dados de Consultoria do Reino Unido Forneça um resumo informativo das Perguntas Mais Frequentes que abordam muitas das preocupações imediatas.
- Dan Linstedt tem um grande número de artigos detalhados sobre os detalhes em torno do Cofre de Dados.
- Construir um Armazém de Dados Escalável com o Cofre de Dados 2.0 – é o livro de referência de Dan Linstedt.
- O Elefante no Frigorífico – é uma introdução acessível ao Cofre de Dados.
Embora estas não devam ser consideradas de forma alguma uma recomendação, aqui está uma lista restrita das ferramentas que podem ajudar a automatizar a entrega do Data Vault.
- dbtvault
- Wherescape
- VaultSpeed
- Data Vault Builder
- Joyn – A lightweight open source automation framework
Conclusion
As on-premise data warehouse projects are moved to the cloud, um número crescente de empresas está repensando a forma como o Data Warehouse é arquitetado. A mudança de vários silos de dados independentes no local para uma solução moderna baseada em nuvem é uma oportunidade única para integrar dados de toda a empresa em um único e consistente repositório.
Se esse é o desafio que você enfrenta, então o Data Vault pode muito bem ajudar a entregar a solução.
Se você achou este artigo útil, você pode estar interessado no meu blog pessoal (absolutamente zero publicidade), em www.Analytics.Today.
Declaração: As opiniões expressas nos meus artigos são minhas e não refletem necessariamente as do meu empregador (passado ou presente) ou de qualquer cliente com quem trabalhei.
Leave a Reply