Najlepsze rozwiązania dotyczące wydajności

W tym artykule opisano najlepsze rozwiązania dotyczące wydajności uporządkowane według zasad architektury wymienionych w poniższych sekcjach.

1. Skalowanie w pionie, skalowanie w poziomie i skalowalność liniowa

Zanim przejdziemy do najlepszych rozwiązań, przyjrzyjmy się kilku koncepcji przetwarzania rozproszonego: skalowania w poziomie, skalowania w pionie i skalowalności liniowej.

• Skalowanie w pionie: skalowanie w pionie przez dodawanie lub usuwanie zasobów z pojedynczej maszyny, zazwyczaj procesorów CPU, pamięci lub procesorów GPU. Zazwyczaj oznacza to zatrzymanie obciążenia, przeniesienie go na większą maszynę i ponowne uruchomienie. Istnieją ograniczenia skalowania w pionie: może nie być większej maszyny lub cena kolejnej większej maszyny może być zbyt duża.
• Skalowanie w poziomie: skaluj w poziomie, dodając lub usuwając węzły z systemu rozproszonego. Po osiągnięciu limitów skalowania w pionie rozwiązanie polega na skalowaniu w poziomie: przetwarzanie rozproszone używa systemów z wieloma maszynami (nazywanymi klastrami) do uruchamiania obciążeń. Należy pamiętać, że aby było to możliwe, obciążenia muszą być przygotowane do równoległego wykonywania, obsługiwane przez aparaty platformy analizy danych usługi Databricks, apache Spark i Photon. Dzięki temu można połączyć wiele tanich maszyn w większy system obliczeniowy. Gdy potrzebne są więcej zasobów obliczeniowych, skalowanie w poziomie dodaje więcej węzłów do klastra i usuwa je, gdy nie są już potrzebne. Chociaż technicznie nie ma limitu (a aparat Spark wykonuje złożoną część równoważenia obciążenia), duża liczba węzłów zwiększa złożoność zarządzania.
• Skalowalność liniowa, co oznacza, że w przypadku dodawania większej liczby zasobów do systemu relacja między przepływnością a używanymi zasobami jest liniowa. Jest to możliwe tylko wtedy, gdy zadania równoległe są niezależne. Jeśli nie, wyniki pośrednie w jednym zestawie węzłów będą potrzebne w innym zestawie węzłów w klastrze w celu przeprowadzenia dalszych obliczeń. Ta wymiana danych między węzłami obejmuje transport wyników za pośrednictwem sieci z jednego zestawu węzłów do innego zestawu węzłów, co zajmuje dużo czasu. Ogólnie rzecz biorąc, przetwarzanie rozproszone ma pewne obciążenie związane z zarządzaniem dystrybucją i wymianą danych. W związku z tym małe obciążenia zestawu danych, które można analizować w jednym węźle, mogą być jeszcze wolniejsze w przypadku uruchamiania w systemie rozproszonym. Platforma analizy danych usługi Databricks udostępnia elastyczne przetwarzanie (pojedyncze węzły i rozproszone), aby zaspokoić unikatowe potrzeby obciążeń.

2. Korzystanie z architektur bezserwerowych

Korzystanie z obliczeń bezserwerowych

W przypadku bezserwerowych obliczeń na platformie analizy danych usługi Databricks warstwa obliczeniowa jest uruchamiana na koncie klienta usługi Azure Databricks. Usługi są w pełni zarządzane i stale ulepszane przez usługę Databricks. Oprócz klientów płacących tylko za to, czego używają, powoduje to zwiększenie wydajności:

• Administratorzy chmury nie muszą już zarządzać złożonymi środowiskami chmury, takimi jak dostosowywanie limitów przydziału, tworzenie i utrzymywanie zasobów sieciowych oraz nawiązywanie połączenia ze źródłami rozliczeniowymi. Mogą skupić się na projektach o wyższej wartości zamiast zarządzania składnikami chmury niskiego poziomu.
• Użytkownicy korzystają z opóźnienia uruchamiania klastra niemal zerowego i ulepszonej współbieżności zapytań.

Usługa Databricks udostępnia usługi zarządzane dla różnych obciążeń:

