Uma corporação multinacional do setor de varejo está unifica...

Próximas questões
Com base no mesmo assunto
Q3878687 Banco de Dados
Uma corporação multinacional do setor de varejo está unificando suas plataformas de dados. O cenário atual apresenta dois desafios distintos, indicados a seguir.
• Transacional e BI: o sistema de vendas gera registros financeiros que exigem consistência estrita (ACID). A equipe de analistas de negócios consome esses dados via painéis de BI que demandam baixa latência em consultas complexas com múltiplas junções (joins).
• Big Data e IA: o sistema de e-commerce gera petabytes de logs de navegação (clickstream) e dados de sensores IoT das lojas físicas (dados semiestruturados). A equipe de ciência de dados precisa acessar esses dados em seu formato bruto para treinar modelos preditivos, sem a perda de informações causada por agregações prematuras.
O arquiteto de dados precisa propor uma solução única que evite a duplicação de dados entre silos (um Data Warehouse para o BI e um Data Lake para a IA) e reduza o custo de armazenamento, mantendo a governança. Considerando os requisitos apresentados e as características das arquiteturas modernas de dados, a abordagem arquitetural e de modelagem adequada é:
Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

Gabarito: E

Fundamento decisivo: O ponto decisivo foi a necessidade de unificar os dados sem manter dois silos separados, preservando ao mesmo tempo os dados brutos para IA e um ambiente adequado ao BI. Entre as alternativas, só a Lakehouse reúne esses requisitos no mesmo ecossistema.

Tema central: Arquitetura Lakehouse
Análise das alternativas
A
Errada
Erra ao colocar todos os dados, inclusive logs e IoT brutos, em um EDW relacional normalizado em 3FN. Isso contraria o requisito de manter dados semiestruturados em formato bruto para IA e não se ajusta ao cenário de petabytes típico de lake.
B
Errada
Erra porque um Data Lake puro com schema-on-read atende a ciência de dados, mas deixa o BI dependente de agregações e joins sobre arquivos brutos em tempo de execução. Isso confronta diretamente o requisito de baixa latência para consultas complexas.
C
Errada
Erra por manter separação física e Data Marts departamentais, preservando silos em vez de evitá-los. Além disso, trocar o acesso a dados brutos por consulta a Data Mart não atende à necessidade da ciência de dados de usar o dado original sem agregação prematura.
D
Errada
Erra porque centralizar tudo em NoSQL documental com desnormalização extrema e documentos aninhados não entrega a combinação pedida de camada bruta acessível, camada analítica otimizada e governança unificada. Também não é a solução arquitetural mais aderente ao BI com múltiplas junções e modelagem analítica adequada.
E
Certa
A alternativa E está correta porque descreve uma Lakehouse sobre armazenamento de objetos com formatos de tabela abertos, o que permite transações ACID e controle de esquema nos dados analíticos. Além disso, preserva os dados brutos na camada Bronze para ciência de dados e usa modelagem dimensional na camada Gold para atender ao BI com desempenho adequado.
Pegadinha da questão
A confusão explorada foi tomar unificação arquitetural como se significasse colocar tudo em um único tipo de banco, ou supor que Data Lake puro ou desnormalização extrema resolveriam igualmente bem BI e IA.
Dica para questões semelhantes
  • Quando a questão exigir simultaneamente dados brutos para IA e consumo analítico otimizado para BI, procure arquitetura com camadas bruta e curada no mesmo ecossistema.
  • Se houver baixa latência para BI com consultas complexas, descarte soluções que deixem joins e agregações diretamente sobre arquivos brutos como estratégia principal.
  • Se o enunciado pedir evitar duplicação entre Data Warehouse e Data Lake, elimine propostas que mantenham separação física ou silos departamentais.
  • Não trate 3FN, schema-on-read puro ou desnormalização extrema como solução universal; compare cada proposta com todos os requisitos ao mesmo tempo.

Clique para visualizar este gabarito

Visualize o gabarito desta questão clicando no botão abaixo

Comentários

Veja os comentários dos nossos alunos

QUESTÃO HARD

Data Lakehouse foi criada exatamente para resolver o dilema e eliminar os silos entre o Data Warehouse (focado em BI e transações ACID) e o Data Lake (focado em Big Data e Inteligência Artificial).

Abaixo estão os pontos que conectam a alternativa E perfeitamente aos requisitos do problema:

  • Garantia de ACID e Governança: O uso de formatos de tabela abertos (como Delta Lake, Apache Iceberg ou Apache Hudi) introduz uma camada de metadados sobre o Object Storage de baixo custo (S3, ADLS, GCS). Isso possibilita transações ACID confiáveis e Schema Enforcement (validação de esquemas), atendendo à exigência de consistência estrita do sistema de vendas transacionais.
  • Performance para BI (Baixa Latência): A arquitetura Lakehouse adota nativamente a organização de dados em camadas (Arquitetura Medalhão: Bronze, Silver e Gold). Ao estruturar e limpar os dados até a camada Gold usando modelagem dimensional (Star Schema ou Snowflake), ela otimiza os índices e arquivos para ferramentas de BI, viabilizando consultas complexas com múltiplos joins em alta velocidade.
  • Acesso a Dados Brutos para IA: Os dados semiestruturados de clickstream e sensores IoT podem ser armazenados em larga escala na camada Bronze em seu formato original, bruto e sem agregações. Isso permite que os cientistas de dados extraiam o valor máximo para o treinamento de modelos preditivos e de Machine Learning.
  • Redução de Custos e Eliminação de Silos: Como os dados residem em um repositório de armazenamento de objetos unificado (Object Storage), elimina-se a necessidade de duplicar informações entre um Data Lake e um Data Warehouse tradicional, reduzindo drasticamente os custos operacionais e de armazenamento.
  • A está incorreta porque tentar normalizar petabytes de logs semiestruturados e dados IoT em 3ª Forma Normal (3FN) em um EDW relacional tradicional é financeiramente inviável e tecnicamente ineficiente. Bancos relacionais rígidos não lidam bem com a velocidade e a variabilidade de dados brutos de sensores e clickstream.
  • B está incorreta porque um Data Lake puro não oferece transações ACID robustas nativamente nem Schema Enforcement, violando o requisito de consistência estrita das vendas. Além disso, forçar a equipe de BI a fazer joins complexos direto em arquivos brutos (Schema-on-Read) geraria uma latência inaceitável para os painéis gerenciais.
  • C está incorreta porque mantém a separação física e os silos que o arquiteto quer evitar. Além disso, usar virtualização de dados para que cientistas consultem dados puramente dimensionais (já agregados ou tratados) impede o acesso ao formato bruto necessário para os modelos de IA.
  • D está incorreta porque bancos NoSQL orientados a documentos (como MongoDB) não foram projetados para processar consultas analíticas de BI complexas (OLAP) com múltiplos joins em escala de petabytes. A desnormalização extrema exigida degradaria o controle de consistência ACID exigido para as transações financeiras de vendas.

Clique para visualizar este comentário

Visualize os comentários desta questão clicando no botão abaixo