Bewährte Methoden für die Verwendung von Azure Data Lake Storage

Dieser Artikel enthält Leitfäden mit bewährten Methoden, mit denen Sie die Leistung optimieren, Kosten senken und Ihr Azure Storage-Konto mit aktiviertem Data Lake Storage schützen können.

Dokumentation finden

Azure Data Lake Storage ist kein dedizierter Dienst- oder Kontotyp. Es handelt sich vielmehr um eine Reihe von Funktionen zur Unterstützung von Analyseworkloads mit hohem Durchsatz. Die Dokumentation zu Data Lake Storage enthält bewährte Methoden und einen Leitfaden für die Verwendung dieser Funktionen. Informationen zu allen anderen Aspekten der Kontoverwaltung, z. B. Einrichten der Netzwerksicherheit, Planen von Hochverfügbarkeit und Notfallwiederherstellung, finden Sie in der Dokumentation zu Blob Storage.

Bewerten Sie die Funktionsunterstützung und bekannte Probleme

Konfigurieren Sie Ihr Konto für die Verwendung von Blob Storage-Funktionen nach dem folgenden Muster.

1. Im Artikel Unterstützung von Blob Storage-Funktionen in Azure Storage-Konten erfahren Sie, ob eine Funktion in Ihrem Konto vollständig unterstützt wird. Einige Funktionen werden in Konten mit aktiviertem Data Lake Storage noch nicht oder nur teilweise unterstützt. Die Funktionsunterstützung wird ständig erweitert, daher sollten Sie diesen Artikel regelmäßig auf Updates überprüfen.

2. Im Artikel Bekannte Probleme mit Azure Data Lake Storage können Sie feststellen, ob Einschränkungen oder besondere Hinweise für die Funktion vorliegen, die Sie verwenden möchten.

3. Durchsuchen Sie die Artikel zu Funktionen nach Hinweisen, die sich speziell auf Konten mit aktiviertem Data Lake Storage beziehen.

Grundlegendes zu den in der Dokumentation verwendeten Begriffen

In den verschiedenen Inhaltssätzen werden Sie einige kleinere begriffliche Unterschiede feststellen. In der Blob-Speicherdokumentation enthaltene Inhalte werden z. B. anstelle der Datei der Begriff BLOB verwendet. Technisch gesehen werden die Dateien, die Sie in Ihr Speicherkonto hochladen, in Ihrem Konto als Blobs gespeichert. Daher ist der Begriff richtig. Der Begriff Blob kann jedoch zu Verwirrung führen, wenn Sie an den Begriff Datei gewöhnt sind. Außerdem wird der Begriff Container verwendet, um ein Dateisystem zu bezeichnen. Diese beiden Begriffe sind als Synonyme zu verstehen.

Premium entdecken

Wenn Ihre Workloads eine niedrige konsistente Latenz erfordern oder eine hohe Anzahl von Eingabeausgabevorgängen pro Sekunde (IOPS) erfordern, sollten Sie ein Premium-Block-Blob-Speicherkonto verwenden. Dieser Kontotyp stellt Daten über leistungsstarke Hardware zur Verfügung. Daten werden auf SSD-Datenträgern (Solid State Drives) gespeichert, die für niedrige Latenz optimiert sind. Der Durchsatz ist bei SSDs im Vergleich zu herkömmlichen Festplatten höher. Die Speicherkosten für Premiumleistung sind höher, aber die Transaktionskosten sind niedriger. Wenn Ihre Anwendungen und Workloads also eine große Anzahl von Transaktionen ausführen, kann sich ein Blockblob-Konto mit Premiumleistung lohnen.

Wenn Ihr Speicherkonto für Analysen verwendet werden soll, wird dringend empfohlen, Azure Data Lake Storage zusammen mit einem Premium-Konto für Blockblobspeicher zu verwenden. Diese Kombination aus Premium-Konto für Blockblobspeicher und Data Lake Storage-fähigem Konto wird als Premium-Ebene für Azure Data Lake Storage bezeichnet.

