Sistemas de Data Warehouse (EDW) empresarial têm como objectivo fornecer um verdadeiro Business Intelligence (BI) para a empresa orientada por dados. As empresas devem abordar as métricas críticas enraizadas nestes dados vitais e vibrantes. Fornecer um processo essencial de integração de dados que eventualmente suporte uma variedade de requisitos de relatórios é um objetivo chave para estes sistemas de Enterprise Data Warehouse. Construí-los envolve um projeto significativo, desenvolvimento, administração e esforço operacional. Quando os sistemas empresariais, estruturas ou regras a montante mudam, não fornecem dados consistentes, ou requerem novas soluções de integração de sistemas, os requisitos mínimos de reengenharia nos apresentam o problema #1: A única constante é a mudança; então quão bem pode uma solução EDW/BI se adaptar?
“Não é a mais forte das espécies que sobrevive, nem a mais inteligente que sobrevive. É a que é a mais adaptável à mudança”. Charles Darwin
Consumo e análise de dados comerciais por diversas comunidades de usuários se tornou uma realidade crítica para manter uma vantagem competitiva, mas as realidades tecnológicas de hoje muitas vezes exigem usuários finais altamente treinados. Capturar, processar, transformar, limpar e reportar esses dados pode ser compreensível, mas na maioria dos casos o volume de dados pode ser esmagador; Sim, problema # 2: Dados Realmente Grandes; muitas vezes caracterizados como: Volume, Velocidade, Variedade, Variabilidade, Veracidade, Visualização, & Valor!
A elaboração de sistemas EDW/BI eficazes e eficientes, simplificados para a usabilidade e relatórios sobre esses dados, rapidamente se torna uma prova técnica assustadora e muitas vezes difícil, mesmo para equipes de engenharia veteranas. Várias tecnologias integradas são necessárias desde sistemas de banco de dados, ferramentas de processamento de dados (ETL) como Talend, várias linguagens de programação, administração, relatórios e software gráfico interativo até redes de alto desempenho e computadores poderosos com capacidade de armazenamento muito grande. A concepção, criação, entrega e suporte de sistemas EDW/BI robustos e sem esforço para uso simplificado e inteligente são, você adivinhou; problema #3: Complexidade!
A maioria das vezes vemos soluções abrangentes e elegantes entregues ao usuário empresarial que não consegue entender as verdadeiras necessidades do negócio. Dizem-nos que é assim que é devido a requisitos técnicos (limitações; piscar, piscar) e/ou parâmetros de design (falta de funcionalidades; empurrar, empurrar). Daí; problema #4: O Domínio do Negócio; encaixar os dados para satisfazer as necessidades do negócio, não o contrário!
Outras vezes, como os sistemas a montante mudam (e mudarão), como a tecnologia EDW/BI arado à frente (e devem), como as complexidades dinâmicas envolvidas prevalecem (implacavelmente), de vez em quando novas fontes de dados precisam de ser adicionadas à mistura. Estas são geralmente imprevistas e imprevistas. O impacto da integração pode ser enorme, muitas vezes exigindo uma regeneração completa dos dados agregados; daí o problema #5: Flexibilidade; ou a falta de!
Então, como resolvemos estes problemas? Bem …
Bill Inmon amplamente considerado como o pai do armazenamento de dados, define um armazenamento de dados como:
“Uma coleta de dados orientada ao assunto, não volátil e variável no tempo em apoio às decisões da gerência”
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), um arquiteto pioneiro de data warehousing, desenvolveu a metodologia de “modelagem dimensional” agora considerada como o padrão de fato na área de apoio à decisão. O Modelo Dimensional (chamado de “esquema em estrela”) é diferente da metodologia de “modelagem normalizada” de Inman (às vezes chamada de “esquema em floco de neve”). No Esquema Estelar de Kimball, os dados transacionais são divididos em “fatos” agregados com “dimensões” referenciais ao redor e fornecendo descritores que definem os fatos. O Modelo Normalizado (3NF ou “terceira forma normal”) armazena dados em “tabelas” relacionadas, seguindo as regras de desenho de bases de dados relacionais estabelecidas por E. F. Codd e Raymond F. Boyce no início dos anos 70, que eliminam a redundância de dados. Fomentando um debate vigoroso entre EDW/BI Architects sobre qual a melhor metodologia, ambos têm fraquezas quando lidam com mudanças inevitáveis nos sistemas que alimentam o armazém de dados e na limpeza dos dados para cumprir com os requisitos metodológicos rigorosos.
Outros, o cubo OLAP (para “processamento analítico online”) é uma estrutura de dados que permite uma análise rápida dos dados a partir de múltiplas perspectivas. A estrutura do cubo é criada a partir de um esquema Star ou Snowflake Schema armazenado como metadados a partir do qual se pode visualizar ou “pivotar” os dados de várias maneiras. Geralmente os cubos têm uma dimensão baseada no tempo que suporta uma representação histórica dos dados. A criação de cubos OLAP pode ser muito cara e muitas vezes criar uma quantidade significativa de dados que são de pouca ou nenhuma utilidade. A regra 80/20 aparece em muitos casos para ser verdadeira (onde apenas 20% dos dados dos cubos OLAP se revelam úteis) o que levanta a questão: Construído sobre uma arquitectura tradicional, será que um cubo OLAP proporciona realmente um ROI suficiente? Muitas vezes, a resposta é um retumbante, NÃO! Sistemas EDW/BI duráveis devem fornecer um valor real.
Saiba como o Talend ajudou o Tipico a transformar oceanos de dados em inteligência de negócios de ponta.
Uma nova abordagem
O Data Vault é uma metodologia híbrida de modelagem de dados que fornece representação de dados históricos de múltiplas fontes projetadas para serem resistentes a mudanças ambientais. Originalmente concebido em 1990 e lançado em 2000 como uma metodologia de modelagem de domínio público, Dan Linstedt, seu criador, descreve um banco de dados Data Vault resultante como:
“Um conjunto de tabelas normalizadas, orientadas ao detalhe, históricas e vinculadas de forma única que suportam uma ou mais áreas funcionais do negócio. É uma abordagem híbrida que engloba o melhor da raça entre 3NF e Star Schemas. O design é flexível, escalável, consistente e adaptável às necessidades da empresa”
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Focalizado no processo de negócio, o Data Vault como uma arquitetura de integração de dados, tem padrões robustos e métodos definitivos que unem a informação para fazer sentido se ela fizer sentido. O modelo Data Vault é composto por três tipos de tabelas básicas:
HUB (azul): contendo uma lista de chaves de negócio únicas com sua própria chave substituta. Metadados descrevendo a origem da chave de negócio, ou registro ‘fonte’ também é armazenado para rastrear onde e quando os dados foram originados.
LNK (vermelho): estabelecendo relações entre chaves de negócio (tipicamente hubs, mas links podem se ligar a outros links); essencialmente descrevendo uma relação entre muitos e muitos. Os links são frequentemente usados para lidar com mudanças na granularidade dos dados, reduzindo o impacto da adição de uma nova chave de negócios a um Hub ligado.
SAT (amarelo): mantendo atributos descritivos que podem mudar com o tempo (semelhante a uma dimensão de mudança lenta de Kimball Tipo II). Onde Hubs e Links formam a estrutura do modelo de dados, os satélites contêm atributos temporais e descritivos incluindo metadados que os ligam às suas tabelas de Hub ou Link pai. Os atributos de metadados dentro de uma tabela de Satélites contendo uma data em que o registo se tornou válido e uma data em que expirou fornecem capacidades históricas poderosas que permitem consultas que podem ser ‘back-in-time’.
Existem várias vantagens chave para a abordagem do Data Vault:
– Simplifica o processo de ingestão de dados
– Remove o requisito de limpeza de um Esquema Estelar
– Proporciona instantaneamente a auditabilidade para HIPPA e outros regulamentos
– Coloca o foco no problema real em vez de programá-lo em torno dele
– Facilmente permite a adição de novas fontes de dados sem interrupção do esquema existente
> Colocado de forma simples, O Data Vault é uma técnica e metodologia de modelagem de dados que acomoda dados históricos, auditoria e rastreamento de dados.
“O Data Vault é a escolha ideal para modelar o EDW no framework DW 2.0”
Bill Inmon
Adaptável
Por meio da separação das chaves de negócio (pois elas são geralmente estáticas) e as associações entre elas a partir de seus atributos descritivos, um Data Vault enfrenta o problema da mudança no ambiente. Usando estas chaves como a espinha dorsal estrutural de um Data Warehouse, todos os dados relacionados podem ser organizados à sua volta. Estes Hubs (chaves de negócio), Links (associações) e SAT (atributos descritivos) suportam uma estrutura de dados altamente adaptável, mantendo um alto grau de integridade dos dados. Dan Linstedt frequentemente correlaciona o Data Vault a uma visão simplista do cérebro onde neurônios são associados a Hubs e Satélites e onde dendritos são Links (vetores de informação). Alguns Links são como sinapses (vectores na direcção oposta). Eles podem ser criados ou lançados na mosca à medida que as relações comerciais mudam automaticamente de modelo de dados, conforme necessário, sem impacto nas estruturas de dados existentes. Problema #1 Resolvido!
Big Data
Data Vault v2.0 chegou ao local em 2013 e incorpora a integração perfeita das tecnologias Big Data juntamente com a metodologia, arquitetura e implementações das melhores práticas. Através desta adoção, grandes quantidades de dados podem ser facilmente incorporadas em um Data Vault projetado para armazenar usando produtos como Hadoop, Infobright, MongoDB e muitas outras opções NoSQL. Eliminando os requisitos de limpeza de um projeto Star Schema, o Data Vault se sobressai quando se trata de grandes conjuntos de dados, diminuindo os tempos de ingestão e permitindo inserções paralelas que aproveitam o poder dos sistemas Big Data. Problema #2 Resolvido!
Simplificação
A criação de um modelo de Data Vault eficaz e eficiente pode ser feita rapidamente uma vez que você entenda o básico dos 3 tipos de tabelas: Hub, Satellite, e Link! Identificar as chaves de negócio em primeiro lugar e definir os Hubs é sempre o melhor lugar para começar. A partir daí os Hub-Satellites representam colunas da tabela de origem que podem mudar, e finalmente os Links amarram tudo junto. Lembre-se que também é possível ter tabelas de Link-Satélites. Uma vez que você tenha estes conceitos, é fácil. Depois de completar seu modelo Data Vault, a próxima coisa comum a fazer é construir o processo de integração de dados ETL para preenchê-lo. Enquanto um modelo Data Vault não está limitado a soluções EDW/BI, a qualquer momento você precisa obter dados de alguma fonte de dados e para algum alvo, um processo de integração de dados é geralmente necessário. A missão do Talend é conectar a empresa orientada a dados.
Com seu conjunto de software de integração, o Talend simplifica o processo de desenvolvimento, reduz a curva de aprendizado e diminui o custo total de propriedade com uma plataforma ETL unificada, aberta e previsível. Uma tecnologia ETL comprovada, o Talend pode certamente ser usado para povoar e manter um sistema EDW/BI robusto construído sobre um modelo de dados Data Vault. Problema #3 Resolvido!
Seu Negócio
O Data Vault define essencialmente a Ontologia de uma Empresa na medida em que descreve o domínio do negócio e as relações dentro dele. O processamento de regras de negócios deve ocorrer antes de povoar um Esquema Estelar. Com um Data Vault você pode empurrá-las para jusante, após a ingestão de EDW. Uma filosofia adicional do Data Vault é que todos os dados são relevantes, mesmo que estejam errados. Dan Linstedt sugere que estar errado é um problema de negócios, não um problema técnico. Eu concordo! Um EDW não é realmente o lugar certo para corrigir (limpar) dados ruins. A simples premissa do Data Vault é ingerir 100% dos dados da fonte 100% do tempo; bons, maus ou feios. Relevante no mundo de hoje, auditabilidade e rastreabilidade de todos os dados no Data Warehouse torna-se assim um requisito padrão. Este modelo de dados é arquitetado especificamente para atender às necessidades dos sistemas EDW/BI de hoje. Problema #4 Resolvido!
“Entender o Data Vault é entender o negócio”
(http://danlinstedt.com)
Flexível
A metodologia Data Vault é baseada nas melhores práticas SEI/CMMI Nível 5 e inclui muitos dos seus componentes combinando-os com as melhores práticas do Six Sigma, TQM, e SDLC (Agile). Os projetos Data Vault têm ciclos curtos de liberação controlada e podem consistir em uma liberação de produção a cada 2 ou 3 semanas adotando automaticamente os projetos repetíveis, consistentes e mensuráveis esperados no CMMI Nível 5. Quando novas fontes de dados precisam ser adicionadas, chaves de negócios similares são prováveis, novos Hubs-Satellites-Links podem ser adicionados e depois vinculados a estruturas Data Vault existentes sem qualquer alteração no modelo de dados existente. Problema #5 Resolvido!
Conclusão
Em conclusão, a modelagem e metodologia do Data Vault aborda os elementos dos problemas que identificamos acima:
– Adapta-se a um ambiente de negócios em mudança
– Suporta conjuntos de dados muito grandes
– Simplifica as complexidades de design EDW/BI
– Aumenta a usabilidade dos usuários de negócios porque é modelado após o domínio do negócio
– Permite adicionar novas fontes de dados sem impactar o design existente
Este avanço tecnológico já está provando ser altamente eficaz e eficiente. Fácil de projetar, construir, preencher e mudar, o Data Vault é um vencedor claro. Muito legal! Você quer um?
Visit http://learndatavault.com ou http://www.keyldv.com/lms para muito mais sobre modelagem e metodologia do Data Vault.
Embora você esteja nele, baixe um teste gratuito da Talend Cloud Integration Platform para o que seus dados realmente podem fazer.