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 mikrosadowej partii natychmiast po zakończeniu obliczeń poprzedniej mikrosadowej bez oczekiwania na ukończenie tworzenia punktów kontrolnych stanu. W poniższej tabeli porównaliśmy kompromisy dotyczące synchronicznego i asynchronicznego tworzenia punktów kontrolnych:

Characteristic	Synchroniczne punkty kontrolne	Asynchroniczne punkty kontrolne
Opóźnienie	Większe opóźnienie dla każdej mikrosadowej partii.	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ż więcej niż w mikrosadowej partii może być konieczne ponowne uruchomienie.

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, mapGroupsWithStatesprzężenia strumienia)
• Opóźnienie punktu kontrolnego stanu jest jednym z głównych czynników wpływających na ogólne opóźnienie wykonywania 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ń przesyłania strumieniowego i sposobu znajdowania wpływu punktu kontrolnego stanu na ogólne opóźnienie wykonywania wsadowego.

  • {
       "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 między zadaniami zawierającymi magazyn 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 związane z czasem trwania partii. Zakładając, że wszystkie 64 zadania są uruchomione współbieżnie, krok punktu kontrolnego przyczynił się do około 9% (50 sekund / 547 sekund) czasu trwania partii. 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ć magazynu stanu opartego na bazie bazy danych RocksDB na potrzeby 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 obliczeń ma ograniczenia skalowania w dół rozmiaru klastra dla obciążeń przesyłania strumieniowego ze strukturą. Usługa Databricks zaleca używanie tabel delta live z rozszerzonym skalowaniem automatycznym na potrzeby obciążeń przesyłania strumieniowego. Zobacz Optymalizowanie wykorzystania klastra potoków tabel na żywo delty przy użyciu 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. Usługa Databricks zaleca używanie zadań ciągłych do automatycznego ponawiania prób w przypadku niepowodzenia zadania. Zobacz Uruchamianie zadań w sposób ciągły.
• Asynchroniczne punktowanie kontrolne działa najlepiej, gdy lokalizacje magazynu stanów nie są zmieniane między wykonywaniem mikrosadowym. Zmiana rozmiaru klastra w połączeniu z asynchronicznym tworzeniem punktów kontrolnych stanu może nie działać, ponieważ wystąpienie magazynu stanów może zostać ponownie rozproszone, ponieważ węzły są dodawane lub usuwane w ramach zdarzenia zmiany rozmiaru klastra.
• Asynchroniczne punktowanie punktów kontrolnych stanu jest obsługiwane tylko w implementacji dostawcy magazynu stanów Bazy danych RocksDB. Domyślna implementacja magazynu stanu w pamięci nie obsługuje jej.