Clustering de données dans Fabric Data Warehouse

S’applique à :✅ Entrepôt dans Microsoft Fabric

Le clustering de données est une technique utilisée pour organiser et stocker des données en fonction de la similarité. Le clustering de données améliore les performances des requêtes et réduit les coûts d’accès au calcul et au stockage pour les requêtes en regroupant des enregistrements similaires.

Fonctionnement

Le clustering de données fonctionne en stockant des rangées avec des valeurs similaires dans des positions adjacentes sur le stockage lors de l’ingestion des données. Le clustering de données utilise une courbe de remplissage d’espace pour organiser les données d’une manière qui conserve la localité dans plusieurs dimensions, ce qui signifie que les lignes avec des valeurs similaires entre les colonnes de clustering sont stockées physiquement ensemble. Cette approche améliore considérablement les performances des requêtes en effectuant un saut de fichier et en réduisant le nombre de fichiers analysés.

Contrairement au classement lexicographique classique, le clustering de données utilise un algorithme sophistiqué pour ingérer, en conservant les lignes avec des valeurs de colonne similaires proches, même lorsqu’une table est clusterée par plusieurs colonnes. Cela rend le clustering de données idéal pour les requêtes de plage, les filtres à cardinalité élevée et les tables volumineuses avec des distributions asymétriques, ce qui entraîne des lectures plus rapides, une réduction des E/S et une utilisation plus efficace des ressources.

Voici une illustration conceptuelle simplifiée du clustering de données :

Dans ce diagramme, une table étiquetée Source data montre des lignes mêlées et mises en surbrillance avec différentes couleurs pour représenter les regroupements de destinations. Une table triée est divisée en trois segments de fichier, chaque segment regroupant des lignes par couleurs similaires, illustrant comment le regroupement organise les données en segments de stockage optimisés en fonction des valeurs de colonne.

Les métadonnées de clustering de données sont incorporées dans le manifeste pendant l’ingestion, ce qui permet au moteur d’entrepôt de prendre des décisions intelligentes sur les fichiers auxquels accéder pendant les requêtes utilisateur. Ces métadonnées, combinées à la façon dont les lignes avec des valeurs similaires sont stockées ensemble, garantissent que les requêtes avec des prédicats de filtre peuvent ignorer des fichiers et des groupes de lignes entiers qui se trouvent en dehors de l’étendue du prédicat. Par exemple : si une requête cible seulement 10% des données d’une table, le clustering garantit que seuls les fichiers qui contiennent les données de la plage du filtre sont analysés, réduisant ainsi la consommation d’E/S et de calcul. Les tables plus volumineuses bénéficient davantage du clustering de données, car les avantages de l'optimisation de l'ignorance de fichiers augmentent avec le volume de données.

Quand utiliser le clustering de données

Lorsque vous décidez si le clustering de données peut être bénéfique, examinez les modèles de requête et les caractéristiques de table dans l’entrepôt. Le clustering de données est le plus efficace lorsque les requêtes filtrent à plusieurs reprises sur des colonnes spécifiques et lorsque les tables sous-jacentes sont volumineuses et contiennent des données de cardinalité moyenne à élevée. Certains scénarios courants incluent les suivants :

Requêtes répétées avec WHERE filtres : si la charge de travail inclut des requêtes fréquentes filtrant des colonnes spécifiques, le clustering de données garantit que seuls les fichiers pertinents sont analysés pendant les requêtes en lecture. Cela s’applique également lorsque les filtres sont utilisés à plusieurs reprises dans les tableaux de bord, les rapports ou les travaux planifiés et poussés vers le moteur d’entrepôt en tant qu’instructions SQL.
Tables plus volumineuses : le clustering de données est le plus efficace lorsqu’il est appliqué à des tables volumineuses où l’analyse du jeu de données complet est coûteuse. En organisant des lignes avec le clustering de données, le moteur d’entrepôt peut ignorer des fichiers et des groupes de lignes entiers qui ne correspondent pas au filtre de requête, ce qui peut réduire l’utilisation des E/S et du calcul.
Colonnes de cardinalité moyenne à élevée : les colonnes avec une cardinalité supérieure (par exemple, les colonnes qui ont de nombreuses valeurs distinctes, telles qu’un ID ou une date) bénéficient davantage du clustering de données, car elles permettent au moteur d’isoler et de colocaliser des valeurs similaires. Cela permet de passer efficacement les fichiers, en particulier pour les requêtes sélectives. Les colonnes avec une faible cardinalité (par exemple : sexe, région) par nature ont ses valeurs réparties sur plusieurs fichiers, offrant donc des opportunités limitées pour le saut de fichier.
Requêtes sélectives avec étendue étroite : lorsque les requêtes ciblent généralement un petit sous-ensemble de données et sont combinées avec un filtre WHERE, le clustering de données garantit que seuls les fichiers contenant les lignes pertinentes sont lus.

Le clustering de données se produit automatiquement pendant l’ingestion des données, quelle que soit la façon dont les lignes ont été ingérées. Aucune opération utilisateur n’est requise une fois que les données sont ingérées pour appliquer le clustering de données.

