Spécifications de la table Apache Iceberg v3 : la communauté open source célèbre son succès commun

Le projet Apache IcebergTM incarne l’esprit de l’open source et montre ce qui est possible lorsqu’une communauté se réunit avec un objectif commun : faire avancer une technologie. Sa mission étant d’apporter fiabilité, performances et ouverture à l’analytique à grande échelle, le projet Iceberg continue d’évoluer et d’offrir de nombreux avantages grâce à la diversité des voix et des efforts de ses contributeurs.

Le dernier jalon d’Iceberg, la ratification des spécifications de la table v3, est plus qu’une simple mise à jour technique. Il est le résultat d’un design réfléchi, de discussions rigoureuses et d’une collaboration entre des dizaines d’entreprises et des centaines de personnes. Les spécifications de la table v3 reflètent un investissement partagé dans l’avenir des architectures de données ouvertes et un engagement à ce qu’Iceberg reste véritablement indépendant des fournisseurs, flexible et axé sur la communauté.

Cet article mettra en avant les principales fonctionnalités de la spécification de la table v3 et mettra en lumière le travail collectif qui a donné vie à cette version.

Développement impulsé par la communauté

Au cours des deux dernières années, Iceberg s’est imposé comme une norme majeure pour les formats de table ouverts, permettant aux utilisateurs comme aux fournisseurs de se mettre d’accord sur une structure pour leurs données et, par conséquent, de bénéficier de l’interopérabilité qu’elle permet. Ce n’est qu’avec la contribution de l’ensemble de la communauté que le projet Iceberg pourra véritablement prospérer et offrir tous les avantages – ouverture, neutralité vis-à-vis des fournisseurs et interopérabilité – qui le rendent précieux.

Avec l’open source, tout le monde peut suggérer une nouvelle fonctionnalité, la créer lui-même et travailler avec d’autres contributeurs pour l’intégrer au projet. Les fonctionnalités intégrées dans la dernière spécification des Iceberg Tables sont le résultat de nombreuses discussions avec des fournisseurs et des particuliers, qui ont décrit ce dont ils avaient besoin de la part d’Iceberg pour continuer à utiliser ou à adopter la technologie. Par exemple, les fournisseurs disposant de leurs propres formats de table propriétaires pourraient suggérer d’ajouter certaines fonctionnalités à Iceberg par souci de cohérence, mais celles-ci ne seraient intégrées que si l’ensemble de la communauté Iceberg acceptait que ces fonctionnalités seraient bénéfiques au projet. C’est l’open source.

Le grand nombre d’utilisateurs, de contributeurs et de fournisseurs qui soutiennent Iceberg signifie que les fonctionnalités suggérées et les améliorations proposées offriront diverses perspectives et que les implémentations qui en résulteront seront plus robustes, ce qui nous amène aux spécifications de la table v3.

Présentation des spécifications de la table v3

La spécification de table v3 représente une étape majeure pour la technologie, en apportant un certain nombre de nouvelles fonctionnalités incroyables et en libérant d’innombrables cas d’usage pour les utilisateurs. 

Valeurs par défaut

Ce que ça fait : avec les valeurs par défaut, les utilisateurs d’Iceberg peuvent gérer les valeurs nulles et manquantes dans leurs tables v3. 

Comment ça marche : les valeurs par défaut sont possibles avec l’ajout de deux nouvelles configurations de tables. En définissant write-default, les utilisateurs peuvent contrôler la façon dont leurs rédacteurs gèrent les valeurs manquantes des champs. Pour plus de flexibilité, cela peut être modifié à tout moment. D’autre part, initial-default, qui est défini une fois pour une table, fournit aux utilisateurs un mécanisme pour remplacer les valeurs nulles existantes par une valeur spécifiée. 

Qui l’a rendue possible :

• Shenoda Guirguis, proposition de spécifications originale

• Limian (Raymond) Zhang, spécification finalisée

• Mise en œuvre

  • Ryan Blue, Iceberg PMC Chair

  • Walaa Eldin Moustafa

Vecteurs de suppression

Ce que ça fait : les vecteurs de suppression sont le nouveau mécanisme par défaut pour la gestion des suppressions de position dans Iceberg. Les utilisateurs n’ont plus à faire de compromis généralement associés à la configuration des suppressions de position, e.g. choisissant entre réduire le nombre de petits fichiers (en activant la granularité au niveau des partitions) et des lectures plus efficaces (en activant la granularité au niveau des fichiers). 

Comment ça marche : une fois mis en œuvre, les vecteurs de suppression remplaceront les suppressions de position. La conception implique le stockage de plusieurs vecteurs de suppression sous forme de bitmaps rugissants dans des fichiers Puffin, un type de fichier performant déjà utilisé dans le cadre du projet Iceberg, où ils sont accessibles efficacement via un index. Point intéressant, « Iceberg v2 avait une notion de [vecteurs de suppression], mais ceux-ci étaient utilisés en mémoire », explique Anton Okolnychyi, Iceberg Project Management Committee (PMC) Member et Senior Staff Software Engineer chez Databricks. « Sur le disque vous aviez des fichiers Parquet, en mémoire des bitmaps. Et une fois que nous avons conçu la v3, nous avons voulu voir ce qui pouvait être fait différemment pour éviter les frais généraux de conversion. » 

La décision de la communauté d’utiliser les fichiers Puffin par rapport à l’implémentation Parquet existante offre des gains de performances aux utilisateurs et peut potentiellement s’avérer meilleure pour les cas d’usage à faible latence. En fin de compte, les vecteurs de suppression offrent aux utilisateurs le meilleur des deux mondes : les suppressions de position s’appliquent à une granularité au niveau des fichiers pour des lectures plus efficaces, mais elles sont physiquement stockées dans des fichiers Puffin consolidés pour réduire le nombre de petits fichiers.

Qui l’a rendue possible :

• Changements de spécifications

  • Renjie Liu, Iceberg PMC Member, proposition originale

  • Anton Okolnychyi, changements finalisés

• Mise en œuvre

  • Amogh Jahagirdar, Iceberg PMC Member

  • Eduard Tudenhoefner, Iceberg PMC Member

Types de données géospatiaux

Ce que ça fait : Iceberg prend désormais en charge deux nouveaux types géospatiaux, la géométrie et la géographie, ce qui permet un meilleur alignement avec les autres projets et offre aux utilisateurs la possibilité d’exploiter de meilleures fonctionnalités autour des données cartographiques et de localisation. 

Selon Jia Yu, Apache Sedona PMC Chair et co-fondatrice de Wherobots, la dernière fonctionnalité est le résultat d’une tonne de recherches communautaires. Ils ont passé en revue un certain nombre de projets et de technologies bénéficiant d’une assistance géospatiale, tels que « Sedona, Databricks, Snowflake, BigQuery, pandas » et plus encore, qui « ont tous une définition différente des données géospatiales... différents types... le comportement de ces types est vraiment différent ». 

Comment ça marche : au-delà de la simple mise à disposition des types géospatiaux dans Iceberg, le changement de spécification aborde également des questions complexes telles que la gestion du partitionnement et du filtrage des champs géospatiaux ainsi que les indicateurs au niveau des colonnes pour ces types de données. Predicate pushdown et des indicateurs réguliers au niveau des colonnes sont toujours disponibles pour les types géospatiaux avec des cases de délimitation décrites par des points géospatiaux servant de maximums et de minimums. 

Qui l’a rendue possible :

• Changements de spécifications

  • Szehon Ho, Iceberg PMC Member

  • Gang Wu

• Kristin Cowalcijk, mise en œuvre

• Une mention spéciale à toute l’équipe Wherobots, qui a mis en œuvre la prise en charge du type géospatial sur sa propre fourche d’Iceberg avant d’offrir son expertise à la communauté Iceberg, en assurant le leadership et en mettant en œuvre la fonctionnalité pour le projet Iceberg.

Transformations multi-arguments

Ce que ça fait : les transformations multi-arguments permettent aux utilisateurs d’effectuer des transformations sur plusieurs champs à des fins de partitionnement et de tri dans Iceberg. Avant la spécification de la table v3, un seul champ pouvait être transformé à ces fins.

Qui l’a rendue possible :

• 叶先进, modifications de spécifications

• Mise en œuvre

  • Fokko Driesprong, Iceberg PMC Member

  • JB Onofré, ASF Board Member

Traçabilité des lignes

Ce que ça fait : la traçabilité des lignes permet aux utilisateurs de suivre plus facilement l’évolution des lignes dans une Iceberg Table au fil du temps, ce qui permet de débloquer un certain nombre de cas d’usage, notamment des flux de travail améliorés de capture des données de changement (CDC), un audit plus facile et une meilleure maintenance des vues matérialisées. En fin de compte, l’ajout de la traçabilité des lignes dans Iceberg « signifie que les utilisateurs d’Iceberg seront en mesure de déterminer avec précision l’historique de n’importe quelle ligne dans leurs tables », explique Russell Spitzer, Iceberg PMC Member et Principal Software Engineer chez Snowflake. « Auparavant, nous ne pouvions deviner qu’en nous basant sur les colonnes d’identité définies par l’utilisateur. Aujourd’hui, le format lui-même est intégré ! »

