Banco de Dados · FGV · 2026 | Questão sqc-fg133976

Banco de DadosBig Data

Código: fg133976
Banca: FGV
Órgão: TJ-RJ
Ano: 2026
Nível: Superior

Cargo: Analista Judiciário - Tecnologia da Informação - Cientista 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 é:

Aimplementar um Data Warehouse Enterprise (EDW) baseado em banco de dados relacional com modelagem normalizada (3FN) para todos os dados, garantindo a integridade referencial tanto das vendas quanto dos logs, visto que a normalização é a única forma de garantir consistência ACID em escala de petabytes;
Badotar uma arquitetura Data Lake pura (baseada em Hadoop/HDFS ou Object Storage), utilizando a abordagem Schema-on-Read para todos os consumidores; isso atenderá à equipe de ciência de dados, e a equipe de BI deverá adaptar suas ferramentas para realizar as agregações e junções em tempo de execução, aceitando a latência inerente à varredura de arquivos brutos;
Cmanter a separação física, construindo um Data Mart dimensional para cada departamento dentro de um banco relacional proprietário e utilizando ferramentas de federação de dados (Data Virtualization) para que a equipe de ciência de dados consulte o Data Mart em tempo real, evitando assim a construção de um Data Lake e garantindo que o modelo de dados seja sempre Schema-on-Write;
Dutilizar um banco de dados NoSQL orientado a documentos (como MongoDB) para centralizar tanto as vendas quanto os logs, aproveitando a flexibilidade do esquema (schemaless) para ingerir dados heterogêneos rapidamente, e resolver a necessidade de BI através de processos de desnormalização extrema, armazenando todos os dados relacionados em um único documento aninhado para evitar joins;
Eimplementar uma arquitetura Lakehouse, utilizando formatos de tabela abertos (como Delta Lake ou Apache Iceberg) sobre o armazenamento de objetos; isso permite aplicar transações ACID e Schema Enforcement nos dados de vendas, enquanto se adota uma modelagem dimensional (esquema estrela) na camada "Gold" para performance de BI, mantendo os dados brutos (camada "Bronze") acessíveis para Machine Learning.

Revelar gabarito e comentário

GabaritoE — implementar uma arquitetura Lakehouse, utilizando formatos de tabela abertos (como Delta Lake ou Apache Iceberg) sobre o armazenamento de objetos; isso permite aplicar transações ACID e Schema Enforcement nos dados de vendas, enquanto se adota uma modelagem dimensional (esquema estrela) na camada "Gold" para performance de BI, mantendo os dados brutos (camada "Bronze") acessíveis para Machine Learning.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Arquitetura de Dados: Lakehouse

Gabarito: letra E. A arquitetura Lakehouse, implementada com formatos de tabela abertos como Delta Lake ou Apache Iceberg sobre armazenamento de objetos, atende simultaneamente aos requisitos de consistência ACID para dados transacionais, baixa latência em consultas complexas de BI (via modelagem dimensional na camada Gold) e acesso a dados brutos para machine learning (camada Bronze), eliminando a duplicação entre Data Warehouse e Data Lake, reduzindo custos e mantendo governança.

A questão cobra o conhecimento das arquiteturas modernas de dados: Data Warehouse, Data Lake e Lakehouse. O cenário apresenta desafios típicos de empresas que precisam unificar cargas de trabalho transacionais (ACID, BI com joins) e de big data/IA (dados semiestruturados, petabyte, schema-on-read). A solução ideal é o Lakehouse, que combina o melhor dos dois mundos.

Alternativa A — ❌ Incorreta

Um EDW baseado em banco relacional com modelagem normalizada (3NF) é inadequado para petabytes de logs de navegação e dados IoT semiestruturados. A normalização não escala para esse volume e não suporta schema-on-read; além disso, a latência de consultas complexas em dados normalizados tende a ser alta. A consistência ACID não é garantida apenas pela normalização — ela exige mecanismos de controle de concorrência e transações.

Alternativa B — ❌ Incorreta

Uma arquitetura Data Lake pura (schema-on-read) atende à equipe de ciência de dados, mas falha no requisito de BI: consultas complexas com múltiplas junções sobre arquivos brutos têm alta latência, pois exigem varredura completa e transformação em tempo de execução. Além disso, sem governança adequada, o Data Lake pode degradar para "data swamp".

Alternativa C — ❌ Incorreta

Manter a separação física com Data Marts dimensionais e usar federação de dados (virtualização) para a equipe de ciência de dados não resolve a duplicação de dados e aumenta o custo de armazenamento. A equipe de ciência de dados precisaria acessar dados via virtualização, que pode ser lenta para grandes volumes e não mantém os dados brutos originais necessários para treinar modelos sem perda de informação.

Alternativa D — ❌ Incorreta

Um banco NoSQL orientado a documentos (MongoDB) com desnormalização extrema não oferece suporte ACID robusto para transações financeiras (vendas) e não é eficiente para consultas com múltiplas junções — justamente o que o BI precisa. Além disso, documentos aninhados enormes podem exceder limites de tamanho e prejudicar a performance. Não é uma solução para petabytes com governança.

Alternativa E — ✅ Correta ⟵ GABARITO

A arquitetura Lakehouse resolve exatamente os dois desafios:

Dados transacionais: o formato de tabela aberto (Delta Lake/Iceberg) fornece transações ACID, schema enforcement e versionamento, garantindo consistência.
BI: a camada "Gold" com modelagem dimensional (esquema estrela) oferece desempenho em consultas complexas com baixa latência.
Big Data/IA: a camada "Bronze" mantém os dados brutos (log, IoT) sem agregações, acessíveis para machine learning com schema-on-read.
O armazenamento único sobre objetos reduz custos e a governança é integrada.

A tabela abaixo resume as diferenças entre as arquiteturas:

Característica	Data Warehouse	Data Lake	Lakehouse
Uso típico	BI tradicional	Big Data e ML	BI, Big Data e ML
Tipos de dados	Estruturados	Estruturados, semiestruturados e não estruturados	Estruturados, semiestruturados e não estruturados
Esquema	Schema-on-write	Schema-on-read	Combina schema-on-read e schema-on-write
Processamento	ETL	ELT	Suporta ELT e ETL
Transações ACID	Sim	Não (sem governança)	Sim
Performance em joins	Alta (modelo dimensional)	Baixa (varredura de arquivos)	Alta (camada Gold dimensional)
Custo de armazenamento	Mais elevado	Mais baixo	Otimizado

PEGA ESSA DICA!

Em questões que envolvem unificar cargas transacionais e analíticas, o Lakehouse é a tendência moderna. Lembre-se da medalharia Bronze→Silver→Gold: Bronze armazena dados brutos; Silver faz limpeza e enriquecimento; Gold contém dados modelados (estrela) para BI. Essa estrutura atende tanto cientistas de dados quanto analistas de negócios.

Gabarito: letra E — a única alternativa que atende a todos os requisitos sem duplicação de dados, com governança e custo reduzido.

Link permanente: /questoes/fg133976