Uma corporação multinacional do setor de varejo está unifica...
• 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 é:
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.
- 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