Arquitectura de data mesh con AWS Lake Formation y AWS Glue

Por Nivas Shankar, Arquitecto de Soluciones Principal en Data de AWS,
Ian Meyers, Gerente Principal de Producto de AWS,
Zach Mitchell, Arquitecto de Soluciones Senior en BigData de AWS y
Roy Hasson, Gerente Principal de Producto de AWS

Organizaciones de todos los tamaños han reconocido que los datos son uno de los principales facilitadores para incrementar y mantener la innovación que a su vez genera valor para sus clientes y unidades de negocio. Estas están modernizando activamente las plataformas de datos tradicionales con tecnologías nativas de la nube que son altamente escalables, ricas en funcionalidades y económicas. A medida que se tomen decisiones empresariales basadas en datos, se puede ser ágil y productivo adoptando una mentalidad que ofrezca productos de datos de equipos especializados, en lugar de a través de una plataforma de gestión de datos centralizada que proporciona análisis generalizados.

En este artículo se describe un enfoque para implementar una arquitectura de data mesh utilizando servicios nativos de AWS que incluyen AWS Lake Formation y AWS Glue. Este enfoque permite a las líneas de negocio (LOBs) y a las unidades organizacionales operar de forma autónoma siendo dueños de sus productos de datos de punta a punta, mientras se proporciona descubrimiento centralizado de datos, gobierno y auditoría para la organización en general, con el fin de garantizar la privacidad y el cumplimiento de los datos.

Beneficios de un modelo de data mesh

Un modelo centralizado pretende simplificar la consecución de personal y su entrenamiento a través de la centralización de los datos y la experiencia técnica en un solo lugar con el fin de reducir la deuda técnica y los costos operativos mediante la administración de una única plataforma de datos. Los grupos de plataformas de datos, que suelen formar parte del equipo de TI, son divididos en equipos con base en las funciones técnicas de la plataforma a la que dan soporte. Por ejemplo, un equipo puede ser propietario de las tecnologías de ingestión utilizadas para recopilar datos de varias fuentes de datos administradas por otros equipos y LOBs. Otro equipo diferente puede ser propietario de flujos de datos en donde se escribe, depura, extrae, transforma y carga código (ETL), además de realizar la orquestación de la ejecución de los trabajos mientras se validan y corrigen los problemas de calidad de los datos y se garantiza el cumplimiento de los acuerdos de nivel de servicio relacionados al procesamiento de los mismos. Sin embargo, la gestión de datos a través de una plataforma de datos central puede crear desafíos de escalabilidad, propiedad y responsabilidad; pues los equipos centrales pueden no comprender las necesidades específicas de un dominio de datos, ya sea por tipos de datos y almacenamiento, seguridad, requisitos de catálogo de datos, o tecnologías específicas requeridas para procesamiento de datos.

Estos desafíos usualmente se pueden mitigar otorgando propiedad y autonomía al equipo propietario de los datos y permitiéndole crear productos de datos, en lugar de simplemente utilizar una plataforma de datos centralizada. Por ejemplo, los equipos de productos son responsables de garantizar que el inventario se actualice periódicamente con nuevos productos y cambios en los productos existentes, pues ellos son los expertos en el dominio de los datos de inventario de productos. Si se produce una discrepancia, son el único grupo que sabe cómo solucionarlo. Por lo tanto, están en mejores condiciones de implementar y operar una solución técnica para ingestar, procesar y producir el conjunto de datos de inventario de productos. Son dueños del flujo completo hasta el consumo de los datos: eligen la tecnología, operan con la mentalidad de datos como producto, aplican seguridad y auditoría, y proporcionan un mecanismo para exponer los datos a la organización que facilite su consumo. Esto reduce la fricción general del flujo de información en la organización, donde el productor es responsable de los datos que produce además de los acuerdos de nivel de servicio acordados con los consumidores.

