Imagina que tens uma tabela com dez milhões de clientes e queres mantê-la sincronizada no teu data warehouse. A abordagem ingénua é copiar os dez milhões de linhas todas as noites. Funciona — até deixar de funcionar. À medida que os dados crescem, essa cópia total demora cada vez mais, pesa cada vez mais sobre a base de dados de origem, e desperdiça recursos a mover milhões de linhas que não mudaram nada. Há uma forma muito melhor: capturar apenas o que mudou. Chama-se Change Data Capture, ou CDC.
O CDC é uma dessas técnicas que parecem um detalhe técnico mas que, na prática, decidem se a tua arquitetura de dados escala ou estrangula. Perceber o problema que resolve e as formas de o implementar é essencial para quem constrói pipelines que têm de acompanhar dados que crescem — ou seja, praticamente todos.
O problema da cópia total
Recarregar tudo a cada atualização é simples de programar e, com poucos dados, perfeitamente aceitável. O problema é que não escala. Se dos dez milhões de clientes só mil mudaram desde ontem, copiar os dez milhões é fazer dez mil vezes mais trabalho do que o necessário. Esse desperdício traduz-se em janelas de atualização que se esticam pela madrugada dentro, em bases de dados de origem sobrecarregadas no pior momento, e em custos de processamento que sobem sem que o valor suba com eles.
Há ainda um problema mais subtil: a cópia total só te dá o estado atual, não a história. Se um cliente mudou de morada três vezes desde a última cópia, tu só vês a última — perdeste as mudanças intermédias. Para muitas análises isso não importa; para outras, a história das mudanças é precisamente o que interessa. O CDC, ao capturar cada alteração, preserva essa história que a cópia total deita fora.
A ideia central: seguir as mudanças, não o estado
O CDC inverte a lógica. Em vez de perguntar "como está tudo agora?" e copiar o resultado inteiro, pergunta "o que mudou desde a última vez?" e move apenas essas alterações — as inserções, as atualizações e as eliminações. Como o número de mudanças num período é tipicamente uma fração minúscula do total, o volume a mover é pequeno, a atualização é rápida, e a origem quase não sente o peso. É a diferença entre mudar de casa todos os dias e apenas trazer o que é novo.
As formas de capturar as mudanças
- Por marca temporal: se cada linha tem um campo "última alteração", basta pedir as que mudaram desde a última execução. Simples, mas depende de a coluna existir e ser sempre atualizada — e não apanha eliminações.
- Por comparação: comparar o estado atual com uma cópia anterior para detetar diferenças. Funciona sempre, mas é pesado, o que contraria em parte o objetivo.
- A partir do log da base de dados: a forma mais poderosa. As bases de dados registam internamente cada alteração num log de transações; o CDC baseado em log lê esse registo e reconstrói as mudanças sem sequer tocar nas tabelas — mínimo impacto na origem, apanha tudo (incluindo eliminações), quase em tempo real.
Porque o CDC baseado em log é o padrão de ouro
Ler o log de transações é elegante porque aproveita algo que a base de dados já faz de qualquer forma para garantir a sua própria consistência. Não é preciso adicionar colunas, não é preciso sobrecarregar a origem com comparações, e não escapa nenhuma mudança — nem sequer as eliminações, que as outras técnicas costumam perder. Em troca desta potência, exige mais configuração e acesso a mecanismos internos da base de dados, o que o torna mais complexo de montar. É o padrão para volumes grandes e requisitos de baixa latência, mas para casos simples as abordagens mais leves chegam.
Um caso concreto
Uma empresa tinha um pipeline noturno que copiava várias tabelas grandes por inteiro para o data warehouse. No início, corria em vinte minutos. À medida que os dados cresceram ao longo de dois anos, essa janela esticou-se para mais de três horas — e começou a colidir com o início do dia de trabalho, altura em que a base de dados de origem já estava a ser usada para operações e não aguentava a carga extra. Os relatórios matinais atrasavam-se, e a equipa vivia a apagar o fogo de uma atualização que já não cabia na noite. A solução não foi comprar hardware maior — foi mudar para CDC baseado em log. Em vez de copiar tudo, o pipeline passou a mover apenas as mudanças de cada tabela, que eram uma pequena fração do total. A janela de atualização caiu de três horas para poucos minutos, a base de dados de origem deixou de sentir o peso, e os relatórios voltaram a estar prontos muito antes do início do dia. O mesmo hardware, uma técnica diferente, um problema resolvido de forma duradoura.
Quando não vale a pena a complexidade
O CDC brilha com volumes grandes e necessidade de frescura. Mas se tens tabelas pequenas que cabem numa cópia total rápida, adicionar CDC é complexidade sem retorno — a cópia total simples é mais fácil de construir e manter. Como quase tudo em engenharia de dados, a técnica certa depende do problema: usar CDC "porque é moderno", sem a escala que o justifica, é resolver um problema que não tens à custa de complicar o que já funcionava.
Na prática
Se as tuas janelas de atualização estão a esticar e a origem sofre com cópias totais cada vez mais pesadas, o CDC é provavelmente a resposta que estás a evitar. Começa por identificar as tabelas maiores e mais custosas de recarregar, e avalia mover apenas o que muda nessas. A maioria dos problemas de "a atualização já não cabe na noite" resolve-se assim. As tuas tabelas grandes estão a ser copiadas por inteiro todas as noites, quando só uma fração delas muda?
