Uber présente AresDB, un moteur d'analyse en temps réel open source optimisé par GPU,

Qui lui ferait gagner en efficacité opérationnelle

Applications d'analyse en temps réel chez Uber

L’analyse des données est essentielle au succès des activités d’Uber. Parmi d'autres fonctions, ces analyses sont utilisées pour:

• Construire des tableaux de bord pour surveiller ses métriques commerciales
• Prendre des décisions automatisées (telles que la tarification des voyages et la détection de la fraude) en fonction de statistiques agrégées recueillies.
• Effectuer des requêtes ad hoc pour diagnostiquer et résoudre les problèmes liés aux opérations commerciales

Nous pouvons résumer ces fonctions en catégories avec des exigences différentes comme suit:


Les tableaux de bord et les systèmes de décision exploitent les systèmes analytiques en temps réel pour effectuer des requêtes similaires sur des sous-ensembles de données relativement petits, mais très précieux (avec une actualité maximale des données) avec un QPS élevé et une latence faible.

La nécessité d'un autre moteur d'analyse

Le problème le plus souvent résolu par l'analyse en temps réel chez Uber consiste à savoir comment calculer les agrégats de séries chronologiques, calculs qui lui donnent un aperçu de l'expérience utilisateur afin d'améliorer ses services en conséquence. Avec ces calculs, Uber peut demander des métriques selon des dimensions spécifiques (telles que le jour, l'heure, l'identifiant de la ville et l'état du trajet) sur une plage de temps sur des données arbitrairement filtrées (ou parfois jointes). Au fil des ans, Uber a déployé de nombreuses solutions pour résoudre ce problème de différentes manières.

Parmi les solutions tierces utilisées par Uber pour résoudre ce type de problème, citons:

• Apache Pinot, une base de données analytique distribuée open source écrite en Java, qui peut être exploitée pour l'analyse de données à grande échelle. Pinot utilise une architecture lambda en interne pour interroger des données par lots et en temps réel dans un stockage en colonnes, utilise un index bitmap inversé pour le filtrage et s’appuie sur un arbre en étoile pour la mise en cache des résultats agrégés. Cependant, il ne prend pas en charge la déduplication à base de clés, l'Usert, les jointures et les fonctionnalités de requête avancées telles que le filtrage géospatial. En outre, en tant que base de données basée sur la machine virtuelle Java, l’exécution de requêtes sur Pinot a un coût plus élevé en termes d’utilisation de la mémoire.
• Elasticsearch est utilisé chez Uber pour une variété de besoins d'analyse en continu. Il a été construit sur Apache Lucene pour la recherche de mots clés en texte intégral qui stocke des documents et un index inversé. Il a été largement adopté et étendu pour prendre également en charge les agrégats. L'index inversé permet le filtrage, mais il n'est pas optimisé pour le stockage et le filtrage basés sur des plages horaires. Il stocke les enregistrements sous forme de documents JSON, ce qui impose un stockage supplémentaire et une surcharge d'accès aux requêtes. Comme Pinot, Elasticsearch est une base de données basée sur la machine virtuelle Java. En tant que telle, elle ne prend pas en charge les jointures et son exécution de requête a un coût de mémoire supérieur.

Vue d'ensemble de l'architecture AresDB

À un niveau élevé, AresDB stocke la plupart de ses données dans la mémoire de l'hôte (RAM connectée à des CPU), gère l'ingestion de données à l'aide de CPU et la récupération de données via des disques. Au moment de la requête, AresDB transfère les données de la mémoire de l'hôte vers la mémoire du processeur graphique pour un traitement parallèle sur le processeur graphique. Comme le montre la figure ci-dessous, AresDB comprend un magasin de mémoire, un métamagasin de données et un magasin de disque:


Les tables

Contrairement à la plupart des systèmes de gestion de base de données relationnelle (SGBDR), AresDB ne contient aucune étendue de base de données ou de schéma. Toutes les tables appartiennent à la même étendue dans le même cluster / instance AresDB, ce qui permet aux utilisateurs de s'y référer directement. Les utilisateurs stockent leurs données sous forme de tables de faits et de tables de dimensions.

Table de faits

Une table de faits stocke un flux infini d'événements de séries chronologiques. Les utilisateurs utilisent une table de faits pour stocker les événements / faits qui se produisent en temps réel, et chaque événement est associé à une heure d'événement, la table étant souvent interrogée par l'heure de l'événement. Un exemple du type d'informations stockées par les tables de faits est celui des voyages, où chaque voyage est un événement et l'heure de la demande de voyage est souvent désignée comme heure de l'événement. Si un événement est associé à plusieurs horodatages, un seul horodatage est désigné comme l'heure de l'événement affiché dans la table de faits.

Table de dimension

Une table de dimension stocke les propriétés actuelles des entités (y compris les villes, les clients et les pilotes). Par exemple, les utilisateurs peuvent stocker des informations sur la ville, telles que le nom de la ville, le fuseau horaire et le pays, dans une table de dimension. Comparées aux tables de faits, qui se développent à l'infini dans le temps, les tables de dimensions sont toujours liées par leur taille (par exemple, pour Uber, la table des villes est liée au nombre réel de villes dans le monde). Les tables de...