🏗️ Fundamentos de Engenharia de Dados

Engenharia de Dados é a disciplina de construir e manter sistemas que coletam, armazenam, transformam e entregam dados de forma confiável para quem precisa deles. Não é programação genérica, não é análise de dados — é infraestrutura de dados.

Toda empresa que usa dados (todas) precisa de alguém que garanta que esses dados chegam limpos, no formato certo, na hora certa. Sem isso, analistas, cientistas e agentes de IA trabalham no escuro.

Pipelines de dados, ingestão, transformação, entrega. A DE é o encanamento — invisível quando funciona, catastrófico quando quebra.

Dados são o piso de qualquer sistema de IA. Um agente GPT-4 com dados sujos vai errar com confiança. Um modelo simples com dados limpos vai surpreender. O piso determina o teto.

A maioria das falhas em projetos de IA não é do modelo — é dos dados. Entender isso muda como você prioriza esforço: menos tempo ajustando prompts, mais tempo limpando o pipeline.

Dado sujo não para o agente. Faz ele responder com confiança e errar. Garbage in, garbage out — mas com IA generativa, o "garbage out" vem embalado em linguagem convincente.

DE constrói o pipeline. Data Science consome os dados para modelos e insights. Analytics Engineering (dbt, Looker) transforma dados em métricas de negócio. Papéis distintos, frequentemente confundidos.

Saber onde você está na cadeia evita fazer trabalho errado na hora errada. Um DE que tenta ser cientista de dados sem dados limpos vai falhar nas duas funções.

DE = infraestrutura e pipeline. DS = modelos e previsões. AE = métricas e dashboards. Sobreposição existe, mas o núcleo é distinto.

Agentes de IA com dados ruins entram em "wild goose chase" — consomem tokens tentando adivinhar o que o dado significa, hallocinam com confiança e geram respostas plausíveis mas erradas.

Antes de qualquer projeto de IA, a pergunta deve ser: os dados estão prontos? Se não, o custo de tokens e o custo de erros vão escalar juntos.

Dados ruins + IA = erros confiantes. O modelo não sabe que não sabe. Por isso a DE vem antes da IA, não depois.

Empresa em Dubai queria "falar com os dados" usando GPT-3.5 Turbo com 4k de contexto — os dados tinham 10 colunas com nomes inconsistentes e valores nulos em 40% das linhas. Resultado: agente inutilizável após semanas de desenvolvimento.

O padrão é pular DE e ir direto para a interface de IA. O resultado é sempre o mesmo: gastar centenas de dólares em tokens de agente para sifar dados sujos — o erro mais caro que existe.

Projetos falham na DE, não no modelo. A Coca-Cola com 10 bilhões de linhas não precisa de GPT-4 — precisa primeiro de dados organizados. A ordem importa.

Em 12-18 meses, muitas funções admin serão automatizadas. Mas data engineers continuarão empregados — porque a maioria das empresas não tem dados organizados o suficiente para que isso aconteça.

O DE é o guardião da matéria-prima da IA. Quanto mais IA for adotada, mais crítico se torna o papel de quem garante que os dados chegam limpos e confiáveis.

DE hoje = construir pipelines + garantir qualidade + orquestrar o fluxo de dados para agentes. É um papel de infraestrutura que cresce com a adoção de IA.

Planilhas Excel, CSVs exportados de sistemas legados, PDFs de relatórios, bancos Oracle/SAP que ninguém documenta. Empresas corporativas têm impérios de Excel — isso é o Wild West dos dados.

Todo pipeline começa aqui. Se você não entende a natureza das fontes brutas, vai tratar um CSV de 10MB como se fosse um banco de produção — e vice-versa.

Fontes brutas são sempre sujas. Formatos variam. Nomes de colunas são inconsistentes. O primeiro passo é sempre auditar antes de assumir.

O pipeline central: auditar → limpar → normalizar → modelar. Esta é a camada que decide se o agente vai ser um Ferrari rodando numa estrada asfaltada ou um Rolls Royce num campo de terra.

