Var skriver Azure Databricks data?

Den här artikeln beskriver platser där Azure Databricks skriver data med vanliga åtgärder och konfigurationer. Eftersom Azure Databricks tillhandahåller en uppsättning verktyg som omfattar många tekniker och interagerar med molnresurser i en modell med delat ansvar varierar standardplatserna som används för att lagra data baserat på körningsmiljön, konfigurationerna och biblioteken.

Informationen i den här artikeln är avsedd att hjälpa dig att förstå standardsökvägar för olika åtgärder och hur konfigurationer kan ändra dessa standardvärden. Dataförvaltare och administratörer som söker vägledning om hur du konfigurerar och kontrollerar åtkomst till data bör se Datastyrning med Unity Catalog.

Mer information om hur du konfigurerar objektlagring och annan datakälla finns i Anslut till datakällor.

Vad är objektlagring?

Vid molnbaserad databehandling refererar objektlagring eller bloblagring till lagringscontainrar som underhåller data som objekt, där varje objekt består av data, metadata och en globalt unik resursidentifierare (URI). Datamanipuleringsåtgärder i objektlagring är ofta begränsade till att skapa, läsa, uppdatera och ta bort (CRUD) via ett REST API-gränssnitt. Vissa objektlagringserbjudanden omfattar funktioner som versionshantering och livscykelhantering. Objektlagring har följande fördelar:

• Hög tillgänglighet, hållbarhet och tillförlitlighet.
• Lägre kostnad för lagring jämfört med de flesta andra lagringsalternativ.
• Oändligt skalbar (begränsas av den totala mängden lagringsutrymme som är tillgängligt i en viss region i molnet).

De flesta molnbaserade datasjöar bygger på öppen källkod dataformat i molnobjektlagring.

Hur använder Azure Databricks objektlagring?

Objektlagring är den huvudsakliga formen av lagring som används av Azure Databricks för de flesta åtgärder. Med Databricks-filsystemet (DBFS) kan Azure Databricks-användare interagera med filer i objektlagring på liknande sätt som i andra filsystem. Om du inte specifikt konfigurerar en tabell mot ett externt datasystem lagrar alla tabeller som skapats i Azure Databricks data i molnobjektlagring.

Delta Lake-filer som lagras i molnobjektlagring utgör grunden för Databricks lakehouse.

Vad är blocklagring?

I molnbaserad databehandling refererar blocklagring eller disklagring till lagringsvolymer som motsvarar traditionella hårddiskar (HDD) eller solid state-enheter (SSD), även kallade "hårddiskar". När du distribuerar blocklagring i en molnbaserad databehandlingsmiljö distribueras vanligtvis en logisk partition av en eller flera fysiska enheter. Implementeringarna varierar något mellan produkterbjudanden och molnleverantörer, men följande egenskaper finns vanligtvis i implementeringar:

• Alla virtuella datorer (VM) kräver en ansluten blocklagringsvolym.
• Filer och program som är installerade på en blocklagringsvolym bevaras så länge blocklagringsvolymen bevaras.
• Blocklagringsvolymer används ofta för tillfällig datalagring.
• Blocklagringsvolymer som är anslutna till virtuella datorer tas vanligtvis bort tillsammans med virtuella datorer.

Hur använder Azure Databricks blocklagring?

När du aktiverar beräkningsresurser konfigurerar och distribuerar Azure Databricks virtuella datorer och kopplar blocklagringsvolymer. Den här blocklagringen används för att lagra tillfälliga datafiler under beräkningstiden. Dessa filer inkluderar operativsystemet och installerade bibliotek, förutom data som används av diskcachen. Apache Spark använder blocklagring i bakgrunden för effektiv parallellisering och datainläsning, men de flesta kodkörningar på Azure Databricks sparar eller läser inte in data direkt för att blockera lagring.

Du kan köra godtycklig kod, till exempel Python- eller Bash-kommandon som använder blocklagringen som är kopplad till drivrutinsnoden. Se Arbeta med filer i tillfällig lagring som är kopplad till drivrutinsnoden.

Var lagrar Unity Catalog datafiler?

