Waar schrijft Azure Databricks gegevens?

In dit artikel worden locaties beschreven waar Azure Databricks gegevens schrijft met dagelijkse bewerkingen en configuraties. Omdat Azure Databricks een reeks hulpprogramma's heeft die veel technologieën omvatten en communiceren met cloudresources in een model voor gedeelde verantwoordelijkheid, variëren de standaardlocaties voor het opslaan van gegevens op basis van de uitvoeringsomgeving, configuraties en bibliotheken.

De informatie in dit artikel is bedoeld om inzicht te verkrijgen in standaardpaden voor verschillende bewerkingen en hoe configuraties deze standaardinstellingen kunnen wijzigen. Gegevensstewards en beheerders die op zoek zijn naar richtlijnen voor het configureren en beheren van de toegang tot gegevens, moeten gegevensbeheer met Unity Catalog zien.

Zie Verbinding maken met gegevensbronnen voor meer informatie over het configureren van objectopslag en andere gegevensbronnen.

Wat is objectopslag?

In cloud-computing verwijst objectopslag of blobopslag naar opslagcontainers die gegevens als objecten onderhouden, waarbij elk object bestaat uit gegevens, metagegevens en een globally unique resource identifier (URI). Bewerkingen voor het bewerken van objectopslaggegevens zijn vaak beperkt tot het maken, lezen, bijwerken en verwijderen (CRUD) via een REST API-interface. Sommige objectopslagaanbiedingen omvatten functies zoals versiebeheer en levenscyclusbeheer. Objectopslag heeft de volgende voordelen:

• Hoge beschikbaarheid, duurzaamheid en betrouwbaarheid.
• Lagere opslagkosten vergeleken met de meeste andere opslagopties.
• Oneindig schaalbaar (beperkt door de totale hoeveelheid opslagruimte die beschikbaar is in een bepaalde cloudregio).

De meeste cloudgegevensmeren zijn gebouwd op basis van opensource-gegevensindelingen in cloudobjectopslag.

Hoe gebruikt Azure Databricks objectopslag?

Objectopslag is de belangrijkste vorm van opslag die wordt gebruikt door Azure Databricks voor de meeste bewerkingen. U configureert de toegang tot cloudobjectopslag met behulp van opslagreferenties van Unity Catalog en externe locaties. Deze locaties worden vervolgens gebruikt voor het opslaan van gegevensbestanden die back-ups maken van tabellen en volumes. Zie Verbinding maken met cloudobjectopslag met behulp van Unity Catalog.

Tenzij u specifiek een tabel configureert op basis van een extern gegevenssysteem, slaan alle tabellen die zijn gemaakt in Azure Databricks gegevens op in de opslag van cloudobjecten.

Delta Lake-bestanden die zijn opgeslagen in cloudobjectopslag bieden de gegevensbasis voor een Databricks Lakehouse.

Wat is blokopslag?