Optimierung für die Datenerfassung

Beim Aufnehmen von Daten aus einem Quellsystem kann die Quellhardware, die Quellnetzwerkhardware oder die Netzwerkkonnektivität mit Ihrem Speicherkonto Engpässe erzeugen.

Quellhardware

Unabhängig davon, ob Sie lokale Computer oder virtuelle Computer (VMs) in Azure verwenden, wählen Sie sorgfältig die entsprechende Hardware aus. Bei Datenträgerhardware sollten Sie die Verwendung von Ssd-Laufwerken (Solid State Drives) in Betracht ziehen und Datenträgerhardware auswählen, die schnellere Spindeln aufweist. Verwenden Sie für Netzwerkhardware die schnellstmöglichen Netzwerkschnittstellenkarten (NIC). Verwenden Sie in Azure Azure D14-VMs, die über die entsprechende leistungsfähige Datenträger- und Netzwerkhardware verfügen.

Netzwerkkonnektivität mit dem Speicherkonto

Die Netzwerkkonnektivität zwischen Den Quelldaten und Ihrem Speicherkonto kann manchmal zu einem Engpass führen. Wenn Ihre Quelldaten lokal sind, sollten Sie einen dedizierten Link mit Azure ExpressRoute verwenden. Sind Ihre Quelldaten in Azure gespeichert, erzielen Sie eine optimale Leistung, wenn sich die Daten in derselben Azure-Region befinden wie das Data Lake Storage-Konto.

Konfigurieren von Datenerfassungstools für maximale Parallelisierung

Um die beste Leistung zu erzielen, verwenden Sie den gesamten verfügbaren Durchsatz, indem Sie so viele Lese- und Schreibvorgänge wie möglich parallel ausführen.

In der folgenden Tabelle finden Sie eine Zusammenfassung der wichtigsten Einstellungen für einige gängige Erfassungstools:

Eine umfassendere Liste der Erfassungstools finden Sie unter Auswählen von Migrationstools.

Sie können Ihr Konto skalieren, um den erforderlichen Durchsatz für sämtliche Analyseszenarios bereitzustellen. Die Standardkonfiguration eines Kontos mit Data Lake Storage-Aktivierung bietet genügend Durchsatz, um die Anforderungen eines breiten Spektrums an Anwendungsfällen zu erfüllen. Wenn der Standardgrenzwert erreicht ist, wenden Sie sich an Azure Support, um Ihr Konto so zu konfigurieren, dass der Durchsatz erhöht wird.

Strukturieren von Datasets

Erwägen Sie die Vorplanung der Struktur Ihrer Daten. Dateiformat, Dateigröße und Verzeichnisstruktur können sich auf Leistung und Kosten auswirken.

Dateiformate

Sie können Daten in verschiedenen Formaten aufnehmen. Daten können in menschenlesbaren Formaten wie JSON, CSV oder XML oder in komprimierten Binärformaten wie .tar.gz vorliegen. Daten können in verschiedenen Größen vorhanden sein. Daten können aus umfangreichen Dateien (einige Terabyte) bestehen, z. B. Daten aus einem Export einer SQL-Tabelle aus lokalen Systemen. Daten können auch in Form einer großen Anzahl kleiner Dateien (wenige Kilobyte) vorliegen, z. B. Daten aus Echtzeitereignissen aus einer IoT-Lösung (Internet der Dinge). Durch Auswahl eines entsprechenden Dateiformats und einer geeigneten Dateigröße können Sie die Effizienz und die Kosten optimieren.

