Esta es una publicación de invitado en coautoría de Mahesh Vandi Chalil, director de tecnología de BookMyShow.

BookMyShow (BMS), una empresa de entretenimiento líder en la India, ofrece una plataforma de venta de entradas en línea para películas, obras de teatro, conciertos y eventos deportivos. BookMyShow, que vende hasta 200 millones de boletos con una tasa de ejecución anual (pre-COVID) a clientes en India, Sri Lanka, Singapur, Indonesia y Medio Oriente, también ofrece un servicio de transmisión de medios en línea y administración integral para experiencias de entretenimiento virtuales y en el suelo en todos los géneros.

La pandemia le dio a BMS la oportunidad de migrar y modernizar nuestra solución de análisis de 15 años a una arquitectura de datos moderna en AWS. Esta arquitectura es una arquitectura moderna, segura, gobernada y rentable, con la capacidad de escalar a petabytes. BMS migró y modernizó desde las instalaciones y otras plataformas en la nube a AWS en solo cuatro meses. Este proyecto se ejecutó en paralelo con nuestro proyecto de migración de aplicaciones y logró un ahorro de costos del 90 % en almacenamiento y un ahorro de costos del 80 % en análisis.

La plataforma de análisis de BMS satisface las necesidades comerciales de ventas y marketing, finanzas y socios comerciales (por ejemplo, cines y propietarios de eventos), y proporciona funcionalidad de aplicación para equipos de audiencia, personalización, fijación de precios y ciencia de datos. La solución de análisis anterior tenía varias copias de datos, por un total de más de 40 TB, con aproximadamente 80 TB de datos en otro almacenamiento en la nube. Los datos se almacenaron en las instalaciones y en la nube en varios almacenes de datos. Al crecer orgánicamente, los equipos tenían la libertad de elegir su pila de tecnología para proyectos individuales, lo que condujo a la proliferación de diversas herramientas, tecnologías y prácticas. Los equipos individuales de personalización, audiencia, ingeniería de datos, ciencia de datos y análisis utilizaron una variedad de productos para la ingesta, el procesamiento de datos y la visualización.

Esta publicación analiza el proceso de migración y modernización de BMS y cómo BMS, AWS y los socios de AWS Minfy Tecnologías El equipo trabajó en conjunto para completar con éxito la migración en cuatro meses y ahorrar costos. Los principios de la migración usando el Arquitectura de datos moderna de AWS hizo que el proyecto fuera un gran éxito.

Desafíos en la plataforma de análisis anterior

• Tecnología variada: Múltiples equipos utilizaron varios productos, idiomas y versiones de software.
• Proyecto de migración más grande: debido a que la modernización de análisis fue un proyecto paralelo con la migración de aplicaciones, la planificación fue crucial para considerar los cambios en las aplicaciones principales y los cronogramas del proyecto.
• Recursos: experimentó la rotación de recursos del proyecto de migración de aplicaciones y tenía muy poca documentación de los sistemas actuales.
• Datos: Tenía múltiples copias de datos y ninguna fuente única de verdad; cada almacén de datos proporcionó una vista para la unidad de negocio.
• Canalizaciones de ingesta: las canalizaciones de datos complejas movieron datos a través de varios almacenes de datos con frecuencias variadas. Teníamos varios enfoques para ingerir datos en Cloudera, a través de más de 100 consumidores de Kafka de sistemas de transacciones y MQTT (protocolo de mensajería de transporte de telemetría de cola de mensajes) para secuencias de clics, procedimientos almacenados y trabajos de Spark. Tuvimos aproximadamente 100 trabajos para la ingestión de datos en Spark, Alteryx, Beam, NiFi y más.
• Clústeres de Hadoop: gran hardware dedicado en el que se configuraron los clústeres de Hadoop, lo que incurrió en costos fijos. La configuración local de Cloudera se adaptó a la mayoría de las cargas de trabajo de procesamiento por lotes de personalización, audiencia e ingeniería de datos. Los equipos tuvieron su implementación de HBase y Hive para nuestra audiencia y aplicaciones de personalización.
• Almacén de datos: el equipo de ingeniería de datos usó TiDB como su almacén de datos local. Sin embargo, cada equipo de consumidores tenía su propia perspectiva de los datos necesarios para el análisis. A medida que esta arquitectura en silos evolucionó, resultó en altos costos operativos y de almacenamiento para mantener estos entornos separados.
• Base de datos de análisis: el equipo de análisis utilizó datos obtenidos de otros sistemas transaccionales y datos desnormalizados. El equipo tenía su propia tubería de extracción, transformación y carga (ETL), usando Alteryx con una herramienta de visualización.

Se siguieron los principios de migración que llevaron al éxito del proyecto:

• Priorizar por funcionalidad empresarial.
• Aplique las mejores prácticas al crear una arquitectura de datos moderna desde el día 1.
• Mueva solo los datos necesarios, canonicalice los datos y almacénelos en el formato más óptimo en el destino. Elimine la redundancia de datos tanto como sea posible. Marque el alcance de la optimización para el futuro cuando los cambios sean intrusivos.
• Cree la arquitectura de datos teniendo en cuenta los formatos de datos, los volúmenes, la gobernanza y la seguridad.
• Simplifique ELT y el procesamiento de trabajos categorizando los trabajos como rehospedados, reescritos y retirados. Finalice el formato de datos canónicos, la transformación, el enriquecimiento, la compresión y el formato de almacenamiento como Parquet.
• Rehospede trabajos de aprendizaje automático (ML) que eran críticos para el negocio.
• Trabaje hacia atrás para lograr nuestros objetivos, elimine obstáculos y modifique las decisiones para avanzar.
• Utilice las opciones sin servidor como primera opción y pague por uso. Evalúe el costo y el esfuerzo de rediseñar para seleccionar el enfoque correcto. Ejecute una prueba de concepto para validar esto para cada componente y servicio.

Estrategias aplicadas para tener éxito en esta migración:

• Equipo – Creamos un equipo unificado con personas de ingeniería de datos, análisis y ciencia de datos como parte del proyecto de migración de análisis. Los equipos de ingeniería de confiabilidad del sitio (SRE) y de aplicaciones participaron cuando se necesitaban decisiones críticas con respecto a los datos o el cronograma para la alineación. Los equipos de análisis, ingeniería de datos y ciencia de datos dedicaron un tiempo considerable a la planificación, la comprensión del código y la observación iterativa de las fuentes de datos existentes, las canalizaciones de datos y los trabajos de procesamiento. El equipo de AWS con el equipo de socios de Minfy Technologies ayudó a BMS a llegar a un plan de migración después de una prueba de concepto para cada uno de los componentes en la ingesta de datos, el procesamiento de datos, el almacenamiento de datos, el aprendizaje automático y los paneles de análisis.
• Talleres – El equipo de AWS realizó una serie de talleres y días de inmersión, y entrenó al equipo de BMS sobre la tecnología y las mejores prácticas para implementar los servicios de análisis. El equipo de AWS ayudó a BMS a explorar la configuración y los beneficios del enfoque de migración para cada escenario (migración de datos, canalización de datos, procesamiento de datos, visualización y aprendizaje automático) mediante pruebas de concepto (POC). El equipo capturó los cambios necesarios en el código existente para la migración. El equipo de BMS también se familiarizó con los siguientes servicios de AWS:
• Prueba de concepto – El equipo de BMS, con la ayuda del socio y el equipo de AWS, implementó varias pruebas de concepto para validar el enfoque de migración:
  • Procesamiento por lotes de trabajos de Spark en Amazon EMR, en el que verificamos el tiempo de ejecución, los cambios de código requeridos y el costo.
  • Ejecutó trabajos de análisis de flujo de clics en Amazon EMR, probando la canalización de un extremo a otro. El equipo realizó pruebas de concepto en Núcleo de AWS IoT para protocolo MQTT y transmisión a Amazon S3.
  • Modelos de ML migrados a Amazon SageMaker y orquestados con Amazon MWAA.
  • Creé informes y paneles QuickSight de muestra, en los que se evaluaron las características y el tiempo de construcción.
  • Configurado para escenarios clave para Amazon Redshift, en los que se evaluaron el tiempo de carga de datos, el rendimiento de las consultas y el costo.
• Análisis de esfuerzo vs costo – El equipo realizó las siguientes evaluaciones:
  • Comparó las canalizaciones de ingesta, la diferencia en la estructura de datos en cada tienda, la base de la necesidad comercial actual para la fuente de datos, la actividad para preprocesar los datos antes de la migración, la migración de datos a Amazon S3 y la captura de datos modificados (CDC) desde el aplicaciones migradas en AWS.
  • Evaluó el esfuerzo de migrar aproximadamente 200 trabajos, determinó qué trabajos eran redundantes o necesitaban mejoras desde una perspectiva funcional y completó una lista de migración para el estado de destino. La modernización del código de flujo de trabajo MQTT a serverless llevó mucho tiempo, decidió volver a alojar en Nube informática elástica de Amazon (Amazon EC2) y modernización para Kinesis amazónica en la siguiente fase.
  • Revisó más de 400 informes y paneles, priorizó el desarrollo en fases y reevaluó las necesidades de los usuarios comerciales.

Servicios en la nube de AWS elegidos para la arquitectura propuesta:

• Lago de datos – Utilizamos Amazon S3 como el lago de datos para almacenar la verdad única de la información para todos los datos sin procesar y procesados, lo que reduce las copias de almacenamiento de datos y los costos de almacenamiento.
• Ingestión – Debido a que teníamos varias fuentes de información en la arquitectura actual, llegamos a una estructura común antes de la migración a Amazon S3 y las canalizaciones existentes se modificaron para realizar el preprocesamiento. Estos trabajos de preprocesamiento únicos se ejecutaron en Cloudera, porque los datos de origen eran locales, y en Amazon EMR para los datos en la nube. Diseñamos nuevas canalizaciones de datos para la ingesta de sistemas transaccionales en la nube de AWS mediante AWS Glue ETL.
• Procesamiento – Los trabajos de procesamiento se segregaron según el tiempo de ejecución en dos categorías: por lotes y casi en tiempo real. Los procesos por lotes se dividieron aún más en clústeres transitorios de Amazon EMR con diferentes tiempos de ejecución y requisitos de aplicaciones de Hadoop como HBase. Los trabajos casi en tiempo real se aprovisionaron en un clúster permanente de Amazon EMR para análisis de flujo de clics y una canalización de datos de sistemas transaccionales. Adoptamos un enfoque sin servidor utilizando AWS Glue ETL para nuevas canalizaciones de datos de sistemas transaccionales en la nube de AWS.
• Almacén de datos – Elegimos Amazon Redshift como nuestro almacén de datos y planificamos cómo se distribuirían los datos en función de los patrones de consulta.
• Visualización – Creamos los informes en Amazon QuickSight en fases y los priorizamos en función de la demanda comercial. Discutimos con los usuarios comerciales sus necesidades actuales e identificamos los informes inmediatos requeridos. Definimos las fases de creación de informes y tableros y construimos los informes en Amazon QuickSight. Planeamos utilizar informes integrados para usuarios externos en el futuro.
• Aprendizaje automático – Se implementaron modelos de ML personalizados en Amazon SageMaker. Los DAG de Airflow existentes se migraron a Amazon MWAA.
• Gobernanza, seguridad y cumplimiento – Gobernanza con Formación del lago Amazonas se adoptó desde el día 1. Configuramos AWS Glue Data Catalog para hacer referencia a los datos utilizados como orígenes y destinos. Tuvimos que cumplir con las pautas de la industria de tarjetas de pago (PCI) porque la información de pago estaba en el lago de datos, por lo que garantizamos las políticas de seguridad necesarias.

Resumen de la solución

Arquitectura de datos moderna de BMS

El siguiente diagrama ilustra nuestra arquitectura de datos moderna.

La arquitectura incluye los siguientes componentes:

1. Sistemas de origen – Estos incluyen lo siguiente:
   • Datos de sistemas transaccionales almacenados en MariaDB (reservas y transacciones).
   • Datos del flujo de clics de la interacción del usuario a través de los consumidores de Kafka a DataOps MariaDB.
   • Miembros e información de asignación de asientos de MongoDB.
   • SQL Server para ofertas específicas e información de pago.
2. Canal de datos – Los trabajos de Spark en un clúster permanente de Amazon EMR procesan los datos de flujo de clics de los clústeres de Kafka.
3. Lago de datos – Los datos de los sistemas de origen se almacenaron en sus respectivos depósitos de Amazon S3, con prefijos para consultas de datos optimizadas. Para Amazon S3, seguimos una jerarquía para almacenar datos sin procesar, resumidos y relacionados con el equipo o el servicio en diferentes carpetas principales según la fuente y el tipo de datos. Se agregaron políticas de ciclo de vida a registros y carpetas temporales de diferentes servicios según los requisitos de los equipos.
4. Proceso de datos – Los clústeres transitorios de Amazon EMR se utilizan para procesar datos en un formato seleccionado para los equipos de audiencia, personalización y análisis. Los trabajos de fusión de archivos pequeños fusionan los datos del flujo de clics en un tamaño de archivo más grande, lo que ahorra costos para consultas únicas.
5. Gobierno – AWS Lake Formation permite el uso de rastreadores de AWS Glue para capturar el esquema de los datos almacenados en el lago de datos y los cambios de versión en el esquema. El catálogo de datos y la política de seguridad en AWS Lake Formation permiten el acceso a los datos para roles y usuarios en Amazon Redshift, Amazon Athena, Amazon QuickSight y trabajos de ciencia de datos. Los trabajos ETL de AWS Glue cargan los datos procesados ​​en Amazon Redshift a intervalos programados.
6. Consultas – El equipo de análisis utilizó Amazon Athena para realizar consultas únicas planteadas por los equipos comerciales en el lago de datos. Debido a que el desarrollo de informes se realiza en fases, se utilizó Amazon Athena para exportar datos.
7. Almacén de datos – Se utilizó Amazon Redshift como almacén de datos, donde se procesan y almacenan los informes para los equipos de ventas, la gerencia y terceros (es decir, teatros y eventos) para una recuperación rápida. Aquí se configuran las vistas para analizar las ventas totales, las tendencias de venta de películas, el comportamiento de los miembros y los modos de pago. Usamos vistas materializadas para tablas desnormalizadas, diferentes esquemas para metadatos y datos transaccionales y de comportamiento.
8. Informes – Usamos los informes de Amazon QuickSight para varios casos de uso de productos, negocios y marketing.
9. Aprendizaje automático – Algunos de los modelos implementados en Amazon SageMaker son los siguientes:
   • Popularidad del contenido – Decide el contenido recomendado para los usuarios.
   • Popularidad de eventos en vivo – Calcula la popularidad de los eventos de entretenimiento en vivo en diferentes regiones.
   • Tendencias de búsquedas – Identifica las búsquedas de tendencias en todas las regiones.

Tutorial

Pasos de ejecución de la migración

Estandarizamos herramientas, servicios y procesos para ingeniería de datos, análisis y ciencia de datos:

• Lago de datos
  • Identificó los datos de origen que se migrarán desde Archival DB, BigQuery, TiDB y la base de datos de análisis.
  • Desarrolló un modelo de datos canónicos que se adaptaba a múltiples equipos comerciales y redujo las copias de datos y, por lo tanto, los costos operativos y de almacenamiento. Trabajos existentes modificados para facilitar la migración a un formato canónico.
  • Identificó los sistemas de origen, la capacidad requerida, el crecimiento previsto, los propietarios y los requisitos de acceso.
  • Ejecuté la migración masiva de datos a Amazon S3 desde varias fuentes.
• Ingestión
  • Sistemas de transacciones – Retuvo las colas y los consumidores de Kafka existentes.
  • Datos de flujo de clics – Realizó con éxito una prueba de concepto para usar AWS IoT Core para el protocolo MQTT. Pero debido a que necesitábamos realizar cambios en la aplicación para publicar en AWS IoT Core, decidimos implementarlo como parte de la modernización de la aplicación móvil en un momento posterior. Decidimos volver a alojar el servidor MQTT en Amazon EC2.
• Procesamiento
• Enumeró las canalizaciones de datos relevantes para el negocio y las migró con modificaciones mínimas.
• Cargas de trabajo categorizadas en trabajos críticos, trabajos redundantes o trabajos que se pueden optimizar:
  • Los trabajos de Spark se migraron a Amazon EMR.
  • Los trabajos de HBase se migraron a Amazon EMR con HBase.
  • Los metadatos almacenados en trabajos basados ​​en Hive se modificaron para usar AWS Glue Data Catalog.
  • Los trabajos de NiFi se simplificaron y reescribieron en Spark run en Amazon EMR.
• Los clústeres de Amazon EMR se configuraron como un clúster persistente para transmitir el flujo de clics y las cargas de trabajo de personalización. Utilizamos varios clústeres transitorios para ejecutar todos los demás trabajos de procesamiento o ETL de Spark. Usamos instancias de spot para nodos de tareas para ahorrar costos. Optimizamos el almacenamiento de datos con trabajos específicos para fusionar archivos pequeños y conversiones de formato de archivo comprimido.
• Los rastreadores de AWS Glue identificaron nuevos datos en Amazon S3. Los trabajos ETL de AWS Glue transformaron y cargaron datos procesados ​​en el almacén de datos de Amazon Redshift.
• Almacén de datos
  • Definí el esquema del almacén de datos clasificando los informes críticos requeridos por el negocio, teniendo en cuenta la carga de trabajo y los informes necesarios en el futuro.
  • Definió el área de preparación para datos incrementales cargados en Amazon Redshift, materializó vistas y ajustó las consultas según el uso. Los metadatos primarios y de transacciones se almacenan en Amazon Redshift para satisfacer todos los requisitos de informes y análisis de datos. Creamos vistas materializadas y tablas desnormalizadas en Amazon Redshift para utilizarlas como fuentes de datos para los paneles de Amazon QuickSight y los trabajos de segmentación, respectivamente.
  • Usó de manera óptima el clúster de Amazon Redshift al cargar los datos de los últimos dos años en Amazon Redshift y usó Espectro de Redshift de Amazon para consultar datos históricos a través de tablas externas. Esto ayudó a equilibrar el uso y el costo del clúster de Amazon Redshift.
• Visualización
  • Los tableros de Amazon QuickSight se crearon para el equipo de ventas y marketing en la Fase 1:
    • Informe resumen de ventas – Un tablero de resumen ejecutivo para obtener una descripción general de las ventas en todo el país por región, ciudad, película, teatro, género y más.
    • Entretenimiento en vivo – Un informe dedicado para eventos verticales de entretenimiento en vivo.
    • Los cupones – Un informe de cupones comprados y redimidos.
    • LibroASmile – Un panel para analizar los datos de BookASmile, una iniciativa benéfica.
• Aprendizaje automático
  • Enumeró las cargas de trabajo de ML que se migrarán en función de las necesidades comerciales actuales.
  • Los trabajos de procesamiento de ML prioritarios se implementaron en Amazon EMR. Los modelos se modificaron para usar Amazon S3 como fuente y destino, y se expusieron nuevas API para usar la funcionalidad. Los modelos ML se implementaron en Amazon SageMaker para películas, análisis de flujo de clics de eventos en vivo y personalización.
  • Los artefactos existentes en la orquestación de Airflow se migraron a Amazon MWAA.
• Seguridad
  • AWS Lake Formation fue la base del lago de datos, con AWS Glue Data Catalog como base para el catálogo central de los datos almacenados en Amazon S3. Esto proporcionó acceso a los datos por varias funcionalidades, incluidos los equipos de audiencia, personalización, análisis y ciencia de datos.
  • La información de identificación personal (PII) y los datos de pago se almacenaron en el lago de datos y el almacén de datos, por lo que teníamos que cumplir con las pautas de PCI. Se consideró y configuró el cifrado de datos en reposo y en tránsito en cada nivel de servicio (Amazon S3, AWS Glue Data Catalog, Amazon EMR, AWS Glue, Amazon Redshift y QuickSight). Se enumeraron y configuraron roles, responsabilidades y permisos de acceso claros para diferentes grupos de usuarios y privilegios en Gestión de identidades y accesos de AWS (IAM) y servicios individuales.
  • Se utilizó la integración existente de inicio de sesión único (SSO) con Microsoft Active Directory para el acceso de los usuarios de Amazon QuickSight.
• Automatización
  • Se utilizó Formación en la nube de AWS para la creación y modificación de todos los servicios básicos y analíticos.
  • AWS Step Functions se utilizó para orquestar trabajos de Spark en Amazon EMR.
  • Los trabajos programados se configuraron en AWS Glue para cargar datos en Amazon Redshift según las necesidades comerciales.
  • El seguimiento de los servicios de análisis se realizó utilizando Reloj en la nube de Amazon métricas, y se logró el tamaño correcto de las instancias y la configuración. El rendimiento del trabajo de Spark en Amazon EMR se analizó mediante los registros nativos de Spark y la interfaz de usuario (IU) de Spark.
  • Se aplicaron políticas de ciclo de vida al lago de datos para optimizar los costos de almacenamiento de datos a lo largo del tiempo.

Beneficios de una arquitectura de datos moderna

Una arquitectura de datos moderna nos ofreció los siguientes beneficios:

• Escalabilidad – Pasamos de una infraestructura fija a la infraestructura mínima requerida, con configuración para escalar bajo demanda. Servicios como Amazon EMR y Amazon Redshift nos permiten hacer esto con solo unos pocos clics.
• Agilidad – Utilizamos servicios administrados especialmente diseñados en lugar de reinventar la rueda. La automatización y el monitoreo fueron consideraciones clave, que nos permiten realizar cambios rápidamente.
• Sin servidor – Adopción de servicios sin servidor como Amazon S3, AWS Glue, Amazon Athena, AWS Step Functions y AWS Lambda apóyenos cuando nuestro negocio tenga picos repentinos con nuevas películas o eventos lanzados.
• En ahorro de costes – Nuestro tamaño de almacenamiento se redujo en un 90%. Nuestro gasto general en análisis y ML se redujo en un 80 %.

Conclusión

En esta publicación, le mostramos cómo una arquitectura de datos moderna en AWS ayudó a BMS a compartir datos fácilmente a través de los límites de la organización. Esto permitió a BMS tomar decisiones con rapidez y agilidad a escala; garantizar el cumplimiento a través del acceso a datos, la seguridad y la gobernanza unificados; y para escalar sistemas a bajo costo sin comprometer el rendimiento. Trabajar con los equipos de AWS y Minfy Technologies ayudó a BMS a elegir los servicios de tecnología correctos y completar la migración en cuatro meses. BMS logró los objetivos de escalabilidad y optimización de costos con esta arquitectura actualizada, que sentó las bases para la innovación mediante el uso de bases de datos gráficas y mejoró nuestros proyectos de ML para mejorar la experiencia del cliente.

Acerca de los autores

Mahesh Vandi Chalil es director de tecnología en BookMyShow, el principal destino de entretenimiento de la India. Mahesh tiene más de dos décadas de experiencia global, apasionado por la creación de productos escalables que deleiten a los clientes mientras mantiene la innovación como el objetivo principal que motiva a su equipo a aspirar constantemente a estos. Mahesh invierte sus energías en crear y nutrir a la próxima generación de líderes tecnológicos y emprendedores, tanto dentro como fuera de la organización. Orgulloso esposo y padre de dos hijas, juega críquet en su tiempo libre.

priya jathar es un arquitecto de soluciones que trabaja en el segmento de negocios nativos digitales en AWS. Tiene más de dos décadas de experiencia en TI, con experiencia en desarrollo de aplicaciones, bases de datos y análisis. Es una constructora que disfruta innovar con nuevas tecnologías para lograr objetivos de negocio. Actualmente ayuda a los clientes a migrar, modernizar e innovar en la nube. En su tiempo libre le gusta pintar y perfeccionar sus habilidades de jardinería y cocina.

Vatsal Shah es arquitecto sénior de soluciones en AWS con sede en Mumbai, India. Tiene más de nueve años de experiencia en la industria, incluidos roles de liderazgo en ingeniería de productos, SRE y arquitectura en la nube. Actualmente se enfoca en permitir que las grandes empresas emergentes optimicen sus operaciones en la nube y las ayuden a escalar en la nube. También se especializa en casos de uso de inteligencia artificial y aprendizaje automático.

• 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-bookmyshow-saved-80-in-costs-by-migrating-to-an-aws-modern-data-architecture/