Você está na página 1de 34

Change Data

Capture (CDC)
com Debezium
OPORTUNIDADES E IMPACTOS
SQUAD ED - PULSE
Change Data Capture - CDC 2

 Change Data Capture ou CDC é um processo de software que


identifica e rastreia alterações nos dados de um banco de dados.
 O CDC possibilita movimentação de dados em tempo real ou
quase em tempo real, movendo e processando dados
continuamente à medida que novos eventos de banco de dados
ocorrem;
 Em ambientes críticos e onde informações em tempo real são
altamente valiosas, o CDC é uma excelente opção para obter
replicação de dados com baixa latência, confiáveis e
escalonáveis;
Change Data Capture Methods 3

 Audit Columns
 Table Deltas
 Trigger-based CDC
 Log-Based CDC
Change Data Capture Methods 4

Audit Columns
 Usando as colunas “LAST_UPDATED” ou “DATE_MODIFIED;
 Essa abordagem recupera apenas as linhas que foram alteradas desde a
última extração dos dados;
 Como funciona:
 Etapa 1: obtenha o valor máximo das colunas ‘Created_Time’ e ‘Updated_Time’ da
tabela de destino;
 Etapa 2: Selecione todas as linhas da fonte de dados com ‘Created_Time’ maior que
(>) o máximo ‘Created_Time’ da tabela de destino;
 Etapa 3: selecione todas as linhas da tabela de origem que têm um ‘Updated_Time’
maior que (>) o máximo ‘Updated_Time’ da tabela de destino, mas menor que (<)
seu máximo ‘Created_Time’;
 Etapa 4: insira novas linhas da etapa 2 ou modifique as linhas existentes da etapa 3
no destino.
Change Data Capture Methods 5

Audit Columns
Target Source
Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00

15:00 17:00 17:00 20:00

12:00 18:00 15:30 12:00

11:00 17:00 12:00 19:30

12:50 17:00 16:00 17:00


Change Data Capture Methods 6

Audit Columns
Target Source
Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00

15:00 17:00 17:00 20:00

12:00 18:00 15:30 12:00

11:00 17:00 12:00 19:30

12:50 17:00 16:00 17:00


Change Data Capture Methods 7

Audit Columns
Target Source Target
Created_Time Updated_Time Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00 9:00 19:00

15:00 17:00 17:00 20:00 17:00 20:00

12:00 18:00 15:30 12:00 15:30 12:00

11:00 17:00 12:00 19:30 12:00 19:30

12:50 17:00 16:00 17:00 16:00 17:00


Change Data Capture Methods 8

Audit Columns
Target Source Target
Created_Time Updated_Time Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00 9:00 19:00

15:00 17:00 17:00 20:00 17:00 20:00

12:00 18:00 15:30 12:00 15:30 12:00

11:00 17:00 12:00 19:30 12:00 19:30

12:50 17:00 16:00 17:00 16:00 17:00

Target Source
Created_Time Updated_Time Created_Time Updated_Time

13:00 16:00 9:00 19:00

15:00 17:00 17:00 20:00

12:00 18:00 15:30 12:00

11:00 17:00 12:00 19:30

12:50 17:00 16:00 17:00


Change Data Capture Methods 9

Audit Columns
Target Source Target
Created_Time Updated_Time Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00 9:00 19:00

15:00 17:00 17:00 20:00 17:00 20:00

12:00 18:00 15:30 12:00 15:30 12:00

11:00 17:00 12:00 19:30 12:00 19:30

12:50 17:00 16:00 17:00 16:00 17:00

Target Source
Created_Time Updated_Time Created_Time Updated_Time

13:00 16:00 9:00 19:00

15:00 17:00 17:00 20:00

12:00 18:00 15:30 12:00

11:00 17:00 12:00 19:30

12:50 17:00 16:00 17:00


Change Data Capture Methods 10

Audit Columns
Target Source Target
Created_Time Updated_Time Created_Time Updated_Time Created_Time Updated_Time
13:00 16:00 9:00 19:00 9:00 19:00

15:00 17:00 17:00 20:00 17:00 20:00

12:00 18:00 15:30 12:00 15:30 12:00

11:00 17:00 12:00 19:30 12:00 19:30

12:50 17:00 16:00 17:00 16:00 17:00

Target Source Target


Created_Time Updated_Time Created_Time Updated_Time Created_Time Updated_Time

13:00 16:00 9:00 19:00 9:00 19:00

15:00 17:00 17:00 20:00 17:00 20:00

12:00 18:00 15:30 12:00 15:30 12:00

11:00 17:00 12:00 19:30 12:00 19:30

12:50 17:00 16:00 17:00 16:00 17:00


Change Data Capture Methods 11

Audit Columns
 Prós:
 Pode ser construído na aplicação nativa;
 Não requer nenhuma ferramenta externa.
 Contras:
 Adiciona sobrecarga adicional ao banco de dados;
 As instruções DML, como exclusões, não serão propagadas para o
