Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące przetwarzania bezserwerowego

Postępuj zgodnie z tymi zaleceniami, aby zmaksymalizować produktywność, zmniejszyć koszty i zwiększyć niezawodność podczas korzystania z bezserwerowych obliczeń dla notesów, zadań i potoków w usłudze Azure Databricks.

Migrowanie obciążeń do obliczeń bezserwerowych

Aby zapewnić izolację kodu użytkownika w udostępnionym środowisku obliczeniowym bezserwerowym , usługa Azure Databricks korzysta z usługi Lakeguard, aby odizolować kod użytkownika od aparatu Spark i innych użytkowników.

W związku z tym niektóre obciążenia wymagają zmian kodu w celu kontynuowania pracy nad obliczeniami bezserwerowymi. Aby uzyskać listę ograniczeń, zobacz Ograniczenia obliczeniowe bezserwerowe.

Niektóre obciążenia są łatwiejsze do migracji niż inne. Obciążenia spełniające następujące wymagania będą najłatwiejsze do zmigrowania:

  • Uzyskiwane dane muszą być przechowywane w Unity Catalog.
  • Obciążenie powinno być zgodne ze standardowymi obliczeniami.
  • Obciążenie powinno być zgodne z środowiskiem Databricks Runtime 14.3 lub nowszym.

Aby sprawdzić, czy obciążenie będzie działać na obliczeniach bezserwerowych, uruchom je w klasycznym zasobie obliczeniowym z trybem dostępu w warstwie Standardowa i środowiskiem Databricks Runtime w wersji 14.3 lub nowszej. Jeśli przebieg zakończy się pomyślnie, obciążenie jest gotowe do migracji.

Usługa Azure Databricks zaleca ustalanie priorytetów zgodności obliczeń bezserwerowych podczas tworzenia nowych obciążeń. W przypadku istniejących obciążeń, które wymagają zmian w kodzie, migruj je przyrostowo jako część regularnego cyklu programowania i konserwacji.

Określanie wersji pakietów języka Python

Podczas migracji do obliczeń bezserwerowych przypnij pakiety języka Python do określonych wersji, aby zapewnić powtarzalne środowiska. Jeśli nie określisz wersji, pakiet może rozpoznać inną wersję na podstawie wersji środowiska bezserwerowego, co może zwiększyć opóźnienie, ponieważ należy zainstalować nowe pakiety.

Na przykład plik requirements.txt powinien zawierać określone wersje pakietów, takie jak:

numpy==2.2.2
pandas==2.2.3

Używanie unikatowych nazw dla widoków tymczasowych

Obliczenia bezserwerowe używają platformy Spark Connect— architektury klient-serwer, która ocenia tymczasowe widoki leniwie. To zachowanie różni się od klasycznej architektury platformy Spark i może powodować błędy, gdy kod ponownie używa tej samej tymczasowej nazwy widoku, na przykład w pętli.

Aby uniknąć błędów, użyj unikatowych nazw dla wszystkich widoków tymczasowych w kodzie.

Sieć i łączność

Przetwarzanie bezserwerowe nie obsługuje peeringu VPC, co jest typowym sposobem łączenia klasycznego systemu obliczeniowego Databricks ze źródłami danych w Twoim koncie chmurowym. Alternatywnie można użyć konfiguracji łączności sieciowej do zarządzania punktami końcowymi, zaporami i łącznością z usługami zewnętrznymi.

Na przykład można dodać zestaw stabilnych adresów IP ruchu wychodzącego w zewnętrznych sieciach VPC do listy dozwolonych, aby umożliwić dwukierunkową łączność z bezserwerowym obliczeniem usługi Azure Databricks. Aby nawiązać połączenie z aplikacjami dla przedsiębiorstw (takimi jak Salesforce) lub zarządzanymi bazami danych (takimi jak MySQL), użyj narzędzia Lakeflow Connect.

