Guia de entrevista para engenheiro de dados

Estrutura: Window function com ordenação determinística

Eu usaria uma window function para numerar as linhas dentro de cada partição de event_id, ordenando de forma decrescente pela coluna de atualização mais confiável, como ingestion_timestamp ou updated_at. Se houver chance de empate, acrescento um critério de desempate determinístico, como source_sequence_number ou raw_file_name. O padrão da query é: selecionar todas as linhas, calcular row_number() over(partition by event_id order by ingestion_timestamp desc, source_sequence_number desc) e depois filtrar onde row_number = 1. O detalhe que mais importa na entrevista é o determinismo. Se dois registros tiverem o mesmo timestamp e não houver desempate, o resultado pode variar entre execuções. Também vale esclarecer se "mais recente" significa o último horário de ingestão, o último horário do evento ou a última atualização na origem. Em produção, eu monitoraria a taxa de duplicidade, os eventos que chegam atrasados, a contagem de event_id nulos e se a deduplicação altera métricas downstream de forma inesperada.

Estrutura: Filtrar eventos de atividade -> normalizar a data -> agrupar por data e usuário

Primeiro, eu definiria o que é um usuário ativo. Normalmente, nem todo evento deve contar. Visualizações de página, eventos de bots, atualizações em segundo plano e usuários internos podem precisar ser excluídos. Eu escolheria eventos significativos, como session_start, purchase, message_sent ou feature_used, dependendo do produto. A transformação filtra os eventos elegíveis, converte os timestamps para o fuso horário do negócio, agrupa por activity_date e user_id e gera uma linha por usuário ativo por dia. Se a tabela final for um agregado, conto usuários distintos por dia. Se for um modelo de consumo, guardo a data, user_id, plataforma, país e first_active_timestamp. Os detalhes importantes para produção incluem fuso horário, eventos que chegam atrasados, filtro de bots e testes, usuários excluídos, eventos duplicados e particionamento por activity_date. Em cargas incrementais, eu reprocessaria as partições recentes para capturar eventos atrasados, e não só o dia corrente. Uma resposta forte também inclui validação: comparar o DAU com a contagem de eventos na origem, monitorar a variação de um dia para o outro e checar a consistência por segmento.

Estrutura: Escopo -> plano de execução -> crescimento dos dados -> joins -> partições -> mudanças recentes

Primeiro, eu verificaria se o problema é específico da query, do warehouse inteiro ou da infraestrutura. Se muitas queries ficaram lentas, pode ser capacidade do cluster, carga no warehouse ou degradação do serviço. Se foi só uma, eu analisaria a query e os dados. Depois, olharia as mudanças recentes: crescimento das tabelas, mudanças de schema, joins novos, filtros alterados, perda do partition pruning, estatísticas desatualizadas, skew de dados, joins que explodem o número de linhas ou novas operações de distinct/order by. Se disponível, revisaria o plano de execução. As causas mais comuns são join na granularidade errada, falta de filtro de data, joins muitos-para-muitos, leitura de todas as partições, window functions ineficientes, shuffles grandes ou funções aplicadas sobre colunas de partição que impedem o pruning. As correções podem incluir filtrar mais cedo, pré-agregar, adicionar filtros de partição, usar clustering/ordenação, materializar modelos intermediários, atualizar estatísticas, selecionar menos colunas ou corrigir a lógica do join. Eu também adicionaria monitoramento de tempo de execução, bytes lidos, contagem de linhas e custo.

Estrutura: Processos de negócio -> fatos -> dimensões -> granularidade -> métricas

