Cree y entrene modelos de ML mediante una arquitectura de malla de datos en AWS: Parte 1

Las organizaciones de diversas industrias están utilizando inteligencia artificial (IA) y aprendizaje automático (ML) para resolver desafíos comerciales específicos de su industria. Por ejemplo, en la industria de servicios financieros, puede usar AI y ML para resolver desafíos relacionados con la detección de fraudes, la predicción del riesgo crediticio, el marketing directo y muchos otros.

Las grandes empresas a veces establecen un centro de excelencia (CoE) para abordar las necesidades de diferentes líneas de negocio (LoB) con análisis innovadores y proyectos de ML.

Para generar modelos de ML de alta calidad y rendimiento a escala, deben hacer lo siguiente:

• Proporcione una manera fácil de acceder a datos relevantes para su análisis y ML CoE
• Cree responsabilidad en los proveedores de datos de LoB individuales para compartir activos de datos seleccionados que sean detectables, comprensibles, interoperables y confiables

Esto puede reducir el tiempo de ciclo largo para convertir casos de uso de ML de experimento a producción y generar valor comercial en toda la organización.

Una arquitectura de malla de datos se esfuerza por resolver estos desafíos técnicos y organizacionales mediante la introducción de un enfoque sociotécnico descentralizado para compartir, acceder y administrar datos en entornos complejos y de gran escala, dentro o entre organizaciones. El patrón de diseño de malla de datos crea un modelo de intercambio de datos responsable que se alinea con el crecimiento organizacional para lograr el objetivo final de aumentar el retorno de las inversiones comerciales en los equipos, procesos y tecnología de datos.

En esta serie de dos partes, brindamos orientación sobre cómo las organizaciones pueden crear una arquitectura de datos moderna utilizando un patrón de diseño de malla de datos en AWS y habilitar un CoE de análisis y ML para crear y entrenar modelos de ML con datos en múltiples LoB. Utilizamos un ejemplo de una organización de servicios financieros para establecer el contexto y el caso de uso de esta serie.

En esta primera publicación, mostramos los procedimientos para configurar una arquitectura de malla de datos con varias cuentas de productores y consumidores de datos de AWS. Luego nos enfocamos en un producto de datos, que es propiedad de un LoB dentro de la organización financiera, y cómo se puede compartir en un entorno de red de datos para permitir que otros LoB consuman y usen este producto de datos. Esto está dirigido principalmente al administrador de datos, que es responsable de simplificar y estandarizar el proceso de intercambio de datos entre productores y consumidores de datos y garantizar el cumplimiento de las reglas de gobierno de datos.

En la segunda publicación, mostramos un ejemplo de cómo un CoE de análisis y ML puede consumir el producto de datos para un caso de uso de predicción de riesgos. Esto está dirigido principalmente a la persona científica de datos, que es responsable de utilizar activos de datos de toda la organización y de terceros para crear y entrenar modelos ML que extraen información comercial para mejorar la experiencia de los clientes de servicios financieros.

Descripción general de la malla de datos

La fundadora del patrón de malla de datos, Zhamak Dehghani en su libro Malla de datos que ofrece valor basado en datos a escala, definió cuatro principios hacia el objetivo de la malla de datos:

• Propiedad de dominio distribuida – Perseguir un cambio organizativo de la propiedad centralizada de los datos por parte de especialistas que ejecutan las tecnologías de la plataforma de datos a un modelo de propiedad de datos descentralizado, empujando la propiedad y la responsabilidad de los datos de vuelta a las LoB donde se producen (dominios alineados con la fuente) o se consumen ( dominios alineados con el consumo).
• Los datos como producto – Para impulsar la responsabilidad de compartir activos de datos seleccionados, de alta calidad, interoperables y seguros. Por lo tanto, los productores de datos de diferentes LoB son responsables de generar datos en forma consumible directamente en la fuente.
• Análisis de autoservicio – Para optimizar la experiencia de los usuarios de datos de análisis y ML para que puedan descubrir, acceder y usar productos de datos con sus herramientas preferidas. Además, para optimizar la experiencia de los proveedores de datos LoB para crear, implementar y mantener productos de datos a través de recetas y componentes y plantillas reutilizables.
• Gobierno computacional federado – Para federar y automatizar la toma de decisiones involucrada en la gestión y el control del acceso a los datos para estar al nivel de los propietarios de los datos de las diferentes LoB, que todavía está en línea con las políticas legales, de cumplimiento y de seguridad de la organización más amplia que, en última instancia, se aplican a través de la malla