Aby ograniczyć i monitorować ruch wychodzący z zasobów obliczeniowych bezserwerowych, skonfiguruj kontrolki ruchu wychodzącego dla obszaru roboczego. Zobacz Zarządzaj zasadami sieciowymi dla kontroli ruchu wychodzącego w środowisku bezserwerowym.

Wersje środowiska bezserwerowego

Środowisko obliczeniowe bezserwerowe używa wersji środowiska zamiast tradycyjnych wersji środowiska Databricks Runtime. Oznacza to zmianę sposobu zarządzania zgodnością obciążeń:

  • Podejście do środowiska Databricks Runtime: wybierz określoną wersję środowiska Databricks Runtime dla obciążenia i ręcznie zarządzaj uaktualnieniami, aby zachować zgodność.
  • Podejście bezserwerowe: kod jest pisany względem wersji środowiska, a usługa Azure Databricks niezależnie uaktualnia bazowy serwer.

Wersje środowiska zapewniają stabilny interfejs API klienta, który zapewnia zgodność obciążenia, podczas gdy usługa Azure Databricks niezależnie zapewnia ulepszenia wydajności, ulepszenia zabezpieczeń i poprawki błędów bez konieczności wprowadzania zmian kodu w obciążeniach.

Każda wersja środowiska zawiera zaktualizowane biblioteki systemowe, funkcje i poprawki błędów przy zachowaniu zgodności z poprzednimi wersjami obciążeń. Usługa Azure Databricks obsługuje każdą wersję środowiska przez trzy lata od daty wydania, zapewniając przewidywalny cykl życia planowania uaktualnień.

Aby wybrać środowisko podstawowe dla obciążenia bezserwerowego, zobacz Wybieranie środowiska podstawowego. Aby uzyskać szczegółowe informacje o dostępnych wersjach środowiska i ich funkcjach, zobacz Wersje środowiska bezserwerowego.

Zarządzanie zależnościami

Obliczenia bezserwerowe nie obsługują skryptów inicjowania. Zamiast tego użyj środowisk bezserwerowych , aby zainstalować biblioteki dla obciążeń bezserwerowych i zarządzać nimi. Środowiska buforują zainstalowane pakiety, co zmniejsza opóźnienie uruchamiania dla kolejnych uruchomień.

Aby używać bibliotek z repozytorium prywatnego, skonfiguruj wstępnie podpisane adresy URL na potrzeby dostępu do uwierzytelnionego repozytorium w ustawieniach środowiska.

Wybieranie trybu wydajności

Przetwarzanie bezserwerowe usługi Azure Databricks oferuje dwa tryby wydajności, które umożliwiają równoważenie szybkości i kosztów na podstawie typu obciążenia w następujący sposób:

  • Tryb zoptymalizowany pod kątem wydajności (wartość domyślna): najlepiej sprawdza się w przypadku obciążeń interaktywnych wymagających szybkich czasów uruchamiania. Usługa Azure Databricks zapewnia pulę ciepłych zasobów obliczeniowych gotowych do zminimalizowania czasu oczekiwania.
  • Tryb standardowy: najlepszy w przypadku zautomatyzowanych zadań wsadowych i potoków, które mogą tolerować dłuższe czasy uruchamiania od 4 do 6 minut. Tryb standardowy może obniżyć koszty o maksymalnie 70% w porównaniu z trybem zoptymalizowanym pod kątem wydajności. Tryb standardowy jest dostępny dla Lakeflow Jobs i potoków deklaratywnych Lakeflow Spark, ale nie dla notebooków.

Wybierz tryb najlepiej zgodny z wymaganiami dotyczącymi obciążenia. W przypadku zaplanowanych zadań, w których opóźnienie uruchamiania nie jest krytyczne, tryb standardowy zwykle oferuje najlepszą wartość. Aby uzyskać bieżące szczegóły cennika, zobacz stronę cennika usługi Databricks.

Optymalizowanie obciążeń przesyłania strumieniowego

