Le Liquid Clustering est une technique de gestion des données au sein de Delta Lake, une plateforme conçue pour résoudre les défis posés par les approches traditionnelles de partitionnement et de clustering. Au lieu d’exiger des ajustements manuels constants de la disposition des données, le Liquid Clustering optimise automatiquement la manière dont les données sont stockées, améliorant ainsi la performance des requêtes.
Contrairement au partitionnement statique ou au Z-Ordering, qui nécessitent de définir à l’avance la manière dont les données seront séparées, le Liquid Clustering est flexible. Il permet de définir et de redéfinir les colonnes de clustering selon les besoins, sans avoir à réécrire les données déjà stockées. Cela signifie que la disposition physique des données peut évoluer avec les besoins analytiques au fil du temps, ce qui est impractical avec le partitionnement standard. En pratique, il s’agit d’une optimisation prête à l’emploi qui simplifie considérablement les décisions d’organisation des données et augmente les performances dans les scénarios de traitement de grands volumes de données.
Comment le Liquid Clustering se différencie-t-il des autres techniques de clustering ?
le Liquid Clustering remplace le partitionnement Hive-style et le Z-Ordering comme méthodes d’optimisation de la disposition des données, offrant une approche plus adaptable pour maintenir les données organisées.
Dans le partitionnement Hive, une colonne (ou un ensemble de colonnes) est choisie pour diviser physiquement les données en répertoires séparés. Bien que cela améliore les requêtes filtrées par cette colonne, cela entraîne plusieurs limitations. Il est nécessaire de bien choisir la colonne de partition : si elle est trop large (cardinalité élevée), elle génère des milliers de petits fichiers ; si elle est trop générale (cardinalité faible), elle produit des fichiers trop volumineux. De plus, une fois la table partitionnée, changer la clé de partition signifie refaire tout le stockage, ce qui est coûteux et complexe.
Avec le Liquid Clustering, ces restrictions disparaissent.Il est possible de choisir des colonnes de haute cardinalité sans pénalité, et même plusieurs colonnes à regrouper, en se concentrant uniquement sur les modèles d’accès des requêtes, sans se soucier de la cardinalité, de l’ordre des clés, de la taille des fichiers ou du skew (biais). Par exemple, il est possible d’utiliser une colonne d’horodatage très distincte comme clé de cluster, ce qui est impossible pour le partitionnement traditionnel.
Une autre différence fondamentale est la flexibilité pour modifier les colonnes de clustering. Si les requêtes filtrent par un champ différent (par exemple, l’ajout d’une colonne « client » dans les recherches), il est possible de simplement modifier les clés de cluster de la table, et les nouvelles données seront organisées selon la nouvelle clé, sans qu’il soit nécessaire de réécrire les anciennes données. Comparé au partitionnement fixe, le Liquid Clustering offre plus d’adaptabilité et de simplicité dans la définition de la manière dont les données doivent être regroupées.
Différences par rapport au Z-Ordering
Le Z-Ordering est une technique de Delta Lake pour ordonner les enregistrements en fonction de plusieurs colonnes,en plaçant les valeurs similaires à proximité dans un espace multidimensionnel. Bien que le Z-Order améliore l’efficacité de la lecture dans les requêtes qui filtrent plusieurs colonnes, il présente des inconvénients opérationnels : il n’est pas incrémentiel (il faut exécuter une commande OPTIMIZE ZORDER BY qui réordonne de grands volumes de données de temps en temps) et il n’agit pas au moment de l’écriture. les données nouvellement insérées ne sont pas immédiatement bien organisées tant que l’optimisation n’est pas exécutée. Cela implique une forte amplification de l’écriture et des tâches d’optimisation coûteuses en termes de temps et de calcul.
En pratique, maintenir une table optimisée via Z-Order peut augmenter le temps de chargement des données et nécessiter la planification régulière de tâches lourdes. De plus, Z-Order ne peut pas optimiser globalement l’ensemble des données lorsque les insertions sont incrémentales (il gère des sections à chaque exécution), ce qui peut laisser des données moins bien regroupées jusqu’à la prochaine exécution complète.
Le liquid Clustering élimine ces inconvénients. Il fonctionne de manière incrémentale et continue, appliquant le clustering pendant l’écriture de nouvelles données (clustering-on-wriet) et également dans des tâches d’optimisation plus légères. Cela réduit considérablement la nécessité de réordonner massivement les données. Des tests ont montré que l’écriture dans des tables avec Liquid Clustering est jusqu’à 7 fois plus rapide que dans des tables utilisant la partition + Z-Order, grâce à la réduction de la surcharge de réarrangement. Contrairement au Z-Order, qui doit être ajusté manuellement pour les nouvelles colonnes, le Liquid Clustering permet de modifier ou d’ajouter facilement des clés de regroupement et peut même choisir automatiquement les colonnes idéales (une fonctionnalité appelée Auto Clustering) en fonction de l’évolution du modèle de requêtes, en utilisant l’intelligence de la plateforme.
comparé au Z-ordering, le Liquid Clustering offre une maintenance beaucoup plus simple et efficace, car il est incrémentiel, et atteint des performances de lecture égales ou supérieures en consommant beaucoup moins de ressources.
Avantages du Liquid Clustering dans le traitement des données
L’adoption du Liquid Clustering dans les pipelines de données massifs apporte plusieurs avantages concrets en termes de performances et de maintenabilité.
Performance de lecture accélérée : En maintenant les données ordonnées en fonction des colonnes filtrées dans les requêtes, le Liquid Clustering améliore l’efficacité du scan et le data skipping. De nombreuses requêtes finissent par lire beaucoup moins de données qu’elles ne le feraient sans ce regroupement. Des gains significatifs en performance de requêtes de lecture ont été rapportés lors de la migration vers Liquid Clustering,par rapport aux techniques traditionnelles.
Vitesse et coût d’écriture réduits : Contrairement au Z-Order, qui introduit beaucoup de surcharge dans les écritures, le Liquid Clustering a une faible amplification d’écriture. Il effectue le regroupement de manière incrémentale et optimisée, évitant les opérations redondantes sur les données déjà écrites. Les tests montrent que les tables avec Liquid Clustering peuvent ingérer des données jusqu’à 7 fois plus rapidement qu’en utilisant la partition + Z-Order traditionnelles. Cela signifie qu’il est possible d’insérer de grands volumes de données en continu avec moins d’impact sur le débit. Moins de temps passé à réorganiser les données implique également une réduction des coûts de calcul pour maintenir la table optimisée.
Flexibilité et adaptation aux requêtes : L’un des avantages les plus notables est la liberté de modifier le schéma de clustering selon les besoins,sans pénalités sévères. Si les modèles d’accès aux données changent (par exemple,de nouvelles questions nécessitant des filtres par d’autres colonnes),il est possible d’ajuster les colonnes de regroupement et de laisser la disposition des données s’adapter progressivement à ces nouvelles demandes. Il n’est plus nécessaire de recréer des tables ou d’effectuer des opérations de maintenance coûteuses pour prendre en charge un nouveau type de requête. Cette flexibilité rend l’environnement plus agile pour répondre aux exigences en évolution.
Simplicité opérationnelle (moins de maintenance) : Le Liquid Clustering simplifie le travail en réduisant ou en éliminant les étapes d’optimisation manuelle. Il n’est pas nécessaire de deviner la partition idéale ou de planifier des routines complexes de Z-Ordering : la plateforme gère automatiquement une grande partie de cela. Il n’y a aucun risque de choisir de mauvaises colonnes de partition et de se retrouver avec des milliers de fichiers ou de devoir créer des colonnes dérivées artificiellement pour contourner les cardinalités élevées. Au lieu de diverses configurations et réglages, il suffit d’activer le clustering et de laisser la plateforme s’occuper de la disposition optimale. La simplicité et les performances « hors de la boîte » apportées par cette fonctionnalité sont appréciées.
Meilleure gestion des hautes cardinalités et du skew : Les colonnes avec des valeurs très distinctes (par exemple,les identifiants d’utilisateurs,les horodatages détaillés) peuvent être utilisées directement comme clé de cluster. le moteur de clustering est résistant au skew : il gère bien la distribution inégale des données, produisant des fichiers de taille cohérente et évitant d’agglomérer tout d’un seul côté ou de générer trop de fragments. Cela contraste avec le partitionnement traditionnel, où les données très concentrées sur une valeur génèrent des partitions déséquilibrées. Avec le Liquid Clustering, même les tables avec une distribution très irrégulière peuvent atteindre une disposition équilibrée de manière automatique.
Concurrence d’écriture améliorée : Dans l’ancien modèle, l’utilisation de partitions était un moyen de permettre à plusieurs rédacteurs sans conflits (chaque tâche écrit dans des partitions différentes).Cependant, cela limitait les colonnes qui pouvaient partitionner la table. Désormais, la plateforme avec Liquid Clustering prend en charge la concurrence au niveau des lignes (row-level concurrency) grâce à des avancées telles que les deletion vectors. En termes pratiques, plusieurs transactions peuvent écrire dans la même table simultanément sans avoir à séparer par partition. Il n’est donc plus nécessaire d’architecturer le partitionnement en pensant à éviter les conflits d’écriture : il est possible de définir les clés de cluster uniquement en fonction des avantages de la lecture. cette fonctionnalité augmente le taux d’ingestion simultanée et simplifie la conception de pipelines de données concurrents.
Meilleures pratiques
*Ne pas mélanger avec le partitionnement/Z-Order actifs :
Le Liquid Clustering se différencie des autres techniques de clustering, notamment le partitionnement Hive et le Z-Ordering, par sa flexibilité et son approche incrémentale.
Contrairement au partitionnement Hive, qui divise physiquement les données en répertoires basés sur une ou plusieurs colonnes choisies à l’avance, le Liquid Clustering s’adapte dynamiquement aux modèles d’accès des requêtes. Il permet d’utiliser des colonnes de haute cardinalité sans pénalité, et même plusieurs colonnes simultanément, sans se soucier de la cardinalité, de l’ordre des clés, de la taille des fichiers ou du skew. Modifier les colonnes de clustering est également possible sans réécriture des données existantes, contrairement au partitionnement Hive où un changement de clé de partition implique une reconstruction complète du stockage.
Comparé au Z-Ordering, qui ordonne les enregistrements selon plusieurs colonnes mais nécessite des opérations d’optimisation (OPTIMIZE ZORDER BY) coûteuses et non incrémentales, le Liquid Clustering fonctionne de manière incrémentale et continue, optimisant la disposition des données pendant l’écriture (clustering-on-write) et lors de tâches d’optimisation plus légères. Cela se traduit par une vitesse d’écriture jusqu’à 7 fois plus rapide que le partitionnement + Z-Order,et une maintenance beaucoup plus simple. De plus, le Liquid Clustering peut automatiquement choisir les colonnes de clustering idéales (Auto Clustering) en fonction de l’évolution des requêtes.