Produktionsüberlegungen für strukturiertes Streaming

Diese Seite enthält Empfehlungen für die Planung von strukturierten Streaming-Workloads mithilfe von Lakeflow-Aufträgen auf Azure Databricks. Siehe Lakeflow Jobs.

Databricks empfiehlt, folgendes immer zu konfigurieren:

  • Entfernen Sie unnötigen Code aus Notebooks, der Ergebnisse zurückgeben würde, z. B. display und count.
  • Führen Sie keine strukturierten Streaming-Workloads mit allzweckbasierter Berechnung aus. Planen Sie Datenströme immer als Lakeflow Jobs mit Job-Compute.
  • Planen von Lakeflow-Aufträgen mithilfe des Continuous Modus. Dies bezieht sich auf das Planungsfeature Azure Databricks Aufträge, nicht auf das Intervall für strukturiertes Streaming Trigger.
  • Aktivieren Sie die automatische Skalierung für die Berechnung für Strukturierte Streaming-Aufträge nicht.

Einige Workloads profitieren von folgendem:

Azure Databricks hat Lakeflow Spark 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 Spark Declarative Pipelines für neue Strukturierte Streaming-Pipelines. Siehe Lakeflow Spark Declarative Pipelines.

Hinweis

Das automatische Skalieren der Rechnerkapazität hat Einschränkungen bei der Reduzierung der Clustergröße für strukturierte Streaming-Workloads. Databricks empfiehlt die Verwendung von Lakeflow Spark Declarative Pipelines mit verbesserter automatischer Skalierung für Streaming-Workloads. Siehe Optimieren der Clusternutzung von Lakeflow Spark Declarative Pipelines mit automatischer Skalierung.

:::note Serverless-Berechnung

Bei serverlosem Computing werden nur Trigger.AvailableNow() und Trigger.Once() unterstützt. Databricks empfiehlt Trigger.AvailableNow().

Verwenden Sie für kontinuierliches Streaming auf serverlosen Berechnungen den modus "Triggered vs. continuous pipeline mode " im fortlaufenden Modus.

Siehe Streaming-Einschränkungen.

:::

Streaming-Workloads darauf auslegen, Ausfälle zu erwarten

Databricks empfiehlt, Streamingaufträge immer so zu konfigurieren, dass beim Fehler automatisch neu gestartet wird. Einige Funktionen, einschließlich der Schemaentwicklung, erfordern, dass strukturierte Streaming-Workloads automatisch erneut versuchen. 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 „mindestens einmal“ statt „genau einmal“. Stellen Sie für diese Vorgänge sicher, dass Ihre 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 erneut versucht?

Sie können mehrere Vorgänge als Teil eines Azure Databricks Auftrags 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 Größe von Aufträgen für jede Streamingaufgabe entsprechend zu berechnen. Sie können Rechenressourcen optional aufgabenübergreifend teilen. Alle Abfragen teilen sich dasselbe Compute. Optional können Sie Abfragen Scheduler-Pools zuweisen.
Wie werden Wiederholungsversuche gehandhabt? 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 Streamingworkloads mithilfe des fortlaufenden Triggers zu konfigurieren. Weitere Informationen finden Sie unter Fortlaufendes Ausführen von Aufträgen.

Der fortlaufende Auslöser weist standardmäßig das folgende Verhalten auf:

  • Er verhindert, dass der Auftrag mehr als einmal gleichzeitig ausgeführt wird.
  • Er startet eine neue Ausführung, wenn eine vorherige Ausführung fehlschlägt.
  • Er nutzt ein exponentielles Backoff-Verfahren 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

Databricks empfiehlt, nicht zu verwenden streamingQuery.awaitTermination() oder spark.streams.awaitAnyTermination(). Siehe Wann awaitTermination() zu verwenden ist.

Wann verwendet werden soll awaitTermination()

streamingQuery.awaitTermination() und spark.streams.awaitAnyTermination() blockieren den aktuellen Thread, bis eine Streaming-Abfrage beendet wird. Ob diese Funktionen verwendet werden sollen, hängt von Ihrer Ausführungsumgebung ab.

Verwenden Sie für Lakeflow Jobs nicht streamingQuery.awaitTermination() oder spark.streams.awaitAnyTermination(). Diese Funktionen sind nicht erforderlich, da der Jobs-Dienst automatisch verhindert, dass ein Durchlauf abgeschlossen wird, wenn eine Streamingabfrage aktiv ist. Beide Funktionen verhindern, dass Notizbuchzellen ihre Ausführung abschließen, und verhindern, dass der Jobs-Dienst die Streamingabfrage nachverfolgt, was zu Unterbrechungen bei Backlogmetriken und Auftragsbenachrichtigungen führt.

Verwenden Sie awaitTermination() in den folgenden Fällen:

Anwendungsfall Verhalten
Interaktive Notizbücher für die gesamte Berechnung awaitTermination() hält die Zelle aktiv, ermöglicht es Ihnen, den Abfragezustand zu beobachten und stellt sicher, dass Fehler in der Notizbuchausgabe angezeigt werden.
Lokale und Entwicklungsumgebungen Wenn Sie ein Spark-Programm lokal ausführen, wird der Prozess beendet, wenn der Hauptthread abgeschlossen ist. Rufen Sie auf awaitTermination() , um das Programm lebendig zu halten, bis die Streamingabfrage abgeschlossen ist oder fehlschlägt.
Fehlerverteilung an den Treiber Ohne awaitTermination() könnte ein Streamingabfragefehler in einem Nichtauftragskontext möglicherweise nicht an den aufrufenden Thread weitergegeben werden. Die Abfrage kann im Hintergrund fehlschlagen, wodurch Fehler schwieriger zu erkennen und zu diagnostizieren sind. Beim Aufruf von awaitTermination() wird die Abfrageausnahme im Treiber erneut ausgelöst.

Verwenden von Planerpools für mehrere Streamingabfragen

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

Standardmäßig werden alle Abfragen, die in einem Notebook gestartet werden, im gleichen fairen 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 in den Abfragen führen, da sie die Clusterressourcen nicht effizient freigeben.

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

Im folgenden Beispiel wird query1 einem dedizierten Pool zugewiesen, während query2 und query3 einen gemeinsamen Planerpool nutzen.

# 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 Eigenschaften muss in derselben Notebook-Zelle vorgenommen werden, in der Ihre Streaming-Abfrage gestartet wird.

Weitere Informationen zu Apache-Fair-Scheduler-Pools finden Sie in der Apache-Fair-Scheduler-Dokumentation.

  • Last updated on