Produktionsüberlegungen für strukturiertes Streaming

Führen Sie produktionsstrukturierte Streaming-Workloads als geplante Lakeflow-Aufträge auf Azure Databricks aus. 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-Einzelvorgänge mit Job Compute.
  • Planen von Lakeflow-Aufträgen mithilfe des Continuous Modus. Dies bezieht sich auf das Planungsfeature für Azure Databricks-Einzelvorgänge, nicht auf das Intervall für strukturiertes Streaming Triggerintervall.
  • Aktivieren Sie die automatische Skalierung für die Berechnung für Strukturierte Streaming-Aufträge nicht.

Einige Workloads profitieren von folgendem:

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 Clusterauslastung von Lakeflow Spark Declarative Pipelines mit automatischer Skalierung.

:::note Serverloses Computing

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

Verwenden Sie für kontinuierliches Streaming auf serverlosem Computing den Modus „Ausgelöste vs. kontinuierliche Pipeline“ im kontinuierlichen 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 foreachBatch bieten eine Garantie vom Typ „Mindesten 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".

Beim erneuter Ausführung eines Einzelvorgangs

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 Bereitstellung von Jobs Compute, das für die einzelnen Streamingaufgaben entsprechend dimensioniert ist. Sie können optional die Rechenleistung auf Aufgaben verteilen. Alle Abfragen teilen sich dasselbe Compute. Sie können optional Abfragen den Scheduler-Pools zuweisen.
Wie werden Wiederholungsversuche gehandhabt? Alle Vorgänge müssen fehlschlagen, bevor der Auftrag erneut ausgeführt wird. Die Aufgabe wird wiederholt, wenn eine der Abfragen fehlschlägt.

Weitere Informationen zum Arbeiten mit mehreren Aufgaben oder Abfragen finden Sie unter Ausführen mehrerer strukturierter Streamingabfragen auf demselben Cluster.

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 Notebookzellen ihren Lauf abschließen, und verhindern, dass der Einzelvorgangsdienst die Streamingabfrage nachverfolgt, was zu Unterbrechungen bei Backlogmetriken und Einzelvorgangsbenachrichtigungen führt.

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

Anwendungsfall Verhalten
Interaktive Notebooks für den All-Purpose Compute 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.
  • Last updated on