Freigeben über

Wichtige Überlegungen zu Azure Data Lake Storage

  • Artikel

Erfahren Sie mehr über wichtige Überlegungen zu Ihren Azure Data Lakes.

Lebenszyklusverwaltung

Azure Storage bietet unterschiedliche Zugriffsebenen, die Ihnen das Speichern von Blob-Objektdaten auf die kostengünstigste Art ermöglichen. Die verfügbaren Zugriffsebenen sind:

  • Heiß: Ist für die Speicherung von Daten optimiert, auf die häufig zugegriffen wird.
  • Kalt: Ist für die Speicherung von Daten optimiert, auf die nicht häufig zugegriffen wird. Daten werden für mindestens 30 Tage gespeichert.
  • Cold-Ebene: Eine Onlineebene, die für die Speicherung von Daten optimiert ist, auf die nicht häufig zugegriffen wird oder die nicht häufig geändert werden. Daten werden für mindestens 90 Tage gespeichert. Für die Ebene „Cold“ fallen im Vergleich zur kalten Ebene niedrigere Speicherkosten und höhere Zugriffskosten an.
  • Archiv: Ist für die Speicherung von Daten optimiert, auf die selten zugegriffen wird. Die Daten werden mindestens 180 Tage lang gespeichert, wobei die Latenzanforderungen flexibel sind und in dem Bereich von Stunden liegen kann.

Wichtig

Es gibt zwischen den verschiedenen Onlinezugriffsstufen keine Kompromisse bei Zuverlässigkeit, Sicherheit, erstklassigen Betriebsprozessen oder Leistungseffizienz, weshalb es sich bei der Wahl einer Onlineebene pro Blob um eine finanzielle Entscheidung handelt, die auf der Datengröße beim Workloadzugriff, auf betrieblichen Interaktionen und auf der Zeit bis zum Löschen des Blobs beruht. Wählen Sie die richtige Ebene pro Blob basierend auf einer Berechnung der vorstehend genannten Faktoren aus. Weitere Informationen finden Sie unter Planen und Verwalten von Kosten für Azure Blob Storage.

Berücksichtigen Sie die folgenden Informationen bei der Verwendung von Zugriffsebenen:

  • Nur die heißen und kalten Zugriffsebenen können auf Kontoebene festgelegt werden. Die Archivzugriffsebene ist auf der Kontoebene nicht verfügbar.

  • Die heißen, kalten und Archiv-Zugriffsebenen können alle während des Uploads oder danach auf Blobebene festgelegt werden.

  • Daten der kalten Ebene oder der Ebene „Cold“ weisen eine etwas geringere Verfügbarkeit auf, bieten aber Dauerhaftigkeit, Abrufwartezeit und Durchsatz auf dem gleichen hohen Niveau wie bei Daten der heißen Ebene. Daher kann bei Daten der kalten Ebene oder der Ebene „Cold“ eine Kombination aus etwas geringerer Verfügbarkeit und höheren Zugriffskosten im Vergleich zur heißen Ebene in Kauf genommen werden, da im Gegenzug die Gesamtspeicherkosten geringer ausfallen.

  • Archivspeicher speichern Daten offline und bieten die niedrigsten Speicherkosten. Sie haben jedoch auch die höchsten Kosten für die Datenneuaktivierung und den Zugriff.

Weitere Informationen finden Sie unter Zugriffsebenen für Blobdaten.

Achtung

Für Analysen auf Cloudebene empfehlen wir, die Lebenszyklusverwaltung mithilfe eines benutzerdefinierten Microservice zu implementieren und die Auswirkungen des Verschiebens von auffindbaren Daten des Benutzers in den kalten Speicher sorgfältig zu berücksichtigen.

Sie sollten nur Abschnitte Ihres Data Lake auf eine kalte Ebene für wohlverstandene Workloads verschieben.

Die Konnektivität der Data Lakes

Jeder Ihrer Data Lakes sollte private Endpunkte verwenden, die in das virtuelle Netzwerk Ihrer Datenzielzone eingefügt werden. Um den Zugriff über Zielzonen hinweg zu ermöglichen, verbinden Sie Ihre Datenzielzonen über Peering virtueller Netzwerke. Diese Verbindung bietet sowohl aus Kostensicht als auch aus Sicht der Zugriffssteuerung eine optimale Lösung.

Weitere Informationen finden Sie unter Private Endpunkte und Datenverwaltungszielzone zur Datenzielzone.

Wichtig

