Introducción a Change Data Capture (CDC)

En este artículo vamos a realizar una Introducción a Change Data Capture (CDC), un patrón que se hace esencial en arquitecturas complejas de microservicios en los que intervienen diferentes elementos y piezas.

¿Por qué usar Change Data Capture (CDC) ?

Cuando comenzamos a crear una arquitectura, lo más normal es que comencemos por lo esencial en donde influyen pocos componentes más allá de una Base de Datos con algunos microservicios.

Esto en un primer momento seguro que nos funciona bien y cumple con nuestras necesidades, por ejemplo, tenemos una aplicación bancaria en el que tenemos diferentes microservicios con una Base de Datos por microservicio.

El ejemplo anterior muestra una arquitectura en donde cada microservicio tiene una base de datos con la que se comunica, obtiene la información y la muestra. En un primer momento, esta aproximación puede servirnos, pero si queremos añadir un ElasticSearch para realizar indexaciones de datos, o añadir una Base de Datos en la que realizar alguna explotación de la información, cómo lo hacemos?

Para esos casos vamos a querer utilizar una Base de Datos adicional que sea una réplica de las Base de Datos que ya tenemos, pero esto nos va a provocar tener información redundante tener que duplicarla, adaptarla etc…

Estos son los casos en los que deberemos aplicar el Patrón Change Data Capture, para aquellas ocasiones en los que necesitamos transformar y adaptar cierta información. Vamos a seguir con una serie de conceptos.

Conceptos Source Data y Derived Data

Una vez que vamos metiendo más componentes y piezas en nuestra arquitectura, como hemos visto en el punto anterior nuestra información tendrá varias versiones del mismo conjunto de datos, por lo que vamos a necesitar una fuente de verdad.

La fuente de verdad será aquella que prevalezca cuando existan discrepancias entre los datos de diferentes versiones. La versión que prevalece sobre las demás se llama Source Data.

Imagina que nuestra aplicación crea un Usuario y se guarda en BBDD, que es la fuente de verdad. Luego llega Elasticsearch para realizar indexaciones de usuarios y obtiene esos datos de la Base de Datos y realiza transformaciones. Estas transformaciones que se realizan para adaptar los datos a Elasticsearch se llama Derived Data. Si por algún problema perdiéramos los datos podríamos ir a nuestra fuente de verdad para recuperarlos.

Pero hay que tener en cuenta que los datos tienen que estar sincronizados para mantener la consistencia entre ambas Bases de Datos. Aquí es donde entra en juego el patrón Change Data Capture.

Patrón Change Data Capture

El Patrón Change Data Capture será aplicado cuando se den las circunstancias que hemos comentado más arriba. El Patrón Change Data Capture se va a encargar de capturar los cambios escritos en la base de datos que sea la fuente de verdad y extraerlos para replicarlos en los sistemas que los necesiten y transformarlos.

El proceso de Change Data Capture o CDC, es un proceso complicado en el que hay que tener la mayor sincronización y optimización posible de los sistemas para evitar problemas.

Podríamos decir que Change Data Capture es un método de ETL (Extract, Transform, Load), en donde la información es extraída, transformada y cargada en un repositorio destino.

Hay tres pasos claramente diferenciados en el patrón CDC, que son:

• Detectar el cambio
• Capturar el cambio
• Realizar la propagación del cambio.

Para realizar los pasos anteriores podemos aplicar diferentes aproximaciones, por ejemplo, lanzar un trigger de nuestra Base de Datos, tener un proceso scheduler o batch para obtener el último registro guardado, o mirar los logs de la Base de Datos para detectar los cambios. Podríamos decir que las dos aproximaciones más importantes son las siguientes, aunque podríamos tener alguna más:

• Query-based CDC
• Log-based CDC o basado en transaction log.

Ambos los veremos en los dos próximos puntos.

Cambios en Base de Datos basados en Query-based

En la aproximación basada en query-based se toman los cambios que han ocurrido en la Base de Datos, lo que provoca mayores recursos que por ejemplo la basada en logs (log-based).

La aproximación de Query-based en CDC, es fácil de conseguir ya que únicamente se requiere una conexión JDBC y no necesita muchos permisos o configuraciones adicionales.

Pero también implica un impacto en rendimiento hacia la Base de Datos, ya que vas a lanzar una query muy constante contra tu Base de Datos o puede ocurrir que entre las peticiones a la base de datos se hagan actualizaciones que no contemplemos.

Detención de cambios en BBDD basados en transaction logs en CDC

Las Bases de Datos tienen un sistema de transaction logs para guardar en BBDD las operaciones realizadas. Este funcionamiento puede ayudar a recuperar la Base de Datos de una inestabilidad o de una caída, además de proporcionar la información de las últimas transacciones.

Una vez la Base de Datos a escrito sus logs los sistemas de CDC de nuestra arquitectura observaran los logs que se han escrito y los propagarán al servicio final. Este servicio final lo que hará, será replicar los cambios y actualizará el estado. Durante este proceso desde el comienzo hasta que el dato llega al servicio final el sistema de CDC intervendrá de una manera activa.

Este sistema debe ser resiliente y tolerante al fallo ya que de otra manera nuestros datos podrían quedar desalineados. Por lo que algunas de las siguientes herramientas o principios son más que necesarios en nuestra arquitectura:

• Arquitectura basada en eventos o mensajes.
• Resiliente y tolerante a fallos.
• Los cambios en la fuente de verdad deben llegar en orden al sistema final.

Actualmente, una de las aproximaciones más utilizadas para aplicar CDC es el uso de eventos a través de Event Driven en el que se recoge el dato y se envía. De esta manera tendremos un sistema altamente escalable y resiliente.

Ventajas de usar eventos con Event Driven en CDC

• Permite estar desacoplado del sistema, siendo escalable si se necesita un mayor consumo o envío.
• Permite un procesamiento y actualización de mensajes en Tiempo Real.
• No impacta en el sistema ni tiene tanto impacto en el rendimiento de las aplicaciones como lanzar triggers o hacer uso de polling o scheduler para leer los cambios.

Sistemas para implementar CDC

Kafka Streams

Podemos hacer uso de Kafka Streams para implementar un sistema basado den CDC, para ello nos apoyamos en Kafka Connect.

Kafka Connect es un componente de código abierto de Apache Kafka que nos permite una integración de datos entre base de datos.

Debezium

Debezium es una plataforma distribuida de código abierto pensada y orientada al Change Data Capture (CDC). Esta solución de CDC de RedHat esta basada en logs transaccionales como aproximación para detectar los cambios en una Base de Datos.

Uno de los usos más comunes es utilizar Debezium junto con Kafka Connect para poder transmitir datos a kafka.

Conclusión

En esta introducción a Change Data Capture (CDC) hemos visto la necesidad de aplicar este patrón cuando nuestra arquitectura crece y aumenta el número de piezas. El aplicar Change Data Capture en nuestra arquitectura nos va a permitir tener un sistema más resistente, resiliente y escalable pudiendo mantener la responsabilidad única.