Appliquer le liquid clustering aux tables Delta

Le clustering liquide est une stratégie de disposition de données flexible pour les tables Delta dans Microsoft Fabric. Il remplace le partitionnement statique de style Hive et la maintenance manuelle de Z-Order par un clustering déclaratif et convivial. Vous définissez les colonnes sur lesquelles le cluster est activé et le runtime Fabric Spark gère automatiquement la disposition des données physiques.

Utilisez cet article pour :

  • Découvrez comment fonctionne le clustering liquide et quand l’utiliser.
  • Comparez le clustering liquide au partitionnement et à L’ordre Z.
  • Configurez le clustering sur vos tables.
  • Comprendre le clustering liquide incrémentiel (Runtime 2.0+).
  • Paramétrez le comportement de clustering avec les configurations de session.

Qu’est-ce que le clustering liquide ?

Le liquid clustering organise les données dans les fichiers d’une table Delta afin que les lignes présentant des valeurs similaires dans les colonnes de clustering soient regroupées. L’organisation permet une meilleure sélection des fichiers à lire pendant l’exécution de la requête : lorsqu’une requête filtre sur les colonnes de clustering, le moteur lit uniquement les fichiers dont les plages de valeurs correspondent au prédicat, en ignorant les autres.

Contrairement au partitionnement, regroupement liquide :

  • Ne crée pas de structures de répertoires physiques par valeur de colonne.
  • Ne vous oblige pas à choisir des colonnes de clustering au moment de la création de table (elles peuvent être modifiées ultérieurement).
  • Gère les colonnes à forte cardinalité sans créer de problèmes potentiels de fichiers de petite taille dus à des milliers de très petites partitions.
  • Applique l’optimisation de la disposition pendant OPTIMIZE, et non au moment de l’écriture.

Avantages par rapport au partitionnement et au Z-Order

Le clustering liquide offre des avantages significatifs sur le partitionnement de style Hive et Z-Order en termes de flexibilité, de maintenance et de gestion des modèles de données en évolution.

Comparé au partitionnement de type Hive

Aspect Partitionnement de style Hive Regroupement de liquide
Granularité Un répertoire par valeur distincte (ou combinaison) Plages de valeurs au niveau du fichier, aucun répertoire
Cardinalité élevée Crée des milliers de petits fichiers/répertoires Gère cela naturellement ; répartit les données dans des fichiers de taille adaptée
Modifications des colonnes Nécessite une réécriture complète de table ALTER TABLE ... CLUSTER BY s’applique à la prochaine OPTIMIZE
Chemin d’écriture La colonne de partition doit être connue au moment de l’écriture N’importe quelle colonne peut être clusterisée a posteriori.
Problème de petit fichier Fréquents avec la diffusion en continu ou les insertions fréquentes Géré par OPTIMIZE compactage

Comparé à Z-Order

Aspect Ordre Z Regroupement de liquide
Modifications des colonnes Doit être réexécuté OPTIMIZE ZORDER BY (...) avec de nouvelles colonnes ALTER TABLE ... CLUSTER BY conserve la définition
Prise en charge progressive Aucun mode incrémentiel ; utiliser WHERE pour limiter l’étendue manuellement Le mode incrémentiel (Runtime 2.0+) traite uniquement les fichiers nouveaux, modifiés ou défectueux automatiquement
Metadata Aucune définition de colonne persistante Colonnes de clustering stockées dans les métadonnées de table
Disposition à plusieurs colonnes Courbe Z-Order appliquée au moment de l’optimisation Ordre Z pour une colonne de clustering ; courbe de Hilbert pour 2 colonnes ou plus, offrant une localité des données optimisée

Le clustering liquide utilise Z-Order pour les configurations à une seule colonne et la courbe de Hilbert pour les configurations à deux colonnes ou plus, ce qui constitue une amélioration par rapport à Z-Order, qui n’utilise que la courbe Z-Order pour le clustering multidimensionnel. Le clustering liquide encapsule les deux algorithmes dans une infrastructure incrémentielle prenant en charge les métadonnées qui réduit le coût de maintenance continu.

