Esta publicación está coescrita con Olivia Michele y Dariswan Janweri P. en Ruparupa.

Ruparupa fue construido por PT. Omni Digitama Internusa con la visión de cultivar la sinergia y crear un ecosistema digital continuo dentro de Kawan Lama Group que toque y mejore la vida de muchos.

Ruparupa es la primera plataforma digital creada por Kawan Lama Group para brindar la mejor experiencia de compra para el hogar, muebles y necesidades de estilo de vida. El objetivo de Ruparupa es ayudarte a vivir una vida mejor, como lo demuestra el significado de la palabra ruparupa, que significa “todo”. Creemos que todos merecen lo mejor y el hogar es donde todo comienza.

En esta publicación, mostramos cómo Ruparupa implementó un lago de datos actualizado gradualmente para obtener información sobre su negocio usando Servicio de almacenamiento simple de Amazon (Amazon S3), Pegamento AWS, apache hudiy Amazon QuickSight. También discutimos los beneficios que obtuvo Ruparupa después de la implementación.

El lago de datos implementado por Ruparupa utiliza Amazon S3 como plataforma de almacenamiento, Servicio de migración de bases de datos de AWS (AWS DMS) como herramienta de ingestión, AWS Glue como herramienta ETL (extracción, transformación y carga) y QuickSight para paneles analíticos.

Amazon S3 es un servicio de almacenamiento de objetos con una escalabilidad, durabilidad y seguridad muy altas, lo que lo convierte en una capa de almacenamiento ideal para un lago de datos. AWS DMS es una herramienta de migración de bases de datos que admite muchos servicios de administración de bases de datos relacionales y también es compatible con Amazon S3.

Un trabajo ETL de AWS Glue, mediante el conector Apache Hudi, actualiza el lago de datos de S3 cada hora con datos incrementales. El trabajo de AWS Glue puede transformar los datos sin procesar en Amazon S3 a formato Parquet, que está optimizado para consultas analíticas. AWS Glue Data Catalog almacena los metadatos y Atenea amazónica (un motor de consulta sin servidor) se utiliza para consultar datos en Amazon S3.

Director de secretos de AWS es un servicio de AWS que se puede utilizar para almacenar datos confidenciales, lo que permite a los usuarios mantener datos como las credenciales de la base de datos fuera del código fuente. En esta implementación, Secrets Manager se usa para almacenar la configuración del trabajo de Apache Hudi para varias tablas.

Desafíos analíticos de datos

Como empresa de comercio electrónico, Ruparupa produce una gran cantidad de datos de su sitio web de comercio electrónico, sus sistemas de inventario y aplicaciones de distribución y finanzas. Los datos pueden ser datos estructurados de sistemas existentes y también pueden ser datos no estructurados o semiestructurados de sus interacciones con los clientes. Estos datos contienen información que, si se desbloquea, puede ayudar a la gerencia a tomar decisiones para ayudar a aumentar las ventas y optimizar los costos.

Antes de implementar un lago de datos en AWS, Ruparupa no tenía una infraestructura capaz de procesar el volumen y la variedad de formatos de datos en poco tiempo. Los analistas de datos tenían que procesar manualmente los datos, y la extracción de datos llevó mucho tiempo. Debido al rápido crecimiento de los datos, se necesitaban entre 1 y 1.5 horas solo para incorporar los datos, que eran cientos de miles de filas.

El proceso manual provocó una limpieza de datos inconsistente. Después de limpiar los datos, a menudo faltaban algunos procesos y todos los datos tenían que pasar por otro proceso de limpieza de datos.

Este largo tiempo de procesamiento redujo la productividad del equipo analítico. El equipo analítico solo podía producir informes semanales y mensuales. Este retraso en la frecuencia de los informes afectó la entrega de información importante a la gerencia, y no pudieron moverse lo suficientemente rápido para anticipar los cambios en su negocio.

