Apache Iceberg est devenu un choix populaire pour la gestion de grands ensembles de données avec flexibilité et évolutivité. Les catalogues sont au cœur de la fonctionnalité d’Iceberg, ce qui est essentiel dans l’organisation des tables, la cohérence et la gestion des métadonnées. Cet article explorera ce que sont les catalogues Iceberg, leurs différentes implémentations, leurs cas d’utilisation et configurations, fournissant ainsi une compréhension des solutions de catalogue les mieux adaptées pour différents cas d’utilisation.
Qu’est-ce qu’un catalogue Iceberg?
Dans Iceberg, un catalogue est responsable de la gestion des chemins des tables, pointant vers les fichiers de métadonnées actuels qui représentent l’état d’une table. Cette architecture est essentielle car elle permet l’atomicité, la cohérence et des requêtes efficaces en garantissant que tous les lecteurs et rédacteurs accèdent au même état de la table. Différentes implémentations de catalogues stockent ces métadonnées de différentes manières, des systèmes de fichiers aux services de métastockage spécialisés.
Responsabilités essentielles d’un catalogue Iceberg
Les responsabilités fondamentales d’un catalogue Iceberg sont:
- Mapping des chemins des tables: Relier un chemin de table (par exemple, « db.table ») au fichier de métadonnées correspondant.
- Prise en charge des opérations atomiques: Garantir la cohérence de l’état de la table lors de lectures/écritures concurrentes.
- Gestion des métadonnées: Stocker et gérer les métadonnées, garantissant l’accessibilité et la cohérence.
Les catalogues Iceberg offrent diverses implémentations pour s’adapter à des architectures système diverses et des besoins de stockage variés. Examinons ces implémentations et leur adéquation pour différents environnements.
Types de catalogues Iceberg
1. Catalogue Hadoop
Le catalogue Hadoop est généralement le plus facile à mettre en place, nécessitant uniquement un système de fichiers. Ce catalogue gère les métadonnées en recherchant le fichier de métadonnées le plus récent dans le répertoire d’une table en fonction des horodatages de fichiers. Cependant, en raison de sa dépendance aux opérations atomiques au niveau des fichiers (que certains systèmes de stockage comme S3 ne possèdent pas), le catalogue Hadoop peut ne pas être adapté aux environnements de production où les écritures concurrentes sont courantes.
Exemple de configuration
Pour configurer le catalogue Hadoop avec Apache Spark:
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.my_catalog.type=hadoop \
--conf spark.sql.catalog.my_catalog.warehouse=file:///D:/sparksetup/iceberg/spark_warehouse
Une autre façon de définir le catalogue dans le job Spark lui-même:
SparkConf sparkConf = new SparkConf()
.setAppName("Example Spark App")
.setMaster("local[*]")
.set("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions")
.set("spark.sql.catalog.local","org.apache.iceberg.spark.SparkCatalog")
.set("spark.sql.catalog.local.type","hadoop")
.set("spark.sql.catalog.local.warehouse", "file:///D:/sparksetup/iceberg/spark_warehouse")
Dans l’exemple ci-dessus, nous définissons le nom du catalogue sur « local » tel que configuré dans Spark “spark.sql.catalog.local« . Ceci peut être un choix de votre nom.
Avantages:
- Configuration simple, aucun metastore externe requis.
- Idéal pour les environnements de développement et de test.
Inconvénients:
- Limité à un seul système de fichiers (par exemple, un seul bucket S3).
- Non recommandé pour la production
2. Catalogue Hive
Le catalogue Hive exploite le Hive Metastore pour gérer l’emplacement des métadonnées, le rendant compatible avec de nombreux outils de données volumineuses. Ce catalogue est largement utilisé en production en raison de son intégration avec l’infrastructure existante basée sur Hive et de sa compatibilité avec plusieurs moteurs de requêtes.
Exemple de configuration
Pour utiliser le catalogue Hive dans Spark :
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.my_catalog.type=hive \
--conf spark.sql.catalog.my_catalog.uri=thrift://<metastore-host>:<port>
Avantages :
- Haute compatibilité avec les outils de données volumineuses existants.
- Indépendant du cloud et flexible sur site et dans les configurations cloud.
Inconvénients :
- Nécessite de maintenir un Hive metastore, ce qui peut ajouter de la complexité opérationnelle.
- Ne prend pas en charge les transactions multi-tables, limitant l’atomicité pour les opérations entre tables
3. Catalogue AWS Glue
Le catalogue AWS Glue est un catalogue de métadonnées géré fourni par AWS, ce qui le rend idéal pour les organisations très investies dans l’écosystème AWS. Il gère les métadonnées des tables Iceberg en tant que propriétés de table dans AWS Glue, permettant une intégration transparente avec d’autres services AWS.
Exemple de configuration
Pour configurer AWS Glue avec Iceberg dans Spark :
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x,software.amazon.awssdk:bundle:x.xx.xxx \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog \
--conf spark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO \
--conf spark.hadoop.fs.s3a.access.key=$AWS_ACCESS_KEY \
--conf spark.hadoop.fs.s3a.secret.key=$AWS_SECRET_ACCESS_KEY
Avantages :
- Service géré, réduisant les coûts d’infrastructure et de maintenance.
- Intégration solide avec les services AWS.
Inconvénients :
- Spécifique à AWS, ce qui limite la flexibilité inter-cloud.
- Pas de prise en charge des transactions multi-tables
4. Catalogue Project Nessie
Le projet Nessie propose une approche « données en tant que code », permettant le contrôle de version des données. Avec ses capacités de branches et d’étiquetage similaires à Git, Nessie permet aux utilisateurs de gérer les branches de données de manière similaire au code source. Il fournit un cadre robuste pour les transactions multi-tables et multi-instructions.
Exemple de configuration
Pour configurer Nessie en tant que catalogue :
spark-sql --packages "org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x" \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.nessie.NessieCatalog \
--conf spark.sql.catalog.my_catalog.uri=http://<host>:<port>
Avantages :
- Fournit des fonctionnalités « données en tant que code » avec contrôle de version.
- Prend en charge les transactions multi-tables.
Inconvénients :
- Requiert l’auto-hébergement, ajoutant de la complexité à l’infrastructure.
- Prise en charge limitée par rapport à Hive ou AWS Glue
5. Catalogue JDBC
Le Catalogue JDBC vous permet de stocker les métadonnées dans n’importe quelle base de données compatible JDBC, comme PostgreSQL ou MySQL. Ce catalogue est indépendant du cloud et garantit une haute disponibilité en utilisant des systèmes SGBD fiables.
Exemple de configuration
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.jdbc.JdbcCatalog \
--conf spark.sql.catalog.my_catalog.uri=jdbc:<protocol>://<host>:<port>/<database> \
--conf spark.sql.catalog.my_catalog.jdbc.user=<username> \
--conf spark.sql.catalog.my_catalog.jdbc.password=<password>
Avantages :
- Facile à mettre en place avec une infrastructure SGBD existante.
- Haute disponibilité et indépendant du cloud.
Inconvénients :
- Pas de prise en charge des transactions multi-tables.
- Augmente les dépendances des pilotes JDBC pour tous les outils d’accès
6. Catalogue Snowflake
Snowflake offre un support robuste pour les tables Apache Iceberg, permettant aux utilisateurs de tirer parti de la plateforme de Snowflake en tant que catalogue Iceberg. Cette intégration combine les performances de Snowflake et la sémantique des requêtes avec la flexibilité du format de table ouverte d’Iceberg, permettant une gestion efficace de grands ensembles de données stockés dans un stockage cloud externe. Consultez la documentation de Snowflake pour plus de configuration à l’lien
Avantages:
- Intégration Transparente: Combine les performances et les capacités de requête de Snowflake avec le format de table ouverte d’Iceberg, facilitant la gestion efficace des données.
- Support Complet de la Plateforme: Fournit un accès complet en lecture et en écriture, ainsi que des fonctionnalités telles que les transactions ACID, l’évolution de schéma et le voyage dans le temps.
- Maintenance Simplifiée: Snowflake gère les tâches du cycle de vie telles que la compaction et la réduction de la charge opérationnelle.
Inconvénients:
- Contraintes de Cloud et de Région: Le volume externe doit être dans le même fournisseur cloud et la même région que le compte Snowflake, limitant les configurations inter-cloud ou inter-régions.
- Limitation du Format de Données: Prend en charge uniquement le format de fichier Apache Parquet, qui peut ne pas correspondre à toutes les préférences de format de données organisationnelles.
- Restrictions des clients tiers : Empêche les clients tiers de modifier les données dans les tables Iceberg gérées par Snowflake, ce qui peut avoir un impact sur les flux de travail qui dépendent d’outils externes.
7. Catalogues basés sur REST
Iceberg prend en charge les catalogues basés sur REST pour répondre à plusieurs défis associés aux mises en œuvre traditionnelles de catalogues.
Défis des catalogues traditionnels
- Complexité côté client : Les catalogues traditionnels nécessitent souvent des configurations côté client et des dépendances pour chaque langage (Java, Python, Rust, Go), entraînant des incohérences entre les différents langages de programmation et moteurs de traitement. En savoir plus à ce sujet ici.
- Contraintes de scalabilité : La gestion des métadonnées et des opérations sur les tables au niveau du client peut introduire des goulets d’étranglement, affectant les performances et la scalabilité dans des environnements de données à grande échelle.
Avantages de l’adoption du catalogue REST
- Intégration simplifiée des clients : Les clients peuvent interagir avec le catalogue REST en utilisant des protocoles HTTP standard, éliminant ainsi la nécessité de configurations ou de dépendances complexes.
- Scalabilité : L’architecture côté serveur du catalogue REST permet une gestion des métadonnées évolutive, s’adaptant à des ensembles de données croissants et à des modèles d’accès simultanés.
- Flexibilité : Les organisations peuvent mettre en œuvre une logique de catalogue personnalisée côté serveur, adaptant le catalogue REST pour répondre à des exigences spécifiques sans modifier les applications clientes.
Plusieurs implémentations du catalogue REST ont émergé, chacune répondant à des besoins organisationnels spécifiques :
- Gravitino : Un service de catalogue REST Iceberg open-source qui facilite l’intégration avec Spark et d’autres moteurs de traitement, offrant une configuration simple pour gérer les tables Iceberg.
- Tabular : Un service géré fournissant une interface de catalogue REST, permettant aux organisations de tirer parti des capacités d’Iceberg sans la surcharge de gestion de l’infrastructure du catalogue. En savoir plus sur Tabular.
- Apache Polaris : Un catalogue open-source et complet pour Apache Iceberg, implémentant l’API REST pour assurer une interopérabilité transparente entre plusieurs moteurs sur des plateformes comme Apache Doris, Apache Flink, Apache Spark, StarRocks et Trino. En savoir plus sur GitHub.
L’une de mes façons préférées et simples d’essayer le catalogue REST avec des tables Iceberg est d’utiliser une implémentation REST Java classique. Veuillez consulter le lien GitHub ici.
Conclusion
Le choix du catalogue Apache Iceberg approprié est crucial pour optimiser votre stratégie de gestion des données. Voici un aperçu concis pour vous guider dans votre décision :
- Catalogue Hadoop : Idéal pour les environnements de développement et de test en raison de sa simplicité. Cependant, des problèmes de cohérence peuvent survenir dans des scénarios de production avec des écritures concurrentes.
- Catalogue Hive Metastore : Idéal pour les organisations disposant d’une infrastructure Hive existante. Il offre une compatibilité avec un large éventail d’outils de big data et prend en charge des opérations de données complexes. Cependant, la maintenance d’un service Hive Metastore peut ajouter de la complexité opérationnelle.
- Catalogue AWS Glue : Optimal pour ceux qui ont fortement investi dans l’écosystème AWS. Il offre une intégration transparente avec les services AWS et réduit le besoin de services de métadonnées auto-gérés. Cependant, il est spécifique à AWS, ce qui peut limiter la flexibilité multi-cloud.
- Catalogue JDBC : Adapté aux environnements préférant les bases de données relationnelles pour le stockage des métadonnées, permettant l’utilisation de n’importe quelle base de données compatible JDBC. Cela offre de la flexibilité et tire parti de l’infrastructure RDBMS existante, mais peut introduire des dépendances supplémentaires et nécessiter une gestion soigneuse des connexions de base de données.
- Catalogue REST : Idéal pour les scénarios nécessitant une API normalisée pour les opérations de catalogue, améliorant l’interopérabilité entre divers moteurs de traitement et langages. Il découple les détails de mise en œuvre du catalogue des clients, mais nécessite la mise en place d’un service REST pour gérer les opérations de catalogue, ce qui peut ajouter de la complexité lors de la configuration initiale.
- Catalogue du Projet Nessie : Cela est parfait pour les organisations ayant besoin de contrôle de version sur leurs données, similaire à Git. Il prend en charge le branching, le tagging et les transactions multi-tables. Il offre des capacités de gestion des données robustes, mais nécessite le déploiement et la gestion du service Nessie, ce qui peut ajouter une surcharge opérationnelle.
Comprendre ces options de catalogue et leurs configurations vous permettra de faire des choix éclairés et d’optimiser votre lac de données ou votre configuration de lakehouse pour répondre aux besoins spécifiques de votre organisation.
Source:
https://dzone.com/articles/iceberg-catalogs-a-guide-for-data-engineers