Empezar este post es fácil, porque muchos nos podemos preguntar:

¿Qué es un Data Lake?

Pescando en un Data Lake. Cortesía de cazapelusas.

Un Data Lake no es un producto de Azure, es un concepto que hace referencia a un lugar donde se guardan datos, sin importar si son estructurados o no. Su único propósito es guardar los datos sin procesar para que estén listos para ser consumidos por otros sistemas. Es como un lago que recibe y almacena el agua de sus afluentes, solo que con datos en vez de agua.

En Azure el Data Lake es un blob que guarda los datos. Y estos datos pueden venir de Microsoft Dynamics 365 for Finance o Supply Chain Management (voy a acabar loco con los cambios de nombre de Axapta 7) o de otros orígenes.

Actualmente, y desde el PU23, #MSDyn365FO (#MSDyn365F ? o #MSDyn365SCM ?) soporta oficialmente la exportación del Entity Store a un Azure Data Lake storage Gen1, pero la compatibilidad con el Data Lake Storage Gen2 está en preview privada con los Data Feeds, que nos permitirán exportar entidades y tablas (SÍ!) en casi tiempo real. Si queréis saber más echadle un ojo al grupo Data Management, Data Entities, OData and Integrations de Yammer del Insider Program (y si no estáis apuntados, deberíais).

Comparación vs. BYOD

Lo primero de lo que nos vamos a dar cuenta es el precio. El almacenamiento es más barato que una base de datos, incluso si es una sola base de datos en una instancia SaaS en Azure SQL. Por ejemplo, un Blob de 1GB en Azure cuesta 18.22€ al mes.

Y la DB más simple, una Azure SQL Gen 4 con 1 vCore cuesta 160,53€ al mes. Casi 10 veces más.

¿Y el redimiento? Esto que voy a decir es una conclusión de la observación, no un test real de rendimiento, pero los datos se transfieren muy rápido. Y es rápido porque en un Data Lake los datos se mandan sin procesar, no hay transformación de los datos hasta que se consumen (ETL para una DB, ELT para un Data Lake) así que se pierde menos tiempo hasta que los datos llegan a su destino. Esto no tiene un impacto real con conjuntos de datos pequeños, pero sí con los grandes.

Configuración

El proceso para exportar el Entity Store al Data Lake es bastante sencillo y está bien documentado (pero no actualizado del todo) en los docs. Lo explicaré paso a paso.

Crear una cuenta de almacenamiento en Azure

En Azure vamos a las cuentas de almacenamiento y creamos una nueva como en la imagen inferior:

Nos aseguramos de deshabilitar el almacenamiento Gen2:

Y ya podemos crear la cuenta. Cuando esté lista vamos a Access Keys y copiamos la cadena de conexión:

Azure Key Vault

El siguiente paso es crear el Key VAult. Para este paso debemos seleccionar la misma región que la de nuestra instancia de Dynamics 365:

Cuando el Key Vaul esté listo vamos al recurso y creamos un nuevo secreto. Pegaremos la cadena de conexión de la cuenta de almacenamiento y pulsamos crear:

Crear un registro de App de AAD

Le damos un nombre a la App, seleccionamos los tipos de cuenta soportadas que necesitemos y rellenamos la URL con la dirección de nuestra instancia de #MSDyn365FO:

La registramos y ahora tenemos que añadir la API de Azure Key Vault para la app como en la imagen:

Seleccionamos la API y añadimos el permiso delegado de user_impersonation:

No os olvidéis de dar permisos con el botón de encima (debe hacerlo un admin de Azure). Ahora vamos a los secretos, creamos uno y copiamos el valor que nos da. Cuando se cierre esta pestaña no podremos ver el valor del secreto, así que aseguráos de haberlo copiado!

Configurar el Key Vault

Volvemos al Key Vault que hemos creado antes y vamos a Access policies. Creamos una nueva:

Necesitamos seleccionar Get y List para permisos de clave y secreto:

Pulsamos select principal y aquí añadimos la App de AAD que hemos creado en el tercer paso:

Añádela y no te olvides de darle a guardar en la página de las políticas de acceso!!

Configurar MSDyn365F… y O o SCM o como sea que se llame este mes

Vamos a Administración del sistema -> Configurar -> Parámetros del sistema y ahí a la pestaña Conexiones de datos. Aquí tenemos 4 campos que hay que rellenar. El Application ID es el Application ID de la App de AAD (obvio) y el Application Secret  el secreto de esa App. Esta parte está bastante clara.

El DNS name es la URL del Key Vault, y el Secret name es el nombre del secreto que hemos creado en el Key Vault con la cadena de conexión.

Una vez está todo configurado podemos pulsar los botones de prueba y, si habéis seguido todos los pasos, deberían saliros estos mensajes:

Si cualquiera de las validaciones falla simplemente borraría todos los recursos y empezaría de cero.
Ahora, los dos checkbox que tenemos al lado de los campos:
  • Enable Data Lake integration: activa el push de datos del entity store a la cuenta de almacenamiento que hemos creado al principio y que es el principal propósito de este post.
  • Trickle update Data Lake: hace actualizaciones después de que cambien los datos (Trickle Feed).

Configurar Entity Store

Para acabar, vamos al Entity Store (en Administración del sistema-> Configurar -> Entity Store) y activamos el refresco de las entidades que queremos que hidraten el Data Lake (me encanta, parece que es el término correcto para referirse a mandar datos al Data Lake):

Y listo, nuestros datos se están mandando a un Blob de Azure:

Las entidades se guardan cada una en una carpeta, y dentro de cada carpeta hay otra carpeta por cada medida de esa entidad, y dentro un CSV con los datos.

Ahora podemos consumir estos datos desde Power BI con el conector de blob, o alimentar a Azure Data Factory o lo que quieras, porque ese es el propósito del Data Lake.

¡Suscríbete!

Recibe un correo cuando se publique un nuevo post
Author

Microsoft Dynamics 365 Finance & Operations technical architect and developer. Business Applications MVP since 2020.

Write A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

ariste.info