Perguntas frequentes
Sou Lukas Rozado, engenheiro de dados. Aqui estão respostas diretas sobre o meu trabalho e sobre os problemas técnicos que os cases publicados neste site resolvem: planilha sem chave primária estável, API sem filtro de delta, cota compartilhada entre chaves, offset drift de paginação e completude de histórico on-chain. Cada resposta vale por si só e aponta para o case onde a decisão foi tomada.
Sobre o trabalho
Que tipo de problema de dados o Lukas Rozado resolve?
Sou engenheiro de dados e trabalho em ingestão, reconciliação e integração de dados financeiros e operacionais críticos. Os cases publicados cobrem data lake de criptoativos com auditoria contínua, plataforma unificada de ledger bancário e PIX, reconciliação de mesa OTC, consolidação de documento fiscal e integração multi-blockchain. O padrão comum entre eles é a fonte hostil: API sem filtro de delta, planilha sem chave primária, paginação que perde registro e cota de API compartilhada entre todas as chaves.
Com quais bancos de dados, linguagens e nuvens o Lukas Rozado trabalha?
Uso Python e PostgreSQL em praticamente todos os cases publicados, com SQL e APIs REST por cima. Meu portfólio se posiciona em Azure e AWS, e os cases detalham Azure na prática: Azure Key Vault para isolar credencial por conta e Azure Active Directory para autenticação corporativa entre sistemas, como no pipeline de liquidação financeira multibancos. Fora do núcleo financeiro, também trabalho com machine learning em scikit-learn e web scraping com BeautifulSoup, Selenium e pandas.
O Lukas Rozado constrói pipeline em tempo real ou só batch?
Construo os dois, e normalmente os combino no mesmo sistema. A plataforma unificada de ledger bancário roda de minuto em minuto, de forma persistente, enquanto o pipeline de reconciliação financeira usa um modelo híbrido: uma via de API quase em tempo real guiada por high-water mark e uma via diária em CSV que recupera a lacuna que a API deixou passar. Pipeline puramente batch aparece onde a fonte é batch por natureza, como a planilha diária da mesa OTC e a consolidação mensal de documento fiscal.
Perguntas técnicas
Como reconciliar uma planilha que não tem chave primária estável?
Sem chave primária estável, o caminho é parar de tentar identificar a linha pela origem e passar a recarregar o conjunto inteiro. No case da mesa OTC, a tabela de fatos é truncada e recarregada por completo a cada execução via protocolo COPY do PostgreSQL, e cada transação recebe um fingerprint SHA-256 sobre a assinatura lógica da linha combinada com um contador de ocorrência (nonce), o que preserva splits legítimos idênticos em vez de colapsá-los como duplicata acidental. Uma camada de blindagem de schema extrai estritamente a lista fechada de colunas financeiras esperadas, então coluna nova criada pela área de negócio não derruba a ingestão do dia seguinte.
Quando usar Full Replace em vez de upsert incremental?
Full Replace faz sentido quando a origem não oferece chave primária estável e as linhas podem ser inseridas, apagadas e reordenadas sem rastreabilidade. Nesse cenário, o upsert incremental vira fonte de registro fantasma: a linha some na origem e continua viva no banco para sempre. Truncar e recarregar por inteiro garante que o banco seja espelho exato do estado atual da fonte, ao custo de reprocessar todo o volume a cada execução, o que só é viável quando o conjunto cabe numa janela de carga aceitável. Quando existe chave confiável, o padrão usado nos demais cases é o oposto: COPY para tabela temporária e depois UPSERT.
Como capturar só o que é novo numa API que não tem filtro de data?
A técnica aplicada é early-exit por marca d'água: a leitura começa da página mais recente e para sozinha assim que N páginas seguidas caem inteiramente numa data já coberta antes. Isso evita os dois extremos ruins, reprocessar o histórico inteiro toda execução e parar cedo demais perdendo registro. Para o caso da transação que muda de status depois de já capturada, um auditor separado e mais barato lê a API só a partir do registro pendente mais antigo e faz UPSERT no que mudou, sem revarrer o histórico completo. As duas peças estão na plataforma unificada de ledger e no integrador de custódia institucional.
Como ingerir de uma API com cota compartilhada sem tomar bloqueio de IP?
O erro comum é estimar o consumo contando chamadas do lado do cliente. Na arquitetura do data lake de criptoativos, o rate limiter lê em cada resposta HTTP o header oficial de cota já consumida que o próprio provedor devolve, e mantém esse estado compartilhado entre processos, respeitando um teto único por minuto em vez de um teto por chave. Um carrossel de prioridade dá vez às contas com atividade recente e empurra as inativas para ciclos mais espaçados, sem gastar cota com quem não mudou. Essa arquitetura eliminou o padrão de bloqueio de IP que existia antes dela.
O que fazer quando a paginação da API perde ou duplica registro?
Quando a fonte sofre offset drift na paginação, registro some ou duplica sem que a API acuse nada, e nenhuma checagem feita apenas contra a própria API detecta isso. A solução aplicada no pipeline de reconciliação financeira foi uma segunda via independente: uma rotina diária baixa o relatório consolidado em CSV e roda anti-join contra o banco, preenchendo exatamente a lacuna que a via de API deixou passar. O checkpoint fica gravado por página, não por dia, então uma falha retoma do ponto exato de interrupção.
Como garantir que o histórico on-chain gravado no banco está completo?
Contagem de linha não prova completude, por isso o integrador multi-chain fecha com um invariante contábil: compara o supply total do token lido direto do contrato contra o supply líquido que o PostgreSQL calcula somando mint e subtraindo burn. Antes disso, um motor de auto-reconciliação varre o histórico em lotes e compara a contagem de eventos on-chain com a contagem no banco, faixa por faixa; quando diverge, apaga o lote inteiro e re-extrai do zero. A extração lê o nó direto por RPC crua, com eth_getLogs filtrado por tópico de evento, sem depender de indexador de terceiro.
Como carregar milhões de linhas no PostgreSQL sem travar a escrita em produção?
O padrão usado nos cases é COPY nativo para uma tabela temporária, seguido de UPSERT na tabela final, com deduplicação em memória por chave primária antes de cada lote. Os tamanhos de lote publicados vão de 5 mil registros por descarga na plataforma de ledger até 50 mil no pipeline de reconciliação financeira. Índice novo nasce com CONCURRENTLY para não bloquear escrita em produção, e o backfill histórico roda em processo separado do incremental, para não disputar lock nem sobrescrever o checkpoint da ingestão que já está no ar.
Por que um pipeline pode aparecer verde no monitoramento estando quebrado?
Um pipeline aparece verde quando o sinal de saúde vem do mesmo caminho que ele deveria auditar. No caso que documentei nos escritos do portfólio, o painel ficou verde por 14,71 dias enquanto o serving estava parado, e piorar o sistema chegava a fortalecer o verde, porque o monitor media a própria execução e não o resultado dela. A correção é medir o efeito no destino, ou seja, dado gravado, contagem reconciliada e invariante fechado, em vez de medir que o job terminou sem exceção.
Como falar com o Lukas Rozado sobre um projeto de dados?
Pelo formulário da página de contato do site, por email ou por LinkedIn. A página de contato informa resposta em até 2 dias úteis. Também publico a newsletter Dado Bruto no LinkedIn, com casos de engenharia de dados.
Sua pergunta não está aqui? Descreva o problema de dados que você tem hoje e eu respondo com o caminho técnico.
Falar sobre seu caso