Ściągawka dotycząca dedykowanej puli SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics

Ten ściągawka zawiera przydatne porady i najlepsze rozwiązania dotyczące tworzenia dedykowanych rozwiązań puli SQL (dawniej SQL DW).

Poniższa ilustracja przedstawia proces projektowania magazynu danych z dedykowaną pulą SQL (dawniej SQL DW):

Szkicu

Zapytania i operacje między tabelami

Jeśli wcześniej wiadomo, które operacje i zapytania będą uruchamiane w magazynie danych, można przydzielać priorytety architekturze magazynu danych dla tych operacji. Te zapytania i operacje mogą być następujące:

  • Łączenie jednej lub dwóch tabel faktów z tabelami wymiarów, filtrowanie połączonej tabeli, a następnie łączenie wyników w składnicy danych.
  • Wprowadzanie dużych lub małych aktualizacji do sprzedaży faktów.
  • Dołączanie tylko danych do tabel.

Wcześniejsza znajomość typów operacji pomaga zoptymalizować projekt tabel.

Migracja danych

Najpierw załaduj dane do Azure Data Lake Storage lub Azure Blob Storage. Następnie użyj instrukcji COPY , aby załadować dane do tabel przejściowych. Użyj następującej konfiguracji:

Projekt Zalecenie
Dystrybucja Działanie okrężne
Indeksowanie Sterta
Partycjonowanie Brak
Klasa zasobów largerc lub xlargerc

Dowiedz się więcej o migracji danych, ładowaniu danych i proces wyodrębniania, przekształcania i ładowania (ELT).

Tabele rozproszone lub replikowane

Użyj następujących strategii, w zależności od właściwości tabeli:

Typ Doskonałe rozwiązanie dla... Należy uważać, jeśli...
Replikowane * Małe tabele wymiarów w schemacie gwiazdy z mniej niż 2 GB magazynu po kompresji (kompresja~5x) * Wiele transakcji zapisu jest w tabeli (takich jak wstawianie, upsert, usuwanie, aktualizacja)

* Często zmieniasz aprowizację jednostek Data Warehouse (DWU)

* Używasz tylko 2–3 kolumn, ale tabela ma wiele kolumn

* Indeksowanie replikowanej tabeli
Działanie okrężne (ustawienie domyślne) * Tabela tymczasowa/przejściowa

* Brak oczywistego klucza dołączania lub kolumny dobrego kandydata
* Wydajność jest niska z powodu przenoszenia danych
Skrót * Tabele faktów

* Duże tabele wymiarów
* Nie można zaktualizować klucza dystrybucji

Porady:

  • Rozpocznij od działania okrężnego, ale staraj się zastosować strategię dystrybucji skrótów, aby skorzystać z zalet architektury z wysokim wskaźnikiem przetwarzania równoległego.
  • Upewnij się, że typowe klucze skrótów mają ten sam format danych.
  • Nie dystrybuuj w formacie varchar.
  • Tabele wymiarów ze wspólnym kluczem skrótu do tabeli faktów z częstymi operacjami sprzężenia mogą być rozproszonymi tabelami skrótów.
  • Użyj elementu sys.dm_pdw_nodes_db_partition_stats, aby analizować skośność danych.
  • Użyj sys.dm_pdw_request_steps do analizowania przenoszenia danych za zapytaniami, monitorowania emisji czasu i operacji mieszania. To pomaga w ocenie stosowanej strategii dystrybucji.

Dowiedz się więcej o tabelach replikowanych i tabelach rozproszonych.

Indeksowanie tabeli

Indeksowanie ułatwia szybkie odczytywanie tabel. W zależności od potrzeb można używać unikatowego zestawu technologii:

Typ Doskonałe rozwiązanie dla... Należy uważać, jeśli...
Sterta * Tabela przejściowa/tymczasowa

* Małe tabele z małymi odnośnikami
* Wszystkie wyszukiwania skanują pełną tabelę
Indeks klastrowany * Tabele z maksymalnie 100 milionami wierszy

* Duże tabele (ponad 100 milionów wierszy) z tylko 1–2 kolumnami intensywnie używanymi
* Używane w tabeli replikowanej

* Masz złożone zapytania obejmujące wiele operacji sprzężenia i grupowania według

* Aktualizujesz indeksowane kolumny: trwa to pamięć
Klastrowany indeks magazynu kolumn (CCI) (ustawienie domyślne) * Duże tabele (ponad 100 milionów wierszy) * Używane w tabeli replikowanej

* Wykonasz ogromne operacje aktualizacji w tabeli

* Nadmierna partycja tabeli: grupy wierszy nie obejmują różnych węzłów dystrybucji i partycji

Porady:

  • Oprócz indeksu klastrowanego można do kolumny intensywnie używanej do filtrowania dodać indeks nieklastrowany.
  • Zachowaj ostrożność przy zarządzaniu pamięcią tabeli przy użyciu indeksu CCI. Gdy ładujesz dane, chcesz, aby użytkownik (lub zapytanie) korzystał z zalet dużej klasy zasobów. Pamiętaj, aby unikać przycinania i tworzenia wielu małych skompresowanych grup wierszy.
  • W przypadku drugiej generacji tabele indeksu CCI są buforowane lokalnie w węzłach obliczeniowych w celu zmaksymalizowania wydajności.
  • W przypadku interfejsu CCI przyczyną niskiej wydajności może być słaba kompresja grup wierszy. W takim przypadku ponownie skompiluj lub zorganizuj indeks CCI. Chcesz, aby każda skompresowana grupa wierszy zawierała co najmniej 100 000 wierszy. Idealna liczba to 1 mln wierszy w grupie.
  • Na podstawie rozmiaru i częstotliwości ładowania przyrostowego chcesz zautomatyzować reorganizację lub ponowną kompilację indeksów. Gruntowne porządki będą zawsze pomocne.
  • Jeśli chcesz przyciąć grupę wierszy, podejdź do tego strategicznie. Jak duże są otwarte grupy wierszy? Ile danych planujesz załadować w ciągu nadchodzących dni?

