Skonfiguruj Auto Loader dla obciążeń produkcyjnych

Aby uzyskać kompleksowe najlepsze rozwiązania dotyczące konfigurowania automatycznego modułu ładującego, w tym wyboru trybu odnajdywania plików, zarządzania schematami i obsługi jakości danych, zobacz Najlepsze rozwiązania dotyczące automatycznego modułu ładującego.

Databricks zaleca używanie Auto Loader w potokach Lakeflow do przyrostowego ładowania danych. Potoki Lakeflow rozszerzają funkcjonalność Apache Spark Structured Streaming i umożliwiają napisanie zaledwie kilku wierszy deklaratywnego kodu w języku Python lub SQL w celu wdrożenia potoku danych klasy produkcyjnej z użyciem:

• Skalowanie automatyczne infrastruktury obliczeniowej w celu uzyskania oszczędności kosztów:Optymalizowanie wykorzystania klastra potoku Lakeflow za pomocą skalowania automatycznego
• Sprawdzanie jakości danych z oczekiwaniami:Zarządzanie jakością danych przy użyciu oczekiwań pipelinu
• Automatyczna obsługa ewolucji schematu:Konfigurowanie wnioskowania schematu i ewolucji w module automatycznego ładowania
• Monitorowanie za pomocą metryk w dzienniku zdarzeń:Dziennik zdarzeń potoku

Usługa Databricks zaleca również stosowanie najlepszych praktyk dotyczących przesyłania strumieniowego na potrzeby uruchamiania Auto Loader w środowisku produkcyjnym. Zobacz Zagadnienia dotyczące produkcji Structured Streaming.

Monitorowanie automatycznego modułu ładującego

W poniższych sekcjach opisano sposób monitorowania automatycznego modułu ładującego w środowisku produkcyjnym, w tym metryk, dzienników, alertów i typowych przepływów pracy rozwiązywania problemów. Aby uzyskać kompleksowe informacje dotyczące wzorców pulpitu nawigacyjnego, analizy opóźnień i wykrywania dryfu schematu, zobacz Monitorowanie i obserwowanie 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. Zapytanie cloud_files_state, podając lokalizację punktu kontrolnego związaną ze strumieniem Auto Loader.

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

Nasłuchiwanie aktualizacji strumienia

Aby lepiej monitorować strumienie Auto Loader, Databricks zaleca korzystanie z interfejsu odbiorcy zapytań strumieniowych Apache Spark. Zobacz Monitorowanie zapytań przesyłania strumieniowego ze strukturą w Azure Databricks.

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 przypadku korzystania z trybu powiadomień plików w środowisku Databricks Runtime 10.4 LTS i nowszych, metryki obejmują przybliżoną liczbę zdarzeń plików w kolejce w chmurze jako approximateQueueSize dla usług AWS 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.

Jeśli Twoje obciążenie robocze nie wymaga niskich opóźnień, możesz obniżyć koszty obliczeń, używając Lakeflow Jobs do planowania Auto Loader jako zadań wsadowych przy użyciu Trigger.AvailableNow zamiast uruchamiania go w trybie ciągłym. 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. Wyzwalacze ciągłe, takie jak Trigger.ProcessingTime , są szczególnie kosztowne w trybie listy katalogów, ponieważ moduł automatycznego ładowania stale wyświetla listę całego katalogu w celu znalezienia nowych plików. Jeśli obciążenie wymaga wyzwalaczy ciągłych, usługa Databricks zaleca wybranie trybu odnajdywania plików na podstawie wymagań dotyczących opóźnień:

• Małe opóźnienia i prostota: użyj automatycznego modułu ładującego ze zdarzeniami plików. Zdarzenia plików wymagają tylko jednej kolejki na zasobnik i używają odnajdywania przyrostowego w kolejnych uruchomieniach. Aby uzyskać więcej informacji, zobacz Auto loader with file events overview (Automatyczne ładowanie za pomocą zdarzeń plików — omówienie).
• Bardzo wrażliwe na opóźnienia aplikacje: użyj klasycznego trybu powiadamiania o plikach. Tryb klasyczny odczytuje dane bezpośrednio z kolejki w chmurze, bez dodatkowego etapu buforowania wprowadzonego przez zdarzenia 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. Aby uzyskać szczegółowe informacje, zobacz Powiadomienie o pliku.

Przechowywanie danych źródłowych

W miarę gromadzenia plików w katalogu źródłowym koszty magazynowania zwiększają się, a odnajdywanie plików spowalnia, szczególnie w trybie listy katalogów. Auto Loader zapewnia opcję cloudFiles.cleanSource do automatycznego zarządzania przechowywaniem plików poprzez ich archiwizowanie lub usuwanie po przetworzeniu.

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

Usługa Databricks zaleca używanie Auto Loader z powiadomieniami o zdarzeniach plików w celu zmniejszenia kosztów odnajdywania. Zmniejsza 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, wolumenie lub punkcie montowania DBFS. Przenoszenie między zasobnikami i między kontenerami nie jest obsługiwane i powoduje wystąpienie błędu.
• Miejsce docelowe przenoszenia może być ścieżką woluminu (na przykład /Volumes/my_catalog/my_schema/my_volume/archive/).
• 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.

Pełne informacje o cleanSource opcjach i ich domyślnych ustawieniach znajdziesz w artykule Czyszczenie przetworzonych plików za pomocą Auto Loadera.

Przenoszenie przetworzonych plików do ścieżki magazynu zimnego

Poniższy przykład umożliwia skonfigurowanie automatycznego modułu ładującego w celu przeniesienia przetworzonych plików do katalogu archiwum w tym samym zasobniku po upływie 14 dni. Zasady cyklu życia chmury można zastosować do ścieżki archiwum, aby przenieść pliki do tańszych warstw przechowywania, takich jak AWS S3 Glacier, Azure Cool/Archive lub GCS Coldline/Archive.

Python

# Step 1: Configure Auto Loader to move processed files to an archive path.
checkpoint = "/Volumes/my_catalog/my_schema/my_volume/checkpoints/ingest_stream"
archive_path = "s3://my-bucket/archive/landing/"

df = (spark.readStream.format("cloudFiles")
  .option("cloudFiles.format", "json")
  .option("cloudFiles.cleanSource", "MOVE")
  .option("cloudFiles.cleanSource.moveDestination", archive_path)
  .option("cloudFiles.cleanSource.retentionDuration", "14 days")
  .option("cloudFiles.schemaLocation", checkpoint)
  .load("s3://my-bucket/landing/")
)

# Step 2: Write to a Delta table.
(df.writeStream
  .option("checkpointLocation", checkpoint)
  .trigger(availableNow=True)
  .toTable("my_catalog.my_schema.raw_events")
)

# Step 3 (outside Databricks): Set up a cloud lifecycle policy on the
# archive path to transition files to cold storage after a grace period.
# For example, in AWS you can configure an S3 Lifecycle rule to move
# objects under s3://my-bucket/archive/landing/ to S3 Glacier after
# 30 days.

SQL

-- Step 1: Configure Auto Loader to move processed files to an archive path
-- using a Lakeflow Declarative Pipeline.
CREATE OR REFRESH STREAMING TABLE raw_events
AS SELECT * FROM STREAM read_files(
  's3://my-bucket/landing/',
  format => 'json',
  cleanSource => 'MOVE',
  `cleanSource.moveDestination` => 's3://my-bucket/archive/landing/',
  `cleanSource.retentionDuration` => '14 days'
);

