Streamen auf serverlosem Compute

Auf dieser Seite wird beschrieben, wie Sie die richtige Konfiguration für serverlose Streaming-Workloads auf Azure Databricks auswählen, einschließlich kontinuierlicher Pipelines, inkrementeller Datenerfassung und verwalteter Konnektoren. Die Auswahl der richtigen Konfiguration hängt von den Anforderungen der Quelle, des Shapes und der Latenz des Datenstroms ab.

Was als Streaming-Workload zählt

Eine Streaming-Workload liest potenziell unbegrenzte Daten aus einer Quelle (z. B. einem Cloud-Objektspeicher, einem Nachrichtenbus oder einem Changefeed) und schreibt sie inkrementell in ein Ziel. Azure Databricks unterstützt zwei Muster von Streamingworkloads:

  • Kontinuierlich: Eine Pipeline, die ohne Unterbrechung läuft und neue Daten verarbeitet, sobald sie eintreffen. Die Latenz wird in Sekunden gemessen.
  • Inkrementell (auch als triggerbasiert bezeichnet): Eine Pipeline, die nach einem Zeitplan oder durch einen Trigger ausgeführt wird, verarbeitet alle Daten, die seit der letzten Ausführung eingegangen sind, und endet. Die Latenz wird in Minuten gemessen.

Einige Workloads sehen wie Streaming-Pipelines aus, sind technisch gesehen aber keine Pipelines. Beispiele sind ein Dienst, der ein Websocket enthält, um auf Ereignisse zu lauschen, eine Chatanwendung, die eine dauerhafte Verbindung pro Benutzer verwaltet, oder einen Webhook-Empfänger, der eingehende HTTP-Anforderungen verarbeitet. Hierbei handelt es sich um Anwendungen, nicht um Streamingpipelinen. Die richtige serverlose Option für diese Workloads finden Sie unter Workloads, die keine Streamingpipelines sind.

Auswählen der richtigen Streamingkonfiguration

Diese Tabelle ordnet Anwendungsfälle den serverlosen Konfigurationen zu, die am besten geeignet sind. Die folgenden Abschnitte auf dieser Seite enthalten weitere Details zu diesen Empfehlungen.

Anwendungsfall Empfohlene Konfiguration Warum?
Kontinuierliches ETL-Streaming oder kontinuierliche Transformationen mit geringer Latenz Lakeflow Spark Declarative Pipelines im kontinuierlichen Modus Der fortlaufende Modus wurde für Always-On-Datenströme entwickelt. Stream-Pipelining führt Mikrobatches gleichzeitig aus, um den Durchsatz und die Latenz zu verbessern. Der verwaltete Zustand sorgt dafür, dass die Wiederherstellung automatisch erfolgt.
Inkrementelle Aufnahme aus Cloudspeicher Verwenden Sie "Auto Loader " innerhalb von Lakeflow Spark Declarative Pipelines (für niedrige Latenz) oder in einem serverlosen Auftrag mit Trigger.AvailableNow() (wenn niedrigere Latenz akzeptabel ist). Auto Loader verfolgt neue Dateien effizient. Trigger.AvailableNow() verarbeitet den Backlog und wird dann beendet, was gut zu einem geplanten oder bedarfsgesteuerten Ausführungsrhythmus passt.
Verwaltete Datenaufnahme aus SaaS-Quellen oder Datenbank-CDC Standardverbindungen in Lakeflow Verbindung Vollständig verwaltete Konnektoren mit serverlosen Ingestionspipelines. Für unterstützte Quellen ist kein Code erforderlich.
Streamen von SQL über Delta-Tabellen Streamingtabellen SQL-native inkrementelle Verarbeitung für anfügeorientierte Quellen mit verwalteten Pipelines und Aktualisierung.
Periodische Verarbeitung in Mikro-Batches in einem Notebook oder Job Serverlose Arbeit mit Trigger.AvailableNow() Kosteneffizient, wenn die Frische auf Minutenniveau ausreicht. Die serverlose Berechnung wird schnell gestartet und beendet, wenn der Batch abgeschlossen ist.

Kontinuierliches Streaming

Verwenden Sie für kontinuierliches Streaming auf serverlosem Compute Lakeflow Spark Declarative Pipelines im fortlaufenden Modus. Die Pipeline bleibt in Betrieb, verarbeitet Datensätze, sobald sie eintreffen, und erholt sich automatisch von Fehlern.

So konfigurieren Sie einen fortlaufenden Datenstrom:

Tip

Stream pipelining ist standardmäßig in serverlosen Lakeflow Spark Declarative Pipelines aktiviert. Microbatches werden gleichzeitig und nicht sequenziell ausgeführt, was den Durchsatz für aufnahmeintensive Datenströme verbessert.

Zeitbasierte Structured-Streaming-Trigger wie Trigger.ProcessingTime(interval) und Trigger.Continuous(interval) sind in serverlosen Notebooks oder Jobs nicht verfügbar. Verwenden Sie Lakeflow Spark Declarative Pipelines im fortlaufenden Modus für das Always-On-Muster. Siehe Streaming-Einschränkungen. Trigger.Once() wird unterstützt, ist jedoch veraltet – migrieren Sie vorhandene Abfragen zu Trigger.AvailableNow().

Inkrementelles und ausgelöstes Streaming

Führen Sie für inkrementelles Streaming Structured Streaming mit Trigger.AvailableNow() in einem serverlosen Job aus. Jede Ausführung verarbeitet alle Daten, die seit dem letzten Checkpoint eingegangen sind, und wird anschließend beendet.

So konfigurieren Sie einen serverlosen Auftrag mit inkrementellem Streaming:

Im folgenden Beispiel werden mit Auto Loader neue Dateien aus dem Cloud-Speicher (source_path) gelesen, alle zum Zeitpunkt der Ausführung verfügbaren Daten verarbeitet und in eine Delta-Tabelle geschrieben:

(spark.readStream
   .format("cloudFiles")
   .option("cloudFiles.format", "json")
   .option("cloudFiles.maxFilesPerTrigger", 1000)
   .load(source_path)
   .writeStream
   .trigger(availableNow=True)
   .option("checkpointLocation", checkpoint_path)
   .toTable("catalog.schema.target_table"))

Ein geplanter Trigger.AvailableNow() Job ist das kosteneffizienteste Streaming-Muster in serverlosen Compute-Umgebungen, wenn eine Latenz im Minutenbereich akzeptabel ist. Die Rechenkapazität ist in Sekunden startbereit, führt den Batch-Job aus und fährt sich wieder herunter.

Verwaltete Aufnahme

Wenn es sich bei der Quelle um eine SaaS-Anwendung oder eine betriebsbereite Datenbank handelt, verwenden Sie Lakeflow Connect, anstatt strukturierten Streaming-Code zu schreiben. Lakeflow Connect führt serverlose Ingestionspipelines für Konnektoren wie Salesforce, Workday, SQL Server CDC und PostgreSQL CDC aus. Siehe Managed Connectors in Lakeflow Connect.

Dieser Pfad ist die richtige Antwort, wenn:

  • Für Ihre Quelle ist ein Connector vorhanden.
  • Sie möchten eine verwaltete Pipeline anstelle von benutzerdefiniertem Code.
  • Sie benötigen Schemaentwicklung, Linien und Überwachung außerhalb des Kastens.

SQL-verwaltete inkrementelle Datenverarbeitung

Für Teams, die in erster Linie mit SQL arbeiten, verwenden Sie Streamingtabellen für SQL-native Streaming-Workloads. Sie können Streamingtabellen innerhalb von Lakeflow Spark Declarative Pipelines oder als eigenständige Streamingtabellen definieren.

Bei eigenständigen Streamingtabellen, die mit der CREATE OR REFRESH STREAMING TABLE SQL-Anweisung erstellt wurden, beginnen die anfängliche Aktualisierung der Daten und die Befüllung sofort. Eine dedizierte serverlose Pipeline wird automatisch vom System für jede Streamingtabelle erstellt und verwaltet.

Wenn Sie Batchsemantik-Abfrageergebnisse mit verwalteter Aktualisierung benötigen, verwenden Sie stattdessen materialisierte Ansichten. Siehe Materialisierte Ansichten.

Workloads, die keine Streamingpipelines sind

Eine Workload, die eine langlebige Verbindung halten muss, einen Port abhören oder auf eingehende HTTP-Anforderungen reagieren muss, ist keine Streamingpipeline. es ist eine Anwendung. Führen Sie diese Workloads nicht auf einem serverlosen Auftrag aus. Die richtigen Databricks-Optionen sind:

  • Lange ausgeführte Dienste, die eine dauerhafte Verbindung oder einen HTTP-Endpunkt benötigen: Erstellen Sie den Dienst mit Databricks-Apps. Databricks Apps ist die serverlose Plattform zum Hosten von benutzerdefinierten Anwendungen auf Azure Databricks, einschließlich FastAPI, Flask, Streamlit, Dash, Gradio, Node.jsund Shiny-Apps. Siehe Databricks-Apps.
  • Eingehende Webhooks oder Ereignislistener: Machen Sie einen HTTP-Endpunkt für Databricks-Apps verfügbar, oder beenden Sie den Webhook in einem externen Dienst und schreiben Sie Ereignisse in Cloudspeicher oder einen Nachrichtenbus, und nehmen Sie sie dann mit einer serverlosen Streamingpipeline auf.
  • Benutzerdefinierter Token- oder Anmeldeinformationsaustausch: Verwenden Sie Dienstprinzipale mit OAuth, oder rufen Sie die Databricks-REST-APIs aus einer App auf. Streamingpipelines enthalten keine Sitzungen pro Benutzer oder benutzerdefinierten Tokenstatus.

Wenn Sie prüfen, ob Ihre Workload zu einer Streaming-Pipeline passt, fragen Sie sich:

  • Liest die Workload aus einer unbegrenzten Datenquelle und schreibt in eine Senke? Wenn ja, handelt es sich um eine Streamingpipeline.
  • Muss die Anwendung eine Verbindung zu einem Client offen halten? Wenn ja, ist es eine Anwendung; verwenden Sie Databricks-Apps.

Einschränkungen

Serverless Compute erzwingt die folgenden Streamingeinschränkungen. Keiner von ihnen verhindert die oben genannten Workloads, wenn sie mit dem richtigen Produkt gekoppelt sind.

  • Zeitbasierte strukturierte Streaming-Trigger (Trigger.ProcessingTime(interval) und Trigger.Continuous(interval)) werden in serverlosen Notizbüchern oder Aufträgen nicht unterstützt. Verwenden Sie Lakeflow Spark Declarative Pipelines im fortlaufenden Modus für Always-On-Streams oder Trigger.AvailableNow() für ausgelöste Läufe. Siehe Streaming-Einschränkungen.
  • Streaming-Abfragen ohne expliziten Trigger schlagen mit INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED fehl. Apache Spark verwendet standardmäßig Trigger.ProcessingTime("0 seconds"), was auf serverlosem Compute nicht unterstützt wird. Legen Sie immer für jede Streamingabfrage fest Trigger.AvailableNow() , oder verwenden Sie Lakeflow Spark Declarative Pipelines im fortlaufenden Modus.
  • Alle Einschränkungen für das Streaming im Zugriffsmodus „Standard“ gelten auch für serverloses Computing. Siehe Streaming-Einschränkungen.

Nächste Schritte

  • Last updated on