Eu começaria pelos processos de negócio centrais: navegação, carrinho, pedidos, pagamentos, envios, devoluções, reembolsos, estoque e atribuição de marketing. Cada processo pode virar uma tabela fato ou um modelo de eventos, dependendo do uso. As principais tabelas fato incluem fact_orders, com uma linha por pedido, fact_order_items, com uma linha por produto em cada pedido, fact_payments, fact_refunds, fact_shipments e fact_inventory_snapshot. As dimensões incluem dim_customer, dim_product, dim_date, dim_store ou dim_warehouse (centro de distribuição), dim_channel e dim_campaign. Eu declararia a granularidade de forma explícita. Receita por categoria de produto normalmente deve vir da granularidade de item do pedido, e não do pedido. Métricas de ciclo de vida do cliente podem usar a granularidade de cliente ou de assinatura. Análises de estoque podem exigir snapshots diários. Pontos de atenção na modelagem: atributos de cliente ou produto que mudam lentamente, reembolsos e cancelamentos, descontos no nível do pedido ou do item, moeda, impostos, frete, compras sem cadastro e dados que chegam atrasados. Eu definiria as métricas oficiais e construiria modelos semânticos ou data marts para finanças, marketing, produto e operações. A validação inclui conciliar a receita com o financeiro, a contagem de pedidos com os sistemas transacionais, o total de reembolsos com os pagamentos e o estoque com os sistemas de armazém.

Estrutura: Tipo 1 ou Tipo 2 conforme a necessidade de histórico

A abordagem certa depende de a precisão histórica importar ou não. O Tipo 1 sobrescreve os valores antigos, o que é simples e útil quando só o valor mais recente interessa. O Tipo 2 preserva o histórico criando uma nova linha na dimensão a cada mudança de atributo, normalmente com effective_start_date, effective_end_date, current_flag e uma surrogate key. Exemplo: se um cliente muda da região Oeste para a Leste, o Tipo 1 atualizaria a linha do cliente para Leste. Os relatórios históricos passariam a mostrar a receita antiga sob Leste, o que pode estar errado. O Tipo 2 manteria a linha antiga de Oeste e criaria uma nova linha de Leste, permitindo que os fatos se conectem à versão correta no momento do evento. O Tipo 2 traz mais complexidade: surrogate keys, joins por intervalo de datas, fatos que chegam atrasados, relatórios com visão atual versus histórica e tabelas de dimensão maiores. Use-o quando os relatórios precisarem refletir os atributos como eram no momento do evento. Uma resposta forte explica a necessidade de negócio antes de escolher o tipo de SCD.

Estrutura: Governança e flexibilidade versus simplicidade e performance das queries

Um star schema separa fatos e dimensões. Ele é útil quando você precisa de dimensões reutilizáveis, métricas consistentes, governança, granularidade clara e flexibilidade de análise. Reduz duplicação e facilita a gestão de mudanças nas dimensões. Uma tabela larga desnormalizada pode ser útil em análises específicas e muito usadas, features de machine learning ou dashboards em que simplicidade e performance das queries importam. Ela reduz a complexidade de joins para quem consome, mas pode duplicar dados e criar risco de governança se várias tabelas largas definirem métricas de jeitos diferentes. Na prática, eu normalmente manteria fatos e dimensões canônicos e bem cuidados e, a partir deles, publicaria data marts curados ou tabelas largas para casos de uso específicos. A base do warehouse precisa continuar confiável, enquanto os modelos downstream se otimizam para as necessidades de cada usuário. A decisão depende de escala, consumidores, comportamento da ferramenta de BI, custo, latência e da frequência com que as definições de negócio mudam.

Estrutura: Extrair -> gravar o bruto -> transformar -> validar -> publicar -> monitorar

Primeiro eu esclareceria os requisitos: atualidade dos dados, volume de pedidos, atraso aceitável, limites de carga no banco de origem, consumidores downstream e se existem correções retroativas. Um desenho simples: extrair os pedidos de forma incremental usando updated_at ou CDC, gravar os dados brutos em object storage ou em uma tabela raw do warehouse, transformar em tabelas de staging e então publicar fatos modelados como fact_orders e fact_order_items. A orquestração pode ser feita com Airflow, Dagster, dbt Cloud ou outra ferramenta gerenciada de workflows. O pipeline deve ser idempotente. Se for reexecutado para uma data ou lote, ele deve substituir ou fazer merge dos dados de forma determinística, em vez de anexar duplicatas. Use watermarks com cuidado e reprocesse uma janela retroativa para capturar atualizações atrasadas. Checagens de validação: contagem de linhas, chaves primárias nulas, IDs de pedido duplicados, totais de receita, distribuição de status, atualidade e conciliação com a origem. O monitoramento deve alertar sobre falhas, variações incomuns de volume, taxas altas de duplicidade ou atraso nos dados. Documente os responsáveis e as dependências downstream.

