Replicando el Data Pipeline de Zendesk desde AWS a Azure, parte I

Hace unos días leí el caso de éxito de arquitectura de datos de la empresa Zendesk sobre AWS y decidí hacer un ejercicio de revisión y adaptación del mismo en Azure. En esta primera entrada, el scope es el relativo a la para del Data Lake Pipeline marcado en rojo.

Lo primero es crear los recursos que necesitaremos para replicar esta arquitectura dentro del grupo de recursos rg-azure-zendesk-dev , que entre otros son:

• Azure SQL Database
• Azure Data Factory
• Azure Databricks
• Azure Data Lake Gen2

Quedaría algo como esto:

Una vez completado el despliegue de componentes, continúo con la configuración de la tecnología Change Tracking y la creación de las tablas en Azure SQL Database, para ello sigo el ejemplo del tutorial de Microsoft que está en el conjunto de links de interés al final del artículo.

Vamos a habilitar el Change Tracking y creamos la tabla data_source_table

ALTER DATABASE zendesk
SET CHANGE_TRACKING = ON  
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)

create table data_source_table
(
    PersonID int NOT NULL,
    Name varchar(255),
    Age int
    PRIMARY KEY (PersonID)
);

Para habilitar el Change Tracking sobre ella e insertar los primeros registros

ALTER TABLE data_source_table
ENABLE CHANGE_TRACKING  
WITH (TRACK_COLUMNS_UPDATED = ON)

INSERT INTO data_source_table
    (PersonID, Name, Age)
VALUES
    (1, 'aaaa', 21),
    (2, 'bbbb', 24),
    (3, 'cccc', 20),
    (4, 'dddd', 26),
    (5, 'eeee', 22);

Para acto seguido crear la tabla table_store_ChangeTracking_version e incluir el primer registro para el recurso data_source_table

create table table_store_ChangeTracking_version
(
    TableName varchar(255),
    SYS_CHANGE_VERSION BIGINT,
);

DECLARE @ChangeTracking_version BIGINT
SET @ChangeTracking_version = CHANGE_TRACKING_CURRENT_VERSION();  

INSERT INTO table_store_ChangeTracking_version
VALUES ('data_source_table', @ChangeTracking_version)

Consideraciones iniciales
El siguiente paso en el ejemplo de Microsoft, es cargar una primera versión del contenido de la tabla data_source_table para posteriormente ejecutar un pipeline de copia incremental. Pero vayamos paso a paso, pues en nuestra aproximación, sustituiremos EMR con Azure Databricks, lo que obliga a modificar el tutorial de Microsoft que utiliza Stored Procedures T-SQL para tal fin. En algún lado tenía que estar la parte diferencial de este artículo 😉

Por lo que para ejecutar el siguiente paso deberemos comenzar a vincular nuestro Azure Databricks con la Azure SQL Database y nuestro Azure Data Lake Gen2, además en el caso de éxito de Zendesk, se utilizaba Apache Hudi como formato de fichero ACID, algo que replicaremos, pero que haremos extensible al formato Delta Lake (que también cumple con la Atomicidad, Consistencia, Aislamiento y Durabilidad), por aquello de seguir añadiendo valor al artículo. Por cierto, antes de entrar en harina, voy a emplear las siguientes líneas para hablar de las características principales de cada formato que serán ampliadas cuando veamos cada uno de los ejemplos.

¿Qué es ACID?
Si bien antes de comenzar haré una breve introducción acerca de lo que significa ACID en el mundo de las bases de datos y más concretamente en el de las relacionales. ACID proviene de las siglas en inglés de Atomicidad, Consistencia, Aislamiento y Durabilidad. Veamos cada una por separado:

• Atomicidad: es la característica que nos permite asegurar que la operación se ha completado ya sea con éxito o no. Es decir, no se ha quedado en el limbo y ha finalizado.
• Consistencia: es la característica por la cual sólo se ejecutarán aquellas operaciones que cumplan con las reglas de integridad de la base de datos.
• Aislamiento: es la capacidad de separar las operaciones, evitando que una afecte a otra.
• Durabilidad: es la capacidad que nos permite asegurar la persistencia del dato.

Saltemos, tras esta explicación, al mini análisis de cada uno de los formatos de datos:

Apache Hudi, es formato Open Source que propone Uber y que se utiliza para simplificar el procesamiento incremental de datos basado en Change Data Capture (CDC), así como los flujos de datos en streaming. Este formato permite gestionar de forma eficiente los requisitos empresariales como el ciclo de vida de los datos, gestionando los casos de uso de privacidad que requieren actualizaciones y borrados a nivel de registro, por ejemplo para lograr el cumplimiento de normativa GDPR.

Delta Lake, es el formato Open Source que propone Databricks para optimizar los Data Lake a través de incrementar la fiabilidad, seguridad y rendimiento, tanto para procesos batch como streaming.

IMPORTANTE:
En este ejercicio no utilizaré las buenas prácticas DataOps como vincular a repositorio de código, trabajar con Visual Studio,… por tartar de simplificar el ya por si complicado desarrollo.

Links de interés:
Microsoft CDC (Change Data capture) para copia incremental mediante la información de control de cambios, aquí.
Caso de éxito de Zendesk, aquí.
Amazon EMR y Hudi, aquí.
Quién es quién entre AWS y Azure, aquí.
Databricks Delta Lake, aquí.
Comparando Hudi vs Delta Lake, aquí.

Foto de portada gracias a Taryn Elliott en Pexels