Handbuch

Daten sind in einem festen tabellarischen Layout mit einem vordefinierten Schema (Zeilen und Spalten) organisiert, z. B. ein Produktkatalog oder Finanzunterlagen.

→Als Strukturierte Daten darstellen.

Warum: Strukturierte Daten entsprechen einem starren Schema und sind ideal für relationale Datenbanken (OLTP). Im Gegensatz dazu stehen semi-strukturierte (JSON/XML) und unstrukturierte Daten (Bilder/Audio).

Daten haben eine gewisse Organisationsstruktur (Tags, Schlüssel), aber kein starres Schema. Jeder Datensatz kann unterschiedliche Felder haben, wie z. B. JSON-Dokumente von IoT-Sensoren.

→Als Semi-strukturierte Daten darstellen (z. B. JSON, XML).

Warum: JSON und XML sind selbstdokumentierend und bieten Flexibilität gegenüber den festen Schemata strukturierter Daten. Ideal für NoSQL-Datenbanken und Data Lakes.

Speicherung großer Dateien ohne vordefiniertes Schema oder Organisationsstruktur, wie z. B. MRT-Scans, Videos oder Audioaufnahmen.

→Als Unstrukturierte Daten darstellen.

Warum: Dieser Datentyp kann nicht in traditionellen Zeilen-/Spalten-Datenbanken gespeichert werden. Erfordert Objektspeicher wie Azure Blob Storage.

Unterscheidung zwischen Workloads für den täglichen Betrieb und für die historische Analyse.

→Verwenden Sie OLTP (Online Transaction Processing) für Transaktionen mit hohem Volumen und niedriger Latenz (z. B. E-Commerce-Bestellungen). Verwenden Sie OLAP (Online Analytical Processing) für komplexe Abfragen über große historische Datensätze (z. B. Verkaufs trendanalyse).

Warum: OLTP-Systeme sind normalisiert und für schnelle Schreibvorgänge optimiert. OLAP-Systeme sind denormalisiert (Sternschema) und für schnelle Lesevorgänge und Aggregationen optimiert.

Wählen Sie ein Datenintegrationsmuster für ein Data Warehouse.

→Verwenden Sie ETL (Extract, Transform, Load), wenn die Transformationslogik komplex ist und vor dem Laden auf einem Staging-Server durchgeführt wird. Verwenden Sie ELT (Extract, Load, Transform), um Rohdaten in ein leistungsstarkes Zielsystem (z. B. Synapse Analytics) zu laden und dessen Rechenleistung für Transformationen zu nutzen.

Warum: ELT ist das moderne Cloud-Muster, das skalierbare Rechenleistung im Zieldatenspeicher (Data Warehouse/Lakehouse) nutzt und die Datenaufnahme vereinfacht.

Zuweisung von Verantwortlichkeiten für Datenplattformaufgaben.

→Data Engineer: Erstellt und wartet ETL/ELT-Pipelines. Datenbankadministrator (DBA): Verwaltet Datenbanksicherheit, -leistung und -verfügbarkeit. Datenanalyst: Erstellt Berichte und Visualisierungen (z. B. Power BI) für Geschäftseinblicke.

Warum: Klar definierte Rollen sind unerlässlich. Die Hauptunterscheidung liegt im Erstellen (Engineer), Verwalten (DBA) und Analysieren (Analyst).

Verarbeitung großer Datenmengen mit unterschiedlichen Latenzanforderungen.

→Verwenden Sie Batch-Verarbeitung für ruhende Daten, die in geplanten Intervallen verarbeitet werden (z. B. nächtliche Berichte). Verwenden Sie Stream-Verarbeitung für Daten in Bewegung, die kontinuierlich bei Ankunft verarbeitet werden (z. B. Echtzeit-Betrugserkennung).

Warum: Der Hauptkompromiss liegt zwischen Latenz und Kosten/Durchsatz. Die Stream-Verarbeitung bietet niedrige Latenz, erfordert aber ständig verfügbare Ressourcen. Die Batch-Verarbeitung hat eine hohe Latenz, ist aber kostengünstig für große Datenmengen.

Entwurf eines Schemas für ein Data Warehouse zur Unterstützung analytischer Abfragen.

→Verwenden Sie ein Sternschema, das aus einer zentralen Faktentabelle (mit numerischen Messwerten) besteht, die mit mehreren Dimensionstabellen (mit beschreibenden Attributen) verbunden ist.