Unity Catalog förlitar sig på administratörer för att konfigurera relationer mellan molnlagring och relationsobjekt. Den exakta platsen där data finns beror på hur administratörer har konfigurerat relationer.

Data som skrivs eller laddas upp till objekt som styrs av Unity Catalog lagras på någon av följande platser:

• En hanterad lagringsplats som är associerad med ett metaarkiv, en katalog eller ett schema. Data som skrivs eller laddas upp till hanterade tabeller och hanterade volymer använder hanterad lagring. Se Hanterad lagring.
• En extern plats som konfigurerats med autentiseringsuppgifter för lagring. Data som skrivs eller laddas upp till externa tabeller och externa volymer använder extern lagring. Se Anslut till molnobjektlagring med hjälp av Unity Catalog.

Var lagrar Databricks SQL databackingtabeller?

När du kör en CREATE TABLE instruktion med Databricks SQL som konfigurerats med Unity Catalog är standardbeteendet att lagra datafiler på en hanterad lagringsplats som konfigurerats med Unity Catalog. Se Var lagrar Unity Catalog datafiler?.

Den äldre hive_metastore katalogen följer olika regler. Se Arbeta med Unity Catalog och det äldre Hive-metaarkivet.

Var lagrar Delta Live Tables datafiler?

Databricks rekommenderar att du använder Unity Catalog när du skapar DLT-pipelines. Data lagras i kataloger på den hanterade lagringsplats som är associerad med målschemat.

Du kan också konfigurera DLT-pipelines med Hive-metaarkiv. När du har konfigurerat med Hive-metaarkivet kan du ange en lagringsplats på DBFS eller molnobjektlagring. Om du inte anger någon plats tilldelas en plats i DBFS-roten till din pipeline.

Var skriver Apache Spark datafiler?

Databricks rekommenderar att du använder objektnamn med Unity Catalog för att läsa och skriva data. Du kan också skriva filer till Unity Catalog-volymer med hjälp av följande mönster: /Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>. Du måste ha tillräcklig behörighet för att ladda upp, skapa, uppdatera eller infoga data i Unity Catalog-reglerade objekt.

Du kan också använda universella resursindikatorer (URI:er) för att ange sökvägar till datafiler. URI:er varierar beroende på molnleverantören. Du måste också ha skrivbehörigheter som konfigurerats för att din aktuella beräkning ska kunna skriva till molnobjektlagring.

Azure Databricks använder Databricks-filsystemet för att mappa Apache Spark-läs- och skrivkommandon tillbaka till molnobjektlagring. Varje Azure Databricks-arbetsyta levereras med en DBFS-rotlagringsplats som konfigurerats i det molnkonto som allokerats för arbetsytan, som alla användare kan komma åt för att läsa och skriva data. Databricks rekommenderar inte att du använder DBFS-roten för att lagra produktionsdata. Se Vad är Databricks-filsystemet (DBFS)? och Rekommendationer för att arbeta med DBFS-roten.

Var skriver Pandas datafiler på Azure Databricks?

I Databricks Runtime 14.0 och senare är den aktuella standardkatalogen (CWD) för alla lokala Python-läs- och skrivåtgärder katalogen som innehåller notebook-filen. Om du endast anger ett filnamn när du sparar en datafil sparar Pandas datafilen som en arbetsytefil parallellt med den notebook-fil som körs.

Alla Databricks Runtime-versioner stöder inte arbetsytefiler, och vissa Databricks Runtime-versioner har olika beteende beroende på om du använder notebook-filer eller Git-mappar. Se Vad är standardkatalogen för aktuell arbetskatalog?.

Var ska jag skriva temporära filer på Azure Databricks?

Om du måste skriva temporära filer som du inte vill behålla när klustret har stängts av, ger skrivning av $TEMPDIR temporära filer bättre prestanda än att skriva till den aktuella arbetskatalogen (CWD) om CWD finns i arbetsytans filsystem. Du kan också undvika att överskrida gränserna för grenstorlek om koden körs på en lagringsplats. Mer information finns i Storleksbegränsningar för filer och lagringsplatser.

Skriv till /local_disk0 om mängden data som ska skrivas är mycket stor och du vill att lagringen ska skalas automatiskt.