Utiliser le « liquid clustering » pour les tables

Le clustering liquide est une technique d’optimisation de la disposition des données qui remplace le partitionnement de table et ZORDER. Il simplifie la gestion des tables et optimise les performances des requêtes en organisant automatiquement les données en fonction des clés de clustering.

Contrairement au partitionnement traditionnel, vous pouvez redéfinir les clés de clustering sans réécrire les données existantes. Cela permet à votre disposition de données d’évoluer en même temps que les besoins analytiques changeants. Le clustering liquide s’applique aux tables de diffusion en continu et aux vues matérialisées.

Quand utiliser le clustering liquide

Databricks recommande un clustering liquide pour toutes les nouvelles tables, y compris les tables de flux continu et les vues matérialisées. Les scénarios suivants bénéficient en particulier du clustering :

• Requêtes qui filtrent sur des colonnes de cardinalité élevée.
• Tables avec une forte asymétrie des données.
• Tables à croissance rapide nécessitant des efforts de maintenance et de réglage.
• Tables avec des requêtes d’écriture simultanées.
• Tables avec des modèles d’accès variés ou changeants.
• Tables où une clé de partition classique peut retourner des résultats d'un trop grand nombre de partitions ou trop peu de partitions.

Activer le regroupement liquide

Vous pouvez activer le clustering liquide sur une table non partitionnée existante ou lors de la création d’une table. Le clustering n’est pas compatible avec le partitionnement ou ZORDER. Databricks recommande d’autoriser la plateforme à gérer toutes les opérations de disposition et d’optimisation pour les données de votre table. Après avoir activé le clustering liquide, exécutez OPTIMIZE des tâches pour regrouper les données de manière incrémentielle. Découvrez comment déclencher le clustering.

Créer des tables avec clustering

Pour activer le clustering liquide, ajoutez l’expression CLUSTER BY à une instruction de création de table, comme dans les exemples ci-dessous. Dans Databricks Runtime 14.3 LTS et versions ultérieures, vous pouvez utiliser les API DataFrame et l’API DeltaTable dans Python ou Scala pour activer le clustering liquide pour les tables Delta Lake.

SQL

Pour créer une table vide avec clustering :

CREATE TABLE table1 (col0 INT, col1 STRING) CLUSTER BY (col0);

Pour créer une table à partir de données existantes avec clustering, CLUSTER BY doit apparaître après le nom de la table, et non dans la SELECT clause :

CREATE TABLE table2 CLUSTER BY (col0)
AS SELECT * FROM table1;

Pour copier une structure de table, y compris sa configuration de clustering :

CREATE TABLE table3 LIKE table1;

Python

Pour créer une table vide avec clustering à l’aide de l’API DeltaTable :

(DeltaTable.create()
  .tableName("table1")
  .addColumn("col0", dataType = "INT")
  .addColumn("col1", dataType = "STRING")
  .clusterBy("col0")
  .execute())

Pour créer une table à partir d’un DataFrame existant :

df = spark.read.table("table1")
df.write.clusterBy("col0").saveAsTable("table2")

Pour créer une table à l’aide de l’API DataFrameWriterV2 (disponible dans Databricks Runtime 14.2 et versions ultérieures) :

df = spark.read.table("table1")
df.writeTo("table1").using("delta").clusterBy("col0").create()

Scala

Pour créer une table vide avec clustering à l’aide de l’API DeltaTable :

DeltaTable.create()
  .tableName("table1")
  .addColumn("col0", dataType = "INT")
  .addColumn("col1", dataType = "STRING")
  .clusterBy("col0")
  .execute()

Pour créer une table à partir d’un DataFrame existant :

val df = spark.read.table("table1")
df.write.clusterBy("col0").saveAsTable("table2")

Pour créer une table à l’aide de l’API DataFrameWriterV2 (disponible dans Databricks Runtime 14.2 et versions ultérieures) :