• Bezserwerowe magazyny SQL dla obciążeń SQL

  Administratorzy obszaru roboczego mogą tworzyć bezserwerowe magazyny SQL, które umożliwiają natychmiastowe obliczenia i są zarządzane przez usługę Databricks. Używaj ich z zapytaniami SQL usługi Databricks tak samo jak w przypadku oryginalnych magazynów SQL usługi Databricks. Przetwarzanie bezserwerowe zapewnia bardzo szybki czas uruchamiania dla magazynów SQL, a infrastruktura jest zarządzana i zoptymalizowana przez usługę Databricks.

• Zadania bezserwerowe umożliwiające wydajne i niezawodne przepływy pracy

  Bezserwerowe obliczenia dla zadań umożliwiają uruchamianie zadania usługi Databricks bez konfigurowania i wdrażania infrastruktury. W przypadku bezserwerowych zasobów obliczeniowych koncentrujesz się na implementowaniu potoków przetwarzania danych i analizy, a usługa Databricks efektywnie zarządza zasobami obliczeniowymi, w tym optymalizowanie i skalowanie zasobów obliczeniowych dla obciążeń. Skalowanie automatyczne i funkcja Photon są automatycznie włączone dla zasobów obliczeniowych, na których uruchomiono zadanie.

  Koszt zadań, które używają bezserwerowych obliczeń dla zadań, można monitorować, wysyłając zapytanie do tabeli systemu użycia rozliczanego.

• Bezserwerowe obliczenia dla notesów

  Jeśli obszar roboczy jest włączony dla bezserwerowych interaktywnych obliczeń, wszyscy użytkownicy w obszarze roboczym mają dostęp do bezserwerowych obliczeń dla notesów. Nie są wymagane żadne dodatkowe uprawnienia.

Korzystanie z usługi obsługującej model klasy korporacyjnej

Usługa Mosaic AI Model Serving udostępnia ujednolicony interfejs do wdrażania modeli sztucznej inteligencji, zarządzania nimi i wykonywania zapytań. Każdy model, który służy, jest dostępny jako interfejs API REST, który można zintegrować z aplikacją internetową lub kliencką.

Obsługa modelu zapewnia usługę o wysokiej dostępności i małym opóźnieniu na potrzeby wdrażania modeli. Usługa automatycznie skaluje w górę lub w dół, aby sprostać zmianom zapotrzebowania, oszczędzając koszty infrastruktury podczas optymalizowania wydajności opóźnień. Ta funkcja korzysta z bezserwerowych obliczeń.

3. Projektowanie obciążeń pod kątem wydajności

Omówienie wzorców pozyskiwania i uzyskiwania dostępu do danych

Z punktu widzenia wydajności wzorce dostępu do danych — takie jak "agregacje a dostęp do punktu" lub "skanowanie a wyszukiwanie" — zachowują się inaczej w zależności od rozmiaru danych. Duże pliki są bardziej wydajne w przypadku zapytań skanowania, a mniejsze pliki są lepsze w przypadku wyszukiwań, ponieważ trzeba odczytać mniej danych, aby znaleźć określone wiersze.

W przypadku wzorców pozyskiwania często używa się instrukcji DML. Instrukcje DML są najbardziej wydajne, gdy dane są klastrowane i można po prostu odizolować sekcję danych. Ważne jest, aby zachować grupowanie danych i izolować podczas pozyskiwania: rozważ zachowanie naturalnej kolejności sortowania czasu i zastosowanie jak największej liczby filtrów do tabeli docelowej pozyskiwania. W przypadku obciążeń pozyskiwania tylko do dołączania i zastępowania nie ma zbyt wiele do rozważenia, ponieważ jest to stosunkowo tania operacja.

Wzorce pozyskiwania i dostępu często wskazują oczywisty układ danych i klastrowanie. Jeśli nie, zdecyduj, co jest ważniejsze dla Twojej firmy i skupić się na tym, jak lepiej osiągnąć ten cel.

Korzystanie z obliczeń równoległych, gdy jest korzystne

Czas do wartości to ważny wymiar podczas pracy z danymi. Chociaż wiele przypadków użycia można łatwo zaimplementować na jednej maszynie (małe dane, kilka i proste kroki obliczeniowe), często istnieją przypadki użycia, które wymagają przetwarzania dużych zestawów danych, mają długi czas wykonywania ze względu na skomplikowane algorytmy lub muszą być powtarzane 100 i 1000 razy.