É o coração do trabalho de DE. Sem essa camada funcionando, nenhuma das camadas acima entrega valor real.

Auditoria de qualidade, limpeza de nulos e inconsistências, normalização de formatos, modelagem em tabelas fato e dimensão.

Você não joga 10 milhões de linhas no contexto de um LLM. Você escreve SQL para buscar o que precisa. DuckDB para análise local rápida, Supabase/PostgreSQL para produção.

A escolha do warehouse determina a velocidade, custo e escalabilidade do sistema. DuckDB resolve 80% dos casos sem infraestrutura complexa.

DuckDB = leve, rápido, perfeito para a maioria dos projetos. Supabase = PostgreSQL gerenciado. Resumos pré-calculados = agentes mais rápidos e baratos.

Skills são sugestões ao LLM sobre como agir. Regras são instruções persistentes que moldam o comportamento. Hooks são código determinístico que roda independente do LLM.

Esta camada é o que transforma um agente genérico em um sistema especializado. É onde você codifica o conhecimento de domínio de forma programática.

Skills = comportamento sugerido. Regras = comportamento persistente. Hooks = comportamento garantido (código real). A distinção importa muito em produção.

Os agentes, dashboards e interfaces que o usuário final vê. É a camada mais visível e a menos importante quando as camadas abaixo estão quebradas.

Para não cair na armadilha de focar aqui primeiro. A camada 5 é consequência das camadas 1-4. Sem base, é castelo de areia.

Briefs = contexto estruturado para o agente. Decisões = output do sistema. A qualidade das decisões reflete diretamente a qualidade dos dados nas camadas inferiores.

A camada 5 (agentes, interfaces) é visual, impressionante e fácil de demonstrar em vídeo. As camadas 1-4 são invisíveis, trabalhosas e geram zero views. Mas são onde o valor real é criado.

Consumir conteúdo de IA sem entender as camadas inferiores leva a projetos que funcionam em demo mas falham em produção. A diferença entre demo e produção é sempre as camadas 1-4.

Construir na ordem certa: 1 → 2 → 3 → 4 → 5. Nunca ao contrário. Um sistema sólido nas camadas inferiores torna a camada 5 trivial de implementar.

A base da pirâmide. Tudo que existe antes de qualquer processamento: CSVs exportados de sistemas, planilhas Excel com macros, PDFs de relatórios mensais, dumps de banco de dados legado.

Se você não entende o que tem na base, vai construir a pirâmide toda no ar. A base define o que é possível nas camadas acima.

Inventário de fontes, mapeamento de schemas, identificação de donos dos dados. Antes de processar, catalogue.

A segunda camada da pirâmide. Antes de limpar, você audita: quantas linhas? Qual % de nulos por coluna? Quais valores únicos existem? Há duplicatas? Os tipos de dado fazem sentido?

Limpar sem auditar é atirar no escuro. A auditoria revela os problemas reais antes que você passe horas resolvendo os problemas errados.

Profile dos dados: shape, dtypes, null count, unique values, duplicates. Ferramentas: pandas profiling, DuckDB, até mesmo Excel para conjuntos pequenos.

Amostras de 100 linhas representativas de cada tabela. Não aleatórias — curadas para mostrar diversidade de casos, edge cases e padrões importantes.

Snippets permitem que agentes de IA "vejam" os dados sem processar milhões de linhas. São o contexto que o LLM precisa para gerar SQL correto.

100 linhas bem escolhidas > 1 milhão de linhas aleatórias para dar contexto a um agente. Curadoria > volume quando o objetivo é contexto.

Tabelas pré-calculadas que agregam os dados brutos em métricas úteis. Tabelas fato contêm eventos mensuráveis (vendas, cliques, pedidos). Tabelas dimensão contêm contexto (clientes, produtos, regiões).

Resumos pré-calculados são a base de qualquer sistema de análise eficiente. Agentes que consultam resumos são 10x mais rápidos e baratos que agentes que processam dados brutos.

Fato = o que aconteceu (métricas). Dimensão = quem/onde/quando (contexto). O modelo estrela une os dois para consultas eficientes.

