Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Gjelder for:✅SQL-database i Microsoft Fabric
Denne artikkelen skisserer hvordan man implementerer et operasjonelt datalager (ODS) ved bruk av SQL-database i Fabric. Den gir arkitektonisk veiledning, designmønstre, arbeidsbelastningskarakteristika og Fabric-spesifikke hensyn for å bygge en sikker, effektiv og styrt ODS.
Hva er en ODS?
Et operasjonelt datalager (ODS) er et emneorientert, integrert og nær-sanntids lager som konsoliderer data fra flere operative systemer i en lett kuratert, normalisert modell – vanligvis i normaliserte skjemaer. Den støtter operasjonell rapportering, lettvektsanalyse, API-servering og nedstrøms utbredelse til analytiske lag som Fabric Warehouse eller Fabric Lakehouse.
En ODS er ikke et kildebasert online transaksjonsbehandlingssystem (OLTP) eller et dimensjonalt lager.
I stedet fungerer den som den «varme, harmoniserte sannheten» de siste N minuttene, timene eller dagene, sittende mellom kildesystemer og analytiske plattformer.
Nøkkelegenskaper ved en ODS
Et operasjonelt datalager (ODS) i Microsoft Fabric er designet for å levere en nær sanntidsoversikt over driftsdata med sterke styrings- og ytelsesgarantier.
- Den tar inn data fra flere kildesystemer, med lav ventetid.
- Skjemaet normaliseres vanligvis i tredje normalform (3NF) for å støtte fleksibilitet og sporbarhet.
- Datakvalitet håndheves gjennom deduplisering, identitetsløsning og håndtering av sent ankomne eller mykt slettede poster, noe som skaper et pålitelig grunnlag for operasjonell rapportering og nedstrøms analyse.
- Serveringsmønstre inkluderer SQL-baserte spørringer, operasjonelle dashbord, varsler og API-er, mens Fabric-styringsfunksjoner sikrer samsvar og sikkerhet gjennom hele datalivssyklusen.
SQL-database i Fabric fungerer som en sikker og effektiv kanal mellom operasjonelle data og analytiske plattformer.
Komponenter
Følgende komponenter er involvert i bruken av SQL-database i Fabric som et operativt datalager:
- Begrensninger og nøkler: Håndhev forretningslogikk og referanseintegritet (naturlige nøkler, surrogatnøkler, fremmednøkler).
- Identitetsoppløsning: Dedupliser på tvers av kilder; Bruk overlevelsesreglene.
- Servering: Eksponer GraphQL-endepunkter og/eller bygger Power BI-dashbord.
Beste praksis for inntak og arbeidsbelastning
Å bygge en ODS på SQL-database i Fabric krever inntaksstrategier som balanserer friskhet, pålitelighet og ytelse.
- Batch- og inkrementelle laster orkestreres vanligvis gjennom Fabric Data Pipelines ved bruk av endringsdatafangst-aktiverte koblinger, med vannmerking og retry-logikk for å sikre konsistens.
- Juster pipeline-samtidighet slik at SQL-databasen kan skalere under toppbelastninger, samtidig som servicenivåets mål for dataferskhet oppnås.
- Vannmerking er et viktig konsept i inkrementelle kopieringsprosesser. Det hjelper deg enkelt å identifisere hvor en inkrementell belastning sist stoppet.
- Utfør tunge transformasjoner oppstrøms i Dataflow Gen2 eller Spark Notebooks. Reserver SQL-laget for siste
MERGEoperasjoner som håndhever begrensninger og opprettholder OLTP-lignende ytelse. - Bruk idempotente designmønstre som kombinerer endringsdeteksjon, vannmerking, T-SQL MERGE og kontrolltabeller for trygge omstarter og operasjonell robusthet.
Motor og miljø
SQL-databasen i Fabric er basert på samme SQL Database Engine som Azure SQL Database, og gir en kjent T-SQL-opplevelse med full kompatibilitet for standard klientverktøy.
Ved å bruke SQL-database i Microsoft Fabric, kan du lage ende-til-ende-arbeidsflyter fra inntak til analyse ved å bruke andre funksjoner i Microsoft Fabric:
- Datasamlebånd
- Dataflyt gen2
- Notebooks
- Real-Time intelligence
- Power BI
- Alt med strømlinjeformet DevOps ved bruk av Git-basert CI/CD