Warum: Diese denormalisierte Struktur minimiert Joins für analytische Abfragen und verbessert die Leistung im Vergleich zu einem normalisierten (OLTP) Schema. Sie ist einfacher und schneller für die meisten BI-Tools als ein Schneeflockenschema.

Wählen eines zentralen Repositories für Analysen.

→Verwenden Sie einen Data Lake (z. B. Azure Data Lake Storage), um große Mengen an Rohdaten in ihrem nativen Format zu speichern (Schema-on-Read). Verwenden Sie ein Data Warehouse (z. B. Synapse Dedicated SQL Pool), um strukturierte, verarbeitete Daten für BI und Reporting zu speichern (Schema-on-Write).

Warum: Data Lakes bieten Flexibilität für Data Science und die Erkundung von Rohdaten. Data Warehouses bieten hohe Leistung und Struktur für Business Intelligence.

Benötigen Sie eine vollständig verwaltete relationale Datenbank für eine neue Cloud-native Anwendung, ohne die zugrunde liegende Infrastruktur verwalten zu müssen.

→Verwenden Sie Azure SQL-Datenbank.

Warum: Es ist ein PaaS-Angebot mit automatischer Patching, Backups und hoher Verfügbarkeit. Ideal für Standard-SQL-Workloads, bei denen kein OS-Zugriff erforderlich ist.

Referenz↗

Lift-and-Shift-Migration einer lokalen SQL Server-Workload, die instanzbezogene Funktionen wie SQL Server Agent, datenbankübergreifende Abfragen oder Service Broker verwendet.

→Verwenden Sie Azure SQL Managed Instance.

Warum: SQL MI bietet nahezu 100%ige Kompatibilität mit der lokalen SQL Server-Engine, wodurch Migrationsänderungen minimiert werden. Azure SQL-Datenbank unterstützt diese instanzbezogenen Funktionen nicht.

Referenz↗

Migration einer SQL Server-Datenbank nach Azure, die volle Kontrolle über das Betriebssystem, spezifische SQL Server-Versionen oder Funktionen mit begrenzter PaaS-Unterstützung (z. B. bestimmte CLR-Assemblies) erfordert.

→Verwenden Sie SQL Server auf Azure Virtual Machines.

Warum: Diese IaaS-Option bietet maximale Kompatibilität und Kontrolle, erfordert jedoch, dass der Benutzer das Betriebssystem, Patches und Backups verwaltet, im Gegensatz zu PaaS-Angeboten.

Eine Anwendung hat intermittierende, unvorhersehbare Nutzungsmuster mit langen Leerlaufzeiten. Die Kosten während der Inaktivität müssen minimiert werden.

→Verwenden Sie den Serverless Compute-Tarif für Azure SQL-Datenbank.

Warum: Serverless skaliert die Rechenleistung automatisch nach Bedarf und kann die Datenbank automatisch anhalten, wobei in Leerlaufzeiten nur der Speicher in Rechnung gestellt wird. Ideal für variable Workloads.

Referenz↗

Hosting mehrerer kleiner Datenbanken für verschiedene Mandanten (SaaS) mit variablen Workloads. Ressourcen müssen gemeinsam genutzt werden, um Kosten zu senken.

→Verwenden Sie Azure SQL-Datenbank-Elastic Pools.

Warum: Elastic Pools ermöglichen es mehreren Datenbanken, einen vorab zugewiesenen Satz von Ressourcen (DTUs oder vCores) gemeinsam zu nutzen, was eine kostengünstige Lösung für mandantenfähige Anwendungen bietet.

Eine Datenbank wird voraussichtlich über 4 TB (bis zu 100 TB) wachsen und erfordert eine schnelle Skalierung sowie nahezu sofortige Backups und Wiederherstellungen, unabhängig von der Größe.

→Verwenden Sie den Hyperscale-Diensttarif für Azure SQL-Datenbank.

Warum: Hyperscale verwendet eine einzigartige verteilte Architektur für sehr große Datenbanken (VLDBs), die die Größenbeschränkungen anderer Tarife durchbricht und Datenbankoperationen in konstanter Zeit ermöglicht.

Bereitstellung einer verwalteten PostgreSQL-Datenbank für eine Microservices-Anwendung, die zonenredundante Hochverfügbarkeit und unabhängige Skalierung von Compute und Speicher erfordert.

