Revenir au contenu principal

Apache Iceberg™ v3 : faire progresser l’écosystème vers l’unification

Apache Iceberg™ v3 contient de nouvelles fonctionnalités majeures (vecteurs de suppression, lignage des lignes, données semi-structurées, types géospatiaux) et unifie la couche de données entre les formats

Apache Iceberg V3 features

Publié: 2 juin 2025

Open Source7 min de lecture

Summary

  • Apache Iceberg™ v3 contient de nouvelles fonctionnalités et améliorations : vecteurs de suppression, lignage au niveau des lignes, données semi-structurées et types géospatiaux.
  • Grâce à ces fonctionnalités, Iceberg v3 unifie la couche de données entre Apache Iceberg™, Delta Lake, Apache Parquet et Apache Spark™.
  • Databricks intègre Iceberg v3 à la plateforme Data Intelligence et se réjouit de l’adoption d’Iceberg v3 par le secteur.

Apache Iceberg™ v3, désormais approuvé par la communauté Apache Iceberg, introduit de nouvelles fonctionnalités avancées et de nouveaux types de données. Iceberg v3 comprend des améliorations majeures telles que les vecteurs de suppression, la lignée des lignes et de nouveaux types pour les cas d’utilisation de données semi-structurées et géospatiales. Ces fonctionnalités permettent aux clients de traiter et d’interroger efficacement les données. De plus, ces améliorations sont cohérentes entre Delta Lake, Apache Parquet et Apache Spark, de sorte que les clients peuvent assurer l’interopérabilité entre Delta et Apache Iceberg sans réécrire les données ni les fichiers de suppression au niveau des lignes.

Dans cet article de blog, nous abordons les dernières nouveautés d’Iceberg v3 :

  • Vecteurs de suppression
  • Lignée des lignes
  • Types de données semi-structurées et géospatiales
  • Interopérabilité entre Delta Lake, Apache Parquet et Apache Spark

Vecteurs de suppression

Iceberg v3 introduit un nouveau format pour les suppressions au niveau des lignes afin d’améliorer les performances de lecture : les vecteurs de suppression. Les suppressions au niveau des lignes réduisent considérablement l’amplification d’écriture en optimisant la façon dont les lignes supprimées sont stockées et suivies, ce qui accélère l’ETL et l’ingestion. Dans Iceberg v2, les moteurs n’étaient pas tenus de compacter les fichiers de suppression ensemble pendant les écritures. L’objectif était que les clients utilisent la maintenance asynchrone. Cependant, de nombreux clients n’ont pas planifié de services de maintenance, de sorte que leurs tables contenaient trop de fichiers de suppression non gérés. Cela a entraîné une lenteur des performances de lecture lorsque les moteurs devaient fusionner de nombreux fichiers de suppression au niveau des lignes lors de la lecture.

Iceberg v3 introduit un nouveau format de vecteur de suppression et de nouvelles exigences de compactage pour les fichiers de suppression. Ce nouveau format évite la traduction entre les fichiers Parquet et les représentations en mémoire utilisées pour appliquer les suppressions. De plus, les moteurs doivent maintenir un seul vecteur de suppression par fichier au moment de l’écriture. Cette exigence améliore les performances et les statistiques sur les fichiers de données. Cela facilite également la comparaison des suppressions précédentes et actuelles, ce qui simplifie le traitement des modifications au niveau des lignes d’une table en tant que flux.

Lignée des lignes

Une autre fonctionnalité majeure d’Iceberg v3 est la lignée des lignes, utilisée pour simplifier le traitement incrémentiel. Grâce à la lignée des lignes, les moteurs trouvent les modifications au niveau des lignes en faisant correspondre les versions des lignes entre les validations.

Iceberg v3 introduit la lignée des lignes à l’aide de métadonnées au niveau des lignes : un ID de ligne et le numéro de séquence lors de la dernière modification ou ajout de la ligne. Les ID identifient la même ligne entre les versions. Les numéros de séquence annotent le moment où les lignes ont été modifiées pour la dernière fois, et pas seulement déplacées entre les fichiers. Cela permet aux moteurs de traiter les modifications de manière sélective, ce qui simplifie les mises à jour en aval avec des workflows plus rapides et moins coûteux.

Les informations d’ID de ligne sont particulièrement utiles lorsqu’elles sont combinées avec des objets de traitement incrémentiel comme les vues matérialisées. Ces objets sont optimisés pour calculer uniquement les données nouvelles ou modifiées depuis le dernier cycle de traitement.

e-book

Démarrer avec l'ETL

Types de données semi-structurées et géospatiales

Iceberg v3 ajoute également de nouveaux types de données pour les données semi-structurées et les données géospatiales.

Les données semi-structurées sont difficiles à stocker, car elles ont des schémas variables, qui ne tiennent pas dans les colonnes de table structurées. Une solution de contournement consiste à extraire des champs individuels de ces données dans un format structuré. Cependant, cela crée des tables extrêmement larges avec de nombreuses colonnes et des valeurs NULL en raison de schémas incohérents. Une autre solution consiste à stocker JSON dans des colonnes de chaîne. Malheureusement, cela entraîne de mauvaises performances de lecture, car les moteurs doivent analyser les données de ces chaînes. Sans types de données semi-structurées, les moteurs ne peuvent pas envoyer de filtres, ils doivent donc lire chaque ligne dans chaque fichier de données. Iceberg v3 introduit VARIANT pour représenter efficacement les données semi-structurées. VARIANT encode la structure des données pour améliorer les performances tout en conservant la flexibilité du schéma.

De même, les données géospatiales (informations associées aux emplacements à la surface de la Terre, comme les routes, les parcs ou les limites de la ville) sont également difficiles à utiliser et à interroger efficacement. Sans types géospatiaux, les clients devaient utiliser des colonnes binaires pour stocker les emplacements de géodonnées. Cependant, cette représentation ne prenait pas en charge la recherche géographique, car les colonnes binaires ne peuvent pas être filtrées pour trouver des objets dans une zone donnée. Iceberg v3 résout ce problème en introduisant de nouveaux types de données de géométrie et de géographie. Les types de géométrie sont destinés aux données spatiales planes, tandis que les types de géographie sont destinés aux données globales tenant compte de la courbure de la Terre. Grâce à ces types, les clients trouvent facilement des données à l’aide de cadres de sélection qui représentent des régions géographiques et localisent efficacement les objets géospatiaux.

Interopérabilité avec Delta Lake, Apache Parquet et Apache Spark

Les nouvelles fonctionnalités et les nouveaux types de données d’Iceberg v3 étendent les fonctionnalités et améliorent les performances. Ces fonctionnalités Apache Iceberg sont également importantes, car elles favorisent l’interopérabilité entre les formats lakehouse.

Historiquement, les clients ont été contraints de choisir entre deux des formats lakehouse les plus populaires : Delta Lake et Apache Iceberg. En effet, la plupart des plateformes ne prennent en charge qu’un seul format. La réécriture des données peut être coûteuse et peu pratique à grande échelle, ce qui rend ce choix à long terme. Les formats sont très similaires : les deux sont des couches de métadonnées au-dessus des fichiers de données Parquet pour fournir une sémantique de table. Cependant, de petites différences dans les formats de table causent des problèmes aux clients.

Iceberg v3 unifie la couche de données entre les formats. Grâce à l’unification des données, les clients peuvent assurer l’interopérabilité entre Delta et Iceberg sans avoir à réécrire les données ni à supprimer les fichiers. En effet, les fonctionnalités d’Iceberg v3 ont des implémentations compatibles entre Delta Lake, Apache Parquet et Apache Spark :

  • Les vecteurs de suppression utilisent les mêmes encodages binaires entre les formats de table
  • La lignée au niveau des lignes dans Iceberg v3 est compatible avec le suivi des lignes dans Delta Lake
  • Les types VARIANT et géodonnées sont en cours de développement dans les communautés Apache Parquet et Apache Spark™ en amont, ce qui s’étend à Apache Iceberg et Delta Lake

En ayant des fonctionnalités compatibles entre les projets open source, Iceberg v3 évite de forcer les clients à choisir un format. Au lieu de cela, les clients peuvent assurer l’interopérabilité librement entre les formats sur une seule copie de leurs données.

En savoir plus sur Iceberg v3

Iceberg v3 fait progresser l’ensemble du secteur vers un monde plus performant, plus performant et plus interopérable. Nous intégrons Iceberg v3 à la plateforme Databricks Data Intelligence et nous sommes impatients de voir d’autres fournisseurs adopter Iceberg v3. L’open source est une valeur fondamentale chez Databricks, où nous contribuons activement à des fonctionnalités telles que les vecteurs de suppression à Iceberg v3. Pour favoriser une communauté open source florissante, nous soutenons et encourageons les contributions à Apache Iceberg. Pour les nouveaux contributeurs, nous recommandons de commencer par un « bon premier problème ».

Pour en savoir plus sur la façon dont nous prévoyons d’intégrer les fonctionnalités d’Iceberg v3 dans notre offre de table gérée et l’avenir des formats de table ouverts, inscrivez-vous au Data and AI Summit du 9 au 12 juin 2025.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original

Ne manquez jamais un article Databricks

Abonnez-vous à notre blog et recevez les derniers articles dans votre boîte mail.