Lire des tables Delta Lake avec des clients Iceberg à l’aide d’UniForm

Disponible dans Databricks Runtime 14.3 LTS et versions ultérieures, les lectures Iceberg vous permettent de configurer des tables Delta Lake pour générer automatiquement des métadonnées Iceberg, ce qui permet aux clients Iceberg de lire les données Delta Lake sans réécrire des fichiers.

Vous pouvez configurer une connexion externe pour qu’Unity Catalog fasse office de catalogue Iceberg. Consultez Accéder aux tables Azure Databricks des clients Apache Iceberg.

Fonctionnement des lectures dans Iceberg

Delta Lake et Apache Iceberg se composent de fichiers de données Parquet et d’une couche de métadonnées. L’activation des lectures Iceberg configure vos tables Delta Lake pour générer automatiquement des métadonnées Iceberg de manière asynchrone, sans réécrire des données, ce qui permet aux clients Iceberg de les lire. Une seule copie des fichiers de données prend en charge plusieurs formats.

Lorsque vous utilisez des lectures Iceberg, tenez compte des éléments suivants :

  • Les tables Delta Lake avec les lectures Iceberg activées utilisent Zstandard au lieu de Snappy comme codec de compression pour les fichiers de données Parquet sous-jacents.
  • La génération de métadonnées iceberg s’exécute de manière asynchrone sur le calcul utilisé pour écrire des données dans des tables Delta Lake, ce qui peut augmenter l’utilisation des ressources du pilote.

Pour obtenir de la documentation sur la fonctionnalité de table UniForm héritée, consultez Legacy UniForm IcebergCompatV1IcebergCompatV1.

Spécifications

Pour activer les lectures Iceberg, les exigences suivantes doivent être remplies :

Remarque

Vous ne pouvez pas activer les vecteurs de suppression sur une table avec les lectures Iceberg activées.

Utilisez REORG pour désactiver et purger les vecteurs de suppression tout en activant la lecture Iceberg sur une table existante avec les vecteurs de suppression activés. Consultez Activer ou mettre à niveau la prise en charge de la lecture d’Iceberg à l'aide de REORG.

Activer la lecture Iceberg (UniForm)

Remarque

L’activation de la lecture d’Iceberg ajoute la fonctionnalité du protocole d’écriture IcebergCompatV2 et met à niveau le protocole d’écriture. Seuls les clients qui prennent en charge cette fonctionnalité de table peuvent écrire dans la table. Cela peut affecter la compatibilité avec les clients Delta Lake externes. Consultez les protocoles et la compatibilité des fonctionnalités Delta Lake.

Lorsque vous activez d’abord les lectures Iceberg, la génération de métadonnées asynchrones commence. Cette tâche doit se terminer avant que les clients externes puissent interroger la table à l’aide d’Iceberg. Consultez Vérifier les états de génération de métadonnées Iceberg.

Pour obtenir la liste des limitations, consultez Limitations.

Lors de la création d’un tableau

Le mappage de colonnes est activé automatiquement lorsque vous activez les lectures Iceberg lors de la création de la table :

CREATE TABLE T(c1 INT) TBLPROPERTIES(
  'delta.columnMapping.mode' = 'id',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg');

Databricks vous recommande de définir delta.columnMapping.mode = id à des fins de compatibilité. Voir Renommer et supprimer des colonnes avec le mappage de colonnes Delta Lake.

Sur une table existante

Pour activer les lectures Iceberg sur une table existante sur Databricks Runtime 15.4 LTS et versions ultérieures :

ALTER TABLE table_name SET TBLPROPERTIES(
  'delta.columnMapping.mode' = 'name',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg');

Pour plus d’informations sur le name mode de mappage de colonne, consultez les modes de mappage de colonnes.

Activer ou mettre à niveau la prise en charge de la lecture d’Iceberg à l'aide de REORG

Permet REORG d’activer les lectures Iceberg si l’une des valeurs suivantes est vraie :

  • Vous avez activé les vecteurs de suppression sur votre table.
  • Vous avez précédemment activé la version IcebergCompatV1 d’UniForm Iceberg.
  • Vous devez lire depuis des moteurs Iceberg qui ne prennent pas en charge les fichiers Parquet de style Hive, tels que ceux d'AWS Athéna ou Redshift.

Pour activer la lecture d’Iceberg et réécrire les fichiers de données sous-jacents, utilisez REORG comme dans l’exemple suivant :

REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));

Vérifiez que la lecture Iceberg est activée

Utilisez DESCRIBE EXTENDED pour vérifier que les lectures Iceberg (UniForm) sont activées pour votre table :

DESCRIBE EXTENDED catalog_name.schema_name.table_name;

Recherchez la section Delta Uniform Iceberg dans la sortie. Si cette section est présente, les opérations de lecture Iceberg sont activées sur votre table de données.

Vous pouvez également utiliser SHOW TBLPROPERTIES :

SHOW TBLPROPERTIES catalog_name.schema_name.table_name;

Vérifiez les propriétés suivantes :

  • delta.enableIcebergCompatV2 = true
  • delta.universalFormat.enabledFormats = iceberg

Si les deux propriétés sont présentes avec ces valeurs, les lectures Iceberg sont activées.

Désactiver la lecture Iceberg

Vous pouvez désactiver les lectures Iceberg en désactivant la delta.universalFormat.enabledFormats propriété de table :

ALTER TABLE table_name UNSET TBLPROPERTIES ('delta.universalFormat.enabledFormats');

Les mises à niveau des versions des protocoles de lecture et d’écriture de Delta Lake ne peuvent pas être annulées. Consultez les protocoles et la compatibilité des fonctionnalités Delta Lake.

Génération de métadonnées Iceberg

Azure Databricks déclenche la génération de métadonnées de manière asynchrone après la fin d’une transaction d’écriture Delta Lake. Ce processus de génération de métadonnées utilise le même calcul que celui qui a terminé la transaction Delta Lake.

Vous pouvez également déclencher manuellement la génération de métadonnées Iceberg. Consultez Déclencher manuellement la conversion de métadonnées Iceberg.

Pour éviter les latences d’écriture associées à la génération de métadonnées, les tables Delta Lake avec des validations fréquentes peuvent regrouper plusieurs validations Delta Lake en une seule validation dans les métadonnées Iceberg.

Delta Lake garantit qu’un seul processus de génération de métadonnées est en cours sur une ressource de calcul donnée. Les validations qui déclenchent un deuxième processus de génération de métadonnées simultanées sont correctement validées sur Delta Lake, mais ne déclenchent pas de génération asynchrone de métadonnées Iceberg. Cela évite la latence en cascade pour la génération de métadonnées pour les charges de travail avec des validations fréquentes (de secondes à minutes entre les validations).

Consultez Versions de la table Delta et Iceberg.

Versions de la table Delta et Iceberg

Delta Lake et Iceberg autorisent les requêtes de voyage dans le temps à l’aide de versions de table ou d’horodatages stockés dans les métadonnées de table.

Les versions de table Delta Lake ne correspondent pas nécessairement aux versions d’Iceberg, ni selon l’horodatage du commit ni selon l’ID de version. Pour vérifier la version d’une table Delta Lake à laquelle correspond une version donnée d’une table Iceberg, utilisez les propriétés de table correspondantes. Consultez Vérifier les états de génération de métadonnées Iceberg.

Vérifier les états de génération de métadonnées Iceberg

L’activation des lectures Iceberg sur une table ajoute les champs suivants aux métadonnées du catalogue Unity et de la table Iceberg pour suivre l’état de génération des métadonnées :

Champ métadonnées Descriptif
converted_delta_version La dernière version de la table Delta Lake pour laquelle les métadonnées Iceberg ont été générées avec succès.
converted_delta_timestamp Horodatage du dernier commit Delta Lake pour lequel les métadonnées Iceberg ont été générées avec succès.

Sur Azure Databricks, vous pouvez passer en revue ces champs de métadonnées en effectuant l’un des éléments suivants :

  • Passer en revue la section Delta Uniform Iceberg retournée par DESCRIBE EXTENDED table_name.
  • Passer en revue les métadonnées de table avec l’Explorateur de catalogues.

Consultez la documentation de votre client de lecteur Iceberg pour savoir comment passer en revue les propriétés de table en dehors d’Azure Databricks. Pour OSS Apache Spark, vous pouvez voir ces propriétés à l’aide de la syntaxe suivante :

SHOW TBLPROPERTIES <table-name>;

Déclencher manuellement la conversion de métadonnées Iceberg

Vous pouvez déclencher manuellement la génération de métadonnées Iceberg pour la dernière version de la table Delta Lake. Cette opération s’exécute de manière synchrone. Une fois l’opération terminée, le contenu de la table disponible dans Iceberg reflète la dernière version de la table Delta Lake disponible au démarrage du processus de conversion.

Cette opération n’est pas nécessaire dans des conditions normales. À utiliser pour récupérer de la situation suivante :

  • Un cluster se termine avant que la génération automatique de métadonnées ne réussisse.
  • Une erreur ou un échec de travail interrompt la génération de métadonnées.
  • Un client qui ne prend pas en charge la génération de métadonnées UniForm Iceberg écrit dans la table Delta Lake.

Utilisez la syntaxe suivante pour déclencher manuellement la génération de métadonnées Iceberg :

MSCK REPAIR TABLE <table-name> SYNC METADATA

