Konfigurieren des Autoloaders für Produktionsworkloads

Artikel
11/07/2024

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

Databricks empfiehlt die Verwendung des Autoloaders in Delta Live Tables für die inkrementelle Datenerfassung. Delta Live Tables erweitert die Funktionalität von Apache Spark Structured Streaming und ermöglicht Ihnen, mit nur wenigen deklarativen Python- oder SQL-Codezeilen eine Datenpipeline auf Produktionsniveau zu schreiben:

Automatische Skalierung der Computeinfrastruktur für Kosteneinsparungen
Überprüfung der Datenqualität mit Erwartungen
Automatische Schemaentwicklung
Überwachung mit Metriken im Ereignisprotokoll

Überwachen des Autoloaders

Abfragen von Dateien, die mit dem Autoloader entdeckt wurden

Hinweis

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 Autoloader-Stream verbundenen Prüfpunkt zu ermitteln.

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

Hören von Streamupdates

Zum weiteren Überwachen von Autoloader-Streams empfiehlt Databricks die Verwendung der Streamingabfragelistener-Schnittstelle von Apache Spark.

Autoloader 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 Rohdaten anhand der Metriken numFilesOutstanding und numBytesOutstanding erkennen:

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

In Databricks Runtime 10.4 LTS und höher enthalten die Metriken bei Verwendung des Dateibenachrichtigungsmodus auch die ungefähre Anzahl Dateiereignisse, die sich in der Cloudwarteschlange befinden, z. B. als approximateQueueSize für AWS und Azure.

Kostenbetrachtung

Beim Ausführen des automatischen Ladevorgangs sind die Kosten für Computeressourcen und die Dateiermittlung die Hauptkostenquelle.

Um Computekosten zu senken, empfiehlt Databricks die Verwendung von Databricks-Aufträgen, um den Autoloader als Batchaufträge mit Trigger.AvailableNow zu planen anstatt diese kontinuierlich auszuführen, solange sie keine geringen Latenzanforderungen haben. Weitere Informationen finden Sie unter Konfigurieren strukturierter Streaming-Triggerintervalle.

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

Bereitstellen eines ProcessingTime-Triggers beim fortlaufenden Ausführen des Autoloaders im Verzeichnisauflistungsmodus
Entwerfen von Dateiuploads in Ihr Speicherkonto in lexikalischer Reihenfolge, um die inkrementelle Auflistung (veraltet) nach Möglichkeit zu nutzen
Nutzen von Dateibenachrichtigungen, wenn eine inkrementelle Auflistung nicht möglich ist
Verwenden von Ressourcentags zum Markieren von Ressourcen, die vom Autoloader erstellt wurden, um Ihre Kosten nachzuverfolgen

Verwenden von Trigger.AvailableNow und Ratenbegrenzung

Hinweis

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

Das automatische Ladeprogramm kann für die Ausführung in Databricks-Aufträgen als Batchauftrag mit 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

Databricks empfiehlt das Festlegen des Prüfpunktstandorts auf einen Standort ohne eine Cloudobjektlebenszyklus-Richtlinie. Wenn Dateien am Prüfpunktspeicherort gemäß der Richtlinie bereinigt werden, ist der Datenstromstatus beschädigt. In diesem Fall müssen Sie den Datenstrom von Grund auf neu starten.

Aufbewahrung von Ereignissen

Der Autolader verfolgt die ermittelten Dateien am Prüfpunktspeicherort mithilfe von RocksDB nach, um die einmalige Erfassung der Dateien zu garantieren. Databricks empfiehlt dringend die Verwendung der Option cloudFiles.maxFileAge für alle umfangreichen oder langlebigen Erfassungsstreams. Mit dieser Option laufen die Ereignisse am Ort des Prüfpunkts ab, was die Startzeit des automatischen Ladeprogramms beschleunigt. Die Startzeit kann sich bei jeder Ausführung des automatischen Ladeprogramms auf mehrere Minuten verlängern., was zu unnötigen Kosten führt, wenn Sie eine Obergrenze für das maximale Alter der Dateien haben, die im Quellverzeichnis gespeichert werden. Der Mindestwert, den Sie für cloudFiles.maxFileAge festlegen können, ist "14 days". Löschungen in RocksDB erscheinen als Tombstone-Einträge. Sie sollten deshalb damit rechnen, dass die Speichernutzung mit dem Ablauf von Ereignissen vorübergehend ansteigt und sich dann wieder verringert.

Warnung

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 "2 months" für cloudFiles.maxFileAge 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 Abgleiche mithilfe von cloudFiles.backfillInterval

Autoloader kann in einem bestimmten Intervall asynchrone Abgleiche auslösen, z. B. einen Tag für einen einmaligen Abgleich pro Tag, oder eine Woche für einen einmaligen Abgleich pro Woche. Benachrichtigungssysteme für Dateiereignisse garantieren keine 100-prozentige Bereitstellung aller hochgeladenen Dateien und bieten keine strengen SLAs für die Latenzzeit der Dateiereignisse. Databricks empfiehlt, regelmäßige Abgleiche mit dem Autoloader auszulösen, indem Sie die Option cloudFiles.backfillInterval verwenden, um sicherzustellen, dass alle Dateien innerhalb einer bestimmten SLA ermittelt werden, wenn die Vollständigkeit der Daten eine Anforderung ist. Das Auslösen regelmäßiger Backfills verursacht keine Duplikate.

Freigeben über