Azure Purview, o como la cloud de Microsoft crece para ser líder en Data

Han pasado unas semanas desde que Microsoft anunciara el lanzamiento de su nueva herramienta para el Gobierno de Datos y aquí está, una breve guía resultado de un par de días de trabajo con Azure Purview.

En este caso, no me centraré en resumir la documentación, sino en presentar algunas de las pantallas con las que he trabajado. También incluiré algunas tips de cara a evitar pérdidas de tiempo en ejecución de los scan de las fuentes de datos, con alguna me estuve «peleando» algún ratito 😉

Como en cualquier despliegue en Azure, todo comienza con la creación de nuestro grupo de recursos.

Y el siguiente paso es crear nuestro recurso Azure Purview.

Configurando el recurso con las características propias de ubicación

y terminamos seleccionando el tamaño de la plataforma. En nuestro caso, nos sirve con 4 unidades de capacidad.

Validamos y creamos

Una vez completado, accedemos y vemos todas las opciones disponibles en la parte izquierda. En el centro tenemos el acceso al Open Purview Studio, que será nuestro principal entorno de trabajo gráfico.

IMPORTANTE:
Siempre debes asignar el rol de lectura a tu cuenta de Azure Purview, en todas las fuentes de datos.

Para disponer de la posibilidad de visualizar el data lineage de tus fuentes, es obligatorio registrar tu cuenta de Azure Data Factory. En mi caso, también utilicé pipelines creados en Azure Synapse, pero éstos no aparecen aún en esta funcionalidad. Uno de los inconvenientes de estar en preview.

En el caso de la vinculación de fuentes de datos como el SQL Pool de Azure Synapse, como en Azure SQL Database, se han de otorgar permisos a la cuenta de Azure Purview mediante un script de TSQL. Este paso es bastante más sencillo en el primero y algo más complicado en el segundo caso.

En el primer caso, sirve con acceder a la base de datos sobre la que se quiere trabajar desde el Azure Synapse Workspace y ejecutar el script.

Mientras que en el segundo caso, primero debemos crear un usuario en nuestro Azure Active Directory y otorgarle permisos de owner para el Servidor SQL donde esté alojada la base de datos.

Añadimos los permisos

El siguiente paso es acceder a la base de datos mediante SSMS utilizando, Active Directory – Password como método de autenticación, además del usuario recién creado y su contraseña.

NOTA: Es obligatorio restablecer la contraseña y acceder con este usuario al portal de azure para cambiarla por la «buena».

Ahora ya podemos ejecutar el script TSQL para asignar las credenciales necesarias a nuestra cuenta de Azure Purview.

Terminadas estas aclaraciones, podremos acceder a nuestro entorno de Azure Purview. Esta imagen representa lo que nos encontraremos al entrar en él. En el lateral izquierdo están todas las secciones de la herramienta y en el centro tenemos varias «cajitas». Las más interesantes son la de Registro de Fuentes y Explorar Activos. Empecemos registrando una fuente.

Para ello, pulsamos sobre fuentes y elegimos el tipo entre las múltiples opciones que nos ofrecen. En este primer ejemplo, seleccionamos una cuenta de Azure Blob Storage.

Aquí nos encontramos con un paso intermedio donde lo que debemos hacer es asignar o crear un padre con el que clasificar las distintas fuentes de datos. En nuestro caso, como estas fuentes de datos provenían del workshop de Microsoft sobre Azure Synapse, lo tuve fácil con el nombre 😉

Finalmente lo registramos completando el conjunto de datos requeridos.

Y ya sólo nos queda observar el resultado en nuestra pantalla.

Hacemos lo mismo con el Pool de SQL para Azure Synapse

A partir de este momento, ya podrías realizar los scan de tus fuentes registradas, sin embargo, como no aparece el lineage de la fuente por no permitir la integración de los pipelines creados en Azure Synapse, voy a crear un nuevo padre incluyendo una Azure SQL Database y un Azure Data Lake Gen2.

NOTA: Creamos un sencillo pipeline de Azure data Factory que ingesta los ficheros json de nuestro Data Lake en una tabla de la base de datos. Ejecutamos

