Le partitionnement coupe la table en dossiers. Le clustering ordonne les lignes à l’intérieur des fichiers. Le data skipping est l’effet : grâce aux min/max (et parfois bloom filters) de chaque fichier ou row group, le moteur n’ouvre pas les objets dont la plage ne recoupe pas le filtre.
Sans ordre, une colonne client_id a, dans chaque fichier, un min proche du plus petit id mondial et un max proche du plus grand. Aucun skip possible. Après un clustering (ou un ZORDER BY client_id), chaque fichier ne couvre plus qu’une bande d’identifiants. Un WHERE client_id = 42 n’ouvre que la poignée d’objets dont la bande contient 42.
Le Z-order (Databricks / Delta) et les équivalents (Iceberg sort order, partition transforms + rewrite, Hudi clustering) étendent ça à plusieurs colonnes : on entrelace les bits des clés pour que deux lignes proches sur toutes les dimensions aient tendance à tomber dans le même fichier. Ce n’est pas magique à 12 colonnes : au-delà de deux ou trois, l’espace se dilue et le gain s’effondre.
Ce que ça ne remplace pas. Un filtre sur dt que tout le monde pose reste plus efficace en partition (on n’liste même pas les autres jours). Le clustering commence après : les colonnes qu’on filtre souvent, mais qu’on ne peut pas mettre en dossiers — haute cardinalité, ou deuxième et troisième prédicats.
Ce que ça coûte. Réécrire. OPTIMIZE ZORDER, rewrite_data_files + sort, clustering Hudi : lecture + écriture de la table (ou d’une partition). Ce n’est pas gratuit, ça se planifie, et ça contredit les petits fichiers du streaming tant qu’on n’a pas compacté. Un Z-order une fois par mois sur une table append-only à fort débit se dégrade : les nouveaux fichiers ne sont plus triés.
Ce que ça donne au plan. Moins de fichiers lus, moins de GET, des row groups dont les dictionnaires et le RLE sont plus efficaces (valeurs proches = runs plus longs). Le bénéfice se voit sur les requêtes sélectives. Un SELECT count(*) sans filtre s’en moque.
Que vous ne dites pas « Z-order = index B-tree ». Il n’y a pas d’arbre maintenu à chaque INSERT. C’est un réarrangement périodique des fichiers. Si le candidat promet des lookups à 5 ms sur un id, il vend un moteur OLTP.
La relance : « Z-order ou partition sur la même colonne ? » Si la cardinalité est basse et le filtre quasi systématique : partition. Si la cardinalité est haute : clustering. Les deux ensemble seulement si les rôles sont distincts (dt en partition, client_id en Z-order).
Deuxième relance : « liquid clustering, clustering Iceberg ? » On attend que vous sachiez que l’industrie sort du Z-order manuel : des layouts que le moteur maintient, avec des clustering keys déclarées. Le principe (ranger pour skipper) reste le même ; l’opération OPTIMIZE à la main devient un détail de plateforme.
Z-orderer sur une colonne que personne ne filtre, ou sur une colonne déjà unique par fichier (une date de partition jour, alors que chaque fichier est déjà un jour). Vous payez la réécriture pour des stats qui étaient déjà parfaites.
Autre piège : mesurer le gain juste après l’OPTIMIZE, puis oublier que 48 h de micro-lots ont dilué le layout. Un clustering sans politique de maintenance est une démo, pas une stratégie.