Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I den här artikeln beskrivs kända problem och begränsningar för Azure Data Lake Storage för konton som har funktionen hierarkisk namnrymd aktiverad. Använd den här informationen för att hantera dina dataarbetsflöden och undvika potentiella fallgropar när du använder olika API:er och integreringar.
Kommentar
Vissa av de funktioner som beskrivs i den här artikeln kanske inte stöds i konton som har stöd för NFS (Network File System) 3.0. Information om hur du visar en tabell som visar effekten av funktionsstöd när olika funktioner är aktiverade finns i Stöd för Blob Storage-funktioner i Azure Storage-konton.
Stöd för funktioner, tjänster och plattformar
De flesta bloblagringsfunktioner, Azure tjänstintegreringar och plattformar med öppen källkod stöds i konton som har ett hierarkiskt namnområde. Fullständiga listor finns i:
- Blob Storage funktioner som är tillgängliga i Azure Data Lake Storage
- Azure-tjänster som stöder Azure Data Lake Storage
- Plattformar med öppen källkod som stöder Azure Data Lake Storage
API:er för Blob Storage
Api:er för Data Lake Storage, NFS 3.0 och Blob-API:er kan användas på samma data.
I det här avsnittet beskrivs problem och begränsningar med användning av blob-API:er, NFS 3.0 och Data Lake Storage-API:er för att arbeta med samma data.
Du kan inte använda blob-API:er, NFS 3.0 och Data Lake Storage-API:er för att skriva till samma instans av en fil. Om du skriver till en fil med hjälp av Data Lake Storage API:er eller NFS 3.0 visas inte filens block för anrop till blob-API:et Hämta blockeringslista. Det enda undantaget är när du överskriver. Du kan skriva över en fil eller blob med antingen API eller med hjälp av NFS 3.0 med alternativet zero-truncate (en POSIX-liknande åtgärd som trunkerar filen till noll byte innan du skriver).
Du kan inte skriva över blobar som skapas med hjälp av en Data Lake Storage åtgärd, till exempel åtgärden Sökväg – Skapa med hjälp av PutBlock- eller PutBlockList-åtgärder. Du kan dock skriva över dessa blobar med hjälp av en PutBlob-åtgärd , med förbehåll för den maximala tillåtna blobstorleken som införts av motsvarande API-version som PutBlob använder.
När du använder åtgärden Listblobar utan att ange en avgränsare innehåller resultatet både kataloger och blobar. Om du väljer att använda en avgränsare använder du bara ett snedstreck (
/). Det här är den enda avgränsare som stöds.Om du använder API:et Ta bort blob för att ta bort en katalog tas katalogen bara bort om den är tom. Det här villkoret innebär att du inte kan använda Blob API för att ta bort kataloger rekursivt.
Dessa BLOB REST-API:er stöds inte:
- Placera blob (sida)
- Placera sida
- Hämta sidintervall
- Inkrementell kopieringsblob
- Infoga sida från URL
- Tilläggsblobtätning
Ohanterade vm-diskar stöds inte i konton som har ett hierarkiskt namnområde. Om du vill aktivera ett hierarkiskt namnområde på ett lagringskonto placerar du ohanterade virtuella datordiskar i ett lagringskonto som inte har funktionen hierarkisk namnrymd aktiverad.
Stöd för att ställa in åtkomstkontrollistor (ACL: er) rekursivt i Azure Data Lake Storage
Möjligheten att tillämpa ACL-ändringar rekursivt från överordnad katalog till underordnade objekt är allmänt tillgänglig. I den aktuella versionen av den här funktionen kan du använda ACL-ändringar med hjälp av Azure Storage Explorer, PowerShell, Azure CLI och .NET, Java, Python och Node.js SDK:er. Support är ännu inte tillgängligt för Azure Portal.
Åtkomstkontrollistor (ACL) och anonym läsåtkomst
Om anonym läsåtkomst beviljas till en container har ACL:er ingen effekt på containern eller filerna i containern. Den här begränsningen påverkar endast läsbegäranden. Skrivbegäranden följer fortfarande ACL:er. Kräv auktorisering för alla begäranden till blobdata.
Privata slutpunkter för Azure Data Lake Storage
Om du använder privata slutpunkter för att komma åt Azure Data Lake Storage (ett lagringskonto med hierarkiskt namnområde aktiverat) måste du skapa ett för både blob- och dfs-underresurserna. Åtgärder som riktar sig mot slutpunkten Data Lake Storage (dfs) kan omdirigeras till blobslutpunkten, och vissa åtgärder (till exempel att hantera ACL:er, skapa kataloger och ta bort kataloger) kräver en privat DFS-slutpunkt. Om du skapar privata slutpunkter för båda underresurserna ser du till att alla åtgärder slutförs. Mer information finns i Använda privata slutpunkter för Azure Storage.
AzCopy med Azure Data Lake Storage
När du använder AzCopy med konton som har ett hierarkiskt namnområde aktiverat stöder endast AzCopy v10 nödvändiga Data Lake Storage API:er. Använd endast den senaste versionen av AzCopy (AzCopy v10). Tidigare versioner, till exempel AzCopy v8.1, stöds inte.
Azure Storage Explorer med Azure Data Lake Storage
När du använder Azure Storage Explorer med lagringskonton som har ett hierarkiskt namnområde aktiverat använder du endast versioner 1.6.0 eller högre. Tidigare versioner stöder inte de hierarkiska namnområdes-API:er som krävs för att hantera filer och kataloger.
Lagringswebbläsare i Azure-portalen
I lagringswebbläsaren som visas i Azure Portal kan du inte komma åt en fil eller mapp genom att ange en sökväg. I stället måste du bläddra igenom mappar för att nå en fil. Om en ACL ger en användare läsbehörighet till en fil men inte läsbehörighet till alla mappar som leder fram till filen kan användaren därför inte visa filen i lagringswebbläsaren.
Program från tredje part
Program från tredje part som använder REST-API:er för att fungera fortsätter att fungera om du använder dem med Data Lake Storage. Program som anropar Blob-API:er fungerar sannolikt.
Drivrutin för Windows Azure Storage Blob (WASB)
För närvarande stöter WASB-drivrutinen, som endast har utformats för att fungera med blob-API:et, på problem i några vanliga scenarier. Mer specifikt, när det är en klient till ett lagringskonto med aktiverat hierarkiskt namnområde. Åtkomst med flera protokoll på Data Lake Storage åtgärdar inte dessa problem.
Det går inte att använda WASB-drivrutinen som en klient till ett hierarkiskt namnområdesaktiverat lagringskonto. Använd i stället drivrutinen Azure Blob File System (ABFS) i Din Hadoop-miljö. Om du försöker migrera från en lokal Hadoop-miljö med en tidigare version än Hadoop branch-3 öppnar du ett supportärende för Azure för att få hjälp med att fastställa rätt väg framåt för din organisation.
Mjuk borttagning för blobar i Azure Data Lake Storage
Om du byter namn på överordnade kataloger för mjukt borttagna filer eller kataloger i lagringskonton som har ett hierarkiskt namnområde kanske Azure portalen inte visar de mjukt borttagna objekten korrekt. I sådana fall använder du PowerShell eller Azure CLI för att lista och återställa de mjukt borttagna objekten.
Händelseprenumerationer i Azure Data Lake Storage
I lagringskonton som har ett hierarkiskt namnområde leder läsåtgärder på den sekundära slutpunkten (den skrivskyddade repliken i geo-redundanta lagringskonton) till ett fel om ditt konto har en händelseprenumeration. Lös problemet genom att ta bort händelseprenumerationer. Att använda Data Lake Storage-slutpunkten (abfss://URI) för konton där hierarkiskt namnområde inte är aktiverat genererar inte händelser, men blobslutpunkten (wasb:// URI) genererar händelser.
Tips
Läsåtkomst till den sekundära slutpunkten är endast tillgänglig när du aktiverar geo-redundant lagring med läsåtkomst (RA-GRS) eller geo-zonredundant lagring med läsåtkomst (RA-GZRS).