Un beneficio clave de un arquitectura de malla de datos está permitiendo que diferentes líneas de negocio (LOB) y unidades organizativas operen de forma independiente y ofrezcan sus datos como un producto. Este modelo no solo permite escalar a las organizaciones, sino que también otorga la propiedad de extremo a extremo del mantenimiento del producto a los productores de datos que son los expertos en el dominio de los datos. Esta propiedad implica el mantenimiento de las canalizaciones de datos, la depuración de secuencias de comandos ETL, la solución de problemas de calidad de los datos y el mantenimiento de las entradas del catálogo actualizadas a medida que el conjunto de datos evoluciona con el tiempo.

Del lado del consumidor, los equipos pueden buscar en el catálogo central productos de datos relevantes y solicitar acceso. El acceso a los datos se realiza a través de la característica de intercambio de datos in Formación del lago AWS. A medida que crece la cantidad de productos de datos y se almacena información potencialmente más confidencial en el lago de datos de una organización, es importante que el proceso y el mecanismo para solicitar y otorgar acceso a productos de datos específicos se realicen de manera escalable y segura.

Esta publicación describe cómo crear un motor de flujo de trabajo que automatice el proceso de intercambio de datos al tiempo que incluye un mecanismo de aprobación independiente para los productos de datos que están etiquetados como confidenciales (por ejemplo, que contienen datos PII). Tanto el flujo de trabajo como el mecanismo de aprobación son personalizables y deben adaptarse para cumplir con los procesos internos de su empresa. Además, incluimos una interfaz de usuario de flujo de trabajo opcional para demostrar cómo integrarse con el motor de flujo de trabajo. La interfaz de usuario es solo un ejemplo de cómo funciona la interacción. En una empresa grande típica, también puede usar sistemas de emisión de boletos para activar automáticamente tanto el flujo de trabajo como el proceso de aprobación.

Resumen de la solución

Una arquitectura de malla de datos típica para análisis en AWS contiene una cuenta central que recopila todos los diferentes productos de datos de múltiples cuentas de productores. Los consumidores pueden buscar los productos de datos disponibles en una sola ubicación. Compartir productos de datos con los consumidores en realidad no hace una copia separada, sino que simplemente crea un puntero al elemento del catálogo. Esto significa que cualquier actualización que los productores realicen en sus productos se reflejará automáticamente en la cuenta central, así como en todas las cuentas de los consumidores.

Construida sobre esta base, la solución contiene varios componentes, como se muestra en el siguiente diagrama:

La cuenta central incluye los siguientes componentes:

• Pegamento AWS – Utilizado para fines de catálogo de datos.
• Formación del lago AWS – Se utiliza para asegurar el acceso a los datos, así como para proporcionar las capacidades de intercambio de datos que permiten la arquitectura de malla de datos.
• Funciones de paso de AWS – El flujo de trabajo real se define como una máquina de estado. Puede personalizar esto para cumplir con los requisitos de aprobación de su organización.
• AWS amplificar – La interfaz de usuario del flujo de trabajo utiliza el marco Amplify para proteger el acceso. También utiliza Amplify para alojar la aplicación basada en React. En el backend, el marco Amplify crea dos Cognito Amazonas componentes para soportar los requisitos de seguridad:
  • Grupos de usuarios – Proporcionar una funcionalidad de directorio de usuarios.
  • Grupos de identidad – Proporcione capacidades de inicio de sesión federado utilizando grupos de usuarios de Amazon Cognito como la ubicación de los detalles del usuario. Los grupos de identidades ofrecen credenciales temporales para que la interfaz de usuario del flujo de trabajo pueda acceder a las API de AWS Glue y Step Functions.
• AWS Lambda – Contiene la lógica de la aplicación orquestada por la máquina de estado de Step Functions. También proporciona la lógica de aplicación necesaria cuando un productor aprueba o deniega una solicitud de acceso.
• Puerta de enlace API de Amazon – Proporciona la API para que los productores acepten y rechacen solicitudes.

La cuenta del productor contiene los siguientes componentes:

La cuenta de consumidor contiene los siguientes componentes:

• Pegamento AWS – Utilizado para fines de catálogo de datos.
• Formación del lago AWS – Después de que los datos estén disponibles, los consumidores pueden otorgar acceso a sus propios usuarios a través de Lake Formation.
• Administrador de acceso a recursos de AWS (AWS RAM) – Si la cuenta del beneficiario está en la misma organización que la cuenta del otorgante, el recurso compartido está disponible inmediatamente para el beneficiario. Si la cuenta del beneficiario no está en la misma organización, AWS RAM envía una invitación a la cuenta del beneficiario para aceptar o rechazar la concesión de recursos. Para obtener más detalles sobre el acceso entre cuentas de Lake Formation, consulte Acceso entre cuentas: cómo funciona.

