Rozwiązywanie problemu z długimi czasami inicjalizacji w potokach

Potoki mogą zawierać wiele zestawów danych z wieloma przepływami, aby zapewnić ich aktualność. Rury przetwarzania automatycznie zarządzają aktualizacjami i aktualizacjami klastrów, aby je wydajnie przeprowadzać. Istnieje jednak pewne obciążenie związane z zarządzaniem dużą liczbą przepływów i czasami może to prowadzić do większych niż oczekiwano inicjowania, a nawet obciążeń związanych z zarządzaniem podczas przetwarzania.

Jeśli wystąpią opóźnienia związane z oczekiwaniem na zainicjowanie wyzwolonych potoków, takie jak czasy inicjowania przekraczające pięć minut, rozważ podzielenie procesu przetwarzania na kilka potoków, nawet jeśli zestawy danych używają tych samych danych źródłowych.

Kiedy należy rozważyć podzielenie przepływu danych

Istnieje kilka przypadków, w których dzielenie potoku może być korzystne ze względu na wydajność.

• Fazy INITIALIZING i SETTING_UP_TABLES trwają dłużej niż byś chciał, co wpływa na ogólny czas pipeline'u. Jeśli trwa to ponad 5 minut, często można poprawić jego wydajność przez podzielenie pipeline'u.
• Sterownik, który zarządza klastrem, może stać się wąskim gardłem podczas uruchamiania wielu (ponad 30–40) tabel przesyłania strumieniowego w jednym potoku. Jeśli twój sterownik nie odpowiada, czas trwania zapytań przesyłanych strumieniowo wzrośnie, co będzie miało wpływ na całkowity czas aktualizacji.
• Wyzwolony potok z kilkoma przepływami tabel strumieniowych może nie być w stanie wykonać wszystkich aktualizacji strumieniowych równocześnie.

Szczegółowe informacje o problemach z wydajnością

W tej sekcji opisano niektóre problemy z wydajnością, które mogą wynikać z wielu tabel i przepływów w jednym potoku.

Wąskie gardła w fazach INICJOWANIA i KONFIGUROWANIA_TABEL

Początkowe fazy uruchomienia mogą być wąskim gardłem wydajności, w zależności od złożoności procesu.

Faza INICJOWANIA

W tej fazie tworzone są plany logiczne, w tym plany tworzenia grafu zależności i określania kolejności aktualizacji tabeli.

faza KONFIGURACJI_TABEL

W tej fazie są wykonywane następujące procesy na podstawie planów utworzonych w poprzedniej fazie:

• Sprawdzanie poprawności schematu i rozpoznawanie wszystkich tabel zdefiniowanych w potoku.
• Skompiluj wykres zależności i określ kolejność wykonywania tabeli.
• Sprawdź, czy każdy zestaw danych jest aktywny w potoku lub jest nowy od ostatniej aktualizacji.
• Utwórz tabele strumieniowe w pierwszej aktualizacji, a dla widoków zmaterializowanych utwórz widoki tymczasowe lub tabele zapasowe wymagane podczas każdej aktualizacji potoku.

Dlaczego inicjowanie i ustawianie_tabel może trwać dłużej

Duże potoki z wieloma przepływami dla wielu zestawów danych mogą trwać dłużej z kilku powodów:

• W przypadku potoków z wieloma przepływami i złożonymi zależnościami te fazy mogą potrwać dłużej z powodu ilości pracy.
• Złożone przekształcenia, w tym Auto CDC przekształcenia, mogą powodować ograniczenia wydajności ze względu na operacje wymagane do zmaterializowania tabel na podstawie zdefiniowanych przekształceń.
• Istnieją również scenariusze, w których znaczna liczba przepływów może powodować spowolnienie, nawet jeśli te przepływy nie są częścią aktualizacji. Rozważmy na przykład zespół procesów, który ma ponad 700 przepływów danych, z których mniej niż 50 jest aktualizowanych dla każdego wyzwalacza na podstawie konfiguracji. W tym przykładzie każde wykonanie musi przejść przez niektóre kroki dla wszystkich 700 tabel, pobrać dane w postaci dataframes, a następnie wybrać te procesy do uruchomienia.

Wąskie gardła w sterowniku

Sterownik zarządza aktualizacjami w trakcie działania. Musi wykonać pewną logikę dla każdej tabeli, aby zdecydować, które wystąpienia w klastrze powinny obsługiwać każdy przepływ. W przypadku uruchamiania kilku (ponad 30–40) tabel przesyłania strumieniowego w jednym potoku sterownik może stać się wąskim gardłem dla zasobów procesora CPU, ponieważ obsługuje pracę w klastrze.

Sterownik może również napotkać problemy z pamięcią. Może się to zdarzyć częściej, gdy liczba przepływów równoległych wynosi 30 lub więcej. Nie ma określonej liczby przepływów lub zestawów danych, które mogą powodować problemy z pamięcią sterownika, ale zależy od złożoności zadań, które są uruchomione równolegle.

Przepływy przesyłania strumieniowego mogą być uruchamiane równolegle, ale wymaga to, aby sterownik używał pamięci i procesora dla wszystkich strumieni jednocześnie. W wyzwalanym potoku przetwarzania mechanizm może jednocześnie przetwarzać podzestaw strumieni, aby uniknąć ograniczeń pamięci i procesora.

We wszystkich tych przypadkach dzielenie potoków w celu zapewnienia optymalnego zestawu przepływów w każdym z nich może przyspieszyć inicjowanie i czas przetwarzania.

Kompromisy w podziale potoków

Gdy wszystkie przepływy znajdują się w tym samym potoku, usługa Lakeflow Spark Deklaratywne potoki zarządza zależnościami. W przypadku wielu potoków należy zarządzać zależnościami między potokami.

• Zależności Może istnieć potok podrzędny, który zależy od wielu potoków nadrzędnych (zamiast jednego). Na przykład, jeśli masz trzy potoki, pipeline_A, pipeline_B i pipeline_C, a pipeline_C zależy od pipeline_A i pipeline_B, chcesz, aby pipeline_C zostało zaktualizowane tylko po zakończeniu odpowiednich aktualizacji przez pipeline_A i pipeline_B. Jednym ze sposobów rozwiązania tego problemu jest orkiestracja zależności poprzez uczynienie każdego potoku zadaniem w zadaniu z prawidłowym odwzorowaniem zależności, tak aby pipeline_C aktualizował się tylko po ukończeniu zarówno pipeline_A, jak i pipeline_B.

• Współbieżność W ramach potoku mogą występować różne przepływy, które zajmują bardzo różny czas na ukończenie, na przykład gdy flow_A aktualizuje się w 15 sekund, a flow_B trwa kilka minut. Warto przyjrzeć się czasom zapytań przed podzieleniem potoków i zgrupować krótsze zapytania.

Planowanie dzielenia potoków

Przed rozpoczęciem możesz wizualizować podział potoku. Oto wykres kanału źródłowego, który przetwarza 25 tabel. Jedno główne źródło danych jest podzielone na 8 segmentów, z których każdy ma 2 widoki.

Po podzieleniu potoku istnieją dwa potoki. Jeden z nich przetwarza pojedyncze główne źródło danych oraz 4 segmenty i skojarzone widoki. Drugi rurociąg przetwarza pozostałe 4 segmenty i skojarzone z nimi widoki. Druga rura polega na pierwszej, aby zaktualizować główne źródło danych.

Podział rurociągu bez pełnego przeładowania

Po zaplanowaniu podziału potoku utwórz potrzebne nowe potoki i przenieś tabele między potokami, aby zrównoważyć obciążenie potoku. Tabele można przenosić bez powodowania pełnego odświeżania.

Aby zapoznać się ze szczegółami, zobacz Przenoszenie tabel między potokami.

Istnieją pewne ograniczenia dotyczące tego podejścia:

• Przepływy danych muszą być w Unity Catalog.
• Potoki źródłowe i docelowe muszą znajdować się w tym samym obszarze roboczym. Przesuwanie między obszarami roboczymi nie jest obsługiwane.
• Potok docelowy należy utworzyć i uruchomić raz (nawet jeśli zakończy się niepowodzeniem) przed przeniesieniem.
• Nie można przenieść tabeli z pipeline’u, który używa domyślnego trybu publikowania, do tego, który używa starszego trybu publikowania. Aby uzyskać więcej informacji, zobacz LIVE schema (starsza wersja).