Asynchroniczne sprawdzanie stanu dla zapytań stanowych

Uwaga

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

Asynchroniczne punktów kontrolnych stanu utrzymuje dokładnie jednokrotne gwarancje dla zapytań przesyłanych strumieniowo, ale może zmniejszyć ogólne opóźnienie dla niektórych obciążeń stanowych przesyłania strumieniowego ze strukturą wąskich gardeł w przypadku aktualizacji stanu. Jest to realizowane przez rozpoczęcie przetwarzania następnej mikropartii natychmiast po zakończeniu obliczeń poprzedniej mikropartii, bez oczekiwania na ukończenie zapisu punktów kontrolnych stanu. W poniższej tabeli porównaliśmy kompromisy dotyczące synchronicznego i asynchronicznego tworzenia punktów kontrolnych:

Charakterystyka	Synchroniczne punkty kontrolne	Asynchroniczne punkty kontrolne
Opóźnienie	Większe opóźnienie dla każdej mikro-serii.	Mniejsze opóźnienie, ponieważ mikrosady mogą nakładać się na siebie.
Uruchom ponownie	Szybkie odzyskiwanie, ponieważ należy ponownie uruchomić tylko ostatnią partię.	Większe opóźnienie ponownego uruchamiania, ponieważ może być konieczne ponowne przetworzenie więcej niż jednej mikropartii.

Poniżej przedstawiono cechy zadań przesyłania strumieniowego, które mogą korzystać z asynchronicznego tworzenia punktów kontrolnych stanu:

• Zadanie ma co najmniej jedną operację stanową (np. agregację, flatMapGroupsWithState, mapGroupsWithState, sprzężenia strumieni)

• Opóźnienie punktu kontrolnego stanu jest jednym z głównych czynników wpływających na całkowite opóźnienie wykonania wsadowego. Te informacje można znaleźć w zdarzeniach StreamingQueryProgress . Te zdarzenia znajdują się również w dziennikach log4j w sterowniku platformy Spark. Oto przykład postępu zapytań strumieniowych i jak znaleźć wpływ stanu punktu kontrolnego na ogólne opóźnienie wykonania partii.

  • {
       "id" : "2e3495a2-de2c-4a6a-9a8e-f6d4c4796f19",
       "runId" : "e36e9d7e-d2b1-4a43-b0b3-e875e767e1fe",
       "...",
       "batchId" : 0,
       "durationMs" : {
         "...",
         "triggerExecution" : 547730,
         "..."
       },
       "stateOperators" : [ {
         "...",
         "commitTimeMs" : 3186626,
         "numShufflePartitions" : 64,
         "..."
       }]
    }
    

  • Analiza opóźnienia punktu kontrolnego stanu dla powyższego zdarzenia postępu zapytania

    • Czas trwania partii (durationMs.triggerDuration) wynosi około 547 sekund.
    • Opóźnienie zatwierdzania magazynu stanów (stateOperations[0].commitTimeMs) wynosi około 3186 sek. Opóźnienie zatwierdzania jest agregowane wewnątrz zadań zawierających przechowalnię stanów. W tym przypadku istnieje 64 takie zadania (stateOperators[0].numShufflePartitions).
    • Każde zadanie zawierające operator stanu trwało średnio 50 sekund (3186/64) dla punktu kontrolnego. Jest to dodatkowe opóźnienie, które jest dodawane do czasu trwania przetwarzania. Zakładając, że wszystkie 64 zadania są uruchomione współbieżnie, etap punktu kontrolnego przyczynił się do około 9% (50 sekund / 547 sekund) czasu trwania serii. Wartość procentowa jest jeszcze wyższa, gdy maksymalna liczba współbieżnych zadań jest mniejsza niż 64.

Włączanie asynchronicznego tworzenia punktów kontrolnych stanu

Musisz użyć opartego na RocksDB magazynu stanu do tworzenia punktów kontrolnych stanu asynchronicznego. Ustaw następujące konfiguracje:

spark.conf.set(
  "spark.databricks.streaming.statefulOperator.asyncCheckpoint.enabled",
  "true"
)

spark.conf.set(
  "spark.sql.streaming.stateStore.providerClass",
  "com.databricks.sql.streaming.state.RocksDBStateStoreProvider"
)

Ograniczenia i wymagania dotyczące asynchronicznego tworzenia punktów kontrolnych

Uwaga

Skalowanie automatyczne zasobów obliczeniowych ma ograniczenia dotyczące skalowania w dół wielkości klastra dla obciążeń strumieniowych o złożonej strukturze. Firma Databricks zaleca używanie DLT z rozszerzonym skalowaniem automatycznym dla obciążeń strumieniowych. Zobacz Optymalizowanie wykorzystania klastra potoków DLT za pomocą rozszerzonego skalowania automatycznego.

• Wszelkie błędy w asynchronicznym punkcie kontrolnym w co najmniej jednym magazynie kończą się niepowodzeniem zapytania. W trybie synchronicznego tworzenia punktów kontrolnych punkt kontrolny jest wykonywany w ramach zadania, a platforma Spark ponawia próbę zadania wiele razy przed niepowodzeniem zapytania. Ten mechanizm nie jest obecny w przypadku asynchronicznego tworzenia punktów kontrolnych stanu. Databricks zaleca używanie zadań ciągłych do automatycznego ponawiania prób w razie niepowodzenia zadania. Zobacz Uruchamianie zadań w sposób ciągły.
• Asynchroniczne tworzenie punktów kontrolnych działa najlepiej, gdy lokalizacje magazynu stanów nie są zmieniane pomiędzy wykonywaniem mikro-zadań. Zmiana rozmiaru klastra w połączeniu z asynchronicznym tworzeniem punktów kontrolnych stanu może nie działać dobrze, ponieważ instancje magazynów stanu mogą zostać rozdzielone ponownie, podczas dodawania lub usuwania węzłów jako część zdarzenia zmiany rozmiaru klastra.
• Asynchroniczne zapisywanie stanu punktów kontrolnych jest obsługiwane tylko w implementacji dostawcy magazynu stanów RocksDB. Domyślna implementacja magazynu stanu w pamięci nie obsługuje jej.