Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Das Lesen von Daten aus dem Cloud-Objektspeicher ist langsamer als das Lesen von einer lokalen Festplatte. Ohne Caching rufen Abfragen und Notizbücher, die dieselben Parquet-Datendateien lesen, sie jedes Mal wiederholt aus dem Cloud-Objektspeicher ab.
Azure Databricks verwendet Festplatten-Caching, um die Datenlesungen zu beschleunigen. Wenn ein Knoten eine Parquet-Datendatei aus dem entfernten Speicher abruft, speichert er automatisch eine Kopie auf seinem lokalen Speicher in einem schnellen Zwischenformat. Spätere Lesevorgänge derselben Daten laufen lokal und sind deutlich schneller. Der Cache funktioniert für alle Parquet-Datendateien, einschließlich der Delta-Lake-Tabellen.
Hinweis
In SQL-Warehouses und Databricks Runtime 14.2 und höher wird der Befehl CACHE SELECT ignoriert. Stattdessen wird ein erweiterter Datenträgerzwischenspeicherungsalgorithmus verwendet.
Bewährte Vorgehensweisen
Der Festplattencache hilft am meisten bei Arbeitslasten, die dieselben Daten mehrfach lesen, wie wiederholte oder iterative Abfragen auf denselben Tabellen. Azure Databricks aktiviert es automatisch bei Worker-Instanztypen, die es unterstützen. Um den Festplattencache beim Beschleunigen von Lesezugriffen zu unterstützen, befolgen Sie folgende Vorgehensweisen:
- Wählen Sie einen Worker-Instanztyp, der Festplatten-Caching unterstützt. Siehe Auswahl der Instanztypen für das Disk-Zwischenspeichern.
- Verwenden Sie den Festplatten-Cache anstelle des Apache Spark-Caches für wiederholte Lesevorgänge von Parquet- und Delta-Lake-Daten. Siehe Vergleichen Sie den Festplatten-Cache und den Spark-Cache.
Delta-Cache in Disk-Cache umbenannt
Das Zwischenspeichern von Datenträgern in Azure Databricks wurde früher als Delta-Cache und DBIO-Cache bezeichnet. Das Verhalten des Datenträgercachings ist ein proprietäres Azure Databricks-Feature. Diese Namensänderung soll die Verwirrung beseitigen, dass der Eindruck entstand, es sei Teil des Delta-Lake-Protokolls.
Vergleichen Sie den Festplattencache mit dem Spark-Cache
Der Azure Databricks-Datenträgercache unterscheidet sich von der Apache Spark-Zwischenspeicherung. Databricks empfiehlt die Verwendung des automatischen Festplatten-Cachings.
Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen Datenträger- und Apache Spark-Caching zusammen, damit Sie das beste Tool für Ihren Workflow wählen können:
| Funktion | Datenträgercache | Apache Spark-Cache |
|---|---|---|
| Gespeichert als | Lokale Dateien auf einem Workerknoten. | In-Memory-Blöcke, aber es hängt von der Speicherebene ab. |
| Angewendet auf | Jede Parquet-Tabelle, die auf ABFS und anderen Dateisystemen gespeichert ist. | Beliebiger DataFrame oder RDD. |
| Ausgelöst | Automatisch beim ersten Lesen (wenn der Cache aktiviert ist). | Manuell sind Änderungen am Code erforderlich. |
| Ausgewertet | Träge. | Träge. |
| Verfügbarkeit | Standardmäßig bei bestimmten Knotentypen aktiviert. Du aktivierst oder deaktivierst es mit Konfigurations-Flags. | Immer verfügbar. |
| Verdrängt | Automatisch nach dem LRU-Prinzip oder bei jeder Dateiänderung, manuell beim Neustart eines Clusters. | Automatisch nach dem LRU-Prinzip, manuell mit unpersist. |
Datenträgercachekonsistenz
Der Datenträgercache erkennt automatisch, wenn Datendateien erstellt, gelöscht, modifiziert oder überschrieben werden, und aktualisiert seinen Inhalt entsprechend. Sie können Tabellendaten schreiben, ändern und löschen, ohne dass zwischengespeicherte Daten explizit ungültig gemacht werden müssen. Veraltete Einträge werden automatisch invalidiert und aus dem Cache entfernt.
Auswahl der Instanztypen für das Disk-Zwischenspeichern
Der empfohlene (und einfachste) Weg, Datenträgercaching zu verwenden, ist die Auswahl eines Workertyps mit SSD-Volumes, wenn Sie Ihr Cluster konfigurieren. Solche Worker sind für Datenträgercaching aktiviert und konfiguriert.
Der Datenträgercache ist so konfiguriert, dass er höchstens die Hälfte des auf den lokalen SSDs der Workerknoten verfügbaren Speicherplatzes nutzt. Konfigurationsoptionen finden Sie unter Konfigurieren des Datenträgercaches.
Datenträgercache konfigurieren
Databricks empfiehlt, dass Sie cache-beschleunigte Worker-Instanztypen für Ihren Compute wählen. Solche Instanzen werden automatisch optimal für den Datenträgercache konfiguriert.
Hinweis
Wenn ein Worker deaktiviert wird, geht der Spark-Cache, der auf diesem Worker gespeichert ist, verloren. Wenn also die automatische Skalierung aktiviert ist, gibt es eine gewisse Instabilität beim Cache. Spark müsste dann bei Bedarf fehlende Partitionen aus der Quelle neu einlesen.
Datenträgerverwendung konfigurieren
Um zu konfigurieren, wie der Festplattencache den lokalen Speicher der Worker-Knoten nutzt, geben Sie während der Clustererstellung diese Spark-Konfiguration-Einstellungen an:
-
spark.databricks.io.cache.maxDiskUsage: für zwischengespeicherte Daten reservierter Speicherplatz pro Knoten in Bytes -
spark.databricks.io.cache.maxMetaDataCache: für zwischengespeicherte Metadaten reservierter Speicherplatz pro Knoten in Bytes -
spark.databricks.io.cache.compression.enabled: ob die zwischengespeicherten Daten in einem komprimierten Format gespeichert werden sollen
Beispielkonfiguration:
spark.databricks.io.cache.maxDiskUsage 50g
spark.databricks.io.cache.maxMetaDataCache 1g
spark.databricks.io.cache.compression.enabled false
Datenträgercache aktivieren oder deaktivieren
Um die aktuelle Einstellung für den Festplattencache zu sehen, führen Sie aus:
spark.conf.get("spark.databricks.io.cache.enabled")
Um den Datenträgercache zu aktivieren und zu deaktivieren, führen Sie Folgenden aus:
spark.conf.set("spark.databricks.io.cache.enabled", "[true | false]")
Die Deaktivierung des Caches führt nicht zum Löschen der Daten, die sich bereits im lokalen Speicher befinden. Stattdessen wird verhindert, dass Abfragen neue Daten zum Cache hinzufügen und Daten aus dem Cache lesen.