Campinas, SP · Brasil

Patrick Leite

Patrick Pimentel Corrêa Leite

Engenheiro de Dados & Engenheiro de Plataforma de Dados
Data Engineer & Data Platform Engineer

Construo plataformas de dados que sustentam decisão — da ingestão ao modelo dimensional. Na Minerva Foods, reduzi em 73% o custo da maior operação de dados da plataforma enquanto o volume atendido crescia.

Databricks Azure Apache Spark Airflow Python SQL C# / .NET Delta Lake Unity Catalog Bicep Docker FinOps Modelagem Dimensional Geoespacial
origem lakehouse erp db api ingestão CDC · batch bronze prata ouro decisão
01 — A trilha

Toda cadeia deixa rastro

Trabalho e curiosidade convergem numa mesma pergunta de engenharia: de onde isso veio? — respondida rápido o bastante para ainda mudar a decisão.

proteína

Cadeia física

Na Minerva, o rastro é de proteína: da fazenda ao contêiner, ao porto e ao destino. Rastreabilidade aqui não é relatório — é requisito de exportação.

fazenda → frigorífico → contêiner
→ porto → destino
pixel

Cadeia espacial

Na MyCarbon, o rastro era de pixel e de polígono: CAR, PRODES e carbono do solo, fazenda por fazenda. Formatos cloud-native mudaram o que dá para perguntar — e a que custo. Ver o caso →

fazenda → polígono (CAR) → sobreposição
→ desmatamento → carbono do solo
tabela

Cadeia de dados

Dentro da plataforma, o rastro é de linhagem: da fonte à tabela ouro, cada número sabe de onde veio e quanto custou produzi-lo. É a mesma pergunta virada para dentro.

fonte → bronze → prata
→ ouro → decisão

São três domínios distintos com o mesmo problema de engenharia: ingerir muito, modelar bem e conseguir reconstruir a origem sob demanda. Modelagem dimensional, particionamento e linhagem não mudam de natureza quando o objeto passa de boi para pixel e para a própria tabela — muda a cardinalidade. O mesmo vale para grafos de transação, que acompanho à parte.

02 — Stack

O que uso, por etapa

Arquitetura de dados de ponta a ponta: medalhão em lakehouse, orquestrada e versionada. O que está em produção no dia a dia.

01

Ingestão

  • Python
  • REST / APIs
  • Batch & CDC
02

Orquestração

  • Apache Airflow
  • Databricks Jobs
  • Asset Bundles
03

Processamento

  • Apache Spark
  • PySpark
  • Databricks
04

Armazenamento

  • Delta Lake
  • Azure Data Lake
  • Unity Catalog
05

Modelagem

  • Kimball / star
  • SCD Type 2
  • SQL

Deslize para o lado para ver o diagrama inteiro →

origem ingestão Python · C# · Airflowlakehouse Delta Lake · Unity Catalogentrega SQL · Power BI · SSASconsumo Databricks · Power BI ERP · transacional APIs públicas IoT industrial raster · satélite vetor · talhão declarativa CDC · batch paridade de linhas bronze prata ouro modelo dimensional cubo · Analysis Services tabela flat · extrato API · serviço de dado BI · self-service Data Science · ML aplicação orquestração · CI/CD · governança de custo linhagem · catálogo · qualidade de dado · controle de acesso transversal a tudo
o dado sai de uma origem e chega em mais de 100 países volume, velocidade e variedade — a escala é o problema, não o detalhe
03 — Percurso

Onde estive

set 2023 — hoje

Engenheiro de Dados / Plataforma

Minerva Foods · remoto

Plataforma de dados numa das maiores exportadoras de proteína do mundo — presente em mais de 100 países. Comecei pelo geoespacial — a base socioambiental da MyCarbon, a subsidiária de carbono do grupo (ver o caso) — e depois assumi a plataforma. Em agosto de 2026 apresentei à liderança um ano de trabalho de plataforma organizado em quatro frentes deliberadamente ordenadas, sob uma tese: a economia é consequência, não o objetivo. O que foi construído tornou o legado desnecessário — desligar veio por último, não primeiro.

01Substituirmotor próprio no lugar da orquestração legada
02Otimizaro maior processo de replicação, redesenhado
03Separarworkspace próprio para Data Science
04Encerrardesligar o legado com evidência

