Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :✅ point de terminaison pour les analyses SQL et entrepôt de données dans Microsoft Fabric
Le clustering de données dans Fabric Data Warehouse organise les données pour accélérer les performances des requêtes et réduire l’utilisation du calcul. Ce tutoriel décrit les étapes de création de tables avec clustering de données, de la création de tables en cluster à la vérification de leur efficacité.
Prerequisites
- Un compte de locataire Microsoft Fabric avec un abonnement actif.
- Vérifiez que vous disposez d’un espace de travail avec Microsoft Fabric : Créer un espace de travail.
- Vérifiez que vous avez déjà créé un entrepôt. Pour créer un entrepôt, reportez-vous à Créer un entrepôt dans Microsoft Fabric.
- Compréhension de base des données T-SQL et interrogation des données.
Importer des exemples de données
Ce tutoriel utilise l’exemple de jeu de données NY Taxi. Pour importer les données des taxis NY dans votre entrepôt. Utilisez le didacticiel Charger des données d'exemple dans un entrepôt de données.
Créez une table avec le regroupement de données
Pour ce tutoriel, nous avons besoin de deux copies de la table NYTaxi : la copie régulière de la table telle qu’importée à partir du didacticiel et une copie qui utilise le clustering de données. Utilisez la commande suivante pour créer une table à l’aide CREATE TABLE AS SELECT de (CTAS), basée sur la table NYTaxi d’origine :
CREATE TABLE nyctlc_With_DataClustering
WITH (CLUSTER BY (lpepPickupDatetime))
AS SELECT * FROM nyctlc
Note
L'exemple suppose que le nom de table est attribué au jeu de données NY Taxi, dans le didacticiel "Charger des exemples de données dans Data Warehouse". Si vous avez utilisé un autre nom pour votre table, ajustez la commande à remplacer nyctlc par votre nom de table.
Cette commande crée une copie exacte de la table NYTaxi d’origine, mais avec un regroupement de données sur la colonne lpepPickupDatetime. Ensuite, nous utilisons cette colonne pour l’interrogation.
Rechercher des données
Exécutez une requête sur la table NYTaxi et répétez exactement la même requête sur la table NYTaxi_With_DataClustering pour la comparaison.
Note
Pour cette analyse, il est utile d’examiner les performances du cache à froid des deux exécutions, c’est-à-dire sans utiliser les fonctionnalités de mise en cache de Fabric Data Warehouse. Par conséquent, exécutez chaque requête exactement une fois avant d’examiner les résultats dans Query Insights.
Nous utilisons une requête qui est souvent répétée dans l’entrepôt. Cette requête calcule le montant moyen des tarifs par année entre les dates 2008-12-31 et 2014-06-30:
SELECT
YEAR(lpepPickupDatetime),
AVG(fareAmount) as [Average Fare]
FROM
NYTaxi
WHERE
lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY
YEAR(lpepPickupDatetime)
ORDER BY
YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Regular');
Note
L’option d’étiquette utilisée dans cette requête est utile lorsque nous comparons les détails de la requête de la table Regular contre celle qui utilise le regroupement de données plus tard à l'aide des vues Query Insights.
Ensuite, nous répétons exactement la même requête, mais sur la version de la table qui utilise le clustering de données :
SELECT
YEAR(lpepPickupDatetime),
AVG(fareAmount) as [Average Fare]
FROM
NYTaxi_With_DataClustering
WHERE
lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY
YEAR(lpepPickupDatetime)
ORDER BY
YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Clustered');
La deuxième requête utilise l’étiquette Clustered pour nous permettre d’identifier cette requête ultérieurement avec Query Insights.
Vérifier l’efficacité du clustering de données
Après avoir configuré le clustering, vous pouvez évaluer son efficacité à l’aide de Query Insights. Query Insights dans Fabric Data Warehouse capture les données d’exécution des requêtes historiques et les agrège en insights actionnables, tels que l’identification de requêtes longues ou fréquemment exécutées.
Dans ce cas, nous utilisons Query Insights pour comparer la différence entre les données analysées entre les cas standard et cluster.
Utilisez la requête suivante :
SELECT
label,
submit_time,
row_count,
total_elapsed_time_ms,
allocated_cpu_time_ms,
result_cache_hit,
data_scanned_disk_mb,
data_scanned_memory_mb,
data_scanned_remote_storage_mb,
command
FROM
queryinsights.exec_requests_history
WHERE
command LIKE '%NYTaxi%'
AND label IN ('Regular','Clustered')
ORDER BY
submit_time DESC;
Cette requête extrait les détails de la exec_requests_history vue. Pour plus d’informations, consultez queryinsights.exec_requests_history (Transact-SQL).
La requête filtre les résultats de la manière suivante :
- Récupère uniquement les lignes qui contiennent le
NYTaxitexte dans le nom de la commande (comme utilisé dans les requêtes de test) - Récupère uniquement les lignes où la valeur d’étiquette était normale ou en cluster
Note
La disponibilité des détails de votre requête peut prendre quelques minutes dans Query Insights. Si votre requête Query Insights ne retourne aucun résultat, réessayez après quelques minutes.
En exécutant cette requête, nous observons les résultats suivants :
Les deux requêtes ont un nombre de lignes de 6 et des heures d’envoi similaires. La Clustered requête indique total_elapsed_time_ms 1794, allocated_cpu_time_ms 1676 et data_scanned_remote_storage_mb 77,519. La Regular requête indique total_elapsed_time_ms 2651, allocated_cpu_time_ms 2600 et data_scanned_remote_storage_mb 177,700. Ces nombres montrent que même si les deux requêtes ont retourné les mêmes résultats, la Clustered version a utilisé environ 36% moins de temps processeur que la version et analysé environ 56% moins de données sur le Regular disque. Aucun cache n’a été utilisé dans l’une ou l’autre exécution de requête. Il s’agit de résultats significatifs pour réduire le temps d’exécution des requêtes et la consommation des ressources, et faire de la lpepPickupDatetime colonne un candidat fort pour le clustering de données.
Note
Il s’agit d’une petite table, avec environ 76 millions de lignes et 2 Go de volume de données. Même si cette requête retourne seulement six lignes sur son agrégation (une pour chaque année dans la plage), elle analyse environ 8,3 millions de lignes dans la plage de dates fournie avant l’agrégation des résultats. Les données de production réelles avec des volumes de données plus volumineux peuvent fournir des résultats plus significatifs. Vos résultats peuvent varier en fonction de la taille de capacité, des résultats mis en cache ou de la concurrence pendant les requêtes.