Tipos de Data Warehouse: Um Guia Completo de Arquiteturas e Casos de Uso

Um data warehouse é um repositório centralizado que coleta, organiza e armazena dados estruturados de toda a organização para que analistas e cientistas de dados possam executar consultas complexas, gerar relatórios e dar suporte a cargas de trabalho de business intelligence (BI). Ao contrário dos bancos de dados operacionais projetados para processamento de transações, um data warehouse é construído para cargas de trabalho analíticas — unindo dados de várias fontes, preservando dados históricos ao longo dos anos e fornecendo a base governada que a tomada de decisões estratégicas exige.

Compreender os diferentes tipos de data warehouse é essencial antes de se comprometer com qualquer plataforma ou migração. Cada tipo reflete um trade-off arquitetônico distinto entre escala, latência, custo e escopo do assunto. Este guia aborda todos os principais tipos de data warehouse — desde os tradicionais Enterprise Data Warehouses até as modernas arquiteturas de lakehouse — e fornece orientações claras sobre quando cada um é a escolha certa.

Os três principais tipos de data warehouses

O setor reconhece três tipos principais de data warehouse que formam a base da arquitetura de dados moderna: o Enterprise Data Warehouse (EDW), o Data Mart e o Operational Data Store (ODS). Além desses, as organizações também implantam data warehouses baseados em nuvem, data warehouses virtuais, data warehouses híbridos e plataformas de lakehouse, dependendo dos requisitos de carga de trabalho, volume de dados e complexidade de governança.

Cada tipo difere em como armazena os dados, quem é o proprietário, qual latência suporta e quais consultas analíticas ele processa bem. A escolha certa depende de suas fontes de dados, estrutura de equipe, requisitos de qualidade de dados e dos casos de uso de análise que você precisa dar suporte.

Enterprise Data Warehouse (EDW)

Um enterprise data warehouse (EDW) é o tipo mais abrangente de data warehouse, projetado para servir como a fonte única e confiável da verdade para toda uma organização. Um EDW integra dados de todas as principais unidades de negócios — vendas, finanças, operações, recursos humanos, sistemas de gerenciamento de relacionamento com o cliente (CRM) e sistemas de gerenciamento de inventário — em um único data warehouse centralizado, governado por padrões consistentes de qualidade de dados e controles de acesso.

Arquitetura e escopo

A característica definidora de um enterprise data warehouse é o seu escopo interorganizacional. Os dados de várias fontes passam por processos de Extract, Transform, Load (ETL) antes de chegarem ao warehouse, onde regras de negócios, limpeza de dados e validação garantem a consistência entre as equipes. O resultado é um repositório governado onde cada analista consulta a mesma versão dos dados de negócios, independentemente de seu departamento.

Os EDWs normalmente implementam uma arquitetura de três camadas. A camada inferior lida com fontes de dados e processos de ETL que ingerem e transformam dados brutos de sistemas operacionais. A camada intermediária hospeda um servidor OLAP que torna os dados acessíveis para análises multidimensionais. A camada superior fornece ferramentas de front-end — dashboards e aplicativos de BI — onde os usuários de negócios analisam os dados. Esse design em camadas separa a complexidade da ingestão do desempenho analítico, permitindo que cada camada seja otimizada de forma independente.

Quando escolher um EDW

Um EDW é a base certa quando sua organização precisa de análises em toda a empresa, relatórios de conformidade regulatória ou uma única fonte da verdade entre unidades de negócios que atualmente operam em silos de dados. Organizações com requisitos complexos de governança de dados — como empresas de serviços financeiros que gerenciam relatórios regulatórios, organizações de saúde que gerenciam dados de pacientes ou grandes fabricantes que integram dados de cadeia de suprimentos e produção — são as que mais se beneficiam da governança centralizada que um EDW oferece.

O principal desafio dos data warehouses tradicionais é a escalabilidade. À medida que o volume de dados cresce, formatos de tabela proprietários e configurações de hardware fixas tornam as implantações de EDW on-premises caras para escalar. Muitas organizações que enfrentam essa limitação estão migrando para arquiteturas baseadas em nuvem ou lakehouse que mantêm o modelo de governança de um EDW, ao mesmo tempo que eliminam o limite de infraestrutura.

