Data fabric vs data mesh vs data lake

La estrategia de datos ha sido durante mucho tiempo un elemento central del funcionamiento de las empresas, pero sigue siendo una carga e incluso un obstáculo para las empresas de hoy en día. Cada año, las empresas aprovechan cada vez más la tecnología, y cada una de estas tecnologías ofrece grandes oportunidades para recopilar nuevos datos y tomar medidas al respecto. La necesidad de una estrategia de datos completa y con visión de futuro es evidente. Al buscar estrategias de datos, se le presentan innumerables opciones, desde el almacén de datos y el lago de datos hasta el data fabric y la malla de datos. Entonces, ¿cómo saber qué opción funcionará mejor para su empresa y sus planes?

Históricamente, cuando se piensa en datos empresariales, nos vienen a la mente palabras como “ágil” y “flexible”. Nunca ha sido tan fácil que la recopilación de datos se descontrole, con tantos sistemas dispares disponibles para recopilar grandes cantidades de datos, agravado por la relativa facilidad para añadir nuevos sistemas a su ecosistema empresarial.

Estos problemas de escala conducen a una falta de cohesión de los datos y, por extensión, los procesos empresariales y la inteligencia empresarial que dependen de estos datos se verán afectados. Aquí es donde su estrategia de datos puede ayudar.

Las estrategias de datos sólidas pueden cambiar las reglas del juego de las empresas. Permiten gestionar de forma eficiente y eficaz los complejos entornos de datos de los sistemas modernos y heredados.

Su estrategia de datos sienta las bases sobre las que se construirán sus análisis y workflows durante años.

Para hacer un inventario de algunas de las opciones actuales de estrategia de datos, echemos un vistazo más de cerca al almacén de datos, el lago de datos, el data fabric y la malla de datos.

[ ¿Quiere saber más sobre cómo resolver sus problemas de silos de datos y acelerar la innovación? Consiga el libro electrónico: La ventaja del data fabric. ]

La forma más antigua (y aún popular) en que las empresas intentan consolidar los datos es extrayéndolos regularmente de cada sistema en el que se encuentran y cargándolos todos en un nuevo sistema. Este nuevo sistema sería el almacén o lago de datos, también conocido como data lake. ¿Cuál es la diferencia entre un almacén de datos y un lago de datos? Bueno, antes de que pueda entenderlo, ayuda saber la diferencia entre ETL (Extract, Transform, Load [Extraer, Transformar, Cargar]) y ELT (Extract, Load, Transform [Extraer, Cargar, Transformar]). Cada término describe un proceso de migración de datos y preparación de datos para su uso, así que definamos brevemente los tres pasos diferentes:

• Extraer: Los datos se extraen del sistema de origen.
• Transformar: Los datos se filtran, se deduplican y se preparan para el análisis.
• Cargar: Los datos se cargan en el sistema de destino, ya sea el almacén de datos o el lago de datos.

Tanto los almacenes de datos como los lagos de datos comienzan con la extracción, pero ahí es donde sus procesos divergen. Un almacén de datos aprovecha una estructura definida, por lo que las distintas entidades y relaciones de datos se codifican directamente en el almacén de datos. Por este motivo, los datos extraídos del sistema fuente deben transformarse y procesarse para que puedan cargarse en este formato estructurado. Una ventaja de esta estructura es que la activación de los datos es más ágil, ya que todo el trabajo ya se ha realizado para moldear los datos en un formato utilizable.

En cambio, un lago de datos se salta directamente la carga de los datos brutos del sistema fuente en el lago de datos. No es necesario definir la estructura o las relaciones entre los datos cuando se cargan. Esto hace que los lagos de datos sean intrínsecamente más flexibles, ya que hay mucho menos trabajo previo para introducir nuevos datos en el lago. Sin embargo, ese trabajo no ha desaparecido para siempre. Ahora es responsabilidad de los ingenieros de datos crear sofisticados conductos de datos que extraigan los datos inconexos del lago de datos y los transformen en un formato que pueda ser utilizado por la empresa.

