3 pièce(s) jointe(s)
Uber présente AresDB, un moteur d’analyse en temps réel open source optimisé par GPU
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
Citation:
Envoyé par Uber
Chez Uber, l’analyse en temps réel nous permet d’obtenir des informations commerciales et une efficacité opérationnelle, nous permettant de prendre des décisions fondées sur les données pour améliorer les expériences sur la plateforme Uber. Par exemple, notre équipe des opérations s'appuie sur des données pour surveiller la santé du marché et détecter les problèmes potentiels sur notre plateforme. Un logiciel basé sur des modèles d'apprentissage automatique exploite les données pour prévoir l'offre de passagers et la demande de conducteurs et les scientifiques de données utilisent les données pour améliorer les modèles d’apprentissage automatique en vue d’une meilleure prévision.
Dans le passé, nous utilisions de nombreuses solutions de bases de données tierces pour des analyses en temps réel, mais aucune n’a été en mesure de répondre simultanément à toutes nos exigences fonctionnelles, d’évolutivité, de performance, de coût et d’exploitation.
Lancé en novembre 2018, AresDB est un moteur d'analyse en temps réel open source qui exploite une source d'alimentation non conventionnelle, des unités de traitement graphique (GPU), pour permettre à nos analyses de se développer à grande échelle. Outil émergent pour l’analyse en temps réel, la technologie GPU a considérablement évolué au fil des ans, ce qui en fait un choix parfait pour le calcul en temps réel et le traitement de données en parallèle.
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.
Citation:
Envoyé par Uber
Bien que ces technologies possèdent leurs propres atouts, elles manquaient de fonctionnalités essentielles pour notre cas d'utilisation. Nous avions besoin d'une solution unifiée, simplifiée et optimisée et d'une solution originale (ou plutôt intégrée au GPU) pour parvenir à une solution.
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 dimensions n'ont pas besoin d'une colonne d'heure spéciale.
Types de données
Le tableau ci-dessous détaille les types de données actuels pris en charge dans AresDB:
Avec AresDB, les chaînes sont converties automatiquement en types énumérés (enums) avant d'entrer dans la base de données pour une meilleure efficacité de stockage et d'interrogation. Cela permet la vérification d'égalité sensible à la casse, mais ne prend pas en charge les opérations avancées telles que la concaténation, les sous-chaînes, les globs et la correspondance des expressions rationnelles. Uber a l'intention d'ajouter un support complet de chaîne à l'avenir.
Principales caractéristiques
L’architecture d’AresDB prend en charge les fonctionnalités suivantes:
- Stockage basé sur colonne avec compression pour l'efficacité du stockage (utilisation réduite de la mémoire en termes d'octets pour stocker les données) et efficacité de la requête (moins de transfert de données de la mémoire de la CPU vers la mémoire du GPU lors de l'interrogation)
- Conversion en temps réel avec déduplication de clé primaire pour une précision élevée des données et une actualisation des données en temps quasi réel en quelques secondes
- Traitements de requête alimentés par GPU pour le traitement de données hautement parallélisé et alimenté par GPU, ce qui permet d'obtenir une latence de requête faible (sous-secondes à secondes)
Source : Uber
Voir aussi :
:fleche: AMS : un émulateur basé sur un projet open source permettant de profiter des vieux jeux Mac et des applis Mac classiques sans ROM Apple
:fleche: La Commission européenne lance un bug bounty sur une sélection de 15 logiciels open source, avec de grosses récompenses à la clé
:fleche: Après Debian, Red Hat supprime MongoDB de RHEL 8 et Fedora à cause de sa licence SSPL dont le statut de licence libre ou open source est contesté
:fleche: Un véhicule - chambre d'hôtel autonome qui vient à vous comme un taxi Uber et où le service de chambre est assuré par des drones
:fleche: La CNIL inflige une amende de 400 000 euros à Uber pour le piratage dont la société a été victime en 2016
