BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités L'évolution De La Plateforme Big Data De Uber Avec Plus De 100 Pétaoctets

L'évolution De La Plateforme Big Data De Uber Avec Plus De 100 Pétaoctets

L'équipe d'ingénieurs d'Uber a expliqué comment sa plateforme Big Data avait évolué, passant de jobs ETL traditionnelles avec des bases de données relationnelles à une structure basée sur Hadoop et Spark. Un modèle d'ingestion évolutif, un format de transfert standard et une bibliothèque personnalisée pour les mises à jour incrémentielles sont les composants clés de la plateforme.

Diverses équipes chez Uber utilisent le Big Data pour des tâches telles que la prévision de la demande de course, la détection de la fraude, le calcul géospatial et la résolution des goulets d'étranglement dans le processus d'inscription du rider-partner. Leur solution initiale, développée avant 2014, était basée sur MySQL et PostgreSQL. La quantité relativement faible de données dont ils disposaient à l'époque - quelques TB - pouvait s'intégrer dans ces SGBDR, et les utilisateurs devaient trouver eux-mêmes comment interroger ses bases de données. Les équipes d'exploitation de la ville, les scientifiques et les analystes de données, ainsi que les équipes d'ingénieurs ont utilisé ces données.

Un effort de standardisation a conduit à l’adoption de Vertica - une plateforme d’analyse par colonnes - soutenue par des jobs ad hoc Extract-Transform-Load (ETL). Un service de requête personnalisé permettait d'accéder aux données à l'aide de SQL. La quantité de données est passée à 10 TB, accompagnée d'une augmentation du nombre d'équipes et de services utilisant ces données. Les principaux problèmes auxquels Uber était confrontée à ce stade étaient le manque d’évolutivité horizontale, les dépenses croissantes et les pertes de données résultant de l’absence de schéma formel entre les producteurs de données et les consommateurs.

L’équipe d’ingénierie a adopté Hadoop lors de la phase suivante pour ingérer les données de plusieurs stores sans les transformer. Apache Spark, Apache Hive et Presto en tant que moteur de requête faisaient partie de la pile. Vertica était rapide, mais ne pouvait pas évoluer à moindre coût, tandis que Hive avait le problème opposé (PDF). Le stockage du schéma et des données ensemble à l'aide d'un service de schéma personnalisé a résolu les problèmes rencontrés lors de la phase précédente. La quantité de données a atteint 10s de PBs. L'infrastructure de données exécutait 100 000 tâches par jour sur 10 000 cœurs de processeur virtuels.

Malgré l'évolutivité horizontale en place, ils se sont heurtés à des goulots d'étranglement dans HDFS. Dans un cluster HDFS, un NameNode garde la trace de chaque fichier du cluster et conserve l'arborescence de répertoires. HDFS est optimisé pour la diffusion en continu de gros fichiers, et beaucoup de petits fichiers rendent l’accès inefficace. Uber a rencontré ce problème lorsque leur volume de données a dépassé 10 PB. Ils ont contourné ses goulots d'étranglement de HDFS en optimisant le garbage collection de NameNode, en limitant le nombre de petits fichiers et en offrant un service de gestion de la charge HDFS. De plus, les données n'étaient pas disponibles assez rapidement pour les utilisateurs finaux. Reza Shiftehfar, responsable de l'ingénierie chez Uber, écrit que :

Les activités d'Uber opèrent en temps réel et, de ce fait, nos services nécessitent un accès à des données aussi fraîches que possible. Pour accélérer la livraison des données, nous avons dû réorganiser notre pipeline pour qu'il ingère de manière incrémentielle uniquement des données mises à jour et nouvelles.

Courtoisie d'image - https://eng.uber.com/uber-big-data-platform/

Le résultat a été une bibliothèque Spark personnalisée appelée Hudi (Hadoop Upserts anD Incrementals). Il forme une couche au-dessus de HDFS et de Parquet (un format de fichier de stockage) qui permet les mises à jour et les suppressions, ce qui permet d'atteindre l'objectif d'incrémentation des tâches ETL. Hudi fonctionne en laissant les utilisateurs interroger leur checkpoint du dernier point de contrôle pour extraire toutes les données mises à jour depuis le point de contrôle, sans avoir à exécuter une analyse complète de la table. Cela a ramené la latence de 24 heures à moins d’une heure pour les données modélisées et de 30 minutes pour les données brutes.

Avec Hudi, la dernière phase de la plateforme Big Data d'Uber est l'autre ingestion de données via Apache Kafka avec en-têtes de métadonnées. Un composant appelé Marmaray récupère les modifications de Kafka et les transmet à Hadoop à l'aide de la bibliothèque Hudi. Tout cela est orchestré avec Apache Mesos et YARN. Tandis que Mesos convient aux services de longue durée, YARN convient mieux aux travaux par batch/Hadoop. Uber utilise son framework de planification personnalisé Peloton, construit sur la base de Mesos, pour gérer ses charges de travail de calcul.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT