Aller au contenu principal
Dernière mise à jour le

Utiliser le clustering liquide pour les tables

Le clustering fluide est une technique d'optimisation du Layout des données qui remplace le partitionnement de table et ZORDER. Il simplifie la gestion des tables et optimise les performances des queries 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. Ceci permet à votre Layout de données d'évoluer en fonction des besoins analytiques changeants. Le liquid clustering s'applique à la fois aux tables de streaming et aux vues matérialisées.

important

Le clustering liquide est généralement disponible pour les tables Delta Lake avec Databricks Runtime 15.4 LTS et versions supérieures, et en Aperçu Public pour les tables Apache Iceberg dans Databricks Runtime 16.4 LTS et versions supérieures. Databricks recommande d'utiliser la dernière version de Databricks Runtime pour des performances optimales.

Les tables Apache Iceberg v3 gérées prennent également en charge les vecteurs de suppression, le suivi des lignes, la concurrence au niveau des lignes et la mise en cluster liquide automatique. Ces fonctionnalités nécessitent Databricks Runtime 18.0 ou une version ultérieure. Voir Utiliser les fonctionnalités d'Apache Iceberg v3.

Quand utiliser le clustering fluide​

Databricks recommande le clustering liquide pour toutes les nouvelles tables, y compris les tables de streaming et les vues matérialisées. Les scénarios suivants bénéficient particulièrement du clustering :

  • Requêtes qui filtrent sur des colonnes à cardinalité élevée.
  • Tables avec un fort décalage des données.
  • Tables à croissance rapide qui nécessitent un effort de maintenance et d'ajustement.
  • Tables avec des exigences d'écriture concurrentes.
  • Tables avec des modèles d'accès variés ou modifiés.
  • Tables où une clé de partition typique pourrait renvoyer des résultats de trop de partitions ou de trop peu de partitions.

Activer le clustering liquide​

Vous pouvez activer le liquid clustering sur une table non partitionnée existante ou pendant la création de la table. Le clustering n'est pas compatible avec le partitionnement ou ZORDER. Databricks vous recommande de permettre à la plateforme de gérer toutes les Opérations de Layout et d'optimisation pour les données de votre table. Après avoir activé le liquid clustering, exécutez OPTIMIZE Jobs pour regrouper les données de manière incrémentielle. Consultez How to Trigger le clustering.

Créez des tables avec clustering​

Pour activer le liquid clustering, ajoutez la phrase 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 en Python ou Scala pour activer le liquid clustering pour les tables Delta Lake.

Pour créer une table vide avec des clusters :

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

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

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

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

SQL
CREATE TABLE table3 LIKE table1;
important

Lorsque vous utilisez les APIs DataFrame pour définir des clés de clustering, vous ne pouvez spécifier des colonnes de clustering que lors de la création de tables ou lorsque vous utilisez le mode overwrite (comme avec les CREATE OR REPLACE TABLE opérations). Vous ne pouvez pas modifier les clés de clustering lors de l'utilisation du mode append.

Pour modifier les clés de clustering sur une table existante tout en ajoutant des données, utilisez les commandes SQL ALTER TABLE pour modifier la configuration de clustering séparément de vos opérations d'écriture de données. Voir Modifier les clés de clustering.

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

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

Les tables Delta Lake avec clustering liquide activé utilisent la version 7 d'écriture Delta et la version 3 de lecture. Les clients Delta qui ne prennent pas en charge ces protocoles ne peuvent pas lire ces tables. Vous ne pouvez pas rétrograder les versions de protocole de table. Consultez la compatibilité des fonctionnalités et les protocoles de Delta Lake.

Pour remplacer l'activation des fonctionnalités default, telles que les vecteurs de suppression, voir Remplacer l'activation des fonctionnalités default (facultatif).

Activer sur les tables existantes​

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

SQL
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 requise car les vecteurs de suppression et le suivi des lignes sont pris en charge. Consultez Utiliser les fonctionnalités Apache Iceberg v3.
remarque

Le comportement par default n'applique pas le clustering aux données précédemment écrites. Pour forcer le re-regroupement, utilisez OPTIMIZE FULL ou OPTIMIZE FULL WHERE <predicate>. Voir Forcer le re-regroupement.

