Konfigurowanie automatycznego modułu ładującego dla obciążeń produkcyjnych

Usługa Databricks zaleca stosowanie najlepszych rozwiązań dotyczących przesyłania strumieniowego na potrzeby uruchamiania automatycznego modułu ładującego w środowisku produkcyjnym.

Usługa Databricks zaleca używanie automatycznego modułu ładującego w tabelach delta live na potrzeby przyrostowego pozyskiwania danych. Delta Live Tables rozszerza funkcje przesyłania strumieniowego ze strukturą platformy Apache Spark i umożliwia napisanie zaledwie kilku wierszy deklaratywnego języka Python lub sql w celu wdrożenia potoku danych jakości produkcyjnej za pomocą:

• Automatyczne skalowanie infrastruktury obliczeniowej w celu uzyskania oszczędności kosztów
• Sprawdzanie jakości danych z oczekiwaniami
• Automatyczna obsługa ewolucji schematu
• Monitorowanie za pomocą metryk w dzienniku zdarzeń

Monitorowanie automatycznego modułu ładującego

Wykonywanie zapytań dotyczących plików odnalezionych przez moduł automatycznego ładowania

Uwaga

Funkcja cloud_files_state jest dostępna w środowisku Databricks Runtime 11.3 LTS i nowszym.

Moduł automatycznego ładowania udostępnia interfejs API SQL do sprawdzania stanu strumienia. cloud_files_state Za pomocą funkcji można znaleźć metadane dotyczące plików, które zostały odnalezione przez strumień automatycznego modułu ładującego. Wystarczy wysłać zapytanie z cloud_files_stateusługi , podając lokalizację punktu kontrolnego skojarzoną ze strumieniem automatycznego modułu ładującego.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Nasłuchiwanie aktualizacji strumienia

Aby dodatkowo monitorować strumienie automatycznego modułu ładującego, usługa Databricks zaleca korzystanie z interfejsu odbiornika zapytań przesyłania strumieniowego platformy Apache Spark.

Moduł automatycznego ładowania raportuje metryki do odbiornika zapytań przesyłanych strumieniowo w każdej partii. Na liście prac można wyświetlić liczbę plików oraz liczbę dużych list prac w numFilesOutstanding metrykach i numBytesOutstanding na karcie Nieprzetworzone dane na pulpicie nawigacyjnym postępu zapytania przesyłania strumieniowego:

{
  "sources" : [
    {
      "description" : "CloudFilesSource[/path/to/source]",
      "metrics" : {
        "numFilesOutstanding" : "238",
        "numBytesOutstanding" : "163939124006"
      }
    }
  ]
}

W środowisku Databricks Runtime 10.4 LTS i nowszym, w przypadku korzystania z trybu powiadamiania plików metryki będą również zawierać przybliżoną liczbę zdarzeń plików, które znajdują się w kolejce chmury, co approximateQueueSize dotyczy usług AWS i Azure.

Kwestie związane z kosztami

Podczas uruchamiania automatycznego modułu ładującego głównym źródłem kosztów będzie koszt zasobów obliczeniowych i odnajdywania plików.

Aby zmniejszyć koszty obliczeń, usługa Databricks zaleca używanie zadań usługi Databricks do planowania automatycznego modułu ładującego jako zadań wsadowych przy użyciu Trigger.AvailableNow zamiast uruchamiania go w sposób ciągły, o ile nie masz wymagań dotyczących małych opóźnień. Zobacz Konfigurowanie interwałów wyzwalacza przesyłania strumieniowego ze strukturą.

Koszty odnajdywania plików mogą być wykonywane w postaci operacji LIST na kontach magazynu w trybie listy katalogów i żądaniach interfejsu API w usłudze subskrypcji oraz w usłudze kolejki w trybie powiadomień dotyczących plików. Aby zmniejszyć koszty odnajdywania plików, usługa Databricks zaleca:

• Zapewnianie wyzwalacza podczas ciągłego uruchamiania ProcessingTime automatycznego modułu ładującego w trybie listy katalogów
• Tworzenie architektury plików przekazywanych do konta magazynu w kolejności leksykalnej w celu wykorzystania listy przyrostowej (przestarzałej) w miarę możliwości
• Korzystanie z powiadomień dotyczących plików, gdy lista przyrostowa nie jest możliwa
• Tagowanie zasobów utworzonych przez moduł automatycznego ładowania w celu śledzenia kosztów przy użyciu tagów zasobów

Korzystanie z elementu Trigger.AvailableNow i ograniczania szybkości

Uwaga

Dostępne w środowisku Databricks Runtime 10.4 LTS i nowszym.

Automatyczne ładowanie może być zaplanowane do uruchamiania w zadaniach usługi Databricks jako zadania wsadowego przy użyciu polecenia Trigger.AvailableNow. Wyzwalacz AvailableNow nakazuje automatycznemu modułowi ładującemu przetwarzanie wszystkich plików, które dotarły przed godziną rozpoczęcia zapytania. Nowe pliki przekazywane po uruchomieniu strumienia są ignorowane do następnego wyzwalacza.

Dzięki Trigger.AvailableNowfunkcji odnajdywanie plików odbywa się asynchronicznie z przetwarzaniem danych, a dane mogą być przetwarzane w wielu mikrosadach z ograniczeniem szybkości. Automatycznie ładujący domyślnie przetwarza maksymalnie 1000 plików co mikrosadowe. Można skonfigurować cloudFiles.maxFilesPerTrigger i cloudFiles.maxBytesPerTrigger skonfigurować liczbę plików lub liczbę bajtów, które mają być przetwarzane w mikrosadowej partii. Limit plików jest limitem twardym, ale limit bajtów jest limitem miękkim, co oznacza, że można przetworzyć więcej bajtów niż podany maxBytesPerTrigger. Gdy obie opcje są udostępniane razem, moduł ładujący automatycznie przetwarza tyle plików, które są potrzebne do przekroczenia jednego z limitów.

Lokalizacja punktu kontrolnego

Usługa Databricks zaleca ustawienie lokalizacji punktu kontrolnego na lokalizację bez zasad cyklu życia obiektu w chmurze. Jeśli pliki w lokalizacji punktu kontrolnego są czyszczone zgodnie z zasadami, stan strumienia jest uszkodzony. W takim przypadku należy ponownie uruchomić strumień od podstaw.

Przechowywanie zdarzeń

Funkcja automatycznego ładowania śledzi odnalezione pliki w lokalizacji punktu kontrolnego przy użyciu bazy danych RocksDB w celu zapewnienia dokładnie raz gwarancji pozyskiwania. Usługa Databricks zdecydowanie zaleca użycie cloudFiles.maxFileAge opcji dla wszystkich strumieni pozyskiwania dużych lub długotrwałych. Ta opcja wygasa zdarzenia z lokalizacji punktu kontrolnego, co przyspiesza czas uruchamiania automatycznego modułu ładującego. Czas uruchamiania może wzrosnąć do minut na uruchomienie automatycznego modułu ładującego, co powoduje dodanie niepotrzebnych kosztów, gdy masz górną granicę maksymalnego wieku plików, które będą przechowywane w katalogu źródłowym. Minimalna wartość, dla której można ustawić cloudFiles.maxFileAge wartość to "14 days". Usunięcia w bazie danych RocksDB są wyświetlane jako wpisy na skutek tego, że użycie magazynu powinno zostać tymczasowo zwiększone, ponieważ zdarzenia wygasają, zanim zacznie się obniżać.

Ostrzeżenie

cloudFiles.maxFileAge jest dostarczany jako mechanizm kontroli kosztów dla zestawów danych o dużej ilości. Dostrajanie cloudFiles.maxFileAge zbyt agresywnie może powodować problemy z jakością danych, takie jak zduplikowane pozyskiwanie lub brakujące pliki. W związku z tym usługa Databricks zaleca ustawienie konserwatywne dla usługi cloudFiles.maxFileAge, takie jak 90 dni, co jest podobne do zalecanych porównywalnych rozwiązań do pozyskiwania danych.

Próba dostosowania cloudFiles.maxFileAge opcji może prowadzić do ignorowania nieprzetworzonych plików przez moduł automatycznego ładowania lub już przetworzonych plików wygasających, a następnie ponownego przetworzenia powodującego zduplikowanie danych. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas wybierania elementu cloudFiles.maxFileAge:

• Jeśli strumień zostanie uruchomiony ponownie po długim czasie, zdarzenia powiadomień plików pobierane z kolejki, które są starsze niż cloudFiles.maxFileAge są ignorowane. Podobnie, jeśli używasz listy katalogów, pliki, które mogły pojawić się w czasie krótszym niż są cloudFiles.maxFileAge ignorowane.
• Jeśli używasz trybu listy katalogów i użyjesz cloudFiles.maxFileAgepolecenia , na przykład ustaw "1 month"wartość , zatrzymasz strumień i uruchom ponownie strumień z ustawioną wartością cloudFiles.maxFileAge "2 months", pliki starsze niż 1 miesiąc, ale nowsze niż 2 miesiące zostaną ponownie przetworzone.

Jeśli ustawisz tę opcję przy pierwszym uruchomieniu strumienia, nie pozyskujesz danych starszych niż cloudFiles.maxFileAge, dlatego jeśli chcesz pozyskać stare dane, nie należy ustawić tej opcji podczas pierwszego uruchamiania strumienia. Należy jednak ustawić tę opcję w kolejnych uruchomieniach.

Wyzwalanie regularnych wypełniania przy użyciu pliku cloudFiles.backfillInterval

Automatyczne moduł ładujący może wyzwalać asynchroniczne wypełnianie w danym interwale, na przykład jeden dzień do wypełniania danych raz dziennie lub jeden tydzień w celu wypełniania kopii zapasowych raz w tygodniu. Systemy powiadomień o zdarzeniach plików nie gwarantują dostarczenia 100% wszystkich plików, które zostały przekazane i nie zapewniają ścisłych umów SLA dotyczących opóźnienia zdarzeń plików. Usługa Databricks zaleca, aby wyzwalać regularne wypełnianie za pomocą modułu automatycznego ładującego przy użyciu cloudFiles.backfillInterval opcji zagwarantowania, że wszystkie pliki zostaną odnalezione w ramach danej umowy SLA, jeśli wymagana jest kompletność danych. Wyzwalanie regularnych wypełniania nie powoduje duplikatów.