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.

Usługa Databricks zaleca używanie "Auto Loader" w potokach deklaratywnych Lakeflow w celu przyrostowego pozyskiwania danych. Potoki deklaratywne Lakeflow rozszerzają funkcjonalność Structured Streaming w Apache Spark i umożliwiają pisanie zaledwie kilku wierszy deklaratywnego kodu w Pythonie lub SQL do wdrożenia potoku danych jakości produkcyjnej.

• 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

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. 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, 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 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).

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:

• 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
• Wykorzystywanie powiadomień dotyczących plików wtedy, gdy niemożliwe jest wykorzystanie listy przyrostowej
• Użycie tagów zasobów do oznaczania zasobów utworzonych przez Auto Loader w celu śledzenia kosztó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 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ć.

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 Databricks rekomenduje ustawienie konserwatywne dla cloudFiles.maxFileAge, takie jak 90 dni, co jest podobne do zaleceń porównywalnych rozwiązań do pozyskiwania danych.

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.