val df = spark.read.table("table1")
df.writeTo("table1").using("delta").clusterBy("col0").create()

Dans Databricks Runtime 16.4 LTS et les versions ultérieures, vous pouvez créer des tables pour lesquelles le clustering liquide est activé à l’aide d’écritures Structured Streaming, comme dans les exemples suivants :

SQL

CREATE TABLE table1 (
  col0 STRING,
  col1 DATE,
  col2 BIGINT
)
CLUSTER BY (col0, col1);

Python

(spark.readStream.table("source_table")
  .writeStream
  .clusterBy("column_name")
  .option("checkpointLocation", checkpointPath)
  .toTable("target_table")
)

Scala

spark.readStream.table("source_table")
  .writeStream
  .clusterBy("column_name")
  .option("checkpointLocation", checkpointPath)
  .toTable("target_table")

Activer sur les tables existantes

Pour activer le clustering liquide sur une table Delta Lake existante non partitionnée, procédez comme suit :

ALTER TABLE <table_name>
CLUSTER BY (<clustering_columns>)

Pour les tables Apache Iceberg gérées, tenez compte des éléments suivants :

• Pour les tables avec la spécification v2, vous devez désactiver explicitement les vecteurs de suppression et le suivi des lignes lors de l’activation du clustering liquide sur une table existante.
• Pour les tables avec la spécification v3, la désactivation de ces fonctionnalités n’est pas nécessaire, car les vecteurs de suppression et le suivi des lignes sont pris en charge. Consultez Utiliser les fonctionnalités Apache Iceberg v3.

Convertir une table partitionnée en clustering liquide

Dans Databricks Runtime 18.1 et versions ultérieures, pour convertir une table Delta Lake partitionnée existante en clustering liquide, utilisez REPLACE PARTITIONED BY WITH CLUSTER BY dans une instruction ALTER TABLE. La conversion réduit le temps d’arrêt du lecteur et de l’enregistreur et prend en charge les tables externes et gérées. Après la conversion, la table prend en charge les lectures avec Databricks Runtime 13.3 LTS et versions ultérieures.

Les avantages de la conversion des tables partitionnées en clustering liquide sont les suivants :

• Des améliorations de performance pour les tables souffrant d’une mauvaise optimisation des données ignorées ou d’un sur-partitionnement.
• Améliorations automatiques des performances, en utilisant CLUSTER BY AUTO, pour les tables avec des modèles de requête fréquemment modifiés.
• Les colonnes de clustering sont flexibles et simples à modifier, tandis que le partitionnement est rigide et difficile à modifier.
• Réduction des conflits d’écriture, car les tables avec clustering liquide autorisent la concurrence au niveau des lignes. Consultez la concurrence au niveau des lignes.

Syntax

ALTER TABLE <table_name>
REPLACE PARTITIONED BY WITH CLUSTER BY [( <clustering_columns> ) | AUTO]

La CLUSTER BY clause prend en charge les options suivantes :

• ( <clustering_columns> ): spécifie de nouvelles colonnes de clustering. Databricks recommande de conserver les nouvelles colonnes de clustering similaires aux colonnes de partition d’origine. L’utilisation de colonnes très différentes déclenche une opération de reclustrage importante lors de la première OPTIMIZE exécution.
• AUTO: utilise les colonnes de partition actuelles comme colonnes de clustering initiales et permet à l’optimisation prédictive de s’adapter au fil du temps. Disponible uniquement pour les tables gérées par le catalogue Unity. Consultez le regroupement automatique de liquide.
• Aucune option spécifiée : utilise les colonnes de partition actuelles comme nouvelles colonnes de clustering.

Pour obtenir des conseils sur le choix des clés de clustering lors de la migration à partir de tables partitionnés, consultez Migration à partir du partitionnement ou de l’ordre Z.

Examples

Pour cluster sur des colonnes différentes des partitions d’origine, comme pour une table partitionnée sur (year, month, day), procédez comme suit :

