Inicio
Introducción
Azure Table Storage es un servicio de almacenamiento en la nube diseñado para manejar grandes cantidades de datos estructurados no relacionales, también conocidos como datos NoSQL estructurados o semiestructurados.Ofrece flexibilidad en el esquema de datos, permitiendo el almacenamiento de petabytes de datos semiestructurados con alta disponibilidad y redundancia geográfica.
Este servicio es ideal para crear aplicaciones que requieren esquemas de datos flexibles, como datos de usuario de aplicaciones web, libretas de direcciones, metadatos de dispositivos.Además, Table Storage proporciona un sólido modelo de coherencia, es escalable de forma masiva.
Azure Table Storage se destaca por su capacidad de adaptarse fácilmente a medida que evolucionan las necesidades de la aplicación,ya que no requiere un esquema fijo. En resumen, es una opción eficiente y rentable para almacenar grandes conjuntos de datos estructurados no relacionales y realizar consultas sobre ellos.
En este post voy a compartir un tutorial para utilizar Azure Tables durante un proceso de ETL. Se van a almacenar metadatos de tablas que se encuentran alojadas en una base de datos OnPremise y una tabla que se va a modificar una vez terminado el ETL con un checkPoint de ultima actualizacion de datos.
Una vez guardados estos datos vamos a crear un linked service para poder leer la tabla desde Azure Data Factory y y asi comenzar con el ETL.
Proceso
1 - Identificar los metadatos necesarios para realizar el ETL de una tabla.
Ejemplo: Si tenemos que migrar al Azure DataLake 2 tablas que se encuentran en una base de datos OnPremise llamadas cliente y ventas y ambas se encuentran en dos Schemas distintos, podemos utilizar la siguiente metodología de armado de Azure Table:
- Para este ejemplo vamos a usar como PartitionKey el nombre de la tabla y como RowKey el Schema. En columnas especificamos solo las columnas a migrar.
* Se recomienda siempre utilizar como PartitionKey una columna con baja cardinalidad respecto a la RowKey. Hay que tener en cuenta este punto para lograr la mayor eficiencia posible en lecturas y escrituras. Si se van a utilizar para un proceso mas grande y escalable es recomendable utilizar los Schema en PartitionKey y el nombre de la tabla en RowKey
[
{
"PartitionKey" : "cliente",
"RowKey" : "schema_a",
"Columnas" : "id, nombre, direccion"
},
{
"PartitionKey" : "ventas",
"RowKey" : "schema_b",
"Columnas" : "id, total, cantidad"
}
]2 - Crear las Azure Tables
- Creamos la Azure Table de metadatos:
Quedando la tabla final de la siguiente manera:
- Luego creamos la Azure Table para el checkPoint de las tablas:
3 - Creamos Datasets en Azure Data Factory
Necesitamos crear dos datasets, uno para la Azure Table con metadatos y otro para la Azure Table con los checkpoints. Ambas Azure Tables se van a linkear con el mismo servicio. Un dataset en Data Factory es una vista de datos con nombre que simplemente señala o hace referencia a los datos que vamos a utilizar en las actividades como entradas y salidas. Estos datasets identifican datos dentro de diferentes almacenes de datos, como tablas, archivos, carpetas y documentos.
Los únicos datos que necesitamos son:
- Linked Service (Es un recurso que define la conexión entre Azure Data Factory y una fuente de datos o un destino)
- Nombre de la Azure Table
Para crear el Linked Service:
Desde manage en Data Factory podemos crear un linked service de azure table storage para poder realizar actividades desde Data Factory. (Previamente hay que tener creado el recurso Storage Account)
4 - Pipeline
El siguiente paso es crear un pipeline desde Data Factory para realizar el ETL y sobreescribir la Azure Table luego de que la actividad de copia de datos desde las bases OnPremise al DataLake termine de forma exitosa.
El pipeline:
Incluye las siguientes actividades y variables:
Actividades:
- Lookup -> Esta actividad levanta todos los datos de la Azure Table con metadatos.
- ForEach -> Itera por cada diccionario (Una Row en la Azure Table).
Dentro del ForEach el pipeline se ve da la siguiente manera:
SetVariable -> Se setean las tres variables de la Azure Table de metadatos, el nombre de la tabla, el schema y las columnas a migrar. Luego se genera el nuevo checkPoint con el siguiente formato: yyyy-mm-dd hh:mm:ss. El checkPoint se genera antes de la actividad de copia de datos para que no haya perdida de datos desde el ultimo checkPoint.
CopyData -> Esta actividad utiliza la siguiente Query para levantar los datos desde la base OnPremise y copiarlos al DataLake.
Dentro de esta actividad hay que setear un Linked Service con la base OnPremise. Para ello se requiere la instalación del Integration Runtime en el servidor OnPremise. El destino de los datos va a ser la nube de Azure. Puede ser en un Blob Storage, Data Lake Storage o una base de datos relacional en Azure. Para ello también se requiere otro linked service.
- CopyData: Edit Azure Table -> Esta actividad final levanta los datos de la Azure Table con los checkPoint y sobreescribe reemplazando el valor anterior del checkPoint de la tabla que se esta iterando por el nuevo checkPoint ni bien termine de forma exitosa la actividad de copia de datos.
El source lo configuramos de la siguiente manera:
Utilizamos la query para solo levantar los datos de la tabla que se esta iterando y seteamos una nueva columna que contenga el valor del nuevo checkPoint.
En el destino usamos el mismo dataset y seteamos las siguientes variables:
En el mapeo final reemplazamos la columna source CheckPoint por la nueva columna con los datos del nuevo checkPoint que se completo en el paso anterior.
Una vez terminado de iterar por las dos filas de la Azure Table el proceso termina con los nuevos checkPoints completados:
Conclusion
El uso de Azure Table Storage se presenta como una solución eficiente y rentable para el almacenamiento y gestión de grandes conjuntos de datos estructurados no relacionales. Su flexibilidad en el esquema de datos, combinada con alta disponibilidad y redundancia geográfica,lo posiciona como una opción sólida para diversas aplicaciones, especialmente aquellas que requieren esquemas de datos flexibles.
En el tutorial proporcionado, se detallaron los pasos para utilizar Azure Tables en un proceso de ETL (Extract, Transform, Load). Se destacó la importancia de identificar metadatos necesarios para el ETL de tablas, y se proporcionó un ejemplo de metodología para el armado de Azure Table. Además, se describió la creación de Azure Tables para metadatos y checkpoints, y se demostró la integración con Azure Data Factory mediante la creación de datasets y linked services.
El pipeline diseñado para el ETL incluyó actividades como la consulta de metadatos, la iteración por cada tabla a migrar, la generación de nuevos checkpoints, y finalmente, la copia de datos desde bases OnPremise al DataLake, seguida por la actualización de los checkpoints en la Azure Table correspondiente.
Este enfoque proporciona una manera estructurada y eficiente de gestionar el flujo de datos durante el proceso de ETL, asegurando la integridad y consistencia de los datos, así como la actualización adecuada de los checkpoints. En resumen, la combinación de Azure Table Storage y Azure Data Factory ofrece una solución completa y escalable para implementar procesos de ETL en entornos de nube.