CLUSTER BY AUTO dans Databricks : arrêtez de choisir les clés de clustering à la main

Pendant des années, optimiser la disposition physique d'une table dans le lakehouse était une tâche artisanale : vous regardiez les requêtes les plus fréquentes, décidiez sur quelles colonnes les données étaient le plus filtrées, appliquiez PARTITIONED BY ou ZORDER, et reveniez des mois plus tard pour réajuster quand le motif d'accès changeait. Ça marchait — mais c'était une décision qui vieillissait et devenait une dette technique silencieuse.

L'Automatic Liquid Clustering, déclenché par le mot-clé CLUSTER BY AUTO, change la donne : Databricks lui-même se met à choisir et à maintenir les clés de clustering des tables gérées d'Unity Catalog, sans intervention manuelle.

Un pas en arrière : partitionnement, ZORDER et Liquid Clustering

Pour comprendre l'AUTO, il vaut la peine de rappeler l'évolution :

• Le partitionnement (PARTITIONED BY) répartit les données en dossiers par valeur de colonne. Excellent en théorie, mais facile à rater : une cardinalité élevée provoque le problème des « small files » ; une cardinalité faible n'aide pas au pruning. Et le choix est rigide — le changer exige de réécrire la table.
• ZORDER réorganise les données à l'intérieur des fichiers sur plusieurs colonnes, améliorant le data skipping. Sauf qu'il tourne dans OPTIMIZE et doit être maintenu à la main.
• Le Liquid Clustering remplace les deux. Il est flexible (vous changez les clés sans réécrire la table), gère bien le skew et les colonnes à forte cardinalité, et évite le problème des petits fichiers.

CLUSTER BY AUTO est l'étape suivante : au lieu que vous indiquiez les colonnes du Liquid Clustering, le moteur décide pour vous.

Ce que fait CLUSTER BY AUTO

En marquant une table gérée d'Unity Catalog avec CLUSTER BY AUTO, vous déléguez la sélection des clés au Predictive Optimization. Il :

1. Analyse l'historique réel des requêtes sur la table (quelles colonnes apparaissent dans les filtres et les jointures).
2. Sélectionne les clés de clustering les plus efficaces pour cette charge.
3. Maintient la table tout seul, en exécutant OPTIMIZE, VACUUM et ANALYZE automatiquement.
4. Réadapte les clés au fil du temps — si le motif d'accès change, le clustering suit.

Autrement dit : l'optimisation cesse d'être un événement ponctuel pour devenir un processus continu et géré.

Comment l'utiliser — les 3 étapes

1. Nouvelle table

CREATE TABLE sales (
  id BIGINT,
  ts TIMESTAMP
)
CLUSTER BY AUTO;

2. Une table existante (non partitionnée ou déjà en Liquid)

ALTER TABLE sales CLUSTER BY AUTO;

3. Convertir une table partitionnée

Pour migrer une table partitionnée vers le clustering automatique à partir de ses colonnes de partition actuelles :

ALTER TABLE sales REPLACE PARTITIONED BY WITH CLUSTER BY AUTO;

Après cela, vous n'avez plus besoin d'appeler OPTIMIZE à la main — le Predictive Optimization s'occupe de la maintenance.

Prérequis

• Databricks Runtime 15.4 LTS ou supérieur.
• Une table gérée dans Unity Catalog (managed table) — Delta Lake ou Iceberg géré.
• Predictive Optimization activé (activé par défaut sur les nouveaux comptes ; le déploiement vers les comptes existants s'est achevé au cours de 2026).

Pour confirmer que l'AUTO est actif :

DESCRIBE DETAIL sales;      -- observez clusteringColumns
SHOW TBLPROPERTIES sales;   -- clusterByAuto = true

Les clusteringColumns peuvent changer avec le temps — c'est attendu, et c'est précisément le mécanisme de réadaptation en action.

Quand l'utiliser — et quand NE PAS l'utiliser

Bons cas pour l'AUTO :

• Tables gérées moyennes et grandes avec des motifs de requête qui évoluent.
• Équipes qui ne veulent pas (ou n'ont pas le temps de) maintenir des stratégies de ZORDER/partition à la main.
• Tables où la clé « évidente » d'hier ne correspond plus aux filtres d'aujourd'hui.

Cas où ça ne vaut peut-être pas la peine :

• Très petites tables, où le data skipping a peu d'impact — le coût de maintenance ne se rentabilise pas.
• Tables avec un partitionnement déjà bien défini et stable, où le gain marginal est faible.
• Scénarios avec des exigences réglementaires de disposition physique spécifique (ex. : purge par partition de date), où vous avez besoin d'un contrôle explicite.

Dans ces cas, vous pouvez encore utiliser le Liquid Clustering avec des clés fixes (CLUSTER BY (colonne)) au lieu de l'AUTO.

Comment surveiller

• Suivez l'évolution des clusteringColumns via DESCRIBE DETAIL.
• Vérifiez l'historique des opérations de maintenance (les exécutions d'OPTIMIZE/VACUUM déclenchées par le Predictive Optimization) pour comprendre fréquence et coût.
• Comparez les temps de requête et le volume de données lu (data skipping) avant et après l'activation de l'AUTO — c'est la métrique qui compte vraiment.

Conclusion

CLUSTER BY AUTO retire à l'ingénieur des données une décision qui a toujours été un pari éclairé et la transforme en un processus gouverné et adaptatif. Le résultat pratique est double : moins de maintenance manuelle et moins de dette technique de disposition physique — parce que la table n'est plus « coincée » avec la meilleure décision que vous avez pu prendre il y a six mois. Pour la plupart des tables gérées d'Unity Catalog, activer l'AUTO est une ligne de SQL au retour élevé : des lectures plus rapides et un TCO moindre, sans effort récurrent.