Bekannte Probleme mit Azure Data Lake Storage

In diesem Artikel werden bekannte Probleme und Einschränkungen von Azure Data Lake Storage für Konten beschrieben, für die das hierarchische Namespacefeature aktiviert ist. Verwenden Sie diese Informationen, um Ihre Datenworkflows zu verwalten und potenzielle Fallstricke bei verwendung verschiedener APIs und Integrationen zu vermeiden.

Feature-, Dienst- und Plattformunterstützung

Die meisten Blob-Speicherfeatures, Azure Dienstintegrationen und Open-Source-Plattformen werden in Konten unterstützt, die über einen hierarchischen Namespace verfügen. Vollständige Listen finden Sie unter:

• In Azure Data Lake Storage verfügbare Blob Storage-Features
• Azure-Dienste mit Unterstützung für Azure Data Lake Storage
• Open-Source-Plattformen, die Azure Data Lake Storage unterstützen

APIs für Blobspeicher

Data Lake Storage-APIs, NFS 3.0 und Blob-APIs können mit denselben Daten arbeiten.

In diesem Abschnitt werden Probleme und Einschränkungen bei der Verwendung von Blob-APIs, NFS 3.0 und Data Lake Storage-APIs für dieselben Daten beschrieben.

• Sie können Blob-APIs, NFS 3.0 und Data Lake Storage-APIs nicht zum Schreiben in dieselbe Instanz einer Datei verwenden. Wenn Sie mit Data Lake Storage APIs oder NFS 3.0 in eine Datei schreiben, sind die Blöcke dieser Datei für Aufrufe der BLOB-API für die Get Block List nicht sichtbar. Die einzige Ausnahme ist, wenn Sie etwas überschreiben. Sie können eine Datei oder ein BLOB überschreiben, indem Sie eine API oder NFS 3.0 mit der Option "Null-Abschneiden" verwenden (ein POSIX-Stil-Vorgang, der die Datei vor dem Schreiben auf null Bytes abschneidet).

  Sie können Blobs, die mithilfe eines Data Lake Storage-Vorgangs wie dem Vorgang Path - Create erstellt wurden, nicht mit PutBlock- oder PutBlockList-Vorgängen überschreiben. Sie können diese Blobs jedoch mithilfe eines PutBlob-Vorgangs überschreiben, vorbehaltlich der maximal zulässigen BLOB-Größe, die von der entsprechenden API-Version von PutBlob verwendet wird.

• Wenn Sie den Vorgang Auflisten von Blobs verwenden, ohne ein Trennzeichen anzugeben, enthalten die Ergebnisse sowohl Verzeichnisse als auch Blobs. Wenn Sie sich für Trennzeichen entscheiden, sollten Sie nur einen Schrägstrich (/) verwenden. Dies ist das einzige Trennzeichen, das unterstützt wird.

• Wenn Sie die Blob-API zum Löschen eines Verzeichnisses verwenden, wird das Verzeichnis nur gelöscht, wenn es leer ist. Diese Bedingung bedeutet, dass Sie die Blob-API nicht verwenden können, um Verzeichnisse rekursiv zu löschen.

Diese Blob-Rest-APIs werden nicht unterstützt:

• Put Blob (Page)
• Put Page
• Seitenbereiche abrufen
• Incremental Copy Blob
• Seite aus einer URL einfügen
• Append Blob Seal

Nicht verwaltete VM-Datenträger werden in Konten mit einem hierarchischen Namespace nicht unterstützt. Wenn Sie für ein Speicherkonto einen hierarchischen Namespace aktivieren möchten, sollten Sie nicht verwaltete VM-Datenträger in einem Speicherkonto speichern, bei dem das Feature für den hierarchischen Namespace nicht aktiviert ist.

Unterstützung für das rekursive Festlegen von Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage

Die Möglichkeit, ACL-Änderungen aus dem übergeordneten Verzeichnis rekursiv auf untergeordnete Elemente anzuwenden, ist allgemein verfügbar. In der aktuellen Version dieser Funktion können Sie ACL-Änderungen mithilfe von Azure Storage-Explorer, PowerShell, Azure CLI und den .NET, Java, Python und Node.js SDKs anwenden. Unterstützung für das Azure-Portal ist noch nicht verfügbar.

Zugriffssteuerungslisten (Access Control Lists, ACLs) und anonymer Lesezugriff

Wenn einem Container anonymer Lesezugriff gewährt wird, haben ACLs keine Auswirkungen auf diesen Container oder die Dateien in diesem Container. Diese Einschränkung betrifft nur Leseanforderungen. Schreibanforderungen berücksichtigen weiterhin die ACLs. Autorisierung für alle Anfragen an Blobdaten anfordern.