ALTER TABLE t1 REPLACE PARTITIONED BY WITH CLUSTER BY (day, id);
OPTIMIZE t1;

Pour utiliser le clustering liquide automatique et commencer par les colonnes de partition actuelles, procédez comme suit :

ALTER TABLE t2 REPLACE PARTITIONED BY WITH CLUSTER BY AUTO;

Pour conserver les colonnes de partition actuelles en tant que colonnes de clustering, procédez comme suit :

ALTER TABLE t3 REPLACE PARTITIONED BY WITH CLUSTER BY;

Gérer les lectures et écritures simultanées pendant la conversion

Après la conversion, Databricks Runtime 13.3 LTS et versions ultérieures sont prises en charge pour les opérations de lecture et d’écriture. Azure Databricks recommande Databricks Runtime 15.4 LTS et versions ultérieures pour les charges de travail qui lisent ou écrivent dans la table pendant la conversion.

Consultez le tableau suivant pour savoir comment gérer les charges de travail de lecture et d’écriture simultanées pendant la conversion :

Vérifier ou restaurer une conversion

Pour confirmer la conversion, exécutez DESCRIBE EXTENDED pour afficher les nouvelles colonnes de clustering. Exécutez DESCRIBE HISTORY pour afficher une série d’opérations REORG , une UPGRADE PROTOCOL opération et une REPLACE PARTITIONED BY WITH CLUSTER BY opération.

Pour restaurer une conversion, utilisez RESTORE cette option pour revenir à la version précédente. Vous pouvez également réécrire le tableau à l’aide de REPLACE TABLE ... PARTITIONED BY (...) AS SELECT * FROM ....

Pour revenir en arrière avec RESTORE, exécutez les commandes suivantes :

ALTER TABLE my_table CLUSTER BY NONE;
ALTER TABLE my_table UNSET TBLPROPERTIES ('delta.liquid.hierarchicalClusteringColumns');
RESTORE TABLE my_table TO VERSION AS OF <version_number_before_conversion>;

Voir RESTORE.

Convertir une table partitionnée par une colonne d’horodatage

Pour convertir une table (t1) partitionnée par une colonne d’horodatage (timestamp_col) et utiliser la colonne timestamp comme clé de clustering, vous devez définir des configurations supplémentaires :

SET spark.databricks.delta.liquidConversion.statsGeneration.enabled = false;
ALTER TABLE t1 REPLACE PARTITIONED BY WITH CLUSTER BY (timestamp_col, id);
ANALYZE TABLE t1 COMPUTE DELTA STATISTICS;

Si vous essayez de convertir une colonne de partition d’horodatage en colonne de clustering sans ces configurations, la commande génère une erreur :

ALTER TABLE REPLACE PARTITIONED BY WITH CLUSTER BY cannot auto-generate stats on table with column event_ts due to unsupported type: timestamp. Disable stats auto-generation by setting 'spark.databricks.delta.liquidConversion.statsGeneration.enabled' to 'false' and retry the command again. SQLSTATE: 42000

Limitations de conversion

Les limitations suivantes s’appliquent à la commande de REPLACE PARTITIONED BY WITH CLUSTER BY conversion :

• Les tables de streaming et les vues matérialisées créées dans les pipelines déclaratifs Spark de Lakeflow ne sont pas prises en charge. Pour utiliser le clustering liquide, vous devez mettre à jour la définition du pipeline pour utiliser CLUSTER BY au lieu de PARTITIONED BY.
• Les tables qui utilisent le partage Delta avec le filtrage de partition ne sont pas prises en charge. Pour plus d’informations sur le filtrage de partition pour le partage delta, consultez Spécifier les partitions de table à partager.

Supprimer les clés de regroupement

Pour supprimer des clés de clustering, utilisez la syntaxe suivante :

ALTER TABLE table_name CLUSTER BY NONE;