AWS presentó su visión para construir una malla de datos sobre AWS en varias publicaciones:

• En primer lugar, nos centramos en la parte organizativa asociada con la propiedad distribuida de dominios y los datos como principios del producto. Los autores describieron la visión de alinear múltiples LOB en toda la organización hacia una estrategia de producto de datos que proporciona a los dominios alineados con el consumo herramientas para encontrar y obtener los datos que necesitan, al tiempo que garantiza el control necesario sobre el uso de esos datos mediante la introducción de responsabilidad por los dominios alineados con la fuente para proporcionar productos de datos listos para usarse directamente en la fuente. Para obtener más información, consulte Cómo JPMorgan Chase creó una arquitectura de malla de datos para impulsar un valor significativo para mejorar su plataforma de datos empresariales.
• Luego nos enfocamos en la parte técnica asociada con la creación de productos de datos, análisis de autoservicio y principios de gobierno computacional federado. Los autores describieron los servicios centrales de AWS que permiten a los dominios alineados con la fuente crear y compartir productos de datos, una amplia variedad de servicios que pueden permitir que los dominios alineados con el consumidor consuman productos de datos de diferentes maneras según sus herramientas preferidas y los casos de uso que utilizan. están trabajando para, y finalmente, los servicios de AWS que rigen el procedimiento de intercambio de datos al hacer cumplir las políticas de acceso a datos. Para obtener más información, consulte Diseñe una arquitectura de malla de datos con AWS Lake Formation y AWS Glue.
• También mostramos una solución para automatizar el descubrimiento de datos y el control de acceso a través de una interfaz de usuario de malla de datos centralizada. Para obtener más detalles, consulte Cree un flujo de trabajo para compartir datos con AWS Lake Formation para su red de datos.

Caso de uso de servicios financieros

Por lo general, las grandes organizaciones de servicios financieros tienen múltiples LoB, como banca de consumo, banca de inversión y gestión de activos, y también uno o más equipos de análisis y ML CoE. Cada LoB proporciona diferentes servicios:

• La LoB de banca de consumo brinda una variedad de servicios a consumidores y empresas, incluidos créditos e hipotecas, administración de efectivo, soluciones de pago, productos de depósito e inversión, y más.
• La LoB de banca comercial o de inversión ofrece soluciones financieras integrales, como préstamos, riesgo de quiebra y pagos mayoristas a clientes, incluidas pequeñas empresas, medianas empresas y grandes corporaciones.
• La LoB de gestión de activos ofrece productos de jubilación y servicios de inversión en todas las clases de activos.

Cada LoB define sus propios productos de datos, que son seleccionados por personas que entienden los datos y son los más adecuados para especificar quién está autorizado para usarlos y cómo se pueden usar. Por el contrario, otros LoB y dominios de aplicaciones, como análisis y ML CoE, están interesados ​​​​en descubrir y consumir productos de datos calificados, combinándolos para generar información y tomar decisiones basadas en datos.

La siguiente ilustración muestra algunos LoB y ejemplos de productos de datos que pueden compartir. También muestra a los consumidores de productos de datos como análisis y ML CoE, que crean modelos de ML que se pueden implementar en aplicaciones orientadas al cliente para mejorar aún más la experiencia del cliente final.

