Empezar este post es fácil, porque muchos nos podemos preguntar:
¿Qué es un Data Lake?
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:
- 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.