Parquet Content-Defined Chunking : déduplication efficace avec Xet sur Hugging Face

TL;DR

• Le Parquet Content-Defined Chunking (CDC) est désormais disponible dans PyArrow et Pandas et fonctionne avec le stockage Xet de Hugging Face pour une déduplication efficace.
• Le CDC déduplique les données au niveau des pages de données avant la sérialisation et la compression, réduisant les uploads/downloads entre les dépôts et les fichiers.
• Activez le CDC Parquet en passant use_content_defined_chunking=True lors de l’écriture Parquet; les URIs PyArrow peuvent être utilisées avec le schéma hf:// pour les lectures/écritures sur le Hub.
• L’alliance CDC + Xet réduit de manière significative les transferts de données et les coûts de stockage pour les grands ensembles de données sur Hugging Face.

Contexte et historique

Parquet est un format de stockage en colonnes largement utilisé en ingénierie des données, et Hugging Face héberge une partie importante de ses données Parquet sur le Hub. Le nouvel espace de stockage Xet utilise un chunking défini par le contenu pour dédupliquer les blocs de données, réduisant les coûts de stockage et accélérant les uploads et les downloads. Comme la disposition de Parquet—en particulier les chunks de colonnes et les pages de données—peut produire des représentations en octets différentes pour de petits changements, la déduplication peut être sous-optimale sans un chunking aligné sur le contenu. C’est là qu’apparaît le CDC: il aligne les limites des chunks sur les valeurs de données logiques, permettant une déduplication plus efficace avant sérialisation ou compression. La démonstration utilise l’exemple OpenOrca pour illustrer le flux. Depuis PyArrow 21.0.0, les URI Hugging Face peuvent être utilisées directement dans les fonctions PyArrow pour lire et écrire Parquet (et d’autres formats) sur le Hub via le schéma hf://. Cette intégration permet des opérations de bout en bout sur Parquet dans le Hub sans quitter l’environnement, et illustre comment le CDC interagit avec Xet pour la déduplication entre dépôts et fichiers. L’objectif est de réduire les transferts de données tout en conservant l’accessibilité et la compatibilité avec les lecteurs et écrivains existants. Hugging Face Blog. Les systèmes traditionnels ne dédupliquent pas les fichiers entre dépôts, entraînant des ré-upload complets et des redownloads. En revanche, un système utilisant le chunking défini par le contenu peut reconnaître le contenu identique et éviter de transférer les données inchangées. Le billet montre que des tables identiques envoyées sur le Hub peuvent être transférées instantanément lorsque CDC est activé, et la déduplication fonctionne entre les dépôts. Cette capacité trans-dépôt est une caractéristique clé de Xet pour favoriser le partage de données. Hugging Face Blog. Les démonstrations présentent comment la déduplication évolue lors de l’ajout ou suppression de colonnes, ou lors d’un changement de type, avec des heatmaps et des métriques de déduplication pour comprendre où les données sont transférées. Hugging Face Blog. Pour illustrer le mécanisme, l’article montre que l’activation du CDC Parquet entraîne des transferts bien moindres lors de l’envoi de l’ensemble original et de son remplacement par rapport au cas sans CDC. Les mêmes bénéfices s’appliquent aux téléchargements via huggingface_hub.hf_hub_download() et datasets.load_dataset(). Hugging Face Blog.

Quoi de neuf

Les points clés sont:

• CDC Parquet est pris en charge dans PyArrow et Pandas, optimisant la déduplication via le storage Xet.
• Pour activer le CDC, utilisez write_parquet avec use_content_defined_chunking=True. L’accès via des URIs hf:// est pris en charge pour les opérations sur le Hub. Hugging Face Blog.
• Les bénéfices de déduplication dépendent de la répartition des changements; la déduplication peut diminuer si la plupart des pages sont affectées. CDC agit au niveau des pages de données Parquet, avant sérialisation et compression. Hugging Face Blog.
• Les écrivains Parquet utilisent par défaut des groupes de lignes de taille fixe; des ajustements peuvent être faits pour équilibrer performances et mémoire. Modifier les frontières des groupes peut déplacer des valeurs entre les pages et impacter la déduplication. Hugging Face Blog.
• Sur des ensembles constitués de plusieurs fichiers, CDC + Xet dédupliquent les données même lorsque les fichiers sont divisés selon des frontières différentes, facilitant le parallélisme et l’accès. Hugging Face Blog.

Pourquoi c’est important (impact pour les développeurs/entreprises)

Pour les équipes manipulant d’importants ensembles Parquet, CDC Parquet sur Xet se traduit par une réduction de coûts et de temps. Avantages pratiques:

• Transferts de données nettement plus faibles lors des uploads et downloads grâce à la déduplication entre fichiers et dépôts.
• Coûts de stockage réduits en évitant de réécrire des données déjà connues par le storage.
• Meilleure collaboration entre équipes, avec des mises à jour de données sans re-téléchargement complet.
• Compatibilité avec les flux Parquet existants, tout en bénéficiant des gains de CDC et Xet. Dans les faits, les organisations qui opèrent de gros jeux de données Parquet sur le Hub peuvent s’attendre à des cycles d’itération plus rapides et à une moindre consommation de bande passante lors de la distribution. L’approche s’aligne sur des objectifs plus larges de gestion du stockage, en réduisant le mouvement inutile de données sans sacrifier l’accessibilité. Hugging Face Blog.

Détails techniques ou Implémentation

Retours pratiques pour intégrer CDC Parquet dans les flux de travail:

• CDC Parquet est pris en charge dans PyArrow 21.0.0+ et Pandas, permettant un chunking basé sur le contenu avant sérialisation et compression. L’intégration avec Xet facilite la déduplication entre fichiers et dépôts.
• Pour activer CDC, utilisez write_parquet avec use_content_defined_chunking=True. Les URIs hf:// peuvent être utilisées pour accéder au Hub. Hugging Face Blog.
• Les avantages de déduplication dépendent de la répartition des changements: si la majorité des pages est affectée, le gain peut être moindre; sinon, il est important. CDC agit au niveau des pages de données Parquet, avant sérialisation et compression. Hugging Face Blog.
• La taille des row-groups par défaut et leur gestion influencent le comportement de déduplication; ajuster cette taille peut optimiser les performances ou l’utilisation mémoire. Hugging Face Blog.
• Lorsqu’un dataset est réparti sur plusieurs fichiers, CDC + Xet continue de dédupliquer les données lors du transfert entre fichiers, ce qui favorise le parallélisme et l’accès rapide. Hugging Face Blog.
• Les lecteurs et outils de téléchargement bénéficient également du CDC pour des flux comme hf_hub_download() et datasets.load_dataset(). Hugging Face Blog. Considérations pratiques: choisir la bonne taille de row-group selon la charge de travail et comprendre que la répartition des changements influence le gain. CDC est appliqué au niveau des pages de données Parquet, ce qui permet un chunking cohérent et une meilleure déduplication lors des mises à jour. Hugging Face Blog.

Points clés (Key takeaways)

• CDC Parquet apporte un chunking défini par le contenu pour améliorer la déduplication sur Xet.
• L’activation se fait via use_content_defined_chunking=True et fonctionne avec les URIs hf:// pour les opérations sur le Hub.
• Cette combinaison réduit les transferts et les coûts de stockage et facilite la déduplication entre fichiers et dépôts.
• La taille de row-group et la distribution des changements influencent les performances; CDC aide à atténuer les défis liés à ces paramètres.
• Les lecteurs, écrivains et outils de téléchargement bénéficient des flux CDC-enabled tout en restant compatibles avec les pipelines Parquet existants. Hugging Face Blog.

Références

• https://huggingface.co/blog/parquet-cdc