Siguiendo el concepto sociotécnico de malla de datos, comenzamos con el aspecto social con un conjunto de pasos organizativos, como los siguientes:

• Utilizar expertos de dominio para definir los límites de cada dominio, de modo que cada producto de datos se pueda asignar a un dominio específico
• Identificar los propietarios de los productos de datos proporcionados desde cada dominio, de modo que cada producto de datos tenga una estrategia definida por su propietario
• Identificar políticas de gobernanza a partir de incentivos globales y locales o federados, de modo que cuando los consumidores de datos accedan a un producto de datos específico, la política de acceso asociada con el producto se pueda aplicar automáticamente a través de una capa central de gobernanza de datos.

Luego pasamos al aspecto técnico, que incluye el siguiente escenario de extremo a extremo definido en el diagrama anterior:

1. Dote a la LoB de banca de consumo de herramientas para crear un producto de datos de perfil crediticio de consumo listo para usar.
2. Permita que la LoB de la banca de consumo comparta productos de datos en la capa de gobierno central.
3. Integre definiciones globales y federadas de políticas de acceso a datos que deben aplicarse al acceder al producto de datos de perfil de crédito del consumidor a través de la gobernanza central de datos.
4. Permita que los análisis y ML CoE descubran y accedan al producto de datos a través de la capa de gobierno central.
5. Potencie el análisis y ML CoE con herramientas para utilizar el producto de datos para construir y entrenar un modelo de predicción de riesgo crediticio. No cubrimos los pasos finales (6 y 7 en el diagrama anterior) en esta serie. Sin embargo, para mostrar el valor comercial que un modelo de ML de este tipo puede aportar a la organización en un escenario de extremo a extremo, ilustramos lo siguiente:
6. Posteriormente, este modelo podría volver a implementarse en los sistemas orientados al cliente, como un portal web de banca de consumo o una aplicación móvil.
7. Se puede utilizar específicamente dentro de la solicitud de préstamo para evaluar el perfil de riesgo de las solicitudes de crédito e hipotecas.

A continuación, describimos las necesidades técnicas de cada uno de los componentes.

Inmersión profunda en las necesidades técnicas

Para que los productos de datos estén disponibles para todos, las organizaciones deben facilitar el intercambio de datos entre diferentes entidades de la organización mientras mantienen un control adecuado sobre ellos o, en otras palabras, equilibrar la agilidad con la gobernanza adecuada.

Consumidor de datos: Analytics y ML CoE

Los consumidores de datos, como los científicos de datos de Analytics y ML CoE, deben poder hacer lo siguiente:

• Descubra y acceda a conjuntos de datos relevantes para un caso de uso dado
• Tenga la seguridad de que los conjuntos de datos a los que desean acceder ya están seleccionados, actualizados y tienen descripciones sólidas.
• Solicitar acceso a conjuntos de datos de interés para sus casos de negocio
• Utilice sus herramientas preferidas para consultar y procesar dichos conjuntos de datos dentro de su entorno para ML sin la necesidad de replicar datos desde la ubicación remota original o preocuparse por las complejidades de ingeniería o infraestructura asociadas con el procesamiento de datos almacenados físicamente en un sitio remoto.
• Reciba notificaciones de cualquier actualización de datos realizada por los propietarios de los datos

Productor de datos: propiedad del dominio

Los productores de datos, como los equipos de dominio de diferentes LoB en la organización de servicios financieros, deben registrarse y compartir conjuntos de datos seleccionados que contengan lo siguiente:

• Metadatos técnicos y operativos, como nombres y tamaños de bases de datos y tablas, esquemas de columnas y claves
• Metadatos comerciales, como descripción, clasificación y confidencialidad de los datos
• Seguimiento de metadatos, como la evolución del esquema desde el formulario de origen hasta el de destino y cualquier formulario intermedio
• Metadatos de calidad de los datos, como los índices de corrección y exhaustividad y el sesgo de los datos
• Políticas y procedimientos de acceso