Este paradigma de datos como producto es similar al modelo operativo de creación de servicios de Amazon. Los equipos de servicio crean sus servicios, exponen APIs con acuerdos de nivel de servicio específicos, operan sus servicios y manejan la experiencia completa del cliente. Esto es diferente del mundo en el que alguien construye el software y otro equipo realiza la operación. El modelo punta a punta nos ha permitido implementar de forma más rápida, eficiente y escalar rápidamente para satisfacer los casos de uso de los clientes, pues no estamos limitados por los equipos centralizados y su capacidad de escalar para satisfacer las demandas de los negocios. Cada servicio que construimos está basado en otros servicios que proporcionan los componentes básicos. La analogía en el mundo de los datos sería que los productores de los mismos tuvieran la implementación y el servicio de los productos de datos de punta a punta, utilizando las tecnologías que seleccionaron en función de sus necesidades específicas. En AWS, hemos hablado del modelo de organizaciones basadas en datos durante años, el cual consiste en productores y consumidores de datos. Este modelo es similar al utilizado por algunos de nuestros clientes y fue descrito con elocuencia recientemente por Zhamak Dehghani de Thoughtworks, quien acuñó el término data mesh en 2019.

Resumen de la solución

En esta publicación, demostraremos cómo la arquitectura de Lake House es ideal para ayudar a los equipos a crear dominios de datos; y cómo el enfoque de data mesh se puede usar para unir dichos dominios con el fin de permitir el intercambio de datos y la federación entre las unidades de negocio. Este enfoque permite una mayor autonomía y un ritmo de innovación más rápido, que se basa en una arquitectura y tecnología probadas que garantiza altos estándares de seguridad y gobernanza de los datos.

Los siguientes puntos son esenciales a la hora de considerar un diseño tipo data mesh:

Data mesh es un estándar para definir cómo las organizaciones pueden organizarse en torno a dominios de datos centrándose en proporcionar datos como producto. Sin embargo, puede que no sea el estándar adecuado para todos los clientes.
El enfoque y la arquitectura tipo Lake House proporcionan orientación técnica y soluciones para crear una plataforma de datos moderna en AWS.
El enfoque de Lake House con un lago de datos fundacional sirve como proyecto repetible para implementar dominios y productos de datos de forma escalable.
La forma en que se utilizan los servicios de analítica de AWS en un patrón de data mesh puede cambiar con el tiempo, pero sigue siendo consistente con las recomendaciones tecnológicas y las mejores prácticas de cada servicio.

Los siguientes son objetivos de diseño de un enfoque data mesh:

Datos como producto: Cada dominio de la organización tiene sus datos de extremo a extremo. Son responsables de crear, operar, servir y resolver cualquier problema que surja del uso de sus datos. La exactitud y la responsabilidad de los datos recaen en el propietario de los datos dentro del dominio.
Gobierno de datos federado: La gobernanza de datos garantiza que los datos estén seguros, sean precisos y no se utilicen de forma indebida. Su implementación técnica que incluye recopilación de linaje, validación de la calidad de datos, cifrado en reposo y en tránsito y despliegue de controles de acceso; puede gestionarse en cada uno de los dominios de datos. Sin embargo, el descubrimiento, la generación de informes y la auditoría de datos centralizados son necesarios para simplificar la búsqueda de datos por parte de los usuarios, además de la verificación de cumplimiento hecha por los auditores.
Acceso común: Los datos deben ser fácilmente consumibles por las personas en cuestión como analistas y científicos de datos, así como servicios de analítica y aprendizaje automático (ML) como Amazon Athena, Amazon Redshift y Amazon SageMaker. Para ello, los dominios de datos deben exponer un conjunto de interfaces que hacen que los datos sean consumibles y también auditables con controles de acceso adecuados.

Las siguientes son consideraciones sobre la experiencia del usuario:

Los equipos de datos poseen el ciclo de vida de la información, desde la aplicación que crea los datos originales hasta los sistemas de análisis que extraen y crean informes y predicciones empresariales. A lo largo de este ciclo de vida, son dueños del modelo de datos y determinan qué conjuntos de datos son adecuados para publicarlos a los consumidores.
Los productores exponen sus datos al resto de la organización registrándolos en un catálogo central. Pueden elegir qué compartir, durante cuánto tiempo y cómo los consumidores pueden interactuar con él. También son responsables de mantener los datos y garantizar que sean precisos y estén actualizados.
Los consumidores o usuarios individuales deben tener acceso a los datos a través de una interfaz compatible, como una API de datos, que pueda garantizar rendimiento consistente, trazabilidad y control de acceso.
Todos los activos de datos se pueden descubrir fácilmente desde un único catálogo de datos centralizado. Dicho catálogo contiene los conjuntos de datos registrados por los productores del dominio, incluyendo metadatos de apoyo como linaje, métricas de calidad, información de propiedad y contexto de negocio.
Todas las acciones realizadas con datos, patrones de uso, transformaciones y clasificaciones deben ser accesibles a través de una única ubicación centralizada. Los propietarios de los datos, administradores y auditores deben poder inspeccionar la postura de cumplimiento de datos de una organización desde una única ubicación.

