À propos des cookies sur ce site Pour fonctionner correctement, nos sites Internet nécessitent certains cookies (requis). En outre, d'autres cookies peuvent être utilisés avec votre consentement pour analyser l'utilisation d'un site, améliorer l'expérience des utilisateurs et à des fins publicitaires. Pour plus informations, passez en revue vos options de préférences en. En visitant notre site Web, vous acceptez que nous traitions les informations comme décrit dans ladéclaration de confidentialité d’IBM. Pour faciliter la navigation, vos préférences en matière de cookie seront partagées dans les domaines Web d'IBM énumérés ici.
Qu'est-ce qu'Apache Iceberg ?
Publication : 26 février 2024
Contributeur : Dave Bergmann
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.
Un entrepôt de données adapté à vos besoins, conçu sur une architecture de type data lakehouse ouverte pour vous permettre de faire évoluer les workloads d’IA, et ce pour toutes vos données, où qu’elles se trouvent
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.
Apache Iceberg, Delta Lake et Apache Hudi
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.
Catalogue Iceberg
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.
Couche de métadonnées
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.
Liste de manifestes
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.
Fichier manifeste
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.
Couche de données
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.
Partitionnement caché
Iceberg gère tous les détails du partitionnement et des requêtes 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.
Évolution de schéma
Iceberg fournit 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é.
Compactage et filtrage des données
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.
Solutions connexes
Accédez à vos données et optimisez les workloads coûteuses avec watsonx.data, un entrepôt de données adapté basé sur une architecture de data lakehouse ouverte pour développer les workloads d’IA, pour toutes vos données, n’importe où.
Exécutez les analyses et les workloads d’IA essentiels avec tous les types de données et partout : IBM Db2 Warehouse répond à vos objectifs de prix et de performances pour les workloads permanents, vous offrant ainsi un accès simple et gouverné à toutes vos données et éliminant les silos de données sur le cloud hybride.
Faites évoluer l’analytique et l’IA grâce à un entrepôt de données cloud unifié, gouverné et rentable. Grâce à la prise en charge de formats ouverts tels que Parquet et Apache Iceberg ainsi qu'à une intégration native à votre data lake et au lakehouse IBM watsonx.data™, Netezza permet aux experts en ingénierie des données, aux data scientists et aux analystes de données d'exécuter des workloads complexes sans ETC supplémentaire ni transfert de données via Cloud Object Storage.
Alimentez vos applications, l’analytique et l’IA avec n’importe quelles données dans un data lakehouse ouvert. Contrairement aux entrepôts de données traditionnels, les data lakehouses peuvent traiter des vidéos, des fichiers audio, des journaux, des textes, des réseaux sociaux, des données de capteurs et des documents pour alimenter les applications, l'analytique et l’IA. Ils peuvent être créés dans le cadre d’une architecture data fabric pour fournir les bonnes données, au bon moment, et ce où qu’elles soient stockées.
Ressources Apache Iceberg
Apprenez-en plus sur le partitionnement dans Apache Iceberg et suivez un exemple pour voir à quel point Iceberg facilite l’évolution des partitions.
Rédigé par des directeurs et des leaders des données et d’autres experts d’IBM et d’ailleurs, ce guide vous aidera à déployer la bonne stratégie, les technologies et la culture d’entreprise nécessaires pour diriger une organisation qui est axée sur les données et qui s’appuie sur l’IA.
Dans un contexte difficile de hausse des coûts des données, de prolifération des silos de données et d’augmentation des exigences réglementaires, les entreprises doivent plus que jamais tirer parti de l’IA pour obtenir un avantage concurrentiel.
Notes de bas de page
Tous les liens sont externes au site ibm.com.
1 « Apache Iceberg: The Hub of an Emerging Data Service Ecosystem? » (lien externe à ibm.com), Datanami, 8 février 2021
2 « Clash of ACID Data Lakes: Comparing Data Lakehouse Formats » (lien externe à ibm.com), Data Insights, 9 août 2022