Comment fonctionne Hudi

Lorsque vous utilisez Hudi avec AmazonEMR, vous pouvez écrire des données dans l'ensemble de données à l'aide de la source de données Spark API ou de l'utilitaire Hudi DeltaStreamer . Hudi organise un jeu de données dans une structure de répertoire partitionnée sous basepath qui est similaire à une table Hive traditionnelle. Les spécificités de la façon dont les données sont présentées en tant que fichiers dans ces répertoires dépendent du type d'ensemble de données que vous choisissez. Vous pouvez choisir CoW (Copy on Write, copie sur écriture) ou MoR (Merge on Read, fusion sur lecture).

Quel que soit le type d'ensemble de données, chaque partition d'un ensemble de données est identifiée de manière unique par son chemin partitionpath relatif au chemin basepath. Au sein de chaque partition, les enregistrements sont répartis dans plusieurs fichiers de données. Pour de plus amples informations, veuillez consulter File management dans la documentation Apache Hudi.

Chaque action dans Hudi est associée à un commit correspondant, identifié par un horodatage croissant de façon monotone appelé Instant. Hudi conserve une série de toutes les actions effectuées sur le jeu de données sous forme de chronologie. Hudi s'appuie sur la chronologie pour isoler instantanément les lecteurs et les rédacteurs, et pour permettre de revenir à un point antérieur dans le temps. Pour plus d'informations sur les actions enregistrées par Hudi et l'état des actions, consultez Timeline dans la documentation Apache Hudi.

Comprendre les types de stockage des jeux de données : copie en écriture ou fusion en lecture

Lorsque vous créez un jeu de données Hudi, vous spécifiez que celui-ci doit être copié en écriture ou fusionné en lecture.

• Copie sur écriture (CoW) – Les données sont stockées dans un format en colonnes (Parquet) et chaque mise à jour crée une nouvelle version des fichiers lors d'une écriture. CoW est le type de stockage par défaut.

• Fusion sur lecture (MoR) – Les données sont stockées en utilisant une combinaison de formats en colonnes (Parquet) et en lignes (Avro). Les mises à jour sont consignées dans des fichiers delta basés sur les lignes et sont compressées si nécessaire pour créer de nouvelles versions des fichiers en colonnes.

Avec les ensembles de données CoW, chaque fois qu'une mise à jour est apportée à un enregistrement, le fichier qui contient l'enregistrement est réécrit avec les valeurs mises à jour. Avec un jeu de données MoR, chaque fois qu'une mise à jour a lieu, Hudi écrit uniquement la ligne du registre modifié. Le type de stockage MoR est mieux adapté aux charges de travail donnant lieu à de nombreuses écritures ou modifications avec moins de lectures. Le type de stockage CoW est mieux adapté aux charges de travail donnant lieu à de nombreuses lectures sur des données qui changent moins souvent.

Hudi fournit trois vues logiques pour l'accès aux données :

• Vue optimisée en lecture – Fournit le dernier ensemble de données validé de tables CoW et le dernier jeu de données compressé de tables MoR.

• Vue incrémentielle : fournit un flux de modifications entre deux actions issues d'un jeu de données CoW pour alimenter les tâches en aval et extraire, transformer, charger (ETL) les flux de travail.

• Vue en temps réel – Fournit les dernières données validées d'une table de MoR en fusionnant en ligne les fichiers de colonnes et les fichiers basés sur des lignes.

Lorsque vous interrogez la vue optimisée en lecture, la requête renvoie toutes les données compressées mais n'inclut pas les dernières validations delta. L'interrogation de ces données fournit de bonnes performances de lecture, mais ignore les données les plus à jour. Lorsque vous interrogez la vue en temps réel, Hudi fusionne les données compressées avec les validations delta sur lecture. Les données les plus à jour sont disponibles pour interrogation, mais la surcharge de calcul de la fusion rend la requête moins performante. La possibilité d'interroger des données compressées ou des données en temps réel vous permet de choisir entre performances et flexibilité lorsque vous exécutez des requêtes.

Pour plus d'informations sur les avantages et inconvénients des types de stockage, consultez Storage Types & Views dans la documentation Apache Hudi.

Hudi crée deux tables dans le metastore Hive pour le type de stockage MoR : une table avec le nom que vous avez spécifié, qui est une vue optimisée en lecture, et une table avec le même nom auquel est ajouté _rt, qui est une vue en temps réel. Vous pouvez interroger les deux tables.

Enregistrement d'un jeu de données Hudi auprès de votre métastore

Lorsque vous enregistrez une table Hudi dans le métastore Hive, vous pouvez interroger les tables Hudi à l'aide de Hive, Spark SQL ou Presto comme vous le feriez avec n'importe quelle autre table. En outre, vous pouvez intégrer Hudi à AWS Glue en configurant Hive et Spark pour utiliser le catalogue de données AWS Glue comme métastore. Pour les tables MoR, Hudi enregistre le jeu de données sous la forme de deux tables dans le metastore : une table avec le nom que vous avez spécifié, qui est une vue optimisée en lecture, et une table avec le même nom auquel est ajouté _rt, qui est une vue en temps réel.

Vous enregistrez une table Hudi auprès du metastore Hive lorsque vous utilisez Spark pour créer un jeu de données Hudi en définissant l'option HIVE_SYNC_ENABLED_OPT_KEY sur "true" et en fournissant d'autres propriétés requises. Pour plus d’informations, consultez Travailler avec un jeu de données Hudi. En outre, vous pouvez utiliser l'utilitaire de ligne de commande hive_sync_tool pour enregistrer un jeu de données Hudi en tant que table dans votre metastore, séparément.