Si observamos este flujo general de datos en una organización que utiliza una arquitectura de datos centralizada, nos damos cuenta de que existen 3 puntos de contacto para los datos:
- Productores de datos
- Equipo de datos centrales
- Datos del consumidor
Ahora hagámonos algunas preguntas para empezar:
- ¿Quién gestiona el almacén de datos?
- ¿Qué equipo responde a las solicitudes de datos?
- ¿Qué equipo es responsable de garantizar la calidad de los datos?
- ¿Qué equipo se espera que sea una PYME de datos?
Cuando hice estas preguntas a un grupo de personas, obtuve una respuesta común en todas las preguntas (junto con otras): opción B, el Equipo de datos centrales.
Entonces podemos concluir que el equipo de datos central necesita:
- Gestionar el almacén de datos.
- Atender solicitudes de datos
- Garantizar la calidad de los datos
- Conviértete en una PYME de datos en el almacén de datos
Y la lista continúa.
Entonces, ¿qué se perdió?
A medida que una empresa sigue creciendo, el equipo de datos central tiende a convertirse en un cuello de botella a la hora de obtener información útil a partir de los datos.
En última instancia, los equipos de datos centrales tienen una gran carga de conocimientos y una presión de entrega cada vez mayor.
Esto construye mi caso para justificar la existencia de una arquitectura de datos descentralizada comúnmente conocida como Data Mesh.
Data Mesh es un tipo de arquitectura analítica, pero lo más importante es un modelo operativo que transfiere la propiedad de los datos analíticos a los equipos que más estrechamente identifican y poseen los datos: los productores y consumidores de datos.
Esta imagen muestra una vista de alto nivel de la arquitectura de malla de datos:
https://martinfowler.com/articles/data-monolith-to-mesh/data-mesh.png
No entraré en los principios o la arquitectura lógica de Data Mesh porque hay muchos artículos que le hacen justicia. Aquí están algunos de mis favoritos: