Wytyczne dotyczące wydajności magazynu danych sieci szkieletowej
Dotyczy:✅ Magazyn w usłudze Microsoft Fabric
Są to wytyczne ułatwiające zrozumienie wydajności magazynu w usłudze Microsoft Fabric. W tym artykule znajdziesz wskazówki i ważne artykuły, na których należy się skupić. Magazyn w usłudze Microsoft Fabric to platforma SaaS, na której działania takie jak zarządzanie obciążeniami, współbieżność i zarządzanie magazynem są zarządzane wewnętrznie przez platformę. Oprócz tego wewnętrznego zarządzania wydajnością nadal można zwiększyć wydajność, opracowując wydajne zapytania w dobrze zaprojektowanych magazynach.
Wydajność zimnego uruchomienia (zimnej pamięci podręcznej)
Buforowanie przy użyciu lokalnego dysku SSD i pamięci jest automatyczne. Pierwsze 1–3 wykonania zapytania wykonuje się znacznie wolniej niż kolejne wykonania. Jeśli występują problemy z wydajnością zimnego uruchomienia, poniżej przedstawiono kilka czynności, które można zrobić, co może poprawić wydajność zimnego uruchomienia:
Jeśli wydajność pierwszego przebiegu jest kluczowa, spróbuj ręcznie utworzyć statystyki. Zapoznaj się z artykułem dotyczącym statystyk , aby lepiej zrozumieć rolę statystyk i uzyskać wskazówki dotyczące tworzenia statystyk ręcznych w celu poprawy wydajności zapytań. Jeśli jednak wydajność pierwszego uruchomienia nie jest krytyczna, możesz opierać się na automatycznych statystykach, które zostaną wygenerowane w pierwszym zapytaniu i będą nadal używane w kolejnych uruchomieniach (tak długo, jak dane bazowe nie zmieniają się znacząco).
W przypadku korzystania z usługi Power BI użyj trybu Direct Lake tam, gdzie to możliwe.
Metryki monitorowania wydajności
Obecnie centrum monitorowania nie zawiera magazynu. Jeśli wybierzesz pozycję Magazyn danych, nie będzie można uzyskać dostępu do centrum monitorowania na pasku nawigacyjnym.
Administratorzy sieci szkieletowej będą mogli uzyskać dostęp do raportu Wykorzystanie pojemności i metryki w celu uzyskania aktualnych informacji śledzenia wykorzystania pojemności obejmującej magazyn.
Monitorowanie wykonywania zapytań za pomocą dynamicznych widoków zarządzania (DMV)
Dynamiczne widoki zarządzania (DMV) umożliwiają monitorowanie stanu połączenia, sesji i żądania w magazynie.
Statystyki
Magazyn używa aparatu zapytań do utworzenia planu wykonywania dla danego zapytania SQL. Podczas przesyłania zapytania optymalizator zapytań próbuje wyliczyć wszystkie możliwe plany i wybrać najbardziej wydajnego kandydata. Aby określić, który plan wymaga najmniejszego obciążenia, aparat musi mieć możliwość oceny ilości pracy lub wierszy, które mogą być przetwarzane przez każdego operatora. Następnie, na podstawie kosztów każdego planu, wybiera ten z najmniejszą ilością szacowanej pracy. Statystyki to obiekty, które zawierają odpowiednie informacje o danych, aby umożliwić optymalizatorowi zapytań oszacowanie tych kosztów.
Możesz również ręcznie aktualizować statystyki po każdym załadowaniu danych lub aktualizacji danych, aby zapewnić, że można utworzyć najlepszy plan zapytań.
Aby uzyskać więcej informacji o statystykach i sposobie rozszerzania automatycznie utworzonych statystyk, zobacz Statystyki w magazynowaniu danych sieci szkieletowej.
Wytyczne dotyczące pozyskiwania danych
Istnieją cztery opcje pozyskiwania danych do magazynu:
- COPY (Transact-SQL)
- Potoki danych
- Przepływy danych
- Pozyskiwanie między magazynami
Aby ułatwić określenie, która opcja jest najlepsza dla Ciebie i przejrzeć niektóre najlepsze rozwiązania dotyczące pozyskiwania danych, zapoznaj się z artykułem Pozyskiwanie danych.
Grupowanie instrukcji INSERT do partii (unikaj wstawiania sztuczek)
Jednorazowe ładowanie do małej tabeli z instrukcją INSERT, na przykład pokazaną w poniższym przykładzie, może być najlepszym podejściem w zależności od potrzeb. Jeśli jednak trzeba załadować tysiące lub miliony wierszy w ciągu dnia, singleton INSERTS nie są optymalne.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Aby uzyskać wskazówki dotyczące obsługi tych scenariuszy ładowania sztuczek, zobacz Najlepsze rozwiązania dotyczące pozyskiwania danych.
Minimalizowanie rozmiarów transakcji
Instrukcje INSERT, UPDATE i DELETE są uruchamiane w transakcji. Gdy się nie powiedzie, muszą zostać wycofane. Aby zmniejszyć potencjał długiego wycofywania, zminimalizuj rozmiary transakcji zawsze, gdy jest to możliwe. Zminimalizowanie rozmiarów transakcji można wykonać przez podzielenie instrukcji INSERT, UPDATE i DELETE na części. Jeśli na przykład masz obiekt INSERT, który ma potrwać 1 godzinę, możesz podzielić wstawianie na cztery części. Każde uruchomienie zostanie następnie skrócone do 15 minut.
Rozważ użycie CTAS (Transact-SQL) do zapisania danych, które mają być trzymane w tabeli, a nie przy użyciu funkcji DELETE. Jeśli CTAS zajmuje tyle samo czasu, bezpieczniej jest uruchomić, ponieważ ma minimalne rejestrowanie transakcji i można je szybko anulować w razie potrzeby.
Sortowanie aplikacji klienckich i usługi Microsoft Fabric
Jeśli używasz aplikacji klienckich, upewnij się, że używasz usługi Microsoft Fabric w regionie zbliżonym do komputera klienckiego. Przykłady aplikacji klienckich obejmują program Power BI Desktop, program SQL Server Management Studio i program Azure Data Studio.
Korzystanie z projektu danych schematu gwiazdy
Schemat gwiazdy organizuje dane w tabele faktów i tabele wymiarów. Ułatwia ona przetwarzanie analityczne przez denormalizację danych z wysoce znormalizowanych systemów OLTP, pozyskiwanie danych transakcyjnych i danych głównych przedsiębiorstwa do wspólnej, oczyszczonej i zweryfikowanej struktury danych, która minimalizuje sprzężenia w czasie zapytania, zmniejsza liczbę wierszy odczytu i ułatwia agregację i przetwarzanie grupowania.
Aby uzyskać więcej wskazówek dotyczących projektowania magazynu, zobacz Tabele w magazynowaniu danych.
Zmniejsz rozmiary zestawu wyników zapytania
Zmniejszenie rozmiarów zestawu wyników zapytania pomaga uniknąć problemów po stronie klienta spowodowanych dużymi wynikami zapytania. Zestawy wyników edytora zapytań SQL są ograniczone do pierwszych 10 000 wierszy, aby uniknąć tych problemów w tym interfejsie użytkownika opartym na przeglądarce. Jeśli musisz zwrócić więcej niż 10 000 wierszy, użyj programu SQL Server Management Studio (SSMS) lub narzędzia Azure Data Studio.
Wybieranie najlepszego typu danych pod kątem wydajności
Podczas definiowania tabel użyj najmniejszego typu danych, który obsługuje dane w ten sposób, poprawi wydajność zapytań. To zalecenie jest ważne dla kolumn CHAR i VARCHAR. Jeśli najdłuższa wartość w kolumnie ma 25 znaków, należy zdefiniować typ kolumny jako VARCHAR(25). Unikaj definiowania wszystkich kolumn znaków o dużej długości domyślnej.
Jeśli to możliwe, użyj typów danych opartych na liczbach całkowitych. Operacje SORT, JOIN i GROUP BY są wykonywane szybciej na liczbach całkowitych niż w danych znaków.
Aby uzyskać informacje o obsługiwanych typach danych i więcej informacji, zobacz typy danych.
Wydajność punktu końcowego analizy SQL
Aby uzyskać informacje i zalecenia dotyczące wydajności punktu końcowego analizy SQL, zobacz Zagadnienia dotyczące wydajności punktu końcowego analizy SQL.
Kompaktowanie danych
Kompaktowanie danych konsoliduje mniejsze pliki Parquet w mniej, większe pliki, co optymalizuje operacje odczytu. Ten proces pomaga również efektywnie zarządzać usuniętymi wierszami, eliminując je z niezmiennych plików Parquet. Proces kompaktowania danych obejmuje ponowne zapisywanie tabel lub segmentów tabel w nowych plikach Parquet zoptymalizowanych pod kątem wydajności. Aby uzyskać więcej informacji, zobacz Blog: Automatic Data Compaction for Fabric Warehouse (Automatyczne kompaktowanie danych dla magazynu sieci szkieletowej).
Proces kompaktowania danych jest bezproblemowo zintegrowany z magazynem. W miarę wykonywania zapytań system identyfikuje tabele, które mogą korzystać z kompaktowania i wykonują niezbędne oceny. Nie ma ręcznego sposobu wyzwalania kompaktowania danych.