Przetwarzanie bezserwerowe obsługuje przesyłanie strumieniowe z użyciem struktur z następującymi względami:

  • Tryb Trigger.AvailableNow wyzwalacza jest obsługiwany dla wszystkich zadań bezserwerowych i potoków. Interwały wyzwalacza oparte na czasie nie są obsługiwane.

  • W przypadku korzystania z Trigger.AvailableNow, każdy wyzwalacz przetwarza wszystkie dostępne dane w źródle, co może spowodować powstanie większych mikro-batów niż wyzwalacz oparty na czasie. Aby zapobiec błędom braku pamięci i zachować przewidywalną wydajność, ogranicz ilość danych przetwarzanych w każdej mikroszeregacji przez ustawienie maxFilesPerTrigger lub maxBytesPerTrigger.

Debugowanie obciążeń bezserwerowych

Interfejs użytkownika platformy Spark nie jest dostępny w obliczeniach bezserwerowych. Zamiast tego użyj profilu zapytania, aby analizować wydajność zapytań i rozwiązywać problemy z obciążeniami. Profil zapytania zawiera szczegółowe informacje dotyczące wykonywania i jest dostępny z historii zapytań w interfejsie użytkownika usługi Azure Databricks.

Pozyskiwanie danych z systemów zewnętrznych

Alternatywne strategie, których można użyć do spożycia, obejmują:

Alternatywy pozyskiwania

W przypadku korzystania z obliczeń bezserwerowych można również użyć następujących funkcji, aby wykonywać zapytania dotyczące danych bez ich przenoszenia.

  • Jeśli chcesz ograniczyć duplikowanie danych lub zagwarantować, że wykonujesz zapytania dotyczące najświeższych możliwych danych, Databricks zaleca korzystanie z Delta Sharing. Zobacz Co to jest Delta Sharing?.
  • W przypadku pracy z raportowaniem ad hoc i weryfikacją koncepcji Lakehouse Federation umożliwia wykonywanie zapytań do zewnętrznych baz danych bezpośrednio z Azure Databricks, bez konieczności przenoszenia danych, zarządzanych przez Unity Catalog. Zobacz Co to jest Federacja Lakehouse?.

Wypróbuj jedną lub obie te funkcje i sprawdź, czy spełniają wymagania dotyczące wydajności zapytań.

Nieobsługiwane ujścia

Jeśli system docelowy nie jest obsługiwany jako bezpośredni cel zapisu z bezserwerowych obliczeń, możesz użyć katalogu Iceberg w Unity Catalog, aby umożliwić temu systemowi bezpośrednie odczytywanie z tabel usługi Azure Databricks. Na przykład Snowflake nie jest obsługiwaną destynacją bezserwerową, ale można go skonfigurować jako klienta Iceberg do odczytywania tabel zarządzanych przez Unity Catalog.

Takie podejście pozwala uniknąć duplikowania danych i utrzymuje katalog Unity jako warstwę zarządzania dla wszystkich operacji odczytu. Aby uzyskać informacje o obsługiwanych klientach i krokach konfiguracji, zobacz Access Azure Databricks tables from Apache Iceberg clients (Uzyskiwanie dostępu do tabel usługi Azure Databricks z klientów platformy Apache Iceberg).

Obsługiwane konfiguracje platformy Spark

Aby zautomatyzować konfigurację platformy Spark na obliczeniach bezserwerowych, usługa Azure Databricks usunęła obsługę ręcznego ustawiania większości konfiguracji platformy Spark. Aby wyświetlić listę obsługiwanych parametrów konfiguracji platformy Spark, zobacz Konfigurowanie właściwości platformy Spark dla notesów i zadań bezserwerowych.

Wykonanie zadania na bezserwerowym środowisku obliczeniowym zakończy się niepowodzeniem, jeśli ustawisz nieobsługiwaną konfigurację platformy Spark.

Monitorowanie kosztów obliczeń bezserwerowych

Istnieje wiele funkcji, których można użyć, aby ułatwić monitorowanie kosztów obliczeń bezserwerowych:

  • Last updated on