destino sem scripts adicionais para rastrear exclusões;
 Propenso a erros e provavelmente causará problemas de consistência
de dados.
Change Data Capture Methods 12

Table Deltas
 Esse método faz uso de uma tabela adicional para armazenar o
snapshot da última atualização feita na tabela destino;
 Através de um script, são identificadas as últimas alterações entre a
tabela origem e o último snapshot, e então, as modificações
identificadas são propagadas para a tabela destino.
Change Data Capture Methods 13

Table Deltas

New Snapshot Previous Snapshot


User ID Last Purchase Created_Time Updated_Time

10 14-12-2021 10 20-11-2021

11 05-03-2021 11 05-03-2021

12 26-07-2021 12 26-07-2021

13 15-02-2021 13 15-02-2021

14 24-11-2021
Change Data Capture Methods 14

Table Deltas

New Snapshot Previous Snapshot


User ID Last Purchase Created_Time Updated_Time

10 14-12-2021 10 20-11-2021

11 05-03-2021 11 05-03-2021

12 26-07-2021 12 26-07-2021

13 15-02-2021 13 15-02-2021

14 24-11-2021
Change Data Capture Methods 15

Table Deltas

New Snapshot Previous Snapshot Target


User ID Last Purchase Created_Time Updated_Time User ID Last Purchase

10 14-12-2021 10 20-11-2021 10 14-12-2021

11 05-03-2021 11 05-03-2021 11 05-03-2021

12 26-07-2021 12 26-07-2021 12 26-07-2021

13 15-02-2021 13 15-02-2021 13 15-02-2021

14 24-11-2021 14 24-11-2021
Change Data Capture Methods 16

Table Deltas
 Prós:
 Fornece uma visão precisa dos dados alterados, usando apenas scripts SQL
nativos.
 Contras:
 A demanda por armazenamento aumenta significativamente porque você
precisa de três cópias das fontes de dados que estão sendo usadas nesta
técnica: os dados originais, o snapshot anterior e snapshot atual;
 Ele não escala muito bem em aplicações com cargas de trabalho
transacionais pesadas;
 Possuí uma latência considerável, não sendo possível aplicar para
replicações em tempo real.
Change Data Capture Methods 17

Trigger-based CDC
 CDC no nível de aplicação: definição de triggers de banco de
dados e criação de log de alterações em shadow tables;
 Os triggers são acionados antes ou depois dos comandos INSERT,
UPDATE ou DELETE e são usados para criar um log de alterações;
 Alguns bancos de dados têm suporte nativo para triggers;
 Requer triggers individuais para cada tabela do banco;
Change Data Capture Methods 18

Trigger-based CDC
 Prós:
 As shadow tables podem fornecer um registro detalhado e imutável de
todas as transações;
 Suporte direto na API SQL de alguns bancos de dados;
 Contras:
 Reduz significativamente o desempenho do banco de dados, exigindo
várias gravações em um banco de dados sempre que uma linha é
inserida, atualizada ou excluída;
 Significativo impacto na performance da aplicação, além da
preocupação de gerenciamento das triggers de acordo com
atualizações da aplicação.
Change Data Capture Methods 19

Log-Based CDC
 Utiliza logs nativos do DBSM (também chamados
de logs de redo) que armazenam todos os DBSM LOGS
eventos do banco de dados, permitindo que o
banco de dados se recupere em caso de crash;
 Novas transações de banco de dados -
incluindo INSERT, UPDATE e DELETE - são lidas dos PROCESSING DATA SINK
logs de transações nativas dos bancos de
dados de origem;
 As mudanças são capturadas sem necessidade
de mudanças no nível da aplicação e sem ter
que varrer as tabelas operacionais;
Change Data Capture Methods 20

Log-Based CDC: Data propagation methods


 Replication-mode:
 A replicação cria uma cópia da fonte de dados: as atualizações irão
alterar os dados no destino e as exclusões removerão os dados do
destino;
 Réplica idêntica da fonte de dados.
 Auditing-mode:
 O Auditing-mode mantém todo o histórico de dados. A ferramenta
CDC converte atualizações e exclusões em inserções no banco destino
e uma flag indica o tipo de operação (INSERT, UPDATE ou DELETE) e
uma coluna de timestamp indica quando o evento aconteceu;
 Preserva rastreabilidade dos dados.
Change Data Capture Methods 21

Log-Based CDC
 Prós:
 Impacto mínimo no DBSM de produção - nenhuma consulta adicional necessária
para cada transação;
 Preserva a confiabilidade de transações ACID;
 Não há necessidade de alteração de esquemas do DBSM de produção ou de
tabelas adicionais;
 O CDC reduz a quantidade de dados transmitidos pela rede em comparação com
