Vaz · Engenharia de informação

Prompt caching: o ajuste de 1 linha que corta 90% do custo de LLM em produção

Thu, 11 Jun 2026 00:00:00 +0000

18 mil tokens. Era o custo de cada execução do meu pipeline de notícias com 6 sub-agents paralelos. Depois de uma linha de código, virou 4 mil e quinhentos. Sem mudar o modelo. Sem mudar o prompt. Sem mudar o output. Só liguei o cache.

A feature existe na API Anthropic há mais de um ano. A maioria dos times que usa LLM em produção ainda não ligou. Eu mesma rodei meses pagando preço cheio antes de olhar a fatura com atenção. É o ajuste com melhor retorno por minuto de trabalho que conheço hoje.

Por que o custo de LLM em produção é prefixo

Toda chamada pra API manda 4 coisas: system prompt, few-shots, contexto e pergunta. Em pipeline de verdade, os 3 primeiros somam 80 a 95 por cento dos tokens, e repetem a cada chamada. A pergunta muda. O resto é prefixo.

Sem cache, você paga pelo prefixo inteiro toda vez. Em pipeline que roda dezenas ou centenas de vezes por hora, isso vira a conta. Em pipeline com fan-out paralelo (vários sub-agents, mesmo system prompt), vira a conta vezes o número de sub-agents.

Com cache, você paga o prefixo uma vez (cache write), e depois só o delta da nova chamada (cache read). Cache read custa cerca de 10% do preço de input normal.

Como funciona o cache na Anthropic

Você marca um bloco do prompt com cache_control: ephemeral. Exemplo simplificado:

"system": [
  {
    "type": "text",
    "text": "<system prompt longo e estável aqui>",
    "cache_control": {"type": "ephemeral"}
  }
]

TTL padrão é 5 minutos. Próxima chamada dentro desse intervalo: o prefixo cacheado é lido a 10% do preço normal. A Anthropic também oferece TTL de 1 hora como opção paga, útil pra workflows mais espaçados.

A API retorna 2 métricas que você precisa monitorar:

cache_creation_input_tokens: você pagou o write.
cache_read_input_tokens: você pagou só o read (90% de desconto).

Sem mexer no modelo, sem reescrever prompt. Só sinalizar o que é cacheável.

Bench real do pipeline noticias-diarias

O número da abertura vem de um pipeline que eu construí e mantenho: minha skill de notícias diárias, que roda todo dia às 8h BRT. Dispara 6 sub-agents paralelos via tool Agent: data-eng, IA, invest, cripto, política BR, política internacional. Cada um carrega um system prompt fixo de aproximadamente 3 mil tokens com regras de tom, formato Telegram, fontes priorizadas e estilo de síntese.

Sem cache, a conta que eu pagava era direta:

6 sub-agents × 3 mil tokens de prefixo = 18 mil tokens pagos por execução.
Multiplicado por 1 execução por dia = 540 mil tokens por mês só de prefixo.

Com cache:

1 cache write inicial (3 mil tokens) + 5 cache reads (com delta de ~300 tokens cada) = ~4 mil e 500 tokens efetivos.
Aproximadamente 75% de corte no custo de prefixo, sem perder qualidade nem mudar uma vírgula do output.

Em pipeline de produção mais agressivo (que roda dezenas de vezes por hora, com prefixos maiores), o corte chega a 90%.

Onde brilha, onde não brilha

Brilha:

System prompt fixo e grande (regras, format spec, exemplos).
Fan-out: vários sub-agents com mesmo prefixo na mesma sessão.
Agentes em loop iterando sobre mesmo contexto.
Chat com documento grande anexado, com várias perguntas seguidas.

Não brilha:

Chamada one-shot sem padrão repetido.
Prompt que muda significativamente a cada chamada.
Workflow com cadência maior que 5 minutos entre calls (cache expirou).

Cuidados que matam o ganho se você não conhece:

Cache write é mais lento que call normal. Você paga uma vez em latência, ganha em todas as seguintes. Em pipeline noturno isso não importa. Em chat interativo, importa.
Não cachear PII ou dado sensível sem auditar. Cache é per-account na Anthropic, mas o princípio vale.
TTL 5 min é janela curta. Se sua skill roda o pipeline a cada 10 minutos, o cache nunca pega. Pra esses casos, use o TTL de 1 hora.
Você só vê o ganho se monitora as 2 métricas. Um timestamp no começo do system prompt basta pra o prefixo nunca cachear, e sem olhar cache_read você acha que ligou e não ligou.

Não é micro-otimização. É arquitetura.

Quem está pagando 100% do preço de cada chamada porque “não teve tempo de configurar” está acumulando dívida com a Anthropic todo mês. Em pipeline de produção com volume sério, isso vira milhares de reais por ano. Por uma linha de código.

A regra que eu sigo em tudo que construo agora: estruture o prompt em camadas. Estável primeiro (cacheável), volátil depois. Marque o estável com cache_control: ephemeral. Monitore cache_creation e cache_read. Pague uma vez, leia muitas.

É o ABC. E ainda tem time chamando isso de “otimização avançada”.

Próximo post sábado 10h: Zero to Expert Ep 02 sobre dependências em DAG, a lei que todo orquestrador segue por baixo do nome. Sem Airflow no centro.

Assina o VazDEng se ainda não assina: vazdeng.substack.com.

SQL ainda é a linguagem mais importante de DE em 2026

Wed, 10 Jun 2026 00:00:00 +0000

Tem dev hoje fazendo onboarding em time sênior que nunca escreveu um GROUP BY na vida. Aprendeu ORM antes de SQL. Acha que df.groupby() resolve. Quando a query trava porque o plan de execução virou full scan em tabela de 80 milhões de linhas, copia o erro pro ChatGPT, cola a resposta, e quando trava de novo, copia de novo. Loop infinito.

Esse dev é o que o Akita chama de codificador. E a IA está acelerando a extinção dele.

O codificador terceirizou o entendimento

Eu aprendi SQL antes de qualquer framework, porque era o único jeito de falar com o banco. Hoje é o contrário. Framework antes de SQL. ORM antes de SQL. pandas antes de SQL. Camadas e mais camadas de abstração que escondem a query que de fato vai rodar.

O problema da abstração não é a abstração. É que ela esconde o custo. Você acha que User.objects.filter().select_related().prefetch_related() é cheap. Não é. É um JOIN que pode estourar memória se você não souber por que está rodando JOIN, em quantas tabelas, com qual cardinalidade. O ORM escreve a query certa em 70% dos casos. Os 30% restantes destroem teu cluster.

Em pipeline real, abstração não cabe

Pipeline de DE moderno processa bilhões de linhas por dia. Toda decisão de query custa minutos vezes cluster vezes DBU vezes dia vezes mês. A diferença entre uma query bem escrita e uma gerada por ORM despreparado é fator 10 a 100x no custo final.

Caso concreto que apareceu numa consultoria: pipeline de fechamento contábil em fintech brasileira. ORM gerando 47 subqueries pra coisa que SQL nativo resolve em 1 CTE com WINDOW. Custo Databricks/Snowflake: R$ 8 mil/mês. Depois que alguém finalmente escreveu a query em SQL puro, R$ 800/mês. Mesmo resultado de negócio, fator 10x de diferença.

Não foi um caso isolado. É o padrão. Onde tem pipeline grande gerado por abstração, tem fator 10x de gordura esperando alguém ler o plan de execução.

A IA gera SQL ruim em escala

Toda IA generativa hoje gera SQL fluente. Compila, roda, retorna o número certo na primeira tentativa. O problema não é correção, é eficiência.

Padrões observados em SQL gerado por LLM sem revisão:

SELECT * em CTE empilhada, arrastando colunas que ninguém vai usar pelo pipeline inteiro.
WHERE coluna IN (SELECT ... ) em vez de JOIN, em casos onde o JOIN seria 100x mais rápido.
WHERE UPPER(coluna) = 'X' em coluna indexada, derrubando o índice.
Sem hint de partition em Spark/Snowflake, lendo tabela inteira quando só precisa de 1 dia.
Window function sem PARTITION BY correto, computando coisa errada sem dar erro.

Desses cinco padrões, não tem um que eu não tenha visto em query gerada. Quem não lê plan de execução não vê. Vai pra produção, paga os juros no fim do mês. Dívida técnica com IA não é a mesma dívida de 5 anos atrás. Você contrai 10x mais rápido, achando que está levando vantagem.

O plan de execução é onde mora a diferença

EXPLAIN ANALYZE no Postgres. EXPLAIN COST no Snowflake. Plano físico no Spark UI. É a primeira coisa que eu olho antes de deixar query nova rodar em escala. Todos te dizem a mesma coisa: quantos rows o engine vai escanear, quais joins escolheu, onde tem shuffle, onde tem broadcast, onde tem fila de espera.

Codificador olha pro plan e não entende. Engenheiro lê e sabe se vale rodar em produção ou se precisa reescrever. Não é decoreba. É leitura de causa pra custo.

Quando você pede pra LLM gerar SQL, peça também o plan estimado, peça pra comparar com versão alternativa, peça pra discutir trade-off de partition vs broadcast. Se você não sabe avaliar a resposta, você não está fazendo engenharia ainda. Está terceirizando decisão.

A decisão é antes da próxima feature

SQL não morreu. Quem morreu foi quem fingiu que sabia.

A IA é darwinismo profissional. Quem aprende SQL de verdade fica 10x mais produtivo com ela, porque sabe avaliar o que ela gera. Quem terceiriza ORM mais IA acumula dívida que vai quebrar produção em 18 meses, e nesse dia não vai ter ninguém pra debugar porque ninguém mais lê plan de execução.

A escolha é antes da próxima feature. Vai aprender o que está rodando ou vai apostar que a IA cobre teu vão? A aposta é ruim.

Próximo post na quinta: prompt caching cortando 90% do custo de LLM em produção. Bench real, configuração em uma linha, onde brilha e onde não brilha.

Assina o VazDEng se ainda não assina. Engenharia de dados em português, padrão sênior, sem hype: vazdeng.substack.com.

YouTube bloqueia o endpoint de legendas. O de áudio continua aberto.

Thu, 04 Jun 2026 00:00:00 +0000

Bati em HTTP 429 do YouTube em 14 vídeos seguidos. Eu tentei --sleep-subtitles 60, backoff exponencial até 45s, cookies do Chrome, yt-dlp pré-release. Nada destravou. Todos os pedidos pro timedtext voltavam 429.

Mudei pro endpoint de áudio. Zero 429.

Em uma frase: o timedtext (legendas) e o googlevideo (áudio/vídeo) do YouTube são endpoints diferentes. Só o primeiro está agressivamente rate-limited em 2026. Baixar áudio e transcrever localmente sai mais barato do que insistir nas legendas.

O problema que pipelines de transcrição ignoram