Hadoop unterstützt eine Reihe von Dateiformaten, die für die Speicherung und Verarbeitung strukturierter Daten optimiert sind. Zu den gängigen Formaten gehören Avro, Parquet und das Optimized Row Columnar (ORC)-Format. Bei all diesen Formaten handelt es sich um maschinenlesbare Binärdateiformate. Zur Verringerung der Dateigröße sind sie komprimiert. Sie verfügen über ein in jede Datei eingebettetes Schema, sodass sie selbstbeschreibend sind. Die Formate unterscheiden sich in der Speicherung der Daten. In Avro werden Daten in einem zeilenbasierten Format gespeichert, in Parquet und ORC dagegen in einem spaltenbasierten Format.

Verwenden Sie das Avro-Dateiformat, wenn Ihre E/A-Muster schreiblastiger sind oder wenn die Abfragemuster auf das Abrufen mehrerer Zeilen vollständiger Datensätze ausgerichtet sind. Beispielsweise funktioniert das Avro-Format gut mit einem Nachrichtenbus wie Event Hubs oder Kafka, die mehrere Ereignisse oder Nachrichten nacheinander schreiben.

Verwenden Sie die Dateiformate Parquet und ORC, wenn die E/A-Muster eher leselastig sind oder wenn sich die Abfragen auf eine Teilmenge der Spalten in den Datensätzen konzentrieren. Lesetransaktionen können so optimiert werden, dass bestimmte Spalten abgerufen werden, ohne dass der gesamte Datensatz gelesen wird.

Apache Parquet ist ein Open-Source-Dateiformat, das für leseintensive Analyse-Pipelines optimiert ist. Die spaltenbasierte Speicherstruktur von Parquet ermöglicht das Überspringen nicht relevanter Daten. Ihre Abfragen sind wesentlich effizienter, da der Umfang der Daten eingegrenzt werden kann, die vom Speicher an die Analytics-Engine gesendet werden. Da zudem ähnliche Datentypen (für eine Spalte) zusammen gespeichert werden, unterstützt Parquet effiziente Schemas zur Datenkomprimierung und -codierung. Auf diese Weise werden die Kosten für die Datenspeicherung gesenkt. Dienste wie Azure Synapse Analytics, Azure Databricks und Azure Data Factory verfügen über systemeigene Funktionen, die die Vorteile von Parkettdateiformaten nutzen.

Dateigröße

Größere Dateien ermöglichen bessere Leistung und geringere Kosten.

In der Regel wird bei Analyse-Engines wie HDInsight für jede Datei ein Verwaltungsaufwand verursacht, der z. B. das Auflisten, das Überprüfen des Zugriffs sowie verschiedene Metadatenvorgänge umfasst. Wenn Sie Ihre Daten so viele kleine Dateien speichern, kann sich diese Auswahl negativ auf die Leistung auswirken. Im Allgemeinen sollten Sie Ihre Daten in größeren Dateien organisieren, um eine bessere Leistung zu erzielen (256 MB bis 100 GB). Dateien mit einer Größe von mehr als 100 GB können von einigen Engines und Anwendungen unter Umständen nicht effizient verarbeitet werden.

Durch Erhöhung der Dateigröße lassen sich auch die Transaktionskosten reduzieren. Lese- und Schreibvorgänge werden in 4-Megabyte-Schritten abgerechnet, sodass Ihnen jeder Vorgang berechnet wird, unabhängig davon, ob die Datei 4 Megabyte oder nur wenige Kilobyte umfasst. Preisinformationen finden Sie unter Azure Data Lake Storage – Preise.

Manchmal haben Datenpipelines nur begrenzte Kontrolle über Rohdaten, die aus vielen kleinen Dateien bestehen. Im Allgemeinen sollte Ihr System eine Art Von Prozess haben, um kleine Dateien in größere Dateien zu aggregieren, um sie für die Verwendung durch downstream-Anwendungen zu verwenden. Wenn Sie Daten in Echtzeit verarbeiten, können Sie ein Echtzeit-Streamingmodul (z. B. Azure Stream Analytics oder Spark Streaming) zusammen mit einem Nachrichtenbroker (z. B. Event Hubs oder Apache Kafka) verwenden, um Ihre Daten als größere Dateien zu speichern. Wenn Sie kleine Dateien in größere aggregieren, sollten Sie zum Speichern ein leseoptimiertes Format wie Apache Parquet für die Downstreamverarbeitung auswählen.