os outros métodos de detecção descritos acima.
 Contras:
 Manutenção do formato interno de registro do DBSM pode ser desafiador;
 É necessário um para gerenciar os metadados dos eventos de mudança do banco
de dados de origem;
 As chaves primárias ou exclusivas são necessárias para muitas ferramentas de CDC
baseadas em log (mas nada que um bom design de banco de dados não garanta).
Debezium 22

 Debezium é uma plataforma distribuída de código aberto para


CDC. Inicie, aponte para seus bancos de dados e suas aplicações
podem começar a responder a todas as inserções, atualizações e
exclusões que outros aplicativos realizam em seus bancos de
dados. Debezium é confiável e rápido, então seus aplicativos
podem responder rapidamente e nunca perder um evento, mesmo
quando algo dá errado.
Arquitetura do Debezium 23

 A arquitetura da Debezium gira em torno do conceito de


"conectores".
 Um conector pode ser configurado em um banco de dados de
origem para detectar as mudanças realizadas no banco e gerar
um stream de eventos de mudanças realizadas nas tabelas-alvo;
 O Debezium atualmente fornece conectores para MySQL,
PostgreSQL, SQL Server, Oracle, Db2 e MongoDB;
 Essencialmente, Debezium é uma coleção de conectores. Não
existe um órgão central que os comanda e controla. Um único
conector incorpora a lógica do Debezium de detecção de
alterações e conversão em eventos.
Metódos de deploy do Debezium 24

 Debezium como uma biblioteca


 Debezium Server
 Debezium com Kafka Connect
Metódos de deploy do Debezium 25

Debezium como uma biblioteca


 O Debezium será executado como uma biblioteca incorporada na
aplicação Java. Esta é a maneira mais simples de usar o Debezium
sem depender de outro aplicação externa.

Debezium Connector

Change Events

Aplicação Java
Metódos de deploy do Debezium 26

Debezium Server
 Outra forma de deploy do Debezium é usando o Debezium Server.
O Debezium Server é uma aplicação configurável e pronta para
usar, que transmite eventos de CDC de banco de dados de origem
para vários tipos de infraestruturas de mensageria.

Debezium
MySql

Debezium
Postgres
Source Connectors

Debezium Server
Metódos de deploy do Debezium 27

Debezium com Kafka Connect


 Para casos de uso corporativos que exigem armazenamento
tolerante a falhas, escalabilidade e desempenho, o Debezium
deve ser implantado como um serviço no Apache Kafka Connect;
 O Kafka Connect opera como um serviço separado do Kafka
Broker;
 Conectores de origem, como Debezium, enviam registros para o
Kafka;
 Conectores coletores que propagam registros de tópicos Kafka
para outros sistemas;
Metódos de deploy do Debezium 28

Debezium com Kafka Connect


 O Kafka Connect fornece tolerância a falhas e escalabilidade para
o Debezium;
 Ele pode agendar vários conectores em muitos nós;
 Se um conector falhar, o Kafka Connect irá reagendá-lo e fazer
com que retome as operações.

Debezium
Postgres

Kafka Connect
Uso do Debezium para replicação 29

de dados do Maxipos
A criação de relatórios com dados que se encontram no banco
Maxipos demanda a movimentação desses dados para o data
lakehouse. Entretanto, para a implantação da solução de CDC
baseado em log, é necessário um teste para avaliar o impacto que o
Debezium teria Maxipos, já que se trata de um banco crítico para a
operação de todo o Grupo Mateus.
Uso do Debezium para replicação 30

de dados do Maxipos
Passos para a implantação do CDC com Debezium no
Maxipos:
 Configuração da replicação lógica no banco Maxipos;
 Deploy do Debezium com o Kafka Connect (VM ou K8s)
na Azure;
 Configuração do Kafka Connect com o Azure Event
Hub;
 Propagação das atualizações nas tabelas destino no
data lakehouse.
Teste de impacto do Debezium no 31

PostgreSQL
 Realizamos um experimento para medir o impacto do uso de CDC
durante a execução de uma carga de leitura/escrita em um
banco transacional (OTLP);
 Para isso, criamos duas máquinas virtuais na Azure Cloud, com o
PostgreSQL em cada máquina.
 Em uma das máquinas o PostgreSQL é preparada para o CDC
baseado em log, e uma terceira máquina com Kafka Connect +
Debezium lê os logs e envia para tópicos Kafka;
 Monitoramos o uso de CPU, memória disponível e operações de
leitura/escrita no disco, enquanto um script Python realiza várias
operações de INSERT, UPDATE e DELETE nos dois bancos.
Resultados 32
Resultados 33
Conclusão 34

O CDC baseado em log é uma ótima alternativa em uma abordagem


de streaming near real time sem impactos consideráveis no banco
Maxipos, considerando as outras alternativas de CDC e os custos de
implantação da tecnologia.

Você também pode gostar