Syntaxe CLUSTER BY

Le clustering de données est défini lors de la création de table, à l’aide de la CLUSTER BY clause. La syntaxe est la suivante :

Syntaxe CREATE TABLE (Transact-SQL) :

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name } (
 [ ,... n ] –- Column list
) WITH (CLUSTER BY [ ,... n ]);

Syntaxe CREATE TABLE AS SELECT (Transact-SQL) :

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name } (
) WITH (CLUSTER BY[ ,... n ])
AS <select_statement>;

La CLUSTER BY clause exige qu’au moins une colonne soit spécifiée pour le clustering de données et un maximum de quatre colonnes.

La création d’une table qui utilise le clustering de données avec SELECT INTO n’est pas prise en charge.

Prise en charge des types de données

Le tableau suivant récapitule les types de colonnes qui peuvent être utilisés dans la CLUSTER BY clause :

Catégorie	Type de données	Regroupement de données pris en charge
Chiffres exacts	bit	Non
Chiffres exacts	bigint, int, smallint, decimal², numeric	Oui
Nombres approximatifs	Flotte, vrai	Oui
Date et heure	date, datetime2, heure	Oui
Chaînes de caractères¹	char	Oui
Chaînes de caractères¹	varchar	Oui
Types de lignes de métier	varchar(max), varbinary(max)	Non
Cordes binaires	varbinary, uniqueidentifier	Non

¹ Pour les types de chaînes (char/varchar), seuls les 32 premiers caractères sont utilisés lorsque les statistiques de colonne sont produites. Par conséquent, les colonnes avec des valeurs qui contiennent des préfixes longs peuvent avoir des avantages limités avec le clustering de données.

^{2 Pour les} types décimaux avec une précision supérieure à 18, les prédicats ne sont pas appliqués au stockage pendant l’exécution de la requête. Si vous utilisez des types décimaux avec le clustering de données, privilégiez les colonnes avec une plus petite précision.

Les colonnes avec des types de données non pris en charge peuvent toujours exister dans une table qui utilise le clustering de données, mais qui ne peuvent pas être utilisées avec CLUSTER BY.

Meilleures pratiques avec le clustering de données

Le clustering de données est plus efficace lorsque les colonnes de clustering sont choisies en fonction des modèles de requête réels, en particulier ceux avec une cardinalité moyenne à élevée et lorsque les prédicats de plage sont utilisés pendant les requêtes.

Tenez compte des meilleures pratiques suivantes lors de l’utilisation du clustering de données :

Le clustering de données est plus efficace sur les tables volumineuses.
Dans la mesure du possible, l’ingestion par lots et les mises à jour pour traiter un plus grand nombre de lignes à la fois, plutôt que d’utiliser des tâches plus petites. Pour des performances optimales, les opérations DML doivent avoir au moins 1 million de lignes pour tirer parti du clustering de données. Après des insertions consécutives, des mises à jour et des suppressions, le compactage des données peut consolider des lignes de fichiers plus petits en fichiers de taille optimale.
Choisissez des colonnes avec une cardinalité moyenne à élevée pour le clustering de données, car elles produisent de meilleurs résultats en raison de leur distribution de valeurs distincte. Les colonnes avec une faible cardinalité peuvent offrir des opportunités limitées pour l'élagage des fichiers.
Sélectionnez des colonnes en fonction de l’utilisation fréquente des WHERE prédicats dans les tableaux de bord, les rapports, les travaux planifiés ou les requêtes utilisateur. Les conditions de jointure d’égalité ne bénéficient pas du clustering de données. Pour obtenir une vue d’ensemble de l’utilisation de Query Insights pour choisir des colonnes pour le clustering de données en fonction de votre charge de travail actuelle, reportez-vous au tutoriel : Utilisation du clustering de données dans Fabric Data Warehouse.
N’utilisez pas le clustering de données par plus de colonnes que strictement nécessaire. Le clustering à plusieurs colonnes ajoute de la complexité au stockage, ajoute une surcharge et peut ne pas offrir d’avantages, sauf si toutes les colonnes sont utilisées ensemble dans les requêtes avec des prédicats.
L’ordre de colonne utilisé dans CLUSTER BY n’est pas important et ne modifie pas la façon dont les lignes sont stockées.
Lors de la création d’une table avec clustering de données à l’aide de CREATE TABLE AS SELECT (CTAS), ou lors de l’ingestion de données à l’aide de INSERT INTO ... SELECT, conservez la partie select de ces instructions aussi simple que possible pour optimiser la qualité du clustering de données.

Le clustering de données peut réduire considérablement les coûts pendant les requêtes, s’ils sont bien alignés sur les prédicats de requête. Toutefois, l’ingestion de données entraîne davantage de temps et d’unités de capacité (CU) sur une table qui utilise le clustering de données par rapport à une table équivalente avec les mêmes données sans clustering de données. Cela se produit parce que le moteur d’entrepôt doit commander des données pendant l’ingestion. Étant donné que les données ingérées sont lues plusieurs fois, le clustering de données peut réduire la consommation globale de calcul d’une charge de travail donnée.

