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'.