Dowiedz się więcej o indeksach.

Partycjonowanie

Tabelę możesz partycjonować, gdy jest to duża tabela faktów (większa niż 1 miliard wierszy). W 99% przypadków klucz partycji powinien opierać się na dacie.

Partycjonowanie może przynieść korzyści w przypadku tabel przejściowych, które wymagają procesu ELT. Ułatwia ono zarządzanie cyklem życia danych. Należy zachować ostrożność, aby nie partycjonować faktów ani tabel przejściowych, zwłaszcza w klastrowanym indeksie magazynu kolumn.

Dowiedz się więcej o partycjach.

Ładowanie przyrostowe

Jeśli planujesz ładować dane przyrostowo, najpierw upewnij się, że przydzielasz większe klasy zasobów na potrzeby ładowania danych. Jest to szczególnie ważne podczas ładowania do tabel za pomocą klastrowanych indeksów magazynu kolumn. Aby uzyskać więcej informacji, zobacz klasy zasobów .

Zalecamy używanie technologii PolyBase i ADF w wersji 2 do automatyzowania potoków ELT w magazynie danych.

W przypadku dużej partii aktualizacji w danych historycznych rozważ użycie funkcji CTAS do zapisywania danych, które chcesz przechowywać w tabeli, zamiast używania instrukcji INSERT, UPDATE i DELETE.

Prowadzenie statystyk

Ważne jest aktualizowanie statystyk w miarę pojawiania się kolejnych znaczących zmian danych. Zobacz statystyki aktualizacji , aby określić, czy wystąpiły znaczące zmiany. Zaktualizowane statystyki optymalizują plany zapytań. Jeśli okaże się, że obsługa wszystkich statystyk trwa zbyt długo, należy przemyśleć dokładnie wybór kolumn ze statystykami.

Można również zdefiniować częstotliwość aktualizacji. Można na przykład codziennie aktualizować kolumny danych, w których mogą być dodawane nowe wartości. Największe korzyści można osiągnąć, prowadząc statystyki dla kolumn uczestniczących w sprzężeniach, kolumn używanych w ramach klauzuli WHERE i kolumn z klauzuli GROUP BY.

Dowiedz się więcej o statystykach.

Klasa zasobów

Grupy zasobów są używane jako sposób przydzielania pamięci do zapytań. Jeśli potrzeba większej ilości pamięci w celu zwiększenia szybkości zapytań lub ładowania, należy przydzielić wyższe klasy zasobów. Z drugiej strony użycie większych klas zasobów wpływa na współbieżność. Należy o tym pamiętać przed przeniesieniem wszystkich użytkowników do dużej klasy zasobów.

Jeśli zauważysz, że wykonywanie zapytań trwa zbyt długo, sprawdź, czy użytkownicy nie stosują uruchamiania w dużych klasach zasobów. Duże klasy zasobów używają wielu miejsc współbieżności. Może to powodować powstanie kolejki innych zasobów.

Na koniec przy użyciu usługi Gen2 dedykowanej puli SQL (dawniej SQL DW) każda klasa zasobów otrzymuje 2,5 razy więcej pamięci niż gen1.

Dowiedz się więcej, jak pracować z klasami zasobów i współbieżnością.

Obniżanie kosztów

Kluczową funkcją Azure Synapse jest możliwość zarządzania zasobami obliczeniowymi. Możesz wstrzymać dedykowaną pulę SQL (dawniej SQL DW), gdy jej nie używasz, co uniemożliwia naliczanie opłat za zasoby obliczeniowe. Zasoby można skalować zgodnie ze swoimi wymaganiami dotyczącymi wydajności. W celu wstrzymania użyj witryny Azure Portal lub programu PowerShell. Aby przeprowadzić skalowanie, użyj Azure Portal, programu PowerShell, języka T-SQL lub interfejsu API REST.

Teraz możesz używać automatycznego skalowania w dowolnym momencie dzięki funkcji Azure Functions:

Obraz przedstawiający przycisk z etykietą

Optymalizacja architektury pod kątem wydajności

Zalecamy rozważenie użycia bazy danych SQL Database i usługi Azure Analysis Services w architekturze gwiazdy. To rozwiązanie może spowodować rozdzielenie obciążenia między różnymi grupami użytkowników przy równoczesnym korzystaniu z zaawansowanych funkcji zabezpieczeń bazy danych SQL Database i usługi Azure Analysis Services. Jest to również sposób na zapewnienie użytkownikom nieograniczonej współbieżności.

Dowiedz się więcej o typowych architekturach korzystających z dedykowanej puli SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics.

Wdróż w jednym kliknięciu szprychy w bazach danych SQL z dedykowanej puli SQL (dawniej SQL DW):

Obraz przedstawiający przycisk z etykietą