Data Marts

Um data mart é um subconjunto específico de assunto de um data warehouse, focado em um único departamento, função de negócios ou domínio analítico. Enquanto um EDW atende a toda a organização, um data mart atende a um público focado — a equipe de marketing, o departamento financeiro ou uma operação de vendas regional. Os data marts armazenam dados em formatos otimizados para consultas e relatórios específicos que uma equipe específica executa, normalmente usando designs de esquema estrela (star schema) ou esquema floco de neve (snowflake schema) desnormalizados que minimizam a complexidade de junção.

Data Marts dependentes e independentes

Os data marts se dividem em dois padrões arquitetônicos. Um data mart dependente extrai dados de um EDW existente, herdando os padrões de governança e qualidade de dados do repositório central. Essa é a abordagem recomendada quando um EDW já existe, pois evita definições de métricas conflitantes entre os departamentos.

Um data mart independente ingere dados diretamente dos sistemas de origem, sem passar por um EDW. Os marts independentes são mais rápidos de construir, mas criam riscos: cada mart pode aplicar regras de negócios diferentes, levando a relatórios inconsistentes entre as unidades de negócios — precisamente o tipo de silo de dados que a arquitetura de data warehouse visa eliminar.

Quando construir um Data Mart

Construa um data mart quando uma equipe específica tiver requisitos analíticos que não justifiquem esperar por uma implementação completa de EDW, quando o desempenho da consulta em um subconjunto de dados precisar de otimização independente ou quando a propriedade departamental dos dados for um requisito de governança. Os data marts funcionam muito bem para análise de dados de vendas, atribuição de marketing e relatórios financeiros — casos de uso em que o domínio de dados é bem definido e o público é concentrado.

Operational Data Store (ODS)

Um Operational Data Store (ODS) é um tipo de data warehouse projetado para relatórios em tempo quase real e tomada de decisões operacionais, posicionado entre os bancos de dados transacionais e o EDW analítico. Enquanto um EDW armazena dados históricos acumulados ao longo de anos, um ODS mantém dados operacionais atuais e recentes — normalmente atualizados em intervalos que variam de minutos a horas — otimizados para consultas que refletem o estado atual dos negócios, em vez de tendências de longo prazo.

O papel do ODS na arquitetura de dados

Sistemas operacionais como plataformas de CRM, sistemas de gerenciamento de inventário e plataformas de processamento de pedidos geram dados transacionais continuamente, mas não são projetados para consultas analíticas. Executar relatórios complexos em um banco de dados transacional de produção desacelera as operações que ele suporta. O ODS resolve isso replicando os dados operacionais em um ambiente separado, onde os analistas podem consultá-los sem impactar os sistemas de origem.

Um ODS integra dados de várias fontes operacionais, aplica uma transformação leve para padronizar os formatos e disponibiliza os dados operacionais integrados para relatórios. Ele não substitui o EDW — a análise de tendências históricas e as consultas de planejamento estratégico ainda pertencem ao warehouse. O ODS lida com questões operacionais urgentes: níveis atuais de estoque, desempenho de vendas no mesmo dia, casos ativos de suporte ao cliente.

Data Warehouse Virtual

Um data warehouse virtual — às vezes chamado de data warehouse federado — não consolida fisicamente os dados em um único local de armazenamento. Em vez disso, ele cria uma camada de abstração lógica que consulta os dados diretamente em vários sistemas de origem, apresentando esses sistemas distintos como um ambiente analítico unificado.

Os warehouses virtuais dependem da tecnologia de federação de consultas para enviar as consultas aos sistemas de origem e agregar os resultados na camada de apresentação. Essa abordagem elimina o custo de armazenamento e infraestrutura de ETL da consolidação física e proporciona um time-to-value mais rápido ao analisar dados que já existem em bancos de dados operacionais sem movê-los. A principal limitação é o desempenho da consulta: consultas complexas que exigem a junção de grandes conjuntos de dados em vários sistemas introduzem uma latência significativa, pois cada consulta deve recuperar dados de sistemas que não foram projetados para cargas de trabalho analíticas.

