Real time replication using Kafka Connect

Replicação de Dados
em Tempo Real
Um projeto de replicação de banco de dados DB2/AS400
para a nuvem u@lizando a plataforma
Apache KaEa, KaEa Streams e KaEa Connect
16/11/2022
Gil César Faria

• Gil César Faria, atua em TI desde 1991, formou-se em Ciência da Computação
pela Unicamp e com MBA RH pela FIA
• Co-founder da Inmetrics, atuou no Brasil e no Chile em Consultoria de TI e Gestão
• Atualmente é sócio da TruStep, onde é responsável técnico pelos projetos da
empresa, com atuação no Brasil e no Chile, com foco em AWS e Apache KaEa
• Meu papel no projeto foi de arquiteto e líder técnico da solução, coordenando
uma equipe de quatro pessoas, interagindo com outras equipes do cliente e de
terceiros envolvidas diretamente na execução, e implementando diretamente
alguns dos componentes crí@cos da plataforma.
Apresentação Pessoal

Contexto Inicial
• Empresa chilena do ramo ﬁnanceiro com mais de 2 milhões de clientes a@vos
• Core bancário world class (an@go) implementado sobre DB2/AS400
• Digitalização inicial trouxe colapso seguido da plataforma de integração fuse

Conceitos Fundamentais
Alguns conceitos fundamentais além do básico para compreender melhor a implementação

• Tabelas u@lizadas com se fossem “arquivos” estruturados hierarquicamente
• Sem chaves primarias deﬁnidas, sem chaves estrangeiras deﬁnidas, embora
algumas chaves lógicas implícitas assumidas pelos aplica@vos exis@ssem.
• Sem garan@a de integridade referencial e sem normalização
• Manutenção anual com reorganização completa das tabelas para gerenciar
espaço e arquivamento de informações (truncates, reorganize, copias de tabelas)
• Regras de negócio implementadas em programas RPG
Caracterís@cas do Core Bancário

• Change Data Capture (CDC): representa uma transação de banco de dados, um
insert, um update ou um delete em par@cular
• Traz a informação sobre os valores de cada coluna, além de metadados, como o
nome da tabela, @po de operação, @mestamp da transação, dentre outros
O que são CDCs