Los almacenes de datos funcionan bien con información empresarial definida y ordenada. Normalmente, esta información está estructurada conceptualmente, por lo que el proyecto se convierte en la ingeniería de ese modelo conceptual en el almacén de datos, así como de los procesos que transforman y cargan los datos de origen.

Los lagos de datos funcionan mejor para albergar datos que pueden tener un potencial o unas relaciones empresariales poco claras o que se encuentran a una escala en la que no todos los datos serían útiles para el análisis. En esos casos, las empresas optan por introducir los datos en el lago de datos y ponerlos a disposición de los ingenieros de datos para que construyan más tarde una canalización que pueda producir un formato utilizable para un caso de uso determinado.

Ambas soluciones plantean varios retos. Ambas introducen una sobrecarga operativa con desarrollo, mantenimiento y conservación añadidos. Puede que hayamos sacado los datos de los sistemas aislados, pero para ello hemos tenido que diseñar estructuras de datos y transformaciones para almacenar los datos de forma ordenada. O, alternativamente, hemos tenido que diseñar sofisticados conductos de datos para tomar datos poco estructurados y procesarlos en un formato utilizable.

Otro riesgo de esta estrategia es que introduce un nuevo sistema de fuente de verdad que se abstrae de la fuente original de datos mediante una compleja lógica de transformación. Esto puede provocar riesgos para la integridad de los datos.

Por último, con los almacenes y lagos de datos, normalmente hay que renunciar al acceso a datos en tiempo real, dada la complejidad de transformar y transferir los datos. A medida que amplíe su empresa y sus sistemas, la complejidad, la deuda técnica y el riesgo de fracaso que plantean estas estrategias de datos se convertirán en un problema cada vez mayor.

En lugar de extraer los datos de los sistemas de origen y almacenarlos en otro lugar, ¿por qué no conectar directamente con las fuentes de datos? Es más fácil decirlo que hacerlo. Sus sistemas ERP y CRM pueden tener un gran solapamiento conceptual, pero a menudo se apoyan en tecnologías diferentes y no tienen una forma nativa de conectar sus estructuras de datos.

En el pasado, las empresas apostaban por un único proveedor tecnológico solo para abordar esta brecha de datos conectados, lo que inevitablemente lleva a hacer ciertos sacrificios. Aunque los datos se encuentren en el mismo proveedor de sistemas, siguen sin poder conectarse a otros sistemas modernos o heredados de la empresa.

Aquí es donde estrategias como el data fabric (o tejido de datos) y la data mesh (malla de datos) entran en juego y aportan valor. El data fabric y la malla de datos son enfoques arquitectónicos que permiten conservar los datos en los sistemas de origen, acceder a ellos en tiempo real y conectarlos entre distintos sistemas. Ambas estrategias tienen similitudes, pero también diferencias importantes.

El concepto de malla de datos surgió con las recientes revoluciones en la arquitectura de software. El sector tiende a dividir los servicios monolíticos en microservicios independientes. Los microservicios pueden agilizar el desarrollo. Sin embargo, esto introdujo la necesidad de orquestar, gestionar y conectar información y acciones entre microservicios. Mediante la creación de integraciones API entre estos diferentes microservicios, podrían permanecer conectados y trabajar juntos. Ampliando este concepto a la empresa, sistemas enteros podrían integrarse entre sí para lograr una malla de datos empresariales.

El problema con el enfoque de malla de datos es doble. En primer lugar, se está cambiando un sofisticado trabajo de ingeniería de datos por un sofisticado trabajo de ingeniería de software. Para implantar y aprovechar estas API, hay que tener los conocimientos adecuados, la información correcta sobre cómo funcionan las integraciones y las herramientas adecuadas para cada integración. A pesar de la eficacia de la arquitectura de malla de datos, solo los especialistas pueden hacer uso de ella. En otras palabras, la malla de datos es un enfoque de alto código que requiere experiencia y tiempo por parte de los desarrolladores.

