El motor SQL siempre ha estado presente en el componente central de la arquitectura de Datos de Microsoft, inicialmente como Azure SQL Data Warehouse y ahora bajo el nombre de Azure Synapse Workspace. Pero en este tiempo han existido cambios sobre él hasta convertirlo en lo que hoy es.
Veamos qué presenta actualmente el Pool de SQL para ayudarnos a implementar la arquitectura de Procesamiento Masivo en Paralelo (MPP) y como ha llegado a separar la capa de almacenamiento y dotar de una tremenda elasticidad a la capa de cómputo.
Si bajamos al nivel de componentes, observamos que SQL Dedicated Pool está compuesto por cuatro elementos que reciben de nombre:
- Distributions
- Control Node
- Compute Nodes
- Data Movement Services (DMS)
En el caso de Distribuciones, SQL Dedicated Pool dispone de un número fijo de 60 unidades básicas de almacenamiento, lo que significa que los datos son divididos y almacenados entre dichas distribuciones. Algo que cobra especial relevancia cuando queremos ejecutar consultas eficientes. Para ello, disponemos de la capacidad de utilizar tres tipos de distribución cuando creamos nuestras tablas.
El Control Node es el SQL Server Endpoint, lo que hace es almacenar la metadata de los almacenamientos, con lo que al recibir la query desde el usuario coordina la ejecución a través de los Compute Nodes que son los que finalmente realizan la consulta. Es la unidad de computo de Azure Synapse y en la actualidad podemos llegar a configurar nuestro componente con un máximo de 60 Compute Nodes. Lo que significa que los Distributions se dividen entre el número asignado de nodos de computación.
Finalmente los DMS actúan cuando existen joins, group by en nuestras queries. Lo que hacen es coordinar el movimiento de datos entre los nodos de computación para componer el resultado.
Otro concepto a tener presente es el de Data Warehouse Unit (DWU) que viene a ser el conjunto de CPU, Memoria e IO es decir, el poder computacional de nuestro SQL Dedicated Pool. Este valor, puede incrementarse o reducirse en función de las necesidades de la organización.
Veamos como configurar nuestro SQL Dedicated Pool. Para ello lo primero es haber configurado previamente un Azure Synapse Workspace, desde él, seleccionamos del área de Analytics pools el de SQL.
Una vez allí, vemos que actualmente disponemos (por defecto) de un SQL Serverless. Este únicamente incurre en coste, en caso de que se utilice, sino no incrementa la cuenta final, algo distinto sucede con el SQL Dedicated Pool Por eso es tan importante «apagarlo» una vez terminado el trabajo.
Al pinchar sobre New accedemos a una pantalla donde configuramos el valor de DWU con los que deseamos trabajar.
Si lo llevamos al extremo máximo de 30.000 DWU, además de soportar un coste de casi 400 euros la hora, dispondríamos de 60 nodos de computación, es decir uno por cada distribución. Algo que sin duda otorga una capacidades de cómputo tremendas. Pero para nosotros, con 100 DWU será suficiente. Una vez configurado, podremos comenzar a hacer uso de sus capacidades.
Para conectarse, sólo tienes que utilizar el Dedicated SQL Endpoint, el usuario y el Password con el que configuraste tu Azure Synapse Workspace.
Y ya estarás en disposición de comenzar tu aventura creando tablas, virtualizando recursos a través de Polybase, componer tus Stored Procedures, vistas,… Las características no soportadas son la creación de Triggers y las consultas entre distintas bases de datos. también hay que revisar la parte que afecta a constraints, identity columns y relaciones pues funcionan de manera distinta al tradicional SQL Server. Algún peaje se debe pagar 😉
En la próxima entrega sobre Azure Synapse configuraré tablas externas mediante Polybase y hablaré sobre Round Robin, Hash y Reference, que son tres aspectos a tener muy claro si queremos que nuestras queries sean eficientes.
Foto de portada gracias a Martin Damboldt en Pexels
Alb3rto Alonso 