−73%custo da plataforma
Reduzi em 73% o custo da maior operação de dados da plataforma — −42% já nos dois primeiros meses, antes de desligar qualquer sistema legado. No mesmo período, o volume atendido cresceu. Mesma entrega, mesma frequência, um terço do custo.
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.
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ó.
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).
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.
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.
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.
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.
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.
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. Estabeleci um método de decisão apoiado em evidência cruzada de quatro fontes independentes, em vez de inventário declarado, e 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.
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.
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.
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.
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.