Créer une table en cluster liquide

Définissez des colonnes de clustering à l’aide de la clause CLUSTER BY lors de la création de la table :

-- Create a new clustered table
CREATE TABLE dbo.sales (
    order_id BIGINT,
    order_date DATE,
    region STRING,
    amount DECIMAL(10,2)
) CLUSTER BY (order_date, region);

-- Create from query results
CREATE TABLE dbo.sales_clustered
CLUSTER BY (order_date, region)
AS SELECT * FROM raw_sales;

-- Enable on existing table
ALTER TABLE dbo.sales_txn CLUSTER BY (order_date, region);

Modifier les colonnes de clustering

Contrairement au partitionnement, vous pouvez modifier les colonnes de clustering à tout moment sans réécrire des données :

-- Change clustering columns
ALTER TABLE sales CLUSTER BY (region, product_category);

-- Remove clustering (table becomes unclustered)
ALTER TABLE sales CLUSTER BY NONE;

Après avoir modifié les colonnes de clustering, la nouvelle disposition s’applique à l’exécution suivante OPTIMIZE . Les fichiers existants conservent leur disposition antérieure jusqu’à ce qu’ils soient reclusterisés.

Appliquer le clustering avec OPTIMIZE

Le clustering est appliqué pendant la OPTIMIZE commande. Il n’est pas nécessaire de spécifier des colonnes dans l’instruction OPTIMIZE , car la définition de clustering est stockée dans les métadonnées de table :

-- Cluster the table using the defined clustering columns
OPTIMIZE sales;

-- Recluster partial Z-Cubes and Z-Cubes with different clustering keys or clustering providers
OPTIMIZE sales FULL;

Utilisez OPTIMIZE FULL quand vous modifiez les clés de clustering et souhaitez reconstruire Z-Cubes qui ne respectent pas la stratégie de clustering actuelle. Un Z-Cube est l’unité logique que le clustering liquide utilise pour regrouper les fichiers qui partagent les mêmes colonnes de clustering. Les données sont regroupées en un seul cube Z jusqu’à ce que les clés de cluster changent ou que la quantité de données dépasse 100 Go.

Tip

À compter de Fabric Runtime 2.0, le moteur d’exécution Native prend en charge l’exécution de OPTIMIZE sur des tables à clustering liquide, offrant des performances de clustering multidimensionnel 30 à 50 % plus rapides. Les versions antérieures du runtime repassent à l’exécution Spark standard non accélérée.

Fonctionnement du clustering liquide

Lorsque vous exécutez OPTIMIZE sur une table à clustering liquide, voici ce qui se passe :

  1. Sélection de fichiers : le moteur sélectionne les fichiers qui ont besoin d’un clustering.
    • Dans Runtime 2.0+ (stratégie de clustering incrémentielle), seuls les fichiers non clusterisés, défectueux, de petite taille ou avec vecteurs de suppression sont sélectionnés.
    • Dans Runtime 1.3, tous les fichiers dans chaque Z-Cube de moins de 100 Go sont sélectionnés, qu’ils soient déjà bien regroupés ou non.
  2. Empaquetage des compartiments : les fichiers sélectionnés sont regroupés en compartiments ciblant une taille de fichier de sortie optimale.
  3. Repartitionnement : les données de chaque bac sont repartitionnée à l’aide d’une courbe de remplissage d’espace (courbe Hilbert pour plusieurs colonnes, Z-Order pour une seule colonne).
  4. Écriture des fichiers : les données repartitionnées sont écrites dans de nouveaux fichiers avec des plages de valeurs étroites sur les colonnes de clustering.
  5. Mise à jour des métadonnées : le journal Delta enregistre le remplacement du fichier, en balisant les nouveaux fichiers avec les métadonnées de clustering.

