AUTORES

Marco Pesarini
Partner @Bip xTech

Giuseppe D’Agostino
Senior Cloud & Data
Architect @Bip xTech

Luca Natali
Senior Cloud & Data
Architect @Bip xTech

Martino Ongaro
Cloud & Data Engineer
@Bip xTech

El data lake siempre ha sido uno de los pilares fundacionales en la base de las organizaciones impulsadas por los datos, una filosofía empresarial hacia la que todas las empresas modernas se han esforzado esta última década. En esencia, un data lake es un gran archivo informático al que se pueden transferir todos los datos corporativos, tal cual, sin transformaciones, para que los datos sean accesibles a todas las funciones; en otras palabras, una democratización del acceso a los datos.

En este diseño, los datos adquieren un valor intrínseco, casi natural.  Aprovechando las nuevas tecnologías, que van desde la ingeniería de datos hasta la ciencia de datos, cualquiera puede acceder a los datos y extraer una evidencia, un significado, sin necesidad de tener demasiada experiencia del contexto del que se derivan los datos.

Sin embargo, trabajando a lo largo de los años en muchos proyectos relacionados, hemos comprobado que el modelo adolece de algunas complicaciones subyacentes. Este afán por extraer los datos brutos del dominio de su nacimiento y procesarlos en plataformas centralizadas, ha creado dos problemas que resultarán familiares a cualquiera que haya practicado en este campo: la dificultad inherente a la búsqueda e interpretación de los datos para quienes desconocen su origen, y la baja calidad crónica de los datos derivada del hecho de que quien extrae los datos de su dominio de nacimiento no se hace luego responsable de su uso.

Para hacer frente a estos problemas, las empresas se dotan cada vez más de complejas estructuras de gobernanza de datos, que definen responsabilidades, procesos y funciones para garantizar la claridad de los datos y preservar su calidad. Sin embargo, la solución a estos problemas no puede ser sólo organizativa. Las empresas también necesitan ayuda técnica para simplificar la esencia del modelo.

A este respecto, es muy interesante la intuición de Zhamak Dehghani, expuesta en su artículo «How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh»[1]. En él, propone una nueva forma de gestionar los datos de la empresa previendo el análisis de los datos en el propio dominio de origen, el dominio donde nacen los datos. Según este enfoque, son los propios expertos del dominio de origen los que se responsabilizan de la interpretación y la calidad de dichos datos. La responsabilidad de los datos de los clientes recae en el dominio del CRM, la de los datos del presupuesto en el sistema de gestión, la de los datos de las ventas en el dominio del comercio electrónico, etc. Es fácil entender cómo en este diseño los problemas relacionados con la interpretación y la calidad de los datos disminuyen sustancialmente, dada la experiencia que abunda en el dominio de origen de los datos.

Sin embargo, el aspecto principal de la intuición relativa a la malla de datos radica en la solución propuesta para evitar una recaída en el viejo mundo de los silos de información, en el que los datos se enmascaraban y se perdían en los distintos dominios de origen. En los dominios de la malla de datos se da la responsabilidad de crear productos de datos que son herramientas de software para visualizar e interpretar los datos que se publican en toda la empresa. Estos productos se ponen a disposición en el mercado interno de información de la empresa y pueden ser remunerados, es decir, dotados de un presupuesto para su crecimiento, en función de su uso o suscripción por parte de otros usuarios.

Se crea un mercado libre -y éste es el reto de las herramientas que soportan la malla de datos- en el que todos los usuarios pueden encontrar y consumir todos los productos de datos corporativos, y de la competencia natural por el presupuesto entre los dominios se deriva un impulso beneficioso para divulgar y compartir datos.

Los datos se comunican así bajo la responsabilidad del dominio, pero en un mercado en el que los dominios individuales están motivados para exponer dichos datos y hacerlos comprensibles y de calidad. Esto pone la experiencia del dominio en la base de la valorización de los datos.

Cómo se compone una malla de datos

La malla de datos basa sus fundamentos teóricos en el modelo arquitectónico del Diseño Dirigido al Dominio (DDD), según el cual el desarrollo de software debe estar estrechamente vinculado a los dominios de negocio dentro de una organización. En el DDD, cada dominio organizativo puede representarse mediante un modelo de dominio, que es una combinación de datos, comportamientos característicos y lógica empresarial que guían el desarrollo del software del dominio. El objetivo principal del DDD es crear un software pragmático, consistente y escalable, descomponiendo la arquitectura en servicios dentro de los dominios individuales y centrándose en su reutilización en la composición de los diferentes productos de software que soportan la empresa. La primera implementación del DDD en el software empresarial fue la revisión de las aplicaciones monolíticas hacia arquitecturas basadas en microservicios: cada microservicio se circunscribe en un dominio y se encarga de satisfacer los requisitos de una funcionalidad específica proporcionando una función de la aplicación a todos los productos que la solicitan.