Vues du système

Les métadonnées de clustering de données peuvent être interrogées à l'aide de sys.index_columns. Elle affiche toutes les colonnes utilisées dans le clustering de données, y compris l’ordinal de colonne utilisé dans la CLUSTER BY clause.

La requête suivante répertorie toutes les colonnes utilisées dans le clustering de données sur l’entrepôt actuel et leurs tables :

SELECT
    t.name AS table_name,
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE ic.data_clustering_ordinal > 0
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Note

L’ordinal de colonne est affiché pour référence uniquement comme ordre utilisé lors CLUSTER BY de la définition de la table. Comme indiqué dans les meilleures pratiques, l’ordre des colonnes n’affecte pas les performances.

Limitations et remarques

Les performances d’ingestion des données peuvent se dégrader lorsque les tables contiennent de grandes colonnes varchar avec des tailles de données hautement variables.
- Par exemple, considérez une table avec une colonne varchar(200) : si certaines lignes contiennent seulement quelques caractères, tandis que d’autres approchent de la longueur maximale, la variance significative de la taille des données peut avoir un impact négatif sur la vitesse d’ingestion.
- Ce problème est connu et sera résolu dans une prochaine version.
IDENTITY les colonnes ne peuvent pas être utilisées avec CLUSTER BY. Les tables qui contiennent une IDENTITY colonne peuvent toujours être utilisées pour le clustering de données, étant donné qu’elles utilisent différentes colonnes avec CLUSTER BY.
Le clustering de données doit être défini lors de la création de la table. La conversion d’une table régulière en une table avec CLUSTER BY n’est pas prise en charge. De même, la modification des colonnes de clustering après la création d’une table n’est pas autorisée. Si différentes colonnes de clustering sont nécessaires, utilisez CREATE TABLE AS SELECT éventuellement (CTAS) pour créer une table avec les colonnes de clustering souhaitées.
Dans certains cas, le clustering de données peut être appliqué de manière asynchrone. Dans ce cas, les données sont réorganisées avec une tâche en arrière-plan et la table peut ne pas être entièrement optimisée lorsque l’ingestion se termine. Cela peut se produire dans les conditions suivantes :
- Lors de l’utilisation de INSERT INTO ... SELECT ou CREATE TABLE AS SELECT (CTAS), si l'interclassement des tables source et cible est différent.
- Lors de l’ingestion à partir de données externes au format CSV compressé.
- Lorsqu’une instruction d’ingestion a moins de 1 million de lignes.
L’ingestion des données sur les tables de clustering de données entraîne une surcharge par rapport à une table avec le même schéma qui n’utilise pas le clustering de données. Cela se produit en raison d’un calcul supplémentaire nécessaire pour optimiser le stockage. Lorsque la colonne de clustering a un interclassement insensible à la casse, une surcharge supplémentaire est également attendue.
Le clustering de données peut bénéficier du temps de réponse des requêtes, de la consommation de l’unité de capacité (CU) ou des deux.

Examples

R. Créez une table regroupée pour les données de ventes

Cet exemple crée une table simple Sales et utilise les colonnes CustomerID et SaleDate pour le clustering de données.

CREATE TABLE Sales (
    SaleID INT,
    CustomerID INT,
    SaleDate DATE,
    Amount DECIMAL(10,2)
) WITH (CLUSTER BY (CustomerID, SaleDate))

B. Créer une table en cluster à l’aide de CREATE TABLE AS SELECT

Cet exemple utilise CREATE TABLE AS SELECT pour créer une copie de la Sales table existante, avec CLUSTER BY la SaleDate colonne.

CREATE TABLE Sales_CTAS 
WITH (CLUSTER BY (SaleDate)) 
AS SELECT * FROM Sales

Chapitre C. Afficher les colonnes utilisées pour le clustering de données sur une table donnée

Cet exemple répertorie les colonnes utilisées pour le clustering de données dans la Sales table.

SELECT
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE 
    ic.data_clustering_ordinal > 0
   AND t.name = 'Sales'
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Résultats :

D. Vérifier l’efficacité des choix de colonnes pour le clustering de données

Query Insights peut vous aider à évaluer l’effet du clustering de données sur votre charge de travail en comparant le temps processeur et les données analysées entre une requête donnée et son exécution équivalente sur une copie en cluster de la table d’origine. L’exemple suivant montre comment récupérer le temps processeur alloué et le volume de données analysées sur disque, mémoire et stockage distant pour une requête spécifique.

SELECT 
    allocated_cpu_time_ms, 
    data_scanned_disk_mb, 
    data_scanned_memory_mb, 
    data_scanned_remote_storage_mb
FROM 
    queryinsights.exec_requests_history 
WHERE 
     distributed_statement_id = '<Query_Statement_ID>'

Où <Query_Statement_ID> est l’ID d’instruction distribué de la requête que vous souhaitez évaluer.

Étape suivante

Tutoriel : Utilisation du clustering de données dans Fabric Data Warehouse

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2025-11-19