Freigeben über

Wohin schreibt Azure Databricks Daten?

  • Artikel

In diesem Artikel werden die Speicherorte beschrieben, an denen Azure Databricks Daten bei alltäglichen Vorgängen und Konfigurationen schreibt. Da Azure Databricks eine Reihe von Tools bereitstellt, die viele Technologien umfassen und mit Cloudressourcen in einem Modell mit gemeinsamer Verantwortung interagieren, variieren die Standardspeicherorte, die zum Speichern von Daten verwendet werden, je nach Ausführungsumgebung, Konfigurationen und Bibliotheken.

Die Informationen in diesem Artikel sollen Ihnen helfen, Standardpfade für verschiedene Vorgänge zu verstehen. Darüber hinaus erfahren Sie, wie Konfigurationen diese Standardwerte ändern können. Data Stewards und Administrator/Administratorinnen, die Leitfäden zum Konfigurieren und Steuern des Zugriffs auf Daten benötigen, lesen den Artikel Datengovernance mit Unity Catalog.

Informationen zum Konfigurieren der Objektspeicherung und anderer Datenquellen finden Sie unter Herstellen einer Verbindung mit Datenquellen.

Was ist Objektspeicher?

In Cloud Computing bezieht sich Objektspeicher oder Blobspeicher auf Speichercontainer, die Daten als Objekte verwalten. Dabei besteht jedes Objekt aus Daten, Metadaten und einem global eindeutigen Ressourcenbezeichner (Uniform Resource Identifier, URI). Bearbeitungsvorgänge für Daten im Objektspeicher sind häufig auf das Erstellen, Lesen, Aktualisieren und Löschen über eine REST-API-Schnittstelle beschränkt. Einige Objektspeicherangebote umfassen Features wie Versionsverwaltung und Lebenszyklusverwaltung. Objektspeicher bietet die folgenden Vorteile:

  • Hochverfügbarkeit, Dauerhaftigkeit und Zuverlässigkeit
  • Geringere Speicherkosten im Vergleich zu den meisten anderen Speicheroptionen
  • Unendliche Skalierbarkeit (begrenzt durch die Gesamtmenge des verfügbaren Speichers in einer bestimmten Cloudregion)

Die meisten cloudbasierten Data Lakes basieren auf Open Source-Datenformaten im Cloudobjektspeicher.

Wie nutzt Azure Databricks den Objektspeicher?

Objektspeicher ist die Hauptform des Speichers, die von Azure Databricks für die meisten Vorgänge verwendet wird. Sie konfigurieren den Zugriff auf Cloudobjektspeicher mit Unity Catalog-Speicheranmeldeinformationen und externen Speicherorten. Diese Speicherorte werden dann zum Speichern von Datendateien verwendet, die Tabellen und Volumes zugrunde liegen. Siehe Verbinden mit Cloudobjektspeicher und -diensten mithilfe des Unity-Katalogs.

Sofern Sie keine Tabelle speziell für ein externes Datensystem konfigurieren, speichern alle in Azure Databricks erstellten Tabellen Daten im Cloudobjektspeicher.

Delta Lake-Dateien, die im Cloudobjektspeicher gespeichert sind, bilden die Datengrundlage für ein Databricks-Lakehouse.

Was ist Blockspeicher?

Im Cloud Computing beziehen sich Blockspeicher oder Datenträgerspeicher auf Speichervolumes, die herkömmlichen Festplattenlaufwerken (HDDs) oder Solid State Drives (SSDs) entsprechen, die auch als „Festplatten“ bezeichnet werden. Bei der Bereitstellung von Blockspeicher in einer Cloud-Computing-Umgebung wird in der Regel eine logische Partition physischer Laufwerke bereitgestellt. Implementierungen unterscheiden sich geringfügig zwischen Produktangeboten und Cloudanbietern, aber die folgenden Merkmale sind in der Regel bei allen Implementierungen zu finden:

  • Alle virtuellen Computer (Virtual Machines, VMs) erfordern ein angefügtes Blockspeichervolume.
  • Dateien und Programme, die auf einem Blockspeichervolume installiert werden, bleiben so lange erhalten, wie das Blockspeichervolume beibehalten wird.
  • Blockspeichervolumes werden häufig für die temporäre Datenspeicherung verwendet.
  • An VMs angefügte Blockspeichervolumes werden in der Regel zusammen mit VMs gelöscht.

Wie nutzt Azure Databricks den Blockspeicher?

Wenn Sie Computeressourcen aktivieren, werden von Azure Databricks VMs konfiguriert und bereitgestellt sowie Blockspeichervolumes angefügt. Dieser Blockspeicher wird zum Speichern kurzlebiger Datendateien für die Lebensdauer der Computeressource verwendet. Zu diesen Dateien gehören das Betriebssystem, installierte Bibliotheken und Daten, die vom Datenträgercache verwendet werden. Während Apache Spark Blockspeicher im Hintergrund für eine effiziente Parallelisierung und das Laden von Daten verwendet, speichert oder lädt der Großteil des in Azure Databricks ausgeführten Codes Daten nicht direkt im bzw. in den Blockspeicher.

