Contenido:
¿Debería implementar una malla de datos para su organización? Pequeño cuestionario al finalizar el artículo
¿Qué es un lago de datos (DataLake)?
Antes de que podamos analizar la malla de datos y cómo se compara este nuevo paradigma arquitectónico, echemos un vistazo más profundo al lago de datos, qué es y cómo sirve a los equipos de datos modernos.
Un lago de datos es un repositorio de datos que proporciona almacenamiento y procesamiento para datos estructurados y no estructurados, a menudo para aprendizaje automático, transmisión o ciencia de datos. Permiten a las organizaciones ingerir y administrar grandes volúmenes de datos en una solución de almacenamiento agregada cuando es posible que no estén completamente seguras de cómo usarán esos datos en el futuro, ya sea para inteligencia empresarial o productos de datos.
Los lagos de datos ofrecen mayor flexibilidad que la mayoría de las soluciones de almacenamiento, pero a menudo a costa de la calidad y la capacidad de consulta, lo que limita el acceso a información rápida.
Históricamente, los lagos de datos tienden a ser preferibles para las empresas con grandes volúmenes de datos, ciencia de datos y desarrollo de capacitación en IA y ML, respaldados por un equipo saludable de ingenieros de datos . Entonces, ¿qué es una malla de datos y qué la diferencia de un lago de datos?
Malla de datos (DataMesh) vs lago de datos (DataLake): ¿cuál es la diferencia?
Si un lago de datos es un enfoque de la arquitectura de datos, una malla de datos es su opuesto filosófico. De manera similar a la aparición de los microservicios para la ingeniería de software, la malla de datos es una transición que se aleja de las estructuras monolíticas y se encamina hacia la flexibilidad, la escalabilidad y la accesibilidad.
Entonces, ¿qué es una malla de datos y qué es un lago de datos? Conceptualizada por primera vez por el consultor de ThoughtWorks Zhamak Dehghani, una malla de datos es una arquitectura de plataforma de datos que adopta la ubicuidad de los datos organizacionales al implementar un enfoque de autoservicio orientado al dominio para la gestión de datos, mientras que un lago de datos es una solución de almacenamiento que prioriza el almacenamiento de grandes cantidades de datos no estructurados para transformarlos más tarde para su consumo. Una malla de datos puede aprovechar un lago de datos como su almacén de datos central, pero no es en sí misma una arquitectura de datos completa que pueda dictar cómo se gestionarán esos datos.
La malla de datos toma prestado de la teoría de diseño impulsado por el dominio de Eric Evans , que es un paradigma de desarrollo de software que combina la estructura y el lenguaje del código con su dominio empresarial correspondiente.
A diferencia de las infraestructuras de datos monolíticas de antaño, que agrupaban el almacenamiento y la producción en un lago de datos centralizado, una malla de datos admite datos distribuidos . La arquitectura de malla de datos se basa en consumidores de datos específicos de cada dominio para optimizar los productos de datos de su dominio (encargando a cada propietario de dominio la responsabilidad de administrar sus propios canales de datos en función de sus casos de uso únicos) y aprovechando una capa de interoperabilidad universal que aplica la misma sintaxis y los mismos estándares de datos para unirlos todos.
Así es como se vería conceptualmente esa malla de datos:
Una arquitectura de malla de datos se compone de tres componentes: fuentes de datos, infraestructura de datos y canales de datos orientados al dominio administrados por propietarios funcionales.
3 diferencias clave
Las diferencias clave entre una malla de datos y un lago de datos se pueden resumir de esta manera:
● En una arquitectura de lago de datos, el equipo de datos es propietario de todas las canalizaciones, mientras que en una arquitectura de malla de datos, los propietarios del dominio administran sus propias canalizaciones directamente.
● Una arquitectura de malla de datos facilita el uso de datos de autoservicio, mientras que una arquitectura de lago de datos no lo hace.
● Una malla de datos requiere estándares de datos más estrictos, incluida la alineación en formato, campos de metadatos, capacidad de descubrimiento y gobernanza.
Ahora, veamos cada uno con un poco más de detalle.
¿Es una malla de datos mejor que un lago de datos?
En el gran debate entre malla de datos y lago de datos, es importante comprender las diferencias en la metodología antes de que podamos entender qué enfoque podría ser el adecuado para nuestros equipos de datos.
Hasta hace poco, la mayoría de las empresas ni siquiera habían adoptado un lago de datos, y mucho menos una malla de datos. En cambio, las empresas aprovechaban un único almacén de datos para impulsar su movimiento de datos. Esa única solución se conectaba a una gran variedad de herramientas de inteligencia empresarial en función de las necesidades de la organización. Si bien era necesaria en ese momento, esta filosofía arquitectónica también creaba una deuda técnica significativa, lo que suponía una presión indebida para el pequeño grupo de especialistas encargado de construirla y mantenerla.
Ahí es donde entró en juego el lago de datos. El lago de datos comenzó a ganar terreno gracias a su capacidad de ofrecer datos en tiempo real y procesamiento de flujo sin aumentar la carga de los equipos de datos. Con un lago de datos, los datos se podían ingerir, enriquecer, transformar y distribuir desde una plataforma centralizada con una deuda técnica relativamente limitada para la solución en sí. Pero hoy, incluso el enfoque del lago de datos ha comenzado a resultar insuficiente para algunos equipos de datos. Si bien una canalización ETL central ciertamente puede reducir la deuda técnica, también les da a los equipos menos control a medida que aumenta el volumen de datos. Y a medida que crece la adopción de datos distribuidos en las organizaciones modernas, el aumento de los casos de uso también aumenta la presión sobre las plataformas centralizadas y los equipos de datos responsables de ellas.
La malla de datos puede ofrecer una solución.
Si bien la idea de una malla de datos puede parecer contradictoria a primera vista con la de un lago de datos, en realidad puede ofrecer lo mejor de ambos mundos. La arquitectura de datos orientada a dominios se basa en una base de datos centralizada, como un lago de datos distribuido, como motor de la plataforma de datos, pero depende de dominios individuales (o áreas de negocios) para administrar los canales. Este enfoque permite a los equipos limitar la deuda tecnológica y, al mismo tiempo, promover un movimiento de datos ágil para las empresas que utilizan datos distribuidos.
A diferencia de un único lago de datos con una canalización ETL centralizada, una malla de datos promueve la autonomía porque facilita la experimentación sin aumentar la tensión en el equipo de datos a medida que esas necesidades escalan.
Pero el hecho de que la malla de datos sea innovadora no significa que sea el enfoque adecuado para todas las organizaciones. Entonces, ¿cómo saber si una malla de datos es adecuada para la arquitectura de su plataforma? Echemos un vistazo a algunas de las diferencias entre una malla de datos y un lago de datos.
Conductos y propietarios de datos
Históricamente, la pregunta de quién es el propietario de los datos ha sido bastante sencilla de responder, en particular en lo que respecta a un lago de datos. Cuando se agregan datos no estructurados en un lago de datos, los ingenieros de datos con la experiencia necesaria en SQL son los encargados de crear y gestionar esos procesos de ETL. Bastante sencillo, ¿verdad? Pero, aunque sin duda se trata de una forma sencilla de responder a la pregunta sobre la propiedad de los datos, ¿es la mejor manera de hacerlo? Es el momento de debatir entre malla de datos y lago de datos.
A diferencia de un lago de datos centralizado, una malla de datos une la propiedad de los datos en cada dominio. Estos propietarios de datos de dominio son responsables de administrar sus datos como si fueran un producto propio, lo que facilita la comunicación de datos distribuidos entre ubicaciones según sea necesario.
En el ejemplo de una malla de datos, el equipo de datos se vuelve responsable de administrar la infraestructura en lugar de los datos en sí, lo que brinda a los líderes del dominio herramientas de autoservicio accesibles para administrar la ingesta, la limpieza y la agregación del ámbito de datos respectivo de su dominio para generar activos para aplicaciones de inteligencia empresarial y productos de datos.
Una vez que un dominio determinado ha convertido un conjunto de datos en un producto, los propietarios del dominio pueden aprovechar esos datos para todo, desde análisis hasta necesidades operativas.
Consumo de datos (autoservicio)
Ser autoservicio o no serlo: esa es la pregunta que debemos responder cuando consideramos una malla de datos frente a un lago de datos. Mientras que un lago de datos depende del equipo de datos para poner en funcionamiento y entregar datos a los equipos funcionales, una malla de datos permite a los usuarios abstraerse de la complejidad técnica y centrarse en aprovechar los datos para sus casos de uso individuales.
Incluso se podría llegar a decir que el autoservicio es el objetivo de una malla de datos: facilitar productos de datos rápidos y ágiles para los usuarios posteriores. Pero si una malla de datos fuera sencilla, todos los equipos de datos ya tendrían una, y una malla de datos ciertamente no está exenta de desafíos.
Una de las principales preocupaciones de la malla de datos frente al lago de datos (y del diseño orientado al dominio en general) es la duplicación de esfuerzos para mantener los canales y la infraestructura por parte de cada dominio funcional. Pero la clave está en una infraestructura independiente del dominio. Al utilizar herramientas accesibles basadas en la nube en una única plataforma central para los canales, el almacenamiento y la transmisión, los equipos de datos pueden crear un motor de autoservicio que esté mantenido y protegido por un único equipo de datos.
Si bien el equipo de datos es responsable del motor de consumo, cada dominio puede ser individualmente responsable de aprovechar ese motor para sus propios casos de uso, ofreciendo el soporte para autogestionar fácilmente los datos, así como la autonomía para poseer el proceso de desarrollo de la canalización sin depender únicamente de la disponibilidad de un equipo de ingeniería sobrecargado.
Colaboración y estándares de datos
Como gran parte de lo que hemos discutido hasta ahora, la gobernanza de datos es relativamente sencilla para la arquitectura de plataforma de lago de datos tradicional, si bien no es la más útil. En el caso de un lago de datos en comparación con una malla de datos, la gobernanza y el intercambio de datos se gestionan a través de un único guardián: el equipo de datos. No es necesario compartir los estándares y las responsabilidades entre los equipos porque todas las necesidades de datos son atendidas y satisfechas por los ingenieros de datos del personal según sea necesario.
Pero la innovación exige sacrificios. Y en lo que respecta a la gobernanza, una malla de datos requiere un enfoque más personalizado. Es inevitable que algunos datos (tanto fuentes sin procesar como conjuntos de datos depurados, transformados y distribuidos) sean valiosos para más de un dominio. Para implementar una malla de datos exitosa, cada dominio debe adherirse a un conjunto universal de estándares de datos que puedan respaldar una colaboración eficaz entre dominios.
Entre otras cosas, una malla de datos requiere una alineación en cuanto a formato, campos de metadatos, capacidad de descubrimiento y gobernanza. Y, al igual que los microservicios, cada dominio de datos también deberá acordar acuerdos de nivel de servicio y prácticas de calidad para proteger a los consumidores posteriores.
Tejido de datos vs malla de datos vs lago de datos
Hasta hace poco, el debate se ha centrado principalmente en las arquitecturas de data mesh y data lake (lo que probablemente resulte bastante obvio por el título), pero siempre se puede confiar en que el gran campo de los datos nos sorprenderá. Mientras que un data lake representa la centralización de la gestión de datos y la data mesh representa su descentralización, la estructura de datos se sitúa en algún punto intermedio al abogar por una gestión centralizada de los datos pero un acceso democratizado . Al igual que una malla de datos, una estructura de datos no es una tecnología independiente, pero depende de una variedad de tecnologías específicas para tener éxito. La estructura de datos es una arquitectura de gestión de datos que aprovecha una capa de datos integrada sobre los datos subyacentes para dotar a los líderes empresariales de análisis en tiempo real y conocimientos basados en datos. El mayor beneficio de una estructura de datos sobre una malla de datos es su capacidad para gestionar grandes cantidades de datos distribuidos no estructurados. Para los equipos que ya aprovechan un data lake, la estructura de datos puede ser una excelente manera de incorporar el autoservicio a su organización al actuar como tejido conectivo en esos puntos de contacto.
No olvide la observabilidad de los datos
Por más emocionante que sea la malla de datos para los equipos de datos modernos, el debate entre malla de datos y lago de datos no significará nada a menos que la calidad de los datos también sea una prioridad.
La autonomía y la democratización siempre introducirán nuevos riesgos para una organización; lo mismo ocurre con su plataforma de datos. Si bien los ingenieros de datos pueden gestionar algunos movimientos de calidad de datos de forma interna en una arquitectura de lago de datos tradicional, esa idea se desvanece con una malla de datos.
Ningún dominio puede ser verdaderamente dueño de sus datos si no es dueño también de la calidad de los mismos. Una buena malla de datos exige una observabilidad de datos escalable y de autoservicio que permita a los propietarios de dominios confiar y mantener la integridad de la salud de sus datos de forma autónoma.
El paradigma de la malla de datos prescribe tener una forma estandarizada, escalable y accesible para que los dominios individuales respondan las siguientes preguntas:
● ¿Mis datos están actualizados?
● ¿Mis datos están dañados?
● ¿Cómo puedo realizar el seguimiento de los cambios del esquema?
● ¿Cuáles son las dependencias ascendentes y descendentes de mis pipelines?
La observabilidad de los datos permite un monitoreo de la calidad de los datos automatizado, de autoservicio y con poco uso de recursos computacionales para los propietarios de dominios, lo que hace que la confiabilidad de los datos sea accesible para los usuarios de los mismos.
¿Debería implementar una malla de datos para su organización?
Si bien la implementación de una malla de datos en lugar de un lago de datos ofrece algunos beneficios muy obvios (y atractivos), tampoco está exenta de desafíos. Por lo tanto, antes de comenzar su recorrido hacia la malla de datos, es importante considerar si una malla de datos es adecuada para su equipo. Una malla de datos es mejor para las organizaciones distribuidas donde los datos son un componente clave de las operaciones multifuncionales.
Estas organizaciones tienden a aprovechar grandes volúmenes de fuentes de datos y requieren una experimentación más rápida con esos datos como un componente clave de sus operaciones comerciales. Los productores de datos desconectados, los consumidores de datos en aumento y los equipos de datos atrasados son señales de que vale la pena explorar una malla de datos.
Consulta esta sencilla calculadora a continuación para ver si invertir en una malla de datos podría ser adecuado para tu organización.
Simplemente responde cada pregunta con un número (1 al 10) y luego suma las respuestas para obtener el total, o su puntaje de malla de datos.
● Cuellos de botella en la ingeniería de datos. ¿Con qué frecuencia el equipo de ingeniería de datos es un cuello de botella para la implementación de nuevos productos de datos en una escala del 1 al 10, donde 1 es “nunca” y 10 es “siempre”?
● Gobernanza de datos. ¿Qué grado de prioridad tiene la gobernanza de datos para su organización en una escala del 1 al 10, siendo 1 “no me importa nada” y 10 “no me deja dormir toda la noche”?
¿Obtuvo una puntuación superior a 10? Es probable que su organización se beneficie de la implementación de algunas prácticas recomendadas de malla de datos , pero es probable que aún le quede un poco más lejos la implementación de una malla de datos completa.
Comments