Środowisko klastra platformy Databricks to doskonałe środowisko do wydajnego dystrybuowania tych obciążeń. Automatycznie równoległie wykonuje zapytania SQL we wszystkich węzłach klastra i udostępnia biblioteki dla języków Python i Scala w celu wykonania tych samych czynności. Pod maską aparaty Apache Spark i Photon analizują zapytania, określają optymalny sposób wykonywania równoległego i zarządzają rozproszonym wykonywaniem w odporny sposób.

W taki sam sposób, jak zadania wsadowe, przesyłanie strumieniowe ze strukturą dystrybuuje zadania przesyłania strumieniowego między klastrem w celu uzyskania najlepszej wydajności.

Jednym z najprostszych sposobów korzystania z przetwarzania równoległego jest użycie tabel Delta Live Tables. Zadeklarujesz zadania i zależności zadania w języku SQL lub Python, a następnie usługa Delta Live Tables obsługuje planowanie wykonywania, wydajną konfigurację infrastruktury, wykonywanie zadań i monitorowanie.

Dla analityków danych biblioteka pandas to pakiet języka Python, który zapewnia łatwe w użyciu struktury danych i narzędzia do analizy danych dla języka programowania Python. Jednak biblioteka Pandas nie jest skalowana w poziomie do danych big data. Interfejs API biblioteki Pandas na platformie Spark wypełnia tę lukę, zapewniając równoważne interfejsy API biblioteki pandas działające na platformie Apache Spark.

Ponadto platforma zawiera równoległe algorytmy uczenia maszynowego w standardowej bibliotece uczenia maszynowego MLlib. Obsługuje gotowe do użycia wieloprocesorowe użycie procesora GPU. Uczenie głębokie można również zrównać za pomocą dystrybutora DeepSpeed lub TorchDistributor.

Analizowanie całego łańcucha wykonywania

Większość potoków lub wzorców zużycia obejmuje łańcuch systemów. Na przykład w przypadku narzędzi analizy biznesowej wydajność ma wpływ na kilka czynników:

• Samo narzędzie analizy biznesowej.
• Łącznik, który łączy narzędzie analizy biznesowej i aparat SQL.
• Aparat SQL, do którego narzędzie analizy biznesowej wysyła zapytanie.

Aby uzyskać najlepszą wydajność w klasie, cały łańcuch musi być brany pod uwagę i wybierany/dostrojony w celu uzyskania najlepszej wydajności.

Preferuj większe klastry

Zaplanuj większe klastry, zwłaszcza jeśli obciążenie jest skalowane liniowo. W takim przypadku użycie dużego klastra dla obciążenia nie jest droższe niż użycie mniejszego klastra. To po prostu szybsze. Kluczem jest to, że wynajmujesz klaster przez czas trwania obciążenia. Tak więc, jeśli uruchamiasz dwa klastry procesów roboczych i zajmuje to godzinę, płacisz za tych pracowników za pełną godzinę. Podobnie, jeśli uruchamiasz cztery klastry procesów roboczych i trwa tylko pół godziny (jest to miejsce, w którym występuje liniowa skalowalność), koszty są takie same. Jeśli koszty są podstawowym czynnikiem z bardzo elastyczną umową SLA, klaster skalowania automatycznego jest zwykle najtańszy, ale niekoniecznie najszybszy.

Uwaga

Preferowanie dużych klastrów nie jest wymagane w przypadku obliczeń bezserwerowych, ponieważ automatycznie zarządza klastrami.

Korzystanie z natywnych operacji platformy Spark

Funkcje zdefiniowane przez użytkownika (UDF) to doskonały sposób rozszerzania funkcji platformy Spark SQL. Nie używaj jednak funkcji UDF języka Python ani Scala, jeśli istnieje funkcja natywna:

• Spark SQL
• PySpark

Przyczyny:

• Serializacja jest wymagana do transferu danych między językiem Python i platformą Spark. Znacznie spowalnia to zapytania.
• Zwiększenie nakładu pracy w celu zaimplementowania i przetestowania funkcji, które już istnieją na platformie.

Jeśli brakuje funkcji natywnych i należy je zaimplementować jako funkcje zdefiniowane przez użytkownika języka Python, użyj funkcji UDF biblioteki Pandas. Usługa Apache Arrow zapewnia wydajne przenoszenie danych między platformą Spark i językiem Python.

Korzystanie z aparatów platformy natywnej

