Arquitetura de Software · FCC · 2026 | Questão sqc-fc077599

Arquitetura de SoftwareArquitetura de Software

Código: fc077599
Banca: FCC
Órgão: SEFAZ-SP
Ano: 2026
Nível: Superior

Cargo: Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)

Uma Secretaria da Fazenda quer unificar, em nuvem, dados de NF-e, escriturações fiscais digitais, transações de cartão de crédito e cruzamentos de malha fiscal em um Único ambiente. Esse ambiente deve sustentar relatórios de arrecadação (Bl) e, também, experimentos de ciência de dados e modelos de machine learning para detectar empresas “laranja”. Já existem um Data Lake em Parquet e um Data Warehouse legado em banco relacional. Considerando governança, desempenho para Bl e flexibilidade analítica, a decisão arquitetural mais adequada a esse cenário é

Acentralizar tudo no Data Warehouse relacional, incluindo XML de NF-e, logs e dados semiestruturados convertidos para tabelas normalizadas, garantindo um repositório único e estável para Bl e analytics, ainda que exija expansão significativa de armazenamento e processamento.
Bdesativar o Data Warehouse e operar sobre o Data Lake, adotando apenas schema-on-read para maximizar flexibilidade e reduzir custos, permitindo que equipes de Bl e ciência de dados definam seus próprios esquemas e camadas de tratamento conforme a necessidade.
Cevoluir o Data Lake para um Data Lakehouse, incorporando tabelas transacionais (Delta/Iceberg/Hudi), governança via catalogo unificado e camadas de acesso otimizadas, permitindo atender simultaneamente consultas de Bl e cargas analíticas avançadas no mesmo repositório.
Dmanter dois ambientes paralelos, com dados brutos no Data Lake e uma versão curada integral em um novo Data Warehouse moderno em nuvem, garantindo isolamento entre workloads, mesmo sem metadados unificados ou mecanismo de consistência entre os dois ambientes.
Eusar o Data Lake somente como staging e arquivamento, exigindo que Bl e modelos avançados sejam alimentados exclusivamente por data marts derivados do Data Warehouse, assegurando padronização total das estruturas analíticas, ainda que isso limite o uso direto de dados semiestruturados e experimento rápido em ciência de dados.

Revelar gabarito e comentário

GabaritoC — evoluir o Data Lake para um Data Lakehouse, incorporando tabelas transacionais (Delta/Iceberg/Hudi), governança via catalogo unificado e camadas de acesso otimizadas, permitindo atender simultaneamente consultas de Bl e cargas analíticas avançadas no mesmo repositório.

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: Data Lakehouse vs. DW vs. Data Lake

Gabarito: letra C. A evolução para um Data Lakehouse (com tabelas transacionais Delta/Iceberg/Hudi, catálogo unificado e camadas otimizadas) atende simultaneamente a governança, desempenho para BI e flexibilidade analítica, combinando o melhor do Data Lake (schema-on-read, dados brutos) e do Data Warehouse (schema-on-write, ACID, performance SQL). O material de apoio compara as três arquiteturas e evidencia que o Data Lakehouse suporta BI, Big Data e Machine Learning no mesmo repositório, com alta confiabilidade e governança.

A banca testa o conhecimento sobre as limitações de cada abordagem em um cenário híbrido (dados estruturados e semiestruturados, BI tradicional + ciência de dados). A tabela a seguir resume as diferenças:

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 ambos
Processamento	ETL	ELT	ELT e ETL
Governança	Integrada	Requer implementação adicional	Integrada
Escalabilidade	Limitada	Alta	Alta

Alternativa A — ❌ Incorreta

Centralizar tudo no Data Warehouse relacional exigiria converter XML de NF-e e logs (dados semiestruturados) para tabelas normalizadas, o que reduz a flexibilidade para experimentos de ciência de dados e ML. Além disso, o DW tem escalabilidade limitada e maior custo de armazenamento, sendo inadequado para grandes volumes de dados brutos.

Alternativa B — ❌ Incorreta

Desativar o Data Warehouse e operar apenas sobre o Data Lake com schema-on-read maximiza flexibilidade, mas compromete a governança (risco de "data swamp") e o desempenho para consultas de BI, que exigem dados estruturados e otimização SQL. BI tradicional não se beneficia de schema-on-read puro.

Alternativa C — ✅ Correta ⟵ GABARITO

O Data Lakehouse (ex.: usando Apache Iceberg/Delta Lake/Hudi) unifica o repositório: dados brutos no formato Parquet (já existente) são gerenciados com transações ACID, catálogo centralizado e camadas de acesso otimizadas. Permite consultas SQL rápidas para BI (schema-on-write nas tabelas curadas) e acesso direto aos dados brutos para ciência de dados (schema-on-read). É a solução mais moderna e alinhada ao cenário.

Alternativa D — ❌ Incorreta

Manter dois ambientes paralelos sem metadados unificados nem consistência gera duplicidade, retrabalho e falta de governança. A ausência de mecanismo de consistência entre DW e Data Lake dificulta a confiabilidade dos dados e aumenta a complexidade operacional.

Alternativa E — ❌ Incorreta

Usar o Data Lake apenas como staging e arquivamento, alimentando BI e ML exclusivamente por data marts do DW, limita o uso direto de dados semiestruturados (XML, logs) e impede experimentação rápida em ciência de dados. A padronização total sacrifica flexibilidade analítica.

Gabarito: letra C

Link permanente: /questoes/fc077599