Os data warehouses virtuais funcionam melhor para análises exploratórias, relatórios em pequena escala ou situações em que restrições regulatórias impedem a movimentação de dados. Eles raramente são a arquitetura certa para consultas analíticas de alto volume ou cargas de trabalho de IA que exigem processamento de dados em larga escala.

Data Warehouses baseados em nuvem

Data warehouses baseados em nuvem são hospedados em plataformas de nuvem — AWS, Microsoft Azure, Google Cloud e outras — e fornecem recursos de data warehouse como serviços totalmente gerenciados. As organizações que executam data warehouses baseados em nuvem não provisionam nem mantêm hardware físico; o provedor de nuvem gerencia a infraestrutura enquanto a organização se concentra em ingerir, modelar e analisar dados.

Vantagens da implantação em nuvem

A vantagem mais significativa dos data warehouses baseados em nuvem é a escalabilidade elástica. Os data warehouses on-premises tradicionais exigem que as organizações dimensionem o hardware para a carga de pico, resultando em superprovisionamento durante as operações normais. Os warehouses em nuvem escalam automaticamente os recursos de computação e armazenamento com base na demanda em um modelo pay-as-you-go, de modo que as organizações pagam pelo que usam. A implantação em nuvem também acelera o time-to-value: enquanto as implantações on-premises podem levar meses desde a aquisição até a produção, um data warehouse em nuvem pode ser provisionado e carregar dados em poucas horas.

Custos de egress e prontidão para migração

Os data warehouses baseados em nuvem trazem trade-offs que as organizações precisam avaliar. As taxas de egresso de dados — cobranças para mover dados para fora da rede de um provedor de nuvem — podem se tornar significativas em escala. Organizações que operam em múltiplos provedores de nuvem enfrentam uma complexidade adicional para gerenciar a integração de dados, políticas de segurança e frameworks de governança em diferentes plataformas.

Antes de migrar para um data warehouse em nuvem, avalie o volume de dados que sairá da plataforma, analise formatos de dados abertos que reduzem o vendor lock-in e confirme se os recursos de governança e segurança da plataforma de destino atendem aos seus requisitos de conformidade.

Data Warehouses Híbridos e Modernos

Um data warehouse híbrido combina recursos de armazenamento de dados locais (on-premises) e em nuvem, permitindo que as organizações mantenham dados confidenciais ou regulamentados em seus próprios data centers, enquanto aproveitam a escalabilidade da nuvem para processamento analítico de demanda variável.

Características de um Data Warehouse Moderno

Um data warehouse moderno estende o modelo tradicional de várias maneiras significativas. Ele suporta não apenas dados estruturados em esquemas predefinidos, mas também dados semiestruturados e não estruturados. Ele separa a computação do armazenamento, permitindo que cada um dimensione de forma independente e reduzindo o custo do processamento de dados em grande escala. Ele se integra a pipelines de dados em streaming para reduzir a latência, suporta formatos de dados abertos para evitar o vendor lock-in e fornece integrações nativas para cargas de trabalho de machine learning e AI, além de BI e relatórios tradicionais.

Os data warehouses modernos também incorporam recursos robustos de linhagem de dados, rastreando os dados desde seus sistemas de origem, passando por cada etapa de transformação, até seu ponto de consumo final. Essa linhagem é essencial para a governança e a garantia de qualidade dos dados — quando um analista questiona um número em um relatório, a documentação da linhagem permite que a equipe de dados rastreie exatamente como esse número foi calculado.

Arquitetura de Data Lake e Lakehouse

Um data lake armazena dados brutos em seu formato original, sem esquemas predefinidos, aceitando dados estruturados, semiestruturados e não estruturados de qualquer origem. Ao contrário de um data warehouse, que exige que os dados passem por processos de ETL e estejam em conformidade com um esquema definido antes de poderem ser armazenados e consultados, um data lake aplica o schema on read — o esquema é aplicado no momento da consulta, não na ingestão. Essa flexibilidade torna os data lakes ideais para armazenar grandes volumes de dados brutos para exploração de machine learning e ciência de dados.

O trade-off é a confiabilidade. Sem a garantia de qualidade de dados que os processos de ETL oferecem, os data lakes podem acumular dados inconsistentes, duplicados ou mal documentados, nos quais os analistas não podem confiar para relatórios de BI governados.

O Lakehouse como uma Solução Unificada

Um data lakehouse combina a flexibilidade e a eficiência de custo de um data lake com os recursos de gerenciamento de dados de um data warehouse. Um lakehouse armazena dados em formatos abertos no armazenamento de objetos em nuvem e, em seguida, adiciona uma camada transacional de metadados e governança que impõe transações ACID, evolução de esquema, restrições de qualidade de dados e time travel — a capacidade de consultar dados como eles existiam em qualquer ponto histórico.

O resultado é uma plataforma única onde engenheiros de dados executam pipelines de ETL, analistas de dados executam consultas SQL em tabelas governadas e cientistas de dados acessam dados brutos e de engenharia de recursos (feature-engineered) para treinamento de modelos — tudo sem mover dados entre sistemas. A arquitetura medalhão, comum em implantações de lakehouse, organiza os dados em camadas bronze (bruto), prata (validado e integrado) e ouro (curado, pronto para consumo), melhorando progressivamente a qualidade dos dados em cada etapa. A camada ouro se mapeia diretamente para os data marts e camadas de serviço de EDW que os warehouses tradicionais já operam, tornando a transição familiar do ponto de vista arquitetônico.

Arquitetura e Armazenamento de Data Warehouse

Independentemente do modelo de implantação, a arquitetura de data warehouse reflete o mesmo princípio fundamental: os dados devem ser separados das aplicações que os geram, limpos e integrados por meio de um processo governado e armazenados em formatos otimizados para consultas analíticas, em vez de gravações transacionais.

Design de Armazenamento e Esquema

Os data warehouses modernos separam a computação do armazenamento, o que permite que cada dimensão seja dimensionada de forma independente. Os sistemas de armazenamento mantêm os dados em formatos colunares que minimizam os dados verificados durante as consultas analíticas — uma consulta que afeta apenas três colunas de cinquenta lê apenas o equivalente a três colunas, em vez de verificar cada linha em sua totalidade.

O design do esquema influencia significativamente o desempenho das consultas. O esquema estrela (star schema) organiza os dados em torno de uma tabela de fatos central — contendo eventos mensuráveis, como transações de vendas ou sessões da web — cercada por tabelas de dimensões que descrevem as entidades envolvidas (clientes, produtos, períodos de tempo). Os joins em um esquema estrela são simples e rápidos. O esquema floco de neve (snowflake schema) normaliza ainda mais as tabelas de dimensões, reduzindo a redundância de armazenamento ao custo de uma complexidade adicional de join. Um esquema galáxia (galaxy schema) compartilha tabelas de dimensões em várias tabelas de fatos, suportando consultas analíticas que abrangem diferentes processos de negócios.

Os esquemas estrela são a escolha mais comum para data marts e para a camada ouro de um lakehouse porque priorizam o desempenho de leitura. O esquema correto depende do volume de dados, dos padrões de atualização e da complexidade das consultas analíticas que o esquema deve suportar.

Tipos de Dados em um Warehouse

Historicamente, os data warehouses armazenam dados estruturados — linhas e colunas com tipos de dados e esquemas predefinidos, originados de bancos de dados relacionais, plataformas de CRM, sistemas financeiros e sistemas de gerenciamento de estoque. Dados estruturados são fáceis de consultar com SQL padrão e se integram perfeitamente a pipelines de ETL.

Dados Estruturados, Semiestruturados e Não Estruturados

Os dados semiestruturados não estão em conformidade com um esquema relacional rígido, mas contêm marcadores organizacionais que os tornam analisáveis — documentos JSON, arquivos XML, registros de log e dados de clickstream se enquadram nessa categoria. Muitas plataformas modernas de data warehouse oferecem suporte a tipos de dados semiestruturados nativos, permitindo que consultas SQL naveguem por estruturas aninhadas sem a necessidade de nivelar previamente os dados.

