Skonfiguruj Auto Loader dla obciążeń produkcyjnych

Usługa Databricks zaleca stosowanie najlepszych praktyk dotyczących przesyłania strumieniowego na potrzeby uruchamiania Auto Loader w środowisku produkcyjnym.

Databricks zaleca używanie Auto Loader w deklaratywnych potokach w Lakeflow Spark dla przyrostowego pozyskiwania danych. Deklaratywne potoki Lakeflow Spark rozszerzają funkcjonalność Strukturalnego strumieniowania Apache Spark i umożliwiają pisanie zaledwie kilku wierszy deklaratywnego języka Python lub SQL w celu wdrożenia potoku danych o jakości produkcyjnej za pomocą następujących elementów:

• Automatyczne skalowanie infrastruktury obliczeniowej w celu uzyskania oszczędności kosztów
• Sprawdzanie jakości danych zgodnie 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

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

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

Nasłuchiwanie aktualizacji strumienia

Aby dodatkowo monitorować strumienie Auto Loader, usługa Databricks zaleca korzystanie z interfejsu nasłuchiwacza zapytań strumieniowych platformy Apache Spark.

Moduł automatycznego ładowania raportuje metryki do odbiornika zapytań przesyłanych strumieniowo w każdej partii. W panelu postępu zapytania przesyłania strumieniowego możesz wyświetlić, ile plików znajduje się w zaległościach i jak duże są te zaległości w metrykach numFilesOutstanding i numBytesOutstanding na karcie Nieprzetworzone dane.

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

W środowisku Databricks Runtime 10.4 LTS i nowszym, podczas korzystania z trybu powiadomień plików, metryki obejmują również przybliżoną liczbę zdarzeń plików w kolejce chmury, zarówno dla AWS, jak i Azure.

Zagadnienia dotyczące kosztów

Podczas uruchamiania automatycznego modułu ładującego główne źródła kosztów to zasoby obliczeniowe i odnajdywanie plików.

Aby zmniejszyć koszty obliczeniowe, Databricks zaleca używanie Lakeflow Jobs do planowania Auto Loader jako zadań wsadowych przy użyciu Trigger.AvailableNow, zamiast uruchamiania go w sposób ciągły, o ile nie masz wymagań dotyczących niskich opóźnień. Zobacz Konfigurowanie interwałów wyzwalania w przesyłaniu strumieniowym (Structured Streaming). Te zadania wsadowe mogą być wyzwalane przy użyciu wyzwalaczy przybycia plików , aby jeszcze bardziej zmniejszyć opóźnienie między przybyciem pliku a przetwarzaniem.

Koszty odnajdywania plików mogą występować w formie operacji LIST na Twoich kontach magazynowych w trybie listy katalogów oraz w żądaniach interfejsu API w usłudze subskrypcji i w usłudze kolejki w trybie powiadomień dotyczących plików. Aby zmniejszyć koszty odnajdywania plików, usługa Databricks zaleca:

• Nie używaj wyzwalaczy ProcessingTime lub Continuous podczas ciągłego uruchamiania Auto Loader w trybie listy katalogów. Zamiast tego użyj automatycznego modułu ładującego ze zdarzeniami plików . Aby uzyskać szczegółowe informacje na temat działania automatycznego modułu ładującego ze zdarzeniami plików, zobacz Auto loader with file events overview (Automatyczne ładowanie z zdarzeniami plików — omówienie).
• Użyj trybu powiadomień plików w trybie legacy, jeśli nie możesz korzystać z Auto Loader z obsługą zdarzeń plików. W tym trybie można tagować zasoby utworzone przez moduł automatycznego ładowania w celu śledzenia kosztów przy użyciu tagów zasobów.

Archiwizowanie plików w katalogu źródłowym w celu obniżenia kosztów

Zalecamy użycie automatycznego modułu ładującego z zdarzeniami plików w celu obniżenia kosztów odnajdywania. Obniża to również koszty obliczeń, ponieważ odnajdywanie jest przyrostowe.

Jeśli nie możesz korzystać ze zdarzeń plików i musisz użyć listy katalogów do odnajdywania plików, możesz skorzystać z opcji cloudFiles.cleanSource umożliwiającej automatyczne archiwizowanie lub usuwanie plików po procesie Auto Loader w celu obniżenia kosztów odnajdywania. Ponieważ Auto Loader czyści pliki z katalogu źródłowego po przetworzeniu, mniej plików musi być wymienianych podczas odkrywania.

W przypadku korzystania cloudFiles.cleanSource z opcji MOVE należy wziąć pod uwagę następujące wymagania:

• Zarówno katalog źródłowy, jak i docelowy katalog przenoszenia muszą znajdować się w tej samej lokalizacji zewnętrznej lub woluminie.
• Jeśli katalog źródłowy i docelowy znajdują się w tej samej lokalizacji zewnętrznej, nie powinny mieć katalogów równorzędnych zawierających magazyn zarządzany (na przykład wolumin zarządzany lub wykaz). W takich przypadkach Auto Loader nie może uzyskać niezbędnych uprawnień do zapisu w folderze docelowym.

Usługa Databricks zaleca użycie tej opcji, gdy:

• Katalog źródłowy gromadzi dużą liczbę plików z biegiem czasu.
• Należy zachować przetworzone pliki dla celów zgodności lub audytu (ustaw cloudFiles.cleanSource na MOVE).
• Chcesz zmniejszyć koszty magazynowania, usuwając pliki po załadowaniu (ustaw wartość na cloudFiles.cleanSourceDELETE). W przypadku korzystania z trybu DELETE, Databricks zaleca włączenie wersjonowania na zasobniku, aby funkcja Auto Loader działała jako tymczasowe usuwanie, dostępne w przypadku błędnej konfiguracji. Ponadto usługa Databricks zaleca skonfigurowanie zasad cyklu życia chmury w celu usunięcia starych wersji, które zostały miękko usunięte, po określonym okresie karencji (np. 60 lub 90 dni), w zależności od wymagań dotyczących odzyskiwania.

Korzystanie z elementu Trigger.AvailableNow i ograniczania szybkości

Automatyczne ładowanie może być zaplanowane do uruchamiania w zadaniach Lakeflow 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 przesyłane po rozpoczęciu strumienia są ignorowane do momentu aktywacji 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. Auto Loader domyślnie przetwarza maksymalnie 1000 plików na każdą mikropartię. Można ustawić cloudFiles.maxFilesPerTrigger i cloudFiles.maxBytesPerTrigger, aby skonfigurować, ile plików lub bajtów ma być przetwarzanych w mikropartii. 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

Lokalizacja punktu kontrolnego służy do przechowywania informacji o stanie i postępie strumienia. Usługa Databricks zaleca ustawienie lokalizacji punktu kontrolnego w miejscu bez polityki cyklu życia obiektów chmurowych. Jeśli pliki w lokalizacji punktu kontrolnego są czyszczone zgodnie z polityką, stan strumienia jest uszkodzony. W takim przypadku należy ponownie uruchomić strumień od podstaw.

Śledzenie zdarzeń plików

Auto Loader śledzi odnalezione pliki w lokalizacji punktu kontrolnego przy użyciu bazy danych RocksDB, aby zapewnić gwarancję dokładnie jednorazowego pozyskiwania. W przypadku strumieni danych o dużej objętości lub długiej żywotności, Databricks zaleca uaktualnienie do Databricks Runtime 15.4 LTS lub nowszego. W tych wersjach funkcja automatycznego ładowania nie czeka na pobranie całego stanu bazy danych RocksDB przed rozpoczęciem strumienia, co może przyspieszyć czas uruchamiania strumienia. Jeśli chcesz zapobiec zwiększaniu się stanów plików bez ograniczeń, możesz również rozważyć użycie cloudFiles.maxFileAge opcji wygasania zdarzeń plików starszych niż określony wiek. Minimalna wartość, którą można ustawić dla cloudFiles.maxFileAge, to "14 days". Usunięcia w RocksDB pojawiają się jako wpisy nagrobkowe. W związku z tym możesz zauważyć tymczasowy wzrost wykorzystania magazynu, ponieważ zdarzenia wygasają, zanim zacznie się stabilizować.

Próba dostosowania opcji cloudFiles.maxFileAge może spowodować, że Auto Loader zignoruje nieprzetworzone pliki lub przetworzone już pliki wygasną, a następnie zostaną ponownie przetworzone, co prowadzi do zduplikowania danych. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas wybierania elementu cloudFiles.maxFileAge:

• Jeśli po dłuższym czasie strumień zostanie uruchomiony ponownie, 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ę podczas przestoju i są starsze niż cloudFiles.maxFileAge, są ignorowane.
• Jeśli używasz trybu listy katalogów i polecenia cloudFiles.maxFileAge, na przykład ustawiając na "1 month", zatrzymasz strumień i uruchomisz go ponownie z ustawieniem cloudFiles.maxFileAge na "2 months", pliki, które są starsze niż 1 miesiąc, ale nie starsze 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.

Wyzwalaj regularne uzupełnienia zaległości przy użyciu ustawienia cloudFiles.backfillInterval

W rzadkich przypadkach pliki mogą zostać pominięte lub opóźnione w zależności od systemów powiadomień, takich jak osiągnięcie limitów przechowywania komunikatów powiadomień. Jeśli masz rygorystyczne wymagania dotyczące kompletności danych i SLA, rozważ ustawienie cloudFiles.backfillInterval do uruchamiania asynchronicznych uzupełnień danych w określonych odstępach czasu. Na przykład ustaw go na jeden dzień dla codziennych uzupełnień lub tydzień dla tygodniowych uzupełnień. Uruchamianie regularnych wypełnień nie powoduje duplikatów.

W przypadku korzystania ze zdarzeń plików uruchom strumień co najmniej raz na 7 dni

W przypadku korzystania ze zdarzeń plików uruchom strumienie Auto Loader co najmniej raz na 7 dni, aby uniknąć konieczności generowania pełnej listy katalogów. Uruchamianie strumieni Auto Loadera z taką częstotliwością zapewni, że odnajdywanie plików jest przyrostowe.

Aby uzyskać kompleksowe najlepsze praktyki dotyczące zarządzanych zdarzeń plików, zobacz Najlepsze praktyki dla modułu Auto Loader z wydarzeniami plików.