O topo da pirâmide: briefs estruturados que combinam resumos + contexto de negócio, agentes que processam esses briefs, e decisões que saem do sistema.

O topo só funciona bem se a base for sólida. A qualidade das decisões é proporcional à qualidade dos dados nas camadas inferiores. Não há atalho.

Briefs bem estruturados = agentes eficientes. A pirâmide é um fluxo: base alimenta cada camada acima. Fragilidade em qualquer ponto se propaga para cima.

Cada camada é input da próxima. Fontes brutas → Auditoria → Snippets → Resumos → Decisões. Quando uma camada falha, todas as camadas acima ficam comprometidas — mas o sistema pode continuar rodando e entregando resultados errados.

Falhas silenciosas são piores que falhas barulhentas. Um sistema que falha e para é problemático. Um sistema que falha e entrega resultado errado é catastrófico.

Validação em cada camada. Testes de qualidade. Alertas quando dados não chegam ou chegam fora do padrão esperado. A pirâmide precisa de monitoramento em cada nível.

Dados que podem assumir qualquer valor dentro de um intervalo. Receita de R$1.234,56, temperatura de 37,2°C, utilização de CPU de 73,4%. Podem ser fracionados indefinidamente.

O tipo de dado define as operações válidas. Para contínuos: min, max, median, average, spread, distribuição. Aplicar essas operações em dados discretos gera resultados sem sentido.

Receita, horas trabalhadas, kilowatts consumidos, peso, temperatura. Operações: média, mediana, desvio padrão, percentis, histogramas.

Dados com valores distintos e contáveis. Status de pedido (pendente, enviado, entregue), país de origem (Brasil, EUA, Alemanha), ciclo de vida do cliente (lead, ativo, churned).

Para discretos, as operações válidas são outras: top-N, contagens, filtros, frequências, tabelas de contingência. Calcular a "média de países" não faz sentido.

Status, categorias, países, nomes, IDs, ciclos de vida. Operações: count, top-N, frequência relativa, filtros por valor.

Para contínuos: verificar outliers extremos, distribuição, zeros suspeitos, valores negativos impossíveis. Para discretos: verificar valores inválidos, typos, padronização (BR vs Brasil vs brazil).

Auditar um dado contínuo como se fosse discreto (ou vice-versa) faz você perder os problemas reais. O checklist de auditoria muda com o tipo de dado.

Contínuo → outliers, zeros, negativos, distribuição. Discreto → valores únicos, typos, padronização, valores esperados vs observados.

Contínuo: min, max, mean, median, std, percentis, histograma, box plot. Discreto: count, frequency, top-N, mode, crosstab, bar chart. Aplicar operações erradas gera números sem sentido.

Agentes de IA aplicam operações automaticamente. Se o dado não for classificado corretamente, o agente vai calcular a "média de status de pedidos" e entregar um número inútil com confiança.

A pergunta guia: "essa operação matemática faz sentido nesse dado?" Se não faz, é o tipo errado de operação.

Idade em dataset é discreta (só valores inteiros), mas biologicamente é contínua. Tenure em dias é discreta. Nota de satisfação 1-10 é discreta (não existe 7,3 de satisfação). Contexto importa.

Casos ambíguos exigem decisão explícita sobre como tratar. Sem essa decisão, cada parte do sistema pode tratar o mesmo dado de forma diferente — gerando inconsistências.

Pergunta rápida: consigo cortar esse valor com uma faca? Se sim, contínuo (receita de R$1,50 existe). Se não, discreto (não existe "2,5 países de origem").

Claude Code detecta o tipo de dado pela distribuição de valores e escolhe operações adequadas. Para contínuos: gera estatísticas descritivas. Para discretos: gera tabelas de frequência e top-N.

Entender como o agente pensa permite que você forneça metadados que guiam a análise corretamente — e detecte quando o agente está fazendo a classificação errada.

Metadados de schema (tipo da coluna, range válido, valores permitidos) são a forma mais eficiente de guiar um agente. Quanto mais contexto, menos erro.