Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:✅SQL-Datenbank in Microsoft Fabric
In diesem Artikel wird die Verwendung der SQL-Datenbank in Fabric als Reverse-ETL-Ziel innerhalb einer Fabric-basierten Datenstruktur beschrieben. Es bietet Architekturanleitungen, Betriebsmuster und Implementierungsüberlegungen für das Verschieben kuratierter Daten aus analytischen Quellen (z. B. Microsoft Fabric Data Warehouse oder Fabric Lakehouse) in SQL-Datenbank in Fabric für den Betriebsverbrauch durch Anwendungen, APIs und Echtzeiterfahrungen.
Was ist reverse ETL in Fabric?
Viele Kunden haben erhebliche Zeit und Mühe in die Erstellung von Extrakt-, Transformations-, Last- (ETL)- Prozessen investiert, um Rohdaten in verfeinerte Analysedaten zu transformieren, die für die Geschäftsberichterstattung verwendet werden können. Das Endergebnis eines ETL-Prozesses ist in der Regel ein analytischer Speicher wie ein Lager oder ein Seehaus, auf das eine Berichtsschicht wie Power BI zugreift. Diese Architektur dient geschäftskunden gut, aber die Berichterstattung ist relativ statisch und Erkenntnisse können nur durch menschliche Interventionen abgeleitet werden. Mithilfe von Reverse ETL können Sie die transformierten Daten wieder in betriebsbereite Systeme einspeisen, sodass Anwendungen und Agenten Einblicke aus diesen analysierten Daten in Echtzeit gewinnen können. Reverse ETL verschiebt Daten aus Fakten und Dimensionen in analytischen Speicher in eine Bereitstellungsebene, auf die über Endpunkte wie GraphQL oder direkt über TDS-Abfragen (Tabular Data Stream) zugegriffen werden kann.
Sie können operative Anwendungen zwar direkt mit einem Lager oder Seehaus verbinden, diese Datenspeicher sind jedoch für analytische Workloads ausgelegt. Betriebsdatenspeicher, z. B. SQL-Datenbank in Fabric, dienen zur Unterstützung von Transaktionsabfragen und bieten eine bessere Leistung und Skalierbarkeit für operative Workloads. Operationale Datenbanken geben Ihnen außerdem die Möglichkeit, Daten mit Vektoreinbettungen und zusätzlichen Metadaten weiter anzureichern, um Vektor- und Hybridsuche sowie retrieval-augmented generation (RAG) zu erleichtern.
- In diesem Muster bleibt das Lager - oder Seehaus das Analytische System der Aufzeichnung.
- DIE SQL-Datenbank in Fabric dient als betriebsbereiter Speicher, der geringe Latenz, eingeschränkte Indizierung, strenge Daten- und Beziehungseinschränkungen und die von Anwendungsteams erwarteten SLAs bietet.
Häufige Reverse-ETL-Ziele
Häufige Reverse-ETL-Ziele stellen in der Regel kuratierte, hochwertige Datensegmente dar, die betriebsbereite Systeme mit minimaler Transformation nutzen können. Diese Ziele sind so konzipiert, dass der Zugriff auf vertrauenswürdige Daten mit geringer Latenz und gleichzeitig die auf der Analytischen Ebene angewendete Geschäftslogik erhalten bleibt. Beispiele sind:
- Kunden- und Benutzerdaten (z. B. Interaktionsmetriken wie Sitzungsaktivität, Featurenutzung und Interaktionen)
- Umsatz- und Marketingdaten (z. B. Bewertungsmetriken wie Neigung zum Kaufen, Engagement-Bewertungen, Wahrscheinlichkeit der Konvertierung)
- Betriebs- und Transaktionsdaten (z. B. Bestell- und Bestandsdaten wie Lagerbestände, Auftragsstatus und Lieferdauern)
- AI/ML Abgeleitete Daten (z. B. personalisierte Produktempfehlungen, vorausschauende Scores wie Churn-Risiko oder Upsell-Neigung oder Stimmungsanalyse)
Mechanismen zur Datenbewegung
Der Prozess beginnt mit der Definition der Quelldaten, dem Festlegen des Ziels und dem Anschließenden Auswählen eines Datenverschiebungsmechanismus. Wählen Sie einen oder mehrere der folgenden Mechanismen aus, um Daten aus Ihrem analytischen Speicher in die SQL-Datenbank in Fabric zu verschieben.
Tipp
Verwenden Sie in der Regel Folgendes:
- Pipelines für einfaches Kopieren und geplante Ladevorgänge.
- Dataflows Gen2 für Low-Code-Transformationen.
- Spark für komplexe und großflächige Verarbeitung (einschließlich maschinellen Lernens).
- Elementübergreifender T-SQL-Dienst , der für sql-zentrierte Vorgänge verfügbar ist, z. B. das Verknüpfen einer Tabelle in einer SQL-Datenbank zu einer Tabelle in einem Lager- oder SQL-Analyseendpunkt.
| Mechanismus | Verwenden, wenn | Stärken | Betrachtungen |
|---|---|---|---|
| Fabric-Datenpipelines | Sie benötigen verwaltete, wiederholbare Arbeitslasten (Batch- oder Mikro-Batch-Verfahren) von Datenkopiervorgängen. | Erstklassige Integration; unterstützt Wasserzeichen und gespeicherte Prozeduren | Parallelität; SQL-Datenbank beim Laden skalieren |
| Dataflow Gen2 | Es werden Low-Code-Datentransformationen und erweiterte Prozesslogik benötigt. | Geschäftsfreundlich; unterstützt Spaltengestaltung und -reinigung | Geringerer Durchsatz für große Mengen: Partitionierung planen |
| Spark (Notizbücher/Aufträge) | Sie benötigen komplexe codebasierte Transformationen und umfangreiche Umgestaltungen | Vollständige Code-Kontrolle; effiziente Delta-Lesevorgänge; Unterstützung für JDBC-Schreibvorgänge | Authentifizierung und Batchverarbeitung; Vermeiden großer Transaktionen |
| Elementübergreifende T-SQL-Abfragen | Sie benötigen in der Datenbank SQL-Bewegung zwischen Fabric-Elementen | Minimale Sanitärinstallation; SQL-nativ; einfach zu planen |
Referenzarchitektur: Reverse ETL in eine SQL-Datenbank in Fabric
Die Referenzarchitektur für reverse ETL in Fabric vereint die wesentlichen Bausteine, die erforderlich sind, um kuratierte Analysedaten zu operationalisieren. Es zeigt, wie Daten aus vertrauenswürdigen analytischen Quellen durch Transformationsebenen in eine strukturierte SQL-Datenbank fließen. Die Betriebsdatenbank dient als Schnittstelle für nachgeschaltete Systeme. Dieses Muster stellt sicher, dass Anwendungen, APIs und Berichterstellungstools auf Daten mit geringer Latenz und hoher Qualität zugreifen können, ohne die Integrität des Analysesystems des Datensatzes zu beeinträchtigen.
Die Kernkomponenten dieses Flusses umfassen:
- Quelle: Kuratierte Datasets aus einem Fabric Data Warehouse oder Lakehouse (Delta).
- Transformationen: Reverse ETL-Transformationen, die mithilfe von Pipelines, Dataflow Gen2, Spark oder cross-item T-SQL angewendet werden.
- Ziel: SQL-Datenbank in Fabric mit definierter Landungs-, optionaler Verlaufs-, Quarantäne- und Dienstschema.
- Consumer: Anwendungen über GraphQL oder TDS, APIs und Power BI für Echtzeit-Dashboards und Berichte.
Komponenten
Die folgenden Komponenten sind am allgemeinen Ablauf zur Verwendung der SQL-Datenbank in Fabric als Ziel für Reverse-ETL beteiligt.
Dienst- und Landungsschemas
- Ordnen Sie Quelldaten den entsprechenden Zielschemas in der SQL-Datenbank in Fabric zu.
- Optional können Sie ein
historySchema zur Überwachung beibehalten. - Verwenden Sie ein
quarantineSchema für Ablehnungen (Datenqualitätsprobleme). - Definieren Sie ein
servingSchema für den nachgeschalteten Verbrauch mit entsprechenden Einschränkungen und Indizierung.
Orchestrierung
- Planen Sie Übertragungen in Fabric mithilfe von Pipelines, Datenflüssen oder Spark-Aufträgen.
- Verwenden Sie die integrierte Zeitplanung, um Rhythmus, Startzeit und Zeitzone zu konfigurieren.
- Planen Sie Spark-Notizbücher über das Fabric-Portal oder die API.
- Überwachen Sie End-to-End-Abläufe im Fabric Monitoring Hub.
Consumption
- Machen Sie Daten über GraphQL-Endpunkte oder T-SQL über TDS verfügbar, indem Sie Clientbibliotheken wie ADO.NET (und andere) verwenden.
- Erstellen Sie Power BI-Dashboards und Visualisierungen direkt über die SQL-Datenbank in Fabric.
Governance und Sicherheit
- Verwenden Sie die Microsoft Entra-ID für die Authentifizierung und Autorisierung.
- Kombinieren Sie Fabric-Arbeitsbereichsrollenberechtigungen und SQL-Berechtigungen für granulare Kontrolle.
- Konfigurieren Sie optional vom Kunden verwaltete Schlüssel für die Verschlüsselung ruhender Daten.
- Auditieren Sie den Zugriff und sichern Sie Daten während der Übertragung mithilfe von Private Link.
Anwendungsbereitstellung
Nachdem Sie Daten in der SQL-Datenbank zusammengestellt und aktualisiert haben, setzen Sie den Fokus auf schnelle und zuverlässige Zugriffe für betriebliche Verbraucher. In diesem Kontext bedeutet Anwendungsbereitstellung, vertrauenswürdige Datensätze über Schnittstellen mit niedriger Latenz zur Verfügung zu stellen, die mit modernen Anwendungsmustern übereinstimmen.
Nachdem Daten in der SQL-Datenbank in Fabric gelandet und aktualisiert wurden:
- Um betriebsbereite Workloads zu bedienen, machen Sie Daten über GraphQL-Endpunkte oder das TDS-Protokoll verfügbar, die über ADO.NET und andere Clientbibliotheken genutzt werden sollen. Stellen Sie beispielsweise Produktinformationen, Lieferketten- oder Kundendienstanwendungsfälle bereit.
- Koppeln Sie das Dataset mit Power BI , um Echtzeit-Dashboards und Self-Service-Analysen bereitzustellen.
Fabric-spezifische Überlegungen
SQL-Datenbank in Fabric verwendet dasselbe SQL-Datenbankmodul wie Azure SQL-Datenbank und wird über das Fabric-Portal gesteuert, gesichert, in Rechnung gestellt und betrieben. Es bietet auch integrierte Spiegelung in Delta-/Parkettdateien , die in Microsoft OneLake gespeichert sind, auf die über einen SQL-Analyseendpunkt zugegriffen wird. Da es sich in der Microsoft Fabric-Umgebung befindet, gibt es einige Überlegungen, die Sie beim Erstellen Ihres Designs berücksichtigen sollten:
- Featureparität: Die SQL-Datenbank in Fabric konvergiert mit der Azure-SQL-Datenbank. Überprüfen Sie bestimmte Features, die Sie benötigen, um die Eignung sicherzustellen, und überwachen Sie Roadmap-Updates.
- Sicherheitsmodell: Die SQL-Datenbank in Fabric verwendet nur die Microsoft Entra ID-Authentifizierung . Planen Sie Identitäten für Pipelines, Dataflows und Spark-Aufträge entsprechend.
- Replikation: SQL-Datenbank in Fabric repliziert automatisch schreibgeschützte Daten in OneLake. Diese Synchronisierung ist nützlich für Berichts- und Analyseanforderungen, während die Datenbank für Arbeitslasten mit Lese-/Schreibzugriff verfügbar bleibt.