Dados não estruturados — imagens, vídeos, documentos de texto livre, gravações de áudio — não podem ser consultados diretamente com SQL, mas são cada vez mais importantes à medida que as organizações desenvolvem recursos de AI e machine learning. As arquiteturas de lakehouse atenuam essa fronteira, permitindo que dados não estruturados sejam armazenados e gerenciados junto com dados estruturados na mesma plataforma.

A escolha entre schema-on-write (imposição de estrutura na ingestão, como fazem os data warehouses tradicionais) e schema-on-read (adiamento da estrutura até o momento da consulta, como fazem os data lakes) reflete um trade-off fundamental entre a consistência da qualidade dos dados e a flexibilidade de ingestão. A maioria das plataformas de dados maduras usa schema-on-write para tabelas analíticas governadas e schema-on-read para zonas de dados exploratórios e brutos.

Fontes de Dados Externas e Integração

Os data warehouses raramente extraem dados de uma única fonte. As implantações empresariais típicas integram dados de bancos de dados operacionais, sistemas de CRM, plataformas de ERP, ferramentas de automação de marketing, livros-razão financeiros, provedores de dados de terceiros e APIs externas. Gerenciar a diversidade dessas fontes de dados externas — cada uma com seu próprio esquema, frequência de atualização e características de qualidade de dados — é um dos principais desafios da arquitetura de data warehouse.

Antes que os dados externos entrem no warehouse, eles devem ser validados em relação aos esquemas esperados e às regras de qualidade de dados. A validação detecta problemas comuns logo no início: campos obrigatórios ausentes, valores fora dos intervalos esperados e violações de integridade referencial. Detectar esses problemas na ingestão é muito menos dispendioso do que descobri-los depois que os dados se propagaram em relatórios e dashboards. O enriquecimento de dados — aumentando os dados ingeridos com contexto de tabelas de referência ou conjuntos de dados externos — transforma os dados de origem brutos nos conjuntos de dados prontos para os negócios que os analistas precisam.

ETL vs. ELT e Monitoramento de Pipeline

O processo de integração de dados determina como os dados se movem dos sistemas de origem para o warehouse e como são transformados. O ETL (Extract, Transform, Load) é a abordagem tradicional: os dados são extraídos das fontes, transformados em um ambiente de processamento separado e carregados em sua forma estruturada final. O ELT (Extract, Load, Transform) inverte a ordem — os dados brutos são carregados primeiro e depois transformados dentro do warehouse usando seu próprio poder de processamento. Os data warehouses modernos em nuvem geralmente preferem o ELT porque a etapa de transformação pode aproveitar os recursos de processamento paralelo do warehouse a um custo geral mais baixo. Para uma análise mais detalhada das implicações arquitetônicas, a comparação entre ELT e ETL aborda os principais trade-offs.

O monitoramento de pipelines de dados garante que os trabalhos de ingestão sejam concluídos no prazo, que os volumes de dados correspondam às expectativas e que as verificações de qualidade sejam aprovadas antes que os dados sejam promovidos para a produção. Pipelines que falham silenciosamente — sendo concluídos sem erros, mas produzindo resultados incorretos — estão entre os modos de falha mais perigosos nas operações de data warehouse.

Segurança e Governança de Dados

A governança e a segurança de dados são requisitos fundamentais para qualquer data warehouse, especialmente para organizações que lidam com dados confidenciais sujeitos à conformidade regulatória. Um warehouse que não consegue provar quem acessou quais dados, quando e com que finalidade não pode satisfazer os auditores ou manter a confiança dos clientes cujos dados ele armazena.

Controle de Acesso, Criptografia e Registro de Auditoria

A segurança de dados eficaz começa com o controle de acesso baseado em função (RBAC), que atribui permissões de acesso a dados a funções em vez de indivíduos, tornando o gerenciamento de acesso escalável em grandes organizações. Os controles de acesso devem operar em vários níveis: o nível do catálogo, o nível da tabela, o nível da coluna (essencial para mascarar informações de identificação pessoal) e o nível da linha (com base na afiliação organizacional ou na propriedade dos dados).