Choisir les clés de clustering

Choisissez des clés de clustering basées sur les colonnes les plus couramment utilisées dans les filtres de requête. Les bonnes clés améliorent considérablement l’évitement des données et les performances des requêtes.

Principales recommandations de sélection

Lorsque vous spécifiez manuellement des clés de clustering, choisissez des colonnes en fonction des colonnes les plus fréquemment utilisées dans les filtres de requête. Vous pouvez définir des clés de clustering dans n’importe quel ordre. Si deux colonnes sont fortement corrélées, vous devez uniquement inclure l’une d’entre elles comme clé de clustering.

Vous pouvez spécifier jusqu’à quatre clés de clustering. Pour les tables plus petites (moins de 10 To), l’utilisation de plusieurs clés de clustering peut dégrader les performances lors du filtrage sur une seule colonne. Par exemple, le filtrage avec quatre clés est pire que le filtrage avec deux clés. Toutefois, à mesure que la taille de la table augmente, cette différence de performances devient négligeable pour les requêtes à colonne unique.

Les clés de clustering doivent être des colonnes pour lesquelles des statistiques ont été collectées. Par défaut, les tables Delta Lake collectent des statistiques pour les 32 premières colonnes. Consultez Spécifier des colonnes de statistiques.

Types de données prises en charge

Le clustering prend en charge ces types de données pour les clés de clustering :

• Date
• Horodatage
• TimestampNTZ (Databricks Runtime 14.3 LTS et versions ultérieures)
• String
• Integer, Long, Short, Byte
• Float, Double, Decimal

Vous pouvez regrouper selon StructField en utilisant la notation par points, par exemple CLUSTER BY (struct_col.field). Les champs de structures imbriquées sont pris en charge à n’importe quelle profondeur, par exemple CLUSTER BY (struct_col.nested.field). Le type de données du champ doit être l’un des types pris en charge dans la liste précédente.

Vous ne pouvez pas mettre en cluster l’un des éléments suivants :

• Types complexes, tels que StructType, MapTypeou ArrayType
• MapType et ArrayType éléments, tels que map_col['key'], array_col[0]ou map_col.key.

Migration à partir du partitionnement ou de l’ordre Z

Si vous convertissez une table existante, tenez compte des recommandations suivantes :

Regroupement automatique de liquide

Dans Databricks Runtime 15.4 LTS et versions ultérieures, vous pouvez activer le clustering liquide automatique pour les tables Delta Lake gérées par le catalogue Unity. Pour les tables Apache Iceberg v3 gérées par Unity Catalog, le clustering liquide automatique nécessite Databricks Runtime 18.0 et versions supérieures. Le clustering liquide automatique permet Azure Databricks de choisir intelligemment des clés de clustering pour optimiser les performances des requêtes, à l’aide de la clause CLUSTER BY AUTO.

Fonctionnement du regroupement automatique de liquides

Le clustering liquide automatique nécessite une optimisation prédictive pour la sélection automatique des clés et les opérations de clustering, et s’exécute de manière asynchrone. Consultez Optimisation prédictive pour les tables managées Unity Catalog.

Le clustering liquide automatique applique des optimisations intelligentes en fonction de vos modèles d’utilisation :

• Analyse la charge de travail de requête : Azure Databricks analyse la charge de travail de requête historique de la table et identifie les meilleures colonnes candidates pour le clustering.
• S’adapte aux modifications : si vos modèles de requête ou distributions de données changent au fil du temps, le clustering liquide automatique sélectionne de nouvelles clés pour optimiser les performances.
• Sélection consciente des coûts : Azure Databricks modifie les clés de clustering uniquement lorsque les économies de coûts prévues grâce aux améliorations du saut de données l'emportent sur le coût du clustering des données.

Le regroupement liquide automatique peut ne pas sélectionner de clés pour les raisons suivantes :

