Pular para o conteúdo

Tema

Fundamentos

Folha de revisão · 3 temas · Engenharia de Dados

Feita para a véspera. Imprimir esta página tira o menu e as abas.

O que é Big Data

É a primeira pergunta de quase toda sabatina e serve de termômetro. Quem responde só 'muitos dados' entrega que decorou; quem separa o problema da ferramenta mostra que entende por que a arquitetura mudou.

Como cai: Todo problema com muitos dados é um problema de Big Data?

Erros comuns

  • Tratar Big Data como sinônimo de Hadoop ou Spark. Os Vs descrevem o problema; a ferramenta é a resposta, e ela muda com a década.
  • Achar que volume sozinho define Big Data. Um terabyte parado num arquivo é só um arquivo grande; o que quebra é volume com velocidade e variedade juntos.
  • Esquecer veracidade e valor. São os dois Vs que ligam a discussão técnica ao negócio, e é neles que a banca separa quem já trabalhou com dado sujo.
  • Usar arquitetura distribuída onde um Postgres bem indexado resolveria. Custo e complexidade sobem, e a banca pergunta justamente isso.

OLAP, OLTP e ETL

É o tema que separa quem entende arquitetura de quem só escreve SQL. A banca usa a pergunta do relatório no banco transacional para ver se você raciocina sobre lock, contenção e modelo, ou se responde só 'porque é lento'.

Como cai: Por que não fazer o relatório direto no banco transacional?

Erros comuns

  • Dizer que a diferença é só desempenho. Desempenho é consequência; a causa é propósito diferente, que leva a modelo diferente, carga diferente e garantia diferente.
  • Achar que OLAP significa obrigatoriamente cubo. Cubo foi a implementação dominante nos anos 2000; hoje OLAP é o tipo de carga, servida por warehouse colunar, lakehouse ou motor MPP.
  • Confundir normalizado com bom. Terceira forma normal serve para escrever com integridade; para ler agregado ela cobra dezenas de joins por consulta.
  • Tratar staging como se fosse camada de consumo. Staging é área de pouso, volátil, espelho da origem; quem consulta staging herda o modelo do sistema fonte e todos os defeitos dele.
  • Esquecer o grão da tabela fato. Sem definir a que corresponde uma linha, a soma duplica e ninguém descobre até o número chegar errado na diretoria.
  • Responder ETL como 'três scripts'. O que a banca quer ouvir é o processo: extração incremental, tratamento de qualidade, conformação de dimensão e carga idempotente.

Vocabulário

tabela fato
tabela que guarda os eventos mensuráveis do negócio, com métricas e chaves para as dimensões
tabela dimensão
tabela que descreve o contexto do evento e fornece filtros e agrupamentos

Data Centric e Data Driven

A banca usa este tema para ver se você enxerga além do pipeline. Engenheiro de dados que só fala de ferramenta não convence; quem liga arquitetura, governança e decisão mostra que entende para que o pipeline existe.

Como cai: Como você tornaria um time data-driven?

Erros comuns

  • Tratar os dois termos como sinônimo. Centric é arquitetura e propriedade do dado; driven é comportamento na hora de decidir. Dá para ser um sem o outro, e é aí que a banca aperta.
  • Achar que dashboard resolve. Painel sem métrica acordada, sem confiança no número e sem alguém com poder de decidir vira decoração cara.
  • Confundir data-driven com decidir só por número. Contexto, risco regulatório e restrição de negócio continuam valendo; data-driven é o dado entrar antes da decisão, não substituir julgamento.
  • Ignorar acesso. Se o analista espera duas semanas por um chamado para ver o dado, o time decide por intuição e chama de agilidade.
  • Usar o dado para justificar decisão já tomada. É o erro mais comum e o mais fácil de detectar: o número aparece depois da escolha, não antes.
  • Separar governança de cultura. Sem catálogo, dono e definição de métrica, cada área traz um número diferente para a mesma pergunta e a discussão morre no 'meu Excel diz outra coisa'.