Photon to aparat usługi Azure Databricks, który zapewnia szybką wydajność zapytań przy niskich kosztach — od pozyskiwania danych, ETL, przesyłania strumieniowego, nauki o danych i interakcyjnych zapytań — bezpośrednio w usłudze Data Lake. Aplikacja Photon jest zgodna z interfejsami API platformy Apache Spark, więc rozpoczęcie pracy jest tak proste, jak włączanie — brak zmian kodu i brak blokady.

Photon jest częścią środowiska uruchomieniowego o wysokiej wydajności, które uruchamia istniejące wywołania interfejsu API SQL i ramki danych szybciej, zmniejszając całkowity koszt obciążenia. Narzędzie Photon jest domyślnie używane w magazynach SQL usługi Databricks.

Opis sprzętu i typu obciążenia

Nie wszystkie maszyny wirtualne w chmurze są tworzone tak samo. Różne rodziny maszyn oferowanych przez dostawców usług w chmurze są wystarczająco różne, aby mieć znaczenie. Istnieją oczywiste różnice — pamięć RAM i rdzenie — i bardziej subtelne różnice — typ procesora i generacja, gwarancje przepustowości sieci oraz lokalny magazyn o dużej szybkości w porównaniu z dyskiem lokalnym a dyskiem zdalnym. Istnieją również różnice na rynkach "spot". Należy je zrozumieć przed podjęciem decyzji o najlepszym typie maszyny wirtualnej dla obciążenia.

Uwaga

Nie jest to wymagane w przypadku obliczeń bezserwerowych, ponieważ obliczenia bezserwerowe automatycznie zarządzają klastrami.

Korzystanie z buforowania

Buforowanie przechowuje często używane dane na szybszym nośniku, skracając czas potrzebny do ich pobrania w porównaniu z dostępem do oryginalnego źródła danych. Powoduje to mniejsze opóźnienia i szybsze czasy odpowiedzi, co może znacznie poprawić ogólną wydajność i środowisko użytkownika aplikacji. Minimalizując liczbę żądań do oryginalnego źródła danych, buforowanie pomaga zmniejszyć ruch sieciowy i koszty transferu danych. Ten wzrost wydajności może być szczególnie korzystny dla aplikacji korzystających z zewnętrznych interfejsów API lub baz danych z płatnością za użycie. Może pomóc w równomiernym rozłożeniu obciążenia w całym systemie, zapobiegając wąskim gardłom i potencjalnym przestojom.

W usłudze Azure Databricks jest dostępnych kilka typów buforowania. Poniżej przedstawiono cechy poszczególnych typów:

• Korzystanie z pamięci podręcznej dysku

  Pamięć podręczna dysku (wcześniej znana jako "delta cache") przechowuje kopie danych zdalnych na dyskach lokalnych (na przykład SSD) maszyn wirtualnych. Może ona poprawić wydajność dla szerokiego zakresu zapytań, ale nie może służyć do przechowywania wyników dowolnych podzapytania. Pamięć podręczna dysku automatycznie wykrywa, kiedy pliki danych są tworzone lub usuwane i odpowiednio aktualizuje jego zawartość. Zalecanym (i najprostszym) sposobem użycia buforowania dysku jest wybranie typu procesu roboczego z woluminami SSD podczas konfigurowania klastra. Takie procesy robocze są włączone i skonfigurowane do buforowania dysku.

• Unikanie buforowania platformy Spark

  Pamięć podręczna Platformy Spark (przy użyciu poleceń .persist() i .unpersist()) może przechowywać wyniki dowolnych danych podrzędnych i danych przechowywanych w formatach innych niż Parquet (takich jak CSV, JSON i ORC). Jeśli jednak jest używana w nieprawidłowych lokalizacjach w zapytaniu, może zużywać całą pamięć, a nawet znacznie spowalniać zapytania. Jako reguła kciuka unikaj buforowania platformy Spark, chyba że wiesz dokładnie, jaki będzie wpływ.

• Pamięć podręczna wyników zapytań

  Buforowanie wyników zapytań dla wszystkich zapytań za pośrednictwem usługi SQL Warehouse. Aby skorzystać z buforowania wyników zapytania, skoncentruj się na zapytaniach deterministycznych, które na przykład nie używają predykatów, takich jak = NOW(). Gdy zapytanie jest deterministyczne, a dane bazowe są w formacie delta i niezmienione, usługa SQL Warehouse zwróci wynik bezpośrednio z pamięci podręcznej wyników zapytania.