→Verwenden Sie Azure Database for PostgreSQL - Flexible Server.

Warum: Flexible Server ist das empfohlene Angebot und bietet zonenredundante HA, benutzerdefinierte Wartungsfenster und eine bessere Kostenoptimierung im Vergleich zum älteren Single Server-Modell.

Schützen Sie sensible Daten (z. B. Kreditkartennummern), sodass diese im Ruhezustand, während der Übertragung UND während der Verwendung (im Speicher) auf dem Server verschlüsselt bleiben. Auch DBAs sollten keine Klartextdaten sehen.

→Verwenden Sie Always Encrypted.

Warum: Always Encrypted ist eine clientseitige Verschlüsselungstechnologie, bei der die Schlüssel vom Client gehalten werden, wodurch sichergestellt wird, dass Daten niemals auf dem Server entschlüsselt werden. TDE schützt Daten nur im Ruhezustand.

Sensible Daten vor nicht-privilegierten Benutzern in Abfrageergebnissen ausblenden (z. B. nur die letzten vier Ziffern einer Sozialversicherungsnummer anzeigen), ohne die gespeicherten Daten zu ändern.

→Verwenden Sie Dynamic Data Masking.

Warum: DDM wendet Maskierungsregeln zur Abfragezeit basierend auf Benutzerberechtigungen an. Es ist eine Sicherheitsfunktion zur Begrenzung der Datenexposition, keine Verschlüsselungsfunktion.

Sicherstellung der Geschäftskontinuität für eine Gruppe von Azure SQL-Datenbanken durch Aktivierung des automatischen Failovers in eine sekundäre Region im Falle eines regionalen Ausfalls.

→Konfigurieren Sie eine Auto-Failover-Gruppe.

Warum: Auto-Failover-Gruppen bieten einen einheitlichen Listener-Endpunkt, der den Datenverkehr nach dem Failover automatisch umleitet und so das Anwendungsdesign für DR vereinfacht. Sie bieten einen niedrigeren RPO/RTO als die Wiederherstellung aus georedundanten Backups.

Massive Mengen unstrukturierter Daten, wie Videodateien, Bilder, Backups und Protokolle, kostengünstig speichern.

→Verwenden Sie Azure Blob Storage.

Warum: Blob Storage ist ein Objektspeicherdienst, der für die Speicherung von Petabytes unstrukturierter Daten optimiert ist. Er ist nicht für Workloads mit strukturierten Abfragen geeignet.

Referenz↗

Speicherkosten für Daten mit unterschiedlichen Zugriffsmustern optimieren.

→Verwenden Sie Azure Blob Storage-Zugriffsebenen: Hot (häufig zugegriffen), Cool (selten zugegriffen, >30 Tage), Archive (sehr selten zugegriffen, >180 Tage).

Warum: Ebenen bieten einen Kosten-Kompromiss: Hot hat die höchsten Speicherkosten, aber die geringsten Zugriffskosten. Archive hat die niedrigsten Speicherkosten, aber die höchsten Zugriffskosten und die höchste Abruflatenz (Stunden).

Blobs automatisch basierend auf ihrem Alter oder der letzten Zugriffszeit zwischen den Hot-, Cool- und Archive-Ebenen verschieben, um Kosten zu optimieren.

→Konfigurieren Sie eine Lebenszyklusverwaltungsrichtlinie für das Speicherkonto.

Warum: Dies automatisiert den Tiering-Prozess und stellt sicher, dass Daten ohne manuellen Eingriff immer auf der kostengünstigsten Ebene gespeichert werden.

Migrieren Sie eine lokale Anwendung, die SMB-Dateifreigaben verwendet. Mehrere VMs müssen denselben freigegebenen Ordner mounten und darauf zugreifen.

→Verwenden Sie Azure File Storage.

Warum: Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, die über die SMB- und NFS-Protokolle zugänglich sind, und ist somit ein direkter Ersatz für lokale Dateiserver.

Aufbau eines Data Lakes für Big Data Analytics, der effiziente Operationen auf Verzeichnisebene und eine feingranulare, POSIX-ähnliche Zugriffssteuerung erfordert.

→Verwenden Sie Azure Data Lake Storage Gen2.

