Sergey Bogomyako - stock.adobe.c
Data Lake : soutenu par Uber, le projet Apache Hudi gagne en maturité
Le projet open source Apache Hudi doit aider de grands groupes comme Uber à se doter de capacités de traitement de flux pour gérer des milliards d’enregistrements par jour sur des data lake.
Le projet de data lake open source d’Apache est arrivé à maturité. Apache Hudi (Hadoop Upserts Deletes and Incrementals) doit faciliter le traitement de données en continu au-dessus de systèmes de stockage compatibles avec Hadoop, dont Amazon S3.
Originellement développé par Uber en 2016, Hudi est devenu open source en 2017 et a rejoint l’incubateur Apache en 2019. Depuis son ouverture, Alibaba, Tencent, Kyligence, et Uber (évidemment) sont quelques-unes des entreprises qui l'ont adopté.
Le quatre juin dernier, le projet a atteint un nouveau stade. L’Apache Software Foundation (ASF) l’a introduit dans sa liste des projets « Top-Level ». En dehors de la sphère Apache, cela veut dire que le code source a atteint un niveau de maturité et qu’il est soutenu par un nombre de développeurs suffisants. Pour rappel, la fondation Apache soutient les projets Hadoop, Spark, Kafka, Zookeeper, et d’autres middlewares et applications de gestion de données.
Une brique intéressante pour concevoir un lac de données analytique
Le contributeur principal du projet, Uber, utilise Apache Hudi de manière (très) assidue.
Tanvi Kothari, directrice de l’ingénierie des données chez Uber, assure que son employeur utilise le projet open source pour traiter plus de 500 milliards d’enregistrements par jour dans un lac de données dépassant les 150 pétaoctets.
Chez Uber, Tanvi Kothari dirige plus particulièrement l’équipe Global Data Warehouse. Celle-ci est responsable des tables de données principales qui servent à l’ensemble des divisions d’Uber. Elle explique que Hudi permet le traitement incrémentiel, en lecture et en écriture, pour plus de 10 000 tables et des milliers de pipelines de données.
« Hudi vous permet de faire abstraction de nombreux défis posés par le traitement Big Data », indique Tanvi Kothari. « Il vous aide à mettre à l’échelle vos pipelines ETL et à améliorer la fidélité des données ».
Kyligence Solutions, un éditeur de solutions analytiques installé à Shanghai et à San José, est également un adepte du composant open source. Shaofeng Shi, chief architect de Kyligence, explique que le spécialiste du Big Data utilise plusieurs technologies open source dont Apache Kylin, Hadoop et Spark pour aider ses clients à gérer leurs données.
Selon Shaofeng Shi, Hudi fournit à Kyligence un moyen de gérer des jeux de données changeants sur HDFS ou Amazon S3. L’éditeur a commencé à utiliser ce projet en 2019 pour un client américain. La chief architect souligne qu’AWS lui-même a annoncé une intégration de Hudi avec Amazon Elastic MapReduce (EMR). Le service Kyligence Cloud prend désormais en charge Hudi comme format source pour le traitement analytique en ligne.
La chief architect salue elle aussi le changement de statut du projet au sein de la fondation Apache. La communauté a même traduit des articles liés à cette solution pour les utilisateurs chinois.
Seulement, ces retours positifs ne nous disent pas comment Apache Hudi fonctionne.
_half_column_mobile.jpg)
Comment fonctionne Apache Hudi
« Hudi offre la possibilité de consommer des flux de données et permet aux utilisateurs de mettre à jour des data sets », déclare Vinoth Chandar, co-créateur et vice-président du projet Apache Hudi à l’ASF.
AWS et Uber Engineering nous en disent un peu plus. Hudi permet d’effectuer trois types d’opérations : des insertions, des mises à jour et des suppressions des enregistrements. Consommer des données en quasi-temps réel, consulter l’historique des modifications ou encore réactiver des données tardives, voilà quelques-unes des capacités du composant open source.
« Il faut considérer Hudi comme un data store ou une base de données qui offre des capacités transactionnelles par-dessus des objets stockés dans S3 », indique Vinoth Chandar.
Pour ajouter cette couche ACID par-dessus un data lake, les responsables du projet l’ont rendu compatible avec plus moteur de requêtes dont Presto, Hive, Spark SQL et Impala. Hudi ajoute donc des index par-dessus l’espace de stockage des données brutes pour les insertions, et créer des métadonnées pour gérer les data sets. C’est d’ailleurs l’un des éléments clés de Hudi qui conserve un historique des opérations effectuées sur les tables. Dès lors, cette couche offre trois vues logiques sur une même table : une vue de lecture optimisée, une vue incrémentielle pour les modifications et une vue en temps réel pour des injections rapides.
D’après les informations d’Uber, Hudi organise les tables via la propriété basePath sur un système de fichiers distribué. Ces tables sont divisées en partition dans lesquelles les fichiers sont rassemblés en groupes qui contiennent des tranches de fichiers. Chaque tranche contient un fichier de base au format Parquet et des logs. Ces « découpes » de fichiers sont créées à l’aide d’une méthode de contrôle des accès concurrents (MVCC). Elle définit la compression et l’assemblage des logs et des fichiers de base. Quand les tranches ne sont plus utilisées, elles sont effacées pour ne pas surcharger l’espace de stockage.
Au moment de créer un data set avec Hudi, l’utilisateur précise s’il effectue une copie sur écriture (Copy on Write- CoW) ou une fusion sur la lecture (Merge on Read - MoR). Avec les copies en écriture, les données sont stockées dans un format en colonnes (Parquet) et les réécritures de fichiers se font de manière synchrone. Avec la fusion sur lecture, les formats de stockage combinent colonnes (Parquet) et lignes (Avro) et les mises à jour sont liées à des fichiers delta basés sur les lignes et compressés au besoin pour créer des fichiers en colonnes, de manière synchrone ou asynchrone.
Si Hudi a atteint un niveau de maturité suffisant pour le faire apparaître auprès des plus gros projets de la fondation, le projet n’est pas encore disponible en version 1.0. La dernière mise à jour en date, publié le 25 mars, porte l’indicatif 0.5.2.
