Coleta e Integração

Objetivos de aprendizagem #

• O1. Extrair dados de arquivos, APIs, bancos relacionais e não relacionais.
• O2. Comparar data lake e data warehouse quanto a propósito e custo.
• O3. Aplicar ETL e explicar quando ELT é preferível.
• O4. Avaliar a licença e a procedência de uma base pública antes de usá-la.

O problema: o mesmo cliente, três vezes #

Uma rede de varejo pede um modelo de recompra. A equipe precisa de uma linha por cliente, e o cliente está em três lugares: no CRM (cadastro comercial), no faturamento e no aplicativo da loja. Ninguém tem a mesma chave. No CRM ele é João Silva; no faturamento, SILVA, J.; no aplicativo, só um CPF e um e-mail.

A equipe faz o que parece óbvio: junta por nome. O resultado sai em duas horas e parece bom. Semanas depois alguém descobre que 12% da base virou dois clientes diferentes, e um punhado de homônimos virou um cliente só — com o histórico de compras de duas pessoas somado. O modelo aprendeu de um mundo que não existe.

Este é o capítulo menos glamouroso do livro e um dos que mais decidem o prazo do projeto. Ele cobre as fases 2 e 3 do ciclo do capítulo I.1, entender e preparar os dados, e o erro que previne não é de algoritmo: é acreditar que "trazer o dado" é uma tarefa de cópia. Não é. É uma tarefa de reconciliação, porque cada sistema tem a sua própria noção do que é um cliente, uma data e um valor ausente.

De onde isto veio #

O aperto. Anos 1980–90. Os dados da empresa viviam nos sistemas transacionais (o do caixa, o do estoque, o da cobrança), todos projetados para registrar, não para perguntar. Registrar exige gravar uma linha por vez, rápido e sem inconsistência. Perguntar exige varrer milhões de linhas de uma vez. Os dois disputavam a mesma máquina, e quando o gerente pedia o relatório do trimestre, a consulta pesada competia com a operação — e podia derrubá-la. O relatório do gerente travava a venda no caixa.

O que se fazia antes. Extraía-se o relatório direto do sistema de produção, em janela noturna. Funcionava enquanto a janela coubesse na noite e enquanto ninguém precisasse perguntar de dia.

A virada. Separar o repositório de análise do repositório de operação — e aceitar a redundância como preço da pergunta rápida. O mesmo fato passa a existir em dois lugares, com dois formatos, sob duas disciplinas diferentes. Copiar dado deixou de ser sintoma de projeto malfeito e virou decisão de arquitetura.

A ideia reaproveitável. Otimizar para escrever e otimizar para ler são objetivos em conflito. Quando os dois não cabem no mesmo lugar, duplicar com disciplina é mais barato que servir mal aos dois. O padrão reaparece longe daqui: réplica de leitura, cache, índice, view materializada, feature store. Todos são a mesma jogada — pagar em espaço e em sincronismo para comprar tempo de resposta.

O nome. Bill Inmon é chamado "pai do data warehouse"; Building the Data Warehouse é de 1992.

O debate que não terminou #

E aqui está a parte mais útil desta seção, justamente por não ter vencedor.

Inmon defende uma arquitetura hub-and-spoke: um warehouse central normalizado, fiel ao modelo corporativo, e data marts dependentes a jusante, montados a partir dele para cada área.

Kimball defende a arquitetura de barramento, e este lado dá para citar da fonte. O Kimball Group a define como algo que "decomposes the DW/BI planning process into manageable pieces by focusing on business processes, while delivering integration via standardized conformed dimensions that are reused across processes". A peça que costura tudo é a dimensão conformada, e a definição dela é mais estreita que a paráfrase habitual: "Dimension tables conform when attributes in separate dimension tables have the same column names and domain contents." São os mesmos nomes de coluna e o mesmo domínio de valores, e não apenas "a mesma ideia de cliente".

Repare no que os dois concordam: modelagem dimensional serve, e é ela que faz o cubo do capítulo II.6 responder rápido. A discordância é sobre onde ela entra — no fim do caminho ou desde a porta de entrada.

Na prática, quase todo warehouse grande é híbrido. E o híbrido não é o fracasso de um projeto que não escolheu lado: é o sedimento de decisões tomadas por equipes diferentes, em épocas diferentes, sob restrições diferentes — a que tinha prazo e fez o mart direto; a que herdou dez fontes e precisou de uma camada normalizada para conciliá-las. Quando você chegar a uma empresa e encontrar as duas coisas convivendo, a leitura correta não é "está errado", é "aqui houve história". Sua pergunta deve ser qual restrição produziu cada pedaço, e se ela ainda vale.

Procedência das afirmações desta seção:

Fundamentos: as fontes e a ordem da transformação #

Toda coleta começa escolhendo por onde o dado sai. Cinco portas cobrem quase tudo, e cada uma falha à sua maneira.

Escolhida a porta, resta a pergunta de ordem: transformar antes ou depois de gravar?

ETL (Extract, Transform, Load) transforma antes de carregar. Nasceu numa época em que armazenamento era caro: guardava-se apenas o que já estava limpo, modelado e agregado. O preço é irreversível — o que a transformação descartou não volta. Quando a regra de negócio muda, você precisa do dado bruto que jogou fora.

ELT (Extract, Load, Transform) carrega o bruto e transforma dentro do repositório, quase sempre em SQL. A ordem inverteu quando o armazenamento ficou barato e o motor analítico ficou forte: passou a ser mais barato guardar tudo e derivar depois do que decidir cedo o que interessa. O ganho real é poder re-derivar — mudou a regra, você recalcula a partir do bruto em vez de pedir uma nova extração. O preço é honesto e precisa ser dito: você paga para armazenar dado que ninguém pediu, e sem catálogo e sem dono ninguém sabe qual das dezessete tabelas cliente é a boa.

