15 Jun Data Mesh: desenredando el gran nudo de los datos
Es una realidad que la transformación digital y el creciente número de iniciativas comerciales están impulsando la necesidad de más integraciones en todos los dominios.
Muchas empresas están invirtiendo en plataformas de datos, especialmente en Data Lakes centralizados para, finalmente, lograr ser data-driven.
Sin embargo, los resultados no están siendo los esperados.
Los Data Lakes están presentando serias complicaciones a la hora de escalar y adaptarse a los cambiantes requisitos de las organizaciones.
La razón más común detrás de estas complicaciones está en la falta de alineación entre los administradores del Data Lake y los equipos comerciales: esta desconección obstaculiza la generación de valor.
Otro desafío está en la enorme diversidad de formatos de datos que están dentro de los Data Lakes. La administración de esta información presenta serias complicaciones, especialmente cuando se pone énfasis en la calidad y disponibilidad de los datos.
Data Mesh y los proyectos de analítica fallidos
A pesar de que muchas empresas están adquiriendo tecnologías analíticas con el fin de transformarse, los resultados no han sido positivos.
Según un informe reciente de Gartner, solo entre el 15 y 20% de los proyectos de ciencia de datos logran completarse.
De esos proyectos que se completan, los gerentes explican que solo alrededor del 8% de ellos generan valor. Si estas cifras son precisas, esto equivaldría a una -decepcionante- tasa de éxito del 2%.
¿Cuáles son las razones de estos fracasos?
Plataformas centralizadas
La mayoría de las empresas suelen mover todos sus datos hacia plataformas centralizadas.
Esta realidad crea ciertos problemas:
- Acceso deficiente: debido a la masiva cantidad de datos que deben acumular, las plataformas se enredan con toda la información y no pueden ponerla a disposición de forma sencilla.
- Datos no confiables: dentro de este enredo, los equipos no pueden hacer un seguimiento de lo que está actualizado y lo que no. Los conjuntos de datos estáticos pueden desviarse con el tiempo y volverse inutilizables.
- Los datos se centran en los técnicos analíticos: los datos se organizan en función de los técnicos de datos y no de los usuarios reales, los equipos de negocio. Dada la organización preestablecida, a estos últimos se les dificulta muchísimo encontrar y utilizar los datos que necesitan.
Arquitectura monolítica
Las arquitecturas de plataformas empresariales suelen ser monolíticas y están altamente vinculadas con muchas dependencias, en términos de tecnología y personas.
Esta realidad crea ciertos problemas:
- Mayor espera: el equipo central de datos se convierte en un cuello de botella. Los equipos de negocio deben esperar por las respuestas que necesitan.
- Interrupciones no planificadas: dado que los usuarios de negocio no pueden acceder a los por sí mismos (o verificar su confiabilidad), demandan constantemente el apoyo del equipo central de datos, el cual se verá relegado a tareas básicas y no podrá realizar ningún trabajo profundo.
- Falta de escalabilidad: debido a que la plataforma está estrechamente acoplada, no puede cambiar ni escalar al ritmo requerido para el análisis de datos avanzado.
Tecnología desconectada del negocio
Desafortunadamente, en la mayoría de las empresas no hay un puente directo entre las personas que gestionan los datos y las que los utilizan.
Los problemas saltan a la vista:
- Datos fragmentados: Dado que las empresas suelen desarrollar datos a partir de proyectos aislados, estos se encuentran segmentados y, por lo tanto, no pueden ser consumidos amplia y transversalmente.
- Procesamiento de datos limitado: El procesamiento de datos tradicional se pensó para una limitada gama de casos de uso; este atributo restringe el acceso masivo a los datos. Actualmente, los casos de uso modernos están requiriendo nuevas capacidades, por ejemplo, la transmisión de datos en tiempo real.
- Separación de los objetivos comerciales: los técnicos de datos no se vinculan con las áreas de negocio; por lo tanto, sus iniciativas no suelen responder a las preguntas y dolores comerciales de la empresa.
En resumen, el fracaso de los proyectos analíticos se debe a pequeños y grandes problemas: cuellos de botella, demoras, desconexiones, malentendidos, poca alineación con el negocio, escasa capacidad de respuesta, y muchas más.
Con base en esta realidad, el Data Mesh ha surgido como un factor clave para darle vuelta a las tendencias negativas de los proyectos analíticos.
¿Qué es el Data Mesh?
El Data Mesh es un enfoque descentralizado que admite el acceso democratizado y de autoservicio a los datos de una organización; estos permanecen ordenados por dominio comercial y no por etapa de canalización.
Los modelos de Data Mesh ayudan a las organizaciones a obtener resultados positivos cuando se trata de:
- Garantizar la propiedad de los datos y dejar que sean administrados por los usuarios que los entienden.
- Poner los datos correctos en manos de las usuarios que los necesitan.
- Proveer una mayor agilidad a toda la organización, en virtud de la autonomía que gana cada equipo en un modelo de gobierno de datos de autoservicio.
Zhamak Dehgani explica: “Las empresas deben estar abiertas a la posibilidad de ir más allá de los lagos de datos monolíticos y centralizados; es decir, buscar la construcción de una arquitectura de Data Mesh que adopte la realidad de los datos y lo que se espera de ellos (máxima disponibilidad y buena distribución)”.
Los orígenes del Data Mesh
El término ‘Data Mesh’ fue acuñado por Zhamak Dehghani, Directora de Tecnologías Emergentes en ThoughtWorks, en su artículo How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, publicado en mayo de 2019.
La investigadora explica que el Data Mesh es una estructura de datos en la que una parte de la responsabilidad de los datos se descentraliza hacia los dominios comerciales. Es decir, las empresas se vuelven responsables de administrar sus datos como un producto.
¿Qué NO es el Data MESH?
El Data Mesh sigue siendo un tema nuevo en el mundo de la analítica de datos.
Por lo tanto, es importante contextualizarlo y evitar las confusiones teóricas.
El Data Mesh es un modelo organizacional que combina el Product Thinking, las arquitecturas de datos descentralizadas, las acciones impulsadas por eventos y un estilo de diseño de microservicios centrado en la transmisión de información.
El Data Mesh no es…
- Lago de datos en una sola nube, «dominios», catálogos y acceso SQL.
- Catálogo de datos: el Data Mesh necesita una implementación física.
- Productos específicos. Ningún proveedor tiene un producto único para Data Mesh.
- Fábrica de datos. Estas incluyen muchas arquitecturas de datos monolíticas.
- Analítica de autoservicio super fácil de usar.
Hay que tener cuidado con las promesas exageradas.
¿Por qué apoyarse en el Data Mesh?
Simple: porque las formas tradicionales de la analítica no están funcionando bien.
Las empresas invierten mucho tiempo y dinero en la integración de plataformas digitales; mientras, descuidan un factor crítico: sus arquitecturas tecnológicas monolíticas son engorrosas, costosas e inflexibles.
A esto se le suma que:
- El 70-80% de las transformaciones digitales fallan.
- El auge de las arquitecturas distribuidas, aplicaciones, datos y arquitecturas en la nube se está volviendo menos centralizado/monolítico.
- El bloqueo en la nube es real y puede volverse más costoso.
- Los lagos de datos rara vez tienen éxito y solo se centran en el análisis.
- Los silos organizacionales exacerban los problemas de intercambio de datos.
- El mundo se está acelerando: el ritmo de la innovación y la competencia.
- El costo de las interrupciones de datos operativos está aumentando.
El Data Mesh no es un modelo que resuelve todos los problemas, pero sí provee un camino para iniciar la transformación y pasar la página de los proyectos analíticos fallidos.
El Data Mesh comparte los principios, las prácticas y las tecnologías que deben alinearse para resolver los desafíos principales de la modernización de las arquitecturas de datos, con el fin de responder a los problemas comerciales, a través de los datos.
Data Mesh y la democratización de los datos
El concepto de Data Mesh resuelve los desafíos de la centralización y también brinda una mayor agilidad al democratizar la gestión de datos a nivel de dominios comerciales.
Este diseño basado en el dominio es el medio principal para estructurar el uso y el intercambio de datos de extremo a extremo. Cada dominio tiene su propia fábrica de datos, la cual se compone de varios perfiles (ingenieros, analistas de datos y científicos de datos).
Los responsables se encargan de gestionar los datos de cada dominio específico.
Estos equipos, a su vez, se distribuyen entre los dominios comerciales y los apoyan en la obtención de información y respuestas provenientes de cada uno de los dominios particulares de la organización.
Principios del Data Mesh
Tareq Abedrabbo, CTO en Mesh-AI, explica que estos son los cuatro principios del Data Mesh:
El dominio como dueño de los datos (Domain-driven)
El Data Mesh es un paradigma que cuestiona la condición fundamental que se le da a los datos dentro de una empresa: mantenerlos centralizados.
Pero, ¿qué es un dominio? Básicamente, es un área del negocio. Los equipos están en la obligación de definir exactamente qué constituye un dominio dentro de su organización.
Desde el punto de vista de los datos, un dominio podría ser definido como la combinación de sistemas de origen que devienen en un conjunto de datos cohesivo.
Esta combinación provee un “conjunto de datos de dominio de origen». A su vez, estos se convertirán eventualmente en «conjuntos de datos de clientes», con el fin de alinearse y satisfacer las necesidades de los usuarios.
Una vez que se define un dominio, se puede aplicar Data Mesh dentro de ese dominio.
En resumen, el enfoque de Data Mesh descentraliza la estructura de datos. Asimismo, provee un acceso distribuido, democratizado y de autoservicio, a los datos organizados por dominio comercial y no por etapa de canalización.
Esto es mucho más útil desde una perspectiva comercial, ya que se relaciona directamente con la estructura real del negocio.
Resultados de un modelo Domain-Driven:
Los dominios se pueden seguir de un extremo a otro del negocio, lo que significa que los equipos comerciales son los responsables de sus datos: este atributo les podría permitir escalar más soluciones.
Gobierno Federado
El Data Mesh propone un cambio de paradigma a lo que entendemos por gobierno de datos. A un alto nivel, la distinción más significativa es gobernar de una manera más “federada”, en lugar de aplicar una gobernanza centralizada.
Esta nueva dinámica exige un cambio de mentalidad: saber que la verdadera responsabilidad por la calidad y la seguridad de los datos se encuentra dentro de los dominios.
Por otra parte, la gobernanza de datos tradicional a menudo se adscribe a una estructura bien definida: por ejemplo, se puede observar la forma en que se manejan los almacenes de datos. En cambio, el Data Mesh reconoce que la naturaleza de los datos es dinámica y, con ello, permite que los dominios designen las estructuras que serán más adecuadas para sus datos.
En la práctica, los estándares de gobierno de datos se definen centralmente, pero los equipos de dominios locales deberán contar con la autonomía suficiente para ejecutar sus soluciones.
Los equipos de dominio de datos autónomos y las funciones centralizadas de gobierno de datos deben colaborar para satisfacer mejor las necesidades de datos de toda la organización.
Esta colaboración es dinámica y transformadora: los equipos de dominios de datos se encargan de los procesos y los casos locales; por su parte, el equipo central se enfoca en garantizar estándares mínimos de consistencia y accesibilidad.
Resultados de un Gobierno Federado:
Bajo este esquema, los equipos pueden mantener su independencia y autonomía y, con ello, consumir datos donde sea que se encuentren y escalar masivamente la colaboración a lo largo de toda la organización.
Datos como producto
Se podría decir que un producto es el resultado de un proceso entre usuarios y empresa. El puente entre los dos agentes sería la tecnología.
Para tratar los datos como un producto, se debe entender la noción de ‘pensamiento de producto’ (product thinking).
El pensamiento de producto reconoce la existencia de un “espacio de problemas” (lo que los usuarios necesitan) y un “espacio de soluciones” (lo que el negocio puede dar).
El product thinking busca acortar la distancia entre los usuarios y el negocio, a través de un enfoque singular para la solución de problemas.
El cambio de paradigma, con base en el Data Mesh, es que los dominios de datos de una empresa y sus equipos comiencen a verse a sí mismos como una empresa autónoma. Es decir, un emprendimiento independiente que está construyendo un producto (conjuntos de datos accesibles y de alta calidad) que puede ser consumido por terceros (otros equipos y líneas de negocio de la organización).
Resultados de asumir los datos como producto:
El resultado es la creación de equipos multifuncionales (perfiles técnicos y comerciales), que serán responsables de crear productos de datos que aporten soluciones a las necesidades de la empresa en general.
Infraestructura de datos como autoservicio
Las empresas deben contar con una infraestructura subyacente que aprovisione a los dominios de todo lo que necesiten para comenzar a crear sus productos de datos.
Los dominios no deberían tener que preocuparse por la complejidad de los servidores, los sistemas operativos, las redes, etc.
Asimismo, la infraestructura debe incluir atributos como el cifrado, el control de versiones de productos y esquema de datos, todo esto anclado a procesos automatizados.
La nube de datos es el método recomendado para sostener esta infraestructura de autoservicio.
Resultados de una infraestructura de datos como autoservicio:
Los equipos encargados de los dominios podrían dejar de lado las tareas higiénicas y centrarse en escalar soluciones y maximizar los beneficios (creación directa de valor).
Beneficios del Data Mesh
Abedrabbo detalla las múltiples transformaciones que se pueden generar cuando las empresas comienzan a ejecutar los principios del Data Mesh:
La responsabilidad y la autonomía de extremo a extremo crean una red de datos fluida y resistente
El Data Mesh elimina la dependencia de un equipo centralizado, tanto desde el lado del productor como del consumidor.
A su vez, al pensar en los datos como producto, los equipos asumen una responsabilidad de extremo a extremo, con foco en cada dominio específico.
Al avanzar en este sentido, el resultado es una red de nodos que producen y consumen datos. Cada unidad es responsable de mantener abierto y disponible el flujo de sus datos para los otros dominios.
Estas funcionalidades crean una web descentralizada y altamente escalable, capaz de maximizar la producción y el consumo de datos en toda la organización.
Los equipos tienen acceso a datos confiables, centrados en el cliente
Cuando los equipos de dominios son responsables de sus datos de principio a fin, las lagunas y los silos de datos desaparecen.
Los equipos se esfuerzan por garantizar que los datos producidos sean confiables y se adapten a las necesidades de sus consumidores. Asimismo, se aseguran de alinearlos con los estándares de gobernanza, exigidos centralmente, para que se mantengan siempre detectables y utilizables.
La entrega de datos es mucho más rápida y se reducen los desperdicios
El Data Mesh invierte los patrones de acceso a los datos: pone énfasis en empoderar a los usuarios para que consuman todos los datos que necesitan y, así, cubrir sus necesidades. De esta manera, se potencia la entrega de datos; se vuelve mucho más rápida y efectiva.
El Data Mesh promueve la creación de un Gobierno Federado, con el fin de eliminar los cuellos de botella que limitan el acceso a los datos.
Dado que los datos serán accesibles como autoservicio, se eliminan los tickets de asistencia y los tiempos de espera para el consumo de información.
Características del Data Mesh: enfoques exitosos
Ahora… ¿Cómo funcionan los modelos de Data Mesh? ¿Cuáles son los factores clave de su éxito?
En el ensayo Data Mesh, los autores David Jerrim, Director Senior en Teradata, y Martin Willcox, Vicepresidente de Tecnología de Teradata detallan seis características exitosas del Data Mesh:
- Áreas temáticas vs. Dominios.
La descomposición de problemas generales en modelos más pequeños no es una idea nueva en la ingeniería de software.
Es frecuente que las empresas opten por la descomposición de datos complejos por área temática; por ejemplo, ‘evento’, ‘acuerdo’ o ‘producto’. Si bien este enfoque puede simplificar la reutilización de datos, en la mayoría de los casos origina largas discusiones para determinar los «elementos comunes» que engloblen los datos que se van a compartir y usar.
Por lo tanto, puede ser más efectivo descomponer los datos en dominios que estén alineados con los procesos comerciales de la empresa; de esta manera, cada dominio podría implementar las áreas temáticas aplicables a sus propias actividades.
- Separar los esquemas por dominio para proporcionar agilidad.
Una de las principales ventajas de adoptar el diseño domain-driven es la agilidad.
Para la implementación de arquitecturas basadas en Data Mesh, los especialistas recomiendan crear esquemas separados para cada dominio.
La responsabilidad de la administración de los datos y su modelado recae en los usuarios comerciales; ellos se encargarán de cada dominio específico en construcción.
Los esquemas domain-driven, por su parte, proporcionan una colección de productos de datos alineados con las áreas comerciales.
- Integración entre dominios.
Los datos de negocio se pueden optimizar en el contexto de un solo dominio. Sin embargo, muchas oportunidades de optimización de procesos comerciales requieren que los datos se combinen a través de límites geográficos y funcionales.
Cuando estos requerimientos se cumplen, se genera una inteligencia analítica capaz de proveer un calor desproporcionadamente alto al negocio.
No obstante, para que estos procesos se hagan realidad, las organizaciones deben tener una estrategia explícita que canalice el intercambio entre dominios.
¿Qué se necesita para generar una estrategia de intercambio entre dominios?
- Comprender, definir y hacer cumplir el conjunto mínimo de relaciones PK/FK requeridas. De esta manera, se pueden unir y comparar datos en diferentes dominios.
- Definir los metadatos comerciales, técnicos y operativos apropiados que permitan descubrir y reutilizar datos.
- Gestionar adecuadamente los datos, con el fin de garantizar que los atributos críticos se reutilicen y compartan con frecuencia en múltiples dominios.
- Desarrollar una política y un marco de control de acceso basado en roles, que garantice la disponibilidad y el uso de los datos.
- Soporte para productos de datos empresariales.
Los productos de datos empresariales presentan una vista multidominio.
Este atributo contribuye con la optimización de los procesos comerciales de extremo a extremo, tales como el cálculo de costo cliente, la previsión basada en la demanda y la planificación de redes.
Estos productos de datos suelen ser multifuncionales; requieren la adición de múltiples fuentes de datos y, a menudo, tienen valor en múltiples casos de uso y aplicaciones.
Por lo tanto, son propicios para ser reutilizados con frecuencia en varios dominios.
- Supertipos y subtipos.
Para entregar productos de datos empresariales exitosos, es necesario que los equipos de dominio involucrados puedan combinar y agregar datos de manera confiable en múltiples dominios.
Un enfoque para lograr esto sería crear un producto de datos empresariales de cuenta «Supertype» que se complete a través de todos los dominios.
Este producto de datos contendría atributos comunes en todos los dominios.
Luego, cada dominio administraría su propio producto de datos de cuenta de subtipo con atributos adicionales específicos.
Este enfoque impulsa un grado importante de consistencia entre los dominios, ya que se aplican claves que respalden la unión a la tabla de supertipos; asimismo, se asegura de ser lo suficientemente flexible para que los dominios de áreas comerciales amplíen sus productos de datos de subtipos, según sea necesario.
- Buen gobierno y uso de estándares correctos.
Cuando se habla de Data Mesh, una de las preguntas más comunes es la relacionada a cuán flexible debe ser el gobierno de datos centralizado.
La transformación digital y las iniciativas comerciales modernas están incrementando la necesidad de más integraciones entre dominios.
Desarrollar una visión interfuncional coherente de las operaciones requiere que los datos estén conectados tanto técnica como semánticamente.
La consistencia en la implementación, a través de los dominios, no se da espontáneamente; requiere de un enfoque coordinado por el negocio, de cara al gobierno de datos.
Asimismo, se requiere de experiencia técnica para aprovechar con éxito las herramientas de gestión de datos e implementar, de manera efectiva, la gobernanza de datos entre dominios.
Cada dominio necesitará soporte para desarrollar procesos de calidad, diseño de estructuras y reconciliación de datos, sumados a otros elementos de la arquitectura.
El objetivo es que los dominios no solo funcionen para casos de uso a corto plazo, sino que impulsen la escalabilidad de las soluciones analíticas.
Para subirse a esta ola de innovación analítica, se requiere de una capacitación especializada y mucha experiencia.
El Data Mesh impulsado por Snowflake
Uno de los principios clave del Data Mesh es la creación de una infraestructura de autoservicio.
La premisa es clara: los equipos de dominio deben contar con los recursos y las tecnologías necesarias que les permitan respaldar cada etapa del ciclo de vida de sus productos de datos: acceso, procesamiento, preparación, análisis, creación de modelos, entrega de productos, entre otros.
La tecnología que escoja la organización debe proporcionar un motor de rendimiento elástico, de modo que los equipos de dominio puedan impulsar canalizaciones a gran escala, exploración ad hoc, informes de BI, ingeniería de características, aplicaciones interactivas y mucho más.
Estos atributos simplifican las arquitecturas, sin sacrificar la velocidad o la usabilidad de la misma.
Independientemente de si los equipos trabajan en SQL o código (como Java, Scala o Python), el motor de rendimiento debe admitir todas las posibilidades.
Además, si la plataforma provee escalabilidad elástica y procesamiento aislado de varios clústeres, cada equipo de dominio obtendrá acceso a los recursos dedicados que necesita sin afectar el rendimiento o la concurrencia de otros equipos.
Estas capacidades podrían acelerar la transición hacia una arquitectura descentralizada, pero bien gobernada.
Por lo tanto, los equipos de dominio necesitan una plataforma capaz de ingerir grandes cantidades de datos, en múltiples formatos.
La plataforma debe estar abierta para consumir y proporcionar datos, desde y hacia otros dominios, al mismo tiempo.
Pensando en estas exigencias, Snowflake se ha proyectado como una de las tecnologías cloud más innovadoras del mercado.
Snowflake es una plataforma que elimina los silos de datos y las complejidades a la hora de consumir datos. Su tecnología proporciona un rendimiento a escala y facilidad de uso, así como el intercambio y la colaboración de datos gobernados.
Snowflake es flexible y efectiva: admite tanto los estándares centralizados como la propiedad descentralizada necesaria para una implementación exitosa de Data Mesh.
Entre sus atributos se encuentran:
- Entrega de infraestructura de autoservicio como plataforma.
- Entrega de datos y propiedad impulsada por el dominio como un producto.
- Gobernanza federada.
A continuación, puedes revisar un caso de éxito real de una implementación de Data Mesh, apalancado con Snowflake:
Casos de estudio de Data Mesh
El Data Mesh es una realidad; miles de empresas lo están implementando, con el fin de transformar sus estrategias de datos.
En el ebook Enterprise Data Mesh: solutions, use cases and case studies, los autores cuentan distintos casos de éxito de implementaciones de Data Mesh.
En esta ocasión, queremos enfocarnos en 3 historias:
Data Mesh en Wells Fargo: Continuidad de datos
Wells Fargo es uno de los bancos más grandes del mundo y, desde hace años, ha estado invirtiendo fuertemente en su transformación digital, con base en los datos.
En el núcleo de la estrategia de datos de Wells Fargo radica una necesidad: garantizar la continuidad de la operación de los datos en un 100%.
Los equipos de Wells Fargo usan microservicios GoldenGate para este tipo de casos de uso. Por lo tanto, la combinación de datos operativos con análisis y lagos de datos simplifica la arquitectura de datos, puesto que reduce la cantidad de «saltos» que los datos deben dar antes de estar disponibles para el análisis.
Mediante la implementación de Data Mesh, los equipos de Wells Fargo se aseguran de reducir la fricción y los desperdicios de recursos, a la hora de unir los datos operativos con los analíticos.
Data Mesh en Netflix: Modernización de aplicaciones
Netflix ha sido una de las primeras empresas en el mundo en implementar Data Mesh.
La empresa se apoyó en Data Mesh para realizar la migración de sus aplicaciones operativas a la nube, sin interrumpir su servicio.
El enfoque de Netflix incluía una arquitectura distribuida y registros de datos basados en eventos.
La arquitectura de destino era una aplicación moderna basada en microservicios, y el enfoque de migración en tiempo real canalizó una transición gradual a nuevas plataformas (infraestructura y bases de datos), sin ningún tiempo de inactividad.
Este es un buen ejemplo de Data Mesh, con enfoque operativo.
Data Mesh en Paypal: Patrones de microservicios
PayPal utiliza una arquitectura de microservicios moderna (distribuida).
Su plataforma necesita procesar, con un 100% de acierto y eficiencia, transacciones que se generan de forma asíncrona entre servicios.
Por tal razón, han realizado una implementación de Data Mesh para descentralizar las transacciones, sin generar pérdida o corrupciones en los datos.
¿Dónde aprender sobre Data Mesh?
El Data Mesh sigue siendo un concepto muy nuevo en la industria de la tecnología.
Pero si deseas conocer más sobre sus características y posibilidades de implementación, te invitamos a revisar los siguientes materiales:
Libro principal sobre Data Mesh
En marzo de 2022, Zhamak Dehghani, creadora del concepto de Data Mesh, publicó el libro Data Mesh: Delivering Data-Driven Value at Scale.
Actualmente, este libro se considera la biblia del Data Mesh.
Puedes leer un avance aquí.
Webinars sobre Data Mesh
Si prefieres los contenidos audiovisuales, te recomendamos este webinar introductorio sobre Data Mesh.
Se titula Data Mesh: Unlocking Data Value in the Enterprise.
Ponentes:
Arif Wider, profesor de Ingeniería de Software en la Universidad de Ciencias Aplicadas de Berlín.
Emily Gorcensk, Gerente de Datos en Thoughtworks Germany.
Puedes ver el webinar aquí.
Tutoriales sobre Data Mesh
Zhamak Dehghani lidera un programa de 4 webinars en los que detalla los principios del Data Mesh. Asimismo, comparte ejemplos de casos de uso e implementación.
Puedes ver la serie de webinars aquí.
Conclusiones sobre el Data Mesh
Con su enfoque en la descentralización, el Data Mesh instaura un nuevo paradigma en el desarrollo de plataformas y productos de datos.
Los plazos en el desarrollo de productos de datos complejos pueden reducirse de meses a semanas cuando el Data Mesh se combina con metodologías ágiles e incrementales, procesos eficientes de DevOps y herramientas de automatización.
Los datos son más valiosos cuando se alinean y combinan todos los dominios. Los modelos de gobernanza flexibles proporcionan la interoperabilidad necesaria para optimizar los procesos comerciales de extremo a extremo.
Esta facultad equivale a una estrategia de reutilización, porque garantiza que los productos de datos de dominio existentes se aprovechen en la creación de productos de datos agregados.
De esta manera, la escalabilidad se potencia y, con ella, el valor, el retorno y los beneficios.
Referencias bibliográficas
Abedrabbo, Tareq. (2022). Why The Data Mesh Is Key To Unleashing True Business Value. Recuperado de www.mesh-ai.com
Dehghani Zhamak. (2019) How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh. Recuperado de www.martinfowler.com
Empower Data Teams with a Data Mesh Built on Snowflake. (2021). Recuperado de www.snowflake.com
Enterprise Data Mesh: solutions, use cases and case studies. (2021). Recuperado de www.oracle.com
Jerrim, David y Willcox, Martin (2021). Data Mesh. Recuperado de www.teradata.com