La solución se divide en varios pasos:

1. Implemente el backend de la cuenta central, incluido el motor de flujo de trabajo y sus componentes asociados.
2. Implemente el backend para las cuentas de productor. Puede repetir este paso varias veces según la cantidad de cuentas de productores que esté incorporando al motor de flujo de trabajo.
3. Implemente la interfaz de usuario de flujo de trabajo opcional en la cuenta central para interactuar con el backend de la cuenta central.

Descripción general del flujo de trabajo

El siguiente diagrama ilustra el flujo de trabajo. En este ejemplo particular, la máquina de estado verifica si la tabla o base de datos (dependiendo de lo que se comparte) tiene la pii_flag parámetro y si está establecido en TRUE. Si ambas condiciones son válidas, envía una solicitud de aprobación al tema SNS del productor. De lo contrario, automáticamente comparte el producto con el consumidor solicitante.

Este flujo de trabajo es el núcleo de la solución y se puede personalizar para adaptarse al proceso de aprobación de su organización. Además, puede agregar parámetros personalizados a bases de datos, tablas o incluso columnas para adjuntar metadatos adicionales para admitir la lógica del flujo de trabajo.

Requisitos previos

Los siguientes son los requisitos de implementación:

Puede clonar la interfaz de usuario del flujo de trabajo y los scripts de AWS CDK desde el Repositorio GitHub.

Implementar el backend de la cuenta central

Para implementar el backend para la cuenta central, vaya a la raíz del proyecto después de clonar el repositorio de GitHub e ingrese el siguiente código:

yarn deploy-central --profile <PROFILE_OF_CENTRAL_ACCOUNT>

Esto despliega lo siguiente:

• Roles de IAM utilizados por las funciones de Lambda y la máquina de estado de Step Functions
• Funciones lambda
• La máquina de estado de Step Functions (el propio flujo de trabajo)
• Una puerta de enlace API

Cuando se completa la implementación, genera un archivo JSON en el src/cfn-output.json ubicación. El script de implementación de la interfaz de usuario utiliza este archivo para generar una aplicación de interfaz de usuario de flujo de trabajo y una política de IAM de alcance inferior para ubicar la máquina de estado creada por el script de CDK de AWS.

Los scripts de AWS CDK reales para la implementación de la cuenta central están en infra/central/. Esto también incluye las funciones Lambda (en el infra/central/functions/ carpeta) que utilizan tanto la máquina de estado como API Gateway.

Permisos de formación de lagos

La siguiente tabla contiene los permisos mínimos requeridos que el administrador del lago de datos de la cuenta central debe otorgar a los respectivos roles de IAM para que el backend tenga acceso a AWS Glue Data Catalog.

Parámetros del catálogo de flujo de trabajo

El flujo de trabajo utiliza los siguientes parámetros de catálogo para proporcionar su funcionalidad.

Puedes usar Actualizar base de datos y Actualizartabla para agregar parámetros a la base de datos y la granularidad a nivel de columna, respectivamente. Como alternativa, puede utilizar el CLI para pegamento de AWS para agregar los parámetros relevantes.

Utilice la AWS CLI para ejecutar el siguiente comando para verificar los parámetros actuales en su base de datos:

aws glue get-database --name <DATABASE_NAME> --profile <PROFILE_OF_CENTRAL_ACCOUNT>

Obtienes la siguiente respuesta:

{ "Database": { "Name": "<DATABASE_NAME>", "CreateTime": "<CREATION_TIME>", "CreateTableDefaultPermissions": [], "CatalogId": "<CATALOG_ID>" }
}

Para actualizar la base de datos con los parámetros indicados en la tabla anterior, primero creamos el archivo JSON de entrada, que contiene los parámetros con los que queremos actualizar la base de datos. Por ejemplo, vea el siguiente código:

{ "Name": "<DATABASE_NAME>", "Parameters": { "data_owner": "<AWS_ACCOUNT_ID_OF_OWNER>", "data_owner_name": "<AWS_ACCOUNT_NAME_OF_OWNER>", "pii_flag": "true" }
}

Ejecute el siguiente comando para actualizar el catálogo de datos:

aws glue update-database --name <DATABASE_NAME> --database-input file://<FILE_NAME>.json --profile <PROFILE_OF_CENTRAL_ACCOUNT>

Implementar el backend de la cuenta del productor

Para implementar el backend para sus cuentas de productor, vaya a la raíz del proyecto y ejecute el siguiente comando:

yarn deploy-producer --profile <PROFILE_OF_PRODUCER_ACCOUNT> --parameters centralMeshAccountId=<central_account_account_id>

Esto despliega lo siguiente:

• Un tema de SNS donde se publican las solicitudes de aprobación.
• El proyecto ProducerWorkflowRole Rol de IAM con una relación de confianza con la cuenta central. Este rol permite que Amazon SNS publique en el tema de SNS creado anteriormente.

Puede ejecutar este script de implementación varias veces, cada vez apuntando a una cuenta de productor diferente que desea que participe en el flujo de trabajo.

Para recibir correos electrónicos de notificación, suscríbase a su correo electrónico en el tema de SNS que creó el script de implementación. Por ejemplo, nuestro tema se llama DataLakeSharingApproval. Para obtener el ARN completo, puede ir a la consola de Amazon Simple Notification Service o ejecutar el siguiente comando para enumerar todos los temas y obtener el ARN para DataLakeSharingApproval:

aws sns list-topics --profile <PROFILE_OF_PRODUCER_ACCOUNT>

Una vez que tenga el ARN, puede suscribir su correo electrónico ejecutando el siguiente comando:

aws sns subscribe --topic-arn <TOPIC_ARN> --protocol email --notification-endpoint <EMAIL_ADDRESS> --profile <PROFILE_OF_PRODUCER_ACCOUNT>

A continuación, recibirá un correo electrónico de confirmación a través de la dirección de correo electrónico que se suscribió. Escoger Confirmar suscripción para recibir notificaciones de este tema de SNS.

Implementar la interfaz de usuario del flujo de trabajo

La interfaz de usuario del flujo de trabajo está diseñada para implementarse en la cuenta central donde se encuentra el catálogo de datos central.

Para iniciar la implementación, ingrese el siguiente comando:

yarn deploy-ui

Esto despliega lo siguiente:

• Grupo de usuarios y grupo de identidades de Amazon Cognito
• Aplicación basada en React para interactuar con el catálogo y solicitar acceso a datos

El comando de implementación le solicita la siguiente información:

• Información del proyecto – Utilice los valores predeterminados.
• Autenticación de AWS – Utilice su perfil para la cuenta central. Amplify usa este perfil para implementar los recursos de back-end.

autenticación de interfaz de usuario – Utilice la configuración predeterminada y su nombre de usuario. Escoger no, he terminado cuando se le pida que configure los ajustes avanzados.

• alojamiento de interfaz de usuario – Utilice el alojamiento con la consola de Amplify y elija la implementación manual.

El script proporciona un resumen de lo que se implementa. Al ingresar Y, se activan los recursos que se implementarán en el backend. El mensaje se parece a la siguiente captura de pantalla:

Cuando se completa la implementación, el aviso restante es para la información inicial del usuario, como el nombre de usuario y el correo electrónico. Una contraseña temporal se genera automáticamente y se envía al correo electrónico proporcionado. El usuario debe cambiar la contraseña después del primer inicio de sesión.

El script de implementación otorga permisos de IAM al usuario a través de una política en línea adjunta al rol de IAM autenticado de Amazon Cognito:

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "glue:GetDatabase", "glue:GetTables", "glue:GetDatabases", "glue:GetTable" ], "Resource":"*" }, { "Effect":"Allow", "Action":[ "states:ListExecutions", "states:StartExecution" ], "Resource":[ "arn:aws:states:<REGION>:<AWS_ACCOUNT_ID>:stateMachine:<STATE_MACHINE_NAME>"
] }, { "Effect":"Allow", "Action":[ "states:DescribeExecution" ], "Resource":[ "arn:aws:states:<REGION>:<AWS_ACCOUNT_ID>:execution:<STATE_MACHINE_NAME>:*"
] } ]
}

El último paso restante es otorgar permisos de Lake Formation (DESCRIBE para bases de datos y tablas) al rol de IAM autenticado asociado con el grupo de identidades de Amazon Cognito. Puede encontrar el rol de IAM ejecutando el siguiente comando:

cat amplify/team-provider-info.json