{ "XPICID": "12345678",
"XPITDC": "X",
"XPIIST": " ",
"XPINAD": 0,
"XPIPTY": "IM13",
"XPIPLA": "99",
"XPIISM": 9,
"XPIISD": 23,
"XPIISY": 1999,
"XPILST": "1999-09-23 23:44:01.000000",
"XPIDAI": "0.00",
"XPISTS": "00",
"RRN_FIELD_DATA": 123455234,
"sv_manip_type": { "string": "I"},
"sv_sending_table": { "string": "LIBRARY.XPIMF" },
"sv_op_timestamp": { “string": "19990923234401958672" },
"sv_journal_seqno": { "string": "" }
}
Exemplo de CDC
sv_manip_type marca o @po de transação:
• I: Insert
• U: Update
• D: Delete
• T: Truncate
• ‘ ‘(espaço): Carga inicial
RRN_FIELD_DATA representa o
endereço jsico da linha no banco de
dados

Dualidade: Tópicos X Tabelas
Fonte: h:ps://ka=a.apache.org/33/documentaEon/streams/core-concepts

Limpeza de Tópicos - 101
Fonte: h:ps://ka=a.apache.org/documentaEon/#geHngStarted

Compactação de Tópicos
Fonte: h:ps://ka=a.apache.org/documentaEon/#geHngStarted

KaEa Streams
Fonte: h:ps://docs.conﬂuent.io/plaLorm/current/streams/introducEon.html#use-case-examples

KaEa Connect
Fonte: h:ps://docs.conﬂuent.io/3.0.0/plaLorm.html

Implementação
Como foi implementada cada camada da arquitetura

• Serviço gerenciado AWS MSK - KaEa 2.7.0 - provisionado
• 3 nós kaEa.m5.large (2vCPU, 8Gb RAM, 10Gbps banda rede), 350GB disco cada
• Entrada: replica@on.factor=3, par@@ons=1, min.insync.replicas=2, reten@on=2d
• Saída: replica@on.factor=3, par@@ons=3, min.insync.replicas=2, cleanup.policy=compact
• Ocupação média de disco varia entre 20% a 40%
• Durante a noite, Picos de CPU de 15%, RX/TX packets de 1200 avg
• Durante o dia média de CPU ﬁca em 5%, RX/TX packets de 600 ou menos avg
Cluster KaEa Brokers (MSK)

• Launch Templates instalação automa@zada do cluster (conﬂuent 6.0.0)
• Autoscaling groups com 3 instancias
• Applica@on Load Balance para API REST de administração
• Target Groups para veriﬁcar saúde de cada nó através da API REST
• t2.medium (2 vCpus, 4Gb RAM), 8Gb Disco
• Pico de CPU abaixo de 10%
• 41 conectores, somente 1 com 3 tasks, todos os demais com apenas 1 task
Cluster KaEa Connect (EC2)

• Launch Templates instalação automa@zada do cluster (conﬂuent 6.0.0)
• Applica@on Load Balance para API REST de administração
• Target Groups para veriﬁcar saúde de cada nó através da API REST
• t2.small (1 vCpus, 2Gb RAM), 8Gb Disco
• Pico de CPU abaixo de 5%
• 481 schemas, entre chaves e valores, para tópicos de entrada, intermediários e de saída
Cluster KaEa Schema Registry (EC2)

• Launch Conﬁgura@on com instalação e coﬁguração automa@zada por terraform
• m5.xlarge (4 vCpus, 16Gb RAM), 100Gb Disco
• Pico de CPU abaixo de 25%, na média abaixo de 10%
• 54 pods, reinicio automá@co, cada um executando uma aplicação kaEa streams
Cluster Kubernetes (EKS)

Transformações
Como os dados são mapeados e processados desde a origem DB2/AS400 até o des@no AWS RDS

• 24 tópicos de entrada, 157 tópicos intermediarios,
• 35 tópicos de saída e DLQ, 7 tópicos internos de administração
Tópicos de Entrada X Saída

• Transformações de Entrada processam um tópico de entrada (stream) gerando um ou
mais tópicos em formato de tabela (changelogs)
• São capazes de processar todos os @pos de transações (sv_manip_type).
• Inserts/Updates/Deletes possuem tratamento trivial
• Truncates e cargas iniciais possuem tratamento similar: ambos eliminam todas as
chaves existentes nos des@nos antes de processar a informação. Ela ocorre sem que
se interrompa o processamento de novas transações.
• Um buﬀer temporário (tópico kaEa) armazena as transações novas enquanto a
limpeza é efetuada nos tópicos de des@no.
Transformações de Entrada

Topologies:
Sub-topology: 0
Source: Source (topics: [LIBRARY.XPIMST])
--> Processor
Processor: Processor (stores:
[LIBRARY.XPIMST-source-store])
--> Sink
<-- Source
Sink: Sink (topic: LIBRARY.XPIMST.table)
<-- Processor
Topologia de Entrada

• Processam um ou mais tópico de entrada em formato de tabela (changelogs)
• Aplicam regras de negócio e mapeamentos
• Geram um tópico de saída (changelog) que representa a tabela de des@no
• Inserts, Updates e Cargas Iniciais são tratados como “upserts”
• Deletes em geral são tratados como “delete lógico”, com algumas exceções
• Truncates são ignorados, com algumas exceções
Transformações de Saída

Topologies:
Sub-topology: 0
Source: KSTREAM-SOURCE-0000000000 (topics:
[LIBRARY.XPITIN.table])
--> KSTREAM-FILTER-0000000001
Processor: KSTREAM-FILTER-0000000001 (stores: [])
--> KSTREAM-MAPVALUES-0000000002
<-- KSTREAM-SOURCE-0000000000
Processor: KSTREAM-MAPVALUES-0000000002 (stores: [])
--> KSTREAM-FLATMAPVALUES-0000000003
<-- KSTREAM-FILTER-0000000001
Processor: KSTREAM-FLATMAPVALUES-0000000003 (stores: [])
--> KSTREAM-SINK-0000000004
<-- KSTREAM-MAPVALUES-0000000002
Sink: KSTREAM-SINK-0000000004 (topic:
msDatabase.tabladescuento.table)
<-- KSTREAM-FLATMAPVALUES-0000000003
Topologia de Saída Simples

Topologies:
Sub-topology: 0 for global store (will not generate tasks)
Source: KSTREAM-SOURCE-0000000001 (topics: [msDatabase.parametro.table])
--> KTABLE-SOURCE-0000000002
Processor: KTABLE-SOURCE-0000000002 (stores: [msDatabase.parametro.table-STATE-STORE-0000000000])
--> none
Sub-topology: 1
Source: KSTREAM-SOURCE-0000000003 (topics: [LIBRARY.XPIMAP.table])
--> KSTREAM-KEY-SELECT-0000000005
Processor: KSTREAM-KEY-SELECT-0000000005 (stores: [])
--> LAST-XPIMAP-repartition-filter
Processor: LAST-XPIMAP-repartition-filter (stores: [])
--> LAST-XPIMAP-repartition-sink
<-- KSTREAM-KEY-SELECT-0000000005
Sink: LAST-XPIMAP-repartition-sink (topic: LAST-XPIMAP-repartition)
<-- LAST-XPIMAP-repartition-filter
Topologia de Saída Complexa

Sub-topology: 2
Source: XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-registration-source (topics: [XPIALS-
LeftJoinedWith-LAST-XPIMAP-subscription-registration-topic])
--> XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-receive
Source: LAST-XPIMAP-repartition-source (topics: [LAST-XPIMAP-repartition])
--> LAST-XPIMAP
Processor: XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-receive (stores: [XPIALS-LeftJoinedWith-LAST-
XPIMAP-subscription-store])
--> XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-join-foreign
<-- XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-registration-source
Processor: LAST-XPIMAP (stores: [LAST-XPIMAP])
--> XPIALS-LeftJoinedWith-LAST-XPIMAP-foreign-join-subscription
<-- LAST-XPIMAP-repartition-source
Processor: XPIALS-LeftJoinedWith-LAST-XPIMAP-foreign-join-subscription (stores: [XPIALS-LeftJoinedWith-
LAST-XPIMAP-subscription-store])
--> XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-response-sink
<-- LAST-XPIMAP
Processor: XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-join-foreign (stores: [LAST-XPIMAP])
--> XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-response-sink
<-- XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-receive
Sink: XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-response-sink (topic: XPIALS-LeftJoinedWith-LAST-
XPIMAP-subscription-response-topic)
<-- XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-join-foreign, XPIALS-LeftJoinedWith-LAST-XPIMAP-
foreign-join-subscription

Sub-topology: 3
Source: KSTREAM-SOURCE-0000000010 (topics: [LIBRARY.XPIXE.table])
--> KSTREAM-KEY-SELECT-0000000012
Processor: KSTREAM-KEY-SELECT-0000000012 (stores: [])
--> VALID-XPIXE-repartition-filter
Processor: VALID-XPIXE-repartition-filter (stores: [])
--> VALID-XPIXE-repartition-sink
<-- KSTREAM-KEY-SELECT-0000000012
Sink: VALID-XPIXE-repartition-sink (topic: VALID-XPIXE-
repartition)
<-- VALID-XPIXE-repartition-filter

Sub-topology: 4
Source: XPIALS-LeftJoinedWith-XPIXE-subscription-registration-source (topics: [XPIALS-LeftJoinedWith-
XPIXE-subscription-registration-topic])
--> XPIALS-LeftJoinedWith-XPIXE-subscription-receive
Source: VALID-XPIXE-repartition-source (topics: [VALID-XPIXE-repartition])
--> VALID-XPIXE
Processor: XPIALS-LeftJoinedWith-XPIXE-subscription-receive (stores: [XPIALS-LeftJoinedWith-XPIXE-
subscription-store])
--> XPIALS-LeftJoinedWith-XPIXE-subscription-join-foreign
<-- XPIALS-LeftJoinedWith-XPIXE-subscription-registration-source
Processor: VALID-XPIXE (stores: [VALID-XPIXE])
--> XPIALS-LeftJoinedWith-XPIXE-foreign-join-subscription
<-- VALID-XPIXE-repartition-source
Processor: XPIALS-LeftJoinedWith-XPIXE-foreign-join-subscription (stores: [XPIALS-LeftJoinedWith-XPIXE-
subscription-store])
--> XPIALS-LeftJoinedWith-XPIXE-subscription-response-sink
<-- VALID-XPIXE
Processor: XPIALS-LeftJoinedWith-XPIXE-subscription-join-foreign (stores: [VALID-XPIXE])
--> XPIALS-LeftJoinedWith-XPIXE-subscription-response-sink
<-- XPIALS-LeftJoinedWith-XPIXE-subscription-receive
Sink: XPIALS-LeftJoinedWith-XPIXE-subscription-response-sink (topic: XPIALS-LeftJoinedWith-XPIXE-
subscription-response-topic)
<-- XPIALS-LeftJoinedWith-XPIXE-subscription-join-foreign, XPIALS-LeftJoinedWith-XPIXE-foreign-join-
subscription

Sub-topology: 5
Source: XPIALS-LeftJoinedWith-XPIXE-subscription-response-source
(topics: [XPIALS-LeftJoinedWith-XPIXE-subscription-response-topic])
--> XPIALS-LeftJoinedWith-XPIXE-subscription-response-resolver
Processor: XPIALS-LeftJoinedWith-XPIXE-subscription-response-
resolver (stores: [KTABLE-FK-JOIN-OUTPUT-STATE-STORE-0000000035])
--> XPIALS-LeftJoinedWith-XPIXE-result
<-- XPIALS-LeftJoinedWith-XPIXE-subscription-response-source
Processor: XPIALS-LeftJoinedWith-XPIXE-result (stores: [])
--> KTABLE-FILTER-0000000051
<-- XPIALS-LeftJoinedWith-XPIXE-subscription-response-resolver
Source: XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-response-
source (topics: [XPIALS-LeftJoinedWith-LAST-XPIMAP-subscription-
response-topic])
…

Sub-topology: 6
Source: Handle-sv-manip-type-repartition-source (topics: [Handle-sv-manip-
type-repartition])
--> Handle-sv-manip-type
Processor: Handle-sv-manip-type (stores: [Handle-sv-manip-type])
--> KTABLE-TOSTREAM-0000000059
<-- Handle-sv-manip-type-repartition-source
Processor: KTABLE-TOSTREAM-0000000059 (stores: [])
--> KSTREAM-FLATMAPVALUES-0000000060
<-- Handle-sv-manip-type
Processor: KSTREAM-FLATMAPVALUES-0000000060 (stores: [])
--> KSTREAM-MAPVALUES-0000000061
<-- KTABLE-TOSTREAM-0000000059
Processor: KSTREAM-MAPVALUES-0000000061 (stores: [])
--> KSTREAM-SINK-0000000062
<-- KSTREAM-FLATMAPVALUES-0000000060
Sink: KSTREAM-SINK-0000000062 (topic: msDatabase.CuentaDeposito.table)
<-- KSTREAM-MAPVALUES-0000000061

Conectores
Como os dados são levados aos sistemas de des@no (Base de dados Aurora Postgres e Redis)

• São responsáveis por executar comandos SQL no banco de dados
• Limpam os caches Redis em algumas transações especíﬁcas
• Garantem seman@ca de processamento 1 e somente 1
• Controlam oﬀsets dos consumer groups em tabelas do banco de dados, por
tópico e par@ção, mas também atualizam o mecanismo default como backup,
sem garanza de transação.
• Podem invocar Stored Procedures ou executar as primi@vas SQL diretamente
Conectores

Conectores - Tratamento de Falhas

• Falhas são tratadas de duas formas dis@ntas:
• Erros de infra-estrutura, conec@vidade ou de programação bloqueiam o ﬂuxo
• Erros de lógica relacional (chaves estrangeiras inexistentes principalmente)
bloqueiam o ﬂuxo até um limite, liberando-o após um número de tenta@vas
pré-determinado.
• São enviados para DLQs (uma para cada tópico de saída)
• Um conector especial copia as DLQs de cada saída para um conjunto de tabelas,
permi@ndo acesso fácil aos usuários para revisão manual
Tratamento de Exceções

• Todos os tópicos de saída possuem múl@plas par@ções.
• Quando um truncate chega, não basta apenas executá-lo na BBDD
• É necessário reposicionar os oﬀsets do consumer group para reﬂe@r o tempo
correto da execução do truncate
Tratamento de Truncates e Par@ções

Tratamento de Truncates e Par@ções
Registros atrasados não precisam
mais ser processados, já “caducaram”
Registros adiantados devem ser
reprocessados para não se perderem
após o truncate ser executado

Desajos
Quais os principais desajos que observamos na implementação dessa plataforma

• Paradigma Relacional versus orientação a eventos
• Compa@bilização e consistência dos modelos de dados
• Conhecimento do sistema legado incompleto ou disperso
• Tratamento de exceções e casos não previstos: QA vs Pro
• Monitoramento e resposta a falhas no pipeline
• Testes unitários e integrados: TopologyTestDriver, TestContainers e Flyway são seus amigos
• Avro: desajo adicional pois a documentação não é muito extensa no uso de APIs de kaEa,
principalmente componentes kaEa streams, em combinação com schemas Avro
Durante o projeto e pós passo a produção

• Estabelecimento de um plano de recuperação de desastres (AWS Region offline)
• Diminuir o tempo de resposta a incidentes nos fluxos de dados
• Monitoramento detalhado dos fluxos: lags, atraso no processamento de
mensagens
• Reestruturação do repositório GIT e projetos Maven
• Melhoria do processo de CI/CD no projeto
Próximos Passos

• h:ps://www.trustep.io/pt/blog/49-arEgos-tecnicos/90-apache-ka=a-como-plataforma-
de-replicacao-de-dados-em-tempo-real
• h}ps://github.com/zz85/kaEa-streams-viz
• h}ps://docs.confluent.io/pla~orm/current/connect/concepts.html#kconnect-long-concepts
• h}ps://docs.confluent.io/pla~orm/current/connect/devguide.html#suggested-reading
• h}ps://docs.confluent.io/pla~orm/current/streams/developer-guide/write-
streams.html#using-kstreams-within-your-applica@on-code
• h}ps://kaEa.apache.org/33/documenta@on/streams/developer-guide/
Referências

• Twi:er: @gilcesarf
• Linked-In: www.linkedin.com/in/gilcesar
• YouTube: h:ps://www.youtube.com/@trustepgilcesar
• e-mail: gilcesarf@trustep.io
Contatos

Real time replication using Kafka Connect

Mais conteúdo relacionado

Mais procurados

Semelhante a Real time replication using Kafka Connect

Mais de confluent

Real time replication using Kafka Connect