• La table est trop petite pour bénéficier du « liquid clustering ».
• La table dispose déjà d’un schéma de clustering efficace, provenant de clés manuelles précédentes ou d’un ordre d’insertion naturel qui correspond aux modèles de requête.
• La table n’a pas de requêtes fréquentes.
• Vous n’utilisez pas Databricks Runtime 15.4 LTS ou version ultérieure.

Vous pouvez appliquer un clustering liquide automatique pour toutes les tables gérées par le catalogue Unity, quelles que soient les données et les caractéristiques de requête. Les heuristiques déterminent s’il est rentable de sélectionner des clés de clustering.

Compatibilité des versions de Databricks Runtime

Vous pouvez lire ou écrire des tables avec le clustering automatique activé à partir de toutes les versions de Databricks Runtime qui prennent en charge le clustering liquide. Toutefois, la sélection intelligente des clés repose sur les métadonnées introduites dans Databricks Runtime 15.4 LTS.

Utilisez Databricks Runtime 15.4 LTS ou version ultérieure pour vous assurer que les clés sélectionnées automatiquement bénéficient de toutes vos charges de travail et que ces charges de travail sont prises en compte lors de la sélection de nouvelles clés.

Activer ou désactiver le clustering liquide automatique

SQL

Pour créer une table avec clustering liquide automatique :

CREATE OR REPLACE TABLE table1 (column01 int, column02 string) CLUSTER BY AUTO;

Pour activer le clustering liquide automatique sur une table existante, y compris les tables dotées de clés spécifiées manuellement :

ALTER TABLE table1 CLUSTER BY AUTO;

Pour définir les indicateurs de colonne de clustering initiaux pour la sélection de clés, définissez les clés de clustering, puis activez le clustering automatique :

ALTER TABLE table1 CLUSTER BY (c1, c2);
ALTER TABLE table1 CLUSTER BY AUTO;

Vous pouvez également utiliser l’API Python pour définir des indicateurs dans une seule opération.

Pour désactiver le regroupement automatique des liquides :

ALTER TABLE table1 CLUSTER BY NONE;

Pour désactiver le clustering liquide automatique et spécifier des colonnes de clustering :

ALTER TABLE table1 CLUSTER BY (column01, column02);

Si une table existante dispose du clustering liquide automatique activé, l’exécution de CREATE OR REPLACE table_name sans CLUSTER BY AUTO désactive le clustering liquide automatique et ne préserve pas les colonnes de clustering. Pour conserver le clustering liquide automatique et toutes les colonnes précédemment sélectionnées, incluez CLUSTER BY AUTO dans l’instruction replace. Avec CLUSTER BY AUTO, l’optimisation prédictive utilise la charge de travail de requête historique de la table pour identifier les meilleures clés de clustering.

Python

L’API Python est disponible dans Databricks Runtime 16.4 et versions ultérieures. Vous ne pouvez utiliser Python que lors de la création ou du remplacement d’une table. Utilisez SQL pour modifier l’état clusterByAuto d’une table existante.

Pour créer une table avec clustering liquide automatique à l’aide de DataFrameWriter :

df = spark.read.table("table1")
df.write
  .format("delta")
  .option("clusterByAuto", "true")
  .saveAsTable(...)

Pour définir les indications initiales de colonne de clustering pour la sélection des clés à l’aide de DataFrameWriter :

df.write
  .format("delta")
  .clusterBy("clusteringColumn1", "clusteringColumn2")
  .option("clusterByAuto", "true")
  .saveAsTable(...)

Pour créer une table avec clustering liquide automatique à l’aide de DataFrameWriterV2 :

df.writeTo(...).using("delta")
  .option("clusterByAuto", "true")
  .create()

Pour définir les indications initiales de colonne de clustering pour la sélection des clés à l’aide de DataFrameWriterV2 :

df.writeTo(...).using("delta")
  .clusterBy("clusteringColumn1", "clusteringColumn2")
  .option("clusterByAuto", "true")
  .create()