Os dados devem ser criptografados tanto em repouso quanto em trânsito. A criptografia em repouso protege contra o acesso não autorizado a mídias de armazenamento; a criptografia em trânsito protege contra a interceptação em redes. O log de auditoria registra cada evento de acesso e modificação — quem consultou uma tabela, quando e quais dados foram retornados — apoiando investigações de segurança e demonstrações de conformidade regulatória. O rastreamento de linhagem de dados, que acompanha os dados desde sua origem por cada transformação até seu ponto de consumo, apoia tanto a governança quanto a garantia de qualidade dos dados.

Casos de uso de análise de dados por tipo de data warehouse

Diferentes tipos de data warehouse se mapeiam para diferentes cargas de trabalho analíticas, e entender esse mapeamento ajuda as organizações a evitar a implantação de uma arquitetura otimizada para um tipo de carga de trabalho esperando que ela tenha um bom desempenho em todos os casos de uso.

Correspondendo a arquitetura à carga de trabalho

Os enterprise data warehouses oferecem suporte a análises estratégicas — análise de tendências ano a ano, relatórios multifuncionais, painéis executivos e relatórios de conformidade que exigem a junção de dados em vários domínios de negócios. Os data marts oferecem suporte a análises departamentais — desempenho de vendas, atribuição de marketing, relatórios de fechamento financeiro e segmentação de clientes — onde o escopo de dados restrito torna o autoatendimento mais rápido. Os operational data stores oferecem suporte a análises operacionais — monitorando as condições atuais dos negócios e respondendo a eventos em tempo real em ambientes de varejo, logística e serviços financeiros.

As arquiteturas de nuvem e lakehouse oferecem suporte a análises avançadas e AI — treinamento de modelos de machine learning em grande escala, pipelines de processamento de linguagem natural e sistemas de recomendação. Essas cargas de trabalho exigem não apenas dados estruturados governados, mas também os dados brutos e semiestruturados que apenas uma arquitetura de armazenamento mais flexível pode acomodar.

BI, relatórios e análises avançadas

As ferramentas de BI se conectam a data warehouses para criar painéis e relatórios acessíveis a usuários de negócios que não escrevem SQL. A integração de machine learning exige que os cientistas de dados acessem tanto dados limpos e governados para engenharia de recursos quanto dados históricos brutos para treinamento de modelos. As arquiteturas lakehouse oferecem suporte a ambos os casos de uso em uma única plataforma, eliminando a sobrecarga de engenharia de dados de manter cópias de dados separadas para cargas de trabalho de BI e ML.

Escolhendo e migrando para uma solução de data warehouse

A seleção da solução de data warehouse certa envolve a avaliação de opções gerenciadas pelo fornecedor versus hospedadas por conta própria, a compreensão das estruturas de custos e a validação de que uma plataforma pode suportar suas cargas de trabalho analíticas específicas em escala. Os serviços gerenciados pelo fornecedor cuidam do gerenciamento de infraestrutura, dimensionamento, aplicação de patches e alta disponibilidade ao custo de algum controle operacional. As opções hospedadas por conta própria oferecem às organizações mais flexibilidade para requisitos estritos de residência de dados ou políticas de segurança complexas, mas exigem que as equipes gerenciem clusters, coordenem atualizações e cuidem do planejamento de capacidade.

Avaliando fatores de fornecedor e custo

Os custos do data warehouse dividem-se em três categorias: custos de armazenamento, custos de computação e custos de movimentação de dados. Os data warehouses em nuvem modernos cobram o armazenamento e a computação separadamente, permitindo que cada um seja dimensionado de forma independente. Antes de se comprometer com uma plataforma para cargas de trabalho de produção críticas, execute uma prova de conceito com seus dados e padrões de consulta reais — os benchmarks sintéticos raramente refletem o desempenho no mundo real nos volumes de dados com os quais você opera.

Migração em fases e otimização de custos

A migração de um data warehouse herdado para uma plataforma moderna se beneficia de uma abordagem em fases organizada por domínio de negócios. Comece com um domínio que tenha requisitos de dados bem definidos e um proprietário de negócios motivado. Valide la migração em relação aos benchmarks de produção antes de prosseguir para o próximo domínio.

