Freigeben über

Produktionsüberlegungen für strukturiertes Streaming

Dieser Artikel enthält Empfehlungen für die Planung von Workloads für strukturiertes Streaming mithilfe von Aufträgen in Azure Databricks.

Databricks empfiehlt, stets wie folgt vorzugehen:

  • Entfernen Sie unnötigen Code aus Notebooks, der Ergebnisse zurückgeben würde, z. B. display und count.
  • Führen Sie keine Workloads für strukturiertes Streaming mit All-Purpose Compute aus. Planen Sie Streams immer als Aufträge mit Jobs Compute.
  • Planen Sie Aufträge mit dem Modus Continuous.
  • Aktivieren Sie keine automatische Skalierung für das Compute von Aufträgen für strukturiertes Streaming.

Einige Workloads profitieren von folgenden Punkten:

Azure Databricks hat Lakeflow Declarative Pipelines eingeführt, um die Komplexität der Verwaltung der Produktionsinfrastruktur für strukturierte Streaming-Workloads zu reduzieren. Databricks empfiehlt die Verwendung von Lakeflow Declarative Pipelines für neue Strukturierte Streaming-Pipelines. Siehe Lakeflow Declarative Pipelines.

Hinweis

Die automatische Computeskalierung hat Einschränkungen beim Herunterskalieren der Clustergröße für strukturierten Streaming-Workloads. Databricks empfiehlt die Verwendung von Lakeflow Declarative Pipelines mit verbesserter automatischer Skalierung für Streaming-Workloads. Weitere Informationen finden Sie unter Optimieren der Clusternutzung von deklarativen Lakeflow-Pipelines mit automatischer Skalierung.

Fehlertolerante Gestaltung von Streaming-Workloads

Databricks empfiehlt, Streamingaufträge stets so zu konfigurieren, dass sie bei einem Fehler automatisch neu starten. Bei einigen Funktionen, darunter die Schema-Weiterentwicklung, wird davon ausgegangen, dass Workloads für das strukturierte Streaming so konfiguriert sind, dass automatisch Wiederholungsversuche erfolgen. Weitere Informationen finden Sie unter Konfigurieren von strukturierten Streamingaufträgen zum Neustart von Streamingabfragen bei Fehlern.

Einige Vorgänge wie z. B. foreachBatch bieten eine Garantie vom Typ „Mindesten einmal“ statt „Genau einmal“. Für diese Vorgänge sollten Sie sicherstellen, dass die Verarbeitungspipeline idempotent ist. Siehe Verwenden von foreachBatch zum Schreiben in beliebige Datensenken.

Hinweis

Wenn eine Abfrage neu gestartet wird, wird der bei der letzten Ausführung geplante Mikrobatch verarbeitet. Wenn ein Auftrag aufgrund von ungenügendem Arbeitsspeicher fehlgeschlagen ist oder Sie einen Auftrag aufgrund eines übergroßen Mikrobatches manuell abgebrochen haben, müssen Sie das Compute möglicherweise skalieren, um den Mikrobatch erfolgreich zu verarbeiten.

Wenn Sie Konfigurationen zwischen Ausführungen ändern, gelten die betreffenden Konfigurationen für den ersten geplanten neuen Batch. Siehe "Wiederherstellen nach Änderungen in einer strukturierten Streamingabfrage".

Wann wird ein Auftrag wiederholt?

Im Rahmen eines Azure Databricks-Auftrags können Sie mehrere Aufgaben planen. Wenn Sie einen Auftrag mit dem Trigger „Fortlaufend“ konfigurieren, können Sie keine Abhängigkeiten zwischen Aufgaben festlegen.

Für die Planung mehrerer Streams in einem einzigen Auftrag stehen Ihnen die folgenden Vorgehensweisen zur Verfügung:

  • Mehrere Aufgaben: Definieren Sie einen Auftrag mit mehreren Aufgaben, die Streaming-Workloads mithilfe eines fortlaufenden Auslösers ausführen.
  • Mehrere Abfragen: Definieren mehrerer Streamingabfragen im Quellcode für eine einzelne Aufgabe.

Diese Strategien lassen sich auch kombinieren. Im folgenden Diagramm werden diese beiden Vorgehensweisen miteinander verglichen.

Strategie: Mehrere Aufgaben Mehrere Abfragen
Wie wird Compute aufgeteilt? Databricks empfiehlt die Bereitstellung von Jobs Compute, das für die einzelnen Streamingaufgaben entsprechend dimensioniert ist. Optional können Sie das Compute auf Aufgaben verteilen. Alle Abfragen teilen sich dasselbe Compute. Optional können Sie Abfragen zu Schedulerpools zuweisen.
Wie wird mit Wiederholungsversuchen umgegangen? Alle Aufgaben müssen fehlschlagen, bevor der Auftrag wiederholt wird. Die Aufgabe wird wiederholt, wenn eine der Abfragen fehlschlägt.

Konfigurieren von strukturierten Streaming-Aufträgen zum Neustarten von Streaming-Abfragen bei einem Fehler

Databricks empfiehlt, alle Streaming-Workloads mithilfe des Triggers „Fortlaufend“ zu konfigurieren. Weitere Informationen finden Sie unter Fortlaufendes Ausführen von Aufträgen.

Der Trigger „Fortlaufend“ zeigt standardmäßig das folgende Verhalten:

  • Er verhindert mehrere gleichzeitige Ausführungen des Auftrags.
  • Er startet eine neue Ausführung, wenn eine vorherige Ausführung fehlschlägt.
  • Er nutzt exponentielle Backoffs für Wiederholungsversuche.

Databricks empfiehlt, bei der Planung von Workflows stets Jobs Compute zu verwenden statt All-Purpose Compute. Beim Fehlschlagen und Wiederholen von Aufträgen werden neue Computeressourcen bereitgestellt.

Hinweis

Sie müssen nicht streamingQuery.awaitTermination() oder spark.streams.awaitAnyTermination() verwenden. Aufträge verhindern automatisch, dass eine Ausführung abgeschlossen wird, wenn eine Streamingabfrage aktiv ist.

Verwenden von Planerpools für mehrere Streamingabfragen

Sie können Zeitplanpools so konfigurieren, dass den Abfragen Rechenkapazität zugewiesen wird, wenn mehrere Streamingabfragen aus demselben Quellcode ausgeführt werden.

Standardmäßig werden alle in einem Notebook gestarteten Abfragen im gleichen Fair-Planungspool ausgeführt. Apache Spark-Aufträge, die durch Trigger von allen Streamingabfragen in einem Notebook generiert werden, werden nacheinander in FIFO-Reihenfolge (First In, First Out) ausgeführt. Dies kann zu unnötigen Verzögerungen bei den Abfragen führen, da die Clusterressourcen nicht effizient gemeinsam genutzt werden.

Mit Scheduler-Pools können Sie deklarieren, welche strukturierten Streaming-Abfragen Computeressourcen gemeinsam nutzen.

Das folgende Beispiel weist query1 einem dedizierten Pool zu, während query2 und query3 sich einen Schedulerpool teilen.

# 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")

Hinweis

Die Konfiguration der lokalen Eigenschaft muss sich in derselben Notebookzelle befinden, in der Sie die Streamingabfrage starten.

Weitere Details finden Sie in der Apache Fair Scheduler-Dokumentation .