SQL-database gebruiken in omgekeerde ETL

Van toepassing op:✅SQL-database in Microsoft Fabric

In dit artikel wordt beschreven hoe u SQL Database in Fabric gebruikt als een omgekeerd ETL-doel in een op fabric gebaseerde gegevensomgeving. Het biedt architectuurrichtlijnen, operationele patronen en implementatieoverwegingen voor het verplaatsen van gecureerde gegevens uit analytische bronnen (zoals Microsoft Fabric Data Warehouse of Fabric Lakehouse) naar SQL Database in Fabric voor operationeel verbruik door toepassingen, API's en realtime-ervaringen.

Wat is omgekeerde ETL in Fabric?

Veel klanten hebben veel tijd en moeite geïnvesteerd in het maken van ETL-processen (extract, transform, load) om onbewerkte operationele gegevens te transformeren in meer verfijnde analytische gegevens die kunnen worden gebruikt voor zakelijke rapportage. Het eindresultaat van een ETL-proces is doorgaans een analytische opslag, zoals een datawarehouse of een lakehouse, waarop een rapportagelaag zoals Power BI toegang heeft. Deze architectuur biedt zakelijke gebruikers goed, maar rapportage is relatief statisch en inzichten kunnen alleen worden afgeleid door menselijke tussenkomst. Door reverse ETL te gebruiken, kunt u de getransformeerde gegevens weer in operationele systemen doorvoeren, zodat toepassingen en agents in realtime inzicht kunnen krijgen in deze geanalyseerde gegevens. Omgekeerd ETL pusht gegevens van feiten en dimensies in analytische archieven naar een ondersteunende laag waar deze toegankelijk is via eindpunten zoals GraphQL of rechtstreeks via TDS-query's (Tabular Data Stream).

Hoewel u operationele toepassingen rechtstreeks met een magazijn of lakehouse kunt verbinden, zijn deze gegevensarchieven ontworpen voor analytische workloads. Operationele gegevensarchieven, zoals SQL Database in Fabric, zijn ontworpen ter ondersteuning van transactionele query's en bieden betere prestaties en schaalbaarheid voor operationele workloads. Operationele databases bieden ook de mogelijkheid om gegevens verder te verrijken met vector embeddings en aanvullende metagegevens om vector- en hybride zoekopdrachten te vergemakkelijken, evenals retrieval-augmented generation (RAG).

In dit patroon blijft het magazijn of lakehouse het analytische systeem van record.
SQL Database in Fabric fungeert als een operationeel archief dat lage latentie, verfijnde indexering, strikte beperkingen voor gegevens en relaties en de SLA's biedt die door toepassingsteams worden verwacht.

Algemene omgekeerde ETL-doelen

Algemene omgekeerde ETL-doelen vertegenwoordigen doorgaans gecureerde, hoogwaardige gegevenssegmenten die operationele systemen kunnen gebruiken met minimale transformatie. Deze doelen zijn ontworpen om toegang met lage latentie tot vertrouwde gegevens te bieden en tegelijkertijd bedrijfslogica te behouden die in de analytische laag wordt toegepast. Voorbeelden zijn:

Klant- en gebruikersgegevens (bijvoorbeeld metrische gegevens over betrokkenheid, zoals sessieactiviteit, functiegebruik en interacties)
Verkoop- en marketinggegevens (bijvoorbeeld scoregegevens zoals propensiteit om te kopen, betrokkenheidsscores, waarschijnlijkheid om te converteren)
Operationele en transactionele gegevens (bijvoorbeeld order- en voorraadgegevens zoals voorraadniveaus, orderstatus en leveringstijdsinstellingen)
AI/ML Afgeleide gegevens (bijvoorbeeld gepersonaliseerde productaanbevelingen, voorspellende scores zoals verlooprisico of upsell-propensiteit of sentimentanalyse)

Mechanismen voor gegevensverplaatsing

Het proces begint met het definiëren van de brongegevens, het instellen van de bestemming en het selecteren van een mechanisme voor gegevensverplaatsing. Kies een of meer van de volgende mechanismen om gegevens uit uw analytische opslag te verplaatsen naar SQL Database in Fabric.

Aanbeveling

Gebruik als algemene regel:

Pijplijnen voor eenvoudige kopieën en geplande laden.
Gegevensstromen Gen2 voor transformaties met weinig code.
Spark voor complexe en grootschalige verwerking (inclusief machine learning).
Cross-item T-SQL waar beschikbaar om operaties SQL-gecentreerd te houden, bijvoorbeeld door een tabel in een SQL-database te koppelen aan een tabel in een datawarehouse of SQL-analyse-eindpunt.

Mechanisme	Gebruiken wanneer	Sterke punten	Overwegingen
Fabric-gegevenspijplijnen	U hebt beheerde, herhaalbare datalasten (batch of microbatch) voor gegevenskopie nodig.	Eersteklas integratie; ondersteunt watermerken en opgeslagen procedures	Concurrency; SQL-database schalen tijdens het laden van gegevens
Gegevensstroom Gen2	U hebt gegevenstransformaties met weinig code en verbeterde proceslogica nodig	Zakelijk vriendelijk; ondersteunt het vormgeven en opschonen van kolommen	Lagere doorvoer voor grote volumes; partitionering plannen
Spark (notebooks/jobs)	U hebt complexe transformaties op basis van code en grootschalige hervorming nodig	Volledig codebeheer; efficiënte Delta-leesbewerkingen; Ondersteuning voor JDBC-schrijfbewerkingen	Verificatie en batchverwerking; grote transacties voorkomen
T-SQL-query's voor meerdere items	Er is een SQL-beweging in de database tussen Fabric-items nodig.	Minimaal sanitair; SQL-systeemeigen; eenvoudig te plannen

Referentiearchitectuur: omgekeerde ETL naar SQL-database in Fabric

De referentiearchitectuur voor omgekeerde ETL in Fabric brengt de essentiële bouwstenen samen die nodig zijn om gecureerde analytische gegevens operationeel te maken. Het laat zien hoe gegevens stromen van vertrouwde analytische bronnen via transformatielagen naar een gestructureerde SQL-database. De operationele database fungeert als de interface voor downstreamsystemen. Dit patroon zorgt ervoor dat toepassingen, API's en rapportagehulpprogramma's toegang hebben tot gegevens met lage latentie, hoge kwaliteit zonder de integriteit van het analytische recordsysteem in gevaar te brengen.

De belangrijkste onderdelen van deze stroom zijn:

Bron: Gecureerde gegevenssets uit een Fabric Data Warehouse of Lakehouse (Delta).
Transformaties: Omgekeerde ETL-transformaties die worden toegepast met behulp van pijplijnen, Gegevensstroom Gen2, Spark of T-SQL voor meerdere items.
Doel: SQL-database in Fabric met gedefinieerde landing, geschiedenis (optioneel), quarantaine en serviceschema's.
Consumenten: Toepassingen via GraphQL of TDS, API's en Power BI voor realtime dashboards en rapportage.

Components

De volgende onderdelen zijn betrokken bij de algemene stroom voor het gebruik van SQL Database in Fabric als een omgekeerd ETL-doel.

Server- en landingsschema's

Brongegevens toewijzen aan de juiste landingsschema's in de SQL-database binnen Fabric.
U kunt desgewenst een history schema voor controlebaarheid onderhouden.
Gebruik een quarantine schema voor weigeringen (problemen met gegevenskwaliteit).
Definieer een serving schema voor downstreamverbruik met de juiste beperkingen en indexering.

Orkestratie

Plan overdrachten in Fabric met behulp van pijplijnen, gegevensstromen of Spark-taken.
Gebruik ingebouwde planning om frequentie, begintijd en tijdzone te configureren.
Gebruik de Fabric-portal of -API om Spark Notebooks te plannen.
End-to-end-uitvoeringen bewaken in de Fabric Monitoring hub.

Consumption

Gegevens beschikbaar maken via GraphQL-eindpunten of T-SQL via TDS met behulp van clientbibliotheken zoals ADO.NET (en andere).
Bouw Power BI-dashboards en -visualisaties rechtstreeks via SQL Database in Fabric.

Governance en beveiliging

Gebruik De Microsoft Entra-id voor verificatie en autorisatie.
Machtigingen voor fabric-werkruimterollen en SQL-machtigingen combineren voor gedetailleerd beheer.
Configureer desgewenst door de klant beheerde sleutels voor versleuteling van gegevens in rust.
Toegang controleren en gegevens tijdens overdracht beveiligen met behulp van Private Link.

Applicatie-servering

Zodra u gegevens in de SQL-database hebt gecureerd en vernieuwd, verplaatst u de focus naar snelle, betrouwbare toegang voor operationele gebruikers. In deze context betekent het leveren van toepassingen het beschikbaar maken van vertrouwde gegevenssets via interfaces met lage latentie die zijn afgestemd op moderne toepassingspatronen.

Nadat gegevens zijn geland en vernieuwd in SQL Database in Fabric:

Als u operationele workloads wilt leveren, maakt u gegevens beschikbaar via GraphQL-eindpunten of het TDS-protocol , die moeten worden gebruikt via ADO.NET en andere clientbibliotheken. Geef bijvoorbeeld productinformatie, supply chain of gebruiksvoorbeelden voor klantenservice op.
Koppel de gegevensset met Power BI om realtime dashboards en selfserviceanalyses te leveren.

Overwegingen voor fabric-specifieke aspecten

SQL Database in Fabric maakt gebruik van dezelfde SQL Database Engine als Azure SQL Database en wordt beheerd, beveiligd, gefactureerd en beheerd via de Fabric-portal. Het biedt ook ingebouwde spiegeling in Delta-/Parquet-bestanden die zijn opgeslagen in Microsoft OneLake, die toegankelijk zijn via een SQL-analyse-eindpunt. Aangezien deze zich in de Microsoft Fabric-omgeving bevindt, zijn er enkele overwegingen waarmee u rekening moet houden bij het maken van uw ontwerp:

Functiepariteit: SQL-database in Fabric wordt samengevoegd met Azure SQL Database. Valideer specifieke functies die u nodig hebt om ervoor te zorgen dat ze geschikt zijn voor het doel, en houd roadmapupdates in de gaten.
Beveiligingsmodel: SQL-database in Fabric maakt alleen gebruik van Microsoft Entra ID-verificatie . Plan identiteiten voor pijplijnen, gegevensstromen en Spark-taken dienovereenkomstig.
Replicatie: SQL Database in Fabric repliceert automatisch gegevens in alleen-lezen formaat naar OneLake. Deze synchronisatie is handig voor rapportage- en analysebehoeften, terwijl de database beschikbaar blijft voor operationele werkbelastingen voor lezen/schrijven.

Feedback

Is deze pagina nuttig?

Last updated on 2026-01-10