Onde o dado descansa: lake, warehouse, lakehouse #

Os três guardam dados, e a diferença que importa é quando o esquema é cobrado.

O warehouse cobra caro na entrada e devolve confiança: se a linha entrou, ela está no formato combinado. O lake cobra barato na entrada e transfere o problema para quem lê — e é exatamente por isso que um lake sem catálogo vira o pântano de que todo mundo fala: não é o volume que o mata, é a ausência de quem responda pelo significado de cada arquivo. O lakehouse é a tentativa de ficar com os dois: arquivos abertos e baratos, mais uma camada de tabela que garante transação, evolução de esquema e viagem no tempo. Ele não elimina a decisão — apenas move o custo para a governança.

Integrar é mais difícil que extrair #

Extrair é engenharia; integrar é semântica. Três problemas aparecem em todo projeto.

Uma entidade, várias chaves. O João Silva do início do capítulo. Quando existe uma chave forte compartilhada (CPF, CNPJ, número do contrato), use-a e acabou. Quando não existe, o casamento é probabilístico: normalize o texto, compare nome, data de nascimento e endereço, calcule uma pontuação de similaridade e escolha um limiar. E esse limiar não é técnico — limiar alto deixa duplicata na base, limiar baixo funde duas pessoas. Decida com quem paga a conta do erro, e registre a regra, porque em seis meses ninguém lembra por que dois cadastros viraram um.

Granularidade, e o que se perde ao agregar cedo. O grão é o fato mais fino que a tabela guarda: um item de um pedido, ou o total do dia por loja. Agregar é irreversível — quem guardou só o total diário por loja não consegue mais responder quais produtos são comprados juntos, nem qual foi o efeito de uma promoção sobre um item. A regra prática: guarde no grão mais fino que couber no orçamento; agregar depois é uma consulta, desagregar depois é uma coleta nova. É o mesmo grão que o cubo do capítulo II.6 vai fatiar.

Idempotência e reprocessamento. Todo pipeline roda de novo — a fonte chegou atrasada, o job caiu no meio, alguém corrigiu o arquivo de ontem. Rodar duas vezes tem de produzir o mesmo estado que rodar uma. INSERT puro não é idempotente: reprocessar duplica o faturamento. As duas formas baratas de conseguir isso são MERGE por chave de negócio e sobrescrita da partição inteira do período reprocessado. Sem isso, o pipeline só é confiável enquanto nunca falhar — e a fila de streaming, que entrega "ao menos uma vez", garante que ele vai falhar. Monitorar essa reexecução é assunto do capítulo V.3.

De onde veio este dado, e quem o produziu? #

É a pergunta que abre o capítulo I.3, e é aqui que ela nasce — porque o vazamento mais comum de todos não vem de um erro de modelagem: vem de juntar tabelas sem respeitar o tempo.

Uma tabela de dimensão que é atualizada no lugar (sem histórico) carrega sempre o estado de hoje. Um JOIN sem recorte temporal cola esse estado de hoje em um fato de doze meses atrás — e o modelo passa a ver, no momento da compra, uma informação que só existiu depois dela. O sintoma é sempre o mesmo: métrica excelente no teste, desempenho medíocre em produção. Por isso a procedência não é burocracia de licença — embora a licença também importe, e nenhuma base pública deva ser usada sem ler a sua. De cada coluna que entra no seu conjunto de treino, saiba responder: quem a produz, com que frequência, e ela é sobrescrita ou versionada? Se você não sabe, você não sabe em que instante ela passou a valer.

SELECT p.pedido_id, p.data_pedido, p.valor,
       c.score_risco, c.situacao_cadastral
FROM   pedidos p
JOIN   clientes c ON c.cliente_id = p.cliente_id
WHERE  p.data_pedido BETWEEN '2025-01-01' AND '2025-12-31';

Síntese — o que levar #

• Otimizar para escrever e otimizar para ler são objetivos em conflito. O warehouse nasceu de aceitar isso e duplicar com disciplina.
• Inmon e Kimball discordam de onde a modelagem dimensional entra, não de que ela sirva. O warehouse híbrido é a norma, não o fracasso — leia-o como sedimento de restrições, e pergunte se cada uma ainda vale.
• Cada fonte falha à sua maneira: arquivo esconde esquema, API muda entre páginas, NoSQL guarda dois formatos no mesmo campo, streaming duplica por projeto.
• ETL transforma antes e descarta; ELT carrega o bruto e compra reversibilidade — pagando em armazenamento e em governança.
• Warehouse cobra esquema na escrita (caro por byte, barato por pergunta); lake cobra na leitura (o inverso); lakehouse tenta os dois e move o custo para a governança.
• Sem chave forte, integração é casamento probabilístico com limiar — e limiar é decisão de negócio, que se registra.
• Guarde no grão mais fino que couber no orçamento. Agregar depois é uma consulta; desagregar depois é uma coleta nova.
• Reprocessar é rotina, não exceção: MERGE por chave ou sobrescrita de partição, nunca INSERT puro.
• De cada coluna: quem produz, quando, e é sobrescrita ou versionada? Junção sem recorte de tempo é a fábrica número um de vazamento.

Verificação #

1. Uma diretora pergunta por que a empresa vai pagar por um data warehouse se "já existe o lake, e ele é mais barato". Responda em termos de custo por byte e custo por pergunta, com um exemplo de cada.
2. Um colega diz que o pipeline dele está correto porque "roda todo dia sem erro há seis meses". Que três perguntas você faz antes de confiar nos dados que ele entrega?

Estas duas não são corrigidas, e a omissão é deliberada: as duas se ganham convencendo alguém, e a resposta certa depende de quem está do outro lado da mesa.