Estrutura: Mesma entrada e reexecução geram a mesma saída

Um pipeline idempotente pode rodar várias vezes com a mesma entrada e produzir a mesma saída correta, sem duplicatas nem efeitos colaterais indesejados. Isso importa porque pipelines falham, são reexecutados e exigem backfills. Exemplo: um pipeline não idempotente anexa os pedidos de ontem toda vez que roda. Se ele for reexecutado depois de uma falha, a receita dobra. Uma versão idempotente apagaria e substituiria a partição de destino, faria merge pela chave primária ou gravaria em uma tabela temporária e depois faria uma troca atômica. Idempotência exige chaves claras, estratégia de particionamento, transformações determinísticas e cuidado com efeitos colaterais. É um dos conceitos mais importantes da engenharia de dados em produção, porque a capacidade de recuperação depende dela.

Estrutura: Detectar -> classificar -> proteger -> comunicar -> migrar

Primeiro, eu detectaria mudanças de schema automaticamente, com schema registry, checagens de metadados, testes de contrato ou validação na ingestão. Depois, classificaria a mudança: coluna adicionada, coluna removida, coluna renomeada, mudança de tipo, mudança de nulabilidade ou mudança semântica. Colunas novas e anuláveis costumam ser seguras. Colunas removidas, campos renomeados e mudanças de tipo podem quebrar transformações e dashboards downstream. Mudanças semânticas são especialmente perigosas, porque o schema pode parecer válido enquanto o significado muda. Eu protegeria o pipeline preservando os dados brutos, com checagens de compatibilidade, alertas e contratos para as fontes críticas. Em mudanças que quebram compatibilidade, eu alinharia com os responsáveis pela fonte, atualizaria as transformações, faria backfill se necessário e comunicaria o impacto downstream. Uma resposta madura inclui contratos de dados, versionamento, linhagem, testes e responsáveis bem definidos, para que mudanças de schema não corrompam o analytics silenciosamente.

Estrutura: Latência da decisão versus complexidade

Eu escolheria streaming quando a baixa latência gera valor real. Exemplos: detecção de fraude, alertas operacionais, personalização em tempo real, atualização de estoque, métricas de experimentos ao vivo e funcionalidades do produto voltadas ao usuário que precisam de eventos recentes. Batch costuma ser melhor para relatórios diários, análises históricas, conciliação financeira e transformações em que uma latência de horas é aceitável. Batch é mais simples de operar, mais fácil de reprocessar e muitas vezes mais barato. A decisão deve considerar os requisitos de atualidade, o volume de eventos, a necessidade de ordenação, o processamento com estado, a tolerância a falhas, a experiência do time, o custo e os consumidores downstream. Streaming não é automaticamente melhor. Ele traz complexidade com duplicatas, eventos atrasados, checkpoints, evolução de schema e monitoramento. Uma resposta forte diz: use a arquitetura mais simples que atenda ao requisito de negócio. Se o negócio só precisa de métricas diárias, não construa um sistema de streaming por status.

Estrutura: Eventos -> stream -> enriquecimento -> regras/modelo -> ação -> armazenamento -> monitoramento