La malla de datos aplica el DDD a las arquitecturas del dominio de los datos. Los productos de datos, como los denominan, permiten el acceso a los datos del dominio a través de funciones elementales que exponen interfaces precisas y ponen a disposición los datos en bruto, preprocesados o procesados. Al igual que los microservicios son componentes de software que exponen funcionalidades elementales de la aplicación, los productos de datos son componentes de software que exponen funcionalidades elementales de datos y análisis dentro del dominio. Los productos de datos tienen el objetivo de dividir las funciones analíticas del dominio en productos elementales y reutilizables, como los microservicios subdividen las funciones de la aplicación.

Al igual que con los microservicios, también en la malla de datos, el nuevo modelo desagregado necesita una serie de reglas y herramientas para mantener el buen gobierno del conjunto.

En primer lugar, los productos de datos deben respetar algunas características, que son funcionales para crear el mercado libre del que hablábamos. Independientemente de cómo se cree la interfaz específica de acceso a los datos -se puede dar acceso a través de una API, a través de una vista en una base de datos o a través de un sistema de virtualización- o del tipo de datos que se pongan a disposición, los productos de datos deben respetar las reglas identificadas en el acrónimo DATSIS según las cuales debe ser un producto de datos:

  • Descubribles – los consumidores deben ser autónomos en la búsqueda e identificación de los productos de datos creados por los diferentes dominios
  • Direccionables: los productos de datos deben ser identificados con un nombre único siguiendo una nomenclatura común.
  • Confiables: los productos de datos son creados por los dominios que los poseen y deben poner a disposición datos de calidad.
  • Autodescriptivos: los consumidores deben poder utilizar los datos sin tener que preguntar a los expertos del sector qué significan.
  • Integrados: deben crearse siguiendo normas compartidas para poder reutilizarlos fácilmente para crear otros productos de datos.
  • Seguros: los productos de datos deben ser seguros por diseño y el acceso a los datos debe estar regulado de forma centralizada mediante políticas de acceso y normas de seguridad.

Sólo respetando estas reglas es posible crear productos de datos que permitan un diseño de malla eficaz y fiable.

Pasando a las herramientas, hay dos factores esenciales para construir una malla de datos que funcione: la infraestructura de datos como plataforma y la gobernanza del ecosistema.

Al imponer el requisito de que los dominios de aplicación individuales desarrollen sus productos de datos, la organización corre el riesgo de que aumente el índice de heterogeneidad de las tecnologías en uso, lo que hace muy compleja la estrategia de aprovisionamiento. Por lo tanto, en la implementación de una malla de datos, es importante que una organización se dote de una plataforma infraestructural común -la infraestructura de datos como plataforma- que suministre los bloques básicos para la creación y el uso de productos de datos a todos los dominios: almacenamiento, pipeline, base de datos, funciones de cálculo, por nombrar algunos. Cualquier dominio que quiera crear sus propios productos de datos tendrá que hacer uso de estos ladrillos accediendo a la infraestructura de datos como plataforma en modo de autoservicio. Esto permite la estandarización del desarrollo de productos de datos y la introducción de un lenguaje común entre los distintos dominios. Las plataformas en la nube PaaS son una opción interesante para construir esta infraestructura común sobre la que construir productos de datos; una opción que podría ofrecer una adopción con costes controlados y velocidad de implementación.

La creación de productos de datos en modo distribuido también corre el riesgo de aumentar la tasa de duplicación y la complejidad del acceso a los datos, perdiendo los objetivos de calidad y responsabilidad propios del paradigma de malla de datos. Para ello es muy importante que la organización se dote de herramientas de gobernanza del ecosistema que ayuden a dar visibilidad y comprensibilidad a los productos de datos, herramientas en las que cada producto de datos pueda ser registrado y, en consecuencia, sea consultable y reutilizable según políticas específicas de autenticación y autorización.

Perspectiva técnica

Ahora que se han presentado los conceptos de producto de datos, infraestructura de datos como plataforma y gobernanza del ecosistema, vamos a entrar en una perspectiva más técnica para dar tangibilidad a esta introducción. En primer lugar, los productos de datos no son más que conjuntos de componentes tecnológicos, a menudo ya conocidos por las empresas para cargar, almacenar, procesar y analizar datos. Por ejemplo, tomemos un producto de datos que sea una herramienta para elaborar un informe sobre datos de dominio y examinemos los ladrillos que pueden componer el producto de datos.

Como se ha mencionado, los bloques de construcción del producto de datos provienen de la infraestructura de datos como plataforma. Aquí encontramos tecnologías establecidas que incluyen el almacenamiento de objetos y las colas de eventos, una capa de procesamiento por lotes y de streaming, y herramientas de consumo de datos para la elaboración de informes, BI, ML e IA. Son herramientas ya ampliamente conocidas y adoptadas.

Tomando el ejemplo del producto de datos que produce un informe, los bloques de construcción podrían ser un almacenamiento que contenga los archivos de los que extraer los datos, un motor Spark para la extracción y el procesamiento, una base de datos donde apoyar los datos procesados, una interfaz para el análisis y una vista para el informe y una API para entregar los resultados.