Comencemos con un diseño de alto nivel basado en el patrón de data mesh. En el siguiente diagrama, hay una separación entre consumidores, productores y gobierno central para resaltar los aspectos claves discutidos anteriormente. Sin embargo, un dominio de datos puede representar a un consumidor de datos, a un productor de datos o a ambos.

El objetivo de este diseño es crear una base para construir plataformas de datos a escala, apoyando los objetivos de los productores y consumidores de datos con una gobernanza sólida y consistente. El enfoque de AWS para diseñar un data mesh identifica un conjunto de principios de diseño y servicios para facilitar las mejores prácticas recomendadas para crear plataformas de datos escalables, compartir datos de forma ubicua y permitir la analítica de autoservicio en AWS.

Al ampliar el diagrama anterior, proporcionamos detalles adicionales para mostrar cómo los servicios nativos de AWS apoyan a los productores, los consumidores y la gobernanza. Cada dominio de datos, ya sea productor, consumidor o ambos, es responsable de su propio stack de tecnología. Sin embargo, el uso de servicios nativos de analítica de AWS con la arquitectura de Lake House proporciona un blueprint repetible que su organización puede utilizar a medida que escala su proyecto de data mesh. Tener una base técnica consistente garantiza que los servicios estén bien integrados, que se incluyan funcionalidades esenciales y que se incorporen la escalabilidad, el rendimiento y los costos se mantengan bajos.

Dominio de datos: productor y consumidor

Un diseño de data mesh se organiza en torno a dominios de datos. Cada dominio de datos posee y opera varios productos de datos con su propio stack de datos y tecnología, que es independiente de los demás. Los dominios de datos pueden ser puramente productores, como un dominio financiero que produce solo datos de ventas e ingresos para dominios de consumidores, o un dominio de consumo, como un servicio de recomendación de productos que consume datos de otros dominios para crear recomendaciones de productos en un sitio de comercio electrónico. Además de compartir, un catálogo de datos centralizado puede proporcionar a los usuarios la capacidad de encontrar más rápidamente los conjuntos de datos disponibles y permitir a los propietarios de los datos asignar permisos de acceso y auditar el uso entre las unidades de negocio.

Un dominio de productor reside en una cuenta de AWS y utiliza buckets de Amazon Simple Storage Service (Amazon S3) para almacenar datos sin procesar y transformados. Mantiene su propio stack de ETL con AWS Glue para procesar y preparar los datos antes de catalogarlos en un catálogo de datos de Lake Formation en su propia cuenta. Del mismo modo, el dominio del consumidor incluye su propio conjunto de herramientas para realizar análisis y aprendizaje automático en una cuenta de AWS independiente. La cuenta central de gobernanza de datos se utiliza para compartir conjuntos de datos de forma segura entre productores y consumidores. Es importante tener en cuenta que los datos se comparten únicamente mediante la vinculación de los metadatos. Los datos no se copian en la cuenta central y la propiedad sigue siendo del productor. El catálogo central facilita a cualquier usuario la búsqueda de datos y la solicitud de acceso al propietario de los datos en una única ubicación. A continuación, pueden utilizar la herramienta que prefieran en su propio entorno para realizar análisis y aprendizaje automático de los datos.

El siguiente diagrama ilustra el flujo de trabajo de extremo a extremo.

El flujo de trabajo desde el productor hasta el consumidor incluye los siguientes pasos:

