Muchas empresas, a la hora de abordar la gestión del big data, han invertido en entornos tecnológicos que pasan por elementos como un data lake central y un equipo de datos. Todo ello con la expectativa de fomentar el crecimiento del negocio en función de los datos que de su actividad se obtiene. Sin embargo, es un problema común que, después de un alto rendimiento inicial, acabe convirtiéndose todo procedimiento data en un cuello de botella en el que quizás no se vea comprometida la calidad de los datos, pero sí la agilidad y la eficacia con la que se pone a disposición la información final a sus usuarios.
Es en torno a esta problemática donde ha surgido en los últimos años con fuerza un término: data mesh, que promete agilizar todos estos procesos en base a romper la tradicional arquitectura monolítica de los entornos data fabric, hacia una arquitectura basada en los microservicios pero, ¿podemos aplicar por igual a todos los entornos el data mesh?, ¿qué diferencias concretas existen con data fabric?, ¿cómo diseñamos un proceso data-mesh?, ¿cuándo conviene aplicarlo? Estas son algunas preguntas cuya respuesta os queremos ofrecer desde elternativa.
¿Qué es la arquitectura data mesh y cómo aborda los cuellos de botella?
Tal como hemos introducido, una arquitectura data-mesh ofrece un enfoque descentralizado frente al enfoque monolítico de otros procesos tradicionales, lo cual permite a los equipos de dominio realizar los análisis de datos por su propia cuenta, sin dependencias del equipo de datos. Eliminando estas dependencias, se reducen notablemente los cuellos de botella que puedan producir en este equipo peticiones desde diferentes departamentos no técnicos, como las que puedan solicitar marketing, ventas, RRHH, finanzas, etc.
 |
