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 é:

Question

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 é: Alternativa A: implementar 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; Ou Alternativa B: adotar 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; Ou Alternativa C: manter 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; Ou Alternativa D: utilizar 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;  Ou Alternativa E: 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.

Qconcursos · Accepted Answer

Alternativa [E] 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. Gabarito: EFundamento decisivo: O ponto decisivo foi a necessidade de unificar os dados sem manter dois silos separados, preservando ao mesmo tempo os dados brutos para IA e um ambiente adequado ao BI. Entre as alternativas, só a Lakehouse reúne esses requisitos no mesmo ecossistema.Tema central: Arquitetura LakehouseAnálise das alternativasAErradaErra ao colocar todos os dados, inclusive logs e IoT brutos, em um EDW relacional normalizado em 3FN. Isso contraria o requisito de manter dados semiestruturados em formato bruto para IA e não se ajusta ao cenário de petabytes típico de lake.BErradaErra porque um Data Lake puro com schema-on-read atende a ciência de dados, mas deixa o BI dependente de agregações e joins sobre arquivos brutos em tempo de execução. Isso confronta diretamente o requisito de baixa latência para consultas complexas.CErradaErra por manter separação física e Data Marts departamentais, preservando silos em vez de evitá-los. Além disso, trocar o acesso a dados brutos por consulta a Data Mart não atende à necessidade da ciência de dados de usar o dado original sem agregação prematura.DErradaErra porque centralizar tudo em NoSQL documental com desnormalização extrema e documentos aninhados não entrega a combinação pedida de camada bruta acessível, camada analítica otimizada e governança unificada. Também não é a solução arquitetural mais aderente ao BI com múltiplas junções e modelagem analítica adequada.ECertaA alternativa E está correta porque descreve uma Lakehouse sobre armazenamento de objetos com formatos de tabela abertos, o que permite transações ACID e controle de esquema nos dados analíticos. Além disso, preserva os dados brutos na camada Bronze para ciência de dados e usa modelagem dimensional na camada Gold para atender ao BI com desempenho adequado.Pegadinha da questãoA confusão explorada foi tomar unificação arquitetural como se significasse colocar tudo em um único tipo de banco, ou supor que Data Lake puro ou desnormalização extrema resolveriam igualmente bem BI e IA.Dica para questões semelhantesQuando a questão exigir simultaneamente dados brutos para IA e consumo analítico otimizado para BI, procure arquitetura com camadas bruta e curada no mesmo ecossistema.Se houver baixa latência para BI com consultas complexas, descarte soluções que deixem joins e agregações diretamente sobre arquivos brutos como estratégia principal.Se o enunciado pedir evitar duplicação entre Data Warehouse e Data Lake, elimine propostas que mantenham separação física ou silos departamentais.Não trate 3FN, schema-on-read puro ou desnormalização extrema como solução universal; compare cada proposta com todos os requisitos ao mesmo tempo.

🚀 Mais performance?

🚀 Mais performance?

Uma corporação multinacional do setor de varejo está unifica...

Gabarito comentado

Gabarito: E

Clique para visualizar este gabarito

Comentários

Clique para visualizar este comentário

Resumos relacionados

SGBD: Conceitos Fundamentais e Aplicações em Concursos Públicos

Questões de assuntos semelhantes

Provas relacionadas