Where 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, zouden Gegevensbeheer met Unity Catalogmoeten raadplegen.

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

Wat is objectopslag?

In cloudcomputing verwijst objectopslag of blobopslag naar opslagcontainers die gegevens als objecten onderhouden, waarbij elk object bestaat uit gegevens, metagegevens en een wereldwijd unieke 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 Unity Catalog-opslag credentials en externe locaties. Deze locaties worden vervolgens gebruikt voor het opslaan van gegevensbestanden die tables en volumesondersteunen. Zie Verbinding maken met opslag en services voor cloudobjecten met behulp van Unity Catalog.

Tenzij u specifiek een table configureert voor een extern gegevenssysteem, worden alle in Azure Databricks gemaakte tables in cloudobjectopslag opgeslagen.

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 opslag volumes die overeenkomen met traditionele harde schijven (HDD's) of SSD's (solid-state drives), ook wel 'harde schijven' genoemd. Bij het implementeren van blokopslag in een cloudcomputingomgeving wordt typisch een logische partition van een of meer fysieke schijven 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.
• Blokopslag volumes worden vaak gebruikt voor tijdelijke gegevensopslag.
• Blokopslag volumes die aan VM's is gekoppeld, wordt meestal samen met de VM's verwijderd.

Hoe gebruikt Azure Databricks blokopslag?

Wanneer u rekenresources inschakelt, configureert en implementeert Azure Databricks VM's en koppelt blokopslag volumes. 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.

Where slaat Unity Catalog gegevensbestanden op?

Unity Catalog is afhankelijk van beheerders om relaties tussen cloudopslag en relationele objecten te configureren. De exacte locatie waar where gegevens zich bevinden, hangt af van de configuratie van relaties door beheerders.

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

• Een beheerde opslaglocatie die is gekoppeld aan een metastore, catalogof schema. Gegevens die zijn geschreven of geüpload naar beheerde tables en beheerde volumes maken gebruik van beheerde opslag. Zie Een beheerde opslaglocatie opgeven in Unity Catalog.
• Een externe locatie die is geconfigureerd met opslag credentials. Gegevens die zijn geschreven of geüpload naar externe tables en externe volumes maken gebruik van externe opslag. Zie Verbinding maken met opslag en services voor cloudobjecten met behulp van Unity Catalog.

Where slaat Databricks SQL data op als ondersteuning voor tables?

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 Where slaat Unity Catalog gegevensbestanden op.

De verouderde hive_metastorecatalog volgt verschillende regels. Zie Werken met Unity Catalog en de legacy Hive metastore.

Where slaat Delta Live Tables gegevensbestanden op?

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

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.

Where 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 schrijven naar Unity Catalogvolumes met behulp van het volgende patroon: /Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>. U moet voldoende bevoegdheden hebben voor het uploaden, maken, updateof insert van gegevens naar Unity Catalog-beheerde objecten.

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.

Where schrijft Pandas gegevensbestanden in 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?

Where 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 de limieten voor bestanden en opslagplaatsen 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.