• Buforowanie interfejsu użytkownika sql usługi Databricks

  Buforowanie wszystkich zapytań i starszych pulpitów nawigacyjnych przez użytkownika powoduje wyświetlenie interfejsu użytkownika SQL usługi Databricks.

Używanie kompaktowania

Usługa Delta Lake w usłudze Azure Databricks może zwiększyć szybkość odczytywania zapytań z tabeli. Jednym ze sposobów jest łączenie małych plików w większe. Kompaktowanie jest wyzwalane przez uruchomienie polecenia OPTIMIZE. Zobacz Optymalizowanie układu pliku danych.

Usługa Delta Lake udostępnia opcje automatycznego konfigurowania rozmiaru pliku docelowego dla operacji zapisu i optymalizacji. Usługa Databricks automatycznie dostraja wiele z tych ustawień i umożliwia funkcje, które automatycznie zwiększają wydajność tabeli, szukając plików o odpowiednim rozmiarze:

• Automatyczne kompaktowanie łączy małe pliki w partycjach tabeli delty, aby automatycznie zmniejszyć małe problemy z plikami. Automatyczne kompaktowanie występuje po pomyślnym zakończeniu zapisu w tabeli i uruchomieniu synchronicznie w klastrze, który wykonał zapis. Automatyczne kompaktowanie tylko kompaktuje pliki, które nie zostały wcześniej skompaktowane.
• Zoptymalizowane zapisy zwiększają rozmiar pliku, ponieważ dane są zapisywane, a kolejne operacje odczytu w tabeli są korzystne. Zoptymalizowane zapisy są najbardziej skuteczne w przypadku tabel partycjonowanych, ponieważ zmniejszają liczbę małych plików zapisywanych w każdej partycji.

Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi Delta Lake w celu kontrolowania rozmiaru pliku danych.

Używanie pomijania danych

Pomijanie danych może znacznie poprawić wydajność zapytań, pomijając dane, które nie spełniają kryteriów zapytania. Zmniejsza to ilość danych, które muszą być odczytywane i przetwarzane, co prowadzi do skrócenia czasu wykonywania zapytań.

W tym celu informacje pomijania danych są zbierane automatycznie podczas zapisywania danych w tabeli delty (domyślnie usługa Delta Lake w usłudze Azure Databricks zbiera statystyki dotyczące pierwszych 32 kolumn zdefiniowanych w schemacie tabeli). Usługa Delta Lake w usłudze Azure Databricks używa tych informacji (minimalnych i maksymalnych wartości) w czasie wykonywania zapytań w celu zapewnienia szybszych zapytań. Zobacz Pomijanie danych dla usługi Delta Lake.

Aby uzyskać najlepsze wyniki, należy użyć porządkowania Z, techniki sortowania powiązanych informacji w tym samym zestawie plików. Ta współlokalność jest automatycznie używana w usłudze Azure Databricks przez algorytmy pomijania danych usługi Delta Lake. To zachowanie znacznie zmniejsza ilość danych, które usługa Delta Lake musi odczytywać.

Możesz też użyć nowszego klastra Liquid Clustering, co upraszcza decyzje dotyczące układu danych i optymalizuje wydajność zapytań. Zastąpi partycjonowanie i kolejność z w czasie. Usługa Databricks zaleca płynne klastrowanie dla wszystkich nowych tabel różnicowych. Klaster Liquid zapewnia elastyczność ponownego definiowania kluczy klastrowania bez ponownego zapisywania istniejących danych, dzięki czemu układ danych może ewoluować wraz z potrzebami analitycznymi w czasie. Usługa Databricks zaleca płynne klastrowanie dla wszystkich nowych tabel różnicowych.

Tabele o następujących cechach korzystają z klastrowania płynnego:

• Filtrowane według kolumn z wysoką kardynalnością.
• Z znacznie niesymetrycznym rozkładem danych.
• To szybko rośnie i wymaga nakładu pracy konserwacyjnych i dostrajania.
• W przypadku współbieżnych żądań zapisu.
• W przypadku wzorców dostępu, które zmieniają się wraz z upływem czasu.
• W przypadku, gdy typowy klucz partycji może pozostawić tabelę z zbyt dużą liczbą lub zbyt kilkoma partycjami.

Aby uzyskać więcej szczegółów i technik, zobacz Kompleksowy przewodnik dotyczący optymalizowania obciążeń usługi Databricks, Spark i delta Lake.