In cloud-computing verwijst blokopslag of schijfopslag naar opslagvolumes die overeenkomen met traditionele harde schijven (HDD's) of SSD's (Solid-State Drives), ook wel bekend als 'harde schijven'. Bij het implementeren van blokopslag in een cloudcomputingomgeving wordt doorgaans een logische partitie van een of meer fysieke stations geïmplementeerd. Implementaties variëren enigszins tussen productaanbiedingen en cloudleveranciers, maar de volgende kenmerken zijn meestal te vinden in implementaties:

• Voor alle virtuele machines (VM's) is een gekoppeld blokopslagvolume vereist.
• Bestanden en programma's die zijn geïnstalleerd op een blokopslagvolume, blijven behouden zolang het blokopslagvolume zich blijft voordoen.
• Blokopslagvolumes worden vaak gebruikt voor tijdelijke gegevensopslag.
• Blokopslagvolumes die aan VM's zijn gekoppeld, worden meestal verwijderd naast VM's.

Hoe gebruikt Azure Databricks blokopslag?

Wanneer u rekenresources inschakelt, configureert en implementeert Azure Databricks VM's en koppelt u blokopslagvolumes. Deze blokopslag wordt gebruikt voor het opslaan van tijdelijke gegevensbestanden voor de levensduur van de rekenresource. Deze bestanden omvatten het besturingssysteem, geïnstalleerde bibliotheken en gegevens die door de schijfcache worden gebruikt. Hoewel Apache Spark blokopslag op de achtergrond gebruikt voor efficiënte parallellisatie en het laden van gegevens, worden de meeste code die wordt uitgevoerd in Azure Databricks, niet rechtstreeks gegevens opgeslagen of geladen om opslag te blokkeren.

U kunt willekeurige code uitvoeren, zoals Python- of Bash-opdrachten die gebruikmaken van de blokopslag die is gekoppeld aan het stuurprogrammaknooppunt. Zie Werken met bestanden in tijdelijke opslag die is gekoppeld aan het stuurprogrammaknooppunt.

Waar worden gegevensbestanden opgeslagen in Unity Catalog?

Unity Catalog is afhankelijk van beheerders voor het configureren van relaties tussen cloudopslag en relationele objecten. De exacte locatie waar gegevens zich bevinden, is afhankelijk van de wijze waarop beheerders relaties hebben geconfigureerd.

Gegevens die zijn geschreven of geüpload naar objecten die onder Unity Catalog vallen, worden opgeslagen op een van de volgende locaties:

• Een beheerde opslaglocatie die is gekoppeld aan een metastore, catalogus of schema. Gegevens die zijn geschreven of geüpload naar beheerde tabellen en beheerde volumes maken gebruik van beheerde opslag. Zie Een beheerde opslaglocatie opgeven in Unity Catalog.
• Een externe locatie die is geconfigureerd met opslagreferenties. Gegevens die zijn geschreven of geüpload naar externe tabellen en externe volumes maken gebruik van externe opslag. Zie Verbinding maken met cloudobjectopslag met behulp van Unity Catalog.

Waar slaat Databricks SQL gegevensbackingtabellen op?

Wanneer u een CREATE TABLE instructie uitvoert met Databricks SQL die is geconfigureerd met Unity Catalog, is het standaardgedrag het opslaan van gegevensbestanden op een beheerde opslaglocatie die is geconfigureerd met Unity Catalog. Zie waar worden gegevensbestanden opgeslagen in Unity Catalog?

De verouderde hive_metastore catalogus volgt verschillende regels. Zie Werken met Unity Catalog en de verouderde Hive-metastore.

Waar worden gegevensbestanden van Delta Live Tables opgeslagen?

Databricks raadt u aan Unity Catalog te gebruiken bij het maken van DLT-pijplijnen. Gegevens worden opgeslagen in mappen op de beheerde opslaglocatie die is gekoppeld aan het doelschema.

U kunt eventueel DLT-pijplijnen configureren met behulp van hive-metastore. Wanneer deze is geconfigureerd met Hive-metastore, kunt u een opslaglocatie opgeven in DBFS of cloudobjectopslag. Als u geen locatie opgeeft, wordt een locatie in de DBFS-hoofdmap toegewezen aan uw pijplijn.

Waar schrijft Apache Spark gegevensbestanden?

Databricks raadt aan om objectnamen te gebruiken met Unity Catalog voor het lezen en schrijven van gegevens. U kunt ook bestanden naar Unity Catalog-volumes schrijven met behulp van het volgende patroon: /Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>. U moet over voldoende bevoegdheden beschikken om gegevens te uploaden, te maken, bij te werken of in te voegen voor objecten die door de Unity-catalogus worden beheerd.

U kunt desgewenst universal resource indicators (URI's) gebruiken om paden naar gegevensbestanden op te geven. URI's variëren afhankelijk van de cloudprovider. U moet ook schrijfmachtigingen hebben geconfigureerd voor uw huidige rekenresource om naar de opslag van cloudobjecten te kunnen schrijven.

Azure Databricks maakt gebruik van het Databricks-bestandssysteem om Lees- en schrijfopdrachten van Apache Spark weer toe te wijzen aan cloudobjectopslag. Elke Azure Databricks-werkruimte heeft een DBFS-hoofdopslaglocatie die is geconfigureerd in het cloudaccount dat is toegewezen voor de werkruimte, waartoe alle gebruikers toegang hebben voor het lezen en schrijven van gegevens. Databricks raadt het gebruik van de DBFS-hoofdmap niet aan om productiegegevens op te slaan. Zie Wat is DBFS? en aanbevelingen voor het werken met de DBFS-hoofdmap.

Waar schrijft Pandas gegevensbestanden op Azure Databricks?

In Databricks Runtime 14.0 en hoger is de standaard huidige werkmap (CWD) voor alle lokale lees- en schrijfbewerkingen van Python de map die het notebook bevat. Als u alleen een bestandsnaam opgeeft bij het opslaan van een gegevensbestand, slaat Pandas dat gegevensbestand op als een werkruimtebestand parallel aan uw huidige actieve notebook.

Niet alle Databricks Runtime-versies ondersteunen werkruimtebestanden en sommige Databricks Runtime-versies hebben een verschillend gedrag, afhankelijk van of u notebooks of Git-mappen gebruikt. Zie Wat is de standaard huidige werkmap?

Waar moet ik tijdelijke bestanden schrijven in Azure Databricks?

Als u tijdelijke bestanden moet schrijven die u niet wilt behouden nadat het cluster is afgesloten, schrijft u de tijdelijke bestanden om betere prestaties te $TEMPDIR behalen dan schrijven naar de huidige werkmap (CWD) als de CWD zich in het bestandssysteem van de werkruimte bevindt. U kunt ook voorkomen dat de limieten voor vertakkingsgrootte worden overschreden als de code wordt uitgevoerd in een opslagplaats. Zie limieten voor bestands- en opslagplaatsgrootten voor meer informatie.

Schrijf naar /local_disk0 als de hoeveelheid gegevens die moet worden geschreven groot is en u wilt dat de opslag automatisch wordt geschaald.