Esta publicación está coescrita por Martin Zoellner, Thomas Ehrlich y Veronika Bogusch de BMW Group.

BMW Group y AWS anunciaron un completo colaboración estratégica en 2020. El objetivo de la colaboración es acelerar aún más el ritmo de innovación de BMW Group colocando los datos y el análisis en el centro de su toma de decisiones. Un elemento clave de la colaboración es el mayor desarrollo de Cloud Data Hub (CDH) de BMW Group. Esta es la plataforma central para administrar datos y soluciones de datos de toda la empresa en la nube. En el Sesión de AWS re:Invent 2019, BMW y AWS demostraron la nueva plataforma Cloud Data Hub describiendo diferentes arquetipos de plataformas de datos y luego recorriendo el camino de la construcción del Cloud Data Hub de BMW Group. Para obtener más información sobre Cloud Data Hub, consulte BMW Cloud Data Hub: una implementación de referencia de la arquitectura de datos moderna en AWS.

Como parte de esta colaboración, BMW Group está migrando cientos de fuentes de datos en varios dominios de datos a Cloud Data Hub. Varias de estas fuentes pertenecen a Servicios financieros de BMW.

En este post, hablamos de cómo el Laboratorio de datos de AWS está ayudando a BMW Financial Services a crear una aplicación de informes reglamentarios para uno de los mercados europeos de BMW utilizando Cloud Data Hub en AWS.

Resumen de la solución

En el contexto de los informes reglamentarios, BMW Financial Services trabaja con datos críticos de servicios financieros que contienen información de identificación personal (PII). Necesitamos proporcionar información mensual sobre nuestros datos financieros a uno de los reguladores nacionales europeos, y también debemos cumplir con la Schrems II y RGPD regulaciones a medida que procesamos datos PII. Esto requiere que la PII sea seudonimizada cuando se carga en Cloud Data Hub, y debe procesarse más en forma seudonimizada. Para obtener una descripción general del proceso de seudonimización, consulte Cree un servicio de seudonimización en AWS para proteger los datos confidenciales .

Para abordar estos requisitos de manera precisa y eficiente, BMW Financial Services decidió trabajar con el laboratorio de datos de AWS. El laboratorio de datos de AWS tiene dos ofertas: el laboratorio de diseño y el laboratorio de construcción.

Laboratorio de diseño

Design Lab es un compromiso de 1 a 2 días para clientes que necesitan una recomendación de arquitectura del mundo real basada en la experiencia de AWS, pero que no están listos para construir. En el caso de BMW Financial Services, antes de comenzar la fase de construcción, fue clave reunir a todas las partes interesadas en la misma sala y registrar todos los requisitos funcionales y no funcionales introducidos por todas las diferentes partes que podrían influir en la plataforma de datos, desde propietarios de las diversas fuentes de datos hasta los usuarios finales que usarían la plataforma para ejecutar análisis y obtener información empresarial. Dentro del alcance del Design Lab, discutimos tres casos de uso:

• Reportes regulatorios – La máxima prioridad para BMW Financial Services fue el caso de uso de informes regulatorios, que implica recopilar y calcular datos e informes que se declararán al regulador nacional.
• Almacén de datos locales – Para este caso de uso, necesitamos calcular y almacenar todos los indicadores clave de rendimiento (KPI) y los indicadores clave de valor (KVI) que se definirán durante el proyecto. Los datos históricos deben almacenarse, pero debemos aplicar un proceso de seudonimización para respetar las directivas de GDPR. Además, se debe acceder diariamente a los datos históricos a través de una herramienta de visualización de cuadros. En cuanto a la estructura, sería valioso definir dos niveles (como mínimo): uno a nivel de contrato para justificar el cálculo de todos los KPI y otro a nivel agregado para optimizar las restituciones. Los datos personales están limitados en la aplicación, pero debe ser posible un proceso de reidentificación para los patrones de consumo autorizados.
• Detalles contables – Este caso de uso se basa en la herramienta de contabilidad IFT de BMW, que proporciona el saldo contable a nivel de contrato de todas las aplicaciones del mercado local. Debe ejecutarse al menos una vez al mes. Sin embargo, si se identifican algunos problemas en IFT durante el cierre, debemos poder reiniciarlo y borrar la ejecución anterior. Cuando se completa el cierre de mes, este caso de uso debe mantener la última versión de saldo contable generada durante el mes y almacenarla. Paralelamente, todas las versiones de saldos contables tienen que ser accesibles por otras aplicaciones para consultas y poder recuperar la información durante 24 meses.

Con base en estos requisitos, desarrollamos la siguiente arquitectura durante el Design Lab.

Esta solución contiene los siguientes componentes:

1. La principal fuente de datos que hidrata nuestros tres casos de uso es la ya disponible en Cloud Data Hub. Cloud Data Hub utiliza Formación del lago AWS enlaces de recursos para otorgar acceso al conjunto de datos a las cuentas de los consumidores.
2. Para trabajos ETL (extracción, transformación y carga) periódicos y estándar que implican operaciones como la conversión de tipos de datos o la creación de etiquetas basadas en valores numéricos o indicadores booleanos basados ​​en una etiqueta, utilizamos Pegamento AWS trabajos ETL.
3. Para trabajos históricos de ETL o cálculos más complejos, como en el caso de uso de detalles de la cuenta, que pueden implicar uniones enormes con configuraciones y ajustes personalizados, recomendamos usar EMR de Amazon. Esto le brinda la oportunidad de controlar las configuraciones de clúster en un nivel detallado.
4. Para almacenar metadatos de trabajos que habilitan funciones como el reprocesamiento de entradas o la repetición de trabajos fallidos, recomendamos crear un registro de datos. El objetivo del registro de datos es crear un inventario centralizado para cualquier dato que se ingrese en el lago de datos. basado en horarios AWS Lambda La función podría activarse para registrar datos que aterrizan en la capa semántica de Cloud Data Hub en un almacén de metadatos centralizado. Recomendamos usar Amazon DynamoDB para el registro de datos.
5. Servicio de almacenamiento simple de Amazon (Amazon S3) sirve como mecanismo de almacenamiento que impulsa el caso de uso de informes reglamentarios utilizando el marco de gestión de datos apache hudi. Apache Hudi es útil para nuestros casos de uso porque necesitamos desarrollar canalizaciones de datos donde las capacidades de inserción, actualización, upsert y eliminación a nivel de registro son deseables. Las tablas de Hudi son compatibles con trabajos de Amazon EMR y AWS Glue a través del conector de Hudi, junto con motores de consulta como Atenea amazónica y Espectro de Redshift de Amazon.
6. Como parte del proceso de almacenamiento de datos en el depósito S3 de informes reglamentarios, podemos completar el Catálogo de datos de AWS Glue con los metadatos requeridos.
7. Athena proporciona un entorno de consulta ad hoc para el análisis interactivo de los datos almacenados en Amazon S3 mediante SQL estándar. Tiene una integración lista para usar con AWS Glue Data Catalog.
8. Para el caso de uso de almacenamiento de datos, primero debemos desnormalizar los datos para crear un modelo dimensional que permita consultas analíticas optimizadas. Para esa conversión, usamos trabajos ETL de AWS Glue.
9. Data marts dimensionales en Desplazamiento al rojo de Amazon habilite nuestro tablero y las necesidades de informes de autoservicio. Los datos en Amazon Redshift están organizados en varias áreas temáticas que están alineadas con las necesidades comerciales, y un modelo dimensional permite el análisis de áreas temáticas cruzadas.
10. Como un subproducto de la creación de un clúster de Amazon Redshift, podemos usar Redshift Spectrum para acceder a los datos en el depósito de informes reglamentarios de la arquitectura. Actúa como un frente para acceder a datos más granulares sin tener que cargarlos en el clúster de Amazon Redshift.
11. Los datos proporcionados a Cloud Data Hub contienen datos personales seudonimizados. Sin embargo, necesitamos que nuestras columnas con seudónimo se vuelvan a personalizar al visualizarlas en Tableau o al generar informes CSV. Ambas cosas Athena y soporte de Amazon Redshift UDF lambda, que se puede usar para acceder a las API de PII de Cloud Data Hub para volver a personalizar las columnas con seudónimo antes de presentarlas a los usuarios finales.
12. Se puede acceder tanto a Athena como a Amazon Redshift a través de JDBC (conectividad de base de datos Java) para proporcionar acceso a los consumidores de datos.
13. Podemos usar un trabajo de shell de Python en AWS Glue para ejecutar una consulta en cualquiera de nuestras soluciones de análisis, convertir los resultados al formato CSV requerido y almacenarlos en una carpeta segura de BMW.
14. Cualquier herramienta de inteligencia comercial (BI) implementada en las instalaciones puede conectarse tanto a Athena como a Amazon Redshift y usar sus motores de consulta para realizar cualquier cálculo pesado antes de recibir los datos finales para alimentar sus tableros.
15. Para la orquestación de canalización de datos, recomendamos usar Funciones de paso de AWS debido a su experiencia de desarrollo de código bajo y su integración completa con todos los demás componentes discutidos.

Con la arquitectura anterior como nuestro estado objetivo a largo plazo, concluimos el Laboratorio de Diseño y decidimos regresar para un Laboratorio de Construcción para acelerar el desarrollo de la solución.

Preparación para el laboratorio de compilación

La preparación típica de un laboratorio de construcción que sigue a un laboratorio de diseño implica identificar algunos ejemplos de patrones de casos de uso comunes, generalmente los más complejos. Para maximizar el éxito en Build Lab, reducimos la arquitectura objetivo a largo plazo a un subconjunto de componentes que abordan esos ejemplos y se pueden implementar en un sprint intenso de 3 a 5 días.

