Processamento de dados

Processamento batch e stream

É a pergunta de cenário mais frequente da sabatina: dado um caso do banco, batch ou stream? Quem responde 'stream porque é tempo real' entrega que nunca operou um pipeline; quem coloca latência exigida, custo e complexidade lado a lado mostra que já tomou essa decisão.

Como cai: Detecção de fraude em cartão: batch ou stream? Quais os trade-offs?

Erros comuns

• ×Dizer que stream é sempre melhor porque é tempo real. Stream cobra cluster ligado 24 por 7, estado para manter, plantão e reprocessamento difícil. Se a decisão só é tomada no dia seguinte, você pagou por latência que ninguém consome.
• ×Confundir micro-batch com stream evento a evento. Spark Structured Streaming agrupa a chegada em micro-lotes de segundos; Flink processa registro a registro. Isso muda o piso de latência que você pode prometer para o negócio.
• ×Ignorar a diferença entre event time e processing time. Agregar pelo horário de chegada faz a mesma janela dar resultado diferente a cada execução, e em banco isso vira número de fechamento que não bate duas vezes.
• ×Prometer exactly-once como se fosse uma flag. Ponta a ponta ela exige checkpoint, estado durável e destino idempotente ou transacional. Sem controlar o destino, o que você tem é at-least-once com deduplicação.
• ×Esquecer o dado atrasado. Sem watermark o estado cresce sem limite; com watermark curto demais você descarta transação legítima que chegou fora de ordem.
• ×Tratar batch como coisa antiga. Fechamento contábil, reporte regulatório e treino de modelo continuam em batch por bons motivos: lógica simples e resultado reproduzível.

Vocabulário

event time

— O momento em que o fato aconteceu: a hora da compra registrada pela maquininha.

processing time

— O momento em que o motor viu o evento.

ETL e ELT

É a pergunta que separa quem sabe a sigla de quem sabe decidir. A banca não quer ouvir 'no ELT o T vem depois'; quer ouvir por que o mercado migrou, o que se ganha guardando o bruto e em que situação, num banco, você ainda transforma antes de aterrissar.

Como cai: Vocês vão usar ELT no Lakehouse. Quais os riscos disso?

Erros comuns

• ×Resumir a diferença a 'a ordem das letras'. A pergunta real é onde a computação da transformação acontece e o que fica gravado no destino, porque é isso que muda custo, governança e capacidade de reprocessar.
• ×Dizer que ELT é sempre melhor porque é moderno. Sem contrato e sem catálogo, ELT vira despejo de tabela crua que ninguém entende, e o lake vira pântano.
• ×Esquecer que ELT joga o custo para o destino. Transformação pesada no warehouse aparece na fatura de computação todo mês, e não em um servidor de ETL comprado uma vez.
• ×Ignorar LGPD ao defender ELT. Carregar CPF, dado de saúde ou biometria cru na zona bronze cria uma cópia de dado sensível fora do perímetro de controle da origem.
• ×Achar que guardar o bruto é bagunça. O bruto é o que permite recalcular seis anos de indicador quando a regra de negócio muda; sem ele, você depende da origem ainda ter o histórico.
• ×Tratar ETL como legado. Origem que só pode ser lida uma vez, contrato rígido com o consumidor e mascaramento obrigatório antes do pouso continuam pedindo transformação em trânsito.

Particionamento de dados

É onde a banca testa julgamento técnico com número. Todo mundo sabe dizer que particionamento acelera consulta; poucos sabem explicar cardinalidade, small files e hot partition, e menos ainda percebem que particionamento em banco relacional e em data lake são mecanismos diferentes com o mesmo nome.

Como cai: Como você particionaria a tabela de transações de cartão?

Erros comuns

• ×Particionar por uma chave de altíssima cardinalidade, como CPF ou id da transação. Cada partição vira um arquivo minúsculo, e o custo de abrir milhões de arquivos supera qualquer ganho de leitura.
• ×Particionar por uma chave que a consulta não filtra. Se ninguém escreve WHERE naquela coluna, não existe partition pruning e você só criou complexidade.
• ×Ignorar a distribuição real dos valores. Particionar por agência ou por bandeira quando 60 por cento do volume está em um único valor cria hot partition: uma task carrega o job inteiro.
• ×Confundir partição de tabela relacional com pasta no data lake. No relacional é uma estrutura interna do banco com índices e estatísticas; no lake é literalmente um diretório no caminho do arquivo.
• ×Tratar bucketing como sinônimo de particionamento. Bucket distribui por hash em um número fixo de arquivos e serve para join e agregação por chave; partição fisicamente separa e serve para pruning.
• ×Particionar tabela pequena. Abaixo de alguns gigabytes, particionar costuma piorar: você cria arquivos pequenos e sobrecarrega o metastore sem ganhar leitura.

Vocabulário

partition pruning

— Descarte de partições inteiras antes de abrir qualquer arquivo, com base no filtro da consulta.