Utiliser des clustering liquides pour les tableaux Delta
Le clustering liquide Delta Lake remplace le partitionnement des tables et ZORDER
pour simplifier les décisions de disposition des données et optimiser les performances des requêtes. Liquid Clustering offre une flexibilité pour redéfinir les clés de clustering sans réécrire les données existantes, ce qui permet d’adapter la disposition des données en fonction de l’évolution des besoins analytiques.
Important
Databricks recommande d’utiliser Databricks Runtime 15.2 et versions ultérieures pour toutes les tables avec clustering liquide activé. La prise en charge de la préversion publique avec limitations est disponible dans Databricks Runtime 13.3 LTS et versions ultérieures.
Remarque
Les tables avec clustering liquide activé prennent en charge l’accès concurrentiel au niveau des lignes dans Databricks Runtime 13.3 LTS et versions ultérieures. L’accès concurrentiel au niveau des lignes est généralement disponible dans Databricks Runtime 14.2 et versions ultérieures pour toutes les tables ayant les vecteurs de suppression activés. Consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.
À quoi sert le clustering liquide ?
Databricks recommande le clustering liquide pour toutes les nouvelles tables Delta. Voici des exemples de scénarios qui tirent parti du clustering :
- Tables souvent filtrées par des colonnes à cardinalité élevée.
- Tables avec une asymétrie significative dans la distribution des données.
- Tables qui augmentent rapidement de taille et nécessitent des efforts de maintenance et de réglage.
- Tables avec des exigences d’écriture concurrentielle.
- Tables avec des modèles d’accès qui changent au fil du temps.
- Tables où une clé de partition classique peut laisser la table avec trop ou trop peu de partitions.
Activer le clustering liquide
Vous pouvez activer le cluster liquide sur une table existante ou lors de la création d’une table. La mise en cluster n'est pas compatible avec le partitionnement ou ZORDER
, et nécessite que vous utilisiez Azure Databricks pour gérer toutes les opérations de mise en page et d'optimisation des données de votre table. Une fois le clustering liquide activé, exécutez OPTIMIZE
des travaux comme d’habitude pour les données de cluster incrémentielle. Consultez Comment déclencher le clustering.
Pour activer le clustering liquide, ajoutez l’expression CLUSTER BY
à une instruction de création de table, comme dans les exemples ci-dessous :
Remarque
Dans Databricks Runtime 14.2 et ultérieur, vous pouvez utiliser les API DataFrame et l’API DeltaTable dans Python ou Scala pour activer le clustering liquide.
SQL
-- Create an empty table
CREATE TABLE table1(col0 int, col1 string) CLUSTER BY (col0);
-- Using a CTAS statement
CREATE EXTERNAL TABLE table2 CLUSTER BY (col0) -- specify clustering after table name, not in subquery
LOCATION 'table_location'
AS SELECT * FROM table1;
-- Using a LIKE statement to copy configurations
CREATE TABLE table3 LIKE table1;
Python
# Create an empty table
(DeltaTable.create()
.tableName("table1")
.addColumn("col0", dataType = "INT")
.addColumn("col1", dataType = "STRING")
.clusterBy("col0")
.execute())
# Using a CTAS statement
df = spark.read.table("table1")
df.write.clusterBy("col0").saveAsTable("table2")
# CTAS using DataFrameWriterV2
df = spark.read.table("table1")
df.writeTo("table1").using("delta").clusterBy("col0").create()
Scala
// Create an empty table
DeltaTable.create()
.tableName("table1")
.addColumn("col0", dataType = "INT")
.addColumn("col1", dataType = "STRING")
.clusterBy("col0")
.execute()
// Using a CTAS statement
val df = spark.read.table("table1")
df.write.clusterBy("col0").saveAsTable("table2")
// CTAS using DataFrameWriterV2
val df = spark.read.table("table1")
df.writeTo("table1").using("delta").clusterBy("col0").create()
Avertissement
Les tables créées avec le clustering liquide activé ont de nombreuses fonctionnalités de table Delta activées à la création et utilisent l’enregistreur Delta version 7 et le lecteur version 3. Vous pouvez outrepasser l’activation de certaines de ces fonctionnalités. Consultez Outrepasser l’activation des fonctionnalités par défaut (facultatif).
Les versions de protocole de table ne peuvent pas être rétrogradées, et les tables avec clustering activé ne sont pas lisibles par les clients Delta Lake qui ne prennent pas en charge toutes les fonctionnalités de table de protocole de lecteur Delta activées. Consultez Comment Azure Databricks gère-t-il la compatibilité des fonctionnalités Delta Lake ?.
Vous pouvez activer le clustering liquide sur une table Delta non partitionnée existante en utilisant la syntaxe suivante :
ALTER TABLE <table_name>
CLUSTER BY (<clustering_columns>)
Outrepasser l’activation des fonctionnalités par défaut (facultatif)
Vous pouvez outrepasser le comportement par défaut qui active les fonctionnalités de table Delta pendant l’activation du clustering liquide. Cela empêche la mise à niveau des protocoles de lecture et d’écriture associés à ces fonctionnalités de table. Vous devez disposer d’une table existante pour effectuer les étapes suivantes :
Utilisez
ALTER TABLE
pour 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);
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 fournit des informations sur les fonctionnalités Delta que vous pouvez outrepasser et sur l’impact de l’activation sur la compatibilité avec les versions de Databricks Runtime.
Fonctionnalité Delta | Compatibilité du runtime | Propriété pour outrepasser l’activation | Impact de la désactivation sur le clustering liquide |
---|---|---|---|
Vecteurs de suppression | Les lectures et les écritures nécessitent Databricks Runtime 12.2 ITS et versions ultérieures. | 'delta.enableDeletionVectors' = false |
La concurrence au niveau des lignes est désactivée, ce qui rend les transactions et les opérations de clustering plus susceptibles d’être en conflit. Consultez Conflits d’écriture avec concurrence au niveau des lignes.DELETE , MERGE et les commandes UPDATE peuvent s’exécuter plus lentement. |
Suivi des lignes | Les écritures nécessitent Databricks Runtime 13.3 LTS et versions ultérieures. Peut être lu à partir de n’importe quelle version de Databricks Runtime. | 'delta.enableRowTracking' = false |
La concurrence au niveau des lignes est désactivée, ce qui rend les transactions et les opérations de clustering plus susceptibles d’être en conflit. Consultez Conflits d’écriture avec concurrence au niveau des lignes. |
Points de contrôle V2 | Les lectures et les écritures nécessitent Databricks Runtime 13.3 LTS et versions ultérieures. | 'delta.checkpointPolicy' = 'classic' |
Aucun impact sur le comportement de clustering liquide. |
Choisir les clés de clustering
Databricks recommande de choisir des clés de clustering basées sur des filtres de requête couramment utilisés. Les clés de clustering peuvent être définies dans n’importe quel ordre. Si deux colonnes sont corrélées, vous ne devez ajouter que l’une d’elles en tant que clé de clustering.
Vous pouvez spécifier jusqu’à 4 colonnes comme clés de clustering. Vous pouvez uniquement spécifier des colonnes avec des statistiques collectées pour les clés de clustering. Par défaut, les 32 premières colonnes d’une table Delta contiennent des statistiques collectées. Consultez Spécifier des colonnes de statistiques Delta.
Le clustering prend en charge les types de données suivants pour les clés de clustering :
- Date
- Horodateur
- TimestampNTZ (requiert Databricks Runtime 14.3 LTS ou version ultérieure)
- Chaîne
- Entier
- Long
- Court
- Float
- Double
- Decimal
- Byte
Si vous convertissez une table existante, tenez compte des recommandations suivantes :
Technique d’optimisation des données actuelle | Recommandation pour les clés de clustering |
---|---|
Partitionnement de style Hive | Utilisez des colonnes de partition comme clés de clustering. |
Indexation de tri en z | Utilisez les colonnes ZORDER BY comme clés de clustering. |
Partitionnement de style Hive et tri en z | Utilisez à la fois des colonnes de partition et des colonnes ZORDER BY comme clés de clustering. |
Colonnes générées pour réduire la cardinalité (par exemple, date pour un timestamp) | Utilisez la colonne d’origine comme clé de clustering et ne créez pas de colonne générée. |
Écrire des données dans une table en cluster
Vous devez utiliser un client enregistreur Delta qui prend en charge toutes les fonctionnalités de table de protocole d’écriture Delta utilisées par le clustering liquide. Sur Azure Databricks, vous devez utiliser Databricks Runtime 13.3 LTS et versions ultérieures.
Les opérations qui effectuent un clustering en écriture sont les suivantes :
- Opérations
INSERT INTO
- Instructions
CTAS
etRTAS
COPY INTO
à partir du format Parquetspark.write.mode("append")
Les écritures de streaming structuré ne déclenchent jamais le clustering en écriture. Des limitations supplémentaires s’appliquent. Voir Limitations.
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 managées Unity Catalog que les autres tables Delta.
Nombre de colonnes de clustering | Taille de seuil pour les tables managées Unity Catalog | Taille de seuil pour d’autres tables Delta |
---|---|---|
1 | 64 Mo | 256 octets |
2 | 256 octets | 1 Go |
3 | 512 Mo | 2 Go |
4 | 1 Go | 4 Go |
É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.
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.
Pour déclencher le clustering, vous devez utiliser Databricks Runtime 13.3 LTS ou version ultérieure. Utilisez la commande OPTIMIZE
sur votre table, comme dans l’exemple suivant :
OPTIMIZE table_name;
Le clustering liquide est incrémentiel, ce qui signifie que les données ne sont réécrites que si nécessaire pour prendre en charge les données qui doivent être mises en cluster. Les fichiers de données avec des clés de clustering qui ne correspondent pas aux données à mettre en cluster ne sont pas réécrites.
Pour de meilleures performances, Databricks recommande de planifier des travaux OPTIMIZE
réguliers sur les données en 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 clustering liquide est incrémentiel, la plupart des travaux OPTIMIZE
pour les tables en cluster s’exécutent rapidement.
Lire les données d’une table en cluster
Vous pouvez lire des données dans une table en cluster à l’aide de n’importe quel client Delta Lake qui prend en charge la lecture des vecteurs de suppression. Pour obtenir de meilleurs résultats de requête, incluez les clés de clustering dans vos filtres de requête, comme dans l’exemple suivant :
SELECT * FROM table_name WHERE cluster_key_column_name = "some_value";
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.
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 de clés de clustering sur NONE
ne réécrit pas les données qui ont déjà été mises en cluster, mais empêche les opérations OPTIMIZE
futures d’utiliser des clés de clustering.
Voir comment la table est mise en cluster
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;
Compatibilité pour les tables avec le clustering liquide
Les tables créées avec le clustering liquide dans Databricks Runtime 14.1 et versions ultérieures utilisent des points de contrôle v2 par défaut. Vous pouvez lire et écrire des tables avec des points de contrôle v2 dans Databricks Runtime 13.3 LTS et versions ultérieures.
Vous pouvez désactiver les points de contrôle v2 et rétrograder les protocoles de table pour lire des tables avec le clustering liquide dans Databricks Runtime 12.2 LTS et versions ultérieures. Consultez l’article Supprimer des fonctionnalités de table Delta.
Limites
Les limites suivantes existent :
- Dans Databricks Runtime 15.1 et versions inférieures, le clustering en écriture ne prend pas en charge les requêtes sources qui incluent des filtres, des jointures ou des agrégations.
- Les charges de travail de Structured Streaming ne prennent pas en charge le clustering en écriture.
- Vous ne pouvez pas créer une table avec un clustering liquide activé à l’aide d’une écriture de streaming structuré. Vous pouvez utiliser le streaming structuré pour écrire des données dans une table existante avec clustering liquide activé.