Para una mayor profundidad del término Data Mesh y sus aplicaciones prácticas, visita nuestro artículo “Data Mesh: qué es, ventajas y cómo implementar esta arquitectura de datos” |
Este hecho no quiere decir que ante un enfoque data-mesh, los equipos técnicos centrados en los datos sean innecesarios o reduzcan su carga de trabajo: aplicar una arquitectura data-mesh requerirá un mayor compromiso con la transformación digital, tal como veremos posteriormente, así como la reparación de los data pipelines tras cambios en la base de datos operativa.
Diferencias entre Data Mesh y Data Fabric
Tal como ocurre con otros términos que forman parte de nuestro vocabulario (ETL vs ELT; datalake vs data warehouse, etc.), entre ambos procesos el fin es el mismo (obtener la máxima información de los datos a través de la incorporación de tecnología), pero con matices que hacen que cada uno sea la opción preferente para diferentes entornos, sobre todo a la hora de cómo presentamos los datos.
Por ello, es muy importante que antes de decidirnos por un proceso data mesh, data fabric o incluso ambos (veremos más adelante como no son excluyentes), auditemos nuestro entorno data y nos guiemos por profesionales que determinen cuál es la solución más adecuada para nuestra empresa.
Esto se debe a que tal como mencionábamos en el anterior apartado, es un error querer aplicar un proceso data mesh por el simple hecho de reducir la dependencia de los departamentos con el equipo IT con el fin de reducir sus funcionalidades, ya que precisamente puede sernos contraproducente si no reforzamos la inversión en el equipo data, que debe en todo momento garantizar la correcta calidad del dato.
Por este motivo y por otros tantos, conviene que conozcamos en detalle las diferencias entre data mesh y data fabric más allá de cómo se presentan los datos, centrándonos en otros aspectos como el cómo manejan los datos, sus mecanismos de almacenaje y su forma de gobernarlos.
Enfoque de datos como productos vs enfoque automatizado
Cada paso en el proceso de tratamiento de los datos de un Data Mesh se enfoca a reducir la fricción que pueda producir el acceso a éstos para quienes lo necesiten sin importar la experiencia técnica, mientras que en el caso de los procesos Data Fabric se centran en la automatización a través de múltiples herramientas con la finalidad de conectar datos disponibles desde varias ubicaciones, extrayendo la información de este entramado tecnológico mediante conexiones.
La descentralización frente a la centralización
Lo destacábamos como el primero de los principios del Data Mesh: la creación de múltiples dominios dedicado cada uno de ellos a una especialidad según el uso que se le de y la función que tenga según el consumidor a quien se dirige. Esto supone un enfoque descentralizado frente a la centralización que propone Data Fabric, que plantea la gestión y el gobierno de los datos desde una única fuente de datos. Ambos ofrecen datos de calidad en los puntos finales de cada una de sus redes, pero la diferencia radica en la procedencia más variada del Data Mesh frente a la procedencia unificada del Data Fabric.
Acceso a los datos
Esa descentralización vs centralización en cuanto a la gestión y gobierno cambia las tornas a la hora de hablar de puntos de acceso y control: el Data Mesh emplea conjuntos de datos controlados por los equipos especializados para ello (IT, Data Engineers, etc.), mientras que Data Fabric emplea el control a través de distintas APIs basadas en objetivos previamente configurados.
Arquitectura data
A la hora de hablar de arquitectura data en el caso de Data Fabric hay un concepto clave: metadatos, que son impulsados por la tecnología basada en herramientas para establecer conexiones entre las diferentes fuentes de datos para ponerlas a disposición a los usuarios finales a través de sistemas de entrega. En el caso de Data Mesh, usa un patrón organizativo y distribuido que crea diferentes dominios especializados, de menor tamaño dentro de una organización según la tipología de usuarios de estos datos.
Enfoque bottom up frente a top down en el gobierno del dato
Nos centramos ahora en el cuarto de los principios definidos para el Data Mesh: su enfoque bottom-up, que dista del enfoque top-down del Data Fabric. Esto es que mientras Data Mesh implica la entrada de todos los dominios a la hora de considerar las reglas y pautas que definirán la calidad y correcta gestión del dato, Data Fabric “impone” estas reglas y pautas desde los máximos responsables de los datos (equipos técnicos, ingenieros del dato, etc.) hasta los equipos que harán uso de su información.
| DATA MESH | DATA FABRIC |
| Datos organizados a través de los propietarios de dominios | Datos organizados a través de la tecnología |
| Grupos distintos de equipos respecto a la administración de datos | Una única capa de administración virtual sobre los datos distribuidos |
| Datos tratados, controlados y manipulados por los equipos data como producto al servicio de la organización | Datos directamente controlados y presentados para el consumo de la organización mediante APIs |
| Estructura de propiedad de data lakes bottom-up (reglas marcadas por los consumidores de datos) | Estructura de propiedad de data lakes top-down (reglas marcadas por los propietarios, desarrolladores y controladores del dato) |
Factores determinantes de la arquitectura Data Mesh vs arquitectura tradicional
Simplificando, la arquitectura data mesh es el equivalente a lo que hasta ahora hemos conocido como microservicios de data. Es decir, pasar de las aplicaciones monolíticas (una aplicación software en la que la capa de interfaz de usuario, lógica de negocios y la capa de acceso a datos están combinadas en un mismo programa y sobre una misma plataforma) a las arquitecturas de microservicios (una aplicación software construida mediante un conjunto de pequeños servicios, independientes entre sí y en la que cada uno de ellos se encarga de implementar una funcionalidad completa del negocio).
Con ello, lo que el Data Mesh nos permite es asociar la estructura y el lenguaje de código (territorio de los departamentos técnicos de la empresa), con el resto de campos en los que se trabaja una empresa (departamentos ejecutivos). Es decir, tal como apuntábamos en la introducción del término Data Mesh: democratizar y descentralizar los datos para que cualquiera con necesidades sobre ellos, pueda usarlos según su propio contexto y no según se presentan de forma generalizada.
Este cambio de paradigma supone dentro de la cultura big data pasar de una visión data-driven (enfoque en el que los datos se ponen al servicio del usuario a través de equipos técnicos) a una visión domain-driven (los datos al servicio del usuario a través de la tecnología).
| El término domain-driven no es contemporáneo al de Data Mesh, habiéndose descrito por primera vez por Eric Evans en su libro «Domain-Driven Design – Tackling Complexity in the Heart of Software» en 2003. Lo que sí que, mientras Evans realizó una conceptualización, el Data Mesh lo convierte en metodología en el contexto de la era big data. |
En cuanto a la arquitectura seguida para el almacenaje de los datos, una metodología data fabric se sirve de un data lake único y centralizado desde donde parte la transformación de los datos, mientras que la metodología data mesh descentraliza este proceso y pone a cargo de cada sector su propio circuito de datos. Cada uno de estos circuitos tendrán sus propios data owners, compartiéndose la propiedad entre todos los que hacen uso de los datos.
Este hecho permite que no se requiera conocimientos técnicos a la hora de tratar los datos, teniendo el foco cada equipo en cómo debe hacer uso de aquellos que necesita para su analítica.
¿Y qué ocurre con los datos cruzados, aquellos que se hacen servir para diferentes sectores de la empresa? Data Mesh garantiza la interoperabilidad mediante la aplicación de estándares universales que permiten la colaboración. Tanto los formatos, la gobernanza, la disponibilidad y los metadatos se deben concretar para impedir caos entre los datos que afecten a su calidad.
Cuando aplicar procesos Data Mesh y cuando procesos Data Fabric
De forma muy resumida, basándonos en el anterior punto donde hemos tratado las diferencias entre ambos procesos, podríamos decir que, en el caso de Data Mesh, el fin es un cambio organizacional, mientras que en el caso de Data Fabric, el cambio es más tecnológico. Es decir, lo que se pretende con el Data Mesh es que toda la plantilla participe y tenga presente la producción de datos como fin máximo, aunque con el gobierno en manos de un equipo altamente especializado, mientras que con Data Fabric lo que se pretende es hacer el dato accesible a cualquier miembro de la plantilla a través de tecnología capacitada para ello.
Con estos puntos sobre la mesa, ¿es mejor un proceso Data Mesh que un proceso Data Fabric o viceversa? Para responder a esta pregunta tenemos que considerar dos aspectos. El primero de ellos el que hemos insistido a lo largo de este artículo: cada situación, cada empresa, cada contexto, requiere su propia solución, por lo que sería un error que indicáramos a priori que un proceso es mejor que otro basándonos en la generalidad, ya que la generalidad no existe en el mundo de los datos.
El segundo de los aspectos es que un proceso no es excluyente del otro: de hecho, es útil a la hora de hablar de arquitectura de datos incluir tanto procesos de Data Fabric como Data Mesh. No son mutuamente exclusivos en cuanto deben ser tratados como marcos arquitectónicos, no arquitecturas sólidas de por sí. No tienes arquitectura de datos hasta que los marcos se adapten y personalicen a tus necesidades, tus datos, tus procesos y tu terminología, y para ello, tanto Data Mesh como Data Fabric tienen cabida en el tratamiento del big data.
De hecho, puede ser muy recomendable aprovechar las automatizaciones implícitas en los procesos de Data Fabric introduciéndolas en etapas concretas del Data Mesh, sobre todo en empresas que avanzan en su proceso de digitalización introduciendo nuevas tecnologías como las aplicaciones de aprendizaje automático o machine learning.
Siguiendo con este ejemplo, veríamos una mejora evidente de incluir ambos procesos en el uso de machine learning si lo acercamos a los usuarios finales (ventas, marketing, RRHH… fin que persigue el Data Mesh) mediante la automatización de las etapas que involucran la preparación de datos para el ML (fin que persigue Data Fabric). De esta forma se mejora la velocidad, la precisión y la disponibilidad mediante conjunto de datos controlados, a la par que los usuarios del dominio conocen qué hacer con los datos sin la necesidad de que tenga que intervenir IT, que por otra parte no requerirá la necesidad de conocer para qué se van a usar los datos para adaptar los procesos a cada fin.
No obstante, conviene destacar a la hora de inclinarnos por una opción, otra o ambas, aspectos como que un proceso Data Mesh requiere un compromiso con la digitalización más elevado, en el que se crean o se mantienen como personal indispensable equipos técnicos en data, mientras que un proceso Data Fabric puede ser abordado desde diferentes niveles de complejidad.
Este hecho se resume en que un proceso Data Fabric no requiere de ningún proceso Data Mesh si así lo solicitan las circunstancias. Sin embargo, un proceso Data Mesh sí requiere procesos Data Fabric, sea cual sea el contexto.
Cuando construir una arquitectura data mesh
Insistimos: no debemos basarnos en la aleatoriedad de “esta arquitectura puede funcionar en mi proceso digitalizador”, sino en el “esta arquitectura resuelve mis problemas con el tratamiento del dato de mi empresa”.
Esos problemas, en el caso del data mesh, los podemos identificar como resistencia a la hora de abordar la escalabilidad, dependencias complejas entre diferentes departamentos de la empresa, los mencionados cuellos de botella producidos por una desmedida solicitud de peticiones al equipo data o problemas de gobierno y seguridad del dato.
Problemas que, por otra parte, también aborda data fabric, pero que pueden inclinarse a favor de data mesh acorde a tres factores principalmente:
- Numero de fuentes de datos de la empresa
- Tamaño del equipo que trabaja con los datos
- Cantidad de departamentos o dominios de negocio
Cuanto mayor sea la suma de estos tres factores en conjunto, más nos podría beneficiar la aplicación de un proceso data mesh.
Soluciones data mesh a nuestro alcance
La arquitectura data mesh se basa en abordar cuatro principios muy definidos: orientación específica de dominio, datos tratados como productos, infraestructura de autoservicio y enfoque bottom-up en el gobierno del dato.
Toda solución que permita un desarrollo óptimo de cada uno de estos cuatro principios será a priori apta para aplicar una arquitectura data mesh, lo cual no quiere decir que no existan diferencias entre ellas que nos puedan beneficiar en según qué entorno de datos nos movamos.
Nuevamente, será la asesoría y la auditoría de nuestros sistemas quienes mejor determinen qué solución es la más adecuada, pero sí podemos señalar como óptimas plataformas como Snowflake, Talend o Informatica al abordar estos principios en su totalidad y contar con herramientas y funcionalidades que responden al sentido de aplicar data mesh en nuestra empresa.
Así, como arquitectura distribuida, la composición básica recomendable de cualquier data mesh a aplicar desde cero o dispuesto para migrar, consiste en un data lake o data warehouse ya alojado en cloud, donde los datos se almacenen y transformen en una plataforma que permita estándares centralizados y propiedades descentralizadas a la par.
Snowflake Data Mesh
Una de las mayores ventajas que ofrece Snowflake a la hora de construir un data mesh en su considerable variedad de capacidades bajo un mismo paraguas. Capacidades que, con otras soluciones, requerirían la adición de diferentes colecciones de servicios, lo cual requeriría un mayor tiempo de adopción, una mayor complejidad y, en definitiva, un mayor número de profesionales del dato que adecuen las herramientas.
Tratando casos particulares, los usuarios de Snowflake pueden crear y automatizar la transformación de datos en pipelines para convertirlos en datos tratados como productos y gobernados, destacando un amplio tratamiento de diferentes formatos de archivo que van desde JSON, XML, Parquet, AVRO, Delta Lake2, Apache, Iceberg3 hasta otros menos comunes. Además, Snowflake da soporte a datos no estructurados como pudieran ser imágenes, videos u otros formatos binarios. Datos que pueden ser manipulados en la propia plataforma Snowflake usando SQL, Python4, Scala, Java y Javascript, o a través de funciones externas más amplias compatibles en su plataforma cloud.
Talend Data Mesh
El data Fabric de Talend es una de las soluciones más completas y flexibles a la hora de gestionar datos. Teniendo en cuenta esta flexibilidad como uno de sus puntos fuertes, esta arquitectura de Talend nos permite tanto integrar un data mesh como facilitar el gobierno y la calidad del dato, dos aspectos que son los puntos débiles de toda arquitectura de microservicios.
Así, contando con las necesidades previas que requiere tu empresa, se puede montar el data mesh sobre la arquitectura que ofrece Talend para atender el proceso de datos de cada dominio sin perder gobernanza, siendo altamente recomendable en este caso, la herramienta Talend Data Catalog, que permite a los dueños de cada dominio una gestión ágil basada en búsqueda por facetas, muestreo de datos y descubrimiento semántico, así como una categorización y perfilado automático de los datos.
Informatica Data Mesh
El punto fuerte de Informatica a la hora de montar un data mesh basado en su arquitectura es la excelente integración de datos que ofrece, admitiendo la analítica desde múltiples arquitecturas. Este hecho, sumado a una no menos potente escalabilidad, permite admitir situaciones de integración de datos complejas como las que el data mesh ofrece.
Por otra parte, la solución de Informatica es de las más avanzadas en el uso de inteligencia artificial y machine learning, lo cual faculta el uso de estas dos metodologías avanzadas para una integración de datos adicional y tratamiento de la calidad del dato.
¿Cuál es la mejor solución Data Mesh?
Insistimos una vez más: que el data mesh de Snowflake resulte mejor que el de Talend, o que el de Talend resulte mejor que el de Informatica o cualquier otra solución compatible del mercado, va a depender del entorno en el que se construya el data mesh y para las necesidades que se vayan a cubrir con él.
Sí que se pueden dar ciertas generalidades que inclinen la balanza hacia un producto u otro, como el grado de madurez digital en el que se encuentre tu empresa, su compromiso con los procesos de transformación digital, el entorno del que se parta (cloud, on premise o híbrido), el tiempo en el que se quiera cubrir la integración, etc.
Así, por ejemplo, podríamos recomendar el data mesh de Informatica en procesos de transformación digital en los que se incluya involucrar IA, con el hándicap de que este tipo de implementaciones y adopciones son complejas, requieren semanas y un presupuesto elevado, lo cual lo hace menos conveniente para digitalizaciones en primeras fases de adopción.
Esto último lo puede resolver la flexibilidad de Talend en cuanto a su variedad de opciones, lo cual abre un amplio abanico de entrada y compromiso con la arquitectura data mesh, siendo otro de sus puntos fuertes la analítica, indispensable para no perder gobierno sobre los datos. Sin embargo, podría perder la batalla en casos en los que se necesite un uso operativo de alto volumen por sus capacidades más limitadas de producción de datos.
Conocimiento y auditoria del entorno en el que trabajan nuestros datos, compromiso con el alto valor que ofrecen a los equipos que forman nuestra organización y herramientas adaptativas a cómo queremos tratar, transformar y organizar nuestras fuentes de información son tres claves que nos ayudarán a decidir si es mejor un data mesh, un data fabric o la combinación de ambos. Deja que desde elternativa te ayudemos con estos tres pilares para que juntos consigamos el único fin posible: devolver el valor de los datos a tu negocio.