Eu começaria pelos requisitos: volume de eventos, meta de latência, tipo de decisão antifraude, tolerância a falsos positivos e se as decisões bloqueiam transações ou disparam uma revisão. Um desenho possível: os eventos de pagamento são publicados no Kafka ou no Kinesis. Um processador de stream consome os eventos, valida o schema, deduplica por event_id, enriquece com features de usuário, dispositivo, estabelecimento e velocidade histórica e então aplica regras ou um modelo. Eventos de alto risco acionam um serviço de decisão, uma fila de revisão manual ou uma autenticação adicional (step-up). Os eventos brutos e as decisões são gravados em armazenamento durável para auditoria e treinamento de modelos. Pontos-chave de engenharia: eventos duplicados, eventos fora de ordem, atualidade das features, tamanho do state store, processamento exactly-once ou effectively-once, backpressure, dead-letter queues, replay, monitoramento de latência e versionamento de modelos e regras. Qualidade de dados e governança importam porque as decisões antifraude afetam clientes. Registre os códigos de motivo, monitore as taxas de falsos positivos e permita rollback se uma regra ou um modelo se comportar mal.

Estrutura: Redistribuição de dados entre partições

Um shuffle acontece quando o Spark precisa redistribuir dados entre partições, geralmente em operações como groupBy, join, distinct, orderBy e repartition. Ele é caro porque os dados precisam trafegar pela rede, ser serializados e desserializados, gravados em disco e coordenados entre os executors. Shuffles costumam dominar o tempo de execução do job e podem causar falhas quando há skew nos dados ou quando os dados intermediários ficam grandes demais. Uma única chave muito concentrada pode mandar dados demais para uma partição, gerando tasks retardatárias (stragglers) ou erros de falta de memória. Para reduzir o custo do shuffle: filtrar cedo, selecionar só as colunas necessárias, pré-agregar, usar broadcast join para tabelas pequenas, particionar pelas chaves de join, aplicar salting em chaves com skew, evitar distinct/orderBy desnecessários e ajustar o número de partições. Uma resposta forte liga o conceito ao debugging na prática: analisar a Spark UI, os stages, o shuffle read/write, o skew, o spill, a duração das tasks e a memória dos executors.

Estrutura: Identificar o stage -> reduzir os dados -> corrigir o skew -> ajustar partições -> evitar operações problemáticas

Primeiro, eu identificaria onde a falha acontece usando a Spark UI ou os logs: qual stage, operação, partição e executor. Um OOM pode vir de skew, joins grandes, operações de collect, partições grandes demais, UDFs ineficientes ou cache de dados demais. Depois, reduziria os dados cedo: filtrar linhas, selecionar só as colunas necessárias, aplicar predicate pushdown e evitar ler partições desnecessárias. Eu revisaria os joins: se uma tabela é pequena, uso broadcast join. Se uma chave tem skew, uso salting ou separo as chaves mais pesadas. Se as partições estão grandes demais, aumento o número de partições; se há muitas partições minúsculas, faço coalesce de forma adequada. Evite collect() em grandes volumes, evite UDFs em Python quando funções nativas resolvem e use cache só quando o dado for reutilizado e houver memória disponível. Na gravação, evite muitos arquivos pequenos e escolha formatos colunares como Parquet com compressão. Se for preciso ajustar recursos, eu mexeria em memória dos executors, cores, shuffle partitions e memory overhead, mas sem depender só de clusters maiores. Corrigir o formato dos dados e o plano de execução costuma ser uma solução mais duradoura.

Estrutura: Armazenamento colunar, schema, compressão, predicate pushdown

Parquet é um formato de arquivo colunar, o que é eficiente para analytics porque as queries costumam ler apenas parte das colunas. Ele suporta compressão, codifica os tipos de dados, armazena o schema e permite predicate pushdown e column pruning em muitos engines. CSV é texto puro orientado a linhas. É legível e portátil, mas não tem tipagem forte, pode ser maior, é mais lento de ler, é mais sujeito a erros com delimitadores e escape e não consegue pular colunas irrelevantes com eficiência. Em data lakes e warehouses, o Parquet geralmente reduz o custo de armazenamento e melhora a performance das queries. O CSV ainda pode ser útil para exportações simples, arquivos pequenos ou interoperabilidade, mas não é o ideal como formato principal de armazenamento para analytics.

Estrutura: Atualidade -> completude -> unicidade -> validade -> conciliação

Em um pipeline de receita, eu colocaria checagens de atualidade, contagem de linhas, chaves primárias nulas, IDs de transação duplicados, status válidos, moedas válidas, valores não negativos quando aplicável, intervalos de datas aceitos e integridade referencial entre pedidos, pagamentos, reembolsos e clientes. Também adicionaria checagens de conciliação: receita total comparada com os sistemas de pagamento de origem, com os relatórios financeiros ou com a versão anterior do pipeline. Monitoraria as variações de um dia para o outro e de uma semana para a outra com limites definidos, levando em conta a sazonalidade e eventos conhecidos. As regras de negócio importam: pedidos cancelados não devem contar como receita, reembolsos devem reduzir a receita líquida, transações de teste devem ser excluídas e a conversão de moeda deve usar a taxa correta. Os alertas precisam ser acionáveis, direcionados a um responsável e trazer contexto: checagem que falhou, tabela afetada, severidade, dependências downstream e o runbook sugerido. Alertas ruidosos demais acabam sendo ignorados.

Estrutura: Avaliar o impacto -> comparar versões -> analisar a linhagem -> mitigar -> causa raiz

Primeiro, eu avaliaria o impacto: qual dashboard, métrica, usuários, período e decisões foram afetados. E verificaria se o número está errado ou se o deploy corrigiu um problema anterior. Depois, compararia a nova saída com a versão anterior por tabela, partição, contagem de linhas, contagem de distintos, totais das métricas e segmentos principais. Usaria a linhagem para identificar mudanças upstream e analisaria as mudanças de código, de schema, filtros, joins, deduplicação e lógica de datas. Se a métrica estiver errada e houver usuários de negócio afetados, eu mitigaria rápido: fazer rollback da transformação, restaurar a versão anterior da tabela, desativar o dashboard ou adicionar um aviso. Em seguida, faria a análise de causa raiz e o backfill dos dados corrigidos, se necessário. A comunicação importa. Eu avisaria os stakeholders sobre o que mudou, o que foi afetado, o nível de confiança, o prazo esperado para a correção e se decisões passadas precisam ser revistas.

Estrutura: Instrumentação -> ingestão -> armazenamento -> processamento -> modelagem -> consumo -> governança

Eu começaria pelos requisitos: volume de eventos, latência, consumidores, retenção, evolução de schema, privacidade e confiabilidade. Eventos de product analytics podem alimentar dashboards, experimentos, personalização e features de machine learning. Os clientes emitem eventos por um SDK com event_name, user_id, session_id, timestamp, propriedades, versão do app, plataforma e ID anônimo. Os eventos vão para uma API de ingestão ou um coletor de eventos e depois para um stream durável como Kafka/Kinesis/Pub/Sub. Os eventos brutos são gravados em object storage para replay e em um warehouse ou lakehouse para analytics. O processamento inclui validação de schema, deduplicação, filtro de bots e de tráfego interno, sessionização, resolução de identidade e transformação em tabelas modeladas como fact_events, fact_sessions, dim_users e data marts específicos de cada produto. Caminhos batch e streaming podem coexistir, dependendo da atualidade necessária. Qualidade e governança: contratos de eventos, schema registry, tratamento de dados pessoais (PII), respeito ao consentimento, linhagem, responsáveis definidos, checagens de atualidade, alertas de anomalia de volume e documentação. As camadas de consumo incluem dashboards de BI, análise de experimentos, reverse ETL e feature stores. Os trade-offs incluem o custo de tempo real versus batch, schema rígido versus flexível, retenção dos eventos brutos, complexidade de identidade e quanta lógica fica na ingestão versus na transformação.

Estrutura: Consistência offline/online -> definição das features -> atualidade -> serving -> monitoramento

