• A

  A duplicidade em (i) é necessariamente um erro de qualidade de dados, pois a chave natural do falecido deve ser única; a correção é aplicar deduplicação por CPF na camada de consumo. Em (ii), a solução é tornar o job idempotente por meio de sobrescrita particionada ou merge por chave de negócio e timestamp de ingestão. Em (iii), a correção é normalizar o campo de partição (trim) e regravar o dado, pois partições com espaços não são podadas pelo mecanismo de consulta. Em (iv), a correção é adotar tabela de dimensão do tipo slowly changing dimension (SCD) tipo 2, preservando versões com datas de vigência.

• B

  Em (i), a coexistência de dois inventários para o mesmo CPF indica violação de integridade referencial e deve ser resolvida com a criação de uma chave substituta (surrogate key) na dimensão falecido, mantendo-se uma única linha por CPF. Em (ii), a duplicidade decorre da ausência de transação ACID no data lake e se corrige com o uso de formato de tabela transacional com controle de commit. Em (iii), o problema é de modelagem, pois o campo de partição deveria ser numérico; a correção é converter o ano para inteiro. Em (iv), a correção é criar uma tabela fato acumulativa que armazene apenas o último valor do imóvel, pois o histórico é responsabilidade do sistema de origem.

• C

  Em (i), a existência de dois inventários para o mesmo CPF é um caso legítimo de granularidade, pois a chave natural do inventário é composta por CPF e data de abertura, e não apenas pelo CPF; a deduplicação por CPF seria incorreta. Em (ii), a duplicidade no reprocessamento evidencia falta de idempotência; a correção adequada é implementar escrita idempotente com chave de negócio e controle de versão do lote, ou usar merge/upsert em tabela transacional. Em (iii), a ausência de poda de partição decorre de o valor da partição conter espaços à esquerda, impedindo o casamento com o predicado; a correção é sanitizar o valor antes da gravação e, se necessário, reprocessar. Em (iv), a preservação do histórico de valores exige modelagem de dimensão com versionamento (SCD tipo 2) ou tabela de histórico, não bastando a tabela fato com o último valor.

• D

  Em (i), a solução é aplicar uma regra de sobrevivência (survivorship) para eleger o inventário mais recente e descartar o mais antigo, pois dados de falecido devem ser únicos. Em (ii), a duplicidade é causada pela falta de particionamento por data de ingestão; a correção é particionar a tabela final por data de ingestão e sobrescrever a partição a cada execução. Em (iii), o problema é que o campo de partição foi gravado como string; a correção é sempre usar tipos numéricos em partições, pois strings nunca são podadas. Em (iv), a correção é criar uma dimensão do tipo SCD tipo 1, que sobrescreve o valor antigo pelo novo, preservando o histórico por meio de backups.

• E

  Em (i), a duplicidade de CPF é um falso positivo, pois a chave primária da tabela fato deve ser o CPF do falecido; a correção é remover a constraint de unicidade. Em (ii), a duplicidade no reprocessamento é inevitável em arquiteturas de data lake e deve ser tratada apenas na camada de BI com DISTINCT. Em (iii), a falta de poda de partição é causada pelo uso de Parquet, que não suporta poda; a correção é migrar para CSV. Em (iv), a preservação do histórico é obtida com o uso de tabela fato sem atualização, pois toda carga deve ser append-only, sem necessidade de SCD.

Atalhos: A–E marca · Shift+letra corta · Enter próxima

Selecione uma alternativa pra criar sua conta e salvar o progresso.