Freigeben über

Verwenden von Datenclustering in Fabric Data Warehouse

Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric

Datenclusterung im Fabric Data Warehouse organisiert Daten für eine schnellere Abfrageleistung und verringerte Rechenleistung. In diesem Lernprogramm werden die Schritte zum Erstellen von Tabellen mit Datenclustering erläutert, von der Erstellung gruppierter Tabellen bis hin zur Überprüfung ihrer Effektivität.

Voraussetzungen

  • Ein Microsoft Fabric-Mandantenkonto mit einem aktiven Abonnement.
  • Stellen Sie sicher, dass Sie über einen für Microsoft Fabric aktivierten Arbeitsbereich verfügen: Erstellen eines Arbeitsbereichs.
  • Stellen Sie sicher, dass Sie bereits ein Lagerhaus erstellt haben. Informationen zum Erstellen eines neuen Warehouse finden Sie unter Create a Warehouse in Microsoft Fabric.
  • Grundlegendes Verständnis von T-SQL und Abfragen von Daten.

Beispieldaten importieren

In diesem Tutorial wird der NY-Taxi-Beispieldatensatz verwendet. Um die NY Taxi-Daten in Ihr Lager zu importieren. Verwenden Sie das Tutorial zum Laden von Beispieldaten in das Data Warehouse.

Erstellen Sie eine Tabelle mit Datenclustering

Für dieses Lernprogramm benötigen wir zwei Kopien der NYTaxi-Tabelle: die reguläre Kopie der Tabelle, die aus dem Lernprogramm importiert wird, und eine Kopie, die Datenclustering verwendet. Verwenden Sie den folgenden Befehl, um eine neue Tabelle mit CREATE TABLE AS SELECT (CTAS) basierend auf der ursprünglichen NYTaxi-Tabelle zu erstellen:

CREATE TABLE nyctlc_With_DataClustering 
WITH (CLUSTER BY (lpepPickupDatetime)) 
AS SELECT * FROM nyctlc

Hinweis

Im Beispiel wird davon ausgegangen, dass der Tabellenname dem NY Taxi-Dataset im Lernprogramm zum Laden von Beispieldaten in das Data Warehouse zugewiesen wird. Wenn Sie einen anderen Namen für die Tabelle verwendet haben, passen Sie den Befehl an, um nyctlc durch Ihren Tabellennamen zu ersetzen.

Mit diesem Befehl wird eine exakte Kopie der ursprünglichen NYTaxi-Tabelle erstellt, aber mit Datenclustering in der lpepPickupDatetime Spalte. Als Nächstes verwenden wir diese Spalte zum Abfragen.

Abfragedaten

Führen Sie eine Abfrage für die NYTaxi-Tabelle aus, und wiederholen Sie die genaue Gleiche Abfrage für die NYTaxi_With_DataClustering Tabelle zum Vergleich.

Hinweis

Für diese Analyse empfiehlt es sich, sich die Kaltcacheleistung beider Ausführungen anzusehen, d. h., ohne die Zwischenspeicherungsfeatures von Fabric Data Warehouse zu verwenden. Führen Sie daher jede Abfrage genau einmal aus, bevor Sie sich die Ergebnisse in Query Insights ansehen.

Wir verwenden eine Abfrage, die häufig im Warehouse wiederholt wird. Diese Abfrage berechnet den durchschnittlichen Tarifbetrag nach Jahr zwischen den Datumsangaben 2008-12-31 und 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');

Hinweis

Die in dieser Abfrage verwendete Bezeichnungsoption ist nützlich, wenn wir die Abfragedetails der Regular Tabelle mit derjenigen vergleichen, die später mithilfe von Datenclustering Abfrage-Insights-Ansichten verwendet.

Als Nächstes wiederholen wir dieselbe Abfrage, aber in der Version der Tabelle, die Datenclustering verwendet:

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');

Die zweite Abfrage verwendet die Bezeichnung Clustered , damit wir diese Abfrage später mit Query Insights identifizieren können.

Überprüfen der Effektivität von Datenclustering

Nach dem Einrichten des Clusterings können Sie die Effektivität mithilfe von Query Insights bewerten. Query Insights in Fabric Data Warehouse erfasst verlaufsbezogene Abfrageausführungsdaten und aggregiert sie in umsetzbare Erkenntnisse, z. B. das Identifizieren langer oder häufig ausgeführter Abfragen.

In diesem Fall verwenden wir Query Insights, um die Differenz der zwischen den regulären und gruppierten Fällen gescannten Daten zu vergleichen.

Verwenden Sie die folgende Abfrage:

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;

Diese Abfrage ruft Details aus der exec_requests_history Ansicht ab. Weitere Informationen finden Sie unter queryinsights.exec_requests_history (Transact-SQL).

Die Abfrage filtert die Ergebnisse wie folgt:

  • Ruft nur Zeilen ab, die den NYTaxi Text im Befehlsnamen enthalten (wie in den Testabfragen verwendet).
  • Ruft nur Zeilen ab, in denen der Label-Wert regulär oder gruppiert war

Hinweis

Es kann einige Minuten dauern, bis Ihre Abfragedetails in Query Insights verfügbar sind. Wenn Ihre Query Insights-Abfrage keine Ergebnisse zurückgibt, versuchen Sie es nach ein paar Minuten erneut.

Beim Ausführen dieser Abfrage werden die folgenden Ergebnisse beobachtet:

Tabelle, in der Abfrageausführungsmetriken für zwei Bezeichnungen verglichen werden: Gruppiert und normal. Die reguläre Abfrage hat weitere Ressourcen verwendet.

Beide Abfragen haben eine Zeilenanzahl von 6 und ähnliche Ausführungszeiten. Die Clustered Abfrage zeigt total_elapsed_time_ms von 1 794, allocated_cpu_time_ms von 1 676 und data_scanned_remote_storage_mb von 77.519. Die Regular Abfrage zeigt total_elapsed_time_ms 2651, allocated_cpu_time_ms von 2600 und data_scanned_remote_storage_mb von 177.700. Diese Zahlen zeigen, dass obwohl beide Abfragen dieselben Ergebnisse zurückgegeben haben, die Clustered Version ungefähr 36% weniger CPU-Zeit als die Regular Version verwendet und ungefähr 56% weniger Daten auf dem Datenträger gescannt hat. In beiden Abfrageausführungen wurde kein Cache verwendet. Dies sind wichtige Ergebnisse, um die Abfrageausführungszeit und den Verbrauch zu reduzieren und die lpepPickupDatetime Spalte zu einem starken Kandidaten für das Daten-Clustering zu machen.

Hinweis

Dies ist eine kleine Tabelle mit ca. 76 Millionen Zeilen und 2 GB Datenvolumen. Obwohl diese Abfrage nur sechs Zeilen für die Aggregation (eine für jedes Jahr im Bereich) zurückgibt, überprüft sie ungefähr 8,3 Millionen Zeilen im angegebenen Datumsbereich, bevor die Ergebnisse aggregiert werden. Tatsächliche Produktionsdaten mit größeren Datenvolumes können signifikantere Ergebnisse liefern. Ihre Ergebnisse können je nach Kapazitätsgröße, zwischengespeicherten Ergebnissen oder Parallelität während der Abfragen variieren.

Verwandte Inhalte

  • Last updated on