Para la realización del producto de datos, la infraestructura de datos como plataforma también tiene la tarea de proporcionar las herramientas que permitan la orquestación de componentes y la colaboración entre usuarios. En ella encontramos tecnologías de orquestación (como Airflow, Dagster, DataFactory), que permiten coordinar la ejecución del procesamiento y las más recientes herramientas de modelado de datos, para facilitar la colaboración en la fase de desarrollo entre ingenieros y analistas (por ejemplo, Dremio, y la herramienta Data Build).

En el caso de nuestro producto de datos, estas herramientas permiten la ejecución ordenada de los comandos y funciones que generan el informe y una colaboración más eficaz entre el ingeniero de datos que utiliza Spark para gestionar los datos en el almacenamiento, el modelador que estructura el modelo de datos en la base de datos, el analista que lo utiliza para la exploración y el desarrollador que distribuye los resultados en forma de API.

En este punto, el producto de datos está listo para ser consumido incluso fuera del dominio, y aquí entran en juego las herramientas de gobernanza del ecosistema adecuadas para gestionar el catálogo y la distribución de los productos de datos. Entre las principales herramientas de organización entre dominios encontramos las tecnologías federadas, las de catalogación de productos de datos y las de descubrimiento de datos (como Amundsen, Metacat, Atlas), que los hacen visibles y utilizables para los usuarios finales. Con la inclusión de estas herramientas, los usuarios de otros dominios pueden buscar y acceder al producto de datos, utilizando las capacidades de búsqueda semántica o desplazándose por el catálogo central de productos de datos de la empresa.

Para completar la plataforma de gobernanza del ecosistema, hay funciones que supervisan el cumplimiento, la calidad de los datos, el control de acceso y la supervisión. El nuevo Data Stewart en la hipótesis de un ecosistema basado en AWS explotará las alertas automáticas de AWS Comprehend para identificar las violaciones de la privacidad, Glue DataBrew para controlar la calidad de la salida del nuevo producto de datos, Lake Formation para controlar sus permisos internos y externos al dominio y CloudTrail para supervisar el acceso y el uso.

Perspectiva organizativa

Un último aspecto importante a tener en cuenta al evaluar el paradigma de la malla de datos es la adaptación organizativa que puede requerir su introducción. Desde esta perspectiva, la transición es más fácil para quienes ya han adoptado modelos organizativos ágiles con capítulos de dominio de competencia y escuadrones de proyectos.

El principio de suministrar datos como «producto» ve el nacimiento de nuevas figuras como los Data Product Owners -similares a los históricos Product Owners- dentro de los dominios individuales; figuras responsables del ciclo de vida de los productos de datos (planificación, seguimiento, etc.) y de la ejecución de la estrategia de datos del dominio.

Los perfiles profesionales ya presentes en las organizaciones actuales se distribuirán en los dominios de negocio: la descentralización de la propiedad sobre los datos, y del tratamiento de los mismos por parte del dominio de competencia, hace que figuras como los Ingenieros de Datos y los Arquitectos de Datos se distribuyan dentro de los dominios individuales. Los Ingenieros de Datos del dominio «cliente» deben ser identificados, por poner un ejemplo, ya que en el pasado los desarrolladores de microservicios verticales nacieron dentro del mismo dominio.

Sin embargo, en una organización distribuida en dominios, la función responsable de las políticas de gobernanza (interoperabilidad, seguridad, cumplimiento, etc.) sigue estando centralizada. Es una entidad organizativa central la que garantiza la aplicación de las políticas a nivel de cada dominio. Esta entidad está formada por figuras técnicas a nivel de empresa (por ejemplo, arquitectos de datos de empresa, arquitectos de TI de empresa, etc.), representantes de los dominios y expertos en seguridad y cumplimiento.

La única otra función que permanece centralizada en el modelo es la de supervisar la infraestructura de datos como plataforma que gestiona la infraestructura de todos los dominios con competencias de ingeniería y operación.

La malla de datos es, por tanto, una composición de muchos aspectos, en una posible transformación del mundo de los datos hacia un modelo más ágil y federado.

Bip xTech, nuestro Centro de Excelencia en tecnologías exponenciales, cuenta con expertos en todas las disciplinas más avanzadas en torno a la gestión de datos; desde la ingeniería de datos hasta la nube, desde la gobernanza de datos hasta las arquitecturas de microservicios; podemos suministrar todos los ingredientes para la transición de la malla de datos.


Si está interesado en obtener más información sobre nuestra oferta o desea mantener una conversación con uno de nuestros expertos, envíe un correo electrónico a [email protected] con el asunto “Data Mesh” y nos pondremos en contacto con usted lo antes posible.


[1] https://martinfowler.com/articles/data-monolith-to-mesh.html

Leer más opiniones

red lines

Contactenos

Milan, Italy | BIP xTech Head Office

Torre Liberty Building
Galleria de Cristoforis 1, Milan, 20121

[email protected]

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.