Pour créer une table de streaming avec clustering liquide automatique :

spark.readStream.table("source_table")
  .writeStream
  .option("clusterByAuto", "true")
  .option("checkpointLocation", checkpointPath)
  .toTable("target_table")

Pour définir les indications initiales de colonnes de clustering pour la sélection des clés dans une table de streaming :

spark.readStream.table("source_table")
  .writeStream
  .clusterBy("column1", "column2")
  .option("clusterByAuto", "true")
  .option("checkpointLocation", checkpointPath)
  .toTable("target_table")

Lorsque vous utilisez .clusterBy pour les indicateurs de sélection de clé de cluster avec .option('clusterByAuto', 'true'), le comportement est le suivant :

• Si cette opération active le Liquid Clustering automatique pour la première fois, les colonnes de clustering sont définies comme celles spécifiées dans .clusterBy.
• S’il s’agit d’une table existante avec clustering liquide automatique activé, un .clusterBy indicateur n’est accepté qu’une seule fois. Par exemple, les colonnes spécifiées .clusterBy par sont définies uniquement si la table n’a pas de colonnes de clustering définies.

Vérifier si le clustering automatique est activé

Pour vérifier si une table a le clustering liquide automatique activé, utilisez DESCRIBE TABLE ou SHOW TBLPROPERTIES.

Si le clustering liquide automatique est activé, la clusterByAuto propriété est définie sur true. La clusteringColumns propriété affiche les colonnes de clustering actuelles qui ont été automatiquement ou sélectionnées manuellement.

Limitations

Le clustering liquide automatique n’est pas disponible pour les tables Apache Iceberg v2 gérées. Il est pris en charge pour les tables Apache Iceberg v3 gérées dans Databricks Runtime 18.0 et versions ultérieures.

Écrire des données dans une table en cluster

Pour écrire sur une table Delta Lake en cluster, vous devez utiliser un client d’écriture Delta qui prend en charge toutes les fonctionnalités de table de protocole d’écriture Delta utilisées par le clustering liquide. Pour écrire dans une table Iceberg en cluster, vous pouvez utiliser l’API catalogue REST iceberg de Unity Catalog. Sur Azure Databricks, vous devez utiliser Databricks Runtime 13.3 LTS et versions ultérieures.

Opérations qui prennent en charge le regroupement lors de l'écriture

Les opérations qui effectuent un clustering en écriture sont les suivantes :

• Opérations INSERT INTO
• Déclarations CTAS et RTAS
• COPY INTO à partir du format Parquet
• spark.write.mode("append")

Seuils de taille pour le clustering

Le clustering en écriture se déclenche uniquement lorsque les données de la transaction atteignent un seuil de taille. Ces seuils varient selon le nombre de colonnes de clustering et sont inférieurs pour les tables gérées par le catalogue Unity que les autres tables Delta Lake.

Étant donné que le clustering liquide n’est pas appliqué à toutes les opérations, Databricks vous recommande d’exécuter fréquemment OPTIMIZE pour vous assurer que toutes les données sont efficacement regroupées.

Charges de travail de diffusion en continu

Les charges de travail en flux structuré prennent en charge le clustering en écriture lorsque vous définissez la configuration Spark spark.databricks.delta.liquid.eagerClustering.streaming.enabled sur true. Le clustering pour ces charges de travail se déclenche uniquement si au moins l’une des cinq dernières mises à jour de diffusion en continu dépasse un seuil de taille à partir du tableau ci-dessus.

Comment déclencher le clustering

L’optimisation prédictive exécute automatiquement les commandes OPTIMIZE sur les tables activées. Consultez Optimisation prédictive pour les tables managées Unity Catalog. Lors de l’utilisation de l’optimisation prédictive, Databricks recommande de désactiver les travaux planifiés OPTIMIZE .

Pour déclencher le clustering, vous devez utiliser Databricks Runtime 13.3 LTS ou version ultérieure. Databricks recommande Databricks Runtime 17.3 LTS et versions ultérieures pour des performances plus rapides OPTIMIZE sur des tables volumineuses. Utilisez la OPTIMIZE commande sur votre table :

OPTIMIZE table_name;

Le clustering liquide est incrémentiel, ce qui signifie qu’il ne réécrit les données que si nécessaire pour adapter les données nécessitant un clustering. OPTIMIZE ne réécrit pas les fichiers de données dont les clés de clustering ne correspondent pas aux données faisant l’objet du clustering. Consultez Forcer le reclustering.

Si vous n’utilisez pas d’optimisation prédictive, Databricks recommande de planifier des travaux réguliers OPTIMIZE sur des données de cluster. Pour les tables présentant de nombreuses mises à jour ou insertions, Databricks recommande de planifier un travail OPTIMIZE toutes les unes ou deux heures. Étant donné que le groupement liquide est incrémentiel, la plupart des tâches OPTIMIZE pour les tables en cluster s'exécutent rapidement.

Forcer le reclustering

Dans Databricks Runtime 16.4 LTS et versions ultérieures, vous pouvez forcer le reclustering de tous les enregistrements d’une table avec la syntaxe suivante :

OPTIMIZE table_name FULL;

Exécutez OPTIMIZE FULL lorsque vous activez le clustering pour la première fois ou modifiez les clés de clustering. Si vous avez déjà exécuté OPTIMIZE FULL et qu’aucune modification n’a été apportée aux clés de clustering, OPTIMIZE FULL s’exécute de la même façon que OPTIMIZE. Dans ce scénario, OPTIMIZE utilise une approche incrémentielle et réécrit uniquement les fichiers qui n’ont pas été précédemment compactés. Utilisez toujours OPTIMIZE FULL pour vous assurer que la disposition des données reflète les clés de clustering actuelles.

Recluster partiel

Dans Databricks Runtime 18.1 et versions ultérieures, vous pouvez forcer le reclustering pour un sous-ensemble d’enregistrements à l’aide de OPTIMIZE FULL WHERE <predicate>. Un fichier est inclus si une partie de son intervalle se chevauche avec le prédicat. Voir Paramètres.

OPTIMIZE events FULL WHERE event_date >= '2025-01-01';

Lire les données d’une table en cluster

Vous pouvez lire des données dans une table Delta Lake en cluster à l’aide de n’importe quel client Delta Lake qui prend en charge la lecture de vecteurs de suppression. À l’aide de l’API du catalogue REST Iceberg, vous pouvez lire des données dans une table Iceberg en cluster. Le clustering liquide améliore les performances des requêtes via le saut automatique des données lors du filtrage sur les clés de clustering.

SELECT * FROM table_name WHERE cluster_key_column_name = "some_value";

Gérer les clés de clustering

Découvrez comment une table est clusterisée

Vous pouvez utiliser des commandes DESCRIBE pour afficher les clés de clustering d’une table, comme dans les exemples suivants :

DESCRIBE TABLE table_name;

DESCRIBE DETAIL table_name;

Modifier les clés de clustering

Vous pouvez modifier les clés de clustering d’une table à tout moment en exécutant une commande ALTER TABLE, comme dans l’exemple suivant :

ALTER TABLE table_name CLUSTER BY (new_column1, new_column2);

Lorsque vous modifiez des clés de clustering, les opérations OPTIMIZE et d’écriture suivantes utilisent la nouvelle approche par clustering, mais les données existantes ne sont pas réécrites. Pour réécrire des données existantes avec les clés de clustering mises à jour, consultez Forcer le reclustering.

Vous pouvez également désactiver le clustering en définissant les clés sur NONE, comme dans l’exemple suivant :

ALTER TABLE table_name CLUSTER BY NONE;