Private Endpunkte für Azure Data Lake Storage

Wenn Sie private Endpunkte verwenden, um auf Azure Data Lake Storage zuzugreifen (ein Speicherkonto mit aktiviertem hierarchischen Namespace), müssen Sie eins für die Blob- und dfs-Unterressourcen erstellen. Vorgänge, die auf den Data Lake Storage (dfs)-Endpunkt abzielen, können an den Blob-Endpunkt umgeleitet werden, und einige Vorgänge (z. B. das Verwalten von ACLs, das Erstellen von Verzeichnissen und das Löschen von Verzeichnissen) erfordern einen privaten DFS-Endpunkt. Durch das Erstellen privater Endpunkte für beide Unterressourcen wird sichergestellt, dass alle Vorgänge erfolgreich abgeschlossen werden. Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Azure Storage.

AzCopy mit Azure Data Lake Storage

Wenn Sie AzCopy mit Konten verwenden, für die ein hierarchischer Namespace aktiviert ist, unterstützt nur AzCopy v10 die erforderlichen Data Lake Storage-APIs. Verwenden Sie nur die neueste Version von AzCopy (AzCopy v10). Frühere Versionen, z. B. AzCopy v8.1, werden nicht unterstützt.

Azure Storage-Explorer mit Azure Data Lake Storage

Wenn Sie Azure Storage-Explorer mit Speicherkonten verwenden, für die ein hierarchischer Namespace aktiviert ist, verwenden Sie nur Versionen 1.6.0 oder höher. Frühere Versionen unterstützen die hierarchischen Namespace-APIs nicht, die zum Verwalten von Dateien und Verzeichnissen erforderlich sind.

Speicherbrowser im Azure-Portal

In dem im Azure-Portal angezeigten Speicherbrowser ist es nicht möglich, auf eine Datei oder einen Ordner zuzugreifen, indem Sie einen Pfad angeben. Stattdessen müssen Sie durch Ordner navigieren, um zu einer Datei zu gelangen. Wenn eine ACL einem Benutzer lesezugriff auf eine Datei gewährt, aber nicht lesezugriff auf alle Ordner, die zur Datei führen, kann dieser Benutzer die Datei nicht im Speicherbrowser anzeigen.

Drittanbieteranwendungen

Anwendungen von Drittanbietern, die REST-APIs verwenden, funktionieren weiterhin, wenn Sie sie mit Data Lake Storage verwenden. Anwendungen, die BLOB-APIs aufrufen, funktionieren wahrscheinlich.

WASB-Treiber (Windows Azure Storage Blob)

Derzeit treten beim WASB-Treiber, der nur für die Verwendung mit der Blob-API entwickelt wurde, in einigen gängigen Szenarien Probleme auf. Dies gilt insbesondere, wenn es sich um einen Client für ein Speicherkonto mit aktiviertem hierarchischem Namespace handelt. Der Multiprotokollzugriff auf Data Lake Storage entschärft diese Probleme nicht.

Die Verwendung des WASB-Treibers als Client für ein Speicherkonto mit aktiviertem hierarchischem Namespace wird nicht unterstützt. Verwenden Sie stattdessen den Azure BLOB File System (ABFS)-Treiber in Ihrer Hadoop-Umgebung. Wenn Sie versuchen, von einer lokalen Hadoop-Umgebung mit einer Version vor Hadoop Branch-3 zu migrieren, erstellen Sie ein Azure-Supportticket, um das richtige weitere Vorgehen für Ihre Organisation zu ermitteln.

Vorläufiges Löschen für Blobs in Azure Data Lake Storage

Wenn Sie in Speicherkonten mit hierarchischem Namespace übergeordnete Verzeichnisse für vorläufig gelöschte Dateien oder Verzeichnisse umbenennen, zeigt das Azure-Portal die vorläufig gelöschten Elemente möglicherweise nicht korrekt an. Verwenden Sie in solchen Fällen PowerShell oder Azure CLI, um die vorläufig gelöschten Elemente auflisten und wiederherzustellen.

Ereignisabonnements in Azure Data Lake Storage

Bei Speicherkonten mit einem hierarchischen Namespace führen Lesevorgänge auf dem sekundären Endpunkt (dem schreibgeschützten Replikat in georedundanten Speicherkonten) zu einem Fehler, wenn Ihr Speicherkonto über ein Ereignisabonnement verfügt. Entfernen Sie Ereignisabonnements, um dieses Problem zu beheben. Wenn Sie den Data Lake Storage Endpunkt (abfss://URI) für nicht hierarchische Namespace-aktivierte Konten verwenden, werden keine Ereignisse generiert, aber der BLOB-Endpunkt (wasb:// URI) generiert Ereignisse.