Glovo gestisce 2 TB di dati al giorno con AWS

Leader mondiale nel settore della consegne, Glovo riceve attualmente 2 TB di dati al giorno da ordini online e offerte dai fornitori. Per la multinazionale spagnola, è essenziale che questi elevati volumi di dati abbiano il maggiore impatto possibile nel fornire il miglior servizio ai clienti. L'utilizzo di soluzioni Amazon Web Services gli ha permesso di raggiungere questo obiettivo.

Glovo è nata a Barcellona nel 2015 e si occupa principalmente della consegna a domicilio di ordini alimentari online. Oggi, l'applicazione è presente in 25 paesi e oltre 1.300 città, con più di 150.000 ristoranti ed esercizi commerciali partner. Oltre ai migliori ristoranti, offre agli utenti servizi relativi a tutti i tipi di esercizi commerciali, tra cui supermercati, negozi di elettronica, salute e bellezza, e articoli da regalo.

Glovo ha una forte componente tecnologica e una piattaforma che mette in contatto clienti, aziende e corrieri attraverso il sito Web e l'applicazione mobile. Ogni giorno, gestisce un volume di dati di 2 TB. "Come azienda in rapida crescita, con richieste di dati (casi d'uso e quantità) in rapido aumento, è fondamentale per il successo di Glovo disporre di una solida struttura per raccogliere, confrontare e utilizzare i dati per ottenere il maggior impatto possibile sull'azienda", spiega Oliver Fenton, Data Platform Director (Responsabile della piattaforma dati) di Glovo.

La protezione dei dati personali degli utenti è molto importante per Glovo, che garantisce sempre la massima sicurezza. "Con AWS riusciamo a raggiungere il nostro obiettivo, vale a dire, archiviare i dati in modo sicuro e accedervi quando necessario, rispettando sempre tutte le normative vigenti", afferma Oliver Fenton. 

Glovo si è rivolta ad Amazon Web Services per la prima iterazione della sua piattaforma dati. Questa scelta è stata fatta su suggerimento di alcuni membri del team dati, che già utilizzavano soluzioni AWS. Il prodotto scelto per iniziare a costruire la piattaforma dati è stato Amazon Redshift, un servizio di data warehouse gestito su cloud. "È stato molto facile iniziare a utilizzare questo servizio e si è rivelato abbastanza potente da soddisfare tutte le nostre esigenze", riconosce Fenton. Il livello di analisi dei dati in esecuzione su Amazon Redshift è stato presto seguito da diversi casi d'uso ETL: "Il primo è stato la tabulazione dei dati grezzi (circa 100 GB di dati grezzi al giorno). Per soddisfare questa esigenza, utilizziamo la piattaforma per i big data di Amazon EMR. In particolare, la tecnologia Apache Spark su cluster effimeri Amazon EMR in esecuzione su istanze Amazon EC2, con l'obiettivo di elaborare i dati grezzi in Amazon S3 e costruire le tabelle analitiche, anch'esse archiviate in S3 e registrate nel catalogo dati AWS Glue".

Tuttavia, "poco dopo, le persone hanno iniziato a costruire i propri processi ETL su questi dati. Anche l'elaborazione è stata eseguita in Spark su Amazon EMR (EC2) ed è stata orchestrata tramite il modulo Luigi, un orchestratore open-source sviluppato da Spotify, implementato su un'istanza EC2. Bisognava rendere disponibili alcuni risultati di questi ETL nel nostro strumento Looker BI e, a causa di alcune limitazioni nei processi dell'epoca, dovevamo anche produrre copie in Amazon Redshift".

Mentre l'attività di Glovo cresceva in modo esponenziale, la sua piattaforma dati continuava a dimensionarsi e doveva coprire diversi casi d'uso. Data la necessità di aumentare la frequenza di aggiornamento per migliorare la disponibilità dei dati operativi, è stato creato Importer, uno strumento di importazione dei dati che sfrutta le capacità di Apache Spark su Amazon EMR (in esecuzione su EC2) per estrarre i dati dai database transazionali in esecuzione su Amazon Aurora e da altri tipi di fonti e trasmetterli in streaming al DataLake in Amazon S3. Questa procedura assicura che i dati siano disponibili sotto forma di tabelle. "Le tabelle vengono create utilizzando dati in formato Delta e l'intero processo di estrazione e utilizzo di Importer viene orchestrato attraverso Luigi in esecuzione su un'istanza EC2", continua il responsabile della piattaforma dati dell'azienda di consegne.

Parallelamente al lavoro dei team dati di Glovo, gli sviluppatori di applicazioni hanno iniziato ad adottare architetture a microservizi, generando nuovi casi d'uso per la gestione dei dati: "Il back-end ha iniziato a essere suddiviso in microservizi. La comunicazione tra i processi è stata effettuata utilizzando i flussi di Amazon Kinesis. Questi eventi, in formato Avro, erano necessari per alcuni casi di analisi. Per caricarli in S3, abbiamo creato un framework chiamato Rivers, utilizzando la tecnologia Apache Beam e il servizio gestito da Amazon per Apache Flink, che fornisce agli eventi una specifica struttura di directory, facilitando un processo successivo, vale a dire la raccolta e l'integrazione degli eventi in tabelle analitiche utilizzando Importer".

Tutti i casi sopra descritti vengono eseguiti su una piattaforma dati monolitica, "che non è scalabile", chiarisce Oliver Fenton, il che rallenta l'aumento dei casi d'uso e delle decisioni aziendali sull'utilizzo dei dati da parte dell'azienda. Per questo motivo, Glovo ha iniziato un percorso verso una mesh di dati che consente di dividere le responsabilità e di dare maggiore autonomia ai team in relazione all'utilizzo dei dati. "Nell'ambito di questo percorso, abbiamo iniziato a creare quelle che chiamiamo pipeline di dati self-service (Self Service Data Pipeline, SSDP). Per questo, utilizziamo ancora Spark su Amazon EMR (EC2) per l'elaborazione, ma includiamo anche un'istanza Amazon Managed Workflows for Apache Airflow (MWAA) per ciascun dominio di dati, al fine di consentire ai team dati un maggiore controllo sul proprio codice e sulle proprie implementazioni. Sia le applicazioni Spark che quelle non Spark sono impacchettate in container Docker e caricate in Amazon Elastic Container Registry (ECR). Le applicazioni non Spark vengono eseguite su Amazon Elastic Container Service (Amazon ECS) su Fargate, mentre le applicazioni Spark vengono eseguite su Amazon EMR (EC2) sfruttando il supporto YARN per Docker".

Inoltre, Glovo ha scelto Starburst come motore di query per la sua mesh di dati. "Abbiamo iniziato a utilizzare Amazon Elastic Kubernetes Service (Amazon EKS) all'interno dei team dati di Glovo per eseguire il nostro motore di query Starburst, eliminando potenzialmente la necessità di avere Amazon Redshift come mezzo per eseguire determinate query di utenti da Looker. Abbiamo anche iniziato a esaminare EMR in EKS, per evitare di pagare per il tempo di attivazione dei cluster EMR (EC2)", afferma Oliver Fenton.

Utilizzando le soluzioni AWS, Glovo ha guadagnato flessibilità nello scalare la propria piattaforma all'interno del framework della mesh di dati: "Nel caso di Amazon EMR, possiamo fornire cluster che saranno attivi solo durante il tempo di elaborazione necessario; ogni gruppo può essere dimensionato in modo indipendente. Avere più cluster ci permette anche di isolare facilmente i diversi casi d'uso", spiega il responsabile tecnico di Glovo.

Inoltre, il team dati ha espresso interesse per le nuove funzionalità serverless disponibili nei servizi AWS, come Amazon EMR o Amazon EKS: "Queste funzionalità ci permettono di avviare qualcosa e renderla operativa più facilmente senza dover conoscere tutti i dettagli sottostanti. Anche l'impegno richiesto per l'implementazione e il funzionamento tende a essere minore". Anche senza implementare modelli puramente serverless (lanciati solo di recente da AWS), l'uso di una combinazione di servizi in esecuzione su AWS e l'adozione della mesh di dati "ha consentito a Glovo di ridurre il tempo necessario per creare prodotti di dati da 5 a 2 settimane". Grazie all'abbondanza di servizi orientati all'importazione, all'elaborazione e all'utilizzo di dati in AWS, in Glovo siamo stati capaci di costruire e scalare una piattaforma dati in grado di supportare l'intera attività e progredire con noi man mano che ci spostiamo verso un modello organizzativo di tipo mesh di dati".

In futuro, l'azienda intende migrare le applicazioni esistenti su Amazon Elastic Kubernetes Services (EKS) e sta già investendo nell'implementazione di un livello di governance, nella sicurezza e nel controllo dell'accesso ai dati, al fine di consentire una migliore gestione di tale accesso per ogni caso d'uso: "Stiamo eseguendo Starburst su EKS e stiamo lavorando per fare in modo che lo strumento di gestione dell'accesso ai dati Privacera funzioni su Amazon EKS".  Glovo sta inoltre implementando una soluzione Notebooks su Amazon EKS (basata su JupyterHub) "per la collaborazione in tempo reale in questo ambiente di sviluppo integrato. In questo modo, analisti e altri profili con accesso ai dati in Glovo potranno lavorare in modo più efficiente", conclude Fenton.