Glovo administra 2 TB de datos a diario con AWS

Glovo, uno de los líderes mundiales del sector de pedidos a domicilio, recibe actualmente 2 TB de datos al día procedentes de pedidos en línea y ofertas de sus proveedores. Para la multinacional española, es fundamental que dichos volúmenes tan elevados de datos afecten de la menor medida posible a un servicio al cliente excepcional. Utilizar soluciones de Amazon Web Services les ha permitido lograr este objetivo.

Glovo se creó en 2015 en Barcelona, y su actividad principal es la entrega de pedidos de comida a domicilio. En la actualidad, la aplicación está presente en 25 países y en más de 1300 ciudades, con más de 150 000 restaurantes y establecimientos asociados. Además de los mejores restaurantes, pone a disposición de sus usuarios todo tipo de negocios, incluidos supermercados, establecimientos de dispositivos electrónicos, comercios de salud y belleza o tiendas de regalos, entre otros.

Glovo cuenta con un fuerte componente tecnológico y una plataforma que conecta a clientes, empresas y repartidores mediante su sitio web y la aplicación móvil. De manera diaria, administra un volumen de datos de 2 TB. “Como compañía que está creciendo con rapidez y con volúmenes de demanda de datos (casos de uso y cantidades) cada vez mayores, es fundamental para el éxito de Glovo contar con una estructura sólida en cuanto a la manera de recopilar, cotejar y utilizar los datos, a fin de lograr el mayor impacto posible en nuestro negocio”, explica Oliver Fenton, director de plataforma de datos de Glovo.

La protección de los datos personales de los usuarios es de vital importancia para Glovo, y siempre garantiza la máxima seguridad. “AWS nos ha permitido cumplir el objetivo de almacenar datos de manera segura y poder acceder a ellos cuando sea necesario, siempre de acuerdo con todas las normativas aplicables”, afirma Oliver Fenton. 

Glovo recurrió a Amazon Web Services para la primera iteración de su plataforma de datos. Tomaron la decisión gracias a las recomendaciones de algunos de los miembros del equipo de datos, que ya eran usuarios de las soluciones de AWS. El producto elegido para comenzar a desarrollar esta plataforma de datos fue Amazon Redshift, un servicio de almacenamiento de datos administrado en la nube. “Era muy fácil comenzar a utilizarlo y lo bastante potente como para satisfacer todas nuestras necesidades”, reconoce Fenton. A esta capa de análisis de datos que se ejecuta en Amazon Redshift pronto le siguieron casos de uso de ETL: “lo primero era la tabulación de los datos sin procesar (cerca de 100 de datos sin procesar por día). Para lograr este objetivo, utilizamos la plataforma de macrodatos Amazon EMR. De manera específica, tecnología de Apache Spark sobre clústeres efímeros de Amazon EMR ejecutándose en instancias de Amazon EC2, con el objetivo de procesar los datos sin procesar en Amazon S3 y crear tablas analíticas, también almacenadas en S3 y registradas en el catálogo de datos de AWS Glue”.

Sin embargo, “poco después, se comenzaron a desarrollar procesos de ETL propios a partir de estos datos. El procesamiento también se realizaba mediante Spark en Amazon EMR (EC2) y se orquestaba a través del módulo Luigi, un orquestador de código abierto desarrollado por Spotify, implementado en una instancia de EC2. Algunos resultados de estos procesos de ETL necesitaban estar disponibles en nuestra herramienta de inteligencia empresarial de Looker BI y, debido a ciertas limitaciones en nuestros procesos en ese momento, también teníamos que producir copias en Amazon Redshift”.

A medida que el negocio de Glovo iba creciendo de manera exponencial, su plataforma de datos seguía escalándose y se hacía necesario abarcar diferentes casos de uso. Se detectó la necesidad de aumentar la frecuencia de actualización para mejorar la disponibilidad de los datos operativos, así que se diseñó Importer, una herramienta de ingesta de datos que saca partido de las capacidades de Apache Spark en Amazon EMR (ejecutándose en EC2) para extraer datos de bases de datos transaccionales que se ejecutan en Amazon Aurora y otros tipos de orígenes, y transmitirlos al lago de datos en Amazon S3. De esta manera, se garantiza que estos datos están disponibles como tablas. “Estas tablas se creaban con datos en formato Delta, y todo el proceso de extracción y uso de Importer se orquestaba a través de Luigi ejecutándose en una instancia de EC2”, prosigue explicando el director de la plataforma de datos de la compañía de reparto a domicilio.

En paralelo al trabajo de los equipos de datos en Glovo, los desarrolladores de la aplicación comenzaron a adoptar arquitecturas de microservicios, lo que generaba nuevos casos de uso de administración de datos: “el backend comenzó a estar dividido en microservicios. La comunicación entre procesos se realizaba mediante secuencias de Amazon Kinesis. Estos eventos, en formato Avro, eran necesarios para ciertos casos de análisis. Para cargarlos en S3, creamos un marco que llamamos Rivers, con tecnología de Apache Beam y la infraestructura de Amazon Managed Service para Apache Flink, la cual brinda a los eventos una estructura de directorios específica que facilita otro proceso posterior para recopilarlos e integrarlos en las tablas de análisis a través de Importer”.

Todos los casos que se han descrito se ejecutan en una plataforma de datos monolítica, “que no escala”, apunta Oliver Fenton, lo que disminuye el aumento de casos de uso y toma de decisiones empresariales relativos al uso de datos de la compañía. Por este motivo, Glovo ha comenzado la transición hacia una malla de datos, que permite dividir responsabilidades y brindar mayor autonomía respecto al uso de datos a los equipos. “Como parte de este camino, hemos comenzado a crear lo que llamamos canalizaciones de datos autoservicio (Self Service Data Pipelines, SSDP). Para ello, seguimos utilizando Spark en Amazon EMR (EC2) para el procesamiento, pero también incluimos una instancia de Amazon Managed Workflows para Apache Airflow (Amazon MWAA) por dominio de datos, de modo que los equipos de datos tuvieran más control de su propio código e implementaciones. Tanto las aplicaciones Spark como las que no son de Spark están empaquetadas en contenedores de Docker y cargadas en Amazon Elastic Container Registry (Amazon ECR). Las aplicaciones que no son de Spark se ejecutan en Amazon Elastic Container Service (Amazon ECS) en Fargate, mientras que las aplicaciones de Spark se ejecutan en Amazon EMR (EC2) y se benefician de la compatibilidad de YARN con Docker”.

Además, Glovo ha instaurado Starburst como el motor de consultas para su malla de datos. “Comenzamos a utilizar Amazon Elastic Kubernetes Service (Amazon EKS) con los equipos de datos de Glovo para ejecutar nuestro motor de consultas de Starburst, lo que eliminaba de manera potencial la necesidad de contar con Amazon Redshift para ejecutar ciertas consultas de usuario procedentes de Looker. También comenzamos a investigar EMR en EKS para no tener que pagar por el tiempo de activación de los clústeres de EMR (EC2)”, explica Oliver Fenton.

Al utilizar soluciones de AWS, Glovo ha ganado flexibilidad para escalar su plataforma dentro del marco de malla de datos: “en el caso de Amazon EMR, podemos aprovisionar clústeres que estarán activos únicamente durante el tiempo de procesamiento necesario; es posible ajustar el tamaño de cada grupo de forma independiente. Contar con varios clústeres también nos permite aislar con facilidad los diferentes casos de uso”, expone el director técnico de Glovo.

Además, el equipo de datos ha expresado interés en las nuevas capacidades sin servidor disponibles en servicios de AWS, como Amazon EMR o Amazon EKS: “nos permiten iniciar algo y ponerlo en marcha con mayor facilidad, sin tener que conocer todos los detalles subyacentes. El esfuerzo necesario para la implementación y la operación también suele ser menor”. Incluso sin la implementación de modelos puramente sin servidor (dado que AWS los ha lanzado de manera reciente), el uso de una combinación de servicios que se ejecutan en AWS y la adopción de la malla de datos “ha permitido a Glovo reducir el tiempo empleado en crear productos de 5 a 2 semanas”. Gracias a la abundancia de servicios orientados a la captura, procesamiento y uso de datos en AWS, en Glovo hemos sido capaces de crear y escalar una plataforma de datos que respalde nuestro negocio al completo y que evolucione en nuestra transición hacia un modelo organizativo de malla de datos”.

En el futuro, la compañía quiere migrar sus aplicaciones existentes a Amazon Elastic Kubernetes Services (EKS) y ya está investigando la implementación de una capa de gobernanza, seguridad y control de acceso a los datos para permitir una mejor administración del acceso a los datos necesarios para cada caso de uso: “ejecutamos Starburst en EKS y ahora estamos trabajando para que la herramienta de administración de acceso a los datos Privacera se ejecute en Amazon EKS”.  Glovo también está implementando una solución de cuadernos en Amazon EKS (basada en JupyterHub) “para la colaboración en tiempo real en este entorno de desarrollo integrado. De esta manera, analistas y otros perfiles con acceso a los datos que contiene Glovo podrán trabajar con mayor eficacia”, concluye Fenton.