A separação de computação e armazenamento é uma das alavancas de otimização de custos mais significativas nos data warehouses modernos. Nas arquiteturas tradicionais, a computação e o armazenamento são dimensionados juntos. As arquiteturas de nuvem modernas desacoplam essas dimensões, permitindo que as organizações adicionem armazenamento sem provisionar computação adicional e aumentem a computação para períodos de pico de consulta sem aumentar permanentemente os custos de armazenamento. O dimensionamento automático evita tanto o subprovisionamento durante os períodos de pico quanto o superprovisionamento durante os períodos de inatividade.

Comparação de tipos de data warehouse

Perguntas frequentes

Quais são os principais tipos de data warehouse?

Os três principais tipos de data warehouse são o Enterprise Data Warehouse (EDW), o Data Mart e o Operational Data Store (ODS). Além desses tipos principais, as organizações também implantam data warehouses baseados em nuvem, data warehouses virtuais, data warehouses híbridos que combinam armazenamento on-premises e em nuvem, e arquiteturas lakehouse que unificam a governança de warehouse com a flexibilidade do data lake. Cada tipo atende a casos de uso distintos com base no escopo dos dados, requisitos de latência e cargas de trabalho analíticas.

Qual é a diferença entre um data warehouse e um data lake?

Um data warehouse armazena dados estruturados em esquemas predefinidos e impõe a qualidade dos dados por meio de processos ETL antes que os dados sejam carregados. Um data lake armazena dados brutos em seu formato original — estruturado, semiestruturado ou não estruturado — sem exigir um esquema predefinido na ingestão. Os data warehouses são otimizados para consultas SQL analíticas complexas e relatórios de BI; os data lakes são otimizados para flexibilidade e cargas de trabalho de ciência de dados e machine learning em grande escala. Um lakehouse combina ambos: ele armazena dados em formatos abertos com a flexibilidade do data lake e, em seguida, adiciona uma camada transacional e de governança com a confiabilidade de um data warehouse.

Quando uma organização deve usar um data mart em vez de um EDW?

Um data mart é a escolha certa quando um departamento específico precisa de recursos analíticos mais rapidamente do que uma implementação completa de EDW permite, quando o desempenho da consulta em um domínio de dados restrito precisa de otimização independente ou quando a propriedade dos dados departamentais é um requisito de governança. Os data marts são mais eficazes como repositórios dependentes criados sobre um EDW existente, extraindo do repositório central em vez de ingerir diretamente dos sistemas de origem. A criação de data marts independentes sem um EDW central corre o risco de criar definições de métricas inconsistentes e silos de dados entre as equipes.

O que é um Operational Data Store e como ele se diferencia de um data warehouse?

Um Operational Data Store (ODS) contém dados operacionais atuais e quase atuais atualizados em intervalos que variam de minutos a horas, projetado para relatórios operacionais e tomada de decisões. Um data warehouse acumula dados históricos ao longo dos anos e é otimizado para análise de tendências, relatórios estratégicos e consultas multidimensionais complexas. O ODS preenche a lacuna de latência entre os sistemas transacionais operacionais e o warehouse, que pode ser atualizado apenas diariamente. Ambos os sistemas são frequentemente implantados juntos: o ODS oferece suporte à visibilidade operacional no mesmo dia, enquanto o warehouse oferece suporte à análise estratégica de longo prazo.

Como os data warehouses em nuvem se diferenciam dos data warehouses locais (on-premises)?

Os data warehouses em nuvem são hospedados em plataformas de nuvem e oferecem escalabilidade elástica, preços de pagamento conforme o uso (pay-as-you-go) e menor sobrecarga de gerenciamento de infraestrutura em comparação com as implantações locais (on-premises). Os data warehouses locais tradicionais devem ser dimensionados para a capacidade máxima, o que geralmente resulta em um superprovisionamento significativo durante as operações normais. Os warehouses em nuvem são dimensionados automaticamente e podem ser provisionados em horas. As compensações incluem custos de saída de dados em volumes elevados, dependência da disponibilidade de um provedor de nuvem e complexidade de governança para organizações que operam em várias plataformas de nuvem.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original