La ubicación de las fuentes de datos alojadas por el productor se crean en el catálogo de datos de AWS Glue del productor y se registran en Lake Formation.
Cuando un conjunto de datos se presenta como un producto, los productores crean entidades del Catálogo de datos de Lake Formation (base de datos, tabla, columnas, atributos) dentro de la cuenta de gobierno central. Esto facilita la búsqueda y el descubrimiento de catálogos entre los consumidores. Sin embargo, esto no otorga ningún permiso para catálogos o datos a las cuentas o consumidores pues estos deben ser otorgados por el productor.
El catálogo de datos central de Lake Formation comparte los recursos del catálogo de datos de vuelta con la cuenta del productor con los permisos necesarios a través de links de recursos de Lake Formation a metadata de bases de datos y tablas.
Los permisos de Lake Formation se conceden en la cuenta central a los usuarios con rol de productor (como el rol de ingeniero de datos) para administrar los cambios de esquema y realizar transformaciones de datos (cambiar, eliminar, actualizar) en el catálogo de datos central.
Los productores aceptan compartir los recursos con la cuenta de gobierno central para poder hacer cambios en el esquema más adelante.
Los cambios de datos realizados en la cuenta del productor se propagan automáticamente a la copia de gobierno central del catálogo.
Basado en una solicitud de acceso de un consumidor y en la necesidad de hacer visibles los datos en el catálogo de datos de AWS Glue del consumidor, el propietario de la cuenta central concede permisos de Lake Formation a una cuenta de consumidor basándose en el uso compartido directo de entidades, o en función de controles de acceso basados en etiquetas, que se pueden utilizar para administrar el acceso a través de controles tales como clasificación de datos, centro de costos o ambiente.
Lake Formation en la cuenta de consumidor puede establecer permisos de acceso sobre estos datos para que los usuarios locales los consuman. Usuarios de la cuenta de consumidor como analistas y científicos de datos, pueden consultar los datos compartidos mediante la herramienta que elijan tal como Athena o Amazon Redshift.

Construir productos de datos

Los productores de dominios de datos ingestan datos en sus respectivos buckets de S3 a través de un conjunto de canales que ellos administran, poseen y operan. Los productores son responsables de todo el ciclo de vida de los datos bajo su control y de trasladar los datos desde su versión cruda capturada desde las aplicaciones, a un formato adecuado para el consumo de terceros. AWS Glue es un servicio de integración y preparación de datos sin servidor que proporciona todos los componentes necesarios para desarrollar, automatizar y administrar flujos de datos a escala y de forma económica. Proporciona una interfaz fácil de usar que las organizaciones pueden utilizar para integrar rápidamente los dominios de datos.

Gobierno de datos centralizado

La cuenta de gobierno de datos centralizada almacena un catálogo de datos de todos los datos corporativos de todas las cuentas y proporciona características que permiten a los productores registrar y crear entradas de catálogo con AWS Glue desde todos sus buckets de S3. No hay datos (excepto logs) en esta cuenta. Lake Formation define de forma centralizada las políticas de seguridad, gobernanza y auditoría en un solo lugar, aplica esas políticas a los consumidores de aplicaciones de analítica y solo proporciona autorización y acceso por token de sesión a las fuentes de datos para el rol que solicita dicho acceso. Lake Formation también proporciona un control de acceso uniforme para el intercambio de datos en toda la empresa a través de recursos compartidos con supervisión y auditoría centralizadas.

Acceso común

Cada consumidor tiene acceso a los recursos compartidos de la cuenta de gobierno central en forma de enlaces de recursos. Estos están disponibles en el Lake Formation local y en el catálogo de datos de AWS Glue, lo que permite el acceso a bases de datos y tablas que pueden ser manejadas por los administradores en los consumidores. Una vez el acceso es otorgado, los consumidores pueden acceder a la cuenta y realizar diferentes acciones con los siguientes servicios:

Athena actúa como consumidor y realiza consultas sobre los datos registrados con Lake Formation. Lake Formation verifica que el principal del rol de AWS Identity and Access Management (IAM) del grupo de trabajo tenga los permisos de Lake Formation adecuados para la consulta en la base de datos, la tabla y ubicación de Amazon S3. Si el principal tiene acceso, Lake Formation envía credenciales temporales a Athena y se ejecuta la consulta. La autenticación se concede mediante roles o usuarios de IAM o identidades web federadas mediante SAML u OIDC. Para obtener más información, consulte Cómo Athena accede a los datos registrados con Lake Formation.
Amazon SageMaker Data Wrangler le permite seleccionar rápidamente datos de varias fuentes de datos, como Amazon S3, Athena, Amazon Redshift, Lake Formation y Amazon SageMaker Feature Store. También se puede escribir consultas para fuentes de datos e importar datos directamente en SageMaker desde distintos formatos de archivo como CSV, Parquet y tablas de base de datos. La autenticación se concede a través de roles de IAM en la cuenta de consumidor. Para obtener más información, consulte Preparación de datos para aprendizaje automático con Amazon SageMaker Data Wrangler.
Amazon Redshift Spectrum permite registrar esquemas externos de Lake Formation y proporciona una jerarquía de permisos para controlar el acceso a las bases de datos y tablas de Amazon Redshift en un catálogo de datos. Si el principal del consumidor tiene acceso, Lake Formation envía credenciales temporales a las tablas de Redshift Spectrum y se ejecuta la consulta. La autenticación se concede mediante roles o usuarios de IAM o identidades web federadas mediante SAML u OIDC. Para obtener más información, consulte Uso de Redshift Spectrum con AWS Lake Formation.
Amazon QuickSight a través de Athena se integra con los permisos de Lake Formation. Si se consulta datos con Athena, se puede utilizar Lake Formation para simplificar la seguridad y la conexión a los datos desde QuickSight. Lake Formation complementa el modelo de permisos de IAM al proporcionar su propio modelo de permisos que se aplica a los servicios de AWS Analytics y ML. La autenticación se concede mediante roles de IAM que son mapeados a permisos de usuario de QuickSight. Para obtener más información, consulte Autorizar conexiones a través de AWS Lake Formation.
Amazon EMR Studio y Amazon EMR notebooks permiten ejecutar SparkSQL en tablas de Lake Formation respaldadas por una autoridad SAML. A partir de Amazon EMR31.0, se puede lanzar clústeres que se integran con Lake Formation. La autenticación se concede mediante roles o usuarios de IAM o identidades web federadas mediante SAML u OIDC. Para obtener más información, consulte Integración de Amazon EMR con AWS Lake Formation.

Con este diseño, se puede conectar varias arquitecturas tipo lake house a una cuenta de gobierno centralizada que almacena todos los metadatos de cada entorno. El beneficio de este enfoque radica en que integra todos los metadatos y los almacena en un esquema de metamodelo al que se puede acceder fácilmente a través de los servicios de AWS desde varios consumidores. Se puede ampliar esta arquitectura para registrar nuevos catálogos de lagos de datos y compartir recursos entre cuentas de consumidores. El siguiente diagrama ilustra una arquitectura de data mesh multicuenta.

Conclusión

Un enfoque de data mesh proporciona un método mediante el cual las organizaciones pueden compartir datos entre unidades de negocio. Cada dominio es responsable de la ingestión, el procesamiento y el suministro de sus datos. Son propietarios de datos, expertos en dominios y responsables de la calidad y precisión de sus datos. Esto es similar a cómo los microservicios transforman un conjunto de recursos técnicos en un producto que otros microservicios pueden consumir. La implementación de una arquitectura tipo data mesh en AWS se simplifica mediante el uso de servicios administrados y sin servidor como AWS Glue, Lake Formation, Athena y Redshift Spectrum que proporciona una solución bien estructurada, de alto rendimiento, escalable y económica lista para integrar, preparar y entregar datos.

Un cliente que ha utilizado el enfoque de data mesh es JPMorgan Chase. Para obtener más información, consulte Cómo JPMorgan Chase creó una arquitectura de data mesh para generar valor y mejorar su plataforma de datos empresariales.

AWS Lake Formation ofrece la capacidad de implementar la gobernanza de datos en cada dominio de datos y en todos los dominios para garantizar que los datos se puedan descubrir fácilmente y sean seguros. Se realiza un seguimiento del linaje y se puede auditar el acceso. La arquitectura tipo Lake House proporciona los fundamentos ideales para un enfoque de data mesh y proporciona un patrón de diseño para aumentar la entrega de dominios de productores dentro de una organización. Cada dominio tiene la autonomía para elegir su propio stack tecnológico, pero se rige por un modelo de seguridad federado que se puede administrar de forma centralizada, lo cual implica buenas prácticas en cuanto a seguridad y cumplimiento normativo, a la vez que permite alta agilidad dentro del dominio.

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre el traductor

Diego Ortiz es Arquitecto de soluciones especialista en analítica en AWS.

Blog de Amazon Web Services (AWS)