Um feature store deve oferecer features reutilizáveis e confiáveis para treinamento e serving. Os requisitos incluem definições de features, correção point-in-time, dados de treinamento offline, serving online com baixa latência, atualidade, controle de acesso e monitoramento. As features offline podem ficar em um warehouse ou lakehouse, particionadas por data e entidade. As features online podem ser servidas por um key-value store de baixa latência. Um registro de features guarda os metadados: nome da feature, responsável, chave da entidade, lógica de transformação, SLA de atualidade, tabelas de origem e descrição. A correção point-in-time é crítica. Os dados de treinamento precisam usar os valores de features disponíveis no momento da predição, e não valores futuros. Para garantir consistência entre online e offline, a mesma lógica de transformação deve ser reaproveitada sempre que possível, ou testada a fundo se houver pipelines separados. O monitoramento deve cobrir atualidade das features, taxas de nulos, drift de distribuição, latência do serving online, training-serving skew e impacto nos modelos downstream. A governança inclui controles de PII, linhagem, descontinuação de features e responsáveis definidos.

Estrutura: Impacto -> triagem -> mitigação -> causa raiz -> prevenção

Escolha um incidente com impacto real: dados faltando, métricas erradas, pipeline atrasado, registros duplicados, dashboard quebrado, problema em features de modelo ou impacto no produto downstream. Comece contando quem foi afetado e por que isso importava. Depois, explique seu processo de triagem: logs, status da orquestração, atualidade da origem, deploys recentes, mudanças de schema, contagem de linhas, partições, linhagem e dependências downstream. Descreva como você mitigou o problema: reexecução, rollback, correção pontual, backfill ou aviso aos stakeholders. A resposta mais forte inclui prevenção. Você adicionou checagens de qualidade de dados, alertas, retentativas, contratos de schema, gravações idempotentes, runbooks, linhagem ou controles melhores de deploy? Evite culpar os times upstream. Mostre que você assumiu a responsabilidade pelo sistema e pela comunicação. Feche com o que você aprendeu sobre confiabilidade e como seu processo mudou depois disso.

Estrutura: Esclarecer -> reproduzir -> rastrear a linhagem -> resolver -> documentar

Primeiro, eu esclareço exatamente o que parece errado: métrica, tabela, período, dashboard, filtro, valor esperado e o motivo de negócio. “Os dados estão errados” precisa virar um problema reproduzível. Depois, comparo a query ou o dashboard do analista com as tabelas de origem e as definições do modelo. Verifico granularidade, filtros, joins, fusos horários, atualidade, definições de métricas e mudanças recentes, e uso a linhagem para rastrear as dependências upstream. Se os dados estiverem errados, corrijo e comunico o impacto. Se estiverem corretos, mas a definição for diferente do esperado, alinho a definição da métrica e a documentação. Se a dúvida continuar, explico o que já se sabe, o que está sendo verificado e quando vou dar retorno. O relacionamento importa. Analistas são clientes da plataforma de dados, e a confiança se constrói com respostas rápidas, claras e baseadas em evidências.

Estrutura: Impacto -> confiabilidade -> urgência -> dependências -> alavancagem

Eu priorizo com base em impacto no negócio, risco de confiabilidade, urgência, dependências downstream e alavancagem. Um pipeline de receita quebrado ou um problema de compliance normalmente passa na frente de um modelo de dashboard que seria só um "nice to have". Uma melhoria de plataforma pode passar na frente de um pedido pontual se destravar vários times. Também separo incidentes urgentes, trabalho estratégico de plataforma, pedidos de stakeholders, dívida técnica e trabalho operacional repetitivo. Se o time só atende tickets, a confiabilidade e a qualidade da plataforma se deterioram. Se o time só constrói abstrações de plataforma, as áreas de negócio podem ficar travadas. Um bom processo de priorização inclui responsáveis definidos, SLAs, níveis de severidade, alinhamento com o roadmap e trade-offs transparentes. Eu comunicaria o que está sendo feito, o que foi adiado, por quê e qual risco isso cria.