Le résultat est des fichiers avec des plages de valeurs qui ne se chevauchent pas (ou se chevauchent minimalement) sur les colonnes de clustering, ce qui permet au moteur d’ignorer les fichiers qui ne correspondent pas aux prédicats de requête.

Avertissement

Fabric Runtime 1.3 (Delta 3.2) : utilisez le clustering liquide avec prudence. Dans ce runtime, le clustering liquide utilise une stratégie complète de réécriture Z-Cube : chaque fichier d’un cube Z est réécrit lors de chaque exécution. Un cube Z est conservé (ignoré) uniquement lorsque sa taille dépasse 100 Go. Pour les tables de moins de 100 Go, la réécriture complète signifie que chaque OPTIMIZE exécution réécrit l’ensemble des données de la table, même lorsque les données sont déjà bien regroupées. Cela provoque une amplification d’écriture grave.

  • N’utilisez pas le compactage automatique avec le clustering liquide dans Runtime 1.3. Chaque déclencheur de compactage automatique peut entraîner une réécriture complète de table au lieu de simplement clusteriser les données nouvelles/modifiées.
  • Évitez d’exécuter OPTIMIZE après chaque opération d’écriture. Dans Runtime 1.3, limiter le clustering à des lancements stratégiques et intentionnels, et accepter une fraîcheur du clustering moindre entre ces lancements.

Le clustering liquide incrémentiel, qui élimine cette amplification d’écriture, n’est disponible qu’à partir de Fabric Runtime 2.0.

Regroupement fluide incrémentiel

À compter de Fabric Runtime 2.0 (Delta 4.1), le clustering liquide utilise une stratégie de clustering incremental par défaut. La stratégie incrémentielle est une amélioration significative du comportement de clustering standard.

Important

Le clustering liquide incrémentiel n’est disponible que dans Fabric Runtime 2.0 et les versions ultérieures. Dans les runtimes antérieurs, OPTIMIZE utilise le comportement standard (réécriture complète) où tous les fichiers d’un cube Z sont réécrits à chaque exécution.

Pourquoi la stratégie de clustering incrémentielle est importante

L’algorithme de clustering standard réécrit tous les fichiers au sein d’un Z-Cube (jusqu’à 100 Go) sur chaque OPTIMIZE exécution, qu’ils soient déjà correctement clusterés. Pour une table recevant de petits ajouts, le coût de clustering augmente linéairement avec la taille de la table, et non avec la quantité de nouvelles données.

Le mode incrémentiel résout le problème de réécriture complète en sélectionnant uniquement les fichiers qui ont réellement besoin d’un clustering :

  • Fichiers non regroupés: données nouvellement enregistrées sans métadonnées de regroupement
  • Petits fichiers : fichiers sous le seuil de taille de fichier cible
  • Fichiers avec vecteurs de suppression : fichiers avec suppressions cumulées dépassant le seuil de nettoyage

Les fichiers déjà bien regroupés et de taille adéquate sont entièrement ignorés.

Recluster automatiquement

Le regroupement liquide incrémentiel inclut la détection automatique des chevauchements, appelée reclustering automatique, afin de maintenir la qualité du regroupement au fil du temps. À mesure que de nouvelles données arrivent, elles peuvent entraîner un chevauchement entre les plages de valeurs des fichiers, ce qui réduit l’efficacité du saut de données. La reclustation automatique détecte les plages de valeurs qui se chevauchent entre les fichiers et reclustent sélectivement uniquement les fichiers affectés.

La reclustation automatique s’exécute automatiquement dans le cadre de OPTIMIZE chaque fois qu’il y a des données nouvelles ou modifiées en cluster. Aucune intervention manuelle ni aucune reclusterisation complète planifiée ne sont nécessaires. La stratégie de clustering incrémentielle maintient une qualité de clustering quasi optimale à mesure que les données évoluent.