El método utilizado para crear tableros analíticos era manual y solo podía producir algunos informes de rutina. La audiencia de estos pocos informes fue limitada: un máximo de 20 personas de la gerencia. Otras unidades de negocios en Kawan Lama Group solo consumían informes semanales que se preparaban manualmente. Incluso los informes semanales no podían cubrir todas las métricas importantes, porque algunas métricas solo estaban disponibles en los informes mensuales.

Solución inicial para un tablero en tiempo real

El siguiente diagrama ilustra la solución inicial implementada por Ruparupa.

Ruparupa inició una iniciativa de datos dentro de la organización para crear una única fuente de verdad dentro de la empresa. Anteriormente, los usuarios comerciales solo podían obtener los datos de ventas del día anterior y no tenían ninguna visibilidad de las actividades de ventas actuales en sus tiendas y sitios web.

Para ganarnos la confianza de los usuarios comerciales, queríamos proporcionar los datos más actualizados en un tablero interactivo de QuickSight. Utilizamos una tarea de replicación de AWS DMS para transmitir actualizaciones de captura de datos de cambios (CDC) en tiempo real a un Edición compatible con MySQL de Amazon Aurora base de datos y creó un tablero QuickSight para reemplazar la plataforma de presentación estática.

Este tablero piloto fue muy bien aceptado por los usuarios, que ahora tenían visibilidad de sus datos actuales. Sin embargo, la fuente de datos para el tablero aún residía en una base de datos Aurora MySQL y solo cubría un único dominio de datos.

El diseño inicial tenía algunos desafíos adicionales:

• Diversa fuente de datos – La fuente de datos en una plataforma de comercio electrónico consta de datos estructurados, semiestructurados y no estructurados, lo que requiere un almacenamiento de datos flexible. El diseño inicial del almacén de datos en Ruparupa solo almacenaba datos transaccionales y los datos de otros sistemas, incluidos los datos de interacción del usuario, aún no se habían consolidado.
• Costo y escalabilidad – Ruparupa quería crear una solución de plataforma de datos preparada para el futuro que pudiera escalar hasta terabytes de datos de la manera más rentable.

El diseño inicial también tenía algunos beneficios:

• Actualizaciones de datos – Los datos dentro del almacén de datos inicial se retrasaron 1 día. Esta fue una mejora con respecto al informe semanal, pero aún no lo suficientemente rápido como para tomar decisiones más rápidas.

Esta solución solo sirvió como una solución temporal; necesitábamos una solución de análisis más completa que pudiera servir fuentes de datos más grandes y complejas, más rápido y rentable.

Solución de lago de datos en tiempo real

Para cumplir con sus requisitos, Ruparupa introdujo un lago de datos mutable, como se muestra en el siguiente diagrama.

Veamos cada componente principal con más detalle.

Proceso CDC de AWS DMS

Para obtener los datos en tiempo real de la fuente, transmitimos el registro de CDC de la base de datos mediante AWS DMS (componente 1 en el diagrama de arquitectura). Los registros de CDC constan de todas las inserciones, actualizaciones y eliminaciones de la base de datos de origen. Estos datos sin procesar se almacenan en la capa sin procesar del lago de datos S3.

Se usa una política de ciclo de vida de S3 para administrar la retención de datos, donde los datos más antiguos se mueven a Glaciar Amazon S3.

Trabajo ETL de AWS Glue

La segunda capa del lago de datos de S3 es la capa transformada, donde los datos se transforman a un formato optimizado que está listo para la consulta del usuario. Los archivos se transforman al formato de columnas de Parquet con compresión rápida y partición de tablas para optimizar las consultas SQL de Athena.

