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

Banco de DadosArquitetura de Banco de Dados

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

Cargo: Analista Judiciário - Tecnologia da Informação - Arquiteto 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 Lakehouse: a solução que unifica Data Lake e Data Warehouse

Gabarito: letra E. A arquitetura Lakehouse, implementada com formatos de tabela abertos como Delta Lake ou Apache Iceberg, combina a flexibilidade e escalabilidade do Data Lake (armazenamento de objetos) com as garantias ACID e o desempenho analítico de um Data Warehouse. Isso permite que dados transacionais (vendas) sejam tratados com consistência ACID e schema enforcement, enquanto os dados brutos (logs, IoT) ficam disponíveis para machine learning na camada Bronze, e uma camada Gold modelada em esquema estrela oferece baixa latência para BI, evitando duplicação de dados entre silos.

A banca testa o conhecimento sobre arquiteturas modernas de dados e a capacidade de equilibrar requisitos conflitantes: consistência transacional, desempenho de BI em larga escala e acesso a dados brutos para IA, tudo com governança e economia de armazenamento. A alternativa E é a única que atende simultaneamente a todos os pontos.

Alternativa A — ❌ Incorreta

Um Data Warehouse Enterprise (EDW) relacional com modelagem normalizada (3FN) é inadequado para petabytes de dados semiestruturados (logs, IoT), pois a normalização rígida e o schema-on-write impõem alto custo de transformação e armazenamento, além de não preservar o formato bruto necessário para machine learning. A consistência ACID em escala de petabytes é possível, mas o EDW tradicional não escala para dados não relacionais nem oferece a flexibilidade de schema-on-read.

Alternativa B — ❌ Incorreta

Uma arquitetura Data Lake pura com schema-on-read atende bem a dados brutos para IA, mas não oferece suporte ACID para dados transacionais de vendas, comprometendo a consistência financeira. Além disso, consultas de BI com múltiplas junções sobre arquivos brutos (Parquet, Avro) teriam latência alta e exigiriam adaptações significativas nas ferramentas de BI, contrariando o requisito de baixa latência.

Alternativa C — ❌ Incorreta

Manter a separação física com Data Marts e usar federação de dados (data virtualization) não resolve o problema de duplicação de dados entre silos, apenas mascara a integração com uma camada virtual. Além disso, a equipe de ciência de dados precisaria consultar dados modelados dimensionalmente (schema-on-write), perdendo o acesso ao formato bruto e gerando overhead de transformação. A federação também pode introduzir latência adicional.

Alternativa D — ❌ Incorreta

Um banco NoSQL orientado a documentos como MongoDB oferece flexibilidade de esquema (schemaless) para ingerir dados heterogêneos, mas não garante ACID forte de forma nativa (embora versões recentes tenham suporte limitado, não é o ideal para transações financeiras). A desnormalização extrema em documentos aninhados para evitar joins gera redundância e dificulta consultas analíticas complexas (múltiplas junções) típicas de BI. Além disso, a performance para grandes volumes de dados semiestruturados pode ser inferior à de um Lakehouse.

Alternativa E — ✅ Correta ⟵ GABARITO

A arquitetura Lakehouse, com formatos de tabela abertos (Delta Lake, Iceberg) sobre object storage, implementa camadas (Bronze/Silver/Gold) que separam dados brutos, dados tratados e dados modelados para BI. A camada Bronze armazena logs e dados IoT em formato bruto (schema-on-read) para machine learning. A camada Gold aplica modelagem dimensional (esquema estrela) com tabelas otimizadas para BI, suportando transações ACID e schema enforcement para os dados de vendas. Isso elimina a duplicação entre Data Lake e Data Warehouse, reduz custos de armazenamento e mantém governança centralizada.

PEGA ESSA DICA!

Na prova, lembre-se da sigla "L-A-K-E-H-O-U-S-E": Lake (dados brutos) + Warehouse (dados modelados) + ACID + Schema enforcement. Questões que pedem solução única para BI + Big Data + IA quase sempre apontam para Lakehouse. Fique atento a alternativas que sugerem Data Lake puro (falta ACID) ou EDW puro (falta flexibilidade para dados brutos).

Gabarito: letra E.

Link permanente: /questoes/fg133950