Concevoir et implémenter une stratégie de clustering

L’optimisation de l’organisation physique des données sur le disque affecte directement les performances des requêtes et l’efficacité du stockage. Lorsque vous concevez une stratégie de clustering pour vos tables Delta Lake, vous déterminez la façon dont le moteur de requête localise et récupère les données pertinentes. La bonne approche peut réduire considérablement la quantité de données analysées pendant les requêtes, ce qui réduit les temps de réponse et les coûts de calcul.

Azure Databricks fournit plusieurs techniques complémentaires pour l’organisation des données. Comprendre quand appliquer un clustering liquide, un ordre Z ou des vecteurs de suppression vous aide à prendre des décisions qui équilibrent les performances, les efforts de maintenance et la compatibilité avec vos tables existantes.

Comprendre les fondamentaux du saut de données

Avant d'examiner des techniques de clustering spécifiques, il est important de comprendre le mécanisme sous-jacent qu'elles exploitent toutes : le saut de données. Delta Lake collecte automatiquement des statistiques pour chaque fichier de données, y compris les valeurs minimales et maximales, les nombres null et les nombres d’enregistrements pour chaque colonne. Lorsque vous exécutez une requête avec des conditions de filtre, le moteur de requête vérifie d’abord ces statistiques et ignore les fichiers qui ne peuvent pas contenir d’enregistrements correspondants.

Par exemple, si vous interrogez des données de ventes pour janvier 2026 et que les statistiques d’un fichier particulier indiquent qu’il contient uniquement les enregistrements de mars 2026, le moteur ignore entièrement ce fichier sans lire son contenu. Cette optimisation se produit automatiquement, mais son efficacité dépend de la façon dont vos données sont organisées.

Le saut de données devient puissant lorsque les enregistrements associés sont stockés ensemble dans les mêmes fichiers. Si les enregistrements pour chaque mois sont dispersés de façon aléatoire dans tous les fichiers, le moteur ne peut ignorer aucun fichier, car chaque fichier contient des enregistrements de chaque mois. Les techniques de clustering existent pour résoudre exactement ce problème.

Mettre en œuvre le liquid clustering pour les nouvelles tables

Le clustering liquide est l’approche recommandée pour organiser les données dans de nouvelles tables Delta Lake et est également disponible en aperçu public pour les tables Apache Iceberg gérées dans Unity Catalog (Databricks Runtime 16.4 LTS et versions ultérieures). Contrairement au partitionnement traditionnel, le clustering liquide vous permet de modifier votre stratégie de clustering sans réécrire les données existantes. Cette flexibilité est précieuse lorsque les modèles de requête évoluent ou lorsque vous êtes incertain sur les colonnes qui seront filtrées le plus fréquemment.

Pour activer le clustering liquide, utilisez la clause CLUSTER BY lors de la création d’une table :

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

Vous pouvez spécifier jusqu’à quatre clés de clustering. Choisissez des colonnes qui apparaissent fréquemment dans vos filtres de requête. L’ordre des clés de clustering est inférieur à la sélection des colonnes appropriées, car le clustering liquide optimise simultanément toutes les clés spécifiées.

Après avoir créé une table en cluster, exécutez la commande pour appliquer le OPTIMIZE clustering à vos données :

OPTIMIZE sales.transactions;

Le clustering liquide est incrémentiel. Chaque OPTIMIZE cluster exécute uniquement les données qui nécessitent une réorganisation, ce qui rend la maintenance régulière efficace. Databricks recommande de planifier des jobs OPTIMIZE toutes les une ou deux heures pour les tables ayant des insertions ou des mises à jour fréquentes.

Modifier les clés de clustering si nécessaire

L’un des avantages importants du clustering liquide sur le partitionnement est la possibilité de modifier votre stratégie de clustering. Si vos modèles de requête changent, mettez à jour les clés de clustering avec une ALTER TABLE instruction :

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

Les opérations suivantes OPTIMIZE utilisent la nouvelle approche de clustering. Les données précédemment écrites ne sont pas réécrites automatiquement. Pour appliquer un nouveau clustering à toutes les données existantes, exécutez :

OPTIMIZE sales.transactions FULL;

Activer la sélection automatique de la clé de clustering

Azure Databricks peut sélectionner intelligemment des clés de clustering en fonction de vos modèles de requête réels. Le liquid clustering automatique analyse l'historique des charges de travail et choisit les colonnes qui offrent le plus grand bénéfice de saut de données :

CREATE TABLE sales.orders CLUSTER BY AUTO;

Vous pouvez activer le clustering automatique sur les tables existantes :

ALTER TABLE sales.transactions CLUSTER BY AUTO;

Le clustering liquide automatique nécessite l’activation de l’optimisation prédictive. Azure Databricks évalue régulièrement si différentes clés de clustering amélioreraient les performances et ajustent la stratégie en conséquence.

Migrer du classement Z vers le clustering liquide

L’ordre Z est une technique héritée qui organise les données pour colocaliser les informations associées dans les mêmes fichiers. Bien que le liquid clustering soit recommandé pour les nouvelles tables, vous rencontrerez des tables existantes qui utilisent le Z-ordering, et vous devez comprendre les deux approches.

L’ordre Z utilise la OPTIMIZE commande avec une ZORDER BY clause :

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

L’ordre Z diffère du clustering liquide de plusieurs façons importantes :

Lorsque vous héritez d’une table triée sur Z, vous avez deux options. Continuez à utiliser l’ordre Z pour la cohérence ou migrez vers le clustering liquide pour améliorer la flexibilité. Pour migrer, activez d'abord le liquid clustering sur la table non partitionnée existante :

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

Ensuite, exécutez une optimisation complète pour réorganiser toutes les données existantes :

OPTIMIZE sales.legacy_transactions FULL;

Gérer les vecteurs de suppression pour des mises à jour efficaces

Les vecteurs de suppression traitent un aspect différent de l’organisation des données : comment Delta Lake gère les enregistrements modifiés ou supprimés. Par défaut, lorsque vous mettez à jour ou supprimez une seule ligne dans un fichier Parquet, Delta Lake doit réécrire l’intégralité du fichier. Pour les tables avec des modifications fréquentes, cela crée une surcharge significative.

Lorsque les vecteurs de suppression sont activés, Delta Lake marque les lignes modifiées comme supprimées dans un fichier de métadonnées distinct plutôt que de réécrire immédiatement le fichier Parquet. Les lectures suivantes appliquent ces suppressions à la volée, combinant le fichier d’origine avec le vecteur de suppression pour retourner des résultats précis.

Les vecteurs de suppression sont activés par défaut pour les nouvelles tables créées avec Databricks Runtime 14.1 ou version ultérieure. Vous pouvez les activer explicitement sur les tables existantes :

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

Les vecteurs de suppression sont appliqués physiquement lorsque les fichiers de données sont réécrits pendant :

• Commande OPTIMIZE
• Déclencheurs de compactage automatique
• Une REORG TABLE ... APPLY (PURGE) opération

Pour les scénarios de conformité où vous devez vous assurer que les données supprimées sont physiquement supprimées, exécutez une REORG opération suivie de VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

Les vecteurs de suppression activent également la concurrence au niveau des lignes, ce qui permet à plusieurs transactions simultanées de modifier différentes lignes dans la même table sans conflit. Cette fonctionnalité est particulièrement utile pour les tables avec des volumes de mises à jour élevés.