Para crear un lago de datos mutable que pueda fusionar los cambios de la fuente de datos, introdujimos un marco de lago de datos Apache Hudi. Con Apache Hudi, podemos realizar modificaciones y eliminaciones en la capa transformada para mantener la coherencia de los datos de manera confiable. Con un lago de datos Hudi, Ruparupa puede crear una única fuente de verdad para todas nuestras fuentes de datos de forma rápida y sencilla. El marco Hudi se ocupa de los metadatos subyacentes de las actualizaciones, lo que facilita su implementación en cientos de tablas en el lago de datos. Solo necesitamos configurar la salida del escritor para crear una tabla de copia en escritura según los requisitos de acceso. Para el escritor, usamos un escritor de trabajo de AWS Glue combinado con un conector Hudi de AWS Glue de AWS Marketplace. La biblioteca adicional del conector ayuda a AWS Glue a comprender cómo escribir en Hudi.

Se utiliza un trabajo ETL de AWS Glue para obtener los cambios de la capa sin procesar y fusionar los cambios en la capa transformada (componente 2 en el diagrama de arquitectura). Con AWS Glue, podemos crear un trabajo de PySpark para obtener los datos y usamos el Conector de AWS Glue para Apache Hudi para simplificar la importación de la biblioteca Hudi al trabajo de AWS Glue. Con AWS Glue, todos los cambios de AWS DMS se pueden fusionar fácilmente con el lago de datos de Hudi. Los trabajos se programan cada hora mediante un programador integrado en AWS Glue.

Secrets Manager se usa para almacenar todos los parámetros relacionados que se requieren para ejecutar el trabajo. En lugar de realizar un trabajo de transformación para cada tabla, Ruparupa crea un solo trabajo genérico que puede transformar varias tablas utilizando varios parámetros. Los parámetros que brindan detalles sobre la estructura de la tabla se almacenan en Secrets Manager y se pueden recuperar usando el nombre de la tabla como clave. Con estos parámetros personalizados, Ruparupa no necesita crear un trabajo para cada tabla; podemos utilizar un solo trabajo que puede ingerir los datos para todas las tablas diferentes pasando el nombre de la tabla al trabajo.

Todos los metadatos de las tablas se almacenan en AWS Glue Data Catalog, incluidas las tablas de Hudi. Este catálogo lo utiliza el trabajo de ETL de AWS Glue, el motor de consultas de Athena y el panel de QuickSight.

Consultas de Atenea

Luego, los usuarios pueden consultar los datos más recientes para su informe utilizando Athena (componente 3 en el diagrama de arquitectura). Athena no tiene servidor, por lo que no hay infraestructura que aprovisionar o mantener. Podemos usar SQL de inmediato para consultar el lago de datos para crear un informe o ingerir los datos en el tablero.

Panel de control QuickSight

Los usuarios comerciales pueden usar un tablero de QuickSight para consultar el lago de datos (componente 4 en el diagrama de arquitectura). El tablero existente se modifica para obtener datos de Athena, reemplazando la base de datos anterior. También se crearon nuevos tableros para satisfacer las necesidades en constante evolución de información de múltiples unidades de negocios.

QuickSight también se usa para notificar a ciertas partes cuando un valor está alcanzando un cierto umbral. Se envía una alerta por correo electrónico a una plataforma externa de notificación y mensajería para que pueda llegar al usuario final.

Resultados comerciales

La implementación del lago de datos en Ruparupa tomó alrededor de 3 meses, con un mes adicional para la validación de datos, antes de que se considerara listo para la producción. Con esta solución, la administración puede obtener la última vista de información de su estado actual hasta la última hora. Anteriormente, solo podían generar informes semanales; ahora, las perspectivas están disponibles 1 veces más rápido.

El panel de QuickSight, que se puede actualizar automáticamente, reduce el tiempo requerido por el equipo analítico. El panel de control de QuickSight ahora tiene más contenido: no solo se informan los datos transaccionales, sino también otras métricas como nuevos SKU, escalamiento de operaciones para servicios gratuitos a los clientes y monitoreo de SLA. Desde abril de 2021, cuando Ruparupa inició su programa piloto QuickSight, la cantidad de paneles aumentó a alrededor de 70 según las solicitudes de los usuarios comerciales.

Ruparupa ha contratado nuevo personal para unirse al equipo de análisis de datos para explorar nuevas posibilidades y nuevos casos de uso. El equipo analítico ha crecido de una sola persona a siete para manejar nuevos casos de uso analítico:

• Especializados
• Operaciones
• Medición del desempeño del gerente de la tienda
• Perspectivas de SKU de tendencia

Kawan Lama Group también tiene tiendas fuera de línea además de la plataforma de comercio electrónico administrada por Ruparupa. Con el nuevo tablero, es más fácil comparar datos de transacciones de tiendas en línea y fuera de línea porque ahora usan la misma plataforma.

Los nuevos tableros también pueden ser consumidos por una audiencia más amplia, incluidas otras unidades comerciales en Kawan Lama Group. El total de usuarios que consumían el tablero aumentó de solo 20 usuarios de administración a alrededor de 180 usuarios (un aumento de 9 veces).

Desde la implementación, otras unidades comerciales de Kawan Lama Group han aumentado su confianza en la plataforma de lago de datos S3 implementada por Ruparupa, porque los datos están más actualizados y pueden profundizar hasta el nivel de SKU para validar que los datos son correctos. Otras unidades de negocio ahora pueden actuar más rápido después de un evento como una campaña de marketing. Esta implementación del lago de datos ha ayudado a aumentar los ingresos por ventas en varias unidades comerciales de Kawan Lama Group.

Conclusión

La implementación de un lago de datos en tiempo real con Amazon S3, Apache Hudi, AWS Glue, Athena y QuickSight le dio a Ruparupa los siguientes beneficios:

• Proporcionó información más rápida (por hora en comparación con semanalmente)
• Desbloqueó nuevos conocimientos
• Habilitó a más personas en más unidades de negocios para consumir el tablero
• Ayudó a las unidades de negocios en Kawan Lama Group a actuar más rápido y aumentar los ingresos por ventas

Si está interesado en obtener beneficios similares, consulte Cree una base de lago de datos con AWS Glue y Amazon S3.

También puede aprender cómo comenzar con QuickSight en el Guía de inicio.

Por último, pero no menos importante, puede obtener información sobre cómo ejecutar Apache Hudi en AWS Glue en Escritura en tablas de Apache Hudi con AWS Glue Custom Connector.

Acerca de los autores

olivia michele es líder científica de datos en Ruparupa, donde ha trabajado en una variedad de roles de datos durante los últimos 5 años, incluida la creación e integración de sistemas de datos de Ruparupa con AWS para mejorar la experiencia del usuario con datos y herramientas de informes. Le apasiona convertir la información sin procesar en información valiosa y procesable y brindar valor a la empresa.

Dariswan Janweri P. es ingeniero de datos en Ruparupa. Considera los desafíos o problemas como acertijos interesantes y encuentra satisfacción en resolverlos, y aún más satisfacción en poder ayudar a sus colegas y amigos, “dos pájaros de un tiro”. Está emocionado de ser un jugador importante en la transformación tecnológica de Indonesia.

Adrianus Budiardjo Kurnadi es Arquitecto de Soluciones Sénior en Amazon Web Services Indonesia. Tiene una gran pasión por las bases de datos y el aprendizaje automático, y trabaja en estrecha colaboración con la comunidad de aprendizaje automático de Indonesia para presentarles varios servicios de aprendizaje automático de AWS. En su tiempo libre, disfruta cantar en un coro, leer y jugar con sus dos hijos.

Nico Anandito es un arquitecto de soluciones especialista en análisis en Amazon Web Services Indonesia. Tiene años de experiencia trabajando en integración de datos, almacenes de datos e implementación de big data en múltiples industrias. Está certificado en análisis de datos de AWS y tiene una maestría en el campo de administración de datos de informática.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/how-ruparupa-gained-updated-insights-with-an-amazon-s3-data-lake-aws-glue-apache-hudi-and-amazon-quicksight/