Estos son necesarios para permitir que los consumidores de datos descubran y accedan a los datos sin depender de procedimientos manuales o tener que contactar a los expertos en el dominio del producto de datos para obtener más conocimiento sobre el significado de los datos y cómo se puede acceder a ellos.

Gobierno de datos: Descubrimiento, accesibilidad y auditabilidad

Las organizaciones necesitan equilibrar las agilidades ilustradas anteriormente con la mitigación adecuada de los riesgos asociados con las fugas de datos. Particularmente en industrias reguladas como los servicios financieros, existe la necesidad de mantener un gobierno de datos central para proporcionar acceso general a los datos y control de auditoría mientras se reduce el espacio de almacenamiento al evitar múltiples copias de los mismos datos en diferentes ubicaciones.

En las arquitecturas de lago de datos centralizados tradicionales, los productores de datos a menudo publican datos sin procesar y transfieren la responsabilidad de la curación de datos, la gestión de calidad de datos y el control de acceso a los ingenieros de datos e infraestructura en un equipo de plataforma de datos centralizados. Sin embargo, estos equipos de plataformas de datos pueden estar menos familiarizados con los diversos dominios de datos y aun así confiar en el apoyo de los productores de datos para poder curar y controlar adecuadamente el acceso a los datos de acuerdo con las políticas aplicadas en cada dominio de datos. Por el contrario, los propios productores de datos están mejor posicionados para proporcionar activos de datos seleccionados y calificados y son conscientes de las políticas de acceso específicas del dominio que deben aplicarse al acceder a los activos de datos.

Resumen de la solución

El siguiente diagrama muestra la arquitectura de alto nivel de la solución propuesta.

Abordamos el consumo de datos por parte de Analytics y ML CoE con Atenea amazónica y Amazon SageMaker in parte 2 de esta serie

En esta publicación, nos enfocamos en el proceso de incorporación de datos en la malla de datos y describimos cómo un LoB individual, como el equipo de datos de dominio de banca de consumo, puede usar herramientas de AWS como Pegamento AWS y Elaboración de datos de AWS Glue para preparar, seleccionar y mejorar la calidad de sus productos de datos, y luego registrar esos productos de datos en la cuenta central de gobierno de datos a través de Formación del lago AWS.

LoB de banca de consumo (productor de datos)

Uno de los principios básicos de la malla de datos es el concepto de datos como producto. Es muy importante que el equipo de datos de dominio de la banca de consumo trabaje en la preparación de productos de datos que estén listos para que los utilicen los consumidores de datos. Esto se puede hacer mediante el uso de herramientas de extracción, transformación y carga (ETL) de AWS como AWS Glue para procesar datos sin procesar recopilados en Servicio de almacenamiento simple de Amazon (Amazon S3) o, alternativamente, conéctese a los almacenes de datos operativos donde se producen los datos. También puedes usar elaboración de datos, que es una herramienta de preparación de datos visuales sin código que facilita la limpieza y la normalización de los datos.

Por ejemplo, mientras prepara el producto de datos de perfil de crédito al consumidor, el equipo de datos de dominio de banca de consumo puede realizar una selección simple para traducir del alemán al inglés los nombres de los atributos de los datos sin procesar recuperados del conjunto de datos de código abierto. Datos crediticios alemanes de Statlog, que consta de 20 atributos y 1,000 filas.

Gobierno de Datos

El servicio central de AWS para habilitar la gobernanza de la malla de datos es Lake Formation. Lake Formation ofrece la capacidad de hacer cumplir la gobernanza de datos dentro de cada dominio de datos y entre dominios para garantizar que los datos sean fácilmente detectables y seguros. Proporciona un modelo de seguridad federado que se puede administrar de forma centralizada, con las mejores prácticas para el descubrimiento de datos, la seguridad y el cumplimiento, al tiempo que permite una gran agilidad dentro de cada dominio.

