Banco de Dados · FCC · 2026 | Questão sqc-fc077303

Banco de DadosArquitetura de Banco de Dados

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

Cargo: Auditor Fiscal da Receita Estadual - AFRE - Gestão Tributária - Conhecimentos Específicos (P3)

A Secretaria da Fazenda de determinado Estado implementou uma solução corporativa para centralizar dados fiscais provenientes de múltiplas fontes heterogêneas: declarações de contribuintes, notas fiscais eletrônicas, dados cadastrais e informações de fiscalizações. A equipe técnica precisava garantir escalabilidade, processamento de grandes volumes e capacidade analítica para identificar irregularidades tributárias. Após análise, optou-se por uma arquitetura que permite armazenar dados brutos em formato nativo, aplicar transformações sob demanda mediante ferramentas de processamento distribuído e disponibilizar estruturas otimizadas para consultas analíticas pelos auditores fiscais, mantendo a governança através de controles transacionais sobre os metadados.A arquitetura implementada

Aconstitui um Data Lakehouse, que combina a flexibilidade do armazenamento de dados brutos em formato nativo com capacidades de processamento estruturado e consultas analíticas otimizadas, aplicando camadas de gerenciamento transacional sobre metadados mediante protocolos como Delta Lake ou Apache Iceberg, viabilizando transformações sob demanda e governança de dados para análises tributárias complexas.
Brepresenta um Data Lake federado com camadas de virtualização, que integram fontes heterogêneas mediante conectores distribuídos sem replicação física dos dados, aplicando transformações em tempo real através de processamento streaming para disponibilizar visões consolidadas aos usuários fiscais, mantendo os dados originais nos sistemas de origem com acesso mediante queries federadas.
Ccorresponde a um Data Warehouse tradicional, pois consolida dados estruturados mediante processos ETL prévios, aplicando modelagem dimensional em esquema estrela para viabilizar consultas OLAP pelos gestores tributários, garantindo consistência transacional através de protocolos ACID nas camadas de apresentação dos dados fiscais consolidados.
Dcorresponde a um Data Mart departamental, uma vez que atende exclusivamente às demandas analíticas da área tributária, implementando subconjuntos especializados dos dados corporativos com modelagem otimizada para relatórios gerenciais, utilizando processos de extração incremental dos sistemas transacionais para alimentar as estruturas dimensionais específicas do domínio fiscal.
Ecaracteriza um Data Lake convencional, que armazena dados em estado bruto sem aplicar transformações prévias, utilizando o método point to data para suportar volumes massivos de metadados.

Revelar gabarito e comentário

GabaritoA — constitui um Data Lakehouse, que combina a flexibilidade do armazenamento de dados brutos em formato nativo com capacidades de processamento estruturado e consultas analíticas otimizadas, aplicando camadas de gerenciamento transacional sobre metadados mediante protocolos como Delta Lake ou Apache Iceberg, viabilizando transformações sob demanda e governança de dados para análises tributárias complexas.

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 Banco de Dados: Data Lakehouse

Gabarito: letra A. A solução descrita combina armazenamento de dados brutos em formato nativo (característica de Data Lake) com processamento analítico otimizado e governança transacional sobre metadados (característica de Data Warehouse), exatamente o conceito de Data Lakehouse, que utiliza protocolos como Delta Lake e Apache Iceberg para gerenciar metadados de forma transacional. As demais alternativas ou omitem um desses pilares ou descrevem arquiteturas distintas.

A banca testa a capacidade de diferenciar arquiteturas modernas de dados. A chave está em identificar a presença simultânea de três elementos: (1) armazenamento de dados brutos em formato nativo, (2) transformações sob demanda (schema-on-read) via processamento distribuído, e (3) controles transacionais sobre metadados, que garantem consistência e governança.

Alternativa A — ✅ Correta ⟵ GABARITO

A descrição se alinha perfeitamente ao Data Lakehouse: armazena dados brutos (como um data lake), permite transformações sob demanda (ex.: com Apache Spark) e disponibiliza estruturas otimizadas para consultas analíticas (como índices e tabelas dimensionais). A governança é mantida por controles transacionais sobre os metadados, viabilizados por tecnologias como Delta Lake (que implementa ACID sobre dados em lote) e Apache Iceberg. Isso permite auditoria fiscal com flexibilidade e confiabilidade.

Alternativa B — ❌ Incorreta

Data Lake federado com virtualização não replica fisicamente os dados, mantendo-os nas fontes originais e acessando-os via consultas federadas. O cenário, porém, indica armazenamento centralizado de dados brutos em formato nativo, com transformações sob demanda – o que pressupõe replicação física. Além disso, a virtualização não oferece controles transacionais sobre metadados no mesmo nível que um Lakehouse.

Alternativa C — ❌ Incorreta

Data Warehouse tradicional utiliza processos ETL prévios para transformar e estruturar os dados antes do carregamento (schema-on-write), não armazenando dados brutos. O enunciado fala em armazenar dados brutos e aplicar transformações sob demanda – típico de schema-on-read. Embora um DW também ofereça consultas analíticas, a ausência de dados brutos e a necessidade de ETL prévio distinguem a arquitetura.

Alternativa D — ❌ Incorreta

Data Mart é um subconjunto departamental do Data Warehouse, voltado a uma área específica. O cenário descreve uma solução corporativa que centraliza dados de múltiplas fontes heterogêneas, ou seja, não se limita a um departamento. Além disso, Data Marts normalmente usam modelagem dimensional com ETL prévio, e não armazenamento de dados brutos com transformações sob demanda.

Alternativa E — ❌ Incorreta

Um Data Lake convencional armazena dados brutos sem transformações prévias, mas não oferece, nativamente, controles transacionais sobre metadados nem estruturas otimizadas para consultas analíticas – essas são extensões do Data Lakehouse. A descrição de "point to data" e governança via metadados é insuficiente para caracterizar um Lakehouse; falta a camada transacional e de processamento analítico otimizado.

NÃO CAIA NESSA!

A banca explora a confusão entre arquiteturas de dados. O candidato pode ser tentado a escolher Data Warehouse (alternativa C) por causa das consultas analíticas, mas o detalhe "armazenar dados brutos em formato nativo" e "transformações sob demanda" aponta para schema-on-read, típico de data lakes e lakehouses. Já o Data Lake convencional (E) não oferece governança transacional. Fique atento à presença simultânea de armazenamento bruto + processamento analítico otimizado + transacionalidade sobre metadados – essa tríade define o Lakehouse.

PEGA ESSA DICA!

Para distinguir as arquiteturas, crie uma tabela mental:

Característica	Data Warehouse	Data Lake	Data Lakehouse
Armazenamento	Dados transformados (modelo dimensional)	Dados brutos (formato nativo)	Dados brutos + estruturas otimizadas
ETL	Prévio (schema-on-write)	Sob demanda (schema-on-read)	Sob demanda (schema-on-read)
Governança	ACID tradicional	Limitada	Transacional sobre metadados (ex.: Delta Lake)
Otimização analítica	Sim (OLAP)	Não nativa	Sim (camada analítica)

Gabarito: letra A

Link permanente: /questoes/fc077303