Aller au contenu principal
Dernière mise à jour le

Qu'est-ce qu'Apache Iceberg dans Databricks ?

Apache Iceberg est un format de table open source pour les charges de travail d'analytique qui prend en charge des fonctionnalités telles que l'évolution des schémas, le time travel et le partitionnement masqué. Comme Delta Lake, Iceberg crée une couche d'abstraction qui permet les Transactions ACID sur vos données dans le stockage d'objets.

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 assure l'atomicité et la cohérence en écrivant de nouveaux fichiers de métadonnées pour chaque modification de table. Toutes les tables Iceberg dans Databricks suivent la spécification de format de table Iceberg ouverte. Consultez la spécification de table Iceberg.

Un catalogue Iceberg est la couche de niveau supérieur de l'architecture de table Iceberg qui renvoie 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 de tables.

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

Exigences​

Pour utiliser les tables gérées ou externes Apache Iceberg, vous devez satisfaire aux exigences suivantes :

  • Utilisez un Workspace avec Unity Catalog activé.
  • Utilisez Databricks Runtime 16.4 LTS ou une version ultérieure.

Créer des tables Iceberg dans Unity Catalog​

Les tables Iceberg que vous créez dans Unity Catalog sont des tables Iceberg gérées. Vous pouvez créer ces tables en utilisant :

Les tables Iceberg gérées sont entièrement intégrées aux fonctionnalités de la plateforme Databricks :

  • Unity Catalog gère les tâches de cycle de vie comme l'expiration des instantanés et le compactage des fichiers sur ces tables.
  • Le clustering liquide améliore les performances des query.
  • L'optimisation prédictive automatise les opérations pour réduire les coûts de stockage et améliorer la vitesse des query.
  • Les vues matérialisées prennent en charge le refresh incrémentiel pour maintenir les résultats à jour à mesure que les données sources changent.
  • Les tables de streaming 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 la version 1.9.2 et supérieure du client Iceberg pour lire et écrire dans Unity Catalog.

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

Une table Iceberg externe est une table Iceberg gérée par un catalogue en dehors de Unity Catalog. Le catalogue externe stocke les métadonnées actuelles de la table. Databricks utilise la 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 Databricks et ont une prise en charge limitée de la plateforme.

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

Vous pouvez accéder à toutes les tables Iceberg dans Unity Catalog en utilisant l'API de catalogue REST Iceberg. Cette API ouverte prend en charge les opérations de lecture et d’écriture à partir de moteurs Iceberg externes, dans différentes langues et plateformes. Voir Accéder aux tables Databricks à partir de clients Apache Iceberg.

Le catalogue REST prend en charge la délivrance d'informations d'identification, qui fournit des informations d'identification temporaires aux moteurs externes pour accéder au stockage sous-jacent. Pour plus d'informations, consultez la distribution d'identifiants Unity Catalog pour l'accès aux systèmes externes.

attention

La distribution d'informations d'identification n'est pas prise en charge sur les Workspaces qui utilisent le stockage par default. Consulter Limitations.

Cloner les tables Iceberg géré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 vers une nouvelle table Iceberg gérée dans Unity Catalog. Consultez Cloner une table Iceberg gérée.

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

info

Aperçu

Les vues matérialisées Iceberg gérées sont en Aperçu public. 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 la syntaxe complète, voir CREATE MATERIALIZED VIEW (pipelines). Pour connaître toutes les exigences, consultez Activer l'accès aux données externes aux tables de streaming et aux vues matérialisées.

SQL
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.

SQL
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 à partir d'un lecteur Iceberg externe, consultez Activer l'accès aux données externes aux tables de streaming et aux vues matérialisées.

Évolution des partitions​

Avec l'évolution du partitionnement, vous pouvez modifier le schéma de partitionnement d'une table Apache Iceberg existante sans réécrire les données. Les nouvelles données sont écrites avec le Layout de partition mis à jour et les données existantes conservent leur Layout de partition d'origine. Apache Iceberg suit les spécifications de partition et applique le filtre correct au moment de la query. Voir l'évolution des partitions pour Apache Iceberg.

remarque

L'évolution des partitions est prise en charge sur les tables Iceberg gérées par le biais de moteurs Iceberg externes utilisant le catalogue Iceberg REST, mais pas par 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. Voir les Limitations.

Pour configurer l'accès externe, voir Accéder aux tables Databricks depuis les clients Apache Iceberg.

Les exemples suivants montrent comment utiliser l'évolution des partitions avec Spark SQL et l'extension Iceberg. Pour la syntaxe d'évolution des partitions 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 :

SQL
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 :

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

Remplacer un champ de partition​

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

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

Limitations​

Les limitations suivantes s’appliquent aux tables Iceberg dans Databricks et sont sujettes à modification :

  • Les tables Iceberg prennent en charge uniquement le format de fichier Apache Parquet.

  • Pour Iceberg v2, les suppressions de position et les suppressions basées sur l'égalité ne sont pas prises en charge. Au lieu de cela, Databricks prend en charge les vecteurs de suppression Iceberg v3 pour les suppressions au niveau des lignes.

  • Le branching et le tagging ne sont pas pris en charge. Seule la branch principale est accessible lors de la lecture de tables Iceberg externes.

  • Partitionnement :

    • L'évolution des partitions n'est prise en charge sur les tables Iceberg gérées que lors de l'interaction à partir de moteurs Iceberg externes.
    • Les tables Iceberg externes 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 depuis les moteurs Iceberg externes.

  • Les types de données suivants ne sont pas pris en charge :

    • UUID
    • Fixed(L)
    • TIME
    • STRUCT imbriqué avec des champs obligatoires

  • Pour les limitations spécifiques à Iceberg v3, consultez Limitations.

Limitations des tables Iceberg gérées​

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

Limitations de la table Iceberg étrangère​

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

  • Le Time Travel est pris en charge uniquement pour les snapshots Iceberg qui ont été précédemment lus dans Databricks (c'est-à-dire, les snapshots où une instruction SELECT a été exécutée).
  • L'utilisation des 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 du 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 Databricks permet de restaurer les données archivées dans des niveaux de stockage moins coûteux.
  • Sur les clusters en mode d'accès dédié, les lectures et les REFRESH FOREIGN TABLE opérations sur les tables Iceberg nécessitent ALL PRIVILEGES.
Sur cette page