Użycie klastrowania danych w Azure Fabric Data Warehouse

Dotyczy:✅ końcowego punktu analizy SQL i magazynu danych w usłudze Microsoft Fabric

Klastrowanie danych w usłudze Fabric Data Warehouse organizuje dane w celu zwiększenia wydajności zapytań i zmniejszenia użycia zasobów obliczeniowych. W tym samouczku przedstawiono procedurę tworzenia tabel z klastrowaniem danych, od tworzenia tabel klastrowanych w celu sprawdzenia ich skuteczności.

Wymagania wstępne

• Konto dzierżawcy usługi Microsoft Fabric z aktywną subskrypcją.
• Upewnij się, że masz obszar roboczy z włączoną usługą Microsoft Fabric: tworzenie obszaru roboczego.
• Upewnij się, że utworzono już magazyn. Aby utworzyć nowy magazyn, zobacz Tworzenie magazynu w usłudze Microsoft Fabric.
• Podstawowa wiedza na temat języka T-SQL i wykonywania zapytań dotyczących danych.

Import przykładowych danych

W tym samouczku używamy przykładowego zestawu danych NY Taxi. Aby zaimportować dane NY Taxi do magazynu. Użyj samouczka Ładowanie przykładowych danych do magazynu danych.

Stwórz tabelę z klastrowaniem danych

W tym samouczku potrzebujemy dwóch kopii tabeli NYTaxi: regularnej kopii tabeli zaimportowanej z samouczka oraz kopii korzystającej z klastrowania danych. Użyj następującego polecenia, aby utworzyć nową tabelę przy użyciu CREATE TABLE AS SELECT (CTAS) na podstawie oryginalnej tabeli NYTaxi:

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

Uwaga / Notatka

W przykładzie przyjęto założenie, że nazwa tabeli nadana została zestawowi danych NY Taxi w samouczku „Ładowanie przykładowych danych do magazynu danych”. Jeśli użyto innej nazwy tabeli, dostosuj polecenie, aby zastąpić nyctlc nazwą tabeli.

To polecenie tworzy dokładną kopię oryginalnej tabeli NYTaxi, ale z klastrowaniem danych w kolumnie lpepPickupDatetime . Następnie użyjemy tej kolumny do wykonywania zapytań.

Wykonywanie zapytań o dane

Uruchom zapytanie w tabeli NYTaxi i powtórz dokładnie to samo zapytanie w tabeli NYTaxi_With_DataClustering w celu porównania.

Uwaga / Notatka

W przypadku tej analizy warto przyjrzeć się wydajności zimnej pamięci podręcznej obu przebiegów — czyli bez używania funkcji buforowania magazynu danych sieci szkieletowej. W związku z tym uruchom każde zapytanie dokładnie raz, zanim przyjrzysz się wynikom w usłudze Query Insights.

Używamy zapytania, które jest często powtarzane w magazynie. To zapytanie oblicza średnią kwotę taryfy według roku między datami 2008-12-31 a 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');

Uwaga / Notatka

Opcja etykiety używana w tym zapytaniu jest przydatna podczas porównywania szczegółów Regular zapytania tabeli z tą, która używa klastrowania danych później przy użyciu widoków usługi Query Insights.

Następnie powtarzamy dokładnie to samo zapytanie, ale w wersji tabeli korzystającej z klastrowania danych:

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

Drugie zapytanie używa etykiety Clustered , aby umożliwić nam identyfikację tego zapytania później za pomocą usługi Query Insights.

Sprawdzanie skuteczności klastrowania danych

Po skonfigurowaniu klastrowania można ocenić jego skuteczność przy użyciu usługi Query Insights. Usługa Query Insights w usłudze Fabric Data Warehouse przechwytuje historyczne dane wykonywania zapytań i agreguje je w szczegółowe informacje umożliwiające podejmowanie działań, takie jak identyfikowanie długotrwałych lub często wykonywanych zapytań.

W tym przypadku użyjemy usługi Query Insights, aby porównać różnicę w danych skanowanych między przypadkami regularnymi i klastrowanych.

Użyj następującego zapytania:

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;

To zapytanie pobiera szczegóły z exec_requests_history widoku. Aby uzyskać więcej informacji, zobacz queryinsights.exec_requests_history (Transact-SQL).

Zapytanie filtruje wyniki na następujące sposoby:

• Pobiera tylko wiersze zawierające tekst NYTaxi w nazwie polecenia (jak używano w zapytaniach testowych)
• Pobiera tylko wiersze, w których wartość etykiety była zwykła lub klastrowana

Uwaga / Notatka

Udostępnienie szczegółów zapytania w usłudze Query Insights może potrwać kilka minut. Jeśli zapytanie query Insights nie zwraca żadnych wyników, spróbuj ponownie po kilku minutach.

Uruchamiając to zapytanie, obserwujemy następujące wyniki:

Oba zapytania mają liczbę wierszy 6 i podobne czasy przesyłania. Zapytanie Clustered pokazuje total_elapsed_time_ms 1794, allocated_cpu_time_ms 1676 oraz data_scanned_remote_storage_mb 77 519. Zapytanie Regular pokazuje total_elapsed_time_ms o wartości 2651, allocated_cpu_time_ms o wartości 2600 oraz data_scanned_remote_storage_mb o wartości 177.700. Liczby te pokazują, że mimo że oba zapytania zwróciły te same wyniki, Clustered wersja używała około 36% mniej czasu procesora NIŻ Regular wersja i przeskanowała około 56% mniej danych na dysku. Żadna pamięć podręczna nie została użyta w każdym uruchomieniu zapytania. To są znaczące wyniki, które pomagają skrócić czas wykonywania zapytań i zużycie oraz uczynić kolumnę lpepPickupDatetime silnym kandydatem na klastrowanie danych.

Uwaga / Notatka

Jest to mała tabela z około 76 milionami wierszy i 2 GB woluminu danych. Mimo że to zapytanie zwraca tylko sześć wierszy w agregacji (jeden dla każdego roku w zakresie), skanuje około 8,3 miliona wierszy w zakresie dat podanym przed zagregacją wyników. Rzeczywiste dane produkcyjne z większymi woluminami danych mogą zapewnić bardziej znaczące wyniki. Wyniki mogą się różnić w zależności od rozmiaru pojemności, buforowanych wyników lub współbieżności podczas wykonywania zapytań.

Treści powiązane

• Klastrowanie danych w magazynie danych Fabric
• Analizy zapytań w magazynie danych Fabric
• Monitor Fabric Data Warehouse
• Użyj etykiet zapytań w Fabryce Danych