Warum: ADLS Gen2 baut auf Blob Storage auf, indem es einen hierarchischen Namespace (für atomare Verzeichnisoperationen) und Unterstützung für POSIX-konforme ACLs hinzufügt, die für Leistung und Sicherheit in Big Data Frameworks wie Spark entscheidend sind.

Eine globale Anwendung erfordert eine Lese-/Schreiblatenz im einstelligen Millisekundenbereich, automatische Replikation über mehrere Regionen und horizontale Skalierung für eine NoSQL-Datenbank.

→Verwenden Sie Azure Cosmos DB.

Warum: Cosmos DB wurde für global verteilte, geschäftskritische Anwendungen entwickelt und bietet schlüsselfertige globale Verteilung, garantierte niedrige Latenz-SLAs und mehrere Konsistenzmodelle.

Referenz↗

Wählen eines Datenmodells und einer API für eine neue Cosmos DB-Anwendung.

→Verwenden Sie die API für NoSQL (Dokument), MongoDB API (Dokument), Apache Gremlin API (Graph), Table API (Schlüssel-Wert) oder Apache Cassandra API (Wide-Column).

Warum: Wählen Sie die API, die am besten zu Ihrem Datenmodell und Ihrem bestehenden Anwendungsstack passt. Verwenden Sie NoSQL für neue JSON-basierte Apps, Gremlin für beziehungsintensive Daten und andere für die Migration bestehender Workloads (MongoDB, Cassandra, Table Storage).

Abwägung von Lesekonsistenz, Verfügbarkeit und Leistung für eine Cosmos DB-Anwendung.

→Wählen Sie aus fünf Konsistenzstufen: Strong, Bounded Staleness, Session (Standard), Consistent Prefix, Eventual.

Warum: Strong bietet die höchste Konsistenz, aber die höchste Latenz. Eventual bietet die niedrigste Latenz, aber die schwächste Konsistenz. Session ist am häufigsten und garantiert, dass ein Benutzer seine eigenen Schreibvorgänge innerhalb seiner Sitzung liest.

Ein nachgeschalteter Dienst muss nahezu in Echtzeit auf alle in einem Cosmos DB-Container erstellten oder aktualisierten Daten reagieren (z. B. zur Aktualisierung eines Suchindex).

→Verwenden Sie den Cosmos DB Change Feed.

Warum: Der Change Feed bietet ein persistentes, geordnetes Protokoll von Änderungen. Er wird häufig von einer Azure Function konsumiert, um ereignisgesteuerte Architekturen ohne Abfragen der Datenbank zu erstellen.

Komplexe analytische Abfragen auf operativen Cosmos DB-Daten ausführen, ohne die Leistung der transaktionalen Workload (HTAP) zu beeinträchtigen.

→Aktivieren Sie den Azure Cosmos DB Analytical Store und verwenden Sie Azure Synapse Link.

Warum: Der Analytical Store ist eine vollständig isolierte, automatisch synchronisierte spaltenbasierte Darstellung Ihrer Transaktionsdaten. Er ermöglicht analytische Abfragen über Synapse, ohne transaktionale Request Units (RUs) zu verbrauchen.

Speicherung großer Mengen einfacher, strukturierter nicht-relationaler Daten (z. B. Gerätelemetrie) für schnelle schlüsselbasierte Abfragen zu sehr geringen Kosten.

→Verwenden Sie Azure Table Storage.

Warum: Table Storage ist ein NoSQL Schlüssel-Wert-Speicher, der für einfache Abfragen mit hohem Volumen mittels PartitionKey und RowKey optimiert ist. Er ist deutlich günstiger als Cosmos DB, wenn niedrige Latenz-SLAs und globale Verteilung nicht erforderlich sind.

Benötigen Sie ein einfaches, zuverlässiges Messaging-System zur Entkopplung von Anwendungskomponenten, bei dem Nachrichten asynchron verarbeitet werden.

→Verwenden Sie Azure Queue Storage.

Warum: Queue Storage bietet eine einfache, kostengünstige und zuverlässige Nachrichtenwarteschlange für grundlegende asynchrone Kommunikationsmuster.

Müssen Sie komplexe Datenintegrations-Workflows erstellen, planen und überwachen, die Daten aus verschiedenen lokalen und Cloud-Quellen verschieben und transformieren.

→Verwenden Sie Azure Data Factory (ADF).