Włączanie optymalizacji predykcyjnej dla usługi Delta Lake

Optymalizacja predykcyjna eliminuje konieczność ręcznego zarządzania operacjami konserwacji tabel różnicowych w usłudze Databricks. Po włączeniu optymalizacji predykcyjnej usługa Databricks automatycznie identyfikuje tabele, które będą korzystać z operacji konserwacji i uruchamia je dla użytkownika. Operacje konserwacji są uruchamiane tylko w razie potrzeby, eliminując zarówno niepotrzebne uruchomienia operacji konserwacji, jak i obciążenia związane ze śledzeniem i rozwiązywaniem problemów z wydajnością.

Unikaj nadmiernego partycjonowania

W przeszłości partycjonowanie było najczęstszym sposobem pomijania danych. Jednak partycjonowanie jest statyczne i manifestuje się jako hierarchia systemu plików. Nie ma łatwego sposobu zmiany partycji, ponieważ wzorce dostępu zmieniają się wraz z upływem czasu. Często partycjonowanie prowadzi do nadmiernego partycjonowania — innymi słowy, zbyt wiele partycji z zbyt małymi plikami, co skutkuje niską wydajnością zapytań.

Usługa Databricks zaleca, aby tabele nie dzieliły na partycje poniżej 1 TB rozmiaru, a tylko partycjonowanie według kolumny, jeśli oczekujesz, że dane w każdej partycji będą mieć co najmniej 1 GB.

W międzyczasie lepszym wyborem niż partycjonowanie jest porządkowanie Z lub nowsze klastrowanie liquid (patrz powyżej).

Optymalizowanie wydajności sprzężeń

• Rozważ optymalizację sprzężenia zakresu.

  Sprzężenia zakresu występują, gdy dwa relacje są łączone przy użyciu warunku interwału lub interwału nakładania się. Obsługa optymalizacji sprzężenia zakresu w środowisku Databricks Runtime może przynieść szereg wielkości poprawy wydajności zapytań, ale wymaga starannego dostrajania ręcznego.

• Użyj adaptacyjnego wykonywania zapytań.

  Adaptacyjne wykonywanie zapytań (AQE) to ponowna optymalizacja zapytań wykonywana podczas wykonywania zapytania. Ma 4 główne funkcje:

  • Dynamicznie zmienia sortowanie scalania sprzężenia w sprzężenia skrótu emisji.
  • Dynamicznie łączą partycje po przetasowaniach wymiany.
  • Dynamicznie obsługuje niesymetryczność sprzężenia scalania sortowania i sprzężenia skrótu shuffle.
  • Dynamicznie wykrywa i propaguje puste relacje.

  Zaleca się zachowanie włączonego AQE. Różne funkcje można skonfigurować oddzielnie.

Aby uzyskać więcej informacji, zobacz Kompleksowy przewodnik dotyczący optymalizowania obciążeń usługi Databricks, Spark i Delta Lake.

Uruchamianie analizy tabeli w celu zbierania statystyk tabeli

Instrukcja ANALYZE TABLE zbiera statystyki dotyczące tabel w określonym schemacie. Te statystyki są używane przez optymalizator zapytań do generowania optymalnego planu zapytania, wybierania prawidłowego typu sprzężenia, wybierania prawidłowej strony kompilacji w sprzężeniu skrótu lub kalibrowaniu kolejności sprzężenia w wielostopniowym sprzężeniu.

Aby prawidłowo wykorzystać te optymalizacje zapytań, ANALYZE TABLE polecenie musi być wykonywane regularnie (najlepiej raz dziennie lub gdy dane są zmutowane przez więcej niż 10%, w zależności od tego, co nastąpi wcześniej).

4. Uruchamianie testów wydajnościowych w zakresie programowania

Testowanie danych reprezentatywnych dla danych produkcyjnych

Uruchamianie testów wydajnościowych na danych produkcyjnych (tylko do odczytu) lub podobnych danych. W przypadku korzystania z podobnych danych cechy, takie jak wolumin, układ plików i niesymetryczność danych, powinny być podobne do danych produkcyjnych, ponieważ ma to znaczący wpływ na wydajność.

Rozważ wstępne wdrażanie zasobów