Lake Formation ofrece una API para simplificar la ingesta, el almacenamiento y la gestión de los datos, junto con seguridad a nivel de fila para proteger sus datos. También proporciona funciones como control de acceso granular, tablas gobernadas y optimización del almacenamiento.

Además, Lake Formations ofrece una API para compartir datos que puedes usar para compartir datos a través de diferentes cuentas. Esto permite que el consumidor de Analytics y ML CoE ejecute consultas de Athena que consultan y unen tablas en varias cuentas. Para obtener más información, consulte el Guía para desarrolladores de AWS Lake Formation.

Administrador de acceso a recursos de AWS (AWS RAM) proporciona una forma segura de compartir recursos a través de Administrador de identidades y accesos de AWS (IAM) roles y usuarios en cuentas de AWS dentro de una organización o unidades organizativas (OU) en Organizaciones de AWS.

Lake Formation junto con AWS RAM proporciona una forma de administrar el uso compartido de datos y el acceso a través de las cuentas de AWS. Nos referimos a este enfoque como Control de acceso basado en RAM. Para obtener más detalles sobre este enfoque, consulte Cree un flujo de trabajo para compartir datos con AWS Lake Formation para su red de datos.

Lake Formation también ofrece otra forma de administrar el intercambio de datos y el acceso mediante Etiquetas de formación de lagos. Nos referimos a este enfoque como control de acceso basado en etiquetas. Para obtener más detalles, consulte Cree una arquitectura de datos moderna y un patrón de malla de datos a escala con el control de acceso basado en etiquetas de AWS Lake Formation.

A lo largo de esta publicación, utilizamos el enfoque de control de acceso basado en etiquetas porque simplifica la creación de políticas en una cantidad menor de etiquetas lógicas que se encuentran comúnmente en diferentes LoB en lugar de especificar políticas en recursos con nombre a nivel de infraestructura.

Requisitos previos

Para configurar una arquitectura de malla de datos, necesita al menos tres cuentas de AWS: una cuenta de productor, una cuenta central y una cuenta de consumidor.

Implementar el entorno de malla de datos

Para implementar un entorno de malla de datos, puede usar lo siguiente Repositorio GitHub. Este depósito contiene tres Formación en la nube de AWS plantillas que implementan un entorno de malla de datos que incluye cada una de las cuentas (productor, central y consumidor). Dentro de cada cuenta, puede ejecutar su plantilla de CloudFormation correspondiente.

cuenta central

En la cuenta central, complete los siguientes pasos:

1. Inicie la pila de CloudFormation:
   
2. Cree dos usuarios de IAM:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner como administrador de Lake Formation.
4. Cree un rol de IAM:
   1. LFRegisterLocationServiceRole
5. Cree dos políticas de IAM:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Cree la base de datos de la tarjeta de crédito para ProducerSteward en la cuenta del productor.
7. Comparta el permiso de ubicación de datos con la cuenta del productor.

Cuenta de productor

En la cuenta del productor, complete los siguientes pasos:

1. Inicie la pila de CloudFormation:
   
2. Crea el depósito de S3 credit-card, que sostiene la mesa credit_card.
3. Permita el acceso al depósito de S3 para el rol de servicio de Lake Formation de la cuenta central.
4. Crear el rastreador de AWS Glue creditCrawler-<ProducerAccountID>.
5. Cree un rol de servicio de rastreador de AWS Glue.
6. Otorgar permisos en la ubicación del depósito S3 credit-card-<ProducerAccountID>-<aws-region> al rol de rastreador de AWS Glue.
7. Cree un usuario de IAM administrador de productores.

Cuenta de consumidor

En la cuenta del consumidor, complete los siguientes pasos:

1. Inicie la pila de CloudFormation:
   
2. Crea el depósito de S3 <AWS Account ID>-<aws-region>-athena-logs.
3. Crear el grupo de trabajo de Athena consumer-workgroup.
4. Crea el usuario de IAM ConsumerAdmin.

