#azure synapse

Luego de crear nuestro Azure Synapse, tal como vimos en el post anterior, nos dirigimos al recurso y abrimos su interfaz para encontrarnos con lo siguiente:

Puede que la primera vez nos pida sincronizar un repositorio para trabajarlo. En dicho caso podemos proceder a sincronizar con un repo de Azure DevOps o GitHub. No mostraremos eso en este post, sino que nos centraremos en el menú.

El menú cuenta con dos secciones, la primera en 3 ítems para construir y la segunda para configurar y monitorear. Analicemos lo que encontraremos aquí:

Menú Data

Data es el espacio donde podemos revisar el contenido de nuestro Storage. Todo lo que llevemos a nuestro Data Lake será visible desde este apartado. Ahora bien, existen distintas secciones en el almacenamiento. Las veremos en las siguientes imágenes como Workspace y Linked. Estas pestañas nos ayudarán a separar la visión de datos en distintos modos.

Linked

Comúnmente contiene dos tipos de elementos que pueden resultarnos familiares a otros productos de data en Azure. Por un lado, tenemos Integration Datasets que será algo similar a los Linked Services de Data Factory. Orígenes de datos con credenciales que luego podemos utilizar para copiar datos de un lugar a otro. Por otro lado, está literalmente los containers del Lake. Si expandemos esta opción y clickeamos nos encontraremos con algo semejante al Azure Storage Explorer.

Workspace 

Contiene lo que me gustaría llamar el apartado “estructurado”. En esta sección contamos con dos tipos de componentes. Por un lado, el famoso LakeHouse y por otro, los Dedicated SQL Pools antes conocidos como Warehouse. Cuando trabajamos/operamos con archivos al Lake podemos crear Bases de datos y tablas para orientar nuestros archivos en un esquema más estructurado. Estas bases internas al lake tambien se las conoce como LakeHouse. El otro tipo de componente lo podemos hacer aparecer creando el recurso de SQL Dedicated Pool en el portal de azure dentro del recurso de Azure. Al hacerlo aparecerá la sección de Base de datos SQL. El funcionamiento del Pool o la base es la clásica tecnología de Warehouse que existió por mucho tiempo en Azure. Aquella con orientación a almacenamiento columnar y gran velocidad de respuesta a consultas analíticas.

Menú Develop

En este apartado aparece la magia analítica. Contiene tres elementos de los cuales dos nos ayudarán a consultar y/o construir las transformaciones y limpiezas complejas de datos.

SQL Scripts

Para generar SQL Scripts podemos simplemente explorar los archivos del lake y cuando veamos uno que nos gustaría consultar darle click derecho como muestra la imagen:

Esto nos genera el formato de código que SQL Serverless para consultar el Data Lake (Algo semejante a Athena de otro vendor). Nos encontraremos con un SQL Standard que nos permite realizar consultas sintiéndonos como si estuviéramos tratando con una base de datos tradicional con la diferencia que hay cierto código que aclarar contra los archivos. Les indique ese método para fácilmente revisarlo y familiarizarse. Creando uno en blanco tal vez no sabríamos llegar allí.

Todo lo que escribamos aquí puede ser guardado como un procedimiento o script que podemos llamar desde un pipeline.

Notebooks

Ya muchos estamos familiarizados con este apartado. Sobre todo, los data engineers gracias a la tecnología de Jupyter y DataBricks. Aquí nos encontraremos con exactamente eso. Tendremos notebooks disponibles para utilizar los lenguajes más comunes con librería Spark. Se puede crear o utilizar por celda PySpark, Scala, .NET Spark, Spark SQL y SparkR.

Al igual que DataBricks los notebooks necesitarán un motor para funcionar. En esa tecnología llamados Cluster y en Synapse llamados Apache Spark Pools.

Power Bi

De momento la opción más limitada. Nos permite sincronizar a un Power Bi Workspace V2. A partir de ese momento podemos explorar conjuntos de datos publicados en esa Área, visualizar los informes desde esa y editarlos. Estimo que más adelante darán más valor a esta sección que por ahora parece muy poco útil.

Menú Integrate

El último apartado es quien contiene los Pipelines de datos. Fanáticos de Azure Data Factory van a sentirse cómodos en esté menú puesto que podemos crear pipelines con sus elementos varios como el proceso estrella “Copy Data”. Está claro que no será idéntico a ADF. Tiene algunas semejanzas y unas pocas diferencias.

Menú Restante

Al final dispondremos de un aparatado de Monitoreo que nos permite visualizar todos los procesos antes mencionados que corren en Synapse. Manage será el dueño de las configuraciones. Aqui podemos visualizar delimitaciones de paquetes, repositorios, pools, etc.

¿Qué es Azure Synapse Analytics?

Microsoft lo define como un servicio de análisis empresarial que acelera el tiempo necesario para obtener información de los sistemas de almacenamientos de datos y de macrodatos. Azure Synapse reúne lo mejor de las tecnologías SQL que se usan en el almacenamiento de datos empresariales, las tecnologías de Spark que se utilizan para macrodatos, Data Explorer para análisis de serie temporal y de registro, Pipelines para la integración de datos y ETL/ELT, y la integración profunda con otros servicios de Azure, como Power BI, CosmosDB y AzureML.

Este servicio permitiría a los distintos roles de equipo de data trabajar en una misma plataforma. Podemos hacer ingesta, transformación y carga de datos. Tenemos notebooks y machine learning. Disponemos de sql serverless o dedicated sql pool (warehouse tradicional). Inclusive una exploración de datos basada en power bi.

NOTA: al crear el recurso el único costo que contiene es el de un storage account. A medida que demos uso posterior de los servicios de la plataforma (ejemplo correr pipelines) aparecen otros.

Para iniciarnos en este mundo maravilloso de un entorno de trabajo de synapse y analítica avanzada, vamos a buscar el recurso Azure Synapse Analytics.  Al momento de crearlo definimos la subscripción y grupo de recursos.

A modo de buena práctica podemos revisar las nomenclaturas sugeridas en este enlace:

El mismo cuenta que, para un Synapse Workspace, podemos usar el prefijo synw.

Toda área de trabajo de Synapse necesita un motor de almacenamiento. En este caso este espacio será controlado por una Storage Account también conocida como Data Lake Gen2. Antes de seguir vamos a crear un Lake. Este recurso tiene una particular opción que debemos prestar atención. El mismo synapse nos advierte de ella cuando nos posicionamos en el icono de información:

Mientras creamos el recurso podemos ponerle nombre, elegir la misma región y determinar la redundancia y plan. En este caso veamos el ejemplo con los menores costos.

Con los datos principales nos vamos a la prestaña advanced para activar el nombrado jerárquico que nos solicita synapse para que nuestro lago sea el file system en formato requerido.

Luego de crearlo necesitamos definir un file system dentro del lake. Esto podemos hacerlo desde el recurso que acabamos de crear o desde la interfaz que teníamos mientras creamos el área de trabajo.

Nombramos el área de trabajo y seguimos con la pestaña de seguridad para determinar el usuario y contraseña de acceso a los servicios de SQL Server que nos brinda la herramienta.

Finalmente podremos ir a nuestro recurso y abrir el espacio de trabajo para comenzar nuestros desarrollos. A partir de ese momento dispondremos las herramientas de Synapse Analytics para disfrutarlo.

Sería una buena práctica integrar nuestra área a un repositorio de DevOps o GitHub para persistir nuestros desarrollos, pero tengan cuidado en solo hacerlo si conocen o entienden de tecnología GIT puesto que si más de una persona desarrolla sobre synapse podrían aparecer conflictos en el repo.