Udostępnij za pośrednictwem

Zagadnienia dotyczące produkcji związane ze strukturalnym przesyłaniem strumieniowym

  • Artykuł

Ten artykuł zawiera zalecenia dotyczące planowania obciążeń przesyłania strumieniowego ze strukturą przy użyciu zadań w usłudze Azure Databricks.

Usługa Databricks zaleca, aby zawsze wykonywać następujące czynności:

  • Usuń niepotrzebny kod z notesów, które będą zwracać wyniki, takie jak display i count.
  • Nie uruchamiaj obciążeń przesyłania strumieniowego ze strukturą przy użyciu obliczeń ogólnego przeznaczenia. Zawsze planuj strumienie jako zadania przy użyciu obliczeń zadań.
  • Planowanie zadań przy użyciu Continuous trybu.
  • Nie włączaj automatycznego skalowania dla obliczeń dla zadań przesyłania strumieniowego ze strukturą.

Niektóre obciążenia korzystają z następujących korzyści:

Usługa Azure Databricks wprowadziła tabele delta live, aby zmniejszyć złożoność zarządzania infrastrukturą produkcyjną dla obciążeń przesyłania strumieniowego ze strukturą. Usługa Databricks zaleca używanie tabel delta Live Tables dla nowych potoków przesyłania strumieniowego ze strukturą. Zobacz Co to jest delta live tables?.

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.

Projektowanie obciążeń przesyłania strumieniowego w celu oczekiwania na awarię

Usługa Databricks zaleca zawsze konfigurowanie zadań przesyłania strumieniowego w celu automatycznego ponownego uruchamiania po awarii. Niektóre funkcje, w tym ewolucja schematu, zakładają, że obciążenia przesyłania strumieniowego ze strukturą są skonfigurowane do automatycznego ponawiania prób. Zobacz Konfigurowanie zadań przesyłania strumieniowego ze strukturą w celu ponownego uruchamiania zapytań przesyłanych strumieniowo w przypadku niepowodzenia.

Niektóre operacje, takie jak foreachBatch zapewniają co najmniej raz, a nie dokładnie jednokrotne gwarancje. W przypadku tych operacji należy się upewnić, że potok przetwarzania jest idempotentny. Zobacz Używanie polecenia foreachBatch do zapisywania do losowego ujściach danych.

Uwaga

Po ponownym uruchomieniu zapytania mikrosadowa planowana podczas poprzednich procesów uruchamiania. Jeśli zadanie nie powiodło się z powodu błędu braku pamięci lub ręcznie anulowano zadanie z powodu przeskalowanej mikrosadowej partii, może być konieczne skalowanie obliczeń w górę w celu pomyślnego przetworzenia mikrosadowej.

Jeśli zmienisz konfiguracje między przebiegami, te konfiguracje mają zastosowanie do pierwszej nowej partii zaplanowanej. Zobacz Odzyskiwanie po zmianach w zapytaniu przesyłania strumieniowego ze strukturą.

Kiedy zadanie jest ponawiane?

Możesz zaplanować wiele zadań w ramach zadania usługi Azure Databricks. Podczas konfigurowania zadania przy użyciu wyzwalacza ciągłego nie można ustawić zależności między zadaniami.

Możesz zaplanować wiele strumieni w jednym zadaniu przy użyciu jednego z następujących podejść:

  • Wiele zadań: zdefiniuj zadanie z wieloma zadaniami, które uruchamiają obciążenia przesyłane strumieniowo przy użyciu wyzwalacza ciągłego.
  • Wiele zapytań: zdefiniuj wiele zapytań przesyłanych strumieniowo w kodzie źródłowym dla jednego zadania.

Można również połączyć te strategie. W poniższej tabeli porównaliśmy te podejścia.

Wiele zadań Wiele zapytań
Jak współużytkowane są zasoby obliczeniowe? Usługa Databricks zaleca wdrożenie zadań o odpowiednim rozmiarze do każdego zadania przesyłania strumieniowego. Opcjonalnie możesz udostępniać zasoby obliczeniowe między zadaniami. Wszystkie zapytania współdzielą te same obliczenia. Możesz opcjonalnie przypisywać zapytania do pul harmonogramu.
Jak są obsługiwane ponawianie prób? Wszystkie zadania muszą zakończyć się niepowodzeniem przed ponowną próbą zadania. Zadanie ponawia próbę, jeśli jakiekolwiek zapytanie zakończy się niepowodzeniem.

Konfigurowanie zadań przesyłania strumieniowego ze strukturą w celu ponownego uruchamiania zapytań przesyłanych strumieniowo w przypadku niepowodzenia

Usługa Databricks zaleca skonfigurowanie wszystkich obciążeń przesyłania strumieniowego przy użyciu wyzwalacza ciągłego. Zobacz Uruchamianie zadań w sposób ciągły.

Wyzwalacz ciągły domyślnie zapewnia następujące zachowanie:

  • Zapobiega więcej niż jednemu współbieżnemu uruchomieniu zadania.
  • Uruchamia nowy przebieg, gdy poprzedni przebieg zakończy się niepowodzeniem.
  • Używa wycofywania wykładniczego dla ponownych prób.

Usługa Databricks zaleca zawsze używanie obliczeń zadań zamiast obliczeń ogólnego przeznaczenia podczas planowania przepływów pracy. W przypadku niepowodzenia zadania i ponawiania próby nowe zasoby obliczeniowe są wdrażane.

Uwaga

Nie trzeba używać ani streamingQuery.awaitTermination() spark.streams.awaitAnyTermination(). Zadania automatycznie uniemożliwiają ukończenie przebiegu, gdy zapytanie przesyłane strumieniowo jest aktywne.

Używanie pul harmonogramu dla wielu zapytań przesyłania strumieniowego

Pule harmonogramu można skonfigurować tak, aby przypisywać pojemność obliczeniową do zapytań podczas uruchamiania wielu zapytań przesyłanych strumieniowo z tego samego kodu źródłowego.

Domyślnie wszystkie zapytania uruchomione w notesie są uruchamiane w tej samej sprawiedliwej puli planowania. Zadania platformy Apache Spark generowane przez wyzwalacze ze wszystkich zapytań przesyłanych strumieniowo w notesie są uruchamiane po drugim w kolejności "pierwszy na początku" (FIFO). Może to spowodować niepotrzebne opóźnienia w zapytaniach, ponieważ nie współdzielą zasobów klastra.

Pule harmonogramu umożliwiają deklarowanie, które zapytania przesyłania strumieniowego ze strukturą współużytkują zasoby obliczeniowe.

Poniższy przykład przypisuje query1 do dedykowanej puli, a następnie query2 query3 udostępnia pulę harmonogramu.

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

Uwaga

Konfiguracja właściwości lokalnej musi znajdować się w tej samej komórce notesu, w której uruchamiasz zapytanie przesyłania strumieniowego.

Aby uzyskać więcej informacji, zobacz dokumentację usługi Apache Fair Scheduler.