El nombre del rol de IAM está en el AuthRoleName propiedad bajo el awscloudformation llave. Después de otorgar los permisos necesarios, puede usar la URL proporcionada en su navegador para abrir la interfaz de usuario del flujo de trabajo.

Su contraseña temporal se le envía por correo electrónico para que pueda completar el inicio de sesión inicial, después de lo cual se le pide que cambie su contraseña.

La primera página después de iniciar sesión es la lista de bases de datos a las que pueden acceder los consumidores.

Elige Solicitar acceso para ver los detalles de la base de datos y la lista de tablas.

Elige Solicitud de acceso por mesa y ver más detalles a nivel de tabla.

Volviendo a la página anterior, solicitamos acceso a nivel de base de datos ingresando la identificación de la cuenta del consumidor que recibe la solicitud de compartir.

Debido a que esta base de datos ha sido etiquetada con un pii_flag, el flujo de trabajo debe enviar una solicitud de aprobación al propietario del producto. Para recibir este correo electrónico de solicitud de aprobación, el correo electrónico del propietario del producto debe estar suscrito al DataLakeSharingApproval Tema SNS en la cuenta del producto. Los detalles deben ser similares a la siguiente captura de pantalla:

El correo electrónico se parece a la siguiente captura de pantalla:

El propietario del producto elige el Aprobar enlace para activar la máquina de estado de Step Functions para continuar ejecutándose y compartir el elemento del catálogo con la cuenta del consumidor.

Para este ejemplo, la cuenta del consumidor no forma parte de una organización, por lo que el administrador de la cuenta del consumidor debe ir a AWS RAM y aceptar la invitación.

Una vez que se acepta el recurso compartido, la base de datos compartida aparece en el catálogo de la cuenta del consumidor.

Limpiar

Si ya no necesita usar esta solución, use los scripts de limpieza proporcionados para eliminar los recursos implementados.

Cuenta de productor

Para eliminar los recursos implementados en las cuentas de productor, ejecute el siguiente comando para cada cuenta de productor que implementó:

yarn clean-producer --profile <PROFILE_OF_PRODUCER_ACCOUNT>

cuenta central

Ejecute el siguiente comando para eliminar el backend de flujo de trabajo en la cuenta central:

yarn clean-central --profile <PROFILE_OF_CENTRAL_ACCOUNT>

IU de flujo de trabajo

El script de limpieza para la interfaz de usuario del flujo de trabajo se basa en un comando Amplify CLI para iniciar el desmantelamiento de los recursos implementados. Además, puede usar un script personalizado para eliminar la política en línea en el rol de IAM autenticado que usa Amazon Cognito para que Amplify pueda limpiar por completo todos los recursos implementados. Ejecute el siguiente comando para activar la limpieza:

yarn clean-ui

Este comando no requiere la profile porque usa la configuración existente de Amplify para inferir dónde se implementan los recursos y qué perfil se usó.

Conclusión

Esta publicación demostró cómo crear un motor de flujo de trabajo para automatizar el proceso de aprobación de una organización para obtener acceso a productos de datos con diversos grados de sensibilidad. El uso de un motor de flujo de trabajo permite compartir datos en forma de autoservicio mientras codifica los procesos internos de su organización para poder escalar de manera segura a medida que se incorporan más productos y equipos de datos.

La interfaz de usuario de flujo de trabajo proporcionada demostró un posible escenario de integración. Otros posibles escenarios de integración incluyen la integración con el sistema de emisión de boletos de su organización para activar el flujo de trabajo, así como recibir y responder solicitudes de aprobación, o la integración con aplicaciones de chat de negocios para acortar aún más el ciclo de aprobación.

Por último, es posible un alto grado de personalización con el enfoque demostrado. Las organizaciones tienen control total sobre el flujo de trabajo, cómo se definen los niveles de sensibilidad del producto de datos, qué se aprueba automáticamente y qué necesita más aprobaciones, la jerarquía de aprobaciones (como un solo aprobador o múltiples aprobadores) y cómo se entregan y actúan las aprobaciones. al. Puede aprovechar esta flexibilidad para automatizar los procesos de su empresa y ayudarlos a acelerar de forma segura para convertirse en una organización basada en datos.

Sobre la autora

Jan Michael Go Tan es Arquitecto Principal de Soluciones para Amazon Web Services. Ayuda a los clientes a diseñar soluciones escalables e innovadoras con la nube de AWS.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://aws.amazon.com/blogs/big-data/build-a-data-sharing-workflow-with-aws-lake-formation-for-your-data-mesh/