Niezależnie od formatu zapytania i danych pierwsze zapytanie w klastrze jest zawsze wolniejsze niż kolejne zapytania. Dzieje się tak, ponieważ wszystkie różne podsystemy są uruchamiane i odczytują wszystkie potrzebne dane. Wstępne działanie ma znaczący wpływ na wyniki testów wydajnościowych:

• Klastry wstępne: zasoby klastra muszą być inicjowane na wielu warstwach. Możliwe jest wstępne tworzenie klastrów: pule usługi Databricks to zestaw bezczynnych, gotowych do użycia wystąpień. Po utworzeniu węzłów klastra przy użyciu tych bezczynnych wystąpień czas uruchamiania klastra i skalowania automatycznego jest skracany.
• Pamięci podręczne prewarm: podczas buforowania jest częścią konfiguracji, pierwszy przebieg gwarantuje, że dane są w pamięci podręcznej, przyspieszając kolejne zadania. Pamięci podręczne można wstępnie uruchomić, uruchamiając określone zapytania w celu zainicjowania pamięci podręcznych (na przykład po ponownym uruchomieniu klastra). Może to znacznie poprawić wydajność kilku pierwszych zapytań.

Dlatego, aby zrozumieć zachowanie różnych scenariuszy, przetestuj wydajność pierwszego wykonania z prewarmingiem i bez przedwzromienia i kolejnych wykonań.

Identyfikowanie wąskich gardeł

Wąskie gardła to obszary obciążenia, które mogą obniżyć ogólną wydajność w miarę wzrostu obciążenia w środowisku produkcyjnym. Zidentyfikowanie tych elementów w czasie projektowania i testowanie pod kątem wyższych obciążeń pomoże utrzymać stabilność obciążeń w środowisku produkcyjnym.

5. Monitorowanie wydajności

Monitorowanie wydajności zapytań

Monitorowanie wydajności zapytań pomaga zrozumieć, w jaki sposób zasoby są używane przez różne zapytania. Możesz zidentyfikować zapytania, które działają wolno, co pozwala wskazać wąskie gardła wydajności w systemie. Możesz również zidentyfikować zapytania, które zużywają znaczne zasoby systemowe, co potencjalnie prowadzi do niestabilności lub przestojów. Te informacje pomagają zoptymalizować alokację zasobów, zmniejszyć ilość odpadów i zapewnić efektywne wykorzystanie zasobów.

Platforma analizy danych usługi Databricks ma różne możliwości monitorowania (zobacz Doskonałość operacyjna — Konfigurowanie monitorowania, zgłaszania alertów i rejestrowania), z których niektóre mogą być używane do monitorowania wydajności:

• Profil zapytania: użyj funkcji profilu zapytania, aby rozwiązać problemy z wąskimi gardłami wydajności podczas wykonywania zapytań. Udostępnia ona wizualizację każdego zadania zapytania i powiązanych metryk, takich jak czas spędzony, liczba przetworzonych wierszy i używana pamięć.
• Monitorowanie usługi SQL Warehouse: monitorowanie magazynów SQL Przez wyświetlanie statystyk na żywo, wykresów z liczbą zapytań szczytowych, uruchomionych wykresów klastrów i tabeli historii zapytań

Monitorowanie obciążeń przesyłania strumieniowego

Monitorowanie przesyłania strumieniowego umożliwia analizowanie danych i wykrywanie problemów w miarę ich występowania, zapewniając wgląd w wydajność i zachowanie systemu w czasie rzeczywistym. Analizując dane przesyłane strumieniowo, można zidentyfikować trendy, wzorce i możliwości optymalizacji. Może to pomóc w dostosowaniu systemu, poprawie wykorzystania zasobów i zmniejszeniu kosztów.

W przypadku zapytań przesyłanych strumieniowo użyj wbudowanego monitorowania przesyłania strumieniowego ze strukturą w interfejsie użytkownika platformy Spark lub wypychania metryk do usług zewnętrznych przy użyciu interfejsu odbiornika zapytań przesyłania strumieniowego platformy Apache Spark.

Monitorowanie wydajności zadań

Monitorowanie zadań ułatwia identyfikowanie i rozwiązywanie problemów w zadaniach usługi Databricks, takich jak błędy, opóźnienia lub wąskie gardła wydajności. Monitorowanie zadań zapewnia wgląd w wydajność zadań, umożliwiając optymalizację wykorzystania zasobów, zmniejszenie wydajności i poprawę ogólnej wydajności.