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

Banco de DadosBig Data

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

Cargo: Analista Judiciário - Tecnologia da Informação - Analista de Inteligência Artificial

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 Lakehouse: a solução unificada para BI e Big Data

Gabarito: letra E. A arquitetura Lakehouse combina o melhor do Data Warehouse e do Data Lake, oferecendo suporte a transações ACID para dados estruturados (vendas) e armazenamento bruto para dados semiestruturados (logs e IoT), com governança e baixa latência para BI. É a única alternativa que atende a todos os requisitos sem duplicação de silos.

O cenário exige uma arquitetura que suporte simultaneamente:

Consistência ACID e baixa latência em consultas complexas (joins) para BI.
Armazenamento de petabytes de dados brutos (clickstream, sensores) para Machine Learning, sem perda de informação.
Redução de custo e governança unificada.

A tabela comparativa a seguir ilustra as diferenças entre as abordagens tradicionais e a Lakehouse:

Característica	Data Warehouse	Data Lake	Data Lakehouse
Uso típico	BI tradicional	Big Data e ML	BI, Big Data e ML
Tipo 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 (pode ser adicionado)	Sim (ex.: Delta Lake, Iceberg)
Latência para BI	Alta (dados agregados)	Baixa (mas varreduras brutas)	Baixa (camada Gold otimizada)
Custo	Mais elevado	Mais baixo	Otimizado

Nenhuma das alternativas A a D resolve o trade-off entre ACID/performance e flexibilidade/volume. Vejamos cada uma.

Alternativa A — ❌ Incorreta

Propor um EDW normalizado (3FN) para todos os dados é inviável. Dados de clickstream e IoT são semiestruturados e em petabytes; a normalização rígida aumentaria custo e complexidade, e o desempenho em consultas analíticas (joins) seria prejudicado. Além disso, a normalização não é a única forma de garantir ACID – o próprio Lakehouse oferece ACID em formatos abertos. A alternativa ignora a necessidade de manter dados brutos para ML.

Alternativa B — ❌ Incorreta

Um Data Lake puro com Schema-on-Read atenderia à equipe de ciência de dados, mas os painéis de BI exigem baixa latência em consultas com múltiplas junções – impraticável sobre arquivos brutos mesmo com ferramentas como Presto ou Spark. A latência e a complexidade das transformações em tempo de execução inviabilizam o uso para BI operacional. Além disso, faltam transações ACID para os dados de vendas, comprometendo a consistência.

Alternativa C — ❌ Incorreta

Manter Data Marts dimensionais separados e usar federação (virtualização) para a equipe de ciência de dados não resolve: os Data Marts armazenam dados agregados/modelados, não brutos. A equipe de ML precisa de dados no formato original, sem perdas – o que a virtualização não oferece (ela apenas consulta os dados modelados). Além disso, a federação aumenta a latência e não resolve o problema de volume (petabytes). A alternativa nega a necessidade de um Data Lake.

Alternativa D — ❌ Incorreta

Bancos NoSQL orientados a documentos (como MongoDB) não são adequados para workloads de BI com múltiplas junções; a desnormalização extrema (documentos aninhados) pode até evitar joins, mas dificulta consultas ad hoc e compromete a consistência. Além disso, o suporte a transações ACID em bancos NoSQL é limitado (geralmente apenas no nível de documento), não atendendo ao requisito de consistência estrita das vendas. A alternativa também não prevê armazenamento de dados brutos para ML.

Alternativa E — ✅ Correta ⟵ GABARITO

A arquitetura Lakehouse, implementada com formatos de tabela abertos (Delta Lake, Apache Iceberg) sobre object storage (ex.: S3, ADLS), oferece:

Camada Bronze (raw): dados brutos ingeridos no formato original (logs, sensores), acessíveis para ciência de dados sem perda de informação.
Camada Silver: dados limpos e validados, com possibilidade de Schema Enforcement.
Camada Gold: dados modelados dimensionalmente (esquema estrela) para BI, com suporte a transações ACID (garantindo consistência nos dados de vendas) e performance otimizada para consultas complexas.
Governança unificada: metadados, linhagem, controle de acesso, tudo em um único ambiente.
Custo reduzido: armazenamento em object storage é barato e elástico.

Assim, a Lakehouse elimina a duplicação de silos (DW + Data Lake), atende tanto a BI quanto a IA, e reduz custo. É a abordagem moderna recomendada para cenários híbridos como o descrito.

🎯 Pegadinha: A banca tenta confundir o candidato com alternativas que focam em apenas uma das necessidades (ex.: só Data Lake para ML, ou só Data Warehouse para BI). A chave é perceber que a arquitetura deve atender a AMBAS as frentes sem duplicação. A Lakehouse é a única que integra transações ACID, suporte a dados brutos e modelagem dimensional otimizada.

💡 Dica: Em questões sobre arquitetura de dados, lembre-se do tripé: consistência (ACID), volume (Big Data) e variedade (estruturados + não estruturados). A Lakehouse surge como resposta moderna para unificar esses requisitos. Estude os conceitos de Bronze/Silver/Gold e formatos como Delta Lake e Iceberg.

Gabarito: letra E.

Link permanente: /questoes/fg133800