Apache Iceberg est un format de table de données open source conçu pour être utilisé avec de très vastes ensembles de données analytiques. Il facilite l’utilisation de tables SQL pour le big data et leur intégration avec des moteurs tels que Apache Spark, Trino, Flink, Presto, Hive et Impala.
Outre sa spécification ouverte, Iceberg intègre aussi un ensemble d’API et de bibliothèques qui permet aux moteurs de stockage, de requête et d’exécution d’interagir de manière optimale avec les tables suivant ce format.
Le format de table Iceberg fait désormais partie intégrante de l’écosystème big data. Cela est dû en grande partie à ses nombreuses fonctionnalités. En exploitant les métadonnées de chaque table, Iceberg permet de modifier facilement le schéma et le partitionnement, mais aussi d’accéder aux versions historiques de la table, sans réécriture ou migration coûteuses. Ce format prend en charge différents systèmes de stockage et sources de données, sans dépendance au système de fichier.
Créé par des ingénieurs de données de Netflix et Apple en 2017 pour combler les lacunes d’Apache Hive, Iceberg a été publié en open source et donné à l’Apache Software Foundation l’année suivante. En 2020, le projet Iceberg est devenu un « top-level project » Apache.
La vitesse, l’efficacité, la fiabilité et la convivialité d’Apache Iceberg simplifient le traitement des données à toutes les échelles. Ces atouts en ont fait un format de table de choix pour un certain nombre d’entrepôts de données, de data lakes et de data lakehouses de premier plan, dont IBM watsonx.data, Netezza et Db2 warehouse.
Restez au fait des tendances les plus étonnantes du secteur dans le domaine de l’IA, de l’automatisation, des données et bien d’autres avec la newsletter Think. Consultez la Déclaration de confidentialité d’IBM.
Iceberg est l’un des rares formats de table open source à prendre en charge les transactions ACID : des échanges de données qui préservent la fiabilité en garantissant l’atomicité, la cohérence, l’isolement et la durabilité.
Iceberg a été créé pour remédier aux limites pratiques des tables Apache Hive dans un environnement de data lake vaste. Selon Ryan Blue, président PMC du projet Apache Iceberg et (ancien) ingénieur senior chez Netflix, « de nombreux services et moteurs utilisaient les tables Hive. Le problème, c’est que nous n’avions pas cette garantie d’exactitude. Nous n’avions pas de transactions atomiques », a-t-il déclaré lors d’une conférence en 2021. « Parfois, les modifications apportées par un système occasionnaient des erreurs de données au niveau d’un autre système. Par conséquent, nous avions renoncé à utiliser ces services et à modifier nos tables, par simple mesure de sécurité. » 1
Apache Hive a été créé pour permettre aux clusters Apache Hadoop de fonctionner de manière similaire aux bases de données relationnelles accessibles en SQL. Particulièrement efficace pour les données statiques, l’outil s’adapte mal aux jeux de données évolutifs : les changements doivent être coordonnés manuellement entre les différentes applications et les utilisateurs, sous peine d’entraîner une corruption ou des inexactitudes sur les jeux de données volumineux.
Pour préserver la précision dans un environnement dynamique, Iceberg a été conçu de manière à garantir que toute transaction de données présente les quatre propriétés ACID :
Toutes les modifications apportées aux données sont effectuées comme s’il s’agissait d’une seule opération, c’est-à-dire que soit toutes les modifications sont exécutées, soit aucune ne l’est. Par exemple, dans une transaction de données financières, l’atomicité garantit que tout débit effectué sur un compte corresponde à un crédit sur un autre compte.
Il n’y a aucune contradiction entre l’état global des données avant la transaction et l’état des données après la transaction. Pour garder l’exemple de la transaction financière, la cohérence garantit que les fonds combinés existant entre les deux comptes sont les mêmes avant et après la transaction.
L’état intermédiaire de toute transaction n’impacte pas les autres transactions : les opérations concomitantes, exécutées simultanément sur le même jeu de données, sont traitées comme si elles étaient successives. Dans notre exemple de transaction financière, l’isolation garantit que, lors de toute autre transaction, les fonds apparaitront soit dans le compte débité soit dans le compte crédité, mais pas dans les deux (ni dans aucun).
Après une transaction réussie, toutes les modifications de données persistent, même en cas de défaillance du système. Dans notre exemple financier, cela signifie que la transaction restera achevée, même si elle est immédiatement suivie d’une panne à l’échelle du système.
Le format de table Apache Iceberg est souvent comparé à deux autres technologies de données open source offrant des transactions ACID : Delta Lake, une couche de stockage optimisée, créée par Databricks, qui étend les fichiers de données Parquet avec un journal des transactions basé sur des fichiers et le traitement évolutif des métadonnées, et Apache Hudi (abréviation de « Hadoop Upserts Deletes and Incrementals »), développé par Uber en 2016.
Dans le cadre d’une étude menée en 2022 par Synvert, des données aléatoires ont été générées et stockées au format JSON dans un compartiment AWS S3 à des fins d’analyse comparative des trois technologies. Les tests ont démontré que le format de table optimisé d’Iceberg offrait des performances supérieures à celles de Delta Lake et d’Apache Hudi sur tous les indicateurs testés.2
Stockage : la taille des fichiers de tables Iceberg était nettement inférieure à Delta Lake ou Hudi, un avantage majeur en termes d’optimisation du stockage.
Opérations d’insertion : pour les opérations d’insertion, Iceberg a également montré les performances les plus rapides, c’est-à-dire la durée d’exécution la plus courte. Iceberg et Delta Lake étaient nettement plus rapides que Hudi.
Opérations de mise à jour : pour les opérations de mise à jour, Iceberg était beaucoup plus rapide que Delta Lake et Hudi. Il ressort notamment que, contrairement à ses homologues, le temps d’exécution d’Iceberg n’a pas augmenté de manière significative avec le nombre total d’enregistrements : aux workloads maximaux testés dans le cadre de l’étude (500 millions d’enregistrements), Iceberg était près de 10 fois plus rapide que Delta Lake.
Opérations de suppression : Iceberg exécutait les opérations de suppression bien plus rapidement que ses deux alternatives.
Iceberg met en œuvre une hiérarchie de fichiers de métadonnées à trois niveaux afin de garantir l'exactitude et la coordination des données des tables dans différents formats de fichiers et avec des changements constants.
Écrit en Java et Python, et également proposé sur une API Scala, Iceberg prend en charge une multitude de formats de fichiers big data, dont Apache Parquet, Apache Avro et Apache ORC. Il offre des fonctionnalités similaires à celles des tables SQL dans les bases de données traditionnelles, avec une compatibilité avec différents formats de fichier et fournisseurs, ce qui permet à plusieurs moteurs de fonctionner sur le même jeu de données.
L’architecture d’une table Iceberg se compose de trois couches : le catalogue Iceberg, la couche de métadonnées et la couche de données.
Le catalogue Iceberg repose sur la couche de métadonnées et la couche de données, un peu comme la partie émergée d’un iceberg, au-dessus de la surface de l’eau. Il renferme les pointeurs de métadonnées actuels, qui associent le nom de la table et l’emplacement de son ou de ses fichiers de métadonnées actuels. Outre son catalogue intégré, Iceberg prend en charge d’autres catalogues comme Hive MetaStore ou AWS Glue.
Les opérations au niveau du catalogue Iceberg sont atomiques, car cela est essentiel pour garantir l’exactitude des transactions en cours.
Un moteur de requête émet ainsi une requête SELECT au catalogue Iceberg, qui fournit l’emplacement du fichier de métadonnées actuel de la table que le moteur de requête cherche à lire.
La couche de métadonnées Iceberg comprend, par ordre décroissant, des fichiers de métadonnées, des listes de manifestes et des fichiers manifestes.
Fichier de métadonnées Les fichiers de métadonnées stockent les métadonnées d’une table, notamment le schéma de la table, les informations de partitionnement, son instantané actuel et les instantanés des états précédents. Une fois dirigé vers le fichier de métadonnées actuel à partir de l’entrée de la table dans le catalogue Iceberg, le moteur de requête utilise la valeur [current-snapshot-id] pour trouver son entrée dans le tableau [snapshots]. À partir de là, il peut localiser et ouvrir la liste de manifeste de la table.
La liste de manifestes est simplement une liste de fichiers manifestes et d’informations importantes pour chaque fichier de données présent, comme son emplacement, l’instantané auquel il est associé et les partitions auxquelles il appartient. Certaines optimisations et fonctions de filtrage sont disponibles à ce stade.
Les fichiers manifestes permettent un suivi des fichiers de données et des détails, métadonnées et statistiques associés. Cela explique l’un des avantages fondamentaux du format de table Iceberg par rapport au format de table Hive : sa capacité à suivre les données au niveau des fichiers. À ce stade, les valeurs [file-path] de chaque objet [data-file] peuvent être utilisées pour trouver et ouvrir ce fichier.
Comme son nom l’indique, la couche de données se trouve sous la couche de métadonnées et contient les fichiers définitifs.
Apache Iceberg offre un certain nombre de fonctionnalités utiles pour améliorer et simplifier la gestion des données.
Iceberg gère tous les détails du partitionnement et de l’interrogation sous le capot. Le partitionnement caché d’Iceberg évite aux utilisateurs d’avoir à fournir des informations sur la disposition des partitions lors de l’interrogation des tables. Les utilisateurs n’ont pas besoin de gérer eux-mêmes les colonnes de partition, ni même de comprendre l’agencement de la table physique, pour obtenir des résultats précis.
Cela rend non seulement le partitionnement d’Iceberg très intuitif, mais permet également de modifier la disposition des partitions au fil du temps sans casser les requêtes préécrites. Lorsque les spécifications de partition évoluent, les données de la table (et leurs métadonnées) ne sont pas affectées. Seules les nouvelles données, écrites dans la table après l’évolution, sont partitionnées selon les nouvelles spécifications, et les métadonnées de ces nouvelles données sont conservées séparément.
Iceberg offre un support natif pour l’évolution des schémas. Cela permet aux utilisateurs de modifier les schémas de table sans cela nécessite de migrations de données complexes, ce qui simplifie considérablement l’adaptation à l’évolution des structures de données.
Voyage dans le temps Iceberg permet aux utilisateurs de remonter dans le temps grâce à des instantanés de données Iceberg à différents moments dans le temps. Cela s’avère utile pour de nombreux cas d’utilisation, notamment les audits, le débogage et les contrôles de conformité.
Iceberg propose un certain nombre de capacités d’indexation qui permettent d’optimiser les performances des requêtes, telles que des options de compactage pour fusionner les petits fichiers avec de plus gros et ainsi réduire la surcharge de métadonnées, et des filtres Bloom pour réduire la lecture inutile de données pendant l’exécution des requêtes.
Exploitez vos données où qu’elles se trouvent grâce à un data lakehouse hybride et ouvert pour l’IA et l’analytique.
Relevez les défis des données d’aujourd’hui grâce à une architecture de data lakehouse. Connectez-vous aux données en quelques minutes, obtenez rapidement des informations fiables et réduisez les coûts de votre entrepôt de données.
Avec IBM Consulting, exploitez les données de votre entreprise et développez une organisation basée sur les informations pour tirer des avantages métier.
1 « Apache Iceberg: The Hub of an Emerging Data Service Ecosystem? », Datanami, 8 février 2021
2 « Clash of ACID Data Lakes: Comparing Data Lakehouse Formats », synvert, a GlobalLogic company, 9 août 2022