La définition des clés de cluster pour NONE ne réécrit pas les données clusterisées, mais empêche les opérations futures OPTIMIZE d’utiliser des clés de clusterisation.

Utiliser le clustering liquide à partir d’un moteur externe

Vous pouvez activer le « liquid clustering » sur des tables Iceberg gérées à partir de moteurs Iceberg externes. Pour activer le clustering liquide, spécifiez des colonnes de partition lors de la création d’une table. Unity Catalog interprète les partitions en tant que clés de clustering. Par exemple, exécutez la commande ci-dessous dans OSS Spark :

CREATE OR REPLACE TABLE main.schema.icebergTable
PARTITIONED BY c1;

Pour désactiver le clustering liquide :

ALTER TABLE main.schema.icebergTable DROP PARTITION FIELD c2;

Pour modifier les clés de clustering en utilisant l'évolution des partitions Iceberg :

ALTER TABLE main.schema.icebergTable ADD PARTITION FIELD c2;

Si vous spécifiez une partition à l’aide d’une transformation de compartiment, Unity Catalog supprime l’expression et utilise la colonne comme clé de clustering :

CREATE OR REPLACE TABLE main.schema.icebergTable
PARTITIONED BY (bucket(c1, 10));

Compatibilité pour les tables avec le clustering liquide

Le clustering liquide utilise des fonctionnalités de table Delta Lake qui nécessitent des versions spécifiques de Databricks Runtime pour les opérations de lecture et d’écriture. Les tables créées avec un clustering liquide dans Databricks Runtime 14.3 LTS et ultérieures utilisent le point de contrôle V2 par défaut. Vous pouvez lire et écrire des tables avec le point de contrôle V2 dans Databricks Runtime 13.3 LTS et versions ultérieures. Voir Point de contrôle V2.

Pour prendre en charge les lecteurs utilisant Databricks Runtime 12.2 LTS à 13.2, désactivez le point de contrôle V2 et rétrogradez le protocole de table. Voir Rétrograder vers classique.

Outrepasser l’activation des fonctionnalités par défaut (facultatif)

Vous pouvez remplacer l’activation par défaut des fonctionnalités des tables Delta Lake lors de l’activation du clustering liquide. Cela empêche les mises à niveau des protocoles de lecteur et d’enregistreur associés à ces fonctionnalités de table. Vous devez disposer d’une table existante pour effectuer les étapes suivantes :

1. Permet ALTER TABLE de définir la propriété de table qui désactive une ou plusieurs fonctionnalités. Par exemple, pour désactiver les vecteurs de suppression, exécutez ce qui suit :

   ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = false);
   

2. Activez le clustering liquide sur la table en exécutant les éléments suivants :

   ALTER TABLE <table_name>
   CLUSTER BY (<clustering_columns>)
   

Le tableau suivant contient des informations sur les fonctionnalités Delta que vous pouvez remplacer et comment l’activation affecte la compatibilité avec les versions de Databricks Runtime :

Limitations

• Databricks Runtime 15.1 et versions antérieures : le clustering lors de l'écriture ne prend pas en charge les requêtes sources qui incluent des filtres, des jointures ou des agrégations.
• Databricks Runtime 15.4 LTS et versions antérieures : vous ne pouvez pas créer une table avec un clustering liquide activé par le biais d’une écriture en flux structuré. Vous pouvez utiliser le streaming structuré pour écrire des données dans une table existante avec clustering liquide activé.
• Apache Iceberg v2 : la concurrence au niveau des lignes n’est pas prise en charge sur les tables Apache Iceberg v2 gérées, car les vecteurs de suppression et le suivi des lignes ne sont pas pris en charge.
  • La concurrence au niveau des lignes est prise en charge sur les tables Apache Iceberg v3 gérées, car la spécification v3 prend en charge les vecteurs de suppression et le suivi des lignes. Consultez Utiliser les fonctionnalités Apache Iceberg v3.