Em 2026, projeto e conduzo a reconstrução da orquestração: um Airflow 2.5.3 fora de suporte, com 2.171 DAGs e cerca de 47 mil tarefas por dia útil, está sendo substituído por uma plataforma Airflow 3 em 17 etapas incrementais, cada uma com um portão automático que prova o próprio resultado. Plataforma não é o servidor que roda as DAGs. É a capacidade de provar, a qualquer momento, que ele está fazendo o que deveria.

DatabricksAzureSparkAirflow 3CeleryExecutorUnity CatalogEntra IDOpenTelemetryC# / .NETBicep
jul — nov 2023

Santander Coders — Engenharia de Dados

Ada · Santander Universidades

Programa intensivo de cinco meses em Big Data, Analytics Engineering e Engenharia de Dados.

2022 — 2026

Sistemas de Informação (BTech)

PUC-Campinas

Bacharelado em Tecnologia. Conclusão em dezembro de 2026.

75 / 70.000taxa de 0,1%

Selecionado entre 75 vagas na trilha de Engenharia de Dados do Santander Coders 2023, de um universo de mais de 70 mil candidatos.

04 — Trabalho

O que construí

Trabalho de plataforma numa operação global de proteína, e um caso geoespacial anterior a ele. Os números de custo e de substituição do legado foram apresentados formalmente à liderança em agosto de 2026; os da reconstrução da orquestração em Airflow 3 são de 2026, do projeto em andamento, medidos pelas suítes e portões do próprio projeto; o caso geoespacial é de 2023–24 e usa só fontes públicas.

−73%custo da maior operação de dados, desde o pico

Reduzi em 73% o custo da maior operação de dados da plataforma, desde o pico — −42% já nos dois primeiros meses, antes de desligar qualquer sistema legado. No mesmo período, as tabelas atendidas cresceram cerca de 10% (≈390 → ≈430) e o consumo de processamento (DBU) caiu 59%. Mesma entrega, mesma frequência, cerca de um terço do custo por tabela.

  1. 100pico
  2. 58após 2 meses −42%
  3. 27ago/2026 −73%

No mesmo período

+10%tabelas atendidas ≈390 → ≈430
−59%consumo de processamento DBU
Custo da maior operação de dados, índice com o pico = 100. Números apresentados à liderança em agosto de 2026; sem valores em reais.

Custo de plataforma como problema de engenharia

FinOps

Assumi o custo da plataforma como responsabilidade de engenharia, não de planilha. Redesenhei o modelo de execução para que cada processo passasse a custar o que de fato consome, e construí a camada de governança que responde quanto custa cada produto de dado e quem responde por ele — pergunta que antes não tinha resposta confiável.

Ver detalhes

O resultado sustentou uma apresentação formal à liderança. Mais importante que os números: decisão de corte deixou de ser palpite. Hoje ela parte de evidência cruzada de sinais independentes e separa custo medido de custo rateado em vez de somar os dois num número só.

−42% em 2 meses−73% do picocusto por donoevidência cruzada

Base geoespacial socioambiental em escala

PySpark · Mosaic · GDAL

Uma empresa de crédito de carbono precisa responder, para cada fazenda, perguntas que não estão em nenhum sistema próprio: sobrepõe terra indígena? unidade de conservação? houve desmatamento? qual o carbono do solo? As respostas estão espalhadas por mais de vinte bases públicas, cada uma com seu formato, sua projeção e sua frequência de atualização. Conduzi a ingestão dessas bases na MyCarbon, a subsidiária de carbono da Minerva — meu primeiro projeto lá (out/2023 a jan/2024).

Ver detalhes

Cada fonte virou um pipeline com cadência própria — do diário ao anual —, baixado por WFS ou HTTP, normalizado em SIRGAS 2000, com a geometria validada antes de gravar e lido em escala com o Mosaic no Spark. O raster ensinou mais que o vetor: 45 GB de altimetria não cabem num banco; cabem num storage, lidos sob demanda em formato cloud-native. É por isso que formato vem antes de ferramenta.

Onde o dado vive

Linhas: as 27 UFs cobertas pelo CAR, baixado por WFS. Cores: os 6 biomas cobertos pelo PRODES.

  • Amazônia
  • Cerrado
  • Mata Atlântica
  • Caatinga
  • Pampa
  • Pantanal

Cobertura das fontes, não resultado de análise. Malha do IBGE (UFs e biomas, escala 1:250 mil), simplificada para o desenho.

