Glovo verwaltet täglich 2 TB an Daten mit AWS

Glovo, ein weltweit führendes Unternehmen im Bereich der Zustellung, erhält derzeit 2 TB Daten pro Tag von Online-Bestellungen und Angeboten seiner Lieferanten. Für das spanische multinationale Unternehmen ist es von entscheidender Bedeutung, dass diese großen Datenmengen die größtmögliche Auswirkung auf die Bereitstellung des besten Kundenservice haben. Mit den Lösungen von Amazon Web Services konnten sie dies erreichen.

Glovo wurde 2015 in Barcelona gegründet und befasst sich hauptsächlich mit der Lieferung von online bestellten Lebensmitteln nach Hause. Heute ist die App in 25 Ländern und mehr als 1.300 Städten mit mehr als 150.000 Partner-Restaurants und -Einrichtungen vertreten. Neben den besten Restaurants finden Benutzer hier alle Arten von Geschäften, darunter Supermärkte, Elektro-, Gesundheits- und Schönheits- sowie Geschenkeläden, um nur einige zu nennen.

Glovo verfügt über eine starke technologische Komponente und eine Plattform, die Kunden, Unternehmen und Kuriere über ihre Website und mobile Anwendung miteinander verbindet. Täglich verarbeitet es ein Datenvolumen von 2 TB. „Als schnell wachsendes Unternehmen, in dem der Datenbedarf (Anwendungsfälle und Datenmengen) rapide ansteigt, ist es für den Erfolg von Glovo entscheidend, eine starke Struktur zu haben, wie wir Daten sammeln, zusammenstellen und nutzen, um den größtmöglichen Einfluss auf das Geschäft zu haben“, erklärt Oliver Fenton, Data Platform Director bei Glovo.

Der Schutz der persönlichen Daten der Benutzer ist für Glovo sehr wichtig, und das Unternehmen sorgt stets für maximale Sicherheit. „AWS ermöglicht es uns, das Ziel zu erreichen, Daten sicher zu speichern und bei Bedarf darauf zuzugreifen und dabei stets alle geltenden Vorschriften einzuhalten“, sagt Oliver Fenton. 

Glovo wandte sich für die erste Iteration seiner Datenplattform an Amazon Web Services. Diese Entscheidung wurde auf Empfehlung einiger Mitglieder des Datenteams getroffen, die zuvor AWS-Lösungen verwendet hatten. Das Produkt, das für den Aufbau dieser Datenplattform ausgewählt wurde, war Amazon Redshift, ein in der Cloud verwalteter Data-Warehouse-Service. „Der Einstieg war sehr einfach und die Software war leistungsfähig genug, um alle unsere Anforderungen zu erfüllen“, bestätigt Fenton. Auf diese Datenanalyseschicht, die auf Amazon Redshift läuft, folgten bald ETL-Anwendungsfälle: „Der erste war die Tabellierung von Rohdaten (etwa 100 GB Rohdaten pro Tag). Um diesen Bedarf zu decken, nutzen wir die Amazon-EMR-Big-Data-Plattform. Genauer gesagt, Apache-Spark-Technologie auf Amazon EMR ephemeren Clustern, die auf Amazon-EC2-Instances laufen, mit dem Ziel, die Rohdaten in Amazon S3 zu verarbeiten und die analytischen Tabellen zu erstellen, die ebenfalls in S3 gespeichert und im AWS-Glue-Datenkatalog“ registriert sind.

Doch „kurz darauf begannen die Leute, ihre eigenen ETL-Prozesse auf diesen Daten aufzubauen. Die Verarbeitung erfolgte ebenfalls in Spark auf Amazon EMR (EC2) und wurde über das Luigi-Modul orchestriert, einen von Spotify entwickelten Open-Source-Orchestrator, der auf einer EC2-Instance bereitgestellt wurde. Einige Ergebnisse aus diesen ETLs mussten in unserem Looker-BI-Tool zur Verfügung gestellt werden, und aufgrund bestimmter Einschränkungen in unseren damaligen Prozessen mussten wir auch Kopien in Amazon Redshift erstellen“.

Während das Geschäft von Glovo exponentiell wuchs, wuchs auch die Datenplattform weiter und musste verschiedene Anwendungsfälle abdecken. Es wurde die Notwendigkeit erkannt, die Aktualisierungsrate zu erhöhen, um die Verfügbarkeit von Betriebsdaten zu verbessern. Daraufhin wurde Importer entwickelt, ein Tool zur Datenaufnahme, das die Fähigkeiten von Apache Spark auf Amazon EMR (das auf EC2 läuft) nutzt, um Daten aus Transaktionsdatenbanken, die auf Amazon Aurora laufen, und anderen Arten von Quellen zu extrahieren und sie in den DataLake in Amazon S3 zu streamen. Dadurch wird sichergestellt, dass diese Daten als Tabellen verfügbar sind. „Diese Tabellen werden mit Daten im Delta-Format erstellt und der gesamte Prozess des Extrahierens und der Verwendung des Importers wird durch Luigi orchestriert, das auf einer EC2-Instance läuft“, fährt der Manager der Datenplattform bei dem Lieferunternehmen fort.

Parallel zur Arbeit der Datenteams bei Glovo begannen die Anwendungsentwickler, Microservice-Architekturen zu übernehmen und neue Anwendungsfälle für die Datenverwaltung zu schaffen: „Das Backend wurde in Microservices aufgeteilt. Die prozessübergreifende Kommunikation erfolgte über Amazon Kinesis Streams. Diese Ereignisse im Avro-Format wurden für bestimmte Analysefälle benötigt. Um diese in S3 hochzuladen, haben wir mithilfe der Apache-Beam-Technologie und der Infrastruktur von Amazon Managed Service für Apache Flink ein Framework mit der Bezeichnung Rivers erstellt. Dieses verleiht den Ereignissen eine spezifische Verzeichnisstruktur, die einen weiteren nachfolgenden Prozess zur Erfassung der Ereignisse und deren Integration in analytische Tabellen mithilfe von Importer vereinfacht.“

Alle oben beschriebenen Fälle werden auf einer monolithischen Datenplattform ausgeführt, „die nicht skalierbar ist“, stellt Oliver Fenton klar und verlangsamt damit die Zunahme von Anwendungsfällen und Geschäftsentscheidungen rund um die Datennutzung des Unternehmens. Aus diesem Grund hat Glovo den Weg zu einem Datennetz eingeschlagen, das es ermöglicht, die Verantwortlichkeiten aufzuteilen und den Teams mehr Autonomie bei der Nutzung der Daten zu geben. „Als Teil dieses Weges haben wir damit begonnen, sogenannte Self Service Data Pipelines (SSDP) zu erstellen. Für die Verarbeitung verwenden wir nach wie vor Spark auf Amazon EMR (EC2), aber wir integrieren auch eine Amazon-Managed-Workflows-for-Apache-Airflow-Instance (MWAA) pro Datendomäne, um den Datenteams mehr Kontrolle über ihren eigenen Code und ihre Bereitstellungen zu geben. Sowohl Spark- als auch Nicht-Spark-Anwendungen werden in Docker-Container verpackt und in die Amazon Elastic Container Registry (ECR) hochgeladen. Nicht-Spark-Anwendungen werden auf Amazon Elastic Container Service (Amazon ECS) auf Fargate ausgeführt, während Spark-Anwendungen auf Amazon EMR (EC2) laufen und YARN-Unterstützung für Docker nutzen“.

Außerdem hat Glovo Starburst als Abfrage-Engine für sein Data Mesh eingeführt. „Wir haben damit begonnen, Amazon Elastic Kubernetes Service (Amazon EKS) innerhalb der Datenteams bei Glovo zu nutzen, um unsere Starburst-Abfrage-Engine auszuführen. Damit entfällt möglicherweise die Notwendigkeit, Amazon Redshift als Mittel zur Ausführung bestimmter Benutzerabfragen von Looker zu nutzen. Wir haben auch damit begonnen, EMR in EKS zu untersuchen, damit wir nicht für die Aktivierungszeit der EMR-Cluster (EC2) bezahlen müssen“, sagt Oliver Fenton.

Durch den Einsatz von AWS-Lösungen hat Glovo Flexibilität bei der Skalierung seiner Plattform im Rahmen des Data Mesh gewonnen: „Im Falle von Amazon EMR können wir Cluster bereitstellen, die nur während der erforderlichen Verarbeitungszeit aktiv sind; jede Gruppe kann unabhängig skaliert werden. Mit diesen mehreren Clustern können wir auch die verschiedenen Anwendungsfälle leicht isolieren“, erklärt der technische Leiter von Glovo.

Darüber hinaus hat das Datenteam Interesse an den neuen Serverless-Funktionen geäußert, die in AWS-Services wie Amazon EMR oder Amazon EKS zur Verfügung stehen: „Weil sie es uns ermöglichen, etwas zu starten und es einfacher zum Laufen zu bringen, ohne alle zugrunde liegenden Details kennen zu müssen. Auch der Aufwand für die Bereitstellung und den Betrieb ist tendenziell geringer“. Auch ohne reine Serverless-Modelle zu implementieren (da diese erst vor kurzem von AWS eingeführt wurden), konnte Glovo durch die Nutzung einer Kombination von Services, die auf AWS laufen, und die Einführung von Data Mesh „die Zeit, die für die Erstellung von Datenprodukten benötigt wird, von 5 auf 2 Wochen reduzieren. Dank der Fülle von Services, die auf die Aufnahme, Verarbeitung und Nutzung von Daten in AWS ausgerichtet sind, konnten wir bei Glovo eine Datenplattform aufbauen und skalieren, die unser gesamtes Geschäft unterstützt und sich weiterentwickelt, während wir uns auf ein Data-Mesh-Organisationsmodell zubewegen“.

In Zukunft möchte das Unternehmen seine bestehenden Anwendungen auf Amazon Elastic Kubernetes Services (EKS) migrieren und investiert bereits in die Implementierung einer Schicht von Governance, Sicherheit und Datenzugriffskontrolle, um eine bessere Verwaltung des Zugriffs auf die erforderlichen Daten für jeden Anwendungsfall zu ermöglichen: „Wir führen Starburst auf EKS aus und arbeiten jetzt daran, das Privacera Datenzugriffsmanagement-Tool auf Amazon EKS laufen zu lassen.“  Glovo implementiert auch eine Notebooks-Lösung auf Amazon EKS (basierend auf JupyterHub) „für die Echtzeit-Zusammenarbeit in dieser integrierten Entwicklungsumgebung. Auf diese Weise können Analysten und andere Profile, die Zugang zu den Daten in Glovo haben, effizienter arbeiten“, so Fenton abschließend.