Auf Daten aus einer Datenzielzone kann von einer anderen Datenzielzone über Peering virtueller Netzwerke zwischen den Zonen zugegriffen werden. Das erfolgt mithilfe der privaten Endpunkte, die jedem Data Lake-Konto zugeordnet sind. Es wird empfohlen, den öffentlichen Zugriff auf Ihre Lakes zu deaktivieren und private Endpunkte zu verwenden. Ihr Plattformbetriebsteam sollte die Netzwerkkonnektivität in Ihren Datenzielzonen steuern.

Vorläufiges Löschen für Container

Vorläufiges Löschen für Container schützt Ihre Daten vor versehentlicher oder böswilliger Löschung. Wenn vorläufiges Löschen für Container für Ihr Speicherkonto aktivieren, werden gelöschte Container und deren Inhalte in Azure Storage für eine längere von Ihnen gewählte Zeit aufbewahrt. Während dieses Datenaufbewahrungszeitraums können Sie zuvor gelöschte Container wiederherstellen. Beim Wiederherstellen eines Containers werden auch alle Blobs wiederhergestellt, die sich in diesem Container befanden, als er gelöscht wurde.

Aktivieren Sie die folgenden Datenschutzfeatures, um End-to-End-Blob-Datenschutz zu erzielen:

Warnung

Das Löschen eines Speicherkontos kann nicht rückgängig gemacht werden. Vorläufiges Löschen für Container schützt nicht vor dem Löschen eines Speicherkontos, sondern nur vor dem Löschen von Containern in einem Konto. Um ein Speicherkonto vor dem Löschen zu schützen, konfigurieren Sie eine Sperre für die Speicherkontoressource. Weitere Informationen zum Sperren von Azure Resource Manager-Ressourcen finden Sie unter Sperren von Ressourcen, um unerwartete Änderungen zu verhindern.

Überwachung

In einer Datenzielzone sollte die gesamte Überwachung zur Analyse an das Management-Abonnement für die Azure-Zielzone gesendet werden.

Informationen zu den Überwachungsdaten, die Azure Storage verwendet, finden Sie unter Überwachen von Azure-Ressourcen mit Azure Monitor. Weitere Informationen zu den Protokollen und Metriken, die Azure Storage erstellt, finden Sie unter Überwachen von Azure Blob Storage.

Protokolleinträge werden nur erstellt, wenn Anforderungen für den Dienstendpunkt gestellt wurden. Die protokollierten Arten von authentifizierten Anforderungen sind:

  • Erfolgreiche Anforderungen
  • Fehlerhafte Anforderungen, einschließlich Timeout-, Drosselungs-, Netzwerk- und Autorisierungsfehler sowie anderer Fehler
  • Anforderungen, die eine SAS (Shared Access Signature) oder OAuth verwenden, einschließlich fehlerhafter und erfolgreicher Anforderungen
  • Anforderungen an Analysedaten wie klassische Protokolldaten im $logs-Container und klassische Metrikdaten in den $metric-Tabellen

Anforderungen, die durch den Speicherdienst erfolgen, wie z. B. Protokollerstellungs- oder -löschvorgänge, werden nicht protokolliert. Die protokollierten Arten von anonymen Anforderungen sind:

  • Erfolgreiche Anforderungen
  • Serverfehler
  • Timeoutfehler für Client und Server
  • Fehlerhafte HTTP GET-Anforderungen mit Fehlercode 304 (Not Modified)

Alle anderen fehlgeschlagenen, anonymen Anforderungen werden nicht protokolliert.

Wichtig

Legen Sie Ihre Standardüberwachungsrichtlinie fest, um den Speicher zu überwachen und Protokolle an Ihr Verwaltungsabonnement auf Unternehmensebene zu senden.

Die folgenden Verwendungen sind die empfohlenen Sicherheitsmuster für jede der Data Lake-Zonen:

  • Die tatsächliche Nutzung ermöglicht den Zugriff auf Daten nur unter Verwendung von Sicherheitsprinzipalnamen (SPNs) – vorzugsweise mithilfe von verwalteten Identitäten.
  • Die angereicherte Nutzung ermöglicht den Zugriff auf Daten nur unter Verwendung von Sicherheitsprinzipalnamen (SPNs) – vorzugsweise mithilfe von verwalteten Identitäten.
  • Die kuratierte Nutzung ermöglicht sowohl Zugriff auf Sicherheitsprinzipalnamen (SPNs) als auch Zugriff auf Benutzerprinzipalnamen (User Principal Names, UPNs).

Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage.

Nächste Schritte