Olá Habr! Muito foi escrito sobre o tema da arquitetura de armazém de dados, mas ainda não foi encontrado de maneira tão sucinta e sucinta quanto em um artigo em que acidentalmente me deparei.
Convido você a se familiarizar com este artigo na minha tradução. Comentários e adições são bem-vindos!
(Fonte da imagem)1. Introdução
Portanto, a arquitetura dos data warehouses está mudando. Neste artigo, compararemos os tradicionais data warehouses corporativos e soluções em nuvem com menor custo inicial, maior escalabilidade e desempenho.
Um data warehouse é um sistema no qual os dados são coletados de várias fontes dentro de uma empresa e esses dados são usados para apoiar decisões de gerenciamento.
As empresas estão cada vez mais migrando para data warehouses baseados em nuvem, em vez de sistemas locais tradicionais. Os armazenamentos de dados em nuvem têm várias diferenças em relação aos armazenamentos tradicionais:
- Não há necessidade de comprar equipamentos físicos;
- Os data warehouses da nuvem são mais rápidos e baratos para configurar e escalar;
- Os data warehouses em nuvem geralmente podem executar consultas analíticas complexas muito mais rapidamente porque eles usam processamento paralelo maciço.
Arquitetura tradicional de data warehouse
Os seguintes conceitos destacam algumas das idéias e princípios de design estabelecidos usados para criar data warehouses tradicionais.
Arquitetura de três níveis
Com bastante frequência, a arquitetura tradicional do data warehouse possui uma estrutura de três camadas, composta pelos seguintes níveis:
- Nível inferior : esse nível contém o servidor de banco de dados usado para recuperar dados de muitas fontes diferentes, por exemplo, de bancos de dados transacionais usados para aplicativos front-end.
- Camada intermediária: a camada intermediária contém um servidor OLAP que transforma os dados em uma estrutura mais adequada para análises e consultas complexas. Um servidor OLAP pode funcionar de duas maneiras: como um sistema avançado de gerenciamento de banco de dados relacional que mapeia operações de dados multidimensionais para operações OLAP relacionais padrão ou usando um modelo OLAP multidimensional que implementa diretamente dados e operações multidimensionais.
- Nível superior : o nível superior é o nível do cliente. Este nível contém as ferramentas usadas para análise, relatório e análise de dados de alto nível.
Kimball vs. Inmon
Dois pioneiros em data warehouses: Bill Inmon e Ralph Kimball, oferecem diferentes abordagens de design.
A abordagem de
Ralph Kimball é baseada na importância dos data marts, que são data warehouses pertencentes a empresas específicas. Um data warehouse é simplesmente uma
combinação de vários data marts que facilitam relatórios e análises. O projeto de data warehouse baseado em Kimball usa uma abordagem de baixo para cima.
A abordagem de Bill Inmon é baseada no fato de que o data warehouse é um armazenamento centralizado de todos os dados corporativos. Com essa abordagem, a organização primeiro cria um
modelo normalizado de data warehouse. Em seguida, os data marts dimensionais são criados com base no modelo de armazém. Isso é conhecido como uma abordagem descendente de data warehouse.
Modelos de Data Warehouse
Na arquitetura tradicional, existem três modelos gerais de data warehouses: armazenamento virtual, data showcase e data warehouse corporativo:
- Um data warehouse virtual é um conjunto de bancos de dados separados que podem ser compartilhados para que o usuário possa acessar efetivamente todos os dados como se estivessem armazenados em um data warehouse;
- Um modelo de demonstração de dados é usado para relatar e analisar linhas de negócios específicas. Nesse modelo de armazenamento, dados agregados de vários sistemas de origem relacionados a uma área de negócios específica, como vendas ou finanças;
- O modelo corporativo de armazém de dados envolve o armazenamento de dados agregados que abrangem toda a organização. Esse modelo considera o data warehouse como o coração de um sistema de informações corporativas com dados integrados de todas as unidades de negócios.
Star vs. Floco de neve
Os esquemas em estrela e floco de neve são duas maneiras de estruturar seu armazém de dados.
Um esquema em
estrela possui um armazém de dados centralizado, que é armazenado em uma tabela de fatos. O gráfico divide a tabela de fatos em uma série de tabelas de dimensões desnormalizadas. A tabela de fatos contém os dados agregados que serão usados para gerar relatórios e a tabela de dimensões descreve os dados armazenados.
Projetos desnormalizados são menos complexos porque os dados são agrupados. A tabela de fatos usa apenas um link para anexar a cada tabela de dimensão. O design mais simples em forma de estrela simplifica bastante a gravação de consultas complexas.
Um padrão de
floco de neve é diferente, pois usa dados normalizados. Normalização significa organização eficiente dos dados, para que todas as dependências dos dados sejam definidas e cada tabela contenha um mínimo de redundância. Assim, tabelas de medição individuais são divididas em tabelas de medição separadas.
O esquema de
floco de neve usa menos espaço em disco e mantém melhor a integridade dos dados. A principal desvantagem é a complexidade das consultas necessárias para acessar os dados - cada consulta deve passar por várias junções de tabela para obter os dados correspondentes.
ETL vs. ELT
ETL e ELT são duas maneiras diferentes de carregar dados no armazenamento.
Os ETLs (Extrair, Transformar, Carregar) primeiro recuperam dados de um pool de fontes de dados. Os dados são armazenados em um banco de dados temporário. Em seguida, operações de conversão são executadas para estruturar e transformar os dados em um formato adequado para o sistema de armazém de dados de destino. Em seguida, os dados estruturados são carregados no armazenamento e prontos para análise.
No caso do
ELT (Extrair, Carregar, Transformar), os dados são carregados imediatamente após a extração dos conjuntos de dados de origem. Não há banco de dados intermediário, o que significa que os dados são enviados imediatamente para um único repositório centralizado.
Os dados são convertidos em um sistema de armazém de dados para uso com ferramentas de inteligência de negócios e análises.
Maturidade organizacional
A estrutura de data warehouse da organização também depende de sua situação e necessidades atuais.
A estrutura básica permite que os usuários finais de armazenamento acessem diretamente os dados resumidos dos sistemas de origem, criem relatórios e analisem esses dados. Essa estrutura é útil para casos em que as fontes de dados vêm dos mesmos tipos de sistemas de banco de dados.
O armazenamento com uma área intermediária é o próximo passo lógico em uma organização com fontes de dados heterogêneas com muitos tipos e formatos diferentes de dados. A área de preparação converte os dados em um formato estruturado genérico que é mais fácil de solicitar usando ferramentas de análise e relatório.
Uma variação da estrutura intermediária é a adição de data marts ao data warehouse. Os data marts armazenam dados resumidos em um campo de atividade específico, o que torna esses dados facilmente acessíveis para formas específicas de análise.
Por exemplo, a adição de data marts pode permitir que um analista financeiro realize mais facilmente consultas detalhadas sobre dados de vendas e preveja o comportamento do cliente. Os data marts facilitam a análise, adaptando dados especificamente para atender às necessidades do usuário final.
Novas arquiteturas de data warehouse
Nos últimos anos, os data warehouses estão migrando para a nuvem. Os novos data warehouses da nuvem não aderem à arquitetura tradicional e cada um deles oferece sua própria arquitetura exclusiva.
Esta seção descreve brevemente as arquiteturas usadas pelos dois armazenamentos em nuvem mais populares: Amazon Redshift e Google BigQuery.
Redshift da Amazon
O Amazon Redshift é uma visão baseada em nuvem de um data warehouse tradicional.
O desvio para o vermelho exige que os recursos de computação sejam preparados e configurados como clusters que contêm uma coleção de um ou mais nós. Cada nó possui seu próprio processador, memória e RAM. O Nó Líder compila os pedidos e os passa para os nós de computação que os executam.
Em cada nó, os dados são armazenados em blocos chamados
fatias . O desvio para o vermelho usa armazenamento de coluna, ou seja, cada bloco de dados contém valores de uma coluna em várias linhas, e não de uma linha com valores de várias colunas.
O Redshift usa a arquitetura MPP (Massively Parallel Processing), dividindo grandes conjuntos de dados em partes que são atribuídas a fatias em cada nó. As solicitações são mais rápidas porque os nós de processamento processam solicitações em cada fatia ao mesmo tempo. O nó Nó Líder combina os resultados e os retorna para o aplicativo cliente.
Aplicativos clientes como BI e ferramentas analíticas podem se conectar diretamente ao Redshift usando os drivers JDBC e ODBC PostgreSQL de código aberto. Dessa maneira, os analistas podem executar suas tarefas diretamente nos dados do Redshift.
O desvio para o vermelho só pode carregar dados estruturados. Você pode carregar dados no Redshift usando sistemas pré-integrados, incluindo Amazon S3 e DynamoDB, transferindo dados de qualquer host local com uma conexão SSH ou integrando outras fontes de dados usando a API Redshift.
Bigquery do Google
A arquitetura do BigQuery não requer um servidor, o que significa que o Google controla dinamicamente a alocação de recursos do computador. Portanto, todas as decisões de gerenciamento de recursos estão ocultas do usuário.
O BigQuery permite que os clientes baixem dados do Google Cloud Storage e outras fontes de dados legíveis. Uma alternativa é a transmissão de dados, que permite que os desenvolvedores adicionem dados ao data warehouse em tempo real, linha por linha, quando estiverem disponíveis.
O BigQuery usa um mecanismo de consulta chamado Dremel, que pode verificar bilhões de linhas de dados em apenas alguns segundos. A Dremel usa consultas massivamente paralelas para digitalizar dados no sistema de gerenciamento de arquivos base Colossus. O Colossus distribui arquivos em pedaços de 64 megabytes entre uma variedade de recursos de computação chamados nós, agrupados em clusters.
Dremel usa uma estrutura de dados da coluna semelhante ao Redshift. A arquitetura em árvore envia solicitações para milhares de máquinas em segundos.
Comandos SQL simples são usados para executar consultas de dados.
Panoply
A Panoply fornece gerenciamento abrangente de dados como um serviço. Sua arquitetura auto-otimizadora exclusiva usa aprendizado de máquina e processamento de linguagem natural (PNL) para modelar e otimizar a transferência de dados da origem para a análise, reduzindo o tempo entre os dados e os valores o mais próximo possível de zero.
A Panoply Intelligent Data Infrastructure inclui os seguintes recursos:
- Consulta e análise de dados - determinando a melhor configuração para cada caso de uso, ajustando-a ao longo do tempo e criando índices, chaves de classificação, chaves de disco, tipos de dados, evacuação e particionamento.
- Identifica consultas que não seguem as práticas recomendadas (por exemplo, aquelas que incluem loops aninhados ou conversões implícitas) e as reescreve em uma consulta equivalente que requer uma fração do tempo ou recursos de execução.
- Otimize a configuração do servidor ao longo do tempo com base nos padrões de consulta e aprendendo qual configuração do servidor funciona melhor. A plataforma alterna perfeitamente os tipos de servidor e mede o desempenho geral.
Além do armazenamento em nuvem
O data warehousing baseado em nuvem é uma grande melhoria em relação às abordagens da arquitetura tradicional. No entanto, os usuários ainda encontram vários problemas ao configurá-los:
- O carregamento de dados em data warehouses baseados na nuvem não é trivial e os pipelines de dados em grande escala requerem configuração, teste e suporte para o processo ETL. Essa parte do processo geralmente é executada por ferramentas de terceiros;
- Atualizações, inserções e exclusões podem ser complexas e devem ser feitas com cuidado para evitar a degradação do desempenho da consulta;
- É difícil lidar com dados semiestruturados - eles precisam ser normalizados em um formato de banco de dados relacional, o que requer automação de grandes fluxos de dados;
- Estruturas aninhadas geralmente não são suportadas em data warehouses da nuvem. Você precisa converter as tabelas aninhadas em formatos que o armazém de dados entenda;
- Otimização de cluster . Existem várias opções para configurar um cluster Redshift para executar suas cargas de trabalho. Diferentes cargas de trabalho, conjuntos de dados ou mesmo tipos diferentes de consultas podem exigir configurações diferentes. Para alcançar o desempenho ideal, é necessário revisar constantemente e, se necessário, configurar adicionalmente a configuração;
- Otimização de consulta - as consultas do usuário podem não seguir as práticas recomendadas e, portanto, levarão muito mais tempo para serem concluídas. Você pode trabalhar com usuários ou aplicativos clientes automatizados para otimizar consultas para que o data warehouse possa funcionar conforme o esperado
- Backup e recuperação - embora os provedores de armazenamento de dados ofereçam muitas opções para fazer backup de seus dados, eles não são triviais para configurar e requerem monitoramento e atenção.
Link para o texto original: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud