Qu’est-ce qu’Apache Iceberg dans Azure Databricks ?

Apache Iceberg est un format de table open source pour les charges de travail d’analyse qui prennent en charge des fonctionnalités telles que l’évolution du schéma, le voyage dans le temps et le partitionnement masqué. Comme Delta Lake, Iceberg crée une couche d’abstraction qui autorise les transactions ACID sur vos données dans le stockage d’objets.

Azure Databricks prend en charge les tables Iceberg qui utilisent le format de fichier Apache Parquet et les versions 1, 2 et 3 de la spécification Iceberg. Iceberg maintient l’atomicité et la cohérence en écrivant de nouveaux fichiers de métadonnées pour chaque modification de table. Toutes les tables Iceberg de Azure Databricks suivent la spécification ouverte du format de table Iceberg. Consultez la spécification de la table Iceberg.

Un catalogue Iceberg est la couche de niveau supérieur de l’architecture de table Iceberg qui retourne les métadonnées actuelles lors du chargement d’une table. Le catalogue Iceberg gère les opérations telles que la création, la suppression et le renommage des tables.

Azure Databricks prend en charge les tables Iceberg gérées par :

Spécifications

Pour utiliser des tables managées ou étrangères Apache Iceberg, vous devez répondre aux exigences suivantes :

  • Utilisez un espace de travail avec Unity Catalog activé.
  • Utilisez Databricks Runtime 16.4 LTS ou version ultérieure.

Pour les tables managées, vous devez également répondre aux exigences suivantes :

  • Un espace de travail avec le calcul sans serveur activé

Azure Databricks utilise le calcul serverless pour gérer les métadonnées de table Iceberg pour les tables managées. Le calcul sans serveur doit avoir une connectivité réseau avec le compte de stockage cloud qui héberge la table. Si un pare-feu protège le compte de stockage, configurez la connectivité réseau serverless afin que les ressources de calcul serverless puissent y accéder. La configuration requise dépend de votre cloud. Pour plus d’informations, consultez Mise en réseau du plan de calcul sans serveur.

Créer des tables Iceberg dans le catalogue Unity

Les tables iceberg que vous créez dans le catalogue Unity sont des tables Iceberg gérées. Vous pouvez créer ces tables à l’aide des éléments suivants :

Les tables Iceberg managées sont entièrement intégrées aux fonctionnalités de plateforme Azure Databricks :

  • Unity Catalog gère les tâches de cycle de vie telles que l’expiration des instantanés et le compactage de fichiers sur ces tables.
  • Le clustering liquide améliore les performances des requêtes.
  • L’optimisation prédictive automatise les opérations pour réduire les coûts de stockage et améliorer la vitesse des requêtes.
  • Les vues matérialisées prennent en charge l’actualisation incrémentielle pour maintenir les résultats à jour lorsque les données sources changent.
  • Les tables de diffusion en continu prennent en charge le chargement incrémentiel des données à partir de Kafka et du stockage d’objets cloud à l’aide de Databricks SQL.

Databricks recommande d’utiliser le client Iceberg version 1.9.2 et ultérieure pour lire et écrire dans le catalogue Unity.

Lire les tables Iceberg gérées par d’autres catalogues

Une table iceberg étrangère est une table Iceberg gérée par un catalogue en dehors de l'Unity Catalog. Le catalogue externe stocke les métadonnées actuelles de la table. Azure Databricks utilise Lakehouse Federation pour récupérer les métadonnées et lire la table à partir du stockage d’objets.

Les tables Iceberg externes sont en lecture seule dans Azure Databricks et bénéficient d'un support limité de la plateforme.

Accéder aux tables Iceberg à l’aide de systèmes externes

Vous pouvez accéder à toutes les tables Iceberg dans le catalogue Unity à l’aide de l’API du catalogue REST Iceberg. Cette API ouverte prend en charge les opérations de lecture et d’écriture à partir de moteurs Iceberg externes sur différents langages et plateformes. Consultez Accéder aux tables Azure Databricks depuis les clients Apache Iceberg.

Le catalogue REST prend en charge la distribution d'informations d'identification, ce qui délivre des informations d'identification temporaires aux moteurs externes pour accéder au stockage sous-jacent. Pour en savoir plus, veuillez consulter la section Distribution d'informations d'identification Unity Catalog pour l'accès aux systèmes externes.

Avertissement

La vente d’informations d’identification n’est pas prise en charge sur les espaces de travail qui utilisent le stockage par défaut. Consultez Limitations.

Cloner des tables Iceberg managées

Vous pouvez créer une copie complète et indépendante d’une table Iceberg gérée à l’aide de DEEP CLONE. Un clone profond copie les fichiers de données et les métadonnées de la table dans une nouvelle table Iceberg managée dans le catalogue Unity. Consultez Cloner une table Iceberg managée.

Créer une vue matérialisée compatible avec les lecteurs Iceberg externes

Importante

Les vues matérialisées Iceberg managées sont disponibles en version préliminaire publique. Pour activer cette fonctionnalité, contactez votre équipe de compte Databricks.

Vous pouvez créer une vue matérialisée compatible avec les lecteurs Iceberg externes. Pour en créer un, utilisez USING ICEBERG dans l’instruction CREATE MATERIALIZED VIEW. Pour obtenir la syntaxe complète, consultez CREATE MATERIALIZED VIEW (pipelines). Pour connaître l’ensemble des exigences, consultez Activer l’accès aux données externes pour les tables en continu et les vues matérialisées.

