Quando o dado financeiro não fecha

O payload bruto fica gravado, sempre

Coluna tipada é conveniência montada por cima do dado, nunca substituta dele. O que muda de um projeto para outro é o formato de armazenamento, JSONB no banco, arquivo em bucket ou Parquet particionado, e nunca a regra: a camada bruta vem antes de qualquer transformação e o modelo Medallion se apoia nela. No data lake de criptoativos, uma camada Bronze obrigatória guarda a resposta original em JSONB antes de qualquer transformação, e é ela que alimenta o modelo Medallion completo. O teste é simples: se responder a uma pergunta nova exige ligar de volta no provedor por um dado que ele já mandou uma vez, a camada bruta está errada. Consertar a camada bruta é mais barato que queimar cota de API para recuperar o que já esteve em casa.

Reconciliar contra a fonte, não contra o próprio pipeline

Contagem de linha não prova completude, e checagem que o pipeline faz contra si mesmo só confirma o que ele já acreditava. No integrador multi-blockchain, o fechamento é um invariante contábil: o supply total 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, compara evento on-chain contra banco faixa por faixa e, quando diverge, apaga o lote inteiro e re-extrai do zero.

Falhar alto em vez de entregar verde falso

Monitor que mede a própria execução, e não o resultado dela, mente com confiança. Documentei um caso em que o painel ficou verde por 14,71 dias com o serving parado, e piorar o sistema chegava a reforçar o verde. A correção é medir o efeito no destino: dado gravado, contagem reconciliada, invariante fechado. Um alerta ruidoso é caro; um verde falso é invisível, e a diferença entre os dois aparece no fechamento do mês.

Assumir que a origem é hostil

A fonte não coopera, e projetar como se ela cooperasse é adiar o incidente. Na mesa OTC, a planilha não tem chave primária estável, então a carga é Full Replace com fingerprint SHA-256 mais contador de ocorrência, uma blindagem de schema ignora coluna nova criada sem aviso, e nome de contraparte digitado à mão passa por cascata de alias, match exato e fuzzy matching com limiar de 92% de similaridade. No pipeline de reconciliação financeira, contra offset drift de paginação, uma segunda via diária em CSV roda anti-join no banco e preenche exatamente a lacuna que a API jamais mostraria.

Domínios

Fintech, criptoativos, serviços financeiros, backoffice e ativos digitais. Na prática isso aparece como ledger bancário e PIX rodando de minuto em minuto, custódia institucional de criptoativos com workspaces isolados, liquidação financeira multibancos e consolidação de documento fiscal. Os cases são anonimizados por sigilo: o que está publicado é a decisão técnica e a arquitetura, nunca o cliente.

Stack

PostgreSQL e Python no núcleo, com SQL e APIs REST por cima. Azure e AWS na nuvem, dbt na modelagem, Dagster na orquestração e Prometheus na observabilidade. O padrão de carga que se repete nos cases é COPY nativo para tabela temporária, UPSERT na tabela final, deduplicação em memória antes do lote e índice novo criado com CONCURRENTLY, para não bloquear escrita em produção.

Um dataset que qualquer pessoa pode auditar

Case anonimizado depende de confiança. Dataset público, não. O LCK Spring 2024 Players Statistics está no Kaggle sob licença CC BY 4.0, com nota máxima de usabilidade (10.0), 300+ downloads e reuso de terceiros em notebooks de EDA. Coleta via BeautifulSoup e Selenium, normalização de percentual e de duração MM:SS para segundos, deduplicação e três tabelas ligadas por Player ID. Está tudo lá para conferência: kaggle.com/datasets/lukasrozado/lck-spring-2024-players-statistics ↗

Escala e resultado nos sistemas em produção

ETL de 206 milhões de registros. 15+ blockchains integradas com auto-reconciliação, fechando em 100% de reconciliação contra o supply on-chain. Arquitetura Medallion, com Bronze, Silver e Gold, construída do zero. E um pipeline de ingestão sustentando >99,9% de uptime em produção, com backfill histórico completo desde a abertura de cada conta, algumas remontando a 2019. Os cases publicados trazem o problema, a decisão e a consequência de cada um.

Trabalho com engenharia de dados desde 2021. Inglês C1, certificado pelo EF SET Advanced, o que significa reunião técnica, documentação e code review em inglês sem intermediário. Ferramentas do dia a dia: PostgreSQL, Python, Azure, AWS, dbt, Dagster e Prometheus. Também escrevo sobre o ofício em Escritos e na newsletter Dado Bruto, e respondo às dúvidas mais comuns no FAQ.