Rétablir le comportement de réécriture complète

Si vous devez désactiver la stratégie de clustering incrémentielle et utiliser le comportement de réécriture complète, définissez la configuration suivante :

SET spark.microsoft.delta.optimize.clustering.strategy.incremental = FALSE;

OPTIMIZE sales;

Vous pouvez également l’utiliser OPTIMIZE FULL pour un reclusteur complet à usage unique sans modifier les paramètres de session :

OPTIMIZE sales FULL;

Note

La stratégie de clustering incrémentielle permet intentionnellement un écart mineur de la disposition théoriquement optimale pour obtenir des réductions significatives de l’amplification d’écriture. L’exécution de OPTIMIZE FULL comble cet écart en reconstruisant entièrement les Z-Cubes jusqu’à leur optimum théorique, mais à un coût d’écriture plus élevé.

Référence de configuration

Les configurations de session suivantes contrôlent le comportement de clustering liquide dans Fabric Runtime 2.0+.

Regroupement incrémental

Configuration Type Default Description
spark.microsoft.delta.optimize.clustering.strategy.incremental Boolean true Commutateur principal pour le clustering incrémentiel. Lorsque true, OPTIMIZE traite uniquement les fichiers non clusterisés, non intègres, de petite taille et à vecteur de suppression. Quand false, tous les fichiers pour Z-Cubes de moins de 100 Go de taille sont réécrits (comportement standard).
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster Boolean true Permet la détection automatique et la reclustation de fichiers avec des plages de données qui se chevauchent. S’applique uniquement lorsque le clustering incrémentiel est activé.

Réglage automatique de recluster

Ces configurations contrôlent la sensibilité et la portée du reclustering automatique. Les valeurs par défaut conviennent à la plupart des charges de travail. Ajustez-les uniquement lorsque vous devez modifier le compromis entre la qualité de clustering et l’amplification d’écriture.

Configuration Type Default Description
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles Int 4 Nombre minimal de fichiers qui se chevauchent pour déclencher la reclustation. Les valeurs plus faibles sont reclassées plus tôt (meilleures performances des requêtes, coût d’écriture plus élevé). Doit être ≥ 2.
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold Double 0.75 Seuil du score de chevauchement des dimensions de regroupement. Les paires de fichiers dont le score est supérieur à cette valeur sont considérées comme se chevauchant. Doit être compris dans l’intervalle (0,25, 1,0]. Les valeurs inférieures sont plus agressives.

Choix des colonnes de clustering

Pour obtenir de meilleurs résultats, choisissez des colonnes de clustering en fonction de vos modèles de filtre de requête les plus courants :

  • Choisissez 1 à 4 colonnes qui apparaissent fréquemment dans WHERE les clauses. Un plus grand nombre de colonnes réduit l’efficacité du saut de fichiers par colonne permis par la courbe de remplissage de l’espace et augmente le temps nécessaire au clustering des données.
  • Considérez la cardinalité des colonnes. Les colonnes à faible cardinalité produisent moins de plages de valeurs distinctes, ce qui réduit le bénéfice du saut de fichiers lorsqu’elles sont associées à des clés de clustering à cardinalité élevée.
  • L’ordre des colonnes n’a aucun impact sur le clustering. L’ordre des colonnes spécifiées après CLUSTER BY n’a aucun impact sur le clustering multidimensionnel résultant.

Types de colonne pris en charge

Tous les types de colonnes ne peuvent pas être utilisés comme clés de clustering. Le moteur évalue le type de données de chaque colonne pour déterminer l’éligibilité.

Toujours éligibles (types atomiques) :

  • NumericType (ByteType, ShortType, IntegerType, LongType, FloatType, DoubleType, DecimalType)
  • DateType
  • TimestampType
  • TimestampNTZType
  • StringType

Éligible de manière conditionnelle :

Note