CREATE MATERIALIZED VIEW <mv_name>
USING ICEBERG
AS
SELECT * FROM samples.nyctaxi.trips;

Après avoir créé la vue matérialisée, exécutez REPAIR TABLE avec SYNC METADATA. Voir REPAIR TABLE.

REPAIR TABLE <mv_name> SYNC METADATA;

Les lecteurs Iceberg externes peuvent lire la vue matérialisée, mais ne peuvent pas y écrire. Pour lire la vue matérialisée depuis un lecteur Iceberg externe, consultez Activer l’accès aux données externes pour les tables de streaming et les vues matérialisées.

Évolution des partitions

Avec l’évolution de la partition, vous pouvez modifier le schéma de partitionnement d’une table Apache Iceberg existante sans réécrire des données. Les nouvelles données sont écrites avec la disposition de partition mise à jour et les données existantes conservent sa disposition de partition d’origine. Apache Iceberg effectue le suivi des spécifications de partition et applique le filtre approprié au moment de la requête. Consultez l’évolution des partitions pour Apache Iceberg.

Note

L’évolution des partitions est prise en charge sur les tables Iceberg gérées via des moteurs Iceberg externes à l’aide du catalogue REST Iceberg, mais pas via Databricks SQL. Les transformations de partition basées sur des expressions telles que years() et bucket() ne sont pas prises en charge pour les tables Iceberg gérées. Consultez Limitations.

Pour configurer l’accès externe, consultez Access Azure Databricks tables à partir de clients Apache Iceberg.

Les exemples suivants montrent comment utiliser l’évolution de la partition avec Spark SQL et l’extension Iceberg. Pour connaître la syntaxe d’évolution de partition Apache Iceberg et les transformations prises en charge, consultez Apache Iceberg Spark DDL.

Ajouter un champ de partition

Pour ajouter un nouveau champ de partition à une table existante :

ALTER TABLE catalog.schema.table ADD PARTITION FIELD column_name;

Supprimer un champ de partition

Pour supprimer un champ de partition existant d’une table :

ALTER TABLE catalog.schema.table DROP PARTITION FIELD column_name;

Remplacer un champ de partition

Pour échanger un champ de partition pour un autre sans repartition intermédiaire :

ALTER TABLE catalog.schema.table REPLACE PARTITION FIELD old_column WITH new_column;

Limitations

Les limitations suivantes s’appliquent aux tables Iceberg dans Azure Databricks et sont susceptibles de changer :

  • Les tables Iceberg prennent uniquement en charge le format de fichier Apache Parquet.
  • Dans Iceberg v2, les suppressions par position et les suppressions basées sur l’égalité ne sont pas prises en charge. Au lieu de cela, Azure Databricks prend en charge les vecteurs de suppression Iceberg v3 pour les suppressions au niveau des lignes.
  • La création de branches et l’ajout de balises ne sont pas pris en charge. Seule la branche principale est accessible lors de la lecture des tables Iceberg étrangères.
  • Partitionnement:
    • L'évolution des partitions est prise en charge sur les tables Iceberg gérées uniquement en interaction avec des moteurs Iceberg externes.
    • Les tables Iceberg étrangères ne prennent pas en charge l’évolution des partitions.
    • Le partitionnement par type BINARY n’est pas pris en charge.
  • Les vues ne sont pas accessibles à partir de moteurs Iceberg externes.
  • Les types de données suivants ne sont pas pris en charge :
    • UUID
    • Fixed(L)
    • TIME
    • STRUCT imbriqué contenant des champs obligatoires
  • Pour connaître les limitations spécifiques à Iceberg v3, consultez Limitations.

Limitations de la table Iceberg managée

Les limitations suivantes s’appliquent spécifiquement aux tables Iceberg gérées :

  • Les tables Iceberg managées ne peuvent être créées que si l’optimisation prédictive est activée pour la maintenance des tables.
  • Les propriétés de tableau suivantes sont gérées par Unity Catalog et ne peuvent pas être définies manuellement :
    • write.location-provider.impl
    • write.data.path
    • write.metadata.path
    • write.format.default
    • write.delete.format.default
  • Le codec de compression pour modifier la compression de table n’est pas pris en charge. Toutes les tables utilisent Zstd par défaut.
  • Le partitionnement par expressions (par exemple, years(), , months()days(), hours(), bucket()) n’est pas pris en charge.
  • Les fonctionnalités non prises en charge dans Apache Iceberg ne sont pas également disponibles pour les tables Iceberg managées. Cela inclut les colonnes générées de Delta Lake, les contraintes sur Azure Databricks et la prise en charge du classement pour Delta Lake.

Limites des tables Iceberg étrangères

Les limitations suivantes s’appliquent spécifiquement aux tables Iceberg étrangères :

  • Les déplacements temporels sont pris en charge uniquement pour les instantanés Iceberg qui ont été lus précédemment dans Azure Databricks (autrement dit, les instantanés où une instruction SELECT a été exécutée).
  • L’utilisation de fonctions de transformation de compartiment pour le partitionnement Iceberg peut dégrader les performances des requêtes lorsque des filtres conditionnels sont utilisés.
  • Les produits de hiérarchisation de stockage cloud tels qu’Amazon S3 ne sont pas intégrés aux tables Iceberg étrangères. L’accès aux tables Iceberg étrangères dans Azure Databricks peut restaurer les données archivées dans des niveaux de stockage à moindre coût.
  • Sur les clusters en mode d’accès dédié, les lectures et les opérations REFRESH FOREIGN TABLE sur les tables Iceberg nécessitent ALL PRIVILEGES.
  • Last updated on