Comment ça marche : chaque ligne d’une Iceberg Table comprend deux champs supplémentaires, _row_id et _last_updated_sequence_number. La communauté Iceberg a pu mettre en œuvre cette approche de telle sorte que toutes les lignes n’aient pas à stocker explicitement des valeurs dans ces champs. Au lieu de cela, pour gagner de l’espace, les valeurs des colonnes sont implicites jusqu’à ce qu’elles soient matérialisées par une requête en lecture et ce n’est qu’alors que les valeurs sont propagées par la couche de métadonnées (Metadata.json → Snapshot → Manifest → Datafile → Row).

Qui l’a rendue possible :

• Changements de spécifications

  • Russell Spitzer

  • Nileema Shingte

  • Attila-Péter Tóth

• Mise en œuvre

  • Russell Spitzer, noyau 

  • Ryan Blue, noyau 

  • Amogh Jahagirdar, Spark 

Chiffrement des tables

Ce que ça fait : la dernière mise à jour concernant le chiffrement des tables débloque le chiffrement côté client des Iceberg Tables, ce qui permet aux utilisateurs de chiffrer toutes leurs données et métadonnées. Des tables entières peuvent être chiffrées avec une seule clé ou l’accès peut être contrôlé au niveau des aperçus. 

Comment ça marche : pour rendre le chiffrement des tables côté client possible dans Iceberg, les utilisateurs peuvent associer des aperçus de tables individuels à des clés de chiffrement stockées dans un magasin de clés tiers. Pour commencer à accéder aux données dans un aperçu spécifique, les clients doivent avoir accès à ce magasin de clés et à la clé de chiffrement afin de déchiffrer et d’accéder à la liste des manifestes de l’aperçu. À partir de là, les listes de manifestes disposent d’un mécanisme similaire pour permettre aux clients de déchiffrer les fichiers manifestes et, enfin, les fichiers manifestes disposent d’une clé de chiffrement des fichiers de données permettant aux clients d’accéder aux fichiers de données. 

Qui l’a rendue possible :

• Changements de spécifications et mise en œuvre

  • Gidon Gerchinski

  • Russell Spitzer

  • Ryan Blue

Type de données Variant

Ce que ça fait : les types Variant permettent aux utilisateurs de gérer des jeux de données semi-structurées moins réguliers où certains champs sont utilisés par intermittence. Prenons l’exemple de données de capteurs : tous les capteurs peuvent indiquer un emplacement et un horodatage, mais certains capteurs indiquent la température, d’autres l’humidité, etc. Comme le dit Aihua Xu, Senior Software Engineer chez Snowflake, l’un des contributeurs au type Variant : « L’ajout de [la variante] à la spécification Iceberg v3 visait à répondre aux réalités des données d’aujourd’hui. La prise en charge native [des variantes] permet à Iceberg de représenter et de traiter efficacement ce type de données, libérant ainsi les performances et la flexibilité sans compromis sur la structure. »

Comment ça marche : le type de données Variant permet aux utilisateurs de stocker des types et des champs variables dans des tables Apache Iceberg™, où les noms des champs et leurs types sont extraits dans des champs de métadonnées et de valeurs, puis stockés en binaire. La lecture des données implique une désérialisation. Pour gagner en efficacité, une fonctionnalité supplémentaire appelée « shredding » permet d’extraire et de stocker les champs cohérents, tels que l’emplacement et l’horodatage dans l’exemple précédent, et leurs types dans Parquet ; les champs restants sont stockés dans les champs de métadonnées et de valeur comme décrit ci-dessus. 

Qui l’a rendue possible :

• Changements de spécifications

  • Tyler Akidau, proposition originale 

  • Aihua Xu, changements finalisés

• Mise en œuvre

  • Aihua Xu, implémentation noyau

  • Ryan Blue, noyau

  • David Cashman, shredding

  • Gene Peng, encodage et travail influent sur le type de données Variant dans Apache Spark

  • Neil Chao, Apache Arrow 

Où nous en sommes et ce qui nous attend

Aucune des fonctionnalités susmentionnées n’aurait été possible sans le travail acharné et la collaboration continue de l’ensemble de la communauté Iceberg. Le travail accompli par tout le monde pour cette dernière spécification témoigne véritablement de l’esprit open source, illustrant comment les individus, les fournisseurs et les utilisateurs peuvent se rassembler pour faire avancer toute une technologie. 

Sur ce, nous voudrions remercier chaleureusement toutes les personnes qui ont contribué à Iceberg et rendu possible la spécification de la table v3, à la fois celles mentionnées ci-dessus et toutes les autres.

Dans sa forme actuelle, la diversité du projet Iceberg, tant au niveau individuel qu’au niveau des entreprises, en dit long sur la santé de la communauté et de l’écosystème. Son succès continu dépendra d’une large adoption des spécifications de la table v3 et d’une intégration généralisée aux technologies existantes et nouvelles. Heureusement, c’est le cas, alors que de plus en plus de technologies, d’entreprises et de fournisseurs soutiennent Iceberg chaque jour.