Les types suivants peuvent être activés à partir de Fabric Spark Runtime 2.0 (Delta 4.1)

  • StructType: lorsqu’il spark.microsoft.delta.clusteredTable.complexTypes.enabled est activé et que tous les champs feuilles sont eux-mêmes des types éligibles.
  • ArrayType: lorsqu’il spark.microsoft.delta.clusteredTable.complexTypes.enabled est activé et que le type d’élément est éligible.
  • MapType : lorsque spark.microsoft.delta.clusteredTable.complexTypes.enabled est activé et que les types de clé et de valeur sont ordonnables et admissibles.

Non éligible :

  • BinaryType
  • BooleanType
  • NullType

Pour connaître les types éligibles équivalents utilisés dans les statistiques au niveau du fichier, consultez L’option Ignorer les fichiers : types de données éligibles.

Interaction avec d’autres fonctionnalités

Fonctionnalité Behavior
Partitionnement Incompatible. Pour l’évitement de lecture de fichiers, le clustering liquide est recommandé plutôt que le partitionnement.
Z-Order Incompatible. À des fins d’skipping de fichier, le clustering liquide est recommandé sur Z-Order.
Optimisation rapide Compatible à partir du runtime 2.0. Dans les runtimes précédents, l’optimisation rapide n’a aucun effet sur les tables en cluster liquides. Pendant OPTIMIZE, ignore le clustering lorsqu’il n’y a pas assez de petits fichiers ou de données insuffisantes pour produire un fichier de sortie de taille saine.
Taille de fichier cible adaptative Compatible. La taille de fichier cible définie par l’évaluation adaptative est utilisée comme taille cible pour le clustering.
Optimiser l’écriture Compatible. Produit des fichiers consolidés lors de l’écriture, qui sont ensuite regroupés lors de OPTIMIZE.
Compactage automatique N’utilisez pas le clustering liquide dans Runtime 1.3 ou version antérieure. Dans ces environnements d’exécution, chaque déclenchement de la compaction automatique réécrit toutes les données dans les Z-Cubes de moins de 100 Go, entraînant une forte amplification des écritures. Dans Runtime 2.0+, le compactage automatique est compatible : le clustering incrémentiel garantit que seuls les fichiers nouveaux ou défectueux sont réécrits. Le compactage automatique gère la consolidation des petits fichiers ; OPTIMIZE gère l’organisation du clustering.
Vecteurs de suppression Les fichiers dépassant le seuil des lignes supprimées sont sélectionnés pour le clustering, indépendamment de leur état de clustering.
V-Order Compatible. Le clustering V-Order et liquid fonctionnent sur différents axes (disposition interne de fichier et plages de valeurs entre fichiers). Les deux peuvent être appliqués ensemble.

Bonnes pratiques

  • Exécutez OPTIMIZE régulièrement après les écritures par lots ou selon une planification pour les tables de diffusion en continu, mais uniquement dans Runtime 2.0+, où la stratégie de clustering incrémentielle rend les exécutions fréquentes peu coûteuses. Dans runtime 1.3 et versions antérieures, chaque OPTIMIZE exécution réécrit toutes les données dans Z-Cubes sous 100 Go. Les exécutions doivent donc être intentionnelles et peu fréquentes.
  • Utilisez OPTIMIZE FULL avec parcimonie. Utilisez-la uniquement après avoir modifié les colonnes de clustering ou lorsque vous avez besoin d’une réinitialisation ponctuelle de la qualité.
  • Surveillez la qualité du clustering en vérifiant les métriques d’analyse des requêtes (fichiers analysés par rapport au nombre total de fichiers) dans l’interface utilisateur Spark ou les plans de requête.
  • Combinez avec l’optimisation des écritures pour les charges de travail de streaming afin de garantir que chaque micro-lot produise un nombre de fichiers raisonnable pour le clustering.

Contenu connexe

  • Last updated on