Exportar 82 millones de filas en menos de 10 minutos

Exportar 82 millones de filas en menos de 10 minutos

¿Quién no se ha encontrado con la difícil tarea de exportar el contenido de una tabla de una base de datos de SQL Server que ha crecido descomunalmente, e inmediatamente piensa en las horas y horas que se va a tomar este proceso?

En la mayoría de aplicaciones existen tablas en su modelo de datos que almacenan información histórica por años y que nadie se percata de su existencia, hasta que ya es muy tarde de notar; sólo hasta que llegan a ocupar el 70% del espacio de la Base de Datos o incluso más. Es en ese entonces cuándo se suele pensar en dónde mover el histórico con tal de poder tener un respaldo en caso poder suplir algún requerimiento de Auditoría a futuro, para luego poder proceder a eliminar y recuperar espacio libre en la Base de Datos.

En esta época del Big Data, de aplicaciones y datos distribuidos, clusters virtuales de procesamiento, por tan sólo nombrar algunos, es muy fácil acceder herramientas que nos facilitan labores de este estilo, que en cuestión de un par de horas podemos configurar, poner en ejecución, y en menos de 10 minutos finalizar exitosamente con el movimiento. Las herramientas seleccionadas para esta labor fueron:

  • Azure Storage Account: Sistema de almacenamiento distribuido. Este va a ser el destino de la información organizada en archivos tipo Blob.
  • Azure Data Factory: Servicio de Flujos de Transformación de Datos (ETL) basado en Clusters Spark. Con tan sólo tres componentes vamos a crear un Pipeline para extraer y enviar al destino de forma eficiente.
  • Azure SQL Managed Instance: Servicio manejado por Azure del Motor SQL Server. Es nuestro origen de datos.

El principio técnico que va permitir mover los millones de filas en poco tiempo es el Paralelismo. De principio a fin vamos a poder explorar la ejecución simultanea de modo que usamos capacidad de computo al máximo y reducimos el tiempo de la actividad. Empezando con la Base de Datos, vamos a configurar que se establezcan varias sesiones de Lectura sobre los datos; una optimización adicional sería tener la tabla Origen previamente Particionada con lo que se gana en lecturas de I/O que nos se bloqueen entre sí. Por el lado del Data Factory, Spark nos garantiza escalar el computo y distribuir el flujo de datos en particiones. Finalmente, el contenedor de Blobs reside en una infraestructura distribuida que nos asegura el acceso a datos en niveles de servicio con latencia menor a 1 segundo.

El componente clave en Data Factory se llama Copy Activity. Es la tarea más básica, pero a su vez, la más potente. Con ella podemos conectarnos desde y hacia múltiples tipos de Conectores y Tipos de datos [1].

Copy Activity Data Factoty. Advance Partition Options.

Luego de configurar el Dataset origen hacia la Azure SQL Managed Instance, y la Base de Datos a extraerle la información, debemos establecer la Opción de Particionamiento Dinámico (Partition option: Dynamic range [2]). Con esta opción, se nos habilitan tres cuadros de texto en donde debemos especificar la columna de la tabla sobre la cual deseamos realizar el particionamiento, así como el límite Mínimo y el límite Máximo. Por ejemplo, podemos establecer una columna con el Mes de creación de los datos y así dinámicamente lograr que el Pipeline ejecute en rangos de: 0 al 1er mes, del 1er al 2do mes, del 3re mes al siguiente, y así sucesivamente. Adicionalmente vamos a querer configurar en el Copy Activity un valor de nivel de paralelismo [3] igual al número de vCores con la que dispone el motor SQL: Por ejemplo, en la siguiente imagen se visualizan cuatro sesiones de Bases de Datos extrayendo datos en paralelo.

Nivel de paralelismo del Copy Activity

Sólo con estas configuraciones anteriores se logró que al ejecutar el Pipeline de Data Factory, se volcara el contenido de datos en cuatro archivos simultáneamente hacia el contenedor de Blobs, tal como se aprecia en la siguiente imagen.

Resumen de ejecución de un Copy Activity con paralelismo dinámico

Lo único que falta es asegurarnos que nuestros datos estén óptimamente organizados en la Cuenta de Almacenamiento. La estrategia más indicada puede ser agrupar los archivos exportados por Año de la fecha de creación de los registros en la tabla, y en cada carpeta de por año, volcar los 12 archivos por meses correspondientes.

La manera más fácil para lograr la separación por años, es ejecutar el Copy Activity dentro de un ciclo ForEach de Data Factory. Adicional, sólo debemos crear una variable en el Pipeline en donde establecemos el valor de años a exportar y asignar este conjunto de valores como el atributo por el cuál debe iterarse.

No hay texto alternativo para esta imagen

Y esto es todo, una vez puesto en ejecución, el Pipeline extraerá los registros históricos de la tabla realizando conexiones simultaneas, y almacenará en carpetas y archivos en la Cuenta de Almacenamiento por año/mes; y lo mejor de todo, en cuestión de tan sólo unos minutos, gracias a la ejecución en paralelo que se le definió.

Carpetas y archivos en la cuenta de almacenamiento de Blobs

Nos leemos en una próxima oportunidad.

Halber Albarracin

Backend Developer | .NET Core & Framework Specialist | AWS Lambda & Cloud Solutions | AI Integration Enthusiast

4 años

La primera vez que leí sobre esto me acordé de usted y sus ETL's jeje

Inicia sesión para ver o añadir un comentario.

Más artículos de Gerardo Arévalo Tamayo

Otros usuarios han visto

Ver temas