Voir REPAIR TABLE.

Lire Iceberg en utilisant un chemin de métadonnées JSON

Certains clients Iceberg, tels que BigQuery, nécessitent que vous fournissiez un chemin d’accès aux fichiers de métadonnées avec version pour inscrire des tables Iceberg externes. Chaque fois que Azure Databricks convertit une nouvelle version de la table Delta Lake en Iceberg, elle crée un fichier JSON de métadonnées.

Pour plus d’informations sur la configuration, reportez-vous à la documentation de votre client de lecteur Iceberg spécifique.

Delta Lake stocke les métadonnées Iceberg sous le répertoire de table à l’aide du modèle suivant :

<table-path>/metadata/<version-number>-<uuid>.metadata.json

Sur Azure Databricks, vous pouvez passer en revue cet emplacement de métadonnées en effectuant l’une des opérations suivantes :

  • Passer en revue la section Delta Uniform Iceberg retournée par DESCRIBE EXTENDED table_name.
  • Passer en revue les métadonnées de table avec l’Explorateur de catalogues.

Importante

Les clients de lecteur Iceberg basés sur un chemin d’accès peuvent nécessiter la mise à jour et l’actualisation manuelles des chemins JSON des métadonnées pour lire les versions de table actuelles. Les utilisateurs peuvent rencontrer des erreurs lors de l’interrogation de tables Iceberg à l’aide de versions obsolètes, car les fichiers de données Parquet sont supprimés de la table Delta Lake avec VACUUM.

VACUUM et nettoyage des métadonnées d’Iceberg

À compter de Databricks Runtime 17.2, la VACUUM commande supprime les fichiers non suivis sous le répertoire UniForm metadata/ tout en préservant les métadonnées Iceberg qui sont toujours accessibles.

La conversion UniForm gère en interne l’expiration des instantanés Iceberg, mais utilise cleanExpiredFiles(false) par défaut. Par conséquent, OPTIMIZE et la conversion UniForm classique rendent uniquement les anciennes métadonnées Iceberg inaccessibles ; elles ne les suppriment pas physiquement.

Pour supprimer physiquement les métadonnées iceberg inaccessibles, exécutez FULL VACUUM une fois la delta.deletedFileRetentionDuration période de rétention écoulée. Voir Configurer la conservation des données pour des requêtes de voyage dans le temps.

Si l’optimisation prédictive est activée, Databricks gère automatiquement ce nettoyage. Vous n’avez donc pas besoin d’exécuter manuellement FULL VACUUM le nettoyage des métadonnées Iceberg.

Limites

Les limitations suivantes existent pour toutes les tables avec les lectures Iceberg activées :

  • La prise en charge du client Iceberg est en lecture seule. Les opérations d'écriture ne sont pas prises en charge.
    • Les lecteurs Iceberg peuvent avoir des limitations individuelles, même si Azure Databricks prend en charge la lecture des Iceberg. Consultez la documentation de votre client choisi.
  • Les vecteurs de suppression ne sont pas pris en charge pour les lectures Iceberg v2. Toutefois, Apache Iceberg v3 prend en charge les vecteurs de suppression. Consultez Utiliser les fonctionnalités Apache Iceberg v3 et les vecteurs de suppression dans Databricks.
  • La lecture Iceberg ne peut pas être activée pour des vues matérialisées ou des tables de streaming en utilisant IcebergCompatV2. Pour les vues matérialisées et les tables de streaming gérées par un pipeline, vous pouvez activer l’accès externe à Iceberg à l’aide de IcebergCompatV3 à la place. Cette fonctionnalité est disponible en préversion publique. Consultez Activer l’accès à des données externes pour les tables en continu et les vues matérialisées.
  • La table Delta Lake doit être accessible par nom (et non par chemin) pour déclencher automatiquement la génération de métadonnées Iceberg.
  • Les tables Delta Lake pour lesquelles la lecture Iceberg est activée ne prennent pas en charge les types VOID.
  • Certaines fonctionnalités de table Delta Lake utilisées par les lectures Iceberg ne sont pas prises en charge par certains clients de lecteur OpenSharing. Voir Qu’est-ce qu’OpenSharing ?.
  • Les destinataires d’OpenSharing peuvent lire les tables Delta Lake avec les lectures Iceberg activées en tant que tables Iceberg à l’aide de l’API du catalogue REST Iceberg. Cette fonctionnalité est disponible en préversion publique. Consultez Activer le partage avec des clients Iceberg externes.
  • L’ancien flux de données de modification fonctionne pour les clients Delta lorsque la lecture Iceberg est activée, mais n’est pas pris en charge dans Iceberg. Consultez Flux de données de modification hérité pour Delta Lake.
  • Last updated on