Sie können beliebigen Code ausführen, z. B. Python- oder Bash-Befehle, die den an Ihren Treiberknoten angefügten Blockspeicher verwenden. Siehe auch unter Arbeiten mit Dateien im kurzlebigen Speicher, der an den Treiberknoten angefügt ist.

Wo speichert Unity Catalog Datendateien?

Unity Catalog verlässt sich darauf, dass Administrator*innen Beziehungen zwischen Cloudspeicher und relationalen Objekten konfigurieren. Der genaue Speicherort der Daten hängt davon ab, wie Administrator*innen Beziehungen konfiguriert haben.

Daten, die in Objekte geschrieben oder hochgeladen werden, die von Unity Catalog gesteuert werden, werden an einem der folgenden Speicherorte gespeichert:

Wo speichert Databricks SQL Datensicherungstabellen?

Wenn Sie eine CREATE TABLE-Anweisung mit einer Databricks SQL-Instanz ausführen, die mit Unity Catalog konfiguriert ist, werden Datendateien standardmäßig an einem verwalteten Speicherort gespeichert, der mit Unity Catalog konfiguriert ist. Weitere Informationen finden Sie unter Wo speichert Unity Catalog Datendateien?.

Der Legacykatalog hive_metastore folgt unterschiedlichen Regeln. Weitere Informationen finden Sie unter Arbeiten mit Unity Catalog und dem Legacy-Hive-Metastore.

Wo speichert Delta Live Tables Datendateien?

Databricks empfiehlt die Verwendung von Unity Catalog beim Erstellen von DLT-Pipelines. Daten werden in Verzeichnissen innerhalb des verwalteten Speicherorts gespeichert, der dem Zielschema zugeordnet ist.

Sie können DLT-Pipelines optional mithilfe des Hive-Metastore konfigurieren. Bei der Konfiguration mit dem Hive-Metastore können Sie einen Speicherort im DBFS- oder Cloudobjektspeicher angeben. Wenn Sie keinen Speicherort angeben, wird Ihrer Pipeline ein Speicherort im DBFS-Stamm zugewiesen.

Wohin schreibt Apache Spark Datendateien?

Databricks empfiehlt die Verwendung von Objektnamen mit Unity Catalog zum Lesen und Schreiben von Daten. Sie können Dateien auch im folgenden Format auf Unity Catalog-Volumes schreiben: /Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>. Sie müssen über ausreichende Berechtigungen zum Hochladen, Erstellen, Aktualisieren oder Einfügen von Daten in von Unity Catalog gesteuerte Objekte verfügen.

Sie können optional URIs (Universal Resource Indicators) verwenden, um Pfade zu Datendateien anzugeben. URIs variieren je nach Cloudanbieter. Außerdem müssen für Ihre aktuelle Computeressource Schreibberechtigungen konfiguriert sein, damit in den Cloudobjektspeicher geschrieben werden kann.

Azure Databricks verwendet das Databricks-Dateisystem, um Apache Spark-Lese- und Schreibbefehle wieder dem Cloudobjektspeicher zuzuordnen. Jeder Azure Databricks-Arbeitsbereich verfügt über einen DBFS-Stammspeicherort. Dieser ist im Cloudkonto konfiguriert, das dem Arbeitsbereich zugeordnet ist, auf den alle Benutzer zum Lesen und Schreiben von Daten zugreifen können. Databricks empfiehlt, nicht den DBFS-Stamm zum Speichern von Produktionsdaten zu verwenden. Weitere Informationen unter Was ist DBFS? und Empfehlungen für die Arbeit mit DBFS-Stamm.

Wohin schreibt Pandas Datendateien in Azure Databricks?

In Databricks Runtime 14.0 und höher ist das aktuelle Standardarbeitsverzeichnis (CWD) für alle lokalen Lese- und Schreibvorgänge von Python das Verzeichnis, das das Notebook enthält. Wenn Sie beim Speichern einer Datendatei nur einen Dateinamen angeben, speichert Pandas diese Datendatei als Arbeitsbereichsdatei parallel zu Ihrem derzeit ausgeführten Notebook.

Nicht alle Databricks Runtime-Versionen unterstützen Arbeitsbereichsdateien, und einige Databricks Runtime-Versionen weisen unterschiedliche Verhaltensweisen auf, je nachdem, ob Sie Notebooks oder Git-Ordner verwenden. Weitere Informationen finden Sie unter Was ist das aktuelle Standardarbeitsverzeichnis?.

Wohin schreibe ich auf Azure Databricks am besten temporäre Dateien?

Wenn Sie temporäre Dateien schreiben müssen, die Sie nach dem Herunterfahren des Clusters nicht beibehalten möchten, können Sie durch das Schreiben der temporären Dateien in $TEMPDIR eine bessere Leistung als beim Schreiben in das aktuelle Arbeitsverzeichnis (Current Working Directory, CWD) erzielen, wenn sich das aktuelle Arbeitsverzeichnis im Dateisystem des Arbeitsbereichs befindet. Sie können auch eine Überschreitung der Grenzwerte für die Branchgröße vermeiden, wenn der Code in einem Repository ausgeführt wird. Weitere Informationen finden Sie unter Datei- und Repositorygrenzwerte.

Schreiben Sie in /local_disk0, wenn die zu schreibende Menge an Daten sehr groß ist und der Speicher automatisch skaliert werden soll.