Freigeben über


Konfigurieren des Autoloaders für Produktionsworkloads

Databricks empfiehlt, für den Einsatz des Autoloaders in der Produktion die bewährten Streamingmethoden zu befolgen.

Databricks empfiehlt die Verwendung von Auto Loader in Lakeflow Spark Declarative Pipelines für inkrementelle Datenaufnahme. Lakeflow Spark Declarative Pipelines erweitert die Funktionalität in Apache Spark Structured Streaming und ermöglicht es Ihnen, nur einige Zeilen deklarativen Python- oder SQL-Code zu schreiben, um eine Datenpipeline in Produktionsqualität mit:

Überwachen des Autoloaders

Abfragen von Dateien, die mit dem Autoloader entdeckt wurden

Note

Die cloud_files_state-Funktion ist in Databricks Runtime 11.3 LTS und höher verfügbar.

Autoloader stellt eine SQL-API zur Verfügung, um den Zustand eines Streams zu überprüfen. Mithilfe der cloud_files_state-Funktion finden Sie Metadaten zu Dateien finden, die von einem Autoloader-Stream entdeckt wurden. Fragen Sie einfach von cloud_files_state ab, um den mit einem automatischen Ladeprogramm-Stream verbundenen Prüfpunkt zu ermitteln.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Hören von Streamupdates

Um Auto Loader-Streams weiter zu überwachen, empfiehlt Databricks die Verwendung der Streaming Query Listener-Schnittstelle von Apache Spark.

Das automatische Ladeprogramm meldet Metriken an den Streamingabfragelistener bei jedem Batch. Wie viele Dateien im Rückstand vorhanden sind und wie groß der Rückstand ist, können Sie im Dashboard zum Fortschritt der Streamingabfrage auf der Registerkarte numFilesOutstanding anhand der Metriken numBytesOutstanding und erkennen:

{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

In Databricks Runtime 10.4 LTS und höher, wenn der Dateibenachrichtigungsmodus verwendet wird, enthalten die Metriken auch die ungefähre Anzahl von Dateiereignissen in der Cloudwarteschlange wie approximateQueueSize für AWS und Azure.

Kostenaspekte

Beim Ausführen des Auto Loaders sind die wichtigsten Kostenquellen Rechenressourcen und Dateierkennung.

Um die Rechenkosten zu reduzieren, empfiehlt Databricks die Verwendung von Lakeflow Jobs, um den Auto Loader als Batch-Aufträge mit Trigger.AvailableNow zu planen, anstatt ihn kontinuierlich auszuführen, solange Sie keine niedrige Latenzanforderungen haben. Weitere Informationen finden Sie unter Konfigurieren von Triggerintervallen für strukturiertes Streaming. Diese Batchaufträge können mithilfe von Dateiankunftstriggern ausgelöst werden, um die Latenz zwischen Dateiankunft und Verarbeitung weiter zu verringern.

Die Kosten für die Dateiermittlung können in Form von Vorgängen LIST für Ihre Speicherkonten im Verzeichnislistenmodus und API-Anforderungen für den Abonnementdienst und den Warteschlangendienst im Dateibenachrichtigungsmodus auftreten. Um die Kosten für die Dateiermittlung zu reduzieren, empfiehlt Databricks Folgendes:

  • Nicht die ProcessingTime oder Continuous Trigger verwenden, wenn Auto Loader kontinuierlich im Verzeichnisauflistungsmodus ausgeführt wird. Verwenden Sie stattdessen Auto Loader mit Dateiereignissen. Ausführliche Informationen dazu, wie der Auto Loader mit Dateiereignissen funktioniert, finden Sie im Überblick über den Auto Loader mit Dateiereignissen.
  • Verwenden sie den Benachrichtigungsmodus für ältere Dateien , wenn Sie das automatische Laden nicht mit Dateiereignissen verwenden können. In diesem Modus können Sie Ressourcen kategorisieren, die vom automatischen Laden erstellt wurden, um Ihre Kosten mithilfe von Ressourcentags nachzuverfolgen.

Archivieren von Dateien im Quellverzeichnis zu geringeren Kosten

Note

Verfügbar in Databricks Runtime 16.4 LTS und höher.

Warning

  • Durch die Einstellung cloudFiles.cleanSource werden Dateien im Quellverzeichnis gelöscht oder verschoben.
  • Wenn Sie foreachBatch zur Datenverarbeitung verwenden, werden Ihre Dateien zu Kandidaten für das Verschieben oder Löschen, sobald der foreachBatch-Vorgang erfolgreich abgeschlossen ist, selbst wenn der Vorgang nur eine Teilmenge der Dateien im Batch verwendet hat.

Es wird empfohlen, das automatische Laden mit Dateiereignissen zu verwenden, um die Ermittlungskosten zu senken. Dies senkt auch die Berechnungskosten, da die Ermittlung inkrementell ist.

Wenn Sie keine Dateiereignisse verwenden können und stattdessen die Verzeichnisauflistung zur Erkennung von Dateien nutzen müssen, können Sie die Option cloudFiles.cleanSource verwenden, um Dateien automatisch zu archivieren oder zu löschen, nachdem der Auto Loader sie verarbeitet hat, um die Ermittlungskosten zu senken. Da das automatische Laden Dateien aus Ihrem Quellverzeichnis nach der Verarbeitung bereinigt, müssen weniger Dateien während der Ermittlung aufgelistet werden.

Berücksichtigen Sie bei der Verwendung cloudFiles.cleanSource mit der MOVE Option die folgenden Anforderungen:

  • Sowohl das Quellverzeichnis als auch das Zielverschiebungsverzeichnis müssen sich am gleichen externen Speicherort oder Volume befinden.
  • Wenn sich Ihr Quell- und Zielverzeichnis am gleichen externen Speicherort befinden, sollten sie keine gleichgeordneten Verzeichnisse haben, die verwalteten Speicher enthalten (z. B. ein verwaltetes Volume oder katalog). In diesen Fällen kann Auto Loader nicht die erforderlichen Berechtigungen erhalten, um in das Zielverzeichnis zu schreiben.

Databricks empfiehlt die Verwendung dieser Option in folgenden Fällen:

  • Ihr Quellverzeichnis sammelt im Laufe der Zeit eine große Anzahl von Dateien.
  • Sie müssen verarbeitete Dateien für die Einhaltung von Vorschriften oder für Prüfzwecke aufbewahren (stellen Sie cloudFiles.cleanSource auf MOVE ein).
  • Sie möchten die Speicherkosten reduzieren, indem Sie Dateien nach dem Einlesen entfernen (setzen Sie cloudFiles.cleanSource auf DELETE). Bei Verwendung des DELETE Modus empfiehlt Databricks, die Versionsverwaltung für den Bucket zu aktivieren, damit Auto Loader-Löschungen als sanftes Löschen fungieren und im Falle einer Fehlkonfiguration verfügbar bleiben. Darüber hinaus empfiehlt Databricks, Cloud-Lifecycle-Richtlinien einzurichten, um alte, vorläufig gelöschte Versionen nach einer bestimmten Nachfrist (z. B. 60 oder 90 Tage) basierend auf Ihren Wiederherstellungsanforderungen zu löschen.

Verwenden von Trigger.AvailableNow und Ratenbegrenzung

Note

Verfügbar in Databricks Runtime 10.4 LTS und höher.

Der Autoloader kann zur Ausführung in Lakeflow-Aufträgen als Batchauftrag unter Verwendung von Trigger.AvailableNow geplant werden. Der Trigger AvailableNow weist den Autoloader an, alle Dateien zu verarbeiten, die vor der Startzeit der Abfrage eingetroffen sind. Neue Dateien, die hochgeladen werden, nachdem der Stream gestartet wurde, werden bis zum nächsten Trigger ignoriert.

Mit Trigger.AvailableNow erfolgt die Dateiermittlung asynchron bei der Datenverarbeitung, und Daten können über mehrere Mikrobatches hinweg mit Ratenbegrenzung verarbeitet werden. Der Autoloader verarbeitet standardmäßig maximal 1.000 Dateien pro Microbatch. Sie können cloudFiles.maxFilesPerTrigger und cloudFiles.maxBytesPerTrigger konfigurieren, um zu konfigurieren, wie viele Dateien oder wie viele Bytes in einem Microbatch verarbeitet werden sollen. Der Dateigrenzwert ist ein harter Grenzwert, aber der Bytegrenzwert ist ein weiches Limit, was bedeutet, dass mehr Bytes verarbeitet werden können als die bereitgestellte maxBytesPerTrigger. Wenn beide Optionen zusammen bereitgestellt werden, verarbeitet das automatische Ladeprogramm so viele Dateien, wie erforderlich sind, um einen der Grenzwerte zu überschreiten.

Prüfpunktposition

Der Prüfpunktspeicherort wird verwendet, um den Status und die Fortschrittsinformationen des Datenstroms zu speichern. Databricks empfiehlt das Festlegen des Prüfpunktstandorts als Standort ohne Cloudobjekt-Lebenszyklusrichtlinie. Wenn Dateien am Prüfpunktspeicherort gemäß der Richtlinie bereinigt werden, ist der Datenstromstatus beschädigt. In diesem Fall müssen Sie den Stream neu starten.

Dateiereignisverfolgung

Das automatische Ladeprogramm verfolgt die ermittelten Dateien am Prüfpunktspeicherort mithilfe von RocksDB nach, um die einmalige Erfassung der Dateien zu garantieren. Für hochvolumige oder langlebige Datenerfassungsstreams empfiehlt Databricks ein Upgrade auf Databricks Runtime 15.4 LTS oder höher. In diesen Versionen wartet auto Loader nicht, bis der gesamte RocksDB-Zustand heruntergeladen wird, bevor der Datenstrom gestartet wird, wodurch die Startzeit des Datenstroms beschleunigt werden kann. Wenn Sie verhindern möchten, dass die Dateizustände ohne Einschränkungen wachsen, können Sie auch die cloudFiles.maxFileAge Option zum Ablaufen von Dateiereignissen in Betracht ziehen, die älter als ein bestimmtes Alter sind. Der Mindestwert, den Sie für cloudFiles.maxFileAge festlegen können, ist "14 days". Löschungen in RocksDB werden als Tombstone-Einträge angezeigt. Daher kann die Speichernutzung vorübergehend ansteigen, wenn Ereignisse verfallen, bevor die Speichernutzung sich schließlich stabilisiert.

Warning

cloudFiles.maxFileAge wird als Mechanismus zur Kostenkontrolle für große Datasets bereitgestellt. Eine zu aggressive Optimierung von cloudFiles.maxFileAge kann zu Problemen mit der Datenqualität führen, z. B. zu doppelter Erfassung oder fehlenden Dateien. Daher empfiehlt Databricks eine konservative Einstellung für cloudFiles.maxFileAge, z. B. 90 Tage. Dies entspricht ungefähr der Empfehlung vergleichbarer Datenerfassungslösungen.

Eine Anpassung der Option cloudFiles.maxFileAge kann dazu führen, dass unverarbeitete Dateien vom Autoloader ignoriert werden oder bereits verarbeitete Dateien ablaufen und anschließend erneut verarbeitet werden, was zu doppelten Daten führt. Nachfolgend werden einige Punkte aufgeführt, die Sie bei der Auswahl von cloudFiles.maxFileAge berücksichtigen sollten:

  • Wenn Ihr Stream nach einer längeren Zeit neu gestartet wird, werden aus der Warteschlange abgerufene Dateibenachrichtigungsereignisse ignoriert, die älter sind als cloudFiles.maxFileAge. Ähnlich verhält es sich bei Verwendung der Verzeichnisauflistung: Dateien, die während der Downtime hinzugekommen sind und deren Alter cloudFiles.maxFileAge übersteigt, werden ignoriert.
  • Wenn Sie den Verzeichnisauflistungsmodus verwenden und cloudFiles.maxFileAge z. B. auf "1 month" festlegen, Ihren Stream anhalten und ihn mit dem Wert cloudFiles.maxFileAge für "2 months" neu starten, werden Dateien, die älter als einen Monat, aber jünger als zwei Monate sind, erneut verarbeitet.

Wenn Sie diese Option beim ersten Start des Streams festlegen, werden keine Daten erfasst, die älter sind als cloudFiles.maxFileAge. Wenn Sie also alte Daten erfassen möchten, sollten Sie diese Option beim ersten Start Ihres Streams nicht festlegen. Sie sollten diese Option jedoch für nachfolgende Ausführungen festlegen.

Auslösen regulärer Backfills mithilfe von "cloudFiles.backfillInterval"

In seltenen Fällen werden Dateien möglicherweise verpasst oder verspätet, wenn sie ausschließlich von Benachrichtigungssystemen abhängig sind, z. B. wenn aufbewahrungsgrenzwerte für Benachrichtigungen erreicht werden. Wenn Sie strenge Anforderungen an die Vollständigkeit von Daten und SLA haben, sollten Sie festlegen cloudFiles.backfillInterval , dass asynchrone Rückfüllungen in einem bestimmten Intervall ausgelöst werden. Legen Sie ihn beispielsweise für tägliche Rückfüllungen auf einen Tag oder eine Woche für wöchentliche Rückfüllungen fest. Das Auslösen regelmäßiger Backfills verursacht keine Duplikate.

Wenn Sie Dateiereignisse verwenden, führen Sie Ihren Stream mindestens einmal alle 7 Tage aus.

Führen Sie bei Verwendung von Dateiereignissen Ihre Auto Loader-Streams mindestens einmal alle 7 Tage aus, um eine vollständige Verzeichnisauflistung zu vermeiden. Wenn Sie Ihre Auto Loader Streams so häufig ausführen, wird sichergestellt, dass die Dateierkennung inkrementell erfolgt.

Umfassende bewährte Methoden für verwaltete Dateiereignisse finden Sie unter Bewährte Methoden für das automatische Laden mit Dateiereignissen.