Data Lake-Zonen und Container
Es ist wichtig, Ihre Datenstruktur zu planen, bevor Sie sie in einem Data Lake platzieren. Wenn Sie über einen Plan verfügen, können Sie Sicherheit, Partitionierung und Verarbeitung effektiv nutzen.
Eine Übersicht über Data Lakes finden Sie unter Übersicht über Azure Data Lake Storage für Analysen auf Cloudebene.
Übersicht
Ihre drei Data Lake-Konten sollten den typischen Data Lake-Ebenen entsprechen:
| Lake-Nummer | Ebenen | Containeranzahl | Containername |
|---|---|---|---|
| 1 | Raw | 1 | Angebotsseite (Landing-Page) |
| 1 | Raw | 2 | Konformität |
| 2 | Angereichert | 1 | Standardisiert |
| 2 | Kuratiert | 2 | Datenprodukte |
| 3 | Entwicklung | 1 | Sandbox für Analyse |
| 3 | Entwicklung | # | Nummer des primären Synapse-Speichers |
Die obige Tabelle zeigt jeweils die Standardanzahl von Containern, die wir für die Datenzielzone empfehlen. Diese Empfehlung gilt nicht, wenn für die Daten in einem Container unterschiedliche Richtlinien für vorläufiges Löschen erforderlich sind. Von diesen Anforderungen hängt ab, ob weitere Container benötigt werden.
Hinweis
In jeder Datenzielzone werden drei Data Lakes veranschaulicht. Der Data Lake erstreckt sich über drei Data Lake-Konten sowie über mehrere Container und Ordner, stellt aber für Ihre Datenzielzone einen einzigen logischen Data Lake dar.
Je nach Ihren Anforderungen können Sie die rohen, angereicherten und kuratierten Ebenen in einem Speicherkonto konsolidieren. Halten Sie ein anderes Speicherkonto mit dem Namen „Entwicklung“ für Datenconsumer vor, um andere nützliche Datenprodukte bereitzustellen.
Weitere Informationen zum Trennen von Data Lake-Konten finden Sie unter Speicherkonten in einem logischen Data Lake.
Aktivieren Sie für Azure Storage das Feature für hierarchische Namespaces, um eine effiziente Dateiverwaltung zu ermöglichen. Das Feature für hierarchische Namespaces organisiert Objekte und Dateien innerhalb eines Kontos in einer Hierarchie von Verzeichnissen und geschachtelten Unterverzeichnissen. Diese Hierarchie ist auf die gleiche Weise strukturiert wie das Dateisystem auf Ihrem Computer.
Wenn Ihr datenagnostisches Erfassungsmodul oder Ihre Onboardinganwendung ein neues System of Record registriert, werden erforderliche Ordner in Containern auf den Ebenen für rohe, angereicherte und standardisierte Daten erstellt. Wenn die Daten durch eine quellenorientierte Datenanwendung erfasst werden, muss das für die Datenzielzone zuständige Team die Ordner und Sicherheitsgruppen für Ihr Datenanwendungsteam erstellen. Platzieren Sie einen Dienstprinzipalnamen oder eine verwaltete Identität in der korrekten Gruppe, und weisen Sie eine Berechtigungsstufe zu. Dokumentieren Sie diesen Prozess für das Team, das für die Datenzielzone zuständig ist, sowie für das Datenanwendungsteam.
Weitere Informationen zu Teams finden Sie unter Grundlegendes zu den Teams für Analysen auf Cloudebene in Azure.
Jedes Datenprodukt muss im Datenproduktcontainer, der sich im Besitz Ihres Datenproduktteams befindet, über zwei Ordner verfügen.
Auf der angereicherten Ebene eines standardisierten Containers gibt es zwei Ordner pro Quellsystem (aufgeteilt nach Klassifizierung). Mit dieser Struktur kann Ihr Team Daten mit unterschiedlichen Sicherheits- und Datenklassifizierungen separat speichern und ihnen unterschiedliche Sicherheitszugriffsarten zuweisen.
Ihr standardisierter Container benötigt einen allgemeinen Ordner für Daten mit geringem bis mittlerem Vertraulichkeitsgrad sowie einen Ordner für sensible (personenbezogene) Daten. Der Zugriff auf diese Ordner kann mithilfe von Zugriffssteuerungslisten (Access Control Lists, ACLs) gesteuert werden. Sie können ein Dataset erstellen, aus dem alle personenbezogenen Daten entfernt wurden, und es in Ihrem allgemeinen Ordner speichern. Im Ordner für sensible (personenbezogene) Daten kann ein weiteres Dataset mit allen personenbezogenen Daten enthalten sein.
Der Zugriff auf die Daten wird durch eine Kombination aus Zugriffssteuerungslisten (ACLs) und Microsoft Entra-Gruppen eingeschränkt. Diese Listen und Gruppen steuern, worauf andere Gruppen zugreifen können und worauf nicht. Datenbesitzer und Datenanwendungsteams können den Zugriff auf ihre Datasets genehmigen oder ablehnen.
Weitere Informationen finden Sie unter Bereitstellen von Sicherheit für Analysen auf Cloudebene in Azure sowie unter Eingeschränkte Daten.
Warnung
Bei einigen Softwareprodukten wird das Einbinden des Stamms eines Data Lake-Containers nicht unterstützt. Aufgrund dieser Einschränkung muss jeder Data Lake-Container auf den Ebenen für Rohdaten, kuratierte Daten, angereicherte Daten und Entwicklungsdaten über einen einzelnen Ordner verfügen, der sich in mehrere Ordner verzweigt. Richten Sie Ihre Ordnerberechtigungen mit Bedacht ein. Wenn Sie vom Stamm aus einen neuen Ordner erstellen, bestimmt die standardmäßige Zugriffssteuerungsliste des übergeordneten Verzeichnisses die Standard-ACL und die ACL eines untergeordneten Verzeichnisses. Für die ACL einer untergeordneten Datei gibt es keine Standard-ACL.
Weitere Informationen finden Sie unter Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage Gen2.
Rohdatenebene (Data Lake 1)
Die Rohdatenebene entspricht einem Auffangbecken, in dem Daten in ihrem natürlichen und ursprünglichen Zustand gespeichert werden. Sie sind ungefiltert und nicht bereinigt. Sie können die Daten im ursprünglichen Format speichern, z. B. JSON oder CSV. Es kann jedoch auch kostengünstig sein, den Dateiinhalt als Spalte in einem komprimierten Dateiformat wie Avro, Parquet oder Databricks Delta Lake zu speichern.
Diese Rohdaten sind unveränderlich. Rohdaten sollten immer gesperrt sein, und Consumern (ob automatisiert oder menschlich) dürfen nur reine Leseberechtigungen erteilt werden. Diese Ebene kann mit jeweils einem Ordner pro Quellsystem strukturiert werden. Erteilen Sie Erfassungsprozessen jeweils nur Schreibzugriff auf den zugeordneten Ordner.
Wenn Sie Daten aus Quellsystemen in die Rohdatenzone laden, stehen Ihnen folgende Optionen zur Verfügung:
- Vollständige Ladevorgänge, um ein vollständiges Dataset zu extrahieren.
- Deltaladevorgänge, um nur geänderte Daten zu laden.
Geben Sie das ausgewählte Lademuster in Ihrer Ordnerstruktur an, um die Nutzung für Ihre Datenconsumer zu vereinfachen.
Rohdaten aus Quellsystemen für die einzelnen quellenorientierten Datenanwendungen oder für die Quelle der automatisierten Erfassungs-Engine werden im Ordner für vollständige Ladevorgänge oder im Deltaordner abgelegt. Jeder Erfassungsprozess darf nur über Schreibzugriff auf den zugeordneten Ordner verfügen.
Zwischen vollständigen Ladevorgängen und Deltaladevorgängen bestehen folgende Unterschiede:
Vollständiger Ladevorgang: Vollständige Daten aus der Quelle können unter folgenden Umständen integriert werden:
- Die Quelle umfasst geringe Datenmengen.
- Das Quellsystem verfügt über kein Zeitstempelfeld, das Aufschluss darüber gibt, ob Daten hinzugefügt, aktualisiert oder gelöscht wurden.
- Vom Quellsystem werden jedes Mal alle Daten überschrieben.
Deltaladevorgang: Inkrementelle Daten aus der Quelle können unter folgenden Umständen integriert werden:
- Die Quelle umfasst umfangreiche Datenmengen.
- Das Quellsystem verfügt über ein Zeitstempelfeld, das Aufschluss darüber gibt, ob Daten hinzugefügt, aktualisiert oder gelöscht wurden.
- Im Quellsystem werden bei Datenänderungen Dateien erstellt und aktualisiert.
Ihr Data Lake für Rohdaten besteht aus Ihren Ziel- und Konformitätscontainern. Jeder Container verwendet eine zu 100 % obligatorische Ordnerstruktur, die für seinen Zweck spezifisch ist.
Zielcontainerlayout
Ihr Zielcontainer ist für Rohdaten aus einem erkannten Quellsystem reserviert. Ihre datenunabhängige Erfassungs-Engine oder eine quellenorientierte Datenanwendung lädt die Daten, die unverändert und im ursprünglich unterstützten Format vorliegen.
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
Konformitätscontainer der Rohdatenebene
Ihre Rohdatenebene enthält Daten, die den Datenqualitätsanforderungen entsprechen. Wenn Daten in einen Zielcontainer kopiert werden, werden Datenverarbeitung und Computing ausgelöst, um die Daten aus dem Zielcontainer in den Konformitätscontainer zu kopieren. In dieser ersten Phase werden Daten in das Delta Lake-Format konvertiert und in einem Eingabeordner platziert. Bei der Datenqualitätsprüfung werden Datensätze, die die Anforderungen erfüllen, in den Ausgabeordner kopiert. Datensätze, die die Anforderungen nicht erfüllen, werden in einem Fehlerordner platziert.
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
Tipp
Denken Sie an Szenarien, in denen Sie eine Analyseplattform möglicherweise von Grund auf neu erstellen müssen. Berücksichtigen Sie die präzisesten Daten, die nötig sind, um nachgelagerte Lesedatenspeicher neu zu erstellen. Stellen Sie sicher, dass Sie über einen BCDR-Plan (Business Continuity & Disaster Recovery) für Ihre zentralen Komponenten verfügen.
Ebene für angereicherte Daten (Data Lake 2)
Die Ebene für angereicherte Daten ist im Prinzip eine Filterebene. Sie entfernt Verunreinigungen und kann auch Anreicherungen umfassen.
Ihr Standardisierungscontainer enthält Systems of Record und Master. Ordner werden zuerst nach Themenbereich und dann nach Entität segmentiert. Daten sind in zusammengeführten, partitionierten Tabellen verfügbar, die für Analysen optimiert sind.
Standardisierter Container
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
Hinweis
Diese Datenebene wird als silberne Ebene oder Lesedatenquelle betrachtet. Auf die in dieser Ebene enthaltenen Daten wurden mit Ausnahme von Datenqualität, Delta Lake-Konvertierung und Datentypausrichtung keinerlei Transformationen angewendet.
Das folgende Diagramm zeigt den Datenfluss für Data Lakes und Container – von den Quelldaten bis zu einem standardisierten Container:
Ebene für kuratierte Daten (Data Lake 2)
Die Ebene für kuratierte Daten ist Ihre Nutzungsebene. Sie werden weniger für die Datenerfassung oder Verarbeitung als vielmehr für Analysen optimiert. Auf der Ebene für kuratierte Daten können Daten in denormalisierten Data Marts oder Sternschemas gespeichert werden.
Daten aus Ihrem standardisierten Container werden in hochwertige Datenprodukte transformiert, die dann für Ihre Datenconsumer bereitgestellt werden. Diese Daten sind strukturiert. Sie können den Consumern entweder unverändert (wie in Data Science-Notebooks) oder über einen anderen Lesedatenspeicher wie eine Azure SQL-Datenbank bereitgestellt werden.
Führen Sie die dimensionale Modellierung nicht intern in Ihrer Datenbank-Engine durch, sondern verwenden Sie dafür Tools wie Spark oder Data Factory. Die Verwendung von Tools wird relevant, wenn der Lake als Single Source of Truth fungieren soll.
Wenn Sie die dimensionale Modellierung außerhalb Ihres Lakes vornehmen, empfiehlt es sich aus Konsistenzgründen gegebenenfalls, Modelle wieder in Ihrem Lake zu veröffentlichen. Diese Ebene ist kein Ersatz für ein Data Warehouse. Die Leistung ist üblicherweise für reaktionsfähige Dashboards oder interaktive Analysen für Endbenutzer nicht ausreichend. Diese Ebene eignet sich am besten für interne Analysten oder für wissenschaftliche Fachkräfte für Daten, die umfangreiche improvisierte Abfragen oder Analysen durchführen, sowie für erfahrene Analysten, die nicht auf zeitkritische Berichte angewiesen sind. Da die Speicherkosten in Ihrem Data Lake niedriger sind als in Ihrem Data Warehouse, kann es kostengünstiger sein, detaillierte Daten auf niedriger Ebene in Ihrem Lake aufzubewahren. Speichern Sie aggregierte Daten in Ihrem Warehouse. Generieren Sie diese Aggregationen mithilfe von Spark oder Azure Data Factory. Speichern Sie sie dauerhaft in Ihrem Data Lake, bevor Sie sie in Ihr Data Warehouse laden.
Datenressourcen in dieser Zone werden in der Regel stark kontrolliert und gut dokumentiert. Weisen Sie Berechtigungen nach Abteilung oder Funktion zu, und strukturieren Sie Berechtigungen nach Consumergruppe oder Data Mart.
Container für Datenprodukte
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Tipp
Wenn Sie Daten in einem anderen Lesedatenspeicher (z. B. Azure SQL-Datenbank) platzieren, achten Sie darauf, dass Sie in Ihren kuratierten Daten über eine Kopie dieser Daten verfügen. Benutzer Ihres Datenprodukts werden zwar zu Ihrem Hauptlesedatenspeicher oder zur Azure SQL-Datenbank-Instanz geleitet, sie können aber auch Datenuntersuchungen mit zusätzlichen Tools durchführen, wenn Sie die Daten in Ihrem Data Lake verfügbar machen.
Entwicklungsebene (Data Lake 3)
Ihre Datenconsumer können weitere nützliche Datenprodukte mit den in Ihrem standardisierten Container erfassten Daten verwenden.
In diesem Szenario kann Ihre Datenplattform für diese Consumer einen Sandboxbereich für Analysen zuordnen. In der Sandbox können sie anhand der kuratierten Daten und mithilfe der eigenen Datenprodukte wertvolle Erkenntnisse generieren. Wenn ein Data Science-Team beispielsweise die beste Product Placement-Strategie für eine neue Region ermitteln möchte, kann es weitere Datenprodukte wie demografische Daten und Nutzungsdaten von Kunden aus ähnlichen Produkten in der jeweiligen Region einbringen. Auf der Grundlage der hochwertigen Vertriebserkenntnisse, die aus diesen Daten gewonnen wurden, kann das Team die Eignung für den Produktmarkt und die Angebotsstrategie analysieren.
Hinweis
Der Sandboxbereich für Analysen ist ein Arbeitsbereich für eine Einzelperson oder eine kleine Gruppe von Projektmitarbeitern. Die Ordner des Sandboxbereichs verfügen über spezielle Richtlinien, die die Verwendung dieses Bereichs als Teil einer Produktionslösung unterbinden. Diese Richtlinien begrenzen den insgesamt verfügbaren Speicher sowie die Dauer der Datenspeicherung.
Qualität und Genauigkeit dieser Datenprodukte sind meist unbekannt. Sie werden zwar weiterhin als Datenprodukte kategorisiert, sind jedoch temporär und nur für die Benutzergruppe relevant, die die Daten verwendet.
Wenn sich diese Datenprodukte weiterentwickeln, kann Ihr Unternehmen die Datenprodukte auf die Ebene für kuratierte Daten höherstufen. Damit Datenproduktteams weiterhin für neue Datenprodukte zuständig sind, empfiehlt es sich, für diese Teams einen dedizierten Ordner in Ihrer Zone für kuratierte Daten bereitzustellen. Sie können neue Ergebnisse im Ordner speichern und sie für andere Teams in der gesamten Organisation freigeben.
Hinweis
Verwenden Sie für jeden von Ihnen erstellten Azure Synapse-Arbeitsbereich den dritten Data Lake, um einen Container zu erstellen, den Sie als primären Speicher verwenden können. Dieser Container verhindert, dass sich Azure Synapse-Arbeitsbereiche auf die Durchsatzgrenzwerte Ihrer Zonen für kuratierte und angereicherte Daten auswirken.
Beispiel für den Datenfluss in Produkte und in die Sandbox für Analysen
Das folgende Diagramm kompiliert die Informationen in diesem Artikel und zeigt, wie Daten in eine Sandbox für Datenprodukte und Analysen fließen.
