Azure SQL Database
Change Data Capture o CDC es una capacidad que permite a los sistema de bases de datos (SQL y NoSQL) como Azure SQL Database capturar aquellos registros que han sufrido modificaciones (lo que son inserciones, borrados y actualizaciones). Dicha cualidad se apoya en elementos como la metadata y tablas de control de cambios, para de este modo, ofrecer de un modo sencillo (y muy eficaz) aquella información que ha cambiado a consumidores que extraen exclusivamente esos registros.
Como entenderás, esto ayuda enormemente cuando hablamos de construir soluciones de Analítica Avanzada, puesto que simplifica enormemente los pipelines de extracción, eliminando la necesidad de controlar aquellas columnas con las que se configuran extracciones Delta, por ejemplo. Del mismo modo, se reduce el movimiento de datos, lo que a su vez redunda en un menor coste en las ejecuciones.
Pues como recientemente lanzaron en preview el componente de Azure Data Factory para ejecutar procesos de tipo CDC, creo que puede resultar interesante describir un E2E desde la creación de la Tabla en Azure SQL Database y su posterior uso en Azure Data Factory CDC. Empecemos!
Lo primero es comprobar si en nuestra recién creada base de datos Azure SQL tiene habilitado el servicio CDC. Para ello sólo tenemos que ejecutar el comando que vemos en la imagen de abajo.
SELECT name, is_cdc_enabled FROM sys.databases
Como el resultado muestra el valor 0, significa que aún no está habilitada dicha funcionalidad. Seguimos!
Ahora ejecutamos el siguiente código:
EXEC sys.sp_cdc_enable_dby repetimos la comprobación para verificar que está habilitado el CDC.
En el siguiente paso, es crear una Tabla.
CREATE TABLE dbo.People (
ID INT PRIMARY KEY
, FirstName NVARCHAR(100)
, LastName NVARCHAR(100)
, BirthDate DATE
, UpdatedOn DATE
, CreatedOn DATE
)Una vez creada, habilitamos CDC en ella ejecutando el siguiente código
USE [owdataex01bd-dev]
GO
EXEC sys.sp_cdc_enable_table
@source_schema = N'dbo',
@source_name = N'People',
@role_name = NULL,
@support_net_changes = 1
GOY finalmente, realizamos la inserción de un nuevo registro dummy
Continuamos realizando inserciones y modificaciones sobre los registros para finalmente consultar la tabla de cambios que soporta el CDC ejecutando:
SELECT * FROM cdc.People_CT
Como puedes observar en la imagen de arriba, existe un campo llamado __$operation con distintos valores. Así pues tenemos que el valor 2 indica una nueva inserción, mientras que el valor 3 informa de que sobre ese registro se ha producido una actualización y graba el valor antiguo, mientras que la operación con valor igual a 4 presenta el registro actualizado. Es decir, esta table de control de cambios nos permite hacer un tracking completo de nuestra tabla origen.
IMPORTANTE: recuerda que CDC no está soportado en los Tier de Azure SQL Database Free, Basic o Standard (S0, S1, S2). Para este ejemplo utilicé un Tier Premium con un coste estimado mensual de alrededor de 400 euros, ¡creo recordar!
Azure Data Factory
Una vez hemos completado la creación de los recursos para completar el pipeline CDC de Azure Data Factory, saltamos al Workspace de ADF y comenzamos a crear uno. Recordar que se trata de un servicio en preview, con lo que no es recomendable su uso en procesos de producción 😉
El proceso de creación es relativamente sencillo, pues tan sólo tienes que seleccionar los orígenes de los registros. En nuestro caso es sencillo puesto que tan sólo hemos creado una Tabla llamada ‘dbo.People’.
Y definir el destino, así como el formato con el que lo quieres persistir. En nuestro ejemplo fue alojar los registros extraídos en formato de fichero Json en un Blob Storage. Por supuesto, existen otras muchas alternativas, como puede ser .parquet, .csv, .delta,… así como sistemas de almacenamiento.
El siguiente paso es completar el mapping entre campos
Para finalmente, elegir la ventana a emplear. En este ejemplo se trata de Microbatch de 15 minutos. Esto significa que nuestro pipeline se ejecutará en ventanas de 15 minutos donde extraerá tan sólo los registros que hayan sido modificados durante dicho periodo de tiempo.
Ejecutamos el proceso y sólo queda esperar a ver cómo se comporta.
Tras un periodo realizando inserciones y actualizaciones en nuestra base de datos, podemos comprobar que el pipeline se ha ido ejecutando correctamente y si vamos a nuestro almacenamiento, podremos comprobar que los ficheros Json contienen los registros afectados en cada una de las ventanas. Para ejemplo, el de la última.
IMPORTANTE: Ten presente que en caso de múltiples actualizaciones de un mismo registro dentro de la misma ventana, el fichero Json tan sólo mostrará la versión inicial del registro al comenzar dicha ventana y la última versión del registro al finalizar la ventana y ejecutarse la extracción. Si necesitas chequear el comportamiento de las modificaciones y demás, estará disponible en la tabla de control de cambios que soporta CDC.
CONCLUSIÓN
Tal y como mencioné al comienzo del artículo, esta combinación de capacidades permite simplificar enormemente el proceso de extracción de la información desde los sistemas transaccionales. Algo que redunda en eficiencia y reducción de costes en tus soluciones de Analítica Avanzada.
Hace tiempo comencé con el análisis de la arquitectura del caso de éxito de Zendesk y ellos utilizaban CDC en más de 700 MySQL para manejar los registros modificados y así gestionar eficientemente los procesos de extracción. Lo que viene a confirmar que a día de hoy nos estamos moviendo hacia paradigmas de integración gestionados. En este caso mediante la implementación de Change Data Captura, mientras que en otros vamos hacia gestión de eventos, como presenté hace unas semanas en esta entrada, aquí.
Si te gusta este tipo de contenido suscríbete al blog, síguenos en nuestro canal de YouTube o mantente informado de nuestros eventos en el canal de Meetup
Foto de portada gracias a zhang kaiyv: https://www.pexels.com/es-es/foto/fotografia-a-intervalos-de-un-edificio-de-hormigon-marron-842654/
Alb3rto Alonso 