La segunda pega de la malla de datos tiene que ver con la gobernanza centralizada. Con los almacenes de datos y los lagos de datos, puede obtener una visión completa de su entorno de datos replicados en un solo sistema. Con una malla de datos, las integraciones API se distribuyen por los sistemas, por lo que solo se ven los patrones que la gente ya ha creado con la malla de datos.

El data fabric ofrece formas atractivas de superar estos dos retos.

Un data fabric incluye una capa de virtualización, un concepto que también puede ver referido como “almacén lógico de datos”. Esto significa que con un data fabric, los datos de sistemas dispares se virtualizan en una plataforma centralizada, completa con la capacidad de conectar, relacionar y ampliar los datos. También puede pensar en el data fabric como una capa de abstracción para gestionar sus datos. Un punto clave que hay que recordar sobre el uso del data fabric: los datos permanecen donde están; no salen de los sistemas de origen.

Con el data fabric, no necesitamos conectarnos directamente a las API call de sistema a sistema para acceder a los datos: las API se abstraen. Esta abstracción nos permite aprovechar los datos de distintos sistemas sin necesidad de saber cuál es el sistema de origen ni cómo conectarse a él. Los datos pueden estar en las instalaciones o en un servicio en la nube como AWS como parte de su estrategia de nube híbrida.

Mientras que la malla de datos requiere especialistas en software, el tejido de datos permite que cualquier persona de la línea de negocio de sus equipos trabaje con el modelado de datos, no solo los desarrolladores. Esto significa que los empleados no técnicos pueden utilizar herramientas de low-code para realizar ellos mismos el trabajo de modelado de datos, lo que aumenta la velocidad y la agilidad.

¿Qué hay de los retos de gobernanza? Como se ha señalado anteriormente, la malla de datos plantea retos relacionados con la observabilidad y el mantenimiento debido a su naturaleza distribuida. En cambio, el data fabric está centralizado. Como el data fabric mantiene todos los datos en un modelo de datos virtualizado, se obtiene una visión completa y unificada de todos los sistemas. Incluso si ciertos patrones no se han utilizado antes, relacionar los datos en el modelo virtualizado permite implementar nuevos modos de acceso a los datos de forma sencilla y gobernable.

He aquí una pista para hablar del data fabric con los demás: El término “data fabric” puede referirse tanto a la capa de la arquitectura en la que se produce la virtualización de datos como al conjunto de herramientas que se utilizan en ella.

El uso de una capa de virtualización de datos es un fuerte valor añadido por sí mismo. Pero este valor aumenta enormemente cuando une su modelo de datos virtualizado con sus aplicaciones empresariales en una plataforma de automatización de procesos con capacidades de low-code y seguridad a nivel de registro. Por ejemplo, mediante reglas de seguridad de low-code, puede hacer referencia a los datos de su CRM para imponer si se debe acceder a filas específicas de datos de su ERP. También puede calcular campos de datos personalizados, como los SLA, haciendo referencia a los datos de los clientes y los casos, aunque no se encuentren en el mismo sistema. Características como éstas le permiten maximizar su potencial empresarial sin renunciar a sus sistemas o tecnologías existentes. Este enfoque también aporta flexibilidad para el futuro.

Cuando se trata de sistemas empresariales, el cambio no solo es constante, sino que se acelera. A medida que las organizaciones aplican la transformación digital a cada vez más facetas de sus negocios, las estrategias tecnológicas que utilizan tendrán que ser más flexibles, escalables y fáciles de mantener que nunca. La agilidad y la velocidad son mandatos competitivos.

Mientras que los almacenes de datos, los lagos de datos y las mallas de datos han sido útiles en el pasado, el data fabric será lo que lleve a las empresas hacia el futuro. Al combinar datos virtualizados, aplicaciones empresariales y modelado de datos sin código en una única plataforma, las empresas podrán convertir su panorama tecnológico en un elemento diferenciador en lugar de una carga.