Agregar una base de datos y suscribir la cuenta del consumidor a ella

Después de ejecutar las plantillas, puede pasar por el Guia paso a paso para agregar un producto en el catálogo de datos y hacer que el consumidor se suscriba a él. La guía comienza configurando una base de datos donde el productor puede colocar sus productos y luego explica cómo el consumidor puede suscribirse a esa base de datos y acceder a los datos. Todo esto se realiza durante el uso Etiquetas LF, que es el control de acceso basado en etiquetas para la Formación del Lago.

registro de productos de datos

La siguiente arquitectura describe los pasos detallados de cómo el equipo LoB de banca de consumo que actúa como productores de datos puede registrar sus productos de datos en la cuenta central de gobierno de datos (productos de datos integrados en la malla de datos de la organización).

Los pasos generales para registrar un producto de datos son los siguientes:

1. Cree una base de datos de destino para el producto de datos en la cuenta de gobierno central. Como ejemplo, la plantilla de CloudFormation de la cuenta central ya crea la base de datos de destino credit-card.
2. Comparta la base de datos de destino creada con el origen en la cuenta del productor.
3. Cree un enlace de recursos de la base de datos compartida en la cuenta del productor. En la siguiente captura de pantalla, vemos en la consola de Lake Formation en la cuenta del productor que rl_credit-card es el enlace de recursos de la credit-card base de datos.
   
4. Complete las tablas (con los datos seleccionados en la cuenta del productor) dentro de la base de datos de enlace de recursos (rl_credit-card) utilizando un rastreador de AWS Glue en la cuenta del productor.
   

La tabla creada aparece automáticamente en la cuenta de gobierno central. La siguiente captura de pantalla muestra un ejemplo de la tabla en Lake Formation en la cuenta central. Esto es después de realizar los pasos anteriores para llenar la base de datos de enlaces de recursos rl_credit-card en la cuenta del productor.

Conclusión

En la parte 1 de esta serie, discutimos los objetivos de las organizaciones de servicios financieros para lograr una mayor agilidad para sus equipos de análisis y ML y reducir el tiempo de los datos a la información. También nos enfocamos en crear una arquitectura de malla de datos en AWS, donde presentamos servicios de AWS fáciles de usar, escalables y rentables, como AWS Glue, DataBrew y Lake Formation. Los equipos de producción de datos pueden utilizar estos servicios para crear y compartir productos de datos seleccionados, de alta calidad, interoperables y seguros que están listos para ser utilizados por diferentes consumidores de datos con fines analíticos.

In parte 2, nos enfocamos en los equipos de análisis y ML CoE que consumen productos de datos compartidos por el LoB de banca de consumo para crear un modelo de predicción de riesgo crediticio utilizando servicios de AWS como Athena y SageMaker.

---

Sobre los autores

Karim Hammouda es un arquitecto de soluciones especializado para análisis en AWS apasionado por la integración de datos, el análisis de datos y BI. Trabaja con los clientes de AWS para diseñar y crear soluciones de análisis que contribuyan al crecimiento de su negocio. En su tiempo libre, le gusta ver documentales de televisión y jugar videojuegos con su hijo.

Hasan Poonawala es un arquitecto sénior de soluciones especialista en IA/ML en AWS, Hasan ayuda a los clientes a diseñar e implementar aplicaciones de aprendizaje automático en producción en AWS. Tiene más de 12 años de experiencia laboral como científico de datos, practicante de aprendizaje automático y desarrollador de software. En su tiempo libre, a Hasan le encanta explorar la naturaleza y pasar tiempo con amigos y familiares.

Benoît de Patoul es un arquitecto de soluciones especializado en IA/ML en AWS. Ayuda a los clientes brindándoles orientación y asistencia técnica para crear soluciones relacionadas con IA/ML mediante AWS. En su tiempo libre le gusta tocar el piano y pasar tiempo con sus amigos.