De vuelta a nuestro entorno de Azure Purview Studio, realizamos el scan sobre la base de datos y observamos su resultado. En este caso, la tabla sólo incluye información de productos, con lo que no hay campos sensibles, como en el caso de la tabla CustomerInfo del Pool de SQL de Azure Synapse. Sin embargo, esta parte es interesante para ver cómo la herramienta dibuja el data lineage.

Para observar el data lineage de la tabla, debemos pulsar sobre Home y acto seguido sobre Browse Assets y recorrer las fuentes hasta dar con la nuestra. En la pestaña Lineage obtendremos un diagrama de todos los pasos que se han completado para crear nuestra tabla Product.

NOTA: Volveremos a esta pantalla posteriormente, con la tabla CustomerInfo de Azure Synapse.

Como he comentado justo arriba, ahora veremos el resultado de un scan sobre una tabla con «posibles» datos sensibles. Es el caso de la tabla CustomerInfo del Pool SQL de Azure Synapse.

Como está en Azure Synapse, vamos a volver a él y comenzamos el scan de dicha fuente. Para ello, lo primer es pulsar sobre el icono de la diana y completar los datos del desplegable. Son nombre, la base de datos y el tipo de credencial con el que conectar. En nuestro caso, ya habíamos habilitado las credenciales sobre Azure Synapse para nuestra cuenta purviewaa.

Seleccionamos el conjunto de tablas sobre las que queremos realizar el escáner y procedemos.

Esperamos y en unos minutos podremos ver el resultado.

Todo correcto. Observamos que se han clasificado varios activos. Si bien a nosotros ahora mismo, lo que nos interesa es la tabla CustomerInfo. Por lo que volvemos a pinchar sobre Home y Browse Assets. Seleccionamos la tabla en cuestión y revisamos las pestañas, empezamos con la Overview. Aquí podemos ver un resumen general de la fuente de datos, como última actualización, su jerarquía y otro campos que pueden ser completados por el usuario.

En el caso del Schema, observamos los distintos campos de la tabla junto con su clasificación, glosario, tipo de dato y descripción. Estos campos son editables, si bien el de clasificación y tipo de dato, se obtienen durante el proceso de escáner, el resto dependen del usuario.

En nuestro escáner, sólo se clasificaron los campos de Email y Phone, por lo que procedimos a editar la fuente y completar el resto de campos.

También creamos un ejemplo de glosario, para incluirlo dentro de nuestro ejemplo. Para ello previamente pulsamos sobre la sección Glosary en el lateral de la izquierda y compusimos uno nuevo. De este modo, tras la edición, el resultado fue el visto previamente.

En CustomerInfo, al tratarse de una tabla resultado de un pipeline de Azure Synapse, no tenemos contenido en la tabla de Lineage (esto deberá ser integrado por Microsoft en sucesivas mejoras), por lo que pasamos a la pestaña de Contacts. En ella puedes incluir tantos expertos como propietarios del dataset. Esto es muy importante en caso de que alguien de la organización deba ponerse en contacto con ellos.

Por último, sólo quedaría la pestaña de Related, donde podemos ver con qué otras fuentes está relacionado.

CONCLUSIÓN
Sabiendo que la herramienta está en preview y apuntado que he tenido alguna dificultad a la hora de configurar los escaneos por temas de credenciales, el resto es sin duda muy interesante.

Este tipo de recurso, en básico de cara a poder implementar un correcto Gobierno del Dato, lo que se traduce en un primer e importante paso para acercar a Microsoft a otras distribuciones como el CDP de Cloudera. No quiero dejar de mencionar que, Azure Purview se puede integrar con Apache Atlas, si bien no lo he explorado en esta guía. Lo que incrementa las capacidades del producto.

Por último mencionar que, la fácil integración de los productos de Azure Data como Data Factory o Synapse con Git para su versionado e integración y despliegue continuo a través de Azure DevOps, como el desarrollo del resto de la infra con las plantillas ARM y ahora Azure Purview, sin duda sitúan a la cloud de Microsoft como un referente en DataOps, Seguridad y Gobierno del Dato.