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 DLT do ładowania danych przyrostowych. Biblioteka DLT rozszerza funkcjonalność przesyłania strumieniowego w ramach Apache Spark Structured Streaming i umożliwia napisanie zaledwie kilku wierszy deklaratywnego kodu w języku Python lub SQL, aby wdrożyć potok danych o jakości produkcyjnej za pomocą:

• 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 dokładniej monitorować strumienie Auto Loader, Databricks zaleca używanie interfejsu słuchacza zapytań strumieniowych 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 obliczeń, usługa Databricks zaleca korzystanie z zadań Databricks do planowania Auto Loader jako zadań wsadowych przy wykorzystaniu 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 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 uruchomienia w zadaniach Databricks jako zadanie wsadowe 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

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.

Przechowywanie zdarzeń

Auto Loader śledzi odnalezione pliki w lokalizacji punktu kontrolnego przy użyciu bazy danych RocksDB, aby zapewnić gwarancję dokładnie jednorazowego pozyskiwania. Usługa Databricks zdecydowanie zaleca użycie opcji cloudFiles.maxFileAge dla wszystkich dużych lub długotrwałych strumieni pobierania danych. Ta opcja usuwa zdarzenia z lokalizacji punktu kontrolnego, co przyspiesza czas uruchamiania Auto Loader. Czas uruchamiania może wzrosnąć do minut dla każdego uruchomienia Auto Loader, co dodaje zbędne koszty, gdy masz ustaloną maksymalną wartość wieku plików przechowywanych w katalogu źródłowym. Minimalna wartość, którą można ustawić dla cloudFiles.maxFileAge, to "14 days". Usunięcia w RocksDB pojawiają się jako wpisy nagrobkowe, dlatego należy spodziewać się, że użycie magazynu tymczasowo wzrośnie, zanim zacznie się stabilizować, gdy zdarzenia wygasną.

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

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. Firma Databricks zaleca rozpoczęcie regularnego uzupełniania danych przy użyciu modułu automatycznego ładującego i opcji cloudFiles.backfillInterval, aby zagwarantować, że wszystkie pliki zostaną odnalezione w ramach określonej umowy SLA, jeśli kompletność danych jest wymagana. Uruchamianie regularnych wypełnień nie powoduje duplikatów.