Da fazenda à resposta

  1. IndexarCada geometria vira células de uma grade hexagonal (H3).
  2. FiltrarSó as células que tocam a fazenda são candidatas; o resto nem entra na conta.
  3. ConfirmarO teste geométrico exato roda só nos candidatos — é a parte cara.
  4. ResponderTerra indígena, unidade de conservação, desmatamento: uma linha por fazenda.
  • fazenda
  • célula candidata
  • terra indígena
  • unidade de conservação
  • desmatamento

Esquema ilustrativo, sem dados reais. A indexação em grade (H3 ou BNG) é o desenho do próprio Mosaic; o ganho está em fazer o teste caro só onde há chance de sobreposição.

Ver o Mosaic por dentro

Mosaic por dentro

O Mosaic era uma extensão do Spark para geoespacial em escala, hoje arquivada. O desenho do próprio projeto tem três camadas:

Apresentaçãoexibição de geometria no notebook e mapas com Kepler.gl
Processamentofunções ST_ de geometria (JTS), expressões do Spark com geração de código e indexação em grades (H3 ou BNG): polígonos e linhas são recortados nas células da grade, e o join espacial vira join por chave
Dadosleitura por GDAL/OGR — vetor em paralelo com multi_read_ogr, raster com gdal — e gravação em Delta Lake

O núcleo é Scala; Python, R e SQL são camadas finas por cima. Onde eu entrei: usei a camada de dados e as funções de raster, enviei uma correção à documentação (PR #444) e abri uma pergunta sobre mesclar tiles de raster em escala (issue #489). Um mantenedor explicou o comportamento do tile que eu relatei e o situou na versão 0.4.1.

Foi ali que o desenho mostrou o limite que encontrei: mesclar tiles em memória não escala, e raster pertence ao storage, com um índice VRT, lido sob demanda. O sucessor, o GeoBrix, documenta hoje esse caminho (COG e mosaicos VRT).

O desenho de três camadas é o do README do projeto, redesenhado aqui.

20+ fontes públicasCAR dos 27 estadosPRODES dos 6 biomasSIRGAS 2000

Plataforma de Data Science entregue de ponta a ponta

Azure · Databricks

Um time inteiro de Data Science precisava sair de um ambiente compartilhado e passar a operar com autonomia — de custo, de configuração e de entrega. Entreguei a plataforma completa — rede isolada, ambiente de computação provisionado como código, e o mesmo padrão replicado entre desenvolvimento e produção. O que antes dependia de pedido e espera passou a ser provisionado pelo próprio time.

Ver detalhes

Plataforma sem adoção é custo. Junto veio o que faz a adoção acontecer: pipeline de CI/CD, material de handoff e exemplos prontos, para o time operar no padrão desde o primeiro dia — a maioria nunca tinha trabalhado assim. Hoje respondo pelo ambiente como referência técnica: mantenho o padrão, acompanho o que entra e garanto que a plataforma continue coerente à medida que o time cresce.

plataforma completadev e produçãoCI/CDreferência técnica do ambiente

Substituição e encerramento de um ambiente legado

Python · C#

A área dependia de mais de mil pipelines presas dentro de uma ferramenta visual — sem versionamento, sem revisão, sem custo rastreável. Construí o motor que as substituiu e conduzi a migração inteira sem um único incidente de dado.

carga histórica retirada~89%
objetos auditados com dependência viva~7%
Ver detalhes

Só com o legado já substituído é que ele pôde ser desligado — a ordem importa, e foi ela que tornou o desligamento uma consequência em vez de um risco. Auditei cerca de 1.100 objetos com um método de decisão apoiado em evidência cruzada de quatro fontes independentes, em vez de inventário declarado — só cerca de 7% tinham dependência viva. Conduzi o encerramento em ondas com verificação automática antes de cada lote. Cerca de 89% da carga histórica do ambiente antigo saiu do ar sem quebrar consumidor.

+1.000 pipelines migradas−89% da carga legadasem incidente

Orquestração como produto interno

Apache Airflow

A orquestração vivia dentro de uma ferramenta visual em nuvem: cada pipeline era uma configuração clicada, sem versionamento, sem revisão e sem reaproveitamento entre uma fonte e outra. Construí a camada que substituiu isso — orquestração em Airflow onde o pipeline nasce de configuração, não de tela.

Ver detalhes

Descrever a fonte passou a bastar: o pipeline é gerado, entra no Git e é revisado como qualquer outra mudança de software. Adicionar uma fonte deixou de custar tempo de engenharia, e o conhecimento parou de ficar preso em quem clicou. Respondo por 93 a 100% do código vivo dessa camada. É a diferença entre entregar pipelines e entregar a capacidade de criá-los.

93–100% do código vivoversionado e revisado em Git

Orquestração reconstruída em etapas que se provam

Airflow 3 · Docker

Recebi um Airflow 2.5.3 em Python 3.8, fora de suporte, com 2.171 DAGs e cerca de 47 mil tarefas por dia útil — bibliotecas remendadas à mão e logs que sumiam em quatro dias. Projetei a substituição por uma plataforma Airflow 3 em Python 3.14, com CeleryExecutor e filas por perfil de carga, e a dividi em 17 etapas incrementais, da base limpa ao cutover: cada uma traz receita, arquivos, portão e rollback, e entra em produção uma a uma.

Ver detalhes

Escrevi os portões com controle negativo: cada um é mostrado falhando contra o defeito que diz pegar. Na revalidação da versão 3.3.2, isso revelou 13 portões quebrados como escritos, que passariam em silêncio. Portão que nunca foi visto falhando é suposição.

A migração das DAGs é automatizada: inventariei o legado contra os dois servidores de produção, reproduzi pelo repositório a contagem exata que a interface mostra e escrevi um conversor de DAGs e um operador próprio de container (nome estável por execução, retomada da tentativa anterior). O portão de carga reprova erro de importação, cron inválido e DAG duplicada entre repositórios. Resultado: de 43 para 96 dos 99 arquivos carregando na versão nova e de 324 para 0 depreciações. Migrar não é converter código: é provar que o que roda depois é o que rodava antes.

2.171 DAGs17 etapas com portão324 → 0 depreciações43 → 96 / 99 arquivos

Benchmark de carga e confiabilidade antes da produção

Airflow 3 · Python

Durante a pausa do projeto, criei uma suíte de 12 DAGs para estressar o ambiente produtivo: CPU, RAM, disco, tarefa longa, estouro de paralelismo, cadências que se sobrepõem e a saúde de cada componente a cada 5 minutos. Em quatro dias: 157.525 tarefas, 2 falhas (ambas diagnosticadas e corrigidas), zero reinícios e zero horários de agendamento perdidos em 17.284 execuções, com atraso p99 de 1,6 s.

Ver detalhes

A suíte achou dois comportamentos não documentados do Airflow 3 — entre eles, max_active_runs=0 travando a DAG para sempre — e quantificou o custo fixo por tarefa (~5 s) e o teto real de concorrência da máquina. Medido vale mais que lido: número sem origem é chute com formatação.

157.525 tarefas em 4 diasp99 1,6 szero reinícios0 horários perdidos em 17.284 execuções

Observabilidade sem privilégio e diagnóstico de logs em escala

Python · Linux

Num ambiente sem sudo e sem acesso ao Docker, montei o raio-X da máquina só com leitura: /proc, cgroups por container, PSI e um papel somente leitura no metastore. Mostrei, por exemplo, que o “vazamento” de memória do worker era cache de arquivo.

Ver detalhes

Escrevi agregadores de uma passada para 40 mil arquivos de log por dia e calculei o custo real do histórico: cerca de 3,7 KB por tarefa no banco, contra cerca de 6 GB por dia de log em arquivo no legado. Nenhum desses números exigiu acesso de administrador. Só exigiu saber onde o sistema já os escreve.

40 mil logs por dia3,7 KB por tarefaacesso somente leitura

Segurança, identidade e retenção na orquestração

Entra ID · Key Vault

Passei a autenticação do LDAP para o SSO do Entra ID, com papel por grupo e MFA, mantendo um acesso de emergência medido em 27 s; os segredos ficam no Azure Key Vault, por ambiente. A borda TLS ficou num proxy nginx, e o diagnóstico da cadeia de certificados resolveu três causas sobrepostas que se disfarçavam de um único erro.

Ver detalhes

Desenhei o ciclo de vida dos dados operacionais em camadas: log de tarefa no Azure Blob com tiers automáticos, trilha de auditoria exportada para container imutável e backup fora da máquina. Validei o comportamento lendo o código-fonte do Airflow e do provider Azure e provando contra o emulador oficial. Isso corrigiu três premissas erradas da documentação interna e achou uma rotina de limpeza que apagava a trilha de auditoria sem exportar, antes que ela rodasse em produção. Documentação é evidência, não instrução: confira contra o código antes de agir.

SSO + MFAacesso de emergência 27 strilha de auditoria imutávelLGPD

Modelagem dimensional em que o negócio confia

Kimball · SQL

Modelo dimensional existe para que a área de negócio confie no número sem precisar saber de onde ele veio. Trabalho com dimensões que preservam histórico e fatos padronizados sob um contrato único do domínio — o que permite reorganizar um domínio inteiro sem quebrar quem já dependia daquele dado.

Ver detalhes

A validação vem antes da publicação, não depois. Nada entra no ar sem reconciliar contra a base de produção — e é isso que torna possível mexer em dado que já está em uso sem pedir que ninguém confie na promessa.

reconciliação antes de publicarSCD Type 2contrato único de domínio

Repositórios públicos

O trabalho acima é interno. No GitHub estão estudos, faculdade e experimentos — incluindo dbt-taxi-analytics, Brain-tumor-detection (redes convolucionais sobre imagem de ressonância) e DataEngJourney.

Ver todos os repositórios →
05 — Formação

Credenciais e certificações

  • Santander Coders — Engenharia de DadosAda · Santander Universidades · 5 meses
    nov 2023
  • Apache Airflow FundamentalsAstronomer
    jun 2023
  • Engenheiro de Dados Cloud — 148hXP Inc. Educação · IGTI
    mai 2023
  • Introduction to Machine LearningDuke University · PyTorch
    jul 2021
  • Cybersecurity FundamentalsIBM
    jun 2021
  • Inglês — nível avançadoleitura técnica e conversação
    —
06 — Radar

O que estou acompanhando

Onde minha atenção está agora, em ordem de prioridade. Destacado, o que estou acompanhando de perto.

Lakehouse

  • (em destaque) Cube — camada semântica para agentes
  • (em destaque) RisingWave — SQL sobre streaming
  • DuckDB — escrita em Iceberg

Geoespacial

  • (em destaque) GeoBrix — sucessor do Mosaic, que usei na MyCarbon
  • (em destaque) CARTO — geo dentro do warehouse

Rastreabilidade

  • (em destaque) TRM Labs — forense de blockchain
  • (em destaque) ar.io — permanência de dados

Leitura atual

Financial Data Engineering Tamer Khraisha · O'Reilly, 2024

Estudo de domínio: o que dados financeiros exigem de quem engenheira a plataforma. O livro é agnóstico de ferramenta; o que levo dele é critério — e o reconhecimento do que já pratico, com o nome que o setor usa.

  1. Contrato de dados

    Uma interface acordada entre quem gera o dado e quem o consome: estrutura, semântica, frequência, privacidade. O livro o trata como padrão de projeto, não como ferramenta.

    No meu trabalho: o contrato único de domínio
  2. Reconciliação

    O mesmo registro vive em sistemas de partes diferentes. Reconciliar é alinhá-los numa visão única antes que a divergência vire risco.

    No meu trabalho: reconciliar com a produção antes de publicar
  3. Linhagem e trilha de auditoria

    Linhagem é visibilidade do ciclo de vida do dado. A trilha de auditoria é a versão financeira dela: o regulador quer ver a origem de um número.

    No meu trabalho: lineage no Unity Catalog; trilha imutável na orquestração
  4. Histórico point-in-time

    Em finanças, o dado não é só o valor de hoje: é o que se sabia em cada data. O warehouse acrescenta registros em vez de sobrescrever.

    No meu trabalho: dimensões com SCD Type 2
  5. Qualidade com tolerância

    Qualidade tem dimensões — erro, duplicata, completude, pontualidade — e uma tolerância definida pelo negócio, como um erro abaixo de 0,01%.

    No meu trabalho: verificações automatizadas como critério de publicação
  6. Catálogo vivo

    Catálogo desatualizado custa mais do que não ter catálogo, e quanto mais sofisticado, maior o custo de curadoria.

    No meu trabalho: Unity Catalog como catálogo da plataforma

O que ainda me falta, e o motivo da leitura: domínio financeiro — instrumentos, identificadores como ISIN e LEI, e a regulação que molda o dado, como o BCBS 239. A leitura está em andamento.

Pessoas que leio

07 — Contato

Vamos conversar

Aberto a conversas sobre engenharia de dados, lakehouse, geoespacial e rastreabilidade de cadeias.