Si como responsable directo o indirecto de la transformación digital, analíticas, BI, datos, o cualquier otro rol relacionado dentro de tu empresa, has estado investigando las novedades del último lustro en cuanto al tratamiento de datos y cómo exprimirlos para obtener el máximo valor para tu negocio y llevar a tu organización al nirvana de ser data-driven, con casi total seguridad te has topado con el término arquitectura de medallón (Medallion Architecture).
Se trata de un modelo que, aplicado a herramientas como Microsoft Fabric para explotar tus datos de Dynamics 365, te abre la puerta a una comprensión profunda de cómo estructurar y gestionar datos de manera más eficaz y estratégica con una arquitectura sólida y escalable.
Quizás hayas visto la ilustración de las medallas de oro, plata y bronce, como en unas olimpiadas. Si ya has trabajado con arquitecturas multicapa anteriormente, como el ciclo típico de datos de origen / staging / ETL / EDW / Datamarts / Modelos semánticos, te harás una idea de lo que es la arquitectura Medallion. Si no es el caso, en este artículo intentaré explicártelo de la manera más simple posible.
De forma simple, es un patrón de arquitectura para data lakehouses, compuesto normalmente por tres capas o medallas: bronce, plata y oro. En la primera capa (bronce) se acumulan los datos (se insertan pero no se borran nunca), y en las capas sucesivas se realizan todos los procesos de calidad e integración necesarios para que los datos lleguen a la siguiente capa más preparados para el análisis que en la capa actual.
Normalmente, las capas de bronce y oro son la primera y la última, y tienen un rol más o menos predefinido. La capa de bronce es donde aterrizan los datos para no volver a salir, y la capa de oro es donde los datos están preparados para el consumo, ya sea a través de modelos dimensionales, vistas o tablas listas para el análisis por herramientas de ciencia de datos, ML o IA.
Una de las principales ventajas de esta arquitectura es su flexibilidad. Aunque la primera y la última capa tienen roles más o menos bien definidos, en el medio podemos tener cualquier cantidad de capas que necesitemos de acuerdo a los requerimientos de nuestra organización. Además, el flujo de los datos no es lineal, pudiendo cada capa leer datos tanto de capas anteriores como posteriores.
Otra gran ventaja de la arquitectura de medallón es que, al tener todos los datos acumulados en la capa bronce, cualquier cambio requerido en las capas subsiguientes se puede lograr con una reconstrucción total o parcial de cualquiera de estas capas. Esto la hace compatible con varias estrategias de implantación de DW, ya sea EDW, modelado dimensional, data vault, o cualquier otra actual o futura.
Por supuesto, como cualquier arquitectura, también tiene sus contras. La principal es que podemos tener datos duplicados en varias capas. Sin embargo, considerando el bajísimo costo actual del almacenamiento, esta es una desventaja insignificante al lado de la flexibilidad y robustez de esta arquitectura.
Donde aterrizan nuestros datos con poco o ningún tratamiento. Aunque no es una regla firme, lo ideal es que en esta capa los datos se carguen de forma incremental, y que el procesamiento sea mínimo o nulo. De esta forma, ante un cambio en las reglas de procesamiento, se pueden realizar sin tener que cargar los datos nuevamente. Además, los datos que entren no deben ser borrados, salvo que se detecten datos incorrectos por cualquier motivo, o por un proceso normal de decomiso cuando ciertos datos ya no son ni serán requeridos a ningún efecto.
En esta capa se aplican reglas de validación e integración de datos. Es la primera capa donde se puede comenzar a generar valor y análisis exploratorios, y en la que se invierten los mayores esfuerzos en cuanto a ingeniería de datos. Es compatible con cualquier combinación de trabajos ELT (Extracción, Carga y luego Transformación) y ETL (Extracción, Transformación y luego Carga) en la secuencia que se requiera, y con la cantidad de capas necesarias de acuerdo con el resultado pretendido y la infraestructura y requerimientos de cada organización.
Aquí los datos ya quedan preparados para habilitar la extracción de conocimiento y hallazgos por parte del negocio con distintos tipos de herramientas de análisis, bien por seres humanos, como por algoritmos de IA/ML, o una combinación de ambos. Esto puede ser a través de modelos analíticos bajo cualquier arquitectura (dimensional, data vault, etc.) o directamente con tablas agregadas para ser consumidas en procesos de ML / Data Science o IA, o herramientas de visualización que utilicen tablas de este tipo.
En esta capa están todas las herramientas necesarias para extraer valor a los datos, bien con herramientas de BI o bien con herramientas de análisis avanzado/Machine learning /IA, etc, conceptualmente no forma parte de la arquitectura medallón, porque en esta capa normalmente no se llevan a cabo transformación ni preparación de los datos sino principalmente consumo, aun cuando este consumo puede incluir, por supuesto, tareas de transformación y preparación de datos para su análisis por parte de los analistas de datos o de negocio, o científicos de datos.
La arquitectura de medallón o Medallion Architecture se ha hecho muy popular en los últimos 5 años debido al auge del concepto de Data Lakehouse, que no es más que disponer, gracias a nuevos estándares y tecnologías construidas para la era moderna de los datos como Delta Lake, de muchas de las principales características y funcionalidades de los Data Warehouses relacionales/tradicionales en los Data Lakes. Estos últimos se popularizaron a partir de la década de 2010, sobre todo por su bajo costo, pero carecían de funcionalidades críticas como el manejo de datos históricos, el viaje en el tiempo y el soporte de transacciones ACID.
Entonces, visto lo anterior, ¿hemos logrado el anhelado sueño de tener las funcionalidades de un Data Warehouse, pero con el costo de almacenamiento y la capacidad de escalar y trabajar con grandes volúmenes de datos de un Data Lake? ¿Debemos olvidarnos de los Data Warehouse tradicionales?
La respuesta es que que aún no, pero estamos en camino. Simplemente es un nuevo paradigma en el que debemos guiar nuestras decisiones de diseño teniendo como bandera la flexibilidad y la capacidad de adaptación de nuestra arquitectura de datos, tanto a los cambios del negocio como de la tecnología.
Optando por estándares abiertos como Delta Lake, y siendo eficientes y eficaces en cuanto al procesamiento en cada una de las etapas o medallas de nuestra arquitectura de datos para optimizar costos. Esto incluye, por supuesto, usar la herramienta adecuada para el trabajo adecuado, sea un Data Lakehouse o un Data Warehouse relacional tradicional.
Una imagen dice más que mil palabras. Aquí tienes un diagrama conceptual de una arquitectura medallón.
En el ejemplo, tenemos dos orígenes de datos en la capa bronce: uno con los datos provenientes de las herramientas ERP y CRM de Microsoft Dynamics, y otro con los datos de la herramienta de gestión de sostenibilidad y medio ambiente de Microsoft.
Esta separación es simplemente a efectos instruccionales, pero físicamente los elementos de cada uno de los orígenes pueden estar juntos, separados por esquemas / artefactos, o como la organización lo decida. Lo importante es mantener los elementos organizados en una estructura coherente para facilitar la mantenibilidad, auditabilidad y escalabilidad de la arquitectura.
Y entonces, si la arquitectura Medallion está basada en estándares abiertos, ¿por qué debería elegir Microsoft Fabric como el pilar para sostener la estrategia de datos de mi organización? Pues, antes de pasar a ello, observa la siguiente imagen y te comento más:
En la imagen podemos observar a un alto nivel los componentes de Fabric, que si bien, ya es llamado por muchos, 'Power BI con esteroides', en realidad es mucho más que eso.
Lo más relevante es el elemento llamado One Lake que lo puedes ver en la imagen como una tubería inmediatamente debajo de las cargas de trabajo o experiencias, y básicamente es la columna vertebral de la plataforma, y en donde se almacenan los datos de todas las cargas de trabajo que vemos más arriba (los 7 cuadraditos de arriba de la imagen que acompañan a Power BI).
Es decir, si te decides por implementar Fabric, desde los ficheros de origen de la capa bronce, pasando por las tablas de un data lakehouse/warehouse o de una solución en tiempo real obteniendo datos de miles de millones de dispositivos IoT, hasta los datos de un modelo semántico de Power BI o los resultados de un experimento de ML... todos están almacenados en One Lake, el 'OneDrive de los datos'.
Y lo más importante, el hecho de que todos los datos estén en One Lake significa que cualquiera de las cargas de trabajo o herramientas de Fabric puede acceder a todos los datos creados por cualquiera del resto de las cargas de trabajo (o importados en Microsoft Fabric desde plataformas externas como GCP, Snowflake o S3) bajo un mismo esquema de costos y una misma infraestructura de seguridad y autorización.
Esto simplifica enormemente la gestión requerida para que todos los integrantes de la comunidad de datos de la organización, sean profesionales o ciudadanos, puedan generar valor desde el mismo momento en que el dato llega a Fabric a través de cualquiera de sus herramientas, sin obstáculos, roces ni escollos técnicos, y sin la necesidad de aprovisionar, encender o apagar capacidades ni infraestructuras más allá de las propias capacidades de Fabric.
Esto en términos prácticos significa que un analista de datos puede estar construyendo un informe de Power BI con datos que aterrizan desde un proceso de ML en el mismo momento en que dichos datos son generados, sin necesidad de exportar e importar datos, ni de utilizar plataformas intermedias para almacenar datos en tránsito.
No es necesario gestionar permisos en múltiples plataformas, ni aprovisionar o dimensionar otros servicios fuera de Fabric. Este es solo un ejemplo de los muchos escenarios posibles. Un científico de datos puede utilizar datos de un modelo semántico de Power BI directamente, y el resultado puede ser consumido por otro proceso de ML subsiguiente o por el mismo u otro modelo semántico. Un proceso en tiempo real podría consumir datos generados por un proceso de IA creado en Fabric Data Science para enviar una alerta vía SMS al jefe de una planta si algo requiere su atención.
Fabric ofrece funcionalidades poderosas y útiles como los shorcuts, que permiten utilizar datos de otros Data Lakes sin necesidad de importarlos, o el mirroring, que permite importar datos de orígenes externos en el mismo momento en que son generados. Estas funcionalidades posibilita utilizar datos de otras plataformas de big data como Snowflake, AWS S3 o GCP directamente dentro de Fabric, de manera ágil y costo / efectiva.
Además, si tu organización utiliza aplicaciones de negocio de Dynamics 365, Fabric ofrece integraciones ya operativas y listas de usar con con desarrollo y poca configuración, que permiten acceso a los datos de forma directa y sin complicaciones, como Link to Fabric, que vimos en un post anterior.
Para ayudarte a implementar una arquitectura de datos sólida y escalable, hemos preparado este Curso de Introducción a la arquitectura de medallón con Microsoft Fabric. Si estás interesado, quieres profundizar en el tema o buscas acompañamiento para llevar tu estructura de análisis de datos al siguiente nivel, contacta con nosotros.
