Continuando a sequência de artigos sobre Kafka agora vamos entender o que é o Kafka Connect e iremos criar um listener que capturará mudanças no banco de dados e irá enviar para um tópico no Kafka.
\nO Kafka Connect é uma ferramenta open source criada pela Apache para poder se conectar com sistemas externos e lidar com volumes altíssimos de dados, podendo assim tanto receber quanto enviar dados para essas fontes. No artigo abaixo iremos explorar o Kafka Connect Source API que faz a parte de ingestão de dados mas também há o Kafka Connect Sink API que é o responsável por enviar dados de tópicos do Kafka para sistemas externos.
\nO Debezium é um CDC, abreviação para Change Data Capture, isso significa que ele é uma peça que fica conectada ao Kafka Connect e tem a responsabilidade de capturar alterações no banco de dados. Ele possui vários conectores para bancos de dados como SQL Server, Oracle, PostgreSQL, MongoDB e etc. nesse artigo será usado o connector para MySQL.
\nPara começar vamos analisar o esboço arquitetural abaixo e entender o que está sendo proposto:
\nVamos iniciar a configuração do Debezium no Kafka Connect. Quando acessar o dashboard na guia lateral clique em Connectors:\n No dashboard irá aparecer todos os conectores disponíveis (existem dois CDC MySQL mas é por que um é o CDC SQL Server que está com o nome errado):\n Irá aparecer o campo text area para inserir as configurações e a aqui vale passar ponto a ponto as configurações: Após adicionar as configurações basta clicar em Create Connector:\n Se clicarmos em Explore na guia lateral iremos ver que foram criados os tópicos e também foi criado os schemas no Schema Registry:\n Após todas essas configurações o conector está pronto e o Debezium já está escutando as alterações, sendo assim se fizermos um INSERT no banco Decider ele irá capturar esse evento através do Binlog e irá adicionar ao tópico do Kafka como na imagem abaixo:\n Aqui conseguimos ver alguns detalhes, primeiro a key passa a ser o id da tabela no banco de dados e segundo que o nosso value trás algumas informações mas o que chama mais a atenção é que ele consegue trazer o valor anterior e o valor atual que foi alterado, nesse exemplo como é um INSERT o campo before é nulo. Agora se atualizarmos o valor dessa linha na tabela:\n Isso gerará uma mensagem no tópico do Kafka onde no campo value poderá ser visto o valor do campo before com os dados antes da atualização e no campo after o valor atual daquela linha nesta tabela.\n Com isso agora temos o conector em pleno funcionamento capturando qualquer alteração realizada nas tabelas que configuramos para monitorar. No artigo foi apresentado como podemos usar um conector para “pegar” os dados em um banco de dados ou qualquer sistema externo e trazer para um tópico no Kafka; o oposto também pode ser feito que é capturar dados em um tópico e inserir em um sistema externo, essa é a responsabilidade do Connector Sink API e aqui deixo o link para um exemplo onde é usado o Connector Sink API para inserir dados em um banco de dados PostgreSQL. Segue o código feito no GitHubConfigurando Debezium
\nname=IRS-Connector\nconnector.class=io.debezium.connector.mysql.MySqlConnector\ndatabase.hostname=mysql\ndatabase.port=3306\ndatabase.user=user\ndatabase.password=user\ndatabase.allowPublicKeyRetrieval=true\ndatabase.server.name=irs-conn-v1\ndatabase.include.list=decider\ndatabase.exclude.list=register\ndatabase.blacklist=register\ndatabase.history.kafka.bootstrap.servers=localhost:9092\ndatabase.history.kafka.topic=schema-changes.decider\ntable.exclude.list=decider.flyway_schema_history,register.flyway_schema_history\ntable.blacklist=decider.flyway_schema_history,register.flyway_schema_history\n
\nname é obrigatório e define o nome do conector.connector.class é obrigatório e é a definição de qual classe que será carregada para esse conector.database.hostname, database.port, database.user e database.password são obrigatórios e são os dados de conexão do banco de dados.database.allowPublicKeyRetrieval é opcional e eu adicionei para permitir o client executar o request da public key.database.server.name é obrigatório, pode ser qualquer nome mas será usado como prefixo para os tópicos que serão criados no Kafka.database.include.list é opcional e serve para informar qual database deve ficar escutando as alterações, como nesse exemplo temos dois databases adicionei qual queria.database.exclude.listé opcional e é o oposto do campo acima e eu adicionei o database que eu não quero ficar observando as alterações.database.blacklist está depreciado pelo campo database.exclude.list segundo a documentação do Debezium, mas não sei se por questão de versão ou bug o campo database.exclude.list não estava funcionando; mas ele é exatamente a mesma ideia de excluir um database específico.database.history.kafka.bootstrap.servers é obrigatório e basicamente é o host/port do cluster do Kafka.database.history.kafka.topic é obrigatório e serve para nomear o tópico no Kafka onde o conector guarda o histórico de schemas do database.table.exclude.list é opcional e indica uma tabela que não deve ter as suas alterações observadas, deve estar no formato nome do database + nome da tabela, nesse caso como o projeto utiliza Flyway para gerenciamento das versões do banco de dados eu o adicionei.table.blacklist também está depreciado porém como ocorreu com o campo database.exclude.list não estava funcionando.Capturando mudanças no banco de dados
\nConclusão
\nCódigo fonte
\n