Convertir une table partitionnée en liquid clustering​

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 minimise les temps d'arrêt des lecteurs et des rédacteurs et prend en charge les tables externes et gérées. Après conversion, la table prend en charge les lectures avec Databricks Runtime 13.3 LTS et versions ultérieures.

remarque

Pour les tables Iceberg gérées, la conversion n'est pas nécessaire, car ces tables utilisent les définitions de partition comme clés de clustering liquide. L'exécution de la commande de conversion entraîne une erreur.

Les avantages de convertir les tables partitionnées en clustering liquide comprennent :

  • Améliorations des performances pour les tables qui souffrent d'une mauvaise omission de données ou de sur-partitionnement.
  • Améliorations automatiques des performances, à l'aide de CLUSTER BY AUTO, pour les tables avec des modèles de query fréquemment modifiés.
  • Les colonnes de clustering sont flexibles et simples à modifier, tandis que le partitionnement est rigide et difficile à modifier.
  • Conflits d'écriture réduits car les tables avec clustering liquide permettent la concurrence au niveau des lignes. Consultez Simultanéité au niveau des lignes.

Syntaxe​

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

La clause CLUSTER BY prend en charge les options suivantes :

  • ( <clustering_columns> ) : Spécifie les nouvelles colonnes de clustering. Databricks recommande de maintenir les nouvelles colonnes de clustering similaires aux colonnes de partition d'origine. L'utilisation de colonnes très différentes Trigger une opération de reclustering importante lors de la première exécution OPTIMIZE.
  • 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 Unity Catalog. Voir Clustering liquide automatique.
  • 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 clusters lors de la migration à partir de tables partitionnées, consultez Migration à partir du partitionnement ou de Z-order.

Exemples​

Pour regrouper sur des colonnes différentes des partitions d'origine, comme pour une table partitionnée sur (year, month, day), effectuez les opérations suivantes :

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

Pour bénéficier de la modification des colonnes de clustering, vous devez exécuter OPTIMIZE.

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

SQL
ALTER TABLE t2 REPLACE PARTITIONED BY WITH CLUSTER BY AUTO;

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

SQL
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 ou version supérieure est pris en charge pour les lectures et les écritures. Databricks recommande Databricks Runtime 15.4 LTS ou version supérieure 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 :

Type de Workload

Lectures pendant la conversion

Écritures pendant la conversion

Batch

Aucun temps d'arrêt. Toutes les versions de Databricks Runtime peuvent lire la table pendant la conversion.

Aucune interruption sur Databricks Runtime 15,4 et versions supérieures. Pour Databricks Runtime 15.3 et les versions antérieures, Databricks vous recommande de mettre en pause les charges de travail avant la conversion, puis de redémarrer les charges de travail une fois la conversion terminée.

Streaming

Avec suivi du schéma et mappage des colonnes : Redémarrez le Stream sans perdre de commits. **Sans suivi de schéma ni mappage des colonnes** : le stream déclenche une exception. Redémarrez avec un nouvel emplacement de point de contrôle et une version start. Les commits ne sont pas perdus.

Redémarrez le Stream sans perdre aucun commits.

Type de Workload

Lectures pendant la conversion

Écritures pendant la conversion

Batch

Aucun temps d'arrêt. Toutes les versions de Databricks Runtime peuvent lire la table pendant la conversion.

Aucune interruption sur Databricks Runtime 15,4 et versions supérieures. Pour Databricks Runtime 15.3 et les versions antérieures, Databricks vous recommande de mettre en pause les charges de travail avant la conversion, puis de redémarrer les charges de travail une fois la conversion terminée.

Streaming

Avec suivi du schéma et mappage des colonnes : Redémarrez le Stream sans perdre de commits. **Sans suivi de schéma ni mappage des colonnes** : le stream déclenche une exception. Redémarrez avec un nouvel emplacement de point de contrôle et une version start. Les commits ne sont pas perdus.

Redémarrez le Stream sans perdre aucun commits.

Vérifier ou annuler une conversion​

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

Pour annuler une conversion, utilisez RESTORE pour revenir à la version précédente. Alternativement, vous pouvez réécrire la table à l'aide de REPLACE TABLE ... PARTITIONED BY (...) AS SELECT * FROM ....

Pour annuler à l'aide de RESTORE, exécutez les commandes suivantes :

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

See RESTORE.

Convertir une table partitionnée par une colonne Timestamp​

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

SQL
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 tentez de convertir une colonne de partition Timestamp en colonne de clustering sans ces configurations, la commande génère une erreur :

Text
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 conversion REPLACE PARTITIONED BY WITH CLUSTER BY :

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

Supprimez les clés de clustering​

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

SQL
ALTER TABLE table_name CLUSTER BY NONE;

Choisir les clés de partitionnement​

Choisissez les clés de clustering en fonction des colonnes les plus fréquemment utilisées dans les filtres de query. Les bonnes clés améliorent considérablement l'ignorance des données et les performances des query.

astuce

Databricks vous recommande d’utiliser le clustering liquide automatique pour sélectionner intelligemment les clés de clustering en fonction de vos modèles de query. Voir le clustering liquide automatique.

Consignes de sélection de clé​

Lorsque vous spécifiez manuellement des clés de clustering, choisissez les colonnes en fonction des colonnes les plus fréquemment utilisées dans les filtres de query. Vous pouvez définir les clés de clustering dans n'importe quel ordre. Si deux colonnes sont fortement corrélées, vous n'avez besoin d'inclure qu'une seule d'entre elles comme clé de clustering.

Vous pouvez spécifier jusqu'à quatre clés de cluster . Pour les tables plus petites (moins de 10 To), l’utilisation de davantage de 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 moins performant qu'avec deux clés. Cependant, à mesure que la taille de la table augmente, cette différence de performances devient négligeable pour les queries à colonne unique.

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

Types de données pris en charge​

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

  • Date
  • Horodatage
  • TimestampNTZ (Databricks Runtime 14.3 LTS et versions supérieures).
  • Chaîne
  • Entier, Long, Court, Octet
  • Float, Double, Décimal

Vous pouvez regrouper par un StructField en utilisant la notation par points, tel que CLUSTER BY (struct_col.field). Les champs de structure imbriqués sont pris en charge à n'importe quelle profondeur, tel que 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 regrouper par aucun des éléments suivants :

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

Migration depuis le partitionnement ou Z-order​

important

Databricks vous recommande d'utiliser la conversion automatique avec la commande REPLACE PARTITIONED BY WITH CLUSTER BY. Voir Convertir une table partitionnée en clustering liquide.

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

Technique actuelle d'optimisation des données

Recommandation pour les clés de clustering

Partitionnement de style Hive

Utilisez les colonnes de partition comme clés de clustering.

Indexation Z-order

Utilisez les colonnes ZORDER BY comme clés de clustering.

Partitionnement de type Hive et Z-order

Utilisez à la fois les colonnes de partition et les colonnes ZORDER BY comme clés de clustering.

Colonnes générées pour réduire la cardinalité (par exemple, la date pour un timestamp)

Utilisez la colonne d'origine comme clé de clustering, et ne créez pas de colonne générée.

Technique actuelle d'optimisation des données

Recommandation pour les clés de clustering

Partitionnement de style Hive

Utilisez les colonnes de partition comme clés de clustering.

Indexation Z-order

Utilisez les colonnes ZORDER BY comme clés de clustering.

Partitionnement de type Hive et Z-order

Utilisez à la fois les colonnes de partition et les colonnes ZORDER BY comme clés de clustering.

Colonnes générées pour réduire la cardinalité (par exemple, la date pour un timestamp)

Utilisez la colonne d'origine comme clé de clustering, et ne créez pas de colonne générée.

Clustering liquide automatique​

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 Unity Catalog. Pour les tables Apache Iceberg v3 gérées par Unity Catalog, le clustering liquide automatique nécessite Databricks Runtime 18,0 et versions ultérieures. Le clustering liquide automatique permet à Databricks de choisir intelligemment les clés de clustering pour optimiser les performances des queries, en utilisant la clause CLUSTER BY AUTO.

remarque

Le clustering liquide automatique est également pris en charge pour les vues matérialisées et les tables de streaming, y compris les Lakeflow pipelines et les pipelines autonomes. Spécifiez CLUSTER BY AUTO dans votre définition de pipeline ou SQL.

Fonctionnement du liquid clustering automatique​

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 gérées par Unity Catalog.

Le clustering liquide automatique applique des optimisations intelligentes basées sur vos modèles d'utilisation :

  • Analyse la charge de travail des requêtes : Databricks analyse la charge de travail historique des requêtes de la table et identifie les meilleures colonnes candidates pour le clustering.
  • S'adapte aux changements : si vos modèles de query ou vos 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 axée sur les coûts : Databricks ne modifie les clés de clustering que lorsque les économies de coûts prévues grâce aux améliorations du saut de données dépassent le coût du clustering des données.

Le clustering liquide automatique pourrait ne pas sélectionner de clés pour les raisons suivantes :

  • La table est trop petite pour bénéficier du clustering liquide.
  • La table dispose déjà d’un schéma de clustering efficace, provenant soit de clés manuelles précédentes, soit d’un ordre d’insertion naturel qui correspond aux modèles de query.
  • Le tableau n’a pas de query fréquentes.
  • Vous n'utilisez pas Databricks Runtime 15.4 LTS ou une version ultérieure.

Vous pouvez appliquer le clustering liquide automatique à toutes les tables gérées par Unity Catalog, quelles que soient les caractéristiques des données et des query. Les heuristiques déterminent s'il est rentable de sélectionner des clés de clustering.

Compatibilité de la version 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. Cependant, la sélection intelligente de clés repose sur les métadonnées introduites dans Databricks Runtime 15,4 LTS.

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

Activez ou désactivez le clustering liquide automatique​

Pour créer une table avec clustering liquide automatique :

SQL
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 avec des clés spécifiées manuellement :

SQL
ALTER TABLE table1 CLUSTER BY AUTO;

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

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

Alternativement, utilisez l'API Python pour définir des indicateurs en une seule opération.

Pour désactiver le clustering liquide automatique :

SQL
ALTER TABLE table1 CLUSTER BY NONE;

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

SQL
ALTER TABLE table1 CLUSTER BY (column01, column02);

Si une table existante a le clustering liquide automatique activé, l'exécution de CREATE OR REPLACE table_name sans CLUSTER BY AUTO désactive le clustering automatique et ne préserve pas les colonnes de clustering. Pour préserver le clustering liquide automatique et toutes les colonnes précédemment sélectionnées, incluez CLUSTER BY AUTO dans l'instruction de remplacement. Avec CLUSTER BY AUTO, l'optimisation prédictive utilise la charge de travail de query historique pour la table afin d'identifier les meilleures clés de clustering.

Vérifier si le regroupement automatique des clusters est activé​

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

Si le liquid clustering automatique est activé, la propriété clusterByAuto est définie sur true. La propriété clusteringColumns affiche les colonnes de clustering actuelles qui ont été sélectionnées automatiquement ou 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 dans une table Delta Lake clusterisée, vous devez utiliser un client d'écriture Delta qui prend en charge toutes les fonctionnalités de table du protocole d'écriture Delta utilisées par le liquid clustering. Pour écrire dans une table Iceberg clusterisée, vous pouvez utiliser l'API REST Catalog d'Iceberg de Unity Catalog. Sur Databricks, vous devez utiliser Databricks Runtime 13.3 LTS ou une version ultérieure.

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

Les opérations de cluster sur écriture incluent les suivantes :

  • INSERT INTO Opérations
  • CTAS et RTAS instructions
  • COPY INTO depuis le format Parquet
  • spark.write.mode("append")

threshold de taille pour le clustering​

Le clustering en écriture ne se Trigger que lorsque les données de la transaction atteignent un threshold de taille. Ces thresholds varient en fonction du nombre de colonnes de clustering et sont inférieurs pour les tables gérées par Unity Catalog que pour les autres tables Delta Lake.

Nombre de colonnes de clustering

Taille de threshold pour les tables gérées par Unity Catalog.

threshold size pour les autres tables Delta Lake

1

64 Mo

256 Mo

2

256 Mo

1 Go

3

512 Mo

2 Go

4

1 Go

4 Go

Nombre de colonnes de clustering

Taille de threshold pour les tables gérées par Unity Catalog.

threshold size pour les autres tables Delta Lake

1

64 Mo

256 Mo

2

256 Mo

1 Go

3

512 Mo

2 Go

4

1 Go

4 Go

Étant donné que toutes les opérations n'appliquent pas le clustering fluide, Databricks recommande d'exécuter fréquemment OPTIMIZE pour s'assurer que toutes les données sont efficacement clusterisées.

Charges de travail en streaming​

Les charges de travail Structured Streaming prennent en charge le clustering à l'écriture lorsque vous définissez la configuration Spark spark.databricks.delta.liquid.eagerClustering.streaming.enabled sur true. Le clustering pour ces charges de travail ne Trigger que si au moins une des cinq dernières mises à jour de streaming dépasse un threshold de taille du tableau ci-dessus.

How to Trigger clustering​

L'optimisation prédictive exécute automatiquement les commandes OPTIMIZE pour les tables activées. Consultez Optimisation prédictive pour les tables gérées par Unity Catalog. Lorsque vous utilisez l'optimisation prédictive, Databricks recommande de désactiver tous les Jobs OPTIMIZE planifiés.

To Trigger 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 OPTIMIZE plus rapides sur les grandes tables. Utilisez la commande OPTIMIZE sur votre table :

SQL
OPTIMIZE table_name;

Le clustering fluide est incrémentiel , ce qui signifie que OPTIMIZE ne réécrit les données que si nécessaire pour s'adapter aux données qui nécessitent un clustering. OPTIMIZE ne réécrit pas les fichiers de données avec des clés de clustering qui ne correspondent pas aux données clusterisées. Consultez Forcer le reclassement.

Si vous n’utilisez pas l’optimisation prédictive, Databricks recommande de planifier régulièrement des OPTIMIZE jobs pour clusteriser les données. Pour les tables subissant de nombreuses mises à jour ou insertions, Databricks recommande de planifier un OPTIMIZE job toutes les une ou deux heures. Le clustering liquide étant incrémentiel, la plupart des OPTIMIZE jobs pour les tables clusterisées s’exécutent rapidement.

Forcer la reclusterisation​

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

SQL
OPTIMIZE table_name FULL;
important

L'exécution de OPTIMIZE FULL reclustérise toutes les données existantes si nécessaire. Pour les grandes tables qui n’ont pas été préalablement mises en cluster sur les clés spécifiées, cette opération peut prendre des heures.

Exécutez OPTIMIZE FULL lorsque vous activez le clustering pour la première fois ou que vous modifiez les clés de clustering. Si vous avez exécuté précédemment OPTIMIZE FULL et qu'il n'y a eu aucun changement dans les clés de clustering, OPTIMIZE FULL s'exécute de la même manière que OPTIMIZE. Dans ce scénario, OPTIMIZE utilise une approche incrémentielle et réécrit uniquement les fichiers qui n'ont pas été compactés précédemment. Assurez-vous toujours d’utiliser OPTIMIZE FULL pour que la data Layout reflète les clés de clustering actuelles.

Recluster partiel​

À partir de 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 sa plage chevauche le prédicat. See parameter.

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

Lire les données d'une table en cluster​

Vous pouvez lire les données d’une table Delta Lake clusterisée à l’aide de n’importe quel client Delta Lake qui prend en charge la lecture des vecteurs de suppression. Grâce à l’API Iceberg REST Catalog, vous pouvez lire les données d’une table Iceberg clusterisée. Le clustering liquide améliore les performances des query grâce au saut de données automatique lors du filtrage sur les clés de clustering.

SQL
SELECT * FROM table_name WHERE cluster_key_column_name = "some_value";

Gérer les clés de clustering​

Voir comment une table est groupée​

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

SQL
DESCRIBE TABLE table_name;

DESCRIBE DETAIL table_name;

Modifier les clés de clusters​

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

SQL
ALTER TABLE table_name CLUSTER BY (new_column1, new_column2);

Lorsque vous modifiez les clés de clustering, les OPTIMIZE et opérations d'écriture ultérieures utilisent la nouvelle approche de clustering, mais les données existantes ne sont pas réécrites. Pour réécrire les données existantes avec les clés de partitionnement mises à jour, consultez Forcer le repartitionnement.

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

SQL
ALTER TABLE table_name CLUSTER BY NONE;

La définition des clés de cluster sur NONE ne réécrit pas les données en clusters, mais empêche les futures OPTIMIZE Opérations d'utiliser les clés de clustering.

Utilisez le clustering liquide à partir d'un moteur externe​

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

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

Pour désactiver le clustering fluide :

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

Pour modifier les clés de clustering à l’aide de l’évolution des partitions Iceberg :

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

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

Compatibilité pour les tables avec clustering liquide​

Le clustering liquide utilise les fonctionnalités de table Delta Lake qui nécessitent des versions spécifiques de Databricks Runtime pour la lecture et l'écriture. Les tables créées avec le clustering liquide dans Databricks Runtime 14.3 LTS et versions ultérieures utilisent le checkpoint V2 par default. Vous pouvez lire et écrire des tables avec le checkpoint V2 dans Databricks Runtime 13.3 LTS et versions ultérieures. Consultez Checkpoint 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. Consultez Passer à la version classique.

Remplacer l'activation de la fonctionnalité default (facultatif)​

Vous pouvez remplacer l’activation default des fonctionnalités de table Delta Lake lors de l’activation du clustering liquide. Cela empêche les mises à niveau des protocoles de lecture et d'écriture associés à ces fonctionnalités de table. Vous devez disposer d'une table existante pour suivre les étapes suivantes :

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

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

  2. Activez le clustering liquide sur la table en exécutant la commande suivante :

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

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

Fonctionnalité Delta

Compatibilité du Runtime

Propriété de remplacement de l'activation.

Effets sur le clustering liquide s'il est désactivé.

Vecteurs de suppression

Les lectures et écritures nécessitent Databricks Runtime 12,2 LTS ou une version supérieure.

'delta.enableDeletionVectors' = false

La désactivation des vecteurs de suppression désactive également la simultanéité au niveau des lignes, ce qui rend les transactions et les opérations de clustering plus susceptibles d'entrer en conflit. Consultez Simultanéité au niveau des lignes.

DELETE, les commandes MERGE et UPDATE peuvent s'exécuter plus lentement.

Suivi des lignes

Les écritures nécessitent Databricks Runtime 13.3 LTS ou une version ultérieure. Peut être lu depuis n'importe quelle version de Databricks Runtime.

'delta.enableRowTracking' = false

La désactivation du suivi des lignes désactive également la concurrence au niveau des lignes, rendant les transactions et les opérations de clustering plus susceptibles d'entrer en conflit. Consultez Simultanéité au niveau des lignes.

Point de contrôle V2

Les lectures et les écritures nécessitent Databricks Runtime 13.3 LTS ou une version ultérieure.

'delta.checkpointPolicy' = 'classic'

Aucun effet sur le comportement du clustering fluide. Consultez Point de contrôle V2.

Fonctionnalité Delta

Compatibilité du Runtime

Propriété de remplacement de l'activation.

Effets sur le clustering liquide s'il est désactivé.

Vecteurs de suppression

Les lectures et écritures nécessitent Databricks Runtime 12,2 LTS ou une version supérieure.

'delta.enableDeletionVectors' = false

La désactivation des vecteurs de suppression désactive également la simultanéité au niveau des lignes, ce qui rend les transactions et les opérations de clustering plus susceptibles d'entrer en conflit. Consultez Simultanéité au niveau des lignes.

DELETE, les commandes MERGE et UPDATE peuvent s'exécuter plus lentement.

Suivi des lignes

Les écritures nécessitent Databricks Runtime 13.3 LTS ou une version ultérieure. Peut être lu depuis n'importe quelle version de Databricks Runtime.

'delta.enableRowTracking' = false

La désactivation du suivi des lignes désactive également la concurrence au niveau des lignes, rendant les transactions et les opérations de clustering plus susceptibles d'entrer en conflit. Consultez Simultanéité au niveau des lignes.

Point de contrôle V2

Les lectures et les écritures nécessitent Databricks Runtime 13.3 LTS ou une version ultérieure.

'delta.checkpointPolicy' = 'classic'

Aucun effet sur le comportement du clustering fluide. Consultez Point de contrôle V2.

Limitations​

  • Databricks Runtime 15.1 et versions antérieures : Le clustering à l'écriture ne prend pas en charge les queries 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 de table avec le clustering liquide activé à l’aide d’une écriture Structured Streaming. Vous pouvez utiliser Structured Streaming pour écrire des données dans une table existante avec le 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 gérées Apache Iceberg v3 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.
Sur cette page