Para un Build Lab exitoso, también necesitamos identificar y resolver las dependencias externas, como la conectividad de la red a las fuentes y destinos de datos. Si eso no es factible, entonces encontramos formas significativas de burlarnos de ellos. Por ejemplo, para hacer que el prototipo se acerque más a cómo se vería el entorno de producción, decidimos usar cuentas de AWS separadas para cada caso de uso, en función de la estructura de equipo existente de BMW, y usar un depósito S3 de consumo en lugar de uno conectado a la red de BMW. almacenamiento (NAS).

Laboratorio de construcción

El equipo de BMW reservó 4 días para su laboratorio de construcción. Durante ese tiempo, su Arquitecto de Laboratorio de Datos dedicado trabajó junto con el equipo, ayudándolos a construir la siguiente arquitectura prototipo.

Esta solución incluye los siguientes componentes:

1. El primer paso fue sincronizar el catálogo de datos de AWS Glue de Cloud Data Hub y las cuentas de informes reglamentarios.
2. Los trabajos de AWS Glue que se ejecutaban en la cuenta de informes regulatorios tenían acceso a los datos en las cuentas de recursos de Cloud Data Hub. Durante el laboratorio de compilación, el equipo de BMW implementó trabajos de ETL para seis tablas, abordando los requisitos de inserción, actualización y eliminación de registros mediante Hudi.
3. El resultado de los trabajos de ETL se almacena en la capa del lago de datos almacenada en el depósito S3 de informes reglamentarios como tablas de Hudi que se catalogan en el catálogo de datos de AWS Glue y pueden ser consumidas por varios servicios de AWS. El cubo está encriptado usando Servicio de administración de claves de AWS (AWS KMS).
4. Athena se utiliza para ejecutar consultas exploratorias en el lago de datos.
5. Para demostrar el patrón de consumo entre cuentas, creamos un clúster de Amazon Redshift en él, creamos tablas externas del catálogo de datos y usamos Redshift Spectrum para consultar los datos. Para habilitar la conectividad entre cuentas entre el grupo de subred del catálogo de datos de la cuenta de informes reglamentarios y el grupo de subred del clúster de Amazon Redshift en la cuenta del almacén de datos local, teníamos que habilitar Emparejamiento de VPC. Para acelerar y optimizar la implementación de estas configuraciones durante el laboratorio de compilación, recibimos el apoyo de un experto en la materia de redes de AWS, quien dirigió una sesión valiosa, durante la cual el equipo de BMW comprendió los detalles de redes de la arquitectura.
6. Para el consumo de datos, el equipo de BMW implementó un trabajo de shell de AWS Glue Python que se conectaba a Amazon Redshift o Athena mediante una conexión JDBC, ejecutaba una consulta y almacenaba los resultados en el depósito de informes como un archivo CSV, al que luego podría acceder el usuarios finales.
7. Los usuarios finales también pueden conectarse directamente a Athena y Amazon Redshift mediante una conexión JDBC.
8. Decidimos orquestar los trabajos ETL de AWS Glue usando Flujos de trabajo de AWS Glue. Usamos el flujo de trabajo resultante para la demostración de fin de laboratorio.

Con eso, completamos todos los objetivos que habíamos establecido y concluimos el laboratorio de construcción de 4 días.

Conclusión

En esta publicación, lo guiamos a través del viaje que el equipo de BMW Financial Services realizó con el equipo de AWS Data Lab para participar en un Design Lab para identificar la arquitectura que mejor se adapta a sus casos de uso, y el posterior Build Lab para implementar prototipos para fines regulatorios. informes en uno de los mercados europeos de BMW.

Para obtener más información sobre cómo AWS Data Lab puede ayudarlo a convertir sus ideas en soluciones, visite Laboratorio de datos de AWS.

Un agradecimiento especial a todos los que contribuyeron al éxito del Laboratorio de Diseño y Construcción: Lionel Mbenda, Mario Robert Tutunea, Marius Abalarus, Maria Dejoie.

Sobre los autores

Martín Zoellner es especialista en TI en BMW Group. Su rol en el proyecto es Experto en la materia para DevOps y ETL/SW Architecture.

Tomas Ehrlich es el administrador de mantenimiento funcional de la aplicación de informes reglamentarios en uno de los mercados europeos de BMW.

Veronika Bogusch es especialista en TI en BMW. Inició la reconstrucción de la capa de integración de lotes de servicios financieros a través de Cloud Data Hub. Los activos de datos ingeridos son la base para el caso de uso de informes reglamentarios descrito en este artículo.

Jorge Komninos es un arquitecto de soluciones para el laboratorio de datos de Amazon Web Services (AWS). Ayuda a los clientes a convertir sus ideas en un producto de datos listo para la producción. Antes de AWS, pasó tres años en el dominio de Alexa Information como ingeniero de datos. Fuera del trabajo, George es fanático del fútbol y apoya al mejor equipo del mundo, el Olympiacos Piraeus.

raul shaurya es Arquitecto Senior de Big Data con Servicios Profesionales de AWS. Ayuda y trabaja en estrecha colaboración con los clientes en la creación de plataformas de datos y aplicaciones analíticas en AWS. Fuera del trabajo, a Rahul le encanta dar largos paseos con su perro Barney.