Autor: Benjamín Mánquez
Cada vez que se interpreta un ecosistema de Data Analytics, es llamado de distintas formas, Big Data, Business Intelligence, Data Science, Data Mesh o se basa en la tecnología el nombre que se le denomina a ese ecosistema Data Lake, Data Warehouse, Lake House, etc. En la experiencia, más que inscribir un nombre a una arquitectura lo primero y más importante es determinar qué problema se desea resolver dentro de un ámbito analítico y cuáles son las posibiidades de evolucionar este hábitat en el tiempo, ya que no todas las organizaciones deben resolver sus problemas de la misma forma, ni se encuentran en el mismo grado de madurez. Además, no porque una solución analítica sea exitosa en alguna compañía, obtendrá los mismos resultados en otra. Invito a interiorizarse, a través de este artículo, a todo aquel lector que esté inmerso en una industria y que sienta que es el momento de transformar la forma de cómo se ven los datos dentro de su organización, cómo se puede comenzar a mejorar la visión del entorno y conducir a una compañía Data Driven. Y por último, en qué es, que no es y qué problemas puede resolver en la industria una arquitectura Data Mesh. Profundizaremos no sólo la forma de entender como opera a nivel tecnológico, sino como el negocio, la comunicación entre áreas y la visión organizacional soporta este cambio de paradigma. El objetivo de este blog es compartir el conocimiento que nos ha transmitido la experiencia de proyectos de Analytics en distintas industrias tales como: Retail, financiera, educación, salud, entre otras.
¿Qué es Data Mesh?
Un Data Mesh es una arquitectura distribuida moderna de datos, que se orienta a no persistir en un único repositorio de datos (Arquitectura clásica Data Lake), velando porque los datos sean tratados como un producto y que los usuarios utilicen los datos con un enfoque de autoservicio. Cada unidad de negocio o usuario trabaja bajo su dominio de datos. El efecto que se busca es que sea colaborativo y abierto para un uso distribuido. Dentro de sus pilares fundamentales se encuentran:
● Orientado a dominios, generando autonomía en la organización. ● Infraestructura de datos de autoservicio, busca tener herramientas comunes en una arquitectura común. ● Gobierno federado, accediendo de forma segura y gobernada a los datos distribuidos.
¿Por qué Data Mesh es importante?
En la evolución del Big Data, del Data Analytics y de la manipulación de grandes volúmenes de datos, la industria se ha visto en la necesidad de agilizar los procesos de manipulación de datos, para que la información esté siempre disponible para quién la necesite. En organizaciones con múltiples fuentes (BBDD, APIs, archivos, streams, etc) se tiende cada vez a priorizar qué es realmente valioso para el negocio o cuál es el orden en el que voy a ir procesando mi información. Al tener sistemas distribuidos en Cloud y trabajar mediante dominios, se favorece al negocio a tener una visión transversal en diferentes nichos de negocio, así como también de forma individual dentro de un área en particular, ya que se potencia lo que realmente es importante para ellas, sin necesidad de tener que participar en mesas con distintos interlocutores que no están viendo el problema desde el mismo punto de vista y por lo mismo, velan por intereses distintos.
Se busca que el negocio sea independiente de la tecnología y del tratamiento principal de la información (limpieza, ordenamiento, perfilamiento) y que se enfoquen netamente en generar indicadores de negocio que aporten valor a su sector o al dominio de negocio en el que se encuentren inmersos, cambiando el foco a pensar en el negocio por sobre la tecnología y los procesos.
USO
Antes de comenzar a impartir una arquitectura de este tipo, es fundamental determinar el As Is, y comprender algunas aristas y objetivos de negocio que quera resolver, aunque en el futuro se puede seguir agregando dominios a medida el negocio lo vaya necesitando. Uno puede encontrarse en una etapa temprana de un arquitectura Lake House (vease) o en una avanzada, y en cualquier grado de madurez se puede complementar con esta visión de Data Mesh. Ejemplos de agrupaciones de negocio (dominios):
● Clientes: Base única de clientes, RRSS, Interacciones, experiencia de cliente. ● Administración y finanzas: Proveedores, cobros, presupuestos, auditorías. ● Canales: Internet, aplicaciones, telecomunicaciones.
En cada uno de estos dominios existen uno o más actores que son quiénes administran y gobiernan sus procesos (ETLs, Dashboards, KPIs, Datawarehouses, Sandboxes, ML) y trabajan la orientación del dato a su conveniencia (pudiendo extistir duplicidad en los dominios pero con orientación específica al negocio).
Uno de los beneficios que vemos que mayor ganancia entrega, es trabajar en canalizaciones distribuidas a través de una o muchas fuentes centralizadas (Data Lakes), ya que podemos evolucionar de una arquitectura más tradicional y poner en práctica el uso de dominios, para que en el futuro puedan compartir información entre ellos y de igual forma poder consumir desde uno o varios repositorios centralizados. Existen muchas formas de diversificar la arquitectura y comenzar a operar de esta forma. Se presentan dos arquitecturas a continuación, la primera con un enfoque Lake House tradicional y la segunda un Lake House orientado a dominios:
Enfoque Lake House tradicional
Enfoque Lake House orientado a dominios
Como se puede observar no hay muchas diferencias dentro de la arquitectura principal, seguimos trabajando bajo un esquema de gobierno, calidad, orquestación y automatización, pero el foco de negocio es el que cambia, presentando cambios hacia una arquitectura desacoplada enfocada en un segmento individual de negocio y siendo colaborativo hacia los otros dominios, pudiendo entregar y consumir información desde otras fuentes descentralizadas y/o centralizadas (tanto desde otro dominio como de uno o varios Lakes / Lake Houses diferentes).
Existen algunas arquitecturas que modifican los conceptos de los buckets con las capas RAW, Trusted y Refined, que desde la capa de Trusted ya están listos para ser utilizados para consumo.
Sugerencias para la construcción de una arquitectura Data Mesh
Lo primero es identificar que desea resolver y quiénes serán partícipes del proceso (unidades de negocio), que deben tener conocimiento al menos en manipulación de datos y reportería, ya que desde ahora el área de BI no será más la responsable de tener sus indicadores o proyecciones actualizadas. Luego, reconocer en qué tipo de arquitectura estás trabajando y por qué, recordar que una visión organizacional de Data Analytics soporta el objetivo, no el uso de la tecnología.
Construir el primer dominio y ver cómo este se soporta y se desacopla de la arquitectura centralizada, de igual forma comprender como puede ayudar en un futuro a otros dominios (visión colaborativa).
Tener presente el gobierno, que no esté centralizado, no significa que no tendrá control, auditoría ni procesos que soporten un uso adecuado de la plataforma, desde la ingesta hasta la explotación. Y por último replicar. Procesos y tecnologías AWS que utilizamos en nuestros pipelines son:
Gobierno: Lakeformation.
Calidad: Deequ (Librería AWS).
Trazabilidad: Dynamo, SNS, Lambda, entre otros.
Ingesta: Lambda, Glue, DMS, Kinesis, entre otros.
Almacenamiento: S3.
Tratamiento: Glue y lambdas (sobre PySpark y Python).
Orquestación: StepFunctions y EventBridge.
Explotación: Redshift y Athena.
Para terminar, si buscas lograr pertenecer a una empresa Data Driven y conseguir una forma de trabajo más ágil y colaborativa de los datos, debes enfocarte en qué es lo que se desea lograr y cuáles son los objetivos de negocio que se desean cumplir, para posteriormente asesorarse a través de un partner como ARKHO, que pueda apoyarlos y guiarlos en cómo llegar a alcanzarlos. ¿Qué esperas para convertir tu empresa en Data Driven?
Comments