Ingénieur Restaurant Manager, notre tableau de bord UberEATS Analytics

Chez Uber, nous utilisons l'analyse de données pour concevoir des expériences utilisateur plus magiques à travers nos produits. Dans la mesure du possible, nous exploitons ces capacités d'ingénierie de données pour permettre à nos partenaires de mieux servir leurs clients. Par exemple, à la fin de 2016, l'équipe d'ingénierie d'UberEATS a mis au point un tableau de bord analytique complet qui fournit aux partenaires des restaurants des informations supplémentaires sur la santé de leur entreprise.

Cette solution devait être capable de recueillir des informations à partir d'un pipeline de données en temps réel, granulaire, hautement disponible et fiable. (Il était inacceptable de signaler un paiement net, même d’un cent, sans parler du cauchemar de l’assistance.) Nous avions besoin d’un pipeline capable de fournir des données sur de multiples marchés pour des dizaines de milliers de restaurants. des centaines de milliers et au-delà.

Lancé en mars 2017, Restaurant Manager est un tableau de bord analytique complet et un pipeline pour nos partenaires de restauration. Dans cet article, nous discutons de la manière dont nous avons conçu cette plate-forme d’analyse et son pipeline de données robuste.

La recette du gérant de restaurant

L'une des demandes les plus importantes de nos partenaires du secteur de la restauration a été de mieux comprendre leurs activités, grâce à des enquêtes et des visites régulières. Notre solution? Restaurant Manager, un tableau de bord analytique sur lequel ils peuvent exploiter les données UberEATS pour améliorer à la fois leurs activités sur UberEATS et celles internes.

Après avoir mené des recherches approfondies auprès de nos partenaires, nous avons identifié un ensemble initial d'indicateurs de base: déboursement net, articles quotidiens et hebdomadaires vendus, taux d'acceptation des commandes, vitesse de préparation des commandes et évaluation des articles (soit un pouce levé, , 'indiquant la satisfaction du client). Une fois que nous avons synthétisé nos résultats, nous avons regroupé ces indicateurs en trois grandes catégories de données: la satisfaction du client, les ventes et la qualité du service.

Concevoir une expérience utilisateur réussie

En tenant compte de ces indicateurs de base et de ces trois catégories, nous avons créé un gestionnaire de restaurants convivial:

Satisfaction du client

Sur notre portail de satisfaction client, nous fournissons des informations sur la satisfaction de leurs clients. Pour mesurer cela, nous regroupons les évaluations des repas et les commentaires catégoriels, entre autres paramètres. En prenant le pouls de la satisfaction des clients, les restaurants peuvent cibler des domaines d’amélioration afin de mieux servir leurs clients.

Ventes

Sur notre portail de vente, nous fournissons une fenêtre sur la performance financière des restaurants sur l’application UberEATS. Les paramètres tels que le paiement net en temps réel, les articles vendus et les plats les plus vendus sont des informations utiles pour les restaurateurs lors de la planification des menus et de la détermination de la stratégie marketing.

Qualité du service

Et enfin, avec notre portail de qualité de service, nous montrons aux restaurants comment le taux d'acceptation des commandes, le temps de préparation des aliments et la disponibilité des menus peuvent affecter la satisfaction des clients. En fournissant ces données aux restaurants, nous pouvons les aider à maximiser leurs revenus et à optimiser leurs expériences.

Ensuite, nous examinons un cas d'utilisation de gestionnaire de restaurant pour mieux décrire comment les partenaires de restaurant peuvent bénéficier de cet outil.

Etude de cas du gérant de restaurant: gains potentiels

Avec le directeur du restaurant, les partenaires du restaurant peuvent avoir un aperçu de leurs gains potentiels. La prémisse est simple: lorsqu'un partenaire de restaurant refuse d'accepter une commande pendant les heures de bureau, nous saisissons le prix de la commande et le présentons, comme illustré ci-dessous sur le tableau de bord du gestionnaire de restaurant:

La mise en œuvre de cette équation, cependant, est un peu plus complexe. Pour accéder à la totalité des revenus potentiels, nous rejoignons et traitons plusieurs flux de données provenant de services distincts en un résultat final, regroupés par emplacement de restaurant.

Dans notre prochaine section, nous disséquons l’architecture de Restaurant Manager, un système puissant et évolutif qui exploite de nombreux services de traitement de données existants d’Uber.

Restaurant Manager architecture

L'architecture de la plateforme repose sur Pinot, une banque de données OLAP (Online Analytical Processing) open source, pour alimenter virtuellement toutes les données de notre tableau de bord analytique. Pinot prend en charge l'ingestion de tables en temps quasi-réel, fournit une prise en charge des requêtes de type SQL par rapport à des ensembles de données relativement volumineux et convient parfaitement aux requêtes QPS (faible latence, requêtes élevées par seconde) et évolutives. Pinot prend également en charge le chargement de données à la fois en ligne (par exemple, les flux Kafka) et hors ligne (par exemple, les travaux Hadoop), décrits ci-dessous:

Figure 1: L'architecture UberEATS Restaurant Dashboard combine le chargement de données provenant de sources en ligne et hors ligne.

Pipeline d'ingestion de données en ligne

Ce workflow en temps réel peut être divisé en quatre phases:

  1. Les services UberEATS, y compris nos services de gestion des comptes de restaurant, de gestion des flux de travail et de notation, captureront l’interaction des utilisateurs avec le système UberEATS et videront les données dans les flux Kafka.
  2. Un travail en continu rejoint les événements de plusieurs flux Kafka, puis les transforme et les agrège, puis produit les événements décorés dans différents flux Kafka.
  3. Pinot consomme des données provenant des flux de Kafka supérieurs, stocke les données et crée des index pour des requêtes efficaces.
  4. Le gestionnaire de restaurant interroge Pinot pour obtenir de nouvelles données avec un QPS élevé, et Pinot fournit des résultats avec une faible latence.

Le job de streaming rejoint les modifications d'état d'une commande UberEATS et les événements de dimension de commande UberEATS, puis publie les commandes non acceptées (et les gains potentiels que les partenaires de restauration pourraient avoir reçus en acceptant ces commandes) dans un flux Kafka. Nous implémentons le job de streaming avec le SQL suivant en utilisant AthenaX, la plate-forme analytique de streaming d'Uber:

Pinot consomme le flux et construit la table avec le schéma suivant: {Chaîne restaurantUUID, chaîne jobUUID, chaîne skuName, prix double, chaîne de devise, chaîne dateStr}.

En utilisant ce modèle, un service frontal enverra une requête Pinot comme celle ci-dessous lorsqu'un partenaire de restaurant souhaite connaître ses gains potentiels pendant une période donnée:

SÉLECTIONNER la somme (prix)

FROM potential_earnings

WHERE restaurantUUID = "?" Et dateStr entre (?,?)

Pipeline d'ingestion de données hors ligne

Après avoir été traité en temps réel, tous les événements commerciaux UberEATS seront déplacés vers HDFS via le protocole d'extraction, de transformation, de chargement (ETL) et seront disponibles dans Hive pour les requêtes. La fraîcheur d'une table Hive dépend de la vitesse de notre pipeline ETL, qui prend généralement quelques heures à compléter. Pour résoudre les éventuels problèmes de collecte de données, nous planifions des flux de production hors connexion avec Oozie pour remplir les données sur les serveurs hors ligne Pinot. Le pipeline hors ligne implique Hive, Spark, Oozie et Pinot.

Les données sur Hive sont appliquées comme source de vérité, mais seulement jusqu'à 24 heures après qu'un événement se soit produit. Pour respecter ce calendrier serré, nous planifions des tâches Oozie pour ajouter et mettre à jour quotidiennement les tables hors ligne Pinot. Il y a trois étapes pour déplacer les données de Hive vers Pinot:

  1. Exécuter un travail Spark pour interroger Hive, puis enregistrer les résultats dans des fichiers Avro sur HDFS.
  2. Exécutez un travail Spark pour générer des segments indexés Pinot (l'unité de stockage de données Pinot) à partir des fichiers Avro créés à l'étape 1.
  3. Poussez ces segments vers un cluster Pinot.
Service de requête

Figure 2: Le gestionnaire de restaurant utilise Pinot pour servir les requêtes d'événement, qui sont alors prêtes à être traitées.

Une fois servis à Pinot, nos événements UberEATS sont prêts à être stockés et traités. Comme le montre la Figure 2 ci-dessus, un proxy REST Pinot, un courtier Pinot et des serveurs temps réel / hors ligne Pinot sont les principaux composants du service de requête.

Une requête Pinot est d'abord envoyée au proxy REST Pinot, responsable du routage des requêtes et de l'équilibrage de charge. Notre proxy REST Pinot acheminera la requête au courtier Pinot correspondant en fonction de la source de données. Ensuite, le Broker Pinot partitionne la requête, disperse la requête vers les serveurs correspondants et rassemble les résultats. Les serveurs Pinot stockent et indexent les données, et répondent aux requêtes concrètes.

Performance d'architecture

Dans cette section, nous détaillons les principales mesures permettant de mesurer les performances de notre architecture basée sur Pinot, notamment le débit, la latence, l'évolutivité, la fiabilité et le temps d'intégration technique. Pour notre benchmark de performance, nous avons mis en place trois serveurs en ligne avec 24 cœurs et 128 Go de RAM.

Débit & latence

Après avoir effectué des tests approfondis, nous avons déterminé que pendant la phase d'ingestion des données, Pinot peut ingérer des requêtes de Kafka à raison de 20 000 messages par seconde par thread.

Pour nous assurer que nous pouvons servir tous les utilisateurs, nous devons garantir que Pinot peut toujours répondre au sein du SLA lorsque QPS augmente. Pour garantir une évolutivité horizontale, nous avons également testé la latence des requêtes traitées à des vitesses différentes. Avec 1 000 QPS, trois serveurs Pinot peuvent toujours répondre à des requêtes avec une latence de 99% inférieure à 100 millisecondes (ms).

Figure 3: Même sous une contrainte intense, notre architecture Pinot peut traiter des requêtes avec une latence de 99%.

Évolutivité et fiabilité

Comme le pinot évolue horizontalement, nous pouvons ajouter plus de matériel au client pour développer le cluster. Actuellement, Pinot est au service des plates-formes d’analyse d’Uber avec une disponibilité de 99,99%.

Temps d'ingénierie d'ingénierie

Grâce à notre architecture d’analyse en continu de bout en bout, nous avons raccourci le temps d’ingénierie moyen nécessaire à l’intégration d’une tâche ou d’une table de plusieurs semaines à quelques heures sur nos plates-formes.

Rendu de données

Pour présenter les données capturées par nos systèmes à nos partenaires de restauration de manière performante et facilement navigable, nous avons utilisé React comme base de notre couche de visualisation et Redux comme base de notre couche de données. Ces choix ont été faciles à réaliser, car l'écosystème d'ingénierie Web d'Uber est en grande partie conçu avec React, et plusieurs équipes contribuent à l'utilisation de composants réutilisables par d'autres équipes.

Après avoir exploré plusieurs options de rendu de graphiques, nous avons choisi Recharts, une bibliothèque de composants déclaratifs simple mais puissante, pour générer des graphiques pour notre tableau de bord avec la bibliothèque D3.js. La prémisse du rendu des données est simple: le client effectue des appels asynchrones indépendants vers le serveur de nœuds pour chaque section d'analyse, qui transmet ensuite les requêtes au Pinot; Une fois les données renvoyées au client, elles sont adaptées à un format consommable par Recharts et restituées sur la page. Le résultat est une interface utilisateur propre et interactive, facilitant la compréhension et l’application de nos analyses.

Figure 4: une mesure de gestionnaire de restaurant est le paiement net d'un partenaire de restaurant (calculé en ajoutant tous les articles vendus sur une période donnée) sur UberEATS.

Construire l'avenir de l'analyse Uber

Grâce au gestionnaire de restaurant et à d’autres outils, les équipes UberEATS de Streaming Analytics et UberEATS développent des solutions d’analyse en temps réel évolutives permettant à nos partenaires de restauration d’obtenir des informations exploitables. Si vous souhaitez construire les plates-formes analytiques next-gen d'Uber, consultez nos offres d'emploi en ingénierie de plate-forme de données / infrastructure. Nous avons également des rôles ouverts dans l’équipe d’ingénierie d’UberEATS qui développe notre plate-forme actuelle.

En savoir plus sur Restaurant Manager en regardant la vidéo, ci-dessous:

Jing Fan et Xiang Fu sont des ingénieurs logiciels de l'équipe Streaming Analytics d'Uber. Faiz Abbasi est un ingénieur logiciel de l'équipe UberEATS Restaurant Experience. Jonathan Chao, un responsable de l'ingénierie de l'équipe UberEATS Restaurant Experience, a également contribué à cet article.

  • Catégories: Uber Data /
  • Tags: Analytique, Tableau de bord analytique, AthenaX, Avro, Intelligence économique, Satisfaction client, Données, Data Analytics, HIVE, Kafka, Nœud, Oozie, Pinot, Réagir, Recharges, Redux, Restaurant Manager, Ventes, Qualité de service, Spark, SQL, Analyse en continu, données Uber, Uber Eats, UberEATS, interface utilisateur, interface utilisateur
4.4
Note utilisateur: 30
5
12
4
4
3
1
2
3
1
1