Desenvolver uma instalação de armazenamento é uma tarefa longa e séria.
Muito na vida de um projeto depende de quão bem o modelo de objeto e a estrutura básica são pensados no início.
A abordagem geralmente aceita tem sido e continua sendo várias variantes de combinação do esquema estrela com a terceira forma normal. Via de regra, de acordo com o princípio: dados iniciais - 3NF, vitrines - estrela. Esta abordagem, testada ao longo do tempo e apoiada por uma grande quantidade de pesquisas, é a primeira (e às vezes a única) coisa que vem à mente de um especialista experiente em DWH quando pensa sobre como deveria ser um repositório analítico.
Por outro lado, os negócios em geral e os requisitos dos clientes em particular tendem a mudar rapidamente e os dados tendem a crescer tanto “em profundidade” como “em amplitude”. E é aqui que aparece a principal desvantagem de uma estrela - limitada flexibilidade.
E se em sua vida tranquila e aconchegante como desenvolvedor DWH de repente:
- surgiu a tarefa de “fazer pelo menos alguma coisa rápido, e depois veremos”;
- surgiu um projeto em rápido desenvolvimento, com conexão de novas fontes e reformulação do modelo de negócios pelo menos uma vez por semana;
- apareceu um cliente que não tem ideia de como o sistema deve ser e quais funções ele deve executar, mas está pronto para experimentar e refinar consistentemente o resultado desejado, ao mesmo tempo em que se aproxima consistentemente dele;
- O gerente de projeto apareceu com a boa notícia: “E agora temos agilidade!”
Ou se você está apenas interessado em descobrir de que outra forma você pode construir instalações de armazenamento - bem-vindo ao corte!
O que significa “flexibilidade”?
Primeiro, vamos definir quais propriedades um sistema deve ter para ser chamado de “flexível”.
Separadamente, vale a pena mencionar que as propriedades descritas devem referir-se especificamente a sistema, não para processo seu desenvolvimento. Portanto, se você quiser ler sobre Agile como metodologia de desenvolvimento, é melhor ler outros artigos. Por exemplo, ali mesmo, em Habré, há muitos materiais interessantes (como и E ).
Isso não significa que o processo de desenvolvimento e a estrutura do data warehouse sejam completamente independentes. No geral, deveria ser significativamente mais fácil desenvolver um repositório Agile para uma arquitetura ágil. Porém, na prática, mais frequentemente existem opções com desenvolvimento ágil do DWH clássico de acordo com Kimbal e DataVault - de acordo com Waterfall, do que felizes coincidências de flexibilidade em suas duas formas em um projeto.
Então, quais recursos o armazenamento flexível deve ter? Existem três pontos aqui:
- Entrega antecipada e retorno rápido - isto significa que idealmente o primeiro resultado comercial (por exemplo, os primeiros relatórios de trabalho) deve ser obtido o mais cedo possível, ou seja, antes mesmo de todo o sistema estar totalmente concebido e implementado. Além disso, cada revisão subsequente também deverá demorar o mínimo de tempo possível.
- Refinamento iterativo - isso significa que, idealmente, cada melhoria subsequente não deve afetar a funcionalidade que já está funcionando. É esse momento que muitas vezes se torna o maior pesadelo em grandes projetos - mais cedo ou mais tarde, objetos individuais começam a adquirir tantas conexões que fica mais fácil repetir completamente a lógica em uma cópia próxima do que adicionar um campo a uma tabela existente. E se você está surpreso com o fato de que a análise do impacto das melhorias nos objetos existentes pode levar mais tempo do que as próprias melhorias, provavelmente você ainda não trabalhou com grandes data warehouses em bancos ou telecomunicações.
- Adaptação constante às mudanças nos requisitos de negócios - a estrutura global do objecto deve ser concebida não apenas tendo em conta uma possível expansão, mas com a expectativa de que a direcção desta próxima expansão não possa sequer ser sonhada na fase de concepção.
E sim, é possível atender a todos esses requisitos em um sistema (é claro, em certos casos e com algumas ressalvas).
Abaixo considerarei duas das metodologias de design ágil mais populares para data warehouses - Modelo âncora и Cofre de dados. Ficam de fora dos colchetes técnicas excelentes como, por exemplo, EAV, 6NF (em sua forma pura) e tudo relacionado a soluções NoSQL - não porque sejam de alguma forma piores, e nem mesmo porque neste caso o artigo ameaçaria adquirir o volume do disser médio. Acontece que tudo isso se refere a soluções de uma classe um pouco diferente - seja a técnicas que você pode usar em casos específicos, independentemente da arquitetura geral do seu projeto (como EAV), ou a outros paradigmas globais de armazenamento de informações (como bancos de dados gráficos e outras opções NoSQL).
Problemas da abordagem “clássica” e suas soluções em metodologias flexíveis
Por abordagem “clássica” quero dizer a boa e velha estrela (independentemente da implementação específica das camadas subjacentes, que os seguidores de Kimball, Inmon e CDM me perdoem).
1. Cardinalidade rígida de conexões
Este modelo é baseado em uma clara divisão de dados em Dimensão и fatos. E isso, caramba, é lógico - afinal, a análise de dados na esmagadora maioria dos casos se resume à análise de certos indicadores numéricos (fatos) em certas seções (dimensões).
Nesse caso, as conexões entre objetos são estabelecidas na forma de relacionamentos entre tabelas por meio de uma chave estrangeira. Isto parece bastante natural, mas leva imediatamente à primeira limitação de flexibilidade - definição estrita da cardinalidade das conexões.
Isso significa que, no estágio de design da tabela, você deve determinar com precisão para cada par de objetos relacionados se eles podem se relacionar como muitos para muitos ou apenas 1 para muitos e “em que direção”. Isso determina diretamente qual tabela terá a chave primária e qual terá a chave estrangeira. Mudar esta atitude quando novos requisitos forem recebidos provavelmente levará a uma reformulação da base.
Por exemplo, ao projetar o objeto “recebimento de caixa”, você, contando com os juramentos do departamento de vendas, estabeleceu a possibilidade de ação uma promoção para várias posições de cheque (mas não vice-versa):
E depois de algum tempo, os colegas introduziram uma nova estratégia de marketing na qual podem atuar na mesma posição várias promoções ao mesmo tempo. E agora você precisa modificar as tabelas separando o relacionamento em um objeto separado.
(Todos os objetos derivados nos quais a verificação de promoção está unida agora também precisam ser melhorados).
Relacionamentos no Data Vault e Modelo Âncora
Evitar essa situação acabou sendo bastante simples: você não precisa confiar no departamento de vendas para fazer isso. todas as conexões são inicialmente armazenadas em tabelas separadas e processá-lo como muitos para muitos.
Esta abordagem foi proposta Dan Linstedt como parte do paradigma Cofre de dados e totalmente suportado Lars Rönnbäck в Modelo âncora.
Como resultado, obtemos a primeira característica distintiva das metodologias flexíveis:
Os relacionamentos entre objetos não são armazenados em atributos de entidades pai, mas são um tipo separado de objeto.
В Cofre de dados tais tabelas de ligação são chamadas Ligaçãoe em Modelo âncora - Laço. À primeira vista, são muito semelhantes, embora suas diferenças não se limitem ao nome (que será discutido a seguir). Em ambas as arquiteturas, as tabelas de links podem vincular qualquer número de entidades (não necessariamente 2).
Esta aparente redundância proporciona flexibilidade significativa para modificações. Tal estrutura torna-se tolerante não apenas a mudanças na cardinalidade dos links existentes, mas também à adição de novos - se agora uma posição de cheque também tiver um link para o caixa que o rompeu, o aparecimento de tal link simplesmente torne-se um complemento das tabelas existentes sem afetar quaisquer objetos e processos existentes.
2. Duplicação de dados
O segundo problema resolvido pelas arquiteturas flexíveis é menos óbvio e é inerente em primeiro lugar. Medições do tipo SCD2 (mudando lentamente as dimensões do segundo tipo), embora não apenas elas.
Em um warehouse clássico, uma dimensão normalmente é uma tabela que contém uma chave substituta (como uma PK) e um conjunto de chaves de negócios e atributos em colunas separadas.
Se uma dimensão suportar controle de versão, os limites de validade da versão serão adicionados ao conjunto padrão de campos e diversas versões aparecerão no repositório para uma linha na origem (uma para cada alteração nos atributos com controle de versão).
Se uma dimensão contiver pelo menos um atributo versionado que muda frequentemente, o número de versões de tal dimensão será impressionante (mesmo que os atributos restantes não sejam versionados ou nunca mudem), e se houver vários desses atributos, o número de versões pode crescer exponencialmente a partir de seu número. Essa dimensão pode ocupar uma quantidade significativa de espaço em disco, embora muitos dos dados que ela armazena sejam simplesmente duplicatas de valores de atributos imutáveis de outras linhas.
Ao mesmo tempo, também é frequentemente usado desnormalização — alguns atributos são armazenados intencionalmente como um valor e não como um link para um livro de referência ou outra dimensão. Essa abordagem acelera o acesso aos dados, reduzindo o número de junções ao acessar uma dimensão.
Normalmente isso leva a a mesma informação é armazenada simultaneamente em vários lugares. Por exemplo, informações sobre a região de residência e a categoria do cliente podem ser armazenadas simultaneamente nas dimensões “Cliente” e nos dados “Compra”, “Entrega” e “Chamadas para Call Center”, bem como na dimensão “Cliente - Gestor de Clientes”. ” tabela de links.
Em geral, o acima descrito se aplica a dimensões regulares (não versionadas), mas nas versionadas podem ter uma escala diferente: o aparecimento de uma nova versão de um objeto (especialmente em retrospecto) leva não apenas à atualização de todos relacionados tabelas, mas ao aparecimento em cascata de novas versões de objetos relacionados - quando a Tabela 1 é usada para construir a Tabela 2 e a Tabela 2 é usada para construir a Tabela 3, etc. Mesmo que nem um único atributo da Tabela 1 esteja envolvido na construção da Tabela 3 (e outros atributos da Tabela 2 obtidos de outras fontes estejam envolvidos), o versionamento desta construção levará, no mínimo, a sobrecarga adicional e, no máximo, a custos adicionais. versões na Tabela 3. que não tem nada a ver com isso, e mais abaixo na cadeia.
3. Complexidade não linear do retrabalho
Ao mesmo tempo, cada nova vitrine construída com base em outra aumenta o número de locais onde os dados podem “divergir” quando são feitas alterações no ETL. Isto, por sua vez, leva a um aumento na complexidade (e duração) de cada revisão subsequente.
Se o acima descreve sistemas com processos ETL raramente modificados, você pode viver nesse paradigma - você só precisa ter certeza de que novas modificações foram feitas corretamente em todos os objetos relacionados. Se as revisões ocorrerem com frequência, a probabilidade de “perder” acidentalmente várias conexões aumenta significativamente.
Se, além disso, levarmos em conta que o ETL “versionado” é significativamente mais complicado do que o “não versionado”, torna-se bastante difícil evitar erros ao atualizar frequentemente toda esta facilidade.
Armazenando objetos e atributos no Data Vault e no modelo âncora
A abordagem proposta pelos autores das arquiteturas flexíveis pode ser formulada da seguinte forma:
É preciso separar o que muda do que permanece igual. Ou seja, armazene as chaves separadamente dos atributos.
Contudo, não se deve confundir não versionado atributo com inalterado: o primeiro não armazena o histórico de suas alterações, mas pode mudar (por exemplo, ao corrigir um erro de entrada ou receber novos dados); o segundo nunca muda.
Os pontos de vista divergem sobre o que exatamente pode ser considerado imutável no Data Vault e no Anchor Model.
Do ponto de vista arquitetônico Cofre de dados, pode ser considerado inalterado conjunto completo de chaves - natural (TIN da organização, código do produto no sistema fonte, etc.) e substituto. Neste caso, os demais atributos podem ser divididos em grupos de acordo com a origem e/ou frequência das alterações e Mantenha uma tabela separada para cada grupo com um conjunto independente de versões.
No paradigma Modelo âncora considerado inalterado apenas chave substituta essência. Todo o resto (incluindo chaves naturais) é apenas um caso especial de seus atributos. Em que todos os atributos são independentes uns dos outros por padrão, então para cada atributo um mesa separada.
В Cofre de dados tabelas contendo chaves de entidade são chamadas Hubami. Os hubs sempre contêm um conjunto fixo de campos:
- Chaves de entidade natural
- Chave substituta
- Link para a fonte
- Registrar tempo de adição
Postagens em hubs nunca mudam e não têm versões. Externamente, os hubs são muito semelhantes às tabelas do tipo mapa de ID usadas em alguns sistemas para gerar substitutos; no entanto, é recomendado usar um hash de um conjunto de chaves de negócios como substitutos no Data Vault. Esta abordagem simplifica o carregamento de relacionamentos e atributos das fontes (não há necessidade de ingressar no hub para obter um substituto, basta calcular o hash de uma chave natural), mas pode causar outros problemas (relacionados, por exemplo, a colisões, casos e não imprimíveis). caracteres em chaves de string, etc. .p.), portanto, geralmente não é aceito.
Todos os outros atributos da entidade são armazenados em tabelas especiais chamadas Satélites. Um hub pode ter vários satélites armazenando diferentes conjuntos de atributos.
A distribuição de atributos entre os satélites ocorre de acordo com o princípio mudança conjunta — em um satélite podem ser armazenados atributos não versionados (por exemplo, data de nascimento e SNILS para um indivíduo), em outro - atributos versionados que raramente mudam (por exemplo, sobrenome e número do passaporte), no terceiro - aqueles que mudam frequentemente (por exemplo, endereço de entrega, categoria, data do último pedido, etc.). Neste caso, o versionamento é realizado ao nível dos satélites individuais, e não da entidade como um todo, pelo que é aconselhável distribuir atributos de forma que a intersecção das versões dentro de um satélite seja mínima (o que reduz o número total de versões armazenadas ).
Além disso, para otimizar o processo de carregamento de dados, atributos obtidos de diversas fontes são frequentemente incluídos em satélites individuais.
Os satélites se comunicam com o Hub via chave estrangeira (que corresponde à cardinalidade de 1 para muitos). Isso significa que vários valores de atributos (por exemplo, vários números de telefone de contato para um cliente) são suportados por esta arquitetura “padrão”.
В Modelo âncora tabelas que armazenam chaves são chamadas Âncoras. E eles mantêm:
- Apenas chaves substitutas
- Link para a fonte
- Registrar tempo de adição
As chaves naturais do ponto de vista do Modelo Âncora são consideradas atributos comuns. Esta opção pode parecer mais difícil de entender, mas dá muito mais espaço para identificar o objeto.
Por exemplo, se os dados sobre a mesma entidade puderem vir de sistemas diferentes, cada um dos quais utiliza a sua própria chave natural. No Data Vault, isso pode levar a estruturas bastante complicadas de vários hubs (um por fonte + uma versão mestre unificadora), enquanto no modelo Anchor, a chave natural de cada fonte cai em seu próprio atributo e pode ser usada ao carregar independentemente de Todos os outros.
Mas há também aqui um ponto insidioso: se atributos de diferentes sistemas forem combinados numa entidade, muito provavelmente haverá alguns regras de “colagem”, pelo qual o sistema deve entender que registros de diferentes fontes correspondem a uma instância da entidade.
В Cofre de dados essas regras provavelmente determinarão a formação “hub substituto” da entidade mestre e não influenciar de forma alguma os Hubs que armazenam chaves de origem natural e seus atributos originais. Se em algum momento as regras de mesclagem mudarem (ou os atributos pelos quais ela é executada forem atualizados), será suficiente reformatar os hubs substitutos.
В Modelo âncora tal entidade provavelmente será armazenada em a única âncora. Isto significa que todos os atributos, independentemente da fonte de origem, estarão vinculados ao mesmo substituto. Separar registros mesclados erroneamente e, em geral, monitorar a relevância da fusão em tal sistema pode ser muito mais difícil, especialmente se as regras forem bastante complexas e mudarem frequentemente, e o mesmo atributo puder ser obtido de fontes diferentes (embora seja certamente possível, já que cada versão do atributo mantém um link para sua fonte).
Em qualquer caso, se o seu sistema pretende implementar a funcionalidade desduplicação, mesclagem de registros e outros elementos MDM, vale a pena dar atenção especial aos aspectos de armazenamento de chaves naturais em metodologias ágeis. É provável que o design mais volumoso do Data Vault se torne subitamente mais seguro em termos de erros de mesclagem.
Modelo âncora também fornece um tipo de objeto adicional chamado Nó é essencialmente especial tipo degenerado de âncora, que pode conter apenas um atributo. Os nós devem ser usados para armazenar diretórios simples (por exemplo, sexo, estado civil, categoria de atendimento ao cliente, etc.). Ao contrário da âncora, o nó não tem tabelas de atributos associadas, e seu único atributo (nome) é sempre armazenado na mesma tabela que a chave. Os nós são conectados às âncoras por tabelas de vínculos (Tie) da mesma forma que as âncoras são conectadas entre si.
Não há uma opinião clara sobre o uso de Nodes. Por exemplo, , que promove ativamente o uso do Modelo Âncora na Rússia, acredita (não sem razão) que, para nenhum livro de referência, pode-se afirmar com certeza que ele sempre será estático e de nível único, portanto, é melhor usar imediatamente uma âncora completa para todos os objetos.
Outra diferença importante entre o Data Vault e o modelo Anchor é a disponibilidade atributos de conexões:
В Cofre de dados Links são os mesmos objetos completos que Hubs e podem ter atributos próprios. Em Modelo âncora Links são usados apenas para conectar âncoras e não pode ter seus próprios atributos. Essa diferença resulta em abordagens de modelagem significativamente diferentes de fatos, que será discutido mais adiante.
Armazenamento de fatos
Antes disso, falamos principalmente sobre modelagem de medição. Os fatos são um pouco menos claros.
В Cofre de dados um objeto típico para armazenar fatos é Link, em cujos satélites são acrescentados indicadores reais.
Esta abordagem parece intuitiva. Fornece fácil acesso aos indicadores analisados e geralmente é semelhante a uma tabela de fatos tradicional (apenas os indicadores são armazenados não na tabela em si, mas na tabela “vizinha”). Mas também existem armadilhas: uma das modificações típicas do modelo – a expansão da chave de factos – necessita adicionando uma nova chave estrangeira ao Link. E isso, por sua vez, “quebra” a modularidade e potencialmente causa a necessidade de modificações em outros objetos.
В Modelo âncora Uma conexão não pode ter atributos próprios, portanto esta abordagem não funcionará - absolutamente todos os atributos e indicadores devem estar vinculados a uma âncora específica. A conclusão disso é simples - Cada fato também precisa de sua própria âncora. Para algumas coisas que estamos acostumados a perceber como fatos, isso pode parecer natural - por exemplo, o fato de uma compra pode ser perfeitamente reduzido ao objeto “pedido” ou “recibo”, visita a um site para uma sessão, etc. Mas também há factos para os quais não é tão fácil encontrar um “objecto transportador” tão natural - por exemplo, restos de mercadorias em armazéns no início de cada dia.
Conseqüentemente, não surgem problemas de modularidade ao expandir uma chave de fato no modelo Âncora (basta simplesmente adicionar um novo Relacionamento à Âncora correspondente), mas projetar um modelo para exibir fatos é menos inequívoco; Âncoras “artificiais” podem aparecer que exibem o modelo de objeto de negócios de maneira pouco clara.
Como a flexibilidade é alcançada
A construção resultante em ambos os casos contém significativamente mais tabelasdo que a medição tradicional. Mas pode demorar significativamente menos espaço em disco com o mesmo conjunto de atributos versionados da dimensão tradicional. Naturalmente, não há mágica aqui – é tudo uma questão de normalização. Ao distribuir atributos entre satélites (no Data Vault) ou tabelas individuais (modelo âncora), reduzimos (ou eliminamos completamente) duplicação de valores de alguns atributos ao alterar outros.
Para Cofre de dados os ganhos dependerão da distribuição de atributos entre os Satélites, e para Modelo âncora — é quase diretamente proporcional ao número médio de versões por objeto de medição.
Entretanto, a economia de espaço é uma vantagem importante, mas não a principal, de armazenar atributos separadamente. Juntamente com o armazenamento separado de relacionamentos, esta abordagem torna a loja design modular. Isso significa que adicionar atributos individuais e novas áreas temáticas em tal modelo parece superestrutura sobre um conjunto existente de objetos sem alterá-los. E é exatamente isso que torna flexíveis as metodologias descritas.
Isso também lembra a transição da produção por peça para a produção em massa - se na abordagem tradicional cada tabela do modelo é única e requer atenção especial, então nas metodologias flexíveis já é um conjunto de “peças” padronizadas. Por um lado, existem mais tabelas e os processos de carregamento e recuperação de dados devem parecer mais complicados. Por outro lado, tornam-se típica. O que significa que pode haver automatizado e orientado por metadados. A questão “como vamos colocar isso?”, cuja resposta poderia ocupar uma parte significativa do trabalho de concepção de melhorias, agora simplesmente não vale a pena (assim como a questão sobre o impacto da mudança do modelo nos processos de trabalho ).
Isso não significa que os analistas não sejam necessários em tal sistema - alguém ainda precisa trabalhar no conjunto de objetos com atributos e descobrir onde e como carregar tudo isso. Mas a quantidade de trabalho, bem como a probabilidade e o custo de um erro, são significativamente reduzidos. Tanto na fase de análise como durante o desenvolvimento do ETL, que em grande parte pode ser reduzido à edição de metadados.
Lado negro
Todos os itens acima tornam ambas as abordagens verdadeiramente flexíveis, tecnologicamente avançadas e adequadas para melhorias iterativas. Claro, também existe um “barril de pomada”, que acho que você já pode adivinhar.
A decomposição dos dados, que fundamenta a modularidade das arquiteturas flexíveis, leva ao aumento do número de tabelas e, consequentemente, a sobrecarga para junções durante a amostragem. Para obter simplesmente todos os atributos de uma dimensão, numa loja clássica uma seleção é suficiente, mas uma arquitetura flexível exigirá toda uma série de junções. Além disso, se todas essas junções para relatórios puderem ser escritas com antecedência, os analistas que estão acostumados a escrever SQL manualmente sofrerão duplamente.
Existem vários fatos que facilitam essa situação:
Ao trabalhar com grandes dimensões, quase nunca todos os seus atributos são utilizados simultaneamente. Isso significa que pode haver menos junções do que parece à primeira vista no modelo. O Data Vault também pode levar em consideração a frequência esperada de compartilhamento ao alocar atributos aos satélites. Ao mesmo tempo, os próprios hubs ou âncoras são necessários principalmente para gerar e mapear substitutos no estágio de carregamento e raramente são usados em consultas (isso é especialmente verdadeiro para âncoras).
Todas as junções são por chave. Além disso, uma forma mais “compactada” de armazenar dados reduz a sobrecarga de varredura de tabelas onde for necessário (por exemplo, ao filtrar por valor de atributo). Isso pode levar ao fato de que a amostragem de um banco de dados normalizado com várias junções será ainda mais rápida do que a varredura de uma dimensão pesada com muitas versões por linha.
Por exemplo, aqui em O artigo contém um teste comparativo detalhado do desempenho do modelo Anchor com uma amostra de uma tabela.
Depende muito do motor. Muitas plataformas modernas possuem mecanismos internos de otimização de junção. Por exemplo, MS SQL e Oracle podem “pular” junções em tabelas se seus dados não forem usados em nenhum lugar, exceto em outras junções e não afetarem a seleção final (eliminação de tabela/junção) e MPP Vertica , provou ser um excelente mecanismo para o modelo âncora, dada alguma otimização manual do plano de consulta. Por outro lado, armazenar o Anchor Model, por exemplo, no Click House, que tem suporte limitado para join, ainda não parece uma boa ideia.
Além disso, para ambas as arquiteturas existem movimentos especiais, facilitando o acesso aos dados (tanto do ponto de vista do desempenho da consulta quanto para os usuários finais). Por exemplo, Tabelas pontuais no Data Vault ou funções especiais de mesa no modelo Âncora.
No total
A principal essência das arquiteturas flexíveis consideradas é a modularidade do seu “design”.
É esta propriedade que permite:
- Após alguma preparação inicial relacionada à implantação de metadados e à escrita de algoritmos ETL básicos, fornecer rapidamente ao cliente o primeiro resultado na forma de alguns relatórios contendo dados de apenas alguns objetos de origem. Não é necessário pensar completamente (mesmo no nível superior) em todo o modelo de objeto.
- Um modelo de dados pode começar a funcionar (e ser útil) com apenas 2 a 3 objetos e, em seguida, crescer gradualmente (em relação ao modelo Anchor Nikolai boa comparação com micélio).
- A maioria das melhorias, incluindo a expansão da área temática e a adição de novas fontes não afeta a funcionalidade existente e não representa risco de quebrar algo que já está funcionando.
- Graças à decomposição em elementos padrão, os processos ETL em tais sistemas parecem iguais, sua escrita se presta à algoritmização e, em última análise, automação.
O preço desta flexibilidade é производительность. Isto não significa que seja impossível alcançar um desempenho aceitável em tais modelos. Na maioria das vezes, você pode simplesmente precisar de mais esforço e atenção aos detalhes para atingir as métricas desejadas.
Aplicativos
Tipos de entidade Cofre de dados
Mais informações sobre o Cofre de Dados:
Tipos de entidade Modelo âncora
Mais detalhes sobre o modelo âncora:
Tabela resumo com características comuns e diferenças das abordagens consideradas:
Fonte: habr.com