O rate limit do timedtext virou comum o suficiente em 2026 pra ter 3 issues abertas no yt-dlp (#7123, #13770, #13831), sem fix definitivo. O conselho oficial é caching e usar a YouTube Data API com OAuth. Os dois funcionam mas mudam o problema, não resolvem. Quem rodou 50 URLs num cron e viu metade vazia conhece o sintoma.

Por que `googlevideo` não cai junto

A descoberta que demorei pra fazer está nas duas camadas distintas que o YouTube expõe. O timedtext é uma camada de API: serve XML/VTT pequenos sob quota global por IP e por dia, com cache pesado e bot detection endurecida em 2025. Cada request conta. Já o googlevideo é a CDN de vídeo e áudio, que responde via segments DASH a partir de edges do Google Global Cache, com peering direto pro seu ISP. A camada de billing é por banda agregada no servidor que serve seu ISP, não por request individual. O rate limit lá só dispara em padrão claramente robótico.

Na prática que eu vi: 60 requests em 5 minutos no timedtext resulta em 429 garantido. Os mesmos 60 downloads no googlevideo com intervalo natural passam sem aviso. Esse detalhe não está documentado em lugar óbvio. Eu descobri quando o cron quebrou e abri o Wireshark.

A pipeline que aguenta batch real

Empacotei a lógica num CLI Python open source chamado yt-nota. Junta 3 ferramentas.

Etapa	Ferramenta	Custo	Quando falha
Metadata + URL da legenda	`yt-dlp` (Python API)	$0	Vídeo privado, region lock
Áudio fallback	`yt-dlp` formato 139 (m4a 49kbps)	$0	Members-only sem cookie
Transcrição local	`faster-whisper` int8 CPU	$0	Vídeo > 1h em hardware fraco

faster-whisper é 4x mais rápido que openai-whisper no mesmo modelo, com a mesma acurácia (mesmos pesos). A API do meu CLI fica assim:

result = extract_transcript(
    url,
    whisper_fallback=True,   # default ligado
    whisper_model="small",   # ou tiny/base/medium
)

No 429, ele desce pro googlevideo, baixa só o áudio, transcreve e devolve o mesmo formato. Quem chama nem sabe se veio do timedtext ou do Whisper.

Benchmark em CPU (Intel i7 12ª gen, 16 GB, int8)

Eu rodei o pipeline em vídeos reais de duração variada pra medir tempo de processo. Sem GPU.

Duração do vídeo	`base` (74 MB)	`small` (244 MB)	`medium` (769 MB)
5 min	35 s	1 min 30 s	5 min
13 min	1 min 50 s	4 min	13 min
45 min	6 min	14 min	45 min

Sobre acurácia em português técnico, fiz leitura comparativa em ~14 horas de áudio de aulas. O modelo base confunde 1 em cada 6 termos técnicos (95% legível mas pede revisão humana). O small confunde 1 em cada 20 (default por uma razão: o LLM downstream corrige os erros raros pelo contexto). O medium chega quase em erro zero, mas dobra o tempo. Pro meu fluxo (transcript → síntese via Claude Code), small é o sweet spot.

E os SaaS já existem com Whisper fallback?

Existem. Dois principais em 2026.

Solução	Preço	Quando faz sentido
Supadata	A partir de $0,001/min, free tier 1000 req/mês	Empresa com SLA, não quer manter infra
Apify YouTube Transcript Scraper	$0,40 por 1000 actor runs + compute	Pipeline já no Apify
yt-nota self-host	250 MB deps + 244 MB modelo	Privacidade, batch acadêmico, controle

A decisão pra mim é trivial: nota de aprendizado e vault Obsidian não atravessam API de terceiro. Se fosse pipeline corporativo com SLA e auditoria, Supadata ganha por operacional. Self-host só faz sentido quando você é o cliente do dado.

Verdict honesto

O que funciona: batch de 50+ vídeos sem cair no meio, zero custo recorrente depois dos 500 MB iniciais, qualidade em português técnico boa o suficiente pra LLM digerir depois.

O que cobra: primeira instalação é pesada (pip install yt-nota[whisper]), modelo small pode confundir termos exóticos (pra áudio crítico, sobe pra medium), e CPU vira gargalo em vídeo maior que 1h.

Quando NÃO vale: volume de 10.000 horas por mês com SLA apertado (a Whisper API da OpenAI a $0,006/min sai mais barato por hora-engenheiro do que manter infra), ou áudio com música e várias vozes simultâneas (faster-whisper não faz diarização, pyannote sim).

Anti-padrões que vi pelo caminho

Confiar no --sleep-subtitles 60 como bala de prata. Eu testei: ele não dispara antes do request, ele dispara depois do primeiro 429. Já era. Pular pra API paga sem ter tentado o pipeline local também é armadilha. $36k/ano em transcrição (cálculo público do faster-whisper) é dinheiro que devia comprar uma GPU intermediária. E apagar o áudio bruto depois de transcrever é erro de quem nunca quis rerodar com modelo melhor 6 meses depois. Eu guardo.

O que isso muda pra você

Se você usa YouTube como fonte de aprendizado, entrada de RAG ou pipeline de notas:

Sua pipeline atual aguenta 50 URLs em sequência sem cair?
Você sabe distinguir 429 de timedtext versus 429 de googlevideo?
Você tem fallback automático ou trata cada falha manual?
Custo mensal real da sua transcrição cabe ou já passou de 1 GPU amortizada?

Se respondeu “não” pra mais de uma, vale uma tarde refatorando.

Code review do meu próprio repo. Cinco coisas que eu mudaria hoje.

Tue, 02 Jun 2026 00:00:00 +0000

Abri um repositório meu de dois anos atrás. Continuava público no GitHub, eu citava ele no portfólio em entrevista, e eu nunca tinha relido o código depois de submeter. Esse fim de semana resolvi reler.

Achei cinco anti-padrões. No meu próprio código, escrito por mim. Mas o tipo de problema que eu vejo aparecer em pipelines reais de empresa grande, não só em case de entrevista.

Resolvi escrever sobre porque é mais honesto criticar o próprio código do que apontar dedo pra repo dos outros. E porque se você tem um repo público de dois anos atrás citado no seu portfólio, você provavelmente também tem pelo menos três desses cinco.

A credencial do banco estava dentro da função

def load_data_to_snowflake(df_merged):
    conn = snowflake.connector.connect(
        user='thaiscxxx',
        password='xxx*',
        account='xxx'
    )

Mascarei com xxx antes de subir, mas o padrão de design é o problema, não a string. Credencial dentro da função significa que cada task que precisa do Snowflake duplica essa conexão, rotacionar a senha exige tocar em código, e auditoria precisa varrer o repo inteiro pra saber quem conecta no banco.

A versão honesta usaria um Hook do Airflow (SnowflakeHook) ou variável de ambiente, com a conexão gerenciada fora do código:

from airflow.providers.snowflake.hooks.snowflake import SnowflakeHook
hook = SnowflakeHook(snowflake_conn_id='snowflake_default')

Conexão criptografada, rastreável, e nunca aparece em pull request.

O pipeline perdia paralelismo de graça

t1 >> t2 >> t3 >> t4

t1 validava students.json. t2 validava missed_days.json. Eu encadeei os dois em sequência, mas eles são independentes. Não existe motivo pra t2 esperar t1 terminar. Em arquivo pequeno, dá quase no mesmo. Quando o JSON pesa gigabytes e validação leva minutos, paralelizar cai a duração pela metade.

A versão correta seria:

[t1, t2] >> t3 >> t4

Quem lê o pipeline hoje entende que validação roda em paralelo e depois faz o join. Quem lia o original ia assumir que existia alguma dependência escondida que não existia.

Os dados estavam dentro da imagem Docker

No Dockerfile:

COPY files/students.json /students.json
COPY files/missed_days.json /missed_days.json

Embuti o dado de entrada na imagem. Cada rebuild da imagem assume o mesmo dado. Pra rodar o pipeline com um JSON diferente, eu teria que rebuildar a imagem ou modificar o código. Acoplamento entre artefato de execução e dado de entrada, no mesmo lugar.

A regra que eu cobrava de outros e ignorei no meu próprio repo: imagem é imutável, dado é mutável. Dado entra via volume montado, S3, GCS, ou parâmetro de execução. Nunca dentro da imagem.

O DAG rodava todo dia sobre dado estático

with DAG('migrate_student_data_to_snowflake',
         schedule_interval=timedelta(days=1),
         catchup=False) as dag:

Agendei o pipeline pra rodar todo dia. O dado de entrada é os dois JSONs estáticos copiados pra dentro da imagem (o anti-padrão acima). Rodar todo dia significa processar exatamente os mesmos arquivos, gerar exatamente os mesmos registros, e tentar inserir tudo de novo na mesma tabela. Na segunda execução, o write_pandas duplicaria as linhas. Na terceira, duplicaria de novo.

O dado é estático. A escolha correta seria schedule_interval=None (dispara só manual ou por trigger) ou um sensor que detecta arquivo novo no bucket. Agendar pipeline sem fonte mutável é cerimônia: gasta worker slot todo dia, dispara alerta se quebrar, polui o histórico de execução. E quando você precisa rodar de verdade com dado novo, a operação fica indistinguível do ruído de fundo.

Era pra rodar uma vez. Eu agendei pra rodar todo dia. Sutil, mas o tipo de coisa que cria DAG cerimonial em produção: pipeline que existe sem motivo de existir naquele intervalo.

O `fillna(0)` apagou um sinal importante

df_merged['missed_days'].fillna(0, inplace=True)

Quando um aluno aparece em students.json mas não em missed_days.json, o join deixa missed_days nulo. Substituí por zero. Parecia certo na hora.

Zero falta tem significado de negócio: aluno foi todos os dias. Ausência de registro tem outro significado: a escola não passou o dado desse aluno. Misturar os dois mascara um problema de qualidade de dado upstream. O dashboard que filtra alunos com “zero faltas” vai contar como exemplares justamente os alunos cujo dado nunca chegou.

A versão honesta deixaria nulo e abriria coluna nova marcando se houve registro:

df_merged['missed_data_source'] = df_merged['missed_days'].notna().map(
    {True: 'reported', False: 'not_reported'}
)

Pequena mudança, completamente diferente o que o dashboard mostra.

O incômodo de revisar código próprio

Reescrever esses cinco trechos hoje levaria uma hora. O incômodo de admitir publicamente que estavam errados é maior do que a hora. Mas o repo continuou público com os defeitos, e eu cito esse repo no meu portfólio. Manter o repo intacto e fazer review honesto em cima é mais útil pra quem está aprendendo do que apagar a história e fingir que sempre escrevi código bom.

Se você tem um repo público antigo que continua no seu portfólio, abre ele essa semana. Vai achar pelo menos três desses cinco.

Data Flows Ep01: o conceito que vem antes de qualquer ferramenta

Sat, 30 May 2026 00:00:00 +0000

Em 1 de agosto de 2012, a Knight Capital perdeu 440 milhões de dólares em 45 minutos.

Não foi bug de algoritmo. Não foi crise de mercado. Foi um único servidor entre oito que recebeu o deploy do novo código, enquanto outro manteve uma flag antiga reativada (Power Peg, código de 2003). Os dois rodaram em paralelo. O resultado foi uma cascata de ordens automáticas que ninguém conseguiu parar.

O SEC documentou o caso (Release No. 70694, outubro 2013): a causa raiz não era um erro de lógica de trading. Era inconsistência de estado entre servidores que deveriam estar sincronizados. Em linguagem de engenharia de dados, era um data flow quebrado.

A Knight Capital tinha algoritmos sofisticados. Tinha mais de uma década de operação. O que não tinha era um modelo mental claro sobre onde o dado nascia, por onde passava, e onde precisava chegar de forma consistente.

Esse modelo mental é o que define o resto. Eu trabalho com dados há tempo suficiente pra ter visto, em escalas menores, variações dessa mesma falha. Antes de Apache Spark, antes de dbt, antes de Snowflake, antes de qualquer ferramenta, existe um conceito que separa pipeline robusto de pipeline frágil.

Em uma frase

Data flow é o caminho que o dado percorre da fonte até o destino, com toda transformação no meio. Acertar esse caminho é decisão arquitetural. Errar custa caro.

De onde veio essa ideia

Não é nova. Bill Inmon publicou Building the Data Warehouse em 1992 defendendo arquitetura top-down, normalizada, enterprise-wide. Ralph Kimball respondeu em 1996 com The Data Warehouse Toolkit: bottom-up, modelagem dimensional, data marts compondo o todo. O debate Inmon vs Kimball dominou os anos 90 e ainda aparece em qualquer revisão de arquitetura.

O que mudou entre 1996 e 2026 não foi o conceito, foi a escala. Em 2017, Martin Kleppmann publicou Designing Data-Intensive Applications e formalizou no capítulo 11 a distinção que organiza a engenharia de dados moderna:

“A stream refers to data that is incrementally made available over time… in contrast to batch processing, where the input is a known, finite size.”

Bounded vs unbounded. Um conjunto de dados com tamanho conhecido (batch) versus um que nunca termina (stream). Toda decisão de arquitetura de dados começa nessa distinção.

Em 2021, o paper do Lakehouse (Armbrust, Ghodsi, Xin, Zaharia, CIDR) propôs unificar warehouse e lake via metadata layer (Delta, Iceberg, Hudi). Em 2020, o pessoal da dbt Labs popularizou ELT no lugar de ETL: transformação dentro do warehouse, não antes. Cada onda mudou ferramenta, não princípio.

Bounded vs unbounded: a decisão que define tudo

Toda decisão de pipeline começa aqui. Resumo prático em tabela:

Tipo	Característica	Quando usar	Custo
Batch	Dataset finito, processado em janela definida	SLA de horas, relatórios contábeis, snapshots históricos	Simples de construir, debugar, recuperar
Streaming	Dataset infinito, evento processado quando chega	SLA de segundos a poucos minutos, fraude em tempo real, dashboards operacionais	Complexo, exige watermarks, exactly-once, observabilidade pesada
Micro-batch	Streaming em janelas curtas (segundos a minutos)	Meio termo: dashboard de minutos, ML feature store próximo do real-time	Spark Structured Streaming, Flink mini-batches

Tyler Akidau e equipe (Google) publicaram em VLDB 2015 o paper The Dataflow Model que formalizou o vocabulário moderno: event time, processing time, watermarks, triggers, windowing. A frase central:

“A practical approach to balancing the inherent tension between correctness, latency, and cost in massive-scale, unbounded, out-of-order data.”

Tradução: streaming é correto em três variáveis ao mesmo tempo. Você não maximiza as três, escolhe duas e paga a terceira.

Quando batch, quando streaming

A regra prática que eu uso é simples: SLA de latência aceitável define a resposta.

SLA acima de 1h tende a batch. Reprocessamento simples, debugging direto, infraestrutura barata.
SLA abaixo de 1 minuto exige streaming. Quem tenta forçar batch nesse cenário cria janelas tão curtas que reinventa streaming com o pior dos dois mundos.
SLA entre 1 minuto e 1h é zona de micro-batch. Spark Structured Streaming ou Flink mini-batches resolvem.

Jay Kreps, fundador do Confluent, escreveu em 2014 o ensaio Questioning the Lambda Architecture atacando o modelo proposto por Nathan Marz, que mantinha duas camadas paralelas (batch + speed). A frase que ficou:

“The problem with the Lambda Architecture is that maintaining code that needs to produce the same result in two complex distributed systems is exactly as painful as it seems.”

Kreps propôs Kappa: log unificado (Kafka) como fonte de verdade, reprocessamento via replay. Kappa virou padrão em quem opera streaming sério.

O erro mais comum que eu vejo é forçar streaming porque “soa moderno”. Streaming não é versão melhor de batch. É contrato diferente, custo diferente, modelo mental diferente. Quando a decisão é tomada por moda em vez de por SLA, a equipe gasta meses construindo complexidade que o problema não pediu, e eu já passei por essa armadilha mais de uma vez.

O que dá errado quando ignoram o flow

Knight Capital não foi um acidente isolado. O padrão se repete em outras escalas.

GitHub, outubro de 2018: outage de 24 horas. Causa raiz documentada pelo Jason Warner (post-mortem oficial): 43 segundos de partição de rede entre data centers no US East causaram divergência no failover do MySQL Orchestrator, replication storm e inconsistência cross-DC. Foi falha pura de data flow na camada de replicação.

Airbnb, antes da Minerva: equipes diferentes calculavam “active user” com queries divergentes no mesmo Spark cluster. Métricas batiam de cabeça em reuniões executivas. A solução não foi outro dashboard, foi uma camada única de definição de métricas com lineage explícito da fonte ao destino. O Minerva indexa hoje mais de 200 mil data assets.

Esses casos cabem em padrões nomeados na literatura. Vale conhecer cada um:

Pipeline jungle (Sculley et al, NeurIPS 2015, Hidden Technical Debt in Machine Learning Systems): “pipeline jungles often appear as data preparation evolves organically… testing such pipelines requires expensive end-to-end integration tests.” É o que acontece quando ninguém desenhou o flow no começo e ele cresce por adição.
Data swamp (Nick Heudecker, Gartner 2014): “lakes turn into swamps when there is no metadata, governance, or quality control.” Lake virou pasta de arquivos jogados em qualquer lugar.
Schema drift: campos mudam sem aviso entre runs, contratos downstream quebram silenciosamente.
Lineage gaps: ninguém sabe de onde veio o dado que está no dashboard.
Reverse-ETL chaos: dado volta do warehouse pra SaaS sem governança, vira fonte secreta de verdade que ninguém audita.

Como os grandes documentam o próprio flow

Empresas que operam dado em produção real publicam a arquitetura. Vale ler.

Empresa	Documento	Anchor
Netflix	Maestro: Netflix’s Workflow Orchestrator (TechBlog, jul 2024)	Orquestra centenas de milhares de workflows por dia, padrão WAP (Write-Audit-Publish) sobre Iceberg
Uber	Uber’s Big Data Platform (Eng Blog, out 2018)	Hudi reduziu latência de ingestão de 24h para menos de 1h em 100+ PB
Airbnb	Democratizing Data at Airbnb (mai 2017)	Dataportal indexa 200K+ data assets com lineage explícito
Stripe	Online migrations at scale (Eng Blog, fev 2017)	Dual-write + backfill + reconciliation para migrar dados financeiros sem perda
Slack	How We Built Slack’s Data Warehouse (set 2023)	Migração de Presto+Hive para Trino+Iceberg, 60K queries por dia

Padrão comum: cada uma documentou o flow antes de construir a próxima ferramenta. Ferramenta nasceu a partir do diagrama, não o contrário.

Anti-padrões pra evitar

Forçar streaming porque soa moderno. Se SLA é diário, batch resolve com 10% da complexidade.
Construir pipeline sem desenhar o flow primeiro. Pipeline jungle é literalmente isso: crescer sem mapa.
Aceitar lake como “joga tudo aqui que organizo depois”. Vira swamp em 6 meses.
Ignorar schema contracts. Schema drift quebra downstream silenciosamente. Use Schema Registry ou contrato versionado em SQL.
Manter duas implementações paralelas (Lambda). Custo de manutenção dobra, comportamentos divergem, ninguém confia em nenhuma.
Pular lineage. Lineage não é luxo. É a única forma de responder “de onde veio esse número” sem abrir 12 jobs.

Onde começar

Você consegue desenhar, em um guardanapo, o data flow do seu pipeline mais crítico? Fonte exata, transformações principais, destinos, SLA por etapa.

Se sim, está à frente da maioria. Se não, comece por aí. Antes de Spark, antes de dbt, antes de qualquer ferramenta nova.

Os próximos episódios da série Zero to Expert vão entrar em cada camada com profundidade: ingestão (formatos, idempotência, CDC), transformação (SQL vs Python vs Spark), destino (warehouse vs lake vs lakehouse), orquestração. Cada episódio com caso concreto e decisão no centro, não teoria.

Se tem algum conceito específico que você quer ver coberto, me manda no LinkedIn ou assina a newsletter pra receber os próximos episódios.

SLA, não moda: quando batch, quando streaming, quando ambos

Sat, 30 May 2026 00:00:00 +0000

Vi um time de marketing fazer o que toda equipe faz uma vez: adotar streaming porque soava moderno. Kafka gerenciado, workers 24x7, exactly-once de garantia. Pra processar eventos que chegavam a cada 10 minutos. Batch noturno resolveria igual. Custava um décimo. Levou seis meses até alguém medir.

O padrão se repete. Eu já passei pela mesma decisão em quatro domínios diferentes: pipelines de finanças, processos industriais, marketing, analytics. A discussão sempre começa errada. “Vamos pra streaming porque é mais moderno.” Ou “vamos manter batch porque é o que a gente sempre fez.” As duas perdem a pergunta certa.

A pergunta certa é uma só: qual o SLA real do consumidor que vai usar esse dado?

A pergunta certa não é “qual é mais moderno”

Martin Kleppmann formaliza no capítulo 11 de Designing Data-Intensive Applications a distinção que organiza qualquer arquitetura de dados em 2026. Dado bounded (conjunto finito, tamanho conhecido) versus unbounded (fluxo que nunca termina). Toda decisão começa aí.

Mas a distinção bounded/unbounded é técnica, não comportamental. O dado real raramente é só uma coisa. Logs de aplicação são unbounded por natureza. Se eu agrego eles em batches de 1 hora pra alimentar um dashboard que ninguém olha mais de hora em hora, o consumidor está tratando como bounded. O dado é o que o consumo decide.

Tyler Akidau e equipe do Google publicaram em 2015 o paper que virou padrão da indústria, The Dataflow Model. A frase central:

A practical approach to balancing the inherent tension between correctness, latency, and cost in massive-scale, unbounded, out-of-order data.

Tradução: streaming é certo em três variáveis ao mesmo tempo. Correção, latência e custo. Você escolhe duas, paga a terceira. Batch é mais simples justamente porque não tenta otimizar latência.

Tabela de decisão: SLA × tecnologia

Pra a maioria dos pipelines que vejo, a tabela acima resolve a decisão em 30 segundos. SLA acima de 1 hora é território de batch. SLA abaixo de 1 minuto exige streaming. O meio é micro-batch, e a maioria dos casos cai aí, não nos extremos.

Quando batch ganha (mesmo em 2026)

Spotify roda recomendação em batch noturno no BigQuery. Netflix tem o Maestro orquestrando centenas de milhares de workflows por dia com padrão Write-Audit-Publish sobre Iceberg. Nenhuma das duas é “atrasada”. Elas escolheram batch onde batch resolve melhor.

Batch ganha quando:

O SLA do consumidor é horário ou diário (relatório contábil, fechamento, snapshot histórico, ML training)
O dado de entrada é estável o suficiente pra você reprocessar quando quiser
Seu time tem mais facilidade em debugar Python rodando 1 vez por noite do que stream processor 24x7

O custo importa muito. Cluster Spark batch noturno fica desligado durante o dia. Infraestrutura quando não tem job rodando: zero. Kafka gerenciado fica ligado 24x7. Confluent Cloud Standard começa em 1 a 3 mil dólares por mês, e o egress pode chegar a 47 mil dólares por mês em 300 MiB/s de saída. A diferença sobre o ano é o salário de um engenheiro pleno em Curitiba.

Quando streaming é a única resposta

Pix tem SLA de menos de 10 segundos, 24x7. O BACEN publica isso. Batch diário não funciona. Não é opcional. Sistema de detecção de fraude em ponto de venda também é assim: ou identifica antes da transação fechar ou não serve pra nada. Dashboard de operações em call center, mesma lógica: o agente precisa ver o cliente atualizado no instante em que atende.

Esses casos não admitem batch. Streaming é a única resposta.

Pra eles, Flink entrega latência abaixo de 100 milissegundos. Spark Structured Streaming fica em 100 milissegundos a 1 segundo (micro-batch). Kafka Streams roda embutido na aplicação, sem cluster próprio, e processa cerca de 1 milhão de eventos por segundo. A escolha entre os três é outro post.

Uber é o caso mais interessante. Adotou streaming sem virar 100% streaming. Adicionou o Hudi pra incremental processing e baixou latência de ingestão de 24 horas pra menos de 1 hora em mais de 100 PB. O Flink IngestionNext deles consome 25% menos compute que o batch antigo. Streaming bem feito também economiza, desde que resolva o problema certo.

Quando “ambos” é a resposta certa

Jay Kreps publicou em 2014 o ensaio que matou a Lambda Architecture. Lambda mantém duas pipelines paralelas pra produzir o mesmo resultado: uma batch confiável, uma streaming rápida. A frase que ficou:

The problem with the Lambda Architecture is that maintaining code that needs to produce the same result in two complex distributed systems is exactly as painful as it seems.

Kreps propôs Kappa: log único (Kafka) como fonte de verdade, com reprocessamento via replay. Batch vira caso especial de streaming sobre o histórico.

O Lakehouse foi um passo a mais. O paper do Databricks de 2021 propõe uma camada de metadata (Delta, Iceberg, Hudi) que serve as duas naturezas. O mesmo dado pode ser consumido em batch pela equipe de BI e em streaming pela aplicação de fraude. Não tem 2 stacks. Tem contrato único.

“Ambos” não é covardia técnica. É design consciente quando você tem consumidores com SLAs diferentes sobre o mesmo dado.

Perguntas que decidem o caso

Antes de abrir Terraform ou docker-compose, responde isso honestamente:

Qual o SLA real do consumidor que vai ler esse dado? Não o SLA que você imagina. O que ele de fato precisa.
Esse SLA é diferente por consumidor? Se sim, considera Lakehouse com contrato único, não 2 pipelines paralelas.
Quanto custa rodar 1 mês de streaming vs batch nesse volume? Faz a conta antes, não depois do invoice.
Seu time tem maturidade pra debugar exactly-once, watermarks e estado distribuído? Se não, o custo de aprender vem embutido no projeto.
Você já tem infraestrutura de batch ou streaming rodando? Reaproveitar reduz risco. Greenfield permite escolher melhor.

Se você respondeu honestamente as 5 e ainda assim chegou em streaming, ótimo. Streaming faz sentido. Se chegou em batch, ótimo também. Batch resolve a maioria dos casos.

O erro não é escolher streaming. O erro é escolher streaming sem responder as 5.

Qual foi o pipeline que você escolheu errado e teve que refazer depois? Me conta no LinkedIn ou responde esse email. Quero ver quantos casos batem.

Airflow por 2 anos: o que eu faria diferente

Sun, 24 May 2026 00:00:00 +0000

Era 2h da manhã quando o alerta chegou. O DAG de relatório mensal tinha falhado no step 8 de 12. Dados financeiros, prazo 6h da manhã, e eu passei as 4 horas seguintes tentando entender se a task realmente falhou, se foi timeout silencioso, ou se o worker tinha morrido sem avisar ninguém. Quando descobri que era a terceira coisa, faltavam 40 minutos.

Esse cenário é rotineiro em times que usam Airflow em produção. O Airflow funciona. E também cria trabalho que ninguém avisa no primeiro tutorial.

Esse post não é para convencer ninguém a abandonar o Airflow. É sobre o que vale mudar antes que o problema apareça.

Contexto: o que é e quem usa

O Airflow foi criado por Maxime Beauchemin no Airbnb em outubro de 2014 para orquestrar pipelines de dados com dependências complexas. Virou open source em junho de 2015 e projeto top-level da Apache Foundation em janeiro de 2019.

Hoje é o orquestrador de dados mais usado no mundo: 320 milhões de downloads só em 2024, dez vezes mais que o segundo colocado. Uber roda 200.000 pipelines com 750.000 task runs por dia. Shopify tem 10.000 DAGs ativos. Stripe processa 150.000 tasks diárias.

É adoção real, não hype.

Mas o mesmo relatório que aponta esses números também revela que 46% dos usuários dizem que quando o Airflow tem problema, a operação inteira para. Essa é a tensão que ninguém conta no primeiro tutorial.

O que o Airflow resolve bem

Dependências entre tasks são garantidas. Você define o grafo em Python. O Airflow garante que task B só roda quando task A termina com sucesso. Com 50 tasks interdependentes num pipeline financeiro, ter isso garantido por um orquestrador evita reescrever lógica de retry e dependência em cada DAG, e elimina a categoria inteira de bug “task rodou antes da hora porque o cron disparou”.

Retry com backoff é nativo. Duas linhas e sua task tenta de novo automaticamente. Em pipelines que dependem de APIs externas instáveis, isso elimina alertas às 2h da manhã para erros transitórios.

O histórico de execução é auditável. Toda execução, cada task, cada log fica registrado. Quando compliance pergunta “o relatório de março foi gerado com dados de 31/03 ou de 01/04?”, você abre o Airflow e responde em segundos.

Backfill funciona. Pipeline parado por três dias? Você reprocessa as execuções históricas com um comando. Para pipelines que precisam de histórico completo e consistente, isso importa muito.

Onde o Airflow complica

O scheduler parseia todo o seu código a cada 30 segundos

O scheduler precisa executar o código Python de cada arquivo DAG repetidamente para entender o que existe e quais são as dependências. Com 200 DAGs, esse ciclo de parse pode levar minutos.

O que torna isso crítico: 98% dos casos de lentidão no scheduler são causados por imports pesados no nível do módulo. Um arquivo que faz import pandas as pd no topo, fora de qualquer função, faz o scheduler executar esse import a cada ciclo. Em 200 DAGs com imports pesados, isso vira minutos de parse antes de qualquer task executar.

# Errado: pandas é importado a cada ciclo do scheduler
import pandas as pd

@dag
def pipeline():
    ...

# Certo: import apenas quando a task executa
@task
def processar():
    import pandas as pd
    ...

XCom tem limite severo que ninguém avisa no começo

XCom é o mecanismo do Airflow para tasks se comunicarem. O problema: foi projetado para mensagens pequenas, não para dados.

No PostgreSQL, o limite default de linha é 8KB. Um DataFrame de 1.000 linhas vai explodir o XCom. Em produção, o erro aparece como timeout ou crash silencioso do metadata database, não como uma mensagem clara de “dado grande demais”.

A solução usada em produção: passar apenas o path no S3 via XCom, nunca o dado em si.

catchup=True já disparou backfills indesejados em muitos times

Por padrão em versões antigas, se você reimplantar um DAG com start_date no passado e catchup=True, o Airflow vai criar e tentar executar todas as runs históricas desde start_date. Com um DAG mensal e start_date dois anos atrás, isso são 24 runs disparadas de uma vez.

A DoubleVerify documentou que depois de migrar para um setup com catchup=False como padrão do cluster e outras mudanças, os incidentes caíram 80%.

Renomear um DAG perde todo o histórico

Não existe operação de rename no Airflow. Renomear um DAG cria uma entrada nova no metadata database e perde todo o histórico de execuções. Em produção, isso significa que você não consegue comparar o comportamento atual com o passado, e qualquer alert que dependa do histórico quebra.

Lógica de negócio dentro do operador vira problema depois

A tentação é colocar transformações e regras de negócio direto dentro do PythonOperator. Funciona no começo. Depois de seis meses, você tem lógica não testável presa dentro de infraestrutura, a mesma regra duplicada em três operadores diferentes, e um DAG que só dá para debugar subindo o Airflow inteiro.

O padrão correto: o operador é infraestrutura e chama funções testáveis que vivem fora do DAG.

O que eu faria diferente

TaskFlow API desde o primeiro dia. Lançada no Airflow 2.0, permite escrever DAGs com decoradores Python em vez de instanciar operadores manualmente. O código fica mais limpo, as dependências ficam implícitas no fluxo, e é mais fácil de testar. Passei tempo demais escrevendo no estilo antigo antes de migrar.

catchup=False como padrão do cluster na configuração inicial. Uma linha em airflow.cfg que evita dezenas de incidentes.

Resource pools desde o primeiro DAG. Por padrão o Airflow não limita quantas tasks de um DAG rodam em paralelo. Um DAG pesado pode consumir todos os slots e bloquear os outros. Configurar pools antes do primeiro problema, não depois.

Nada de multi-tenant numa mesma instância. Compartilhar uma instância Airflow entre times diferentes cria conflitos de dependências Python, falta de isolamento de recursos, e upgrade paralysis: um time não consegue atualizar sem coordenar com todos os outros. Uma instância por time é o padrão recomendado.

Monitorar o scheduler, não só as tasks. O scheduler é o coração do Airflow e pode degradar silenciosamente. Grafana no heartbeat do scheduler identifica problemas antes que as tasks comecem a falhar.

Sobre o Airflow 3.0

Em abril de 2025 o Airflow lançou a versão 3.0, a maior release da história do projeto. Ela resolve problemas que a comunidade documentou durante anos: Task Execution API que elimina a necessidade dos workers acessarem diretamente o banco de metadados, DAG Versioning nativo, interface React reconstruída, e suporte a tasks em múltiplas linguagens além de Python.

Se você está começando um projeto novo, avalie o Airflow 3.0 antes de escolher a versão a instalar. As mudanças são breaking, então migrar um cluster existente exige planejamento.

Quando avaliar alternativas

O Airflow tem 320 milhões de downloads por uma razão: ele funciona, tem o maior ecossistema de integrações do mercado, e a comunidade é vasta.

Mas existem casos onde outras ferramentas resolvem melhor:

Prefect ou Dagster para times menores que valorizam desenvolvimento local simples, workflows event-driven, e observabilidade mais rica sem overhead operacional do Airflow.

dbt Cloud quando a maioria dos pipelines são transformações SQL num warehouse. A orquestração nativa é mais simples para esse caso específico.

Airflow gerenciado (Astronomer, Amazon MWAA, Google Cloud Composer) se o custo cabe e você não quer manter a infraestrutura. Remove parte significativa da dor operacional.

O que não vale é escolher pela popularidade sem avaliar se o problema que o Airflow resolve é o seu problema.

O que fica

O Airflow funciona bem para o que foi feito: orquestrar pipelines batch com dependências complexas, histórico auditável e retry confiável.

Os problemas que encontrei foram quase todos evitáveis com configuração correta desde o início: imports fora de funções, XCom para dados grandes, catchup sem controle, lógica de negócio dentro de operadores.

Se você está começando: imports dentro das funções, catchup=False no cluster, XCom só para coordenação, lógica de negócio em módulos testáveis separados. São quatro decisões que evitam a maioria dos problemas que eu encontrei.

Qual foi o problema mais irritante que você já viu com Airflow? Me conta no LinkedIn ou assina a newsletter.

Vinte conceitos de IA que você precisa entender em 2026

Sat, 23 May 2026 00:00:00 +0000

Toda semana aparece um termo novo de IA. Agente, RAG, fine-tuning, embedding, top-p, RLHF. Você abre o LinkedIn e três pessoas já estão “construindo agentes autônomos” antes do café da manhã. No Twitter alguém reclama que o RAG dele alucina, enquanto o post do lado debate se vale a pena fine-tunar Llama 3. Aí você vai na documentação da API que ia testar pra resolver uma coisa simples e cai num glossário de cem palavras antes da primeira chamada útil.

O problema não é a quantidade de termos. É que ninguém para pra desenhar como eles se conectam.

Esse infográfico é a minha tentativa de mapa. Vinte conceitos, seis seções, uma sequência que faz sentido se você for da base pra fronteira. Está longe de cobrir tudo que existe em IA. Mas dá pra abrir ele numa reunião técnica em 2026 e entender do que estão falando, ou ler o código de um sistema agêntico e identificar o que cada peça faz no fluxo.

Como a IA funciona (1 a 4)

Tudo começa em redes neurais. Camadas de neurônios conectados por pesos, ajustados durante o treinamento pra fazer previsões. É a única primitiva de tudo isso. Modelo que vê imagem, modelo que escreve texto, modelo que entende áudio: todos são variações dela, com escolhas diferentes de arquitetura por cima.

Pra linguagem entrar nessa rede, precisa virar número. Esse é o trabalho da tokenização: quebrar texto em pedaços que o modelo consegue mastigar. A IA não lê palavras. Lê tokens. Depois cada token vira um vetor num espaço de centenas de dimensões, e isso é embedding. Significados parecidos ficam perto. É o que faz busca semântica, recomendação e RAG funcionarem.

E no topo desses três vem atenção. O mecanismo que deixa cada palavra olhar pra todas as outras da entrada e decidir o que importa pra ela. Antes de atenção, modelos liam texto em sequência e esqueciam o começo no meio da frase. Atenção quebrou esse gargalo. Sem ela, o resto da IA contemporânea simplesmente não existiria no formato que a gente conhece hoje.

A mágica por trás (5 a 8)

Transformers são a arquitetura que empacotou atenção em algo treinável em paralelo. Antes deles, modelos de linguagem eram lentos e curtos. Depois deles, viraram GPT, Claude, Gemini.

Mas arquitetura sem dado é nada. Pré-treinamento é a fase em que o modelo lê o equivalente a uma biblioteca de Alexandria. Trilhões de tokens. É aqui que ele absorve sintaxe, gramática, fatos sobre o mundo e os padrões de raciocínio que os humanos deixaram escritos. Ajuste fino é o que vem depois: pegar esse modelo geral e especializar em tarefa específica com dado específico. E RLHF é a etapa que pegou modelos que sabiam responder qualquer coisa e ensinou eles a responder de um jeito que serve pra alguém. Pessoas reais comparam saídas, dizem qual é melhor, o modelo aprende a preferência. É o que separa “modelo que sabe muito” de “modelo que conversa bem”.

Além dos modelos (9 a 12)

Modelo nenhum vai pra produção sozinho. Em volta dele vai uma camada de salvaguardas: filtros e classificadores construídos sobre regras explícitas, pra evitar que o sistema diga coisa que machuca alguém ou que reproduz viés óbvio. É a parte chata que ninguém quer construir e que todo produto sério precisa ter.

E quando o modelo precisa saber algo que não estava no pré-treinamento, entra RAG. Geração aumentada por recuperação. O sistema busca documentos relevantes, injeta no contexto, e o modelo responde ancorado neles. RAG depende de dois primos: bancos vetoriais (que armazenam embeddings de forma que dá pra achar o mais parecido em milissegundos) e fragmentação (que quebra documentos grandes em pedaços indexáveis). RAG sem boa fragmentação é RAG que alucina elegantemente. Eu vi mais sistema RAG quebrar por chunking ruim do que por qualquer outro motivo isolado.

Como a IA gera saídas (13 a 14)

Quando o modelo responde, ele não escreve a frase inteira de uma vez. Ele prevê um token, depois o próximo, depois o próximo. Isso é decodificação. E o jeito que ele escolhe cada próximo token muda completamente o caráter da saída. Temperatura alta dá criatividade e variação. Top-p baixo dá foco nas opções mais prováveis. Mexer nesses dois parâmetros é a diferença entre um modelo que escreve poesia e um modelo que escreve documentação técnica.

Como a IA age (15 a 16)

Até aqui o modelo só responde. Agentes são o passo seguinte: ele decide e age. Recebe um objetivo, decompõe em passos, escolhe qual ferramenta usar, executa, observa o resultado, ajusta o próximo passo. Ferramentas e funções são as mãos que damos pra esse agente: API, calculadora, busca, execução de código, acesso a banco. Sem isso o agente fica preso na própria cabeça falando sozinho. Toda a parte que importa de sistema agêntico começa quando o modelo finalmente pode chamar alguma coisa que muda estado no mundo real.

Melhoria e avaliação (17 a 20)

Sistema agêntico sem planejamento explícito vira caos rápido. Sem avaliação rigorosa, qualquer afirmação sobre o modelo virou torcida. Melhoria iterativa é o que separa protótipo bonito de sistema que sobrevive em produção: testar, medir, ajustar, repetir. E viés e justiça tem uma característica chata: se você ignora no design, vai te encontrar no incidente.

Fechamento

IA não é mágica. É matemática com dados em cima, lógica em volta e iteração no centro. Quem entende esses vinte conceitos lê arquitetura de sistema agêntico sem se perder no glossário. Consegue debugar comportamento esquisito do modelo a partir de hipóteses reais, não chute. E numa conversa técnica fala como quem participou da construção, não como quem leu o release.

Pega o infográfico. Salva no celular, imprime e cola na parede, joga no Notion. Eu volto nele toda vez que aparece um termo que parece novo, e quase sempre o termo é um caso particular de um desses vinte. E mais importante que tudo isso: constrói alguma coisa com ele. É quando você tenta fazer um RAG funcionar de verdade que descobre o que cada uma dessas palavras realmente quer dizer.

Esse é o primeiro post da trilha IA Foundations no VazDEng. Por lá saem três posts por semana sobre engenharia de dados em português, no nível sênior que faltava na BR.

Quando o modelo deveria dizer 'não sei'

Sun, 17 May 2026 00:00:00 +0000

Em setembro de 1998, a Long-Term Capital Management perdeu 4.6 bilhões de dólares em algumas semanas. Os modelos de spread foram treinados em correlações de tempo normal. O default russo e a fuga subsequente para qualidade fizeram correlações que historicamente eram 0.3 convergirem para 1 em dias. Em When Genius Failed, o Lowenstein cita o cálculo interno do fundo sobre a probabilidade do que aconteceu:

“An event so freakish as to be unlikely to occur even once over the entire life of the universe.”

Os modelos estavam tecnicamente corretos. Estavam só extrapolando confiança numa região do espaço que nunca tinham visto. Não tinham botão de “não sei”.

Meu agente quant tinha o mesmo problema, em escala incomparavelmente menor mas com a mesma natureza. Resolvi essa semana.

Em uma frase

Conservative degradation é o princípio que diz que um modelo precisa ter o direito de abster. Quando os dados estão fora do que ele viu, devolver “não sei” é mais útil que devolver uma classificação espúria com confiança matemática alta.

O ponto cego que sobrava depois do data leakage

O post anterior fechou o capítulo do Sharpe -1.14. Posterior virou causal, data leakage saiu, número ficou honesto. Mas tinha um ponto cego que não aparecia no Sharpe.

O HMM gaussiano de 3 estados sempre classifica. Recebe um candle, calcula posterior sobre BULL/SIDEWAYS/BEAR, e devolve aquela com maior probabilidade. Por construção. Se as features estão na zona normal de treino, ótimo. Se estão completamente fora, ele continua classificando, e a posterior continua somando 1.

Cenário concreto: ATR diário 4x acima da média de 90 dias, funding rate em extremo negativo histórico, volume 10x acima do normal. Um pico que o modelo simplesmente não tem ponto de referência. O HMM devolve algo como “BULL com 73% de confiança”, porque uma das três classes vai ganhar.

Matematicamente legítimo. Operacionalmente perigoso.

O que a literatura chama disso

Olhei a literatura antes de implementar nada. Três fios convergem.

Out-of-Distribution detection (visão computacional, ML clássico). A linhagem começa em Hendrycks & Gimpel 2017 (“A Baseline for Detecting Misclassified and Out-of-Distribution Examples in Neural Networks”), que mostra que a probabilidade máxima do softmax já é um sinal razoável de confiança. Liang et al 2018 (ODIN) adiciona temperature scaling e perturbação adversarial, reduzindo false positive rate de 34.7% para 4.3%. Lee et al 2018 propõe Mahalanobis distance no espaço de features pra capturar covariância entre dimensões. Os três são o canon de OOD.

Selective classification (estatística, reconhecimento de padrões). Chow 1957 já formalizou o reject option em IRE Trans. Electronic Computers. Em 1970 ele deriva a curva error-reject ótima. Em 2017, Geifman e El-Yaniv levam o conceito pra deep learning com garantia formal de risco:

“We can achieve a target coverage with a guaranteed level of risk.”

A métrica canônica de avaliar abstenção é AURC (Area Under Risk-Coverage curve): mostra como o erro cai conforme o modelo se permite rejeitar mais casos.

Sistemas críticos com conservative degradation. Aviação tem regulamentação explícita (FAA AC 25.1329-1B): autopilot deve alertar quando envelope protection é invocada e desengajar em condições off-nominal. SAE J3016 (autonomous driving) define Operational Design Domain (ODD) e exige que o sistema saia de operação ou peça takeover quando opera fora dele. O princípio é o mesmo: modelo treinado pra condições X não opera em Y, ele alerta e devolve controle.

Trading se beneficia desse vocabulário. Foi o que faltava.

Já fizeram isso em finanças

Dois precedentes pra ancorar.

Kritzman e Li 2010 (“Skulls, Financial Turbulence, and Risk Management”, Financial Analysts Journal). Definem o Turbulence Index como distância de Mahalanobis multivariada dos retornos contra média e covariância históricas. Frase central:

“The more asset returns, volatilities and correlations differ from their historical norms, the more likely it is that these differences result from a significant market event rather than from random noise.”

Empiricamente o índice alinha com 1987, default russo de 98, 9/11, e crise de 2008. Turbulência é persistente, o que justifica abster por janelas, não por tick isolado.

Chalkidis et al 2021 (“Trading via Selective Classification”, ACM ICAIF, arXiv 2110.14914). Esse paper é o caso direto do que eu fiz. Classificador binário up/down vira estratégia que toma posição apenas quando confia, e abstém quando não confia. Resultado empírico: coverage menor com mesmo risco melhora Sharpe. A frase do abstract:

“Selective classifiers give rise to trading strategies that do not take a trading position when the classifier abstains.”

Selective classification em trading não é meu insight. É tema documentado em ACM. O que faltava era trazer pro meu HMM.

Como implementei

As features do HMM passam por StandardScaler antes do treino. No espaço escalado, a média de cada feature é zero e o desvio é um. Qualquer candle novo com uma feature em z-score absoluto muito alto está, por definição, fora da distribuição que o modelo viu.

Limite em 5 sigmas (conservador, cripto tem fat tails). Método estático no MarketRegimeHMM:

@staticmethod
def is_ood(x_scaled_row, threshold=OOD_SIGMA_THRESHOLD):
    if x_scaled_row.size == 0:
        return False
    return bool(np.nanmax(np.abs(x_scaled_row)) > threshold)

E o predict_state checa antes de chamar a posterior:

if self.is_ood(last_features):
    logger.warning("OOD detectado: max |z| = %.2f > %.1f. Abstem-se.",
                   max_dev, OOD_SIGMA_THRESHOLD)
    return REGIME_OOD, 0.0, {REGIME_OOD: 1.0}

Downstream da decisão (decide_position na camada 4) já tinha lookup em REGIME_MULTIPLIER. Adicionei "OOD": 0.0 por defesa em camadas, e log explícito de “ABSTAIN” pra deixar visível quando o sistema preferiu não operar.

70 testes passaram, mais 2 novos cobrindo o caminho OOD. Suite completa em 6 segundos.

Cenário	Antes	Depois
Features dentro da distribuição	Classifica BULL/SIDEWAYS/BEAR com posterior real	Igual
Features 5+ sigmas fora (raras)	Classifica mesmo assim, com posterior espúria	Retorna OOD, sizing zera
Log do tick OOD	Não havia distinção	“ABSTAIN: regime sem playbook (OOD, conf=0.000)”
Trade aberto em condição anômala	Possível, com cap de 2%	Impossível

Por que 5 sigmas, não 3

A escolha do threshold é o ponto onde teoria encontra dados reais de cripto. Em features gaussianas perfeitas, 3 sigmas cobririam 99.73% e seria razoável. Cripto não é gaussiana. Realized volatility, funding rate, e DI spread têm caudas pesadas. Bulla 2011 (Quantitative Finance) já mostrou que HMM gaussiano subestima caudas em retornos financeiros, propondo Student-t em vez.

Em 5 sigmas, o detector dispara só quando o tick está em região genuinamente sem precedente recente. Em 3, dispararia em movimentos grandes mas históricos, gerando abstenção excessiva. A próxima iteração é trocar z-score univariado por Mahalanobis multivariada (capta correlação entre features), que é exatamente o que Kritzman-Li fizeram em 2010 para retornos.

O que mudei no sono

O número mais útil pra mim não é o aumento ou queda de Sharpe (vou medir em backtest na próxima semana). É o seguinte:

Antes, quando o agente tomava uma posição na madrugada e eu acordava com Telegram piscando, eu precisava abrir o auditor e ler decisão por decisão pra entender se o modelo tinha alguma lógica naquele momento ou se estava chutando em mercado caótico.

Agora, se o sistema abstém, o log diz ABSTAIN. Se opera, é porque estava em território que ele viu. A pergunta “essa decisão tem base?” virou binária: existe um log de ABSTAIN antes, ou não.

Nick Leeson, Jérôme Kerviel, LTCM, Knight Capital. A história de perdas operacionais em finanças quase sempre tem o mesmo padrão: um sistema continuando a tomar decisão quando não devia. O custo do “não sei” sempre foi mais barato que o custo do “achei que era”.

Anti-padrões pra evitar

Aceitar posterior alta como evidência de boa decisão. A posterior de um HMM sempre soma 1. Confiança é métrica intra-modelo, não evidência de que o modelo entende o que está vendo.
Usar threshold de OOD baseado em intuição, não em distribuição. 3 sigmas funciona em gaussiana pura. Cripto não é gaussiana. Mede a cauda real do teu dado primeiro.
Abster por tick isolado e voltar a operar no próximo. Turbulência é persistente. Bom design abstém por janela, não por candle.
Adicionar OOD sem mexer no decisor. Detector que não muda comportamento downstream é decoração. O REGIME_MULTIPLIER é onde o efeito acontece.
Esconder a abstenção do log. Se o sistema preferiu não operar, isso é decisão. Tem que aparecer no audit trail com o motivo, não silenciosamente.

O próximo capítulo

A versão atual usa um único critério (z-score absoluto por feature). Duas extensões já estão em backlog: Mahalanobis distance no espaço completo (captura covariância, é o que Kritzman-Li implementaram pra retornos em 2010) e likelihood do tick sob o modelo HMM treinado (mais sensível, mais caro).

Por enquanto, o que está em produção é a versão simples. E ela já mudou o que eu olho quando acordo.

Você já teve um modelo que devolveu confiança alta numa decisão que não deveria ter sido tomada? Me conta no LinkedIn ou assina a newsletter para receber os próximos posts.

Instrumentando lineage do zero com Unity Catalog

Wed, 13 May 2026 00:00:00 +0000

Quando me perguntam “de onde vem esse número?”, tenho duas respostas possíveis.

A primeira é abrir o código, rastrear manualmente qual job leu de qual tabela, entender quais transformações foram aplicadas, e voltar até a fonte. Em pipelines com 20 steps isso pode levar horas.

A segunda é abrir o Unity Catalog, clicar na coluna em questão, e ver o grafo completo: fonte, transformações, tabelas intermediárias, destino. Em segundos.

Essa diferença é o que lineage resolve na prática. Mas o Unity Catalog não captura tudo automaticamente. Entender o que ele cobre e o que exige trabalho adicional é o que separa uma implementação que funciona de uma que dá falsa sensação de segurança.

O que o Unity Catalog captura automaticamente

O Unity Catalog intercepta os planos de execução do Spark em runtime e registra cada leitura e escrita em tabelas do metastore. Não precisa de configuração extra no código.

Lineage de tabelas funciona para qualquer operação SELECT, CREATE TABLE AS SELECT, INSERT INTO SELECT em qualquer linguagem: Python, SQL, Scala, R. Para cada operação, o sistema registra qual tabela foi lida, qual foi escrita, em qual job, em qual notebook, com qual usuário, em qual horário.

Lineage de colunas vai além: mapeia quais colunas de origem alimentam quais colunas de destino. Requer Databricks Runtime 11.3 LTS ou superior para jobs comuns. Para Delta Live Tables, requer 13.3 LTS ou superior.

Essas informações ficam acessíveis de duas formas: pelo Catalog Explorer com interface visual, e pelos system tables system.access.table_lineage e system.access.column_lineage para quem precisa programaticamente.

O que não é capturado e onde a maioria erra

A documentação oficial é clara mas discreta sobre as limitações. Vi essas limitações morderem em produção mais de uma vez.

UPDATE, DELETE e INSERT VALUES não geram edges de lineage. Essa é a limitação mais crítica para quem trabalha com CDC, SCD Type 2, ou qualquer pipeline com atualizações in-place. O dado foi modificado, mas o Unity Catalog não registra essa relação.

MERGE INTO não captura lineage por padrão. É possível ativar com spark.databricks.dataLineage.mergeIntoV2Enabled, mas exige configuração explícita em cada cluster ou job.

RDDs não são suportados. A Unity Catalog API não funciona com RDD e portanto qualquer pipeline que use a API de baixo nível do Spark fica completamente fora do rastreamento.

Objetos renomeados perdem o histórico permanentemente. Se você renomear uma tabela, um schema ou um catálogo, o lineage histórico quebra. Não existe migração automática do grafo quando o objeto muda de nome.

JDBC connections fazem bypass completo. Dados lidos ou escritos via JDBC não passam pelo mecanismo de captura do Unity Catalog.

Tabelas referenciadas por path (s3://…) não capturam column lineage. Table lineage via path funciona, mas mapeamento de colunas não.

E um detalhe prático importante: os system tables só têm dados a partir de setembro de 2024. Se você precisa de lineage histórico antes dessa data, não existe nos system tables.

Multi-hop lineage: o que o Catalog Explorer não mostra

O visualizador do Catalog Explorer exibe apenas um hop em cada direção: uma tabela upstream e uma tabela downstream imediata. Se o dado passou por cinco transformações, você vê só a adjacente.

Para rastrear a cadeia completa, a abordagem é fazer queries iterativas nos system tables:

-- Encontrar todos os ancestrais de uma tabela (multi-hop)
WITH RECURSIVE lineage AS (
  SELECT source_table_name, target_table_name, 1 as hop
  FROM system.access.table_lineage
  WHERE target_table_name = 'minha_tabela_gold'

  UNION ALL

  SELECT l.source_table_name, tl.target_table_name, lineage.hop + 1
  FROM system.access.table_lineage tl
  JOIN lineage l ON tl.target_table_name = l.source_table_name
)
SELECT * FROM lineage ORDER BY hop;

Databricks não suporta CTE recursiva nativa nos system tables. Na prática, isso precisa de lógica iterativa em Python que vai fazendo a query por nível.

OpenLineage como complemento

Para pipelines que saem do ecossistema Databricks (Airflow orquestrando jobs externos, dbt rodando num warehouse diferente, scripts Python com pandas), o OpenLineage é a alternativa mais usada para unificar lineage cross-platform.

O OpenLineage integra via OpenLineageSparkListener e captura lineage de S3, GCS, JDBC, Redshift e BigQuery. A integração existe, mas tem bugs documentados com Databricks Spark 3.4+: payloads gerados às vezes contêm apenas inputs sem outputs, e há incompatibilidades entre a versão do agente Spark 3.3 do OpenLineage e a implementação 3.4.1 do Databricks.

Se OpenLineage é crítico no seu setup, verifique a compatibilidade de versão antes de ir para produção.

O que instrumentar manualmente

Para ter lineage completo em pipelines reais, essas são as lacunas que precisam de trabalho adicional:

Ferramentas de BI (Tableau, Power BI, Looker) precisam de connector explícito ou cadastro manual via External Lineage API, que está em Public Preview. O limite é de 10.000 objetos externos e 100.000 relações por metastore.

Orchestradores externos (Airflow, Prefect) precisam de integração via API para que os jobs apareçam no grafo de lineage.

Pipelines com UPDATE/DELETE extensivos precisam de logging complementar via system.query.history para auditoria, já que o lineage automático não cobre essas operações.

Por onde começar do zero

Se você está instrumentando lineage pela primeira vez num ambiente Databricks:

Primeiro, confirme que os clusters e jobs estão em workspaces com Unity Catalog habilitado. Sem isso, nenhuma captura automática funciona.

Segundo, valide o Databricks Runtime: 11.3 LTS ou superior para column lineage em jobs comuns. Projetos mais antigos rodando em runtimes abaixo disso não vão ter column lineage mesmo com Unity Catalog ativo.

Terceiro, mapeie quais pipelines usam UPDATE/DELETE/MERGE extensivamente. Para esses, defina desde o início qual será a estratégia de auditoria complementar, seja via system.query.history ou via logging explícito no código.

Quarto, crie uma query de validação que roda semanalmente contra os system tables e verifica se tabelas críticas têm lineage registrado. Ausência de lineage em tabela importante é sinal de que algo saiu do scope de captura.

Lineage não é uma feature que se ativa e esquece. Eu uso como prática contínua: a cada pipeline novo, valido o que o Unity Catalog capturou e o que ficou de fora.

Com qual parte do lineage você tem mais dificuldade hoje? Me conta no LinkedIn ou assina a newsletter.

Quando a Medallion Architecture atrapalha mais do que ajuda

Tue, 12 May 2026 00:00:00 +0000

Existe um padrão de arquitetura que vi crescer desde 2020, criado pelo Databricks, adotado pela Microsoft como padrão oficial da plataforma Fabric em 2023, e que hoje está em quase toda conversa sobre engenharia de dados: o Medallion Architecture.

Bronze, Silver, Gold. Dado bruto, dado limpo, dado agregado.

O problema não é o padrão. O problema é que ele virou resposta automática. E quando qualquer arquitetura vira resposta automática, ela começa a criar mais problema do que resolve.

O próprio Databricks deixa isso claro na documentação oficial: “Following the medallion architecture is a recommended best practice but not a requirement.”

Isso raramente aparece nas apresentações.

O que é Medallion Architecture, de verdade

O Databricks define assim: um padrão de design que organiza dados em um lakehouse em camadas que progressivamente melhoram a estrutura e qualidade do dado, da Bronze para a Silver para a Gold.

Bronze guarda o dado exatamente como veio da fonte, sem nenhuma transformação. É o arquivo histórico imutável. Se algo der errado nas camadas seguintes, você volta aqui.

Silver aplica o mínimo de transformação necessário para criar uma visão consistente da empresa: limpeza, padronização, deduplicação, joins entre fontes. É onde o dado vira informação confiável.

Gold organiza os dados para consumo específico: dashboards de analytics, modelos de ML, relatórios financeiros. É desnormalizada, otimizada para leitura, pensada para o usuário final.

Vale um dado histórico: o conceito de pipeline em camadas não é novo. Data Warehousing dos anos 1990 já usava staging, cleansed e presentation layers. O que o Databricks criou em 2020 foi a terminologia Bronze/Silver/Gold e o branding “Medallion”, não o princípio em si. Isso não torna o padrão inválido, só ajuda a entender o que é inovação e o que é nomenclatura.

Quando Medallion funciona bem

O padrão resolve três problemas reais, e resolve bem.

Primeiro: reprocessamento sem perda. Quando um bug aparece na transformação Silver, você volta ao Bronze e reprocessa sem precisar buscar os dados novamente na fonte. Em sistemas onde a fonte só mantém os últimos 90 dias de histórico, essa proteção pode ser a diferença entre corrigir um problema e perder dois anos de dados.

Segundo: múltiplas equipes com necessidades diferentes. O time de analytics precisa de totais por mês. O time de ciência de dados precisa do dado no menor grão para treinar o modelo. Os dois compartilham o Silver, cada um constrói sua camada Gold de forma independente. Sem duplicação do trabalho de limpeza, sem inconsistência entre as visões.

Terceiro: separação de responsabilidade em times grandes. A equipe de ingestão cuida do Bronze sem precisar conhecer as regras de negócio. A equipe de transformação cuida do Silver sem depender da equipe de ingestão. Em organizações com mais de 20 profissionais de dados trabalhando em paralelo, isso reduz acoplamento e bloqueios.

Quando esses três problemas existem, Medallion é uma escolha sólida. Quando não existem, você está adicionando complexidade sem contrapartida.

Onde Medallion começa a atrapalhar

Quando há um único consumidor

Você tem um pipeline que ingere dados de folha de pagamento para alimentar um único dashboard de RH. Uma equipe consome, uma finalidade, uma transformação.

Aplicar Medallion aqui significa criar Bronze, Silver e Gold para servir exatamente a mesma coisa. O dado passa por três camadas de leitura e escrita, três conjuntos de jobs para monitorar, e três vezes a latência. Por zero ganho.

O sinal prático: se a camada Gold é idêntica à Silver com um agrupamento a mais, você não precisa de três layers. Uma única transformação direta da fonte para a tabela consumida faz o mesmo trabalho com metade da infraestrutura.

Um caso documentado por um arquiteto de dados: um cliente tinha 4,2 bilhões de linhas no Bronze acumuladas em seis anos de dados, mas o Silver só consumia os últimos 90 dias. 97% dos dados armazenados nunca eram usados. O custo de storage era real, o benefício não era.

Quando a latência importa mais do que a qualidade

Cada transição Bronze para Silver, Silver para Gold, é um job separado. Em pipelines com Spark, isso costuma ser 20 a 40 minutos por camada. Três camadas em sequência e a latência total passa de uma hora antes de o dado chegar em qualquer lugar.

Análises com dados reais de praticantes mostram overhead de 53% ou mais em casos simples: 23 minutos com Medallion contra 15 minutos com transformação direta, para o mesmo resultado.

Quando o negócio precisa do dado em 30 minutos para tomar decisão, uma arquitetura com 80 minutos de latência não é um problema de código. É um problema de arquitetura.

Para dados que precisam chegar em tempo real ou próximo disso, o Databricks é explícito: recomenda micro-batch (latência de segundos a poucos minutos) para Medallion, e orienta explicitamente que quando a ingestão vem de um message broker como Kafka, a leitura direta sem etapa intermediária reduz complexidade e latência. Para sub-segundo, a própria documentação aponta limitações no modo real-time que afetam negativamente o throughput.

Quando é protótipo ou análise de vida curta

Uma exploração rápida de dados. Um modelo que vai existir por três meses. Uma análise pontual que vai virar um número num slide e não será consumida de novo.

Forçar Medallion num protótipo cria tabelas que nunca serão mantidas, jobs que ninguém vai monitorar, e estrutura que será abandonada em duas semanas. A equipe gasta tempo e energia organizando o que deveria ser descartável.

Protótipo precisa ser rápido de construir e fácil de jogar fora. Três camadas dificultam as duas coisas.

Quando o time é pequeno e os dados são simples

Uma startup com 3 engenheiros de dados processando 500 GB não tem os mesmos problemas que um banco com 50 engenheiros e 50 TB. O overhead operacional de manter Bronze, Silver e Gold, com todas as tabelas, jobs, documentação e monitoramento que isso exige, pode ser injustificável quando o benefício real é pequeno.

Para times pequenos com um ou dois casos de uso, duas camadas (dado bruto e dado consumível) ou uma solução com dbt direto na fonte resolvem o problema sem a complexidade adicional.

O anti-padrão que ninguém comenta

Vi um problema específico aparecer mais do que qualquer outro quando Medallion não funciona bem: a Bronze fica exposta como produto de dados.

Elliott Cordo, engenheiro de dados com trabalho publicado sobre arquitetura de dados, documenta isso como anti-padrão direto: expor a camada Bronze para quem consome cria acoplamento forte entre quem usa os dados e os detalhes internos de como eles são armazenados. Quando a fonte muda, todos os consumidores quebram junto.

O segundo problema documentado: quando Silver é Bronze com um campo renomeado, e Gold é Silver com um GROUP BY, as camadas intermediárias não agregam valor real. Analistas acabam escrevendo SQL complexo no Gold ou criando planilhas paralelas para compensar. Múltiplas equipes implementam a mesma métrica de formas diferentes, e os números começam a divergir.

Nesses casos, o padrão não está sendo aplicado, está sendo imitado.

A pergunta certa antes de decidir

Três perguntas definem se Medallion é a arquitetura certa:

Há múltiplos consumidores com necessidades diferentes? Se sim, uma camada compartilhada entre eles faz sentido. Se não, você está criando separação sem benefício.

Reprocessar os dados na fonte é caro ou impossível? Se sim, Bronze imutável é proteção real. Se você consegue reprocessar sem custo ou perda de histórico, o benefício diminui.

A latência de cada camada cabe no prazo que o negócio exige? Se sim, Medallion funciona. Se não, você precisa de uma arquitetura diferente para esse caso de uso.

Três “sim”: Medallion é uma escolha sólida. Dois ou menos: vale questionar quantas camadas você realmente precisa.

O que empresas grandes usam na prática

Um detalhe importante que raramente aparece nas discussões: Netflix e Uber, duas das empresas mais referenciadas em engenharia de dados, não usam a terminologia Bronze/Silver/Gold.

A Netflix usa o padrão WAP (Write-Audit-Publish) com Apache Iceberg: o dado é escrito em snapshot oculto, auditado automaticamente, publicado se aprovado. O problema que resolve é o mesmo (qualidade antes da exposição), mas a implementação é diferente e não usa as três camadas do Medallion.

O Uber usa um data lake transacional com Apache Hudi, com tabelas raw, derivadas e agregadas. A migração de batch completo para incremental ETL reduziu o tempo de pipeline em 82% e o custo em 78%, segundo o Uber Engineering Blog de março de 2023. Mas esses números são do incremental ETL, não do padrão de camadas em si.

A Microsoft adotou Medallion como arquitetura oficial do Fabric em 2023 e é hoje o maior case público de adoção institucional. Ainda assim, a documentação da própria Microsoft orienta: antes de construir pipelines complexos entre camadas, avalie Materialized Lake Views, que gerenciam as transformações automaticamente sem overhead operacional.

O que fica

Medallion Architecture é um padrão bom para os problemas certos: times grandes, múltiplos consumidores, dados críticos que precisam de histórico protegido e qualidade progressiva.

Não é obrigatório. Não é universal. E quando aplicado onde não cabe, o custo é real: latência desnecessária, storage desperdiçado, complexidade operacional sem benefício.

A escolha da arquitetura deveria começar pelo problema, não pelo padrão. O que esse pipeline precisa resolver? Quem vai consumir? Qual é o prazo aceitável? Reprocessar da fonte é caro?

Se as respostas apontam para Medallion, ótimo. Se não apontam, uma arquitetura mais simples vai resolver melhor.

Você já implementou Medallion num lugar que não precisava? O que aconteceu depois? Me conta no LinkedIn ou assina a newsletter para receber os próximos posts.

LGPD e modelos de ML: o que fazer com dados que já viraram pesos de modelo

Sat, 02 May 2026 00:00:00 +0000

Um titular pediu exclusão dos dados. Você deletou a linha do banco. E o modelo?

Os pesos de um modelo de ML treinado com dados pessoais guardam, de forma não explícita, a contribuição de cada registro de treino. Deletar o dado original não apaga essa influência. Pesquisas de membership inference conseguem, com alguma probabilidade, determinar se um CPF específico fez parte do dataset de treino de um modelo. Isso é dado pessoal sob a LGPD.

Vi a maioria dos times sem processo para esse cenário. Não por falta de intenção: ninguém estabeleceu o fluxo antes de treinar o primeiro modelo.

O que o Art. 18 efetivamente exige

O Art. 18, IV da LGPD garante ao titular o direito de solicitar anonimização, bloqueio ou eliminação de dados “desnecessários, excessivos ou tratados em desconformidade”.

A interpretação que a ANPD vem sinalizando em suas consultas públicas sobre IA é que modelos de ML são processadores de dados pessoais quando os dados de treino eram pessoais no momento do tratamento. O modelo em produção herda essa classificação.

Se um titular pediu exclusão e você consegue demonstrar que os dados dele foram usados no treino, o direito ao apagamento se aplica ao modelo também. Não só ao dataset.

A lei não especifica como executar esse apagamento. Ela especifica o resultado esperado: o titular não deve mais ter influência sobre as decisões do modelo. Como você chega lá é problema técnico seu.

O problema técnico real

Três cenários que vi na prática, com dificuldades diferentes.

Dados genuinamente anonimizados antes do treino: se você aplicou anonimização real, não pseudonimização, antes de qualquer processamento de ML, está fora do escopo da LGPD para esse dado. O Art. 12 é claro: dado anonimizado não é dado pessoal. Mas anonimização precisa ser irreversível. K-anonymity com k=3 em transações financeiras não é anonimização real.

Dados pseudonimizados no treino: você substituiu o CPF por um token, mas manteve o mapeamento. O dado continua sendo pessoal. O modelo foi treinado com esse dado e agora está em produção. Um pedido de exclusão ativa o problema completo.

Dados brutos no treino, sem tratamento: o cenário mais comum em modelos mais antigos, treinados antes de qualquer preocupação regulatória. Também o mais difícil de resolver.

O que os times fazem na prática

Três abordagens que uso de referência, com trade-offs reais, nenhuma gratuita.

Retraining completo sem o dado: você remove o registro do dataset, retreina do zero ou a partir de um checkpoint anterior. É a abordagem mais limpa juridicamente, a mais defensável numa auditoria, e a mais cara computacionalmente. Para modelos que levam semanas para treinar, é impraticável como resposta rotineira.

Machine unlearning seletivo: técnicas que tentam remover a influência de registros específicos sem retreinamento completo. SISA training (Sharded, Isolated, Sliced, Aggregated) e gradient-based unlearning reduzem o custo. O problema: a maioria das implementações em produção ainda não tem certificação formal de que o apagamento foi efetivo. Numa disputa com a ANPD, “usamos machine unlearning” sem evidência mensurável não resolve.

Documentar a impraticabilidade e mitigar o risco: a LGPD permite, em alguns casos, a continuidade do tratamento quando o apagamento é impossível e existe base legal residual. Documentar que o modelo foi treinado com dados que à época tinham base legal, que o retraining é tecnicamente inviável, e que medidas de mitigação foram implementadas pode ser a resposta juridicamente defensável. Isso precisa de opinião jurídica, não só técnica.

Como arquitetar antes de treinar

O momento certo para resolver isso é antes do primeiro modelo ir para produção, não depois da primeira requisição de exclusão.

Versionamento de datasets por titulares: manter um índice de quais registros foram usados em qual versão de treino. Sem esse índice, você nem sabe quais modelos precisam de ação quando um titular pede exclusão.

Separação de dados de treino por consentimento: se parte do dataset veio de consentimento explícito e parte de legítimo interesse, trate como datasets separados desde o início. Quando o consentimento for revogado, você sabe exatamente qual subconjunto está comprometido.

Checkpoints rotulados por composição de dataset: se você usa treinamento modular, mantenha os checkpoints com metadados sobre quais shards foram usados. Isso reduz o custo de retraining seletivo de semanas para horas.

A decisão que todo time vai precisar tomar

O cenário vai aparecer: um titular envia uma requisição de exclusão, você deleta o dado, e alguém pergunta o que fazer com o modelo de score de crédito que usou esse CPF no treino.

A resposta honesta hoje é: depende de qual modelo, quando foi treinado, como o dataset foi gerenciado, e qual é a base legal original do tratamento.

O que não é mais aceitável é não ter a resposta. A ANPD está construindo sua posição sobre IA e LGPD. Os times que já documentaram suas decisões arquiteturais vão estar em posição muito melhor do que os que estão improvisando quando a orientação chegar.

Delta Lake ou Parquet? Você está fazendo a pergunta errada

Thu, 30 Apr 2026 00:00:00 +0000

No Slack do meu time aparece toda semana: “deve usar Delta Lake ou Parquet?”

Delta Lake não é um formato de arquivo concorrente ao Parquet. É uma camada de gerenciamento transacional que armazena os dados em arquivos Parquet. Você não está escolhendo entre dois formatos. Está decidindo se precisa de uma camada transacional por cima dos seus arquivos.

Essa distinção muda o critério de decisão completamente. E confundir os dois em produção custa caro.

O que o Parquet não faz

Parquet resolve um problema específico muito bem: armazenar dados de forma colunar, comprimida, eficiente para leitura analítica. É o formato certo para isso.

O que Parquet não faz: controle de concorrência. Se dois jobs escrevem na mesma partição ao mesmo tempo, o resultado é não-determinístico. Sem transação, sem rollback, sem detecção de conflito. O arquivo que chegou por último vence. O outro desaparece.

Numa fintech onde trabalhei, com pipelines de ingestão distribuídos, isso não era teórico. Era o cenário padrão toda vez que um job de streaming e um job de backfill rodavam juntos na mesma tabela.

Em pipelines com job de streaming e backfill simultâneos esse cenário aparece sem aviso. O sintoma é sutil: contagem de linhas correta, valores que divergem do dia anterior sem nenhum erro no log. O último writer sobrescreveu o anterior. Silencioso e sem rollback.

O que o Delta Lake adiciona

Delta Lake resolve o problema de concorrência com o _delta_log: um diretório de commits JSON e checkpoints Parquet que registra cada transação. Todo writer registra o que adicionou, o que removeu e a versão resultante. Leitores veem estados consistentes, nunca parciais.

Isso habilita quatro capacidades que Parquet puro não tem:

Operações UPDATE, DELETE e MERGE sem reescrever a tabela inteira. O Delta marca os arquivos afetados como removidos e adiciona novos. O dado antigo fica acessível via time travel (SELECT * FROM tabela VERSION AS OF 10), mas não aparece nas consultas correntes.

Schema enforcement. Se um pipeline tenta escrever uma coluna com tipo incompatível, a escrita falha antes de contaminar a tabela. Com Parquet puro, você descobre o problema no consumidor, não na fonte.

Compactação controlada via OPTIMIZE. Ingestões de streaming geram dezenas de pequenos arquivos por hora. O Delta consolida esses fragmentos sem downtime, mantendo o log de transações intacto.

Data skipping usando estatísticas min/max por arquivo. Numa tabela de 2 TB com 10 mil arquivos Parquet, uma query filtrada por data precisa abrir potencialmente todos os arquivos para checar os metadados. O Delta mantém min/max de cada coluna no log e pula arquivos inteiros sem leitura.

Quando Delta Lake é excessivo

Delta Lake tem custo. O _delta_log adiciona overhead em escritas pequenas. O checkpoint é gerado a cada 10 commits por padrão. Para datasets imutáveis, o custo não tem contrapartida.

Três cenários onde Parquet é a escolha certa:

Datasets de referência que nunca mudam. Tabelas de código BACEN, tabelas de calendário, dados históricos selados após processamento. Nenhum escritor concorrente, nenhum update. Parquet direto, sem overhead de log.

Pipelines de exportação para sistemas externos. Você está gerando arquivos para enviar a um parceiro, um sistema legado, ou um bucket S3 consumido por ferramenta que não lê Delta. Parquet é o padrão de interoperabilidade.

Experimentos e dados efêmeros. Um notebook de análise que lê um arquivo CSV e salva o resultado. Não precisa de controle de versão nem de transação. O overhead do Delta não agrega nada aqui.

A decisão em três perguntas

Antes de escolher o formato, responda:

Mais de um processo escreve nessa tabela ao mesmo tempo, ou vai escrever no futuro? Se sim, Delta Lake.
Os dados são atualizados, deletados ou têm requisito de auditoria? Se sim, Delta Lake.
A tabela é consumida apenas por leitura e nunca muda depois de escrita? Parquet é suficiente.

A maioria das tabelas operacionais em um lakehouse produtivo responde “sim” para a primeira ou segunda pergunta. A maioria das tabelas de lookup responde “sim” para a terceira.

No contexto de compliance com o BACEN 521, que entra em vigor em outubro de 2026, tabelas de auditoria de transações financeiras precisam de time travel e schema enforcement. Usar Parquet puro nessas tabelas não é só ineficiente. É um risco regulatório.

A decisão arquitetural real

Delta Lake não é uma versão melhorada do Parquet. É uma camada diferente que resolve um problema diferente.

O Parquet resolve: como armazenar dados de forma eficiente para leitura analítica.

O Delta Lake resolve: como garantir consistência quando múltiplos processos acessam o mesmo dado ao mesmo tempo.

A pergunta certa não é “qual formato usar”. É “esse dado precisa de controle transacional?” Se precisar, Delta Lake. Se não precisar, Parquet. Passei pelas duas direções em projetos diferentes. O errado custou caro nos dois lados.

Se você já encontrou corrupção silenciosa por concorrência em Parquet, ou se optou por Delta em algo que depois pareceu excessivo, conta nos comentários qual foi o contexto.

Sharpe -1.14 é sucesso de engenharia, não fracasso

Thu, 23 Apr 2026 00:00:00 +0000

Por 6 meses, construí um agente quant para trading de BTC/USDT.

Objetivo: maximizar retorno.

Resultado: Sharpe ratio de -1.14. Não é bom.

O sistema não fracassou. Fracassou em um objetivo (alpha) e se saiu bem em outro (capital preservation).

A arquitetura por camadas

Quant trading é complexo. Não é “compre aqui, venda ali”. É isso:

L1: Ingestion        (dados de verdade)
L2: Processing       (sinais)
L3: Intelligence     (previsões)
L4: Decision         (sizing)
L5: Execution        (minimizar impacto)
L6: Evaluation       (backtests)
L7: Compliance       (auditoria)

Cada camada é independente. Cada uma tem fallbacks.

L1: Ingestion

- BinanceFetcher: OHLCV, funding rates, open interest, order book
- MacroFetcher: DXY, S&P 500 via yfinance
- GlassnodeFetcher: on-chain metrics

Por que 3 fontes? Triangulação. Se Binance cai, você continua com macro + on-chain.

L2: Processing

32+ indicadores técnicos:
- RSI, MACD, Bollinger Bands (clássicos)
- ATR, Stochastic, Williams %R (volatilidade)
- Volume profile, Time-weighted moving average
- On-chain: MVRV, SOPR, Cumulative delta
- Macro: VIX-like crypto index

Tudo normalizado (z-score, min-max).
Tudo alinhado temporalmente (sem forward-looking bias).

L3: Intelligence

Gaussian HMM (Hidden Markov Model) com 3 estados:

BULL (uptrend)    → RSI > 60 + momentum + macro positive
SIDEWAYS (range)  → RSI 40-60 + low volatility
BEAR (downtrend)  → RSI < 40 + momentum negative

LightGBM regressor prediz retornos nos próximos 4 candles (walk-forward).

Você não precisa de accuracy 60% pra ter alpha. Precisa de consistency. Um modelo que acerta 45% das vezes mas com low drawdown supera um modelo que acerta 70% com 30% max DD.

L4: Decision

Quarter Kelly sizing. Não full Kelly (agressivo demais).

Position size = (edge * odds) / odds_ratio
Capped at 2% of portfolio (max risk per trade)

Guardrails (inegociáveis):
- Max drawdown: 15%
- Circuit breaker: 3 consecutive losses = pausa
- Kill switch: manual override sempre disponível

L5: Execution

Almgren-Chriss (minimizar market impact):

Não execute 100% em 1 candle.
Quebre em 5-10 pequenas ordens.
Use TWAP/VWAP pra timing melhor.
Cheque liquidez antes de cada ordem.

L6: Evaluation

Walk-forward backtesting (não data leakage):

Train window: 60 days
Test window: 5 days
Roll forward: shift 5 days, repeat

Métricas:
- Sharpe, Sortino, Calmar ratios
- Max drawdown
- Win rate
- Recovery factor

L7: Compliance

- KillSwitch thread-safe (emergência)
- Auditor append-only em JSONL (irrevogável)
- Telegram notifications (alertas em tempo real)
- 202 testes (Python, pytest)
- CI/CD (GitHub Actions)

O insight: Engenharia de quant não é “acertar previsões”. É construir um sistema testado, auditável, que falha com graça (drawdown mínimo).

O Bug Que Revelou Tudo

Inicialmente, o Sharpe era +0.66. Parecia bom.

Então encontrei data leakage no HMM: o modelo via o futuro durante treinamento.

Um simples descuido:

# WRONG: treina com dados inteiros (future data vaza)
hmm.fit(all_indicators)

# RIGHT: treina apenas com passado até data T
hmm.fit(indicators_until_date_T)

Ao corrigir: Sharpe caiu para -1.14.

Esse momento foi crucial: real » espúrio.

Eu poderia ter:

Ignorado o bug e lançado o sistema (risco: fraude)
Abandonado o projeto (risco: oportunidade de aprendizado perdida)

Em vez disso, documentei a correção, refiz os testes, e fiz a pergunta certa: “O que este sistema realmente resolve?”

O Tradeoff: Alpha vs Preservação de Capital

Vamos aos números (out-of-sample, walk-forward):

Métrica	Agente Quant	Buy & Hold
Sharpe ratio	-1.14	-0.04
Max drawdown	0.29%	26.24%
Win rate	1/7 windows	4/7 windows

Leia isso novamente.

Agente não tem alpha. Mas reduz drawdown em ~90x.

Pergunte-se: em qual cenário você preferiria estar?

Cenário 1: Você compra e segura (Buy & Hold). Em um ano, há 1 dia onde você perde 26% de tudo. Dia seguinte, você recupera 15%. Você dorme?

Cenário 2: Você tá no agente. Max loss é 0.29% em qualquer dia. Você dorme melhor.

Preservação de capital > busca por alpha.

Framework vs Resultado

O código não “falhou”. O código resolveu um problema diferente do planejado.

Systems thinking:

Objetivo inicial: Gerar retorno positivo (alpha)
Problema descoberto: Alpha é raro (até pros profissionais)
Solução emergente: Risk management é consistente
Resultado real: Um sistema de preservação de capital

Às vezes, falhar no objetivo original é a forma que o universo tem de te mostrar o verdadeiro objetivo.

O Stack Técnico

Para devs, aqui está o que funcionou:

O que funcionou:

Python + SQLAlchemy (ORM robusto)
asyncio (concorrência real, non-blocking I/O)
pytest (202 testes passando)
Postgres (auditoria append-only, compliance)
Task Scheduler do Windows (low-cost orchestration)

O que foi desafiador:

HMM em dados não-estacionários (quant é hard)
Market microstructure (Almgren-Chriss é complexo)
Real-time data latency (lag = slippage real)

Stack final:

Data ingestion:  Binance API + Glassnode + yfinance
ML stack:        scikit-learn (HMM), LightGBM (regressão)
Backend:         FastAPI (opcional, current: local scheduler)
Database:        Postgres 16 + JSONL audit trail
Notifications:   Telegram bot + Discord webhook
Infrastructure:  VPS barato (1 vCPU, 4GB RAM, 50GB NVMe)

Tudo roda em uma máquina barata. Sem Kubernetes, sem AWS bill assustador.

Lições duradouras

1. Testes Primeiro (TDD)

202 testes = confiança. Você refatora sem medo.

Sem testes? Falhas silenciosas. Você descobre em produção.

Cada feature tem teste associado:
- test_hmmpredict.py (validação do modelo)
- test_kelly_sizing.py (risk management)
- test_market_impact.py (execution)
- test_audit_trail.py (compliance)

2. Auditoria é Design

JSONL append-only logs me salvaram quando questionei resultados.

{"timestamp": "2026-04-22T10:30:00", "action": "BUY", "size": 0.05, "price": 65000, "reason": "BULL_regime_high_momentum"}
{"timestamp": "2026-04-22T11:45:00", "action": "CLOSE", "pnl": 50, "drawdown": 0.0015}

Você pode rastrear por que cada decisão foi tomada.

3. Constraints Geram Inovação

Quarter Kelly sizing é mais conservador que full Kelly. Mas foi mais efetivo.

Constraints (2% max risk, 15% max DD) obrigaram criatividade na decisão.

Livre demais = overfitting.

4. Real-time é Diferente de Backtesting

Walk-forward validation previne surpresas.

Seu modelo pode ter 70% de accuracy no backtest, mas em produção? 45%. Por quê?

Slippage (você não pega o preço exato)
Latência (0.5s de delay = preço diferente)
Spread (bid/ask widening em volatilidade)

Real-time não perdoa.

5. Falhar é Learning

Data leakage (-1.14 vs +0.66) foi a descoberta mais valiosa.

Correção daquele bug = aprendi mais do que 10 livros sobre quant.

Não tenha medo de “falhas” que educam.

6. Simplicidade > Complexidade

3 estados no HMM funcionou melhor que 10+ features.

6 meses construindo. Resultado: simples.

Inversão de tempo: 95% construindo, 5% simplificando. Mas aqueles 5% = o código que realmente roda em produção.

7. Preservação de Capital > Busca por Alpha

Seu objetivo deve ser: “Não perder dinheiro.”

Alpha (extra retorno) é bônus.

A maioria dos quants inverte: “Busco alpha, tolero perda.”

Errado.

O Que Vem Depois

Este agente não vai gerar riqueza da noite para o dia.

(Se alguém prometer isso, corre.)

Mas ele resolve um problema real:

“Como construir um sistema robusto de decisão em Python?”

Próximos passos para você:

O código: projeto fechado por enquanto. A arquitetura descrita acima (HMM + LightGBM + Kelly + HRP, separação treino/produção, evento-baseado vs polling) é o que importa pra replicar a abordagem.
Adapte: Para stocks, commodities, cripto (framework é agnóstico)
Realize: Quão difícil é quant. Respeite quem faz bem.

Qual É a Sua Métrica?

Sharpe é útil. Mas talvez você otimize para outra coisa:

Máxima riqueza em tempo mínimo? (tempo alocado)
Mínimo drawdown? (paz de espírito)
Mínimo capital needed? (acessibilidade)

Escolha sua métrica. Construa para ela. Valide com dados reais.

Não a escolha dele. Não a moda. A sua.

Sharpe de -1.14 é um fracasso de marketing. Mas é um sucesso de engenharia.

Se o objetivo era aprender a construir um sistema robusto, testado, auditável, escalável, missão cumprida.

O próximo objetivo é seu.

Responde no LinkedIn ou assina a newsletter no Substack pra receber os próximos posts.

Engenharia de dados em português de verdade é rara. Vou ajudar a mudar isso.

Sat, 18 Apr 2026 00:00:00 +0000

Conteúdo de engenharia de dados em português, daquele tipo que você abre e sente que a pessoa viveu o que está escrevendo, é raro de achar.

Procura agora. Você vai encontrar muito material de qualidade pra começar: traduções de artigos gringos, tutoriais que partem da documentação oficial, cursos de Pandas com datasets simples. Tudo isso tem espaço, é por onde muita gente começa, e quem produz esse material está fazendo um trabalho importante.

O que ainda é difícil de achar é alguém te contando como decidiu usar Delta Lake em vez de Parquet num ambiente que processa centenas de milhões de transações por dia. Ou em quais momentos a Medallion Architecture ajuda e em quais ela só atrapalha. Ou como a LGPD muda, na prática, a forma como você desenha uma camada de ingestão.

É esse pedaço que eu quero ajudar a preencher.

Quem sou eu pra dizer isso

Não vou listar certificados. Vou te contar o que construí.

Sou engenheira de dados sênior há mais de 8 anos. Comecei em qualidade de dados num grande banco brasileiro, passei por uma fintech brasileira em escala global construindo pipelines ETL, atuei em consultoria internacional num projeto de big tech em Silicon Valley, e hoje atuo em outro grande banco brasileiro. (Currículo completo na página /sobre/.)

Minha stack principal é Databricks. Não porque eu li um tutorial. Porque é o que roda em produção nos lugares onde trabalhei nos últimos anos.

Em 2026 entrei num mestrado em métodos computacionais aplicados. Pesquiso uso de IA pra monitoramento preditivo em sistemas operacionais críticos. Tudo que aprendo lá eu pretendo trazer pra cá traduzido pra realidade de quem trabalha com dados todo dia.

Por que cripto entrou nessa história

Alguns anos atrás eu comecei a estudar análise on-chain. E percebi uma coisa que pouca gente parece estar dizendo de forma clara: cripto, em boa parte, é um problema de engenharia de dados ainda mal resolvido.

Os dados estão todos ali. Na blockchain, abertos, públicos. Mas boa parte de quem investe não sabe tratá-los, e grande parte das engenheiras de dados ainda não está olhando pra eles.

Então decidi construir um agente de IA especialista em cripto. Do zero, em público, documentando cada decisão de arquitetura. Com as mesmas ferramentas que uso no trabalho: pipelines reais, backtesting rigoroso, modelos estatísticos de verdade. Sem hype, sem promessa de enriquecimento rápido.

O que você vai encontrar aqui

Três frentes, uma newsletter.

A primeira é engenharia de dados de produção: Databricks, Delta Lake, Spark, dbt, Airflow. Decisões reais de arquitetura, erros que cometi e o que aprendi com eles, contexto brasileiro onde for relevante (LGPD na prática, custo de cloud, a realidade de dados em instituições financeiras).

A segunda é o agente de IA pra cripto, construído em público. Arquitetura, código, backtesting, análise on-chain. Cada etapa documentada. Se der errado, você vai saber por quê.

A terceira é o mestrado traduzido pra prática. O que a pesquisa acadêmica tem a dizer sobre os problemas que você enfrenta todo dia. Sem filtro, sem academiquês.

Publicações em português e inglês, toda semana.

Responde esse post com uma pergunta: qual é o maior desafio de dados que você está enfrentando agora? Eu leio tudo.

Thais Vaz

Newsletter no Substack →

LGPD na ingestão de dados: 4 princípios que mudam sua arquitetura

Thu, 16 Apr 2026 00:00:00 +0000

Vi a maioria dos times tratar LGPD como algo pra resolver “depois”.

Primeiro o pipeline é montado, os dados entram no lake, os dashboards começam a sair. Aí, um dia, chega uma requisição de titular pedindo exclusão de dados pessoais. E o time descobre que não sabe onde aquele CPF está, quantas cópias existem no Bronze, quantos modelos de ML já foram treinados com ele.

É tarde.

LGPD não é compliance no fim do pipeline. É uma restrição de design que começa no primeiro byte que você ingere. Existem quatro princípios que, se você incorporar logo na camada de ingestão, evitam praticamente todas as dores que vêm depois.

Princípio 1: minimize na fonte, não no destino

O Art. 6º, III da LGPD fala em necessidade: só trate dados adequados e limitados ao que é necessário para a finalidade.

A tradução prática que aprendi é simples. Não ingira o que você não vai usar.

Parece óbvio, mas não é. A maioria dos pipelines ingere tabelas inteiras (incluindo colunas de CPF, RG, telefone, endereço, e-mail) “porque está na fonte”. Aí o compliance chega, pede o mapeamento desses campos, e descobre que 80% deles nunca foram consumidos por ninguém.

O padrão correto é aplicar schema filtering antes da persistência. No pipeline de ingestão, você define explicitamente quais campos entram no lake. O que não entrar, não vira problema seu de retenção, de anonimização, de auditoria.

A pergunta que vale a pena fazer antes de cada campo é: qual caso de uso concreto precisa desse dado?. Se a resposta for “sei lá, pode ser útil”, é porque não precisa.

Princípio 2: pseudonimize desde o primeiro byte

Três termos que parecem iguais e não são.

Anonimização é o dado tornado irreversível. Não dá mais pra identificar ninguém. É o único estado que a LGPD trata como fora do escopo (Art. 12).

Pseudonimização é a identidade substituída por um código, mas com possibilidade de reverter via uma tabela separada. Continua sendo dado pessoal (Art. 13, §4º). Reduz risco, mas não remove a obrigação.

Tokenização é uma variante específica de pseudonimização com token determinístico, útil pra preservar joins sem expor o dado original.

A prática que funciona é tokenizar na ingestão. O Bronze nunca vê o dado cru. Vê o token determinístico. O mapeamento token ↔ dado original vive numa tabela isolada, com criptografia em repouso, acesso auditado e política de retenção própria.

Isso resolve três problemas de uma vez. Você consegue fazer join entre tabelas no lake sem expor o dado original. Direito ao apagamento vira um DELETE no mapeamento, sem precisar mexer no Bronze. E analistas e modelos de ML trabalham com dados pseudonimizados por padrão, reduzindo a superfície de risco.

Princípio 3: lineage é requisito, não feature

Quando chega uma requisição de titular (Art. 18, direito de acesso, correção, exclusão), você tem 15 dias pra responder. Sem lineage completo, esse prazo vira pesadelo.

Lineage de verdade responde três perguntas pra qualquer dado pessoal. De onde veio? Sistema fonte, campo original, timestamp de ingestão. Que transformações sofreu? Passos do pipeline, regras aplicadas, derivações. Onde está agora? Tabelas, modelos treinados, dashboards que o consomem.

Ferramentas como OpenLineage, DataHub e o Unity Catalog do Databricks entregam isso, mas só se você instrumentar desde a ingestão. Colocar lineage depois que o pipeline já está rodando é dez vezes mais caro do que colocar antes.

O teste prático é direto: você consegue, em menos de uma hora, listar todas as tabelas e modelos que contêm o CPF 123.456.789-00? Se não consegue, seu lineage não está pronto pra LGPD.

Princípio 4: retenção por finalidade, não por tabela

O Art. 15 diz que o tratamento termina quando a finalidade for alcançada. O Art. 16 completa: depois disso, os dados devem ser eliminados.

Na prática da engenharia de dados, cada dado passa a ter um relógio próprio. Não dá pra criar uma política única de “retenção igual a 5 anos” pra todas as tabelas. Algumas finalidades exigem meses, outras anos, outras são indefinidas (por base legal diferente).

Padrões que funcionam: tabelas particionadas por data de tratamento, com VACUUM ou TRUNCATE PARTITION no fim do ciclo. Mapa de finalidades documentado em código, num YAML que define, por tabela e por campo, qual finalidade justifica, qual base legal e qual prazo. E jobs de expiração automáticos, sem confiar em processo manual: configura retention policies que rodam sozinhas.

Delta Lake, BigQuery e Snowflake têm mecanismos pra isso. O trabalho é traduzir finalidade jurídica em configuração técnica, e esse é o trabalho que ninguém quer fazer, mas que determina se você vai ou não bater de frente com a ANPD.

O que o time de dados precisa combinar com o jurídico

Três conversas que a engenharia não pode terceirizar.

A primeira é a base legal de cada dado. Consentimento? Legítimo interesse? Execução contratual? Cada base tem implicações técnicas diferentes. Direito de revogação, por exemplo, só existe em consentimento.

A segunda é a finalidade concreta de cada pipeline. “Analytics” não vale. Qual decisão de negócio esse dado suporta?

A terceira é o processo de resposta a requisições. Quem recebe? Qual o fluxo? Qual o SLA interno? Isso precisa estar documentado, testado e ter dono.

Se essas três conversas ainda não aconteceram, seu pipeline de dados pessoais está operando em dívida técnica de compliance.

O que fica

LGPD não é checklist no fim. É uma restrição de design que muda quatro coisas. O que você ingere (minimização). Como você ingere (pseudonimização). O que você rastreia (lineage). Por quanto tempo mantém (retenção por finalidade).

Times que tratam LGPD como “resolvemos depois” pagam o retrabalho inteiro na primeira requisição de titular que chega. Times que tratam como design constraint desde o primeiro byte nem percebem que ela está ali, porque é só como as coisas funcionam.

A diferença entre um e outro não é jurídica. É de engenharia.

Qual foi a requisição de titular mais cabulosa que você já viu chegar no seu time? Me responde no LinkedIn ou assina o Substack pra receber os próximos posts.

Vaz · Engenharia de informação

Prompt caching: o ajuste de 1 linha que corta 90% do custo de LLM em produção

Por que o custo de LLM em produção é prefixo

Como funciona o cache na Anthropic

Bench real do pipeline noticias-diarias

Onde brilha, onde não brilha

Não é micro-otimização. É arquitetura.

SQL ainda é a linguagem mais importante de DE em 2026

O codificador terceirizou o entendimento

Em pipeline real, abstração não cabe

A IA gera SQL ruim em escala

O plan de execução é onde mora a diferença

A decisão é antes da próxima feature

YouTube bloqueia o endpoint de legendas. O de áudio continua aberto.

O problema que pipelines de transcrição ignoram

Por que googlevideo não cai junto

A pipeline que aguenta batch real

Benchmark em CPU (Intel i7 12ª gen, 16 GB, int8)

E os SaaS já existem com Whisper fallback?

Verdict honesto

Anti-padrões que vi pelo caminho

O que isso muda pra você

Code review do meu próprio repo. Cinco coisas que eu mudaria hoje.

A credencial do banco estava dentro da função

O pipeline perdia paralelismo de graça

Os dados estavam dentro da imagem Docker

O DAG rodava todo dia sobre dado estático

O fillna(0) apagou um sinal importante

O incômodo de revisar código próprio

Data Flows Ep01: o conceito que vem antes de qualquer ferramenta

Em uma frase

De onde veio essa ideia

Bounded vs unbounded: a decisão que define tudo

Quando batch, quando streaming

O que dá errado quando ignoram o flow

Como os grandes documentam o próprio flow

Anti-padrões pra evitar

Onde começar

SLA, não moda: quando batch, quando streaming, quando ambos

A pergunta certa não é “qual é mais moderno”

Tabela de decisão: SLA × tecnologia

Quando batch ganha (mesmo em 2026)

Quando streaming é a única resposta

Quando “ambos” é a resposta certa

Perguntas que decidem o caso

Airflow por 2 anos: o que eu faria diferente

Contexto: o que é e quem usa

O que o Airflow resolve bem

Onde o Airflow complica

O scheduler parseia todo o seu código a cada 30 segundos

XCom tem limite severo que ninguém avisa no começo

catchup=True já disparou backfills indesejados em muitos times

Renomear um DAG perde todo o histórico

Lógica de negócio dentro do operador vira problema depois

O que eu faria diferente

Sobre o Airflow 3.0

Quando avaliar alternativas

O que fica

Vinte conceitos de IA que você precisa entender em 2026

Como a IA funciona (1 a 4)

A mágica por trás (5 a 8)

Além dos modelos (9 a 12)

Como a IA gera saídas (13 a 14)

Como a IA age (15 a 16)

Melhoria e avaliação (17 a 20)

Fechamento

Quando o modelo deveria dizer 'não sei'

Em uma frase

O ponto cego que sobrava depois do data leakage

O que a literatura chama disso

Já fizeram isso em finanças

Como implementei

Por que 5 sigmas, não 3

O que mudei no sono

Anti-padrões pra evitar

O próximo capítulo

Instrumentando lineage do zero com Unity Catalog

O que o Unity Catalog captura automaticamente

O que não é capturado e onde a maioria erra

Multi-hop lineage: o que o Catalog Explorer não mostra

Por que `googlevideo` não cai junto

O `fillna(0)` apagou um sinal importante