-- Step 2 (outside Databricks): Set up a cloud lifecycle policy on the
-- archive path to transition files to cold storage.
-- For example, in AWS configure an S3 Lifecycle rule to move objects
-- under s3://my-bucket/archive/landing/ to S3 Glacier after 30 days.

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, które docierają 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. 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 odkryte pliki w punkcie kontrolnym za pomocą RocksDB, aby zapewnić, że każdy plik zostanie pobrany dokładnie raz. 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 pobierasz danych starszych niż cloudFiles.maxFileAge. Dlatego jeśli chcesz pobierać stare dane, nie ustawiaj tej opcji na początku streamu. Jednak ustaw tę opcję przy kolejnych uruchomieniach.

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

Backfill to asynchroniczne listowanie katalogów, które Auto Loader uruchamia równolegle ze standardowym wykrywaniem plików, aby wychwycić pliki, które nie zostały wykryte podczas tego procesu. Mimo że systemy powiadomień w chmurze dostarczają zdarzenia przynajmniej raz, plik nadal może zostać przeoczony. Okresowe ponowne skanowanie powoduje ponowne listowanie katalogu źródłowego, dzięki czemu pliki, które wcześniej pominięto, zostaną ostatecznie wykryte.

Ustaw cloudFiles.backfillInterval na ciąg czasu trwania takiego jak 1 day lub 1 week do planowania okresowych uzupełnień. Nie ma wartości domyślnej. W trybie wyświetlania katalogów i klasycznych powiadomień o plikach uzupełnianie danych działa tylko wtedy, gdy ustawisz ten interwał.

Jak działa uzupełnianie wsteczne:

• Oparty na czasie, nie na plikach: Auto Loader uruchamia następne uzupełnienie, gdy czas od ostatniego przekroczy przedział, śledząc ostatni czas wypełnienia w punkcie kontrolnym zamiast porównywać znaczniki czasu plików. Aby potwierdzić ostatnie uzupełnienie danych, użyj metryk lastBackfillStartTimeMs i lastBackfillFinishTimeMs. Zobacz Monitorowanie zapytań przesyłania strumieniowego ze strukturą w Azure Databricks.
• Pobierane są tylko przegapione pliki: Backfill pobiera tylko te, które nie zostały jeszcze przetworzone, a nowe pliki nadal docierają przez skonfigurowany tryb odkrywania. Pomija już pobrane pliki, sprawdzając stan pliku w punkcie kontrolnym, unikając duplikatów.
• Asynchroniczne: Operacje uzupełniania danych są uruchamiane w tle i nie blokują przetwarzania w mikropartiach.

Ustaw interwał uzupełniania, gdy korzystasz z klasycznego trybu powiadomień o plikach i masz rygorystyczne wymagania dotyczące kompletności danych lub umów SLA. Auto Loader następnie ponownie listuje źródło w tym interwale, aby wychwycić pominięte powiadomienia.

Nie ustawiaj interwału backfillu w przypadku użycia zdarzeń plikowych. Azure Databricks automatycznie uzupełnia te lokalizacje zewnętrzne o pełny wykaz przy pierwszym włączeniu zdarzeń plików, a następnie uzupełnia je dalej mniej więcej co 24 godziny podczas pozyskiwania danych przez strumień. Ustawienie interwału nie jest obsługiwane w przypadku zdarzeń plików, a ponieważ automatyczne uzupełnianie danych jest mniej kosztowne, Databricks zaleca używanie zdarzeń plików zamiast ręcznego ustawiania interwału.

Każde uzupełnianie to pełne wylistowanie katalogu, więc jego koszt rośnie wraz z liczbą plików w katalogu źródłowym i w trybie listowania katalogów powoduje naliczanie opłat za API LIST. Wybierz najdłuższy odstęp, który nadal spełnia Twoje SLA dotyczące kompletności.

Unikaj pełnych listów katalogów z zdarzeniami plików

Korzystając ze zdarzeń plików, uruchamiaj strumienie Auto Loader co najmniej raz na 7 dni, aby uniknąć pełnego listowania katalogu. Uruchamianie strumieni Auto Loader z taką częstotliwością zapewnia, że wykrywanie 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.