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.
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 →
o dado sai de uma origem e chega em mais de 100 paísesvolume, 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.
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.
100pico
58após 2 meses −42%
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
IndexarCada geometria vira células de uma grade hexagonal (H3).
FiltrarSó as células que tocam a fazenda são candidatas; o resto nem entra na conta.
ConfirmarO teste geométrico exato roda só nos candidatos — é a parte cara.
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.
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
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 EngineeringTamer 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.
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
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
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
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
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
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
Simon Spätipadrões de projeto em engenharia de dadosssp.shLinkedIn