Verzeichnisstruktur

Jede Workload hat unterschiedliche Anforderungen für die Nutzung von Daten. Berücksichtigen Sie beim Arbeiten mit Internet of Things (IoT), Batchszenarien oder beim Optimieren von Zeitreihendaten diese gängigen Layouts.

IoT-Struktur

In IoT-Workloads können Sie eine große Datenmenge aufnehmen, die sich über zahlreiche Produkte, Geräte, Organisationen und Kunden erstreckt. Planen Sie das Verzeichnislayout für Organisation, Sicherheit und effiziente Verarbeitung der Daten für Downstream-Verbraucher vor. Das folgende Layout kann hierbei als allgemeine Vorlage dienen:

• {Region}/{SubjectMatter(s)}/jjjj/{mm}/{tt}/{hh}/

Die Telemetriedaten für die Landung eines Flugzeugtriebwerks aus dem Vereinigten Königreich könnten beispielsweise wie folgt strukturiert sein:

• UK/Planes/BA1293/Engine1/2017/08/11/12/

In diesem Beispiel können Sie Zugriffssteuerungslisten verwenden, um Regionen und Themen für bestimmte Benutzer und Gruppen einfacher zu schützen, indem Sie das Datum an das Ende der Verzeichnisstruktur setzen. Wenn Sie die Datumsstruktur an den Anfang stellen, wäre es deutlich schwieriger, diese Regionen und Themenbereiche abzusichern. Wenn Sie beispielsweise nur Zugriff auf UK-Daten oder bestimmte Flugzeuge gewähren möchten, müssten Sie für zahlreiche Verzeichnisse unter jedem Stundenverzeichnis jeweils eine separate Berechtigung festlegen. Diese Struktur würde auch die Anzahl der Verzeichnisse im Laufe der Zeit exponentiell erhöhen.

Struktur von Batchaufträgen

Ein häufig verwendeter Ansatz bei der Batchverarbeitung besteht darin, Daten in einem „in“-Verzeichnis abzulegen. Nachdem die Daten verarbeitet wurden, werden die neuen Daten dann in einem Verzeichnis des Typs „Ausgang“ (Out) angeordnet, damit sie von nachgelagerten Prozessen genutzt werden können. Diese Verzeichnisstruktur wird manchmal bei Aufträgen verwendet, bei denen einzelne Dateien verarbeitet werden müssen und ggf. kein Massively Parallel Processing für große Datasets erforderlich ist. Wie bei der oben empfohlenen IoT-Struktur auch, verfügt eine gute Verzeichnisstruktur über übergeordnete Verzeichnisse für Dinge wie Region und Themen (z. B. Organisation, Produkt oder Hersteller). Berücksichtigen Sie in der Struktur das Datum und die Uhrzeit, um eine bessere Organisation, gefilterte Suchen, Sicherheit und Automatisierung der Verarbeitung zu ermöglichen. Der Granularitätsgrad für die Datumsstruktur wird durch das Intervall bestimmt, nach dem die Daten hochgeladen oder verarbeitet werden, z.B. stündlich, täglich oder auch monatlich.

Es kann vorkommen, dass die Dateiverarbeitung nicht erfolgreich ist, weil Daten beschädigt sind oder ein unerwartetes Format haben. In diesen Fällen kann für die Verzeichnisstruktur die Nutzung des Ordners /bad vorteilhaft sein, in den die Dateien zur weiteren Untersuchung verschoben werden können. Der Batch-Job kann auch die Meldung oder Benachrichtigung dieser fehlerhaften Dateien zur manuellen Bearbeitung übernehmen. Erwägen Sie die Verwendung der folgenden Vorlagenstruktur:

• {Region}/{SubjectMatter(s)}/In/jjjj/{mm}/{tt}/{hh}/
• {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

Es kann beispielsweise sein, dass ein Marketingunternehmen tägliche Datenextrakte aus Kundenupdates von seinen Kunden in Nordamerika erhält. Vor und nach der Verarbeitung kann dies ggf. wie im folgenden Codeausschnitt aussehen:

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

Im allgemeinen Fall, dass Batchdaten direkt in Datenbanken wie Hive oder herkömmliche SQL-Datenbanken verarbeitet werden, ist kein In - oder Ausgabeverzeichnis erforderlich, da die Ausgabe bereits in einen separaten Ordner für die Hive-Tabelle oder externe Datenbank wechselt. Beispielsweise werden tägliche Datenextrakte von Kunden in den jeweiligen Verzeichnissen abgelegt. Anschließend löst ein Dienst wie Azure Data Factory, Apache Oozie oder Apache Airflow einen täglichen Hive- oder Spark-Auftrag aus, um die Daten in eine Hive-Tabelle zu verarbeiten und zu schreiben.

Struktur von Zeitreihendaten

Bei Hive-Workloads können Sie durch Bereinigen der Partition von Zeitreihendaten eine Leistungsverbesserung erreichen, da einige Abfragen nur eine Teilmenge der Daten lesen.

Diese Pipelines, die Zeitreihendaten aufnehmen, platzieren ihre Dateien häufig mit einer strukturierten Benennung für Dateien und Ordner. Nachfolgend finden Sie ein gängiges Beispiel für Daten, die nach Datum strukturiert sind:

/DataSet/JJJJ/MM/TT/datafile_JJJJ_MM_TT.tsv

Beachten Sie, dass die Datums-/Uhrzeitinformationen sowohl in Ordnern als auch im Dateinamen erscheinen.

Im Folgenden wird ein allgemeines Muster für Datums- und Uhrzeitangaben vorgestellt:

/DataSet/JJJJ/MM/TT/HH/mm/datafile_JJJ_MM_TT_HH_mm.tsv

Auch hier sollte die Wahl, die Sie bei der Ordner- und Dateiorganisation treffen, für größere Dateien und eine angemessene Anzahl von Dateien in den einzelnen Ordnern optimiert sein.

Einrichten der Sicherheit

Lesen Sie zunächst die Empfehlungen im Artikel Sicherheitsempfehlungen für Blob Storage. Sie finden bewährte Methoden dazu, wie Sie Ihre Daten vor versehentlicher oder absichtlicher Löschung schützen, Daten hinter einer Firewall absichern und Microsoft Entra ID als Grundlage der Identitätsverwaltung verwenden.

Lesen Sie dann den Artikel Zugriffssteuerungsmodell in Azure Data Lake Storage, um spezifische Leitfäden für Konten mit aktiviertem Data Lake Storage zu erhalten. In diesem Artikel erfahren Sie, wie Sie Rollen der rollenbasierten Azure-Zugriffssteuerung (Azure RBAC) zusammen mit Zugriffssteuerungslisten (ACLs) verwenden, um Sicherheitsberechtigungen für Verzeichnisse und Dateien in Ihrem hierarchischen Dateisystem zu erzwingen.

Erfassen, Verarbeiten und Analysieren

Sie können Daten aus vielen verschiedenen Quellen und auf unterschiedliche Weise in ein Data Lake Storage aktiviertes Konto aufnehmen.

Sie können zum Beispiel große Datensätze von HDInsight- und Hadoop-Clustern oder kleinere Sätze von Ad-hoc-Daten für Prototyping-Anwendungen erfassen. Sie können gestreamte Daten aufnehmen, die verschiedene Quellen generieren, z. B. Anwendungen, Geräte und Sensoren. Verwenden Sie für diese Art von Daten Tools zum Erfassen und Verarbeiten der Daten auf Ereignisbasis in Echtzeit, und schreiben Sie dann die Ereignisse in Batches in Ihr Konto. Sie können auch Webserverprotokolle erfassen, die Informationen wie den Verlauf von Seitenanforderungen enthalten. Für Protokolldaten sollten Sie benutzerdefinierte Skripts oder Anwendungen schreiben, um sie hochzuladen, sodass Sie die Flexibilität haben, Ihre Datenuploadkomponente als Teil Ihrer größeren Big Data-Anwendung einzuschließen.

Sobald die Daten in Ihrem Konto verfügbar sind, können Sie mit diesen Daten Analysen durchführen, Visualisierungen erstellen und sogar Daten auf Ihren lokalen Rechner oder auf andere Repositories wie eine Azure SQL-Datenbank oder SQL Server-Instanz herunterladen.

In der folgenden Tabelle werden Tools empfohlen, die Sie zum Erfassen, Analysieren, Visualisieren und Herunterladen von Daten verwenden können. Verwenden Sie die Links in dieser Tabelle, um Anleitungen zur Konfiguration und Verwendung der einzelnen Tools zu erhalten.

Überwachen von Telemetriedaten

Die Überwachung der Nutzung und Leistung Ihres Diensts ist ein wichtiger Bestandteil der Operationalisierung Ihres Diensts. Beispiele für Telemetrie sind häufige Vorgänge, Vorgänge mit hoher Latenz oder Vorgänge, die eine dienstseitige Drosselung verursachen.

Sie können über Azure Storage Protokolle in Azure Monitor auf alle Telemetriedaten für Ihr Speicherkonto zugreifen. Mit dieser Funktion wird das Speicherkonto in Log Analytics und Event Hubs integriert. Gleichzeitig können Sie Protokolle in einem anderen Speicherkonto archivieren. Eine vollständige Liste der Metriken und Ressourcenprotokolle und des zugehörigen Schemas finden Sie unter Azure Storage Überwachungsdatenverweis.

Wo Sie die Protokolle speichern, hängt davon ab, wie Sie darauf zugreifen möchten. Wenn Sie beispielsweise in nahezu Echtzeit auf Ihre Protokolle zugreifen und Ereignisse in Protokollen mit anderen Metriken aus Azure Monitor korrelieren können, speichern Sie Ihre Protokolle in einem Log Analytics Arbeitsbereich. Fragen Sie dann die Protokolle mithilfe von KQL ab und erstellen Sie Abfragen, die die Tabelle StorageBlobLogs in Ihrem Arbeitsbereich enumerieren.

Wenn Sie Ihre Protokolle sowohl für nahezu Echtzeitabfragen als auch für die langfristige Aufbewahrung speichern möchten, konfigurieren Sie Ihre Diagnoseeinstellungen so, dass Protokolle sowohl an einen Log Analytics Arbeitsbereich als auch an ein Speicherkonto gesendet werden.

Wenn Sie über ein anderes Abfragemodul wie Splunk auf Ihre Protokolle zugreifen möchten, konfigurieren Sie Ihre Diagnoseeinstellungen, um Protokolle an einen Event Hub zu senden und Protokolle vom Event Hub an Ihr ausgewähltes Ziel aufzunehmen.

Sie können Azure Storage Protokolle im Azure Monitor über das Azure Portal, PowerShell, die Azure CLI und Azure Resource Manager Vorlagen aktivieren. Verwenden Sie für umfangreiche Bereitstellungen Azure Policy mit vollständiger Unterstützung für Wartungsaufgaben. Weitere Informationen finden Sie unter ciphertxt/AzureStoragePolicy.

Siehe auch

• Geschäftsleitungsstrategie zur Vereinheitlichung Ihrer Daten
• Zugriffssteuerungsmodell in Azure Data Lake Storage
• Per Anhalter durch den Data Lake
• Übersicht über Azure Data Lake Storage