Warum: ADF ist ein verwalteter Cloud-Orchestrierungsdienst zum Erstellen und Verwalten von ETL/ELT-Pipelines im großen Maßstab, mit umfangreichen Konnektivitäts- und Überwachungsfunktionen.

Referenz↗

Eine Azure Data Factory-Pipeline muss auf eine Datenquelle zugreifen, die sich lokal hinter einer Unternehmensfirewall befindet.

→Installieren Sie eine selbstgehostete Integration Runtime (IR) auf einem Computer innerhalb des lokalen Netzwerks.

Warum: Die selbstgehostete IR fungiert als sicheres Gateway, das ADF in der Cloud ermöglicht, sich mit lokalen Datenquellen zu verbinden und Daten von dort zu verschieben, ohne diese dem öffentlichen Internet auszusetzen.

Benötigen Sie eine einzige, integrierte Plattform für Data Warehousing (SQL), Big Data Analytics (Spark), Datenexploration (serverloses SQL) und Datenintegration.

→Verwenden Sie Azure Synapse Analytics.

Warum: Synapse bietet einen vereinheitlichten Arbeitsbereich (Synapse Studio), der diese verschiedenen Analyse-Engines zusammenführt und so Komplexität und Integrationsaufwand reduziert.

Wählen einer SQL-Abfrage-Engine innerhalb von Synapse Analytics.

→Verwenden Sie den Serverless SQL Pool für Ad-hoc-, explorative Abfragen auf Daten im Data Lake mit einem Pay-per-Query-Modell. Verwenden Sie den Dedicated SQL Pool für leistungsstarke, vorhersehbare Data Warehousing-Workloads mit bereitgestellten Ressourcen.

Warum: Serverless ist für unvorhersehbare Exploration und Entdeckung. Dedicated ist für die Produktions-BI und Berichterstattung mit Leistungs-SLAs.

Müssen Sie hochvolumige Streaming-Daten in Echtzeit aus Quellen wie IoT Hub oder Event Hubs verarbeiten und analysieren, um Live-Dashboards zu versorgen oder Alarme auszulösen.

→Verwenden Sie Azure Stream Analytics.

Warum: Stream Analytics ist eine Echtzeit-Ereignisverarbeitungs-Engine, die eine einfache SQL-ähnliche Abfragesprache verwendet, um Daten in Bewegung mit geringer Latenz zu analysieren.

Ein Data Science-Team benötigt eine kollaborative, Notebook-basierte Umgebung für groß angelegte Datenengineering und maschinelles Lernen mit Apache Spark.

→Verwenden Sie Azure Databricks.

Warum: Databricks bietet eine optimierte Spark-Laufzeit, kollaborative Notebooks und integrierte ML-Funktionen (MLflow), was es zur führenden Plattform für erweiterte Analysen und ML in Azure macht.

Müssen Sie Millionen von Ereignissen pro Sekunde aus Quellen wie mobilen Apps, Web-Telemetrie oder IoT-Geräten für die Echtzeitverarbeitung erfassen.

→Verwenden Sie Azure Event Hubs.

Warum: Event Hubs ist eine Big-Data-Streaming-Plattform, die für die Ereignisaufnahme mit hohem Durchsatz entwickelt wurde. Sie fungiert als "Vordertür" für Streaming-Daten und entkoppelt Produzenten von Konsumenten.

Ein Unternehmen wünscht sich eine einzige, vereinheitlichte SaaS-Analyseplattform, die Datenengineering, Data Science, Data Warehousing und BI mit minimaler Infrastrukturverwaltung kombiniert.

→Verwenden Sie Microsoft Fabric.

Warum: Fabric bietet ein End-to-End-, SaaS-basiertes Analyseerlebnis, das auf einem einzigen Data Lake (OneLake) aufgebaut ist. Es vereinfacht die Architektur und reduziert den Integrationsaufwand im Vergleich zur Erstellung mit separaten PaaS-Diensten.

Referenz↗

Innerhalb von Microsoft Fabric benötigen Sie ein einziges Artefakt, um Daten im offenen Delta Lake-Format zu speichern, das sowohl von Spark-Engines (für Data Engineering) als auch von SQL-Engines (für BI) zugänglich ist.

→Verwenden Sie ein Microsoft Fabric Lakehouse.

Warum: Das Lakehouse ist das zentrale Architekturmuster in Fabric. Es kombiniert die Skalierbarkeit und Flexibilität eines Data Lakes mit den Transaktionsgarantien und SQL-Abfragefunktionen eines Data Warehouses.

Ein Power BI-Bericht in Microsoft Fabric muss große Datenmengen direkt aus OneLake abfragen, mit der Leistung des Importmodus, aber der Datenaktualität von DirectQuery.

→Verwenden Sie den Direct Lake-Modus in Power BI.

Warum: Direct Lake ist eine einzigartige Fabric-Funktion, die Parquet-/Delta-Dateien bei Bedarf direkt in den Arbeitsspeicher der Power BI-Engine lädt, wodurch Datenredundanz und Abfragelatenz vermieden und nahezu Echtzeit-Datenzugriff ermöglicht wird.

Geschäftsanwender müssen sich mit verschiedenen Datenquellen verbinden, interaktive Dashboards und Berichte erstellen und Erkenntnisse in der gesamten Organisation teilen.

→Verwenden Sie Power BI.

Warum: Power BI ist der Business-Analytics-Dienst von Microsoft zum Erstellen interaktiver Datenvisualisierungen. Verwenden Sie Power BI Desktop für die Erstellung und Power BI Service für die Freigabe und Zusammenarbeit.

Unterscheidung zwischen einer mehrseitigen interaktiven Analyse und einer einseitigen, hochrangigen Übersicht in Power BI.

→Ein Bericht ist eine mehrseitige Sammlung detaillierter, interaktiver Visualisierungen, die aus einem einzigen Datensatz erstellt wurden. Ein Dashboard ist eine einzelne Arbeitsfläche von Kacheln, die aus einem oder mehreren Berichten angeheftet wurden und eine schnelle Übersicht bieten.

Warum: Berichte sind für detaillierte Analysen. Dashboards dienen der Überwachung wichtiger Kennzahlen.

Ein einzelner Power BI-Bericht muss mit mehreren Benutzern geteilt werden, aber jeder Benutzer soll nur die für ihn relevanten Daten sehen (z. B. sieht ein Vertriebsleiter nur die Daten seiner Region).

→Implementieren Sie Row-Level Security (RLS).

Warum: RLS definiert Filterregeln basierend auf Benutzerrollen und erzwingt die Datensicherheit auf Ebene des Datenmodells, sodass Benutzer, die denselben Bericht aufrufen, unterschiedliche Teildatensätze sehen.

Müssen Sie hochformatierte, pixelgenaue Berichte (wie Rechnungen oder Finanzberichte) erstellen, die für den Druck oder den PDF-Export optimiert sind.

→Verwenden Sie Power BI Paginated Reports.

Warum: Paginated Reports sind für druckfertige Layouts mit präziser Kontrolle über Kopf- und Fußzeilen sowie Seitenumbrüche konzipiert, im Gegensatz zu standardmäßigen interaktiven Power BI-Berichten, die für die Bildschirmexploration gedacht sind.

Ein Power BI-Datensatz mit Milliarden von Zeilen benötigt zu lange zum Aktualisieren. Nur die Daten der letzten Tage ändern sich häufig.

→Konfigurieren Sie die inkrementelle Aktualisierung für den Datensatz.

Warum: Die inkrementelle Aktualisierung partitioniert die Daten (normalerweise nach Datum) und aktualisiert nur die jüngsten Partitionen, wodurch die Aktualisierungszeit und der Ressourcenverbrauch für große Datensätze drastisch reduziert werden.

Ein einzelner Power BI-Bericht muss vorab geladene, hochleistungsfähige Daten (Import-Modus) mit Echtzeitdaten aus einer operativen Quelle (DirectQuery-Modus) kombinieren.

→Verwenden Sie Power BI Composite Models.

Warum: Composite Models ermöglichen es einem einzelnen Datensatz, Tabellen mit verschiedenen Speichermodi zu mischen, was die Flexibilität bietet, Leistung und Datenaktualität auszugleichen.

Ein Unternehmen muss alle Datenbestände in seiner hybriden Datenlandschaft entdecken, klassifizieren und katalogisieren, um Daten-Governance und -Entdeckung zu ermöglichen.

→Verwenden Sie Microsoft Purview.

Warum: Purview ist ein vereinheitlichter Daten-Governance-Dienst, der automatisiertes Daten-Scanning, ein Business-Glossar, Datenklassifizierung und eine End-to-End-Datenherkunfts visualisierung bietet.