Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Gäller för:✅SQL-databas i Microsoft Fabric
Den här artikeln beskriver hur du använder SQL-databasen i Fabric som ett omvänt ETL-mål inom en Fabric-baserad datainfrastruktur. Det ger arkitekturvägledning, driftmönster och implementeringsöverväganden för att flytta kurerade data från analyskällor (till exempel Microsoft Fabric Data Warehouse eller Fabric Lakehouse) till SQL-databasen i Fabric för användning av program, API:er och realtidsupplevelser.
Vad är omvänd ETL i Fabric?
Många kunder har investerat betydande tid och arbete med att skapa ETL-processer (extract, transform, load) för att omvandla rådata till mer raffinerade analysdata som kan användas för affärsrapportering. Slutresultatet av en ETL-process är vanligtvis ett analysarkiv, såsom ett warehouse eller lakehouse som ett rapporteringsverktyg som Power BI får tillgång till. Den här arkitekturen fungerar bra för företagsanvändare, men rapporteringen är relativt statisk och insikter kan bara härledas genom mänsklig inblandning. Genom att använda omvänd ETL kan du mata tillbaka omvandlade data till driftsystem så att program och agenter kan få insikter från dessa analyserade data i realtid. Omvänd ETL överför data från fakta och dimensioner i analyslager till ett betjänande lager där de kan nås via slutpunkter som GraphQL eller direkt via TDS-frågor (Tabular Data Stream).
Du kan ansluta operativa program direkt till ett lager eller lakehouse, men dessa datalager är utformade för analytiska arbetsbelastningar. Driftdatalager, till exempel SQL Database i Fabric, är utformade för att stödja transaktionsfrågor och ger bättre prestanda och skalbarhet för driftsarbetsbelastningar. Driftdatabaser ger dig också möjlighet att ytterligare berika data med vektorinbäddningar och ytterligare metadata för att underlätta vektor- och hybridsökning samt hämtningsförhöjd generering (RAG).
- I det här mönstret förblir lagret eller lakehouse det analytiska systemet för arkivhandling.
- SQL-databasen i Fabric fungerar som ett driftlager som erbjuder låg svarstid, förfinad indexering, strikta data- och relationsbegränsningar och de serviceavtal som förväntas av programteamen.
Vanliga omvända ETL-mål
Vanliga omvända ETL-mål representerar vanligtvis utvalda datasektorer med högt värde som driftsystem kan använda med minimal transformering. Dessa mål är utformade för att ge åtkomst med låg latens till betrodda data samtidigt som affärslogik som tillämpas i analysskiktet bevaras. Exempel är:
- Kund- och användardata (till exempel engagemangsmått som sessionsaktivitet, funktionsanvändning och interaktioner)
- Försäljnings- och marknadsföringsdata (till exempel bedömningsmått som benägenhet att köpa, engagemangspoäng, sannolikhet att konvertera)
- Drift- och transaktionsdata (till exempel order- och inventeringsdata som lagernivåer, orderstatus och leveranstider)
- AI-/ML-härledda data (till exempel anpassade produktrekommendationer, förutsägelsepoäng som omsättningsrisk eller säljeffektivitet eller attitydanalys)
Dataförflyttningsmekanismer
Processen börjar med att definiera dina källdata, ange målet och sedan välja en mekanism för dataförflyttning. Välj en eller flera av följande mekanismer för att flytta data från analysarkivet till SQL-databasen i Fabric.
Tips/Råd
Använd som en allmän regel:
- Pipelines för enkel kopiering och schemalagda inläsningar.
- Dataflöden Gen2 för omvandlingar med låg kod.
- Spark för komplex och storskalig bearbetning (inklusive maskininlärning).
- T-SQL för tvärgående objekt där det är tillgängligt för att hålla åtgärderna SQL-centrerade, till exempel genom att koppla en tabell i SQL-databasen till en tabell i ett lager eller SQL-analysslutpunkt.
| Mekanism | Använd när | Styrkor | Överväganden |
|---|---|---|---|
| Datapipelines för infrastruktur | Du behöver hanterade, repeterbara belastningar (batch- eller mikrobatch) av datakopieringsåtgärder | Förstklassig integrering; stöder vattenstämpling och lagrade procedurer | Samtidighet; skala SQL-databas under inläsningar |
| Dataflöde Gen2 | Du behöver datatransformeringar med låg kod och förbättrad processlogik | Affärsvänlig; stöder kolumnformning och rensning | Lägre genomströmning för stora volymer; planera partitionering. |
| Spark (notebook-filer/jobb) | Du behöver komplexa kodbaserade transformeringar och storskalig omformning | Fullständig kodkontroll; effektiva Delta-läsningar; JDBC-skrivstöd | Autentisering och batchbearbetning; undvika stora transaktioner |
| T-SQL-frågor mellan objekt | Du behöver SQL-rörelse mellan Fabric-komponenter i databasen | Minimal VVS; SQL-native; lätt att schemalägga |
Referensarkitektur: omvänd ETL till SQL-databas i Fabric
Referensarkitekturen för omvänd ETL i Fabric sammanför de viktiga byggstenar som krävs för att operationalisera kurerade analysdata. Den visar hur data flödar från betrodda analyskällor via transformeringslager till en strukturerad SQL-databas. Driftdatabasen fungerar som gränssnitt för underordnade system. Det här mönstret säkerställer att program, API:er och rapporteringsverktyg kan komma åt data med låg latens och hög kvalitet utan att äventyra integriteten i postens analyssystem.
Huvudkomponenterna i det här flödet är:
- Källa: Kurerade datauppsättningar från ett infrastrukturlager eller Lakehouse (Delta).
- Transformeringar: Omvända ETL-transformeringar som tillämpas med pipelines, Dataflow Gen2, Spark eller T-SQL mellan objekt.
- Mål: SQL-databas i Fabric med definierade landnings-, historik- (valfritt), karantän- och användarscheman.
- Konsumenter: Program via GraphQL eller TDS, API:er och Power BI för instrumentpaneler och rapportering i realtid.
Diagram över en omvänd ETL-referensarkitektur som involverar SQL-databas i Fabric.
Components
Följande komponenter ingår i den generella processen för att använda SQL-databas i Fabric som omvänd ETL-mål.
Serverings- och landningsscheman
- Mappa källdata till lämpliga landningsscheman i SQL Database i Fabric.
- Du kan också underhålla ett
historyschema för granskningsbarhet. - Använd ett
quarantineschema för avslag (problem med datakvalitet). - Definiera ett
servingschema för nedströmsförbrukning med lämpliga begränsningar och indexering.
Orkestrering
- Schemalägg överföringar i Fabric med hjälp av Pipelines, Dataflöden eller Spark Jobb.
- Använd inbyggd schemaläggning för att konfigurera takt, starttid och tidszon.
- Schemalägg Spark Notebooks via Fabric-portalen eller API:et.
- Övervaka end-to-end-körningar i Fabric Monitoring-hubben.
Consumption
- Exponera data via GraphQL-slutpunkter eller T-SQL via TDS med hjälp av klientbibliotek som ADO.NET (och andra).
- Skapa Power BI-instrumentpaneler och visualiseringar direkt över SQL-databasen i Fabric.
Styrning och säkerhet
- Använd Microsoft Entra-ID för autentisering och auktorisering.
- Kombinera Fabric-arbetsytebehörigheter och SQL-behörigheter för granulär kontroll.
- Du kan också konfigurera kundhanterade nycklar för kryptering av vilande data.
- Granska åtkomst och säkra data under överföring med hjälp av Private Link.
Applikationshantering
När du har kurerat och uppdaterat data i SQL-databasen skiftar du fokus till att aktivera snabb och tillförlitlig åtkomst för driftkonsumenter. I det här sammanhanget innebär programhantering att exponera betrodda datamängder via gränssnitt med låg latens som överensstämmer med moderna programmönster.
När data har landats och uppdaterats i SQL-databasen i Fabric:
- För att hantera operativa arbetsbelastningar exponerar du data via GraphQL-slutpunkter eller TDS-protokollet som ska användas via ADO.NET och andra klientbibliotek. Ange till exempel produktinformation, leveranskedja eller kundtjänstanvändningsfall.
- Koppla ihop datauppsättningen med Power BI för att leverera realtidsinstrumentpaneler och självserviceanalys.
Nätverksspecifika överväganden
SQL Database i Fabric använder samma SQL Database-motor som Azure SQL Database och styrs, skyddas, faktureras och drivs via Fabric-portalen. Det erbjuder också inbyggd spegling i Delta/Parquet-filer som lagras i Microsoft OneLake, som nås via en SQL-analysslutpunkt. Eftersom det är i Microsoft Fabric-miljön finns det några saker att tänka på när du skapar din design:
- Funktionsparitet: SQL-databasen i Fabric konvergerar med Azure SQL Database. Verifiera specifika funktioner som du behöver för att säkerställa att de passar för ändamålet och övervaka översiktsuppdateringar.
- Säkerhetsmodell: SQL-databasen i Fabric använder endast Microsoft Entra-ID-autentisering . Planera identiteter för pipelines, dataflöden och Spark-jobb i enlighet med detta.
- Replikering: SQL-databasen i Fabric replikerar automatiskt skrivskyddade data till OneLake. Den här synkroniseringen är användbar för rapporterings- och analysbehov, medan databasen fortfarande är tillgänglig för läs-/skrivåtgärder.