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.
Speiling i Fabric gir en enkel opplevelse for å unngå komplisert ETL (Extract Transform Load) og integrere dine eksisterende Snowflake-lagerdata med resten av dataene dine i Microsoft Fabric. Du kan kontinuerlig replikere dine eksisterende Snowflake-data direkte til Fabrics OneLake. I Fabric kan du låse opp kraftige scenarioer for forretningsanalyse, kunstig intelligens, datateknikk, datavitenskap og datadeling.
For en veiledning om hvordan du konfigurerer din Snowflake-database for speiling i Fabric, se Tutorial: Konfigurer Microsoft Fabric speilede databaser fra Snowflake.
Hvorfor bruke speiling i stoff?
Med speiling i stoff trenger du ikke å sette sammen forskjellige tjenester fra flere leverandører. I stedet kan du glede deg over et svært integrert, ende-til-ende og brukervennlig produkt som er utformet for å forenkle analysebehovene dine, og bygget for åpenhet og samarbeid mellom Microsoft, Snowflake og 1000-vis av teknologiløsninger som kan lese Delta Lake-tabellformatet med åpen kildekode.
Hvilke analyseopplevelser er innebygd?
Speilede databaser er et element i Fabric Data Warehousing som er forskjellig fra lager - og SQL-analyseendepunktet.
Speiling oppretter disse elementene i Fabric-arbeidsområdet:
- Det speilvendte databaseelementet. Dette muliggjør nedstrømsscenarioer som datateknikk, datavitenskap og mer. Speiling fungerer:
- Replikasjon av administrerte tabell- og visningsdata inn i OneLake og konvertering til Parquet, i et analyseklart format.
- Replikasjon av metadata fra Iceberg-tabellen inn i OneLake ved hjelp av snarveier til og konvertering til lagringen som inneholder dine Iceberg-tabeller. OneLake konverterer automatisk disse Iceberg-tabellene til Delta Lake-formaterte tabeller for bruk på tvers av Fabric-arbeidsbelastninger.
- Et SQL-analyseendepunkt
Viktig!
Støtte for isfjelltabeller: Hvis du velger å speile isfjelltabeller, må du tilby en lagringsforbindelse til den underliggende lagringen som inneholder isfjelltabelldataene. Kun Iceberg-tabeller som kan nås via samme lagringstilkobling kan speiles sammen. For å finne lagringsstedet for et Iceberg-bord, kjør systemfunksjonen SYSTEM$GET_ICEBERG_TABLE_INFORMATION i Snowflake. For mer informasjon, se Veiledning: Konfigurer Microsoft Fabric speilede databaser fra Snowflake.
Hver speilede database har et automatisk generert SQL-analyseendepunkt som gir en rik analytisk opplevelse på toppen av Delta-tabellene som opprettes av speilingsprosessen. Brukere har tilgang til kjente T-SQL-kommandoer som kan definere og spørre etter dataobjekter, men ikke manipulere dataene fra SQL-analyseendepunktet, siden det er en skrivebeskyttet kopi. Du kan utføre følgende handlinger i SQL Analytics-endepunktet:
- Utforsk tabellene som refererer til data i Delta Lake-tabellene dine fra Snowflake.
- Opprett ingen kodespørringer og visninger, og utforsk data visuelt uten å skrive en kodelinje.
- Utvikle SQL-visninger, innebygde TVF-er (tabellverdifunksjoner) og lagrede prosedyrer for å innkapsle semantikken og forretningslogikken i T-SQL.
- Administrer tillatelser for objektene.
- Spør etter data i andre lagre og innsjøhus i samme arbeidsområde.
I tillegg til SQL-spørringseditoren, finnes det et bredt økosystem av verktøy som kan spørre SQL-analyseendepunktet, inkludert SQL Server Management Studio (SSMS), MSSQL-utvidelsen for Visual Studio Code, og til og med GitHub Copilot.
Støttede Snowflake-objekttyper
Tabellen nedenfor viser hvilke Snowflake-objekttyper som støttes for speiling:
| Objekttype | Støttes | Merknader |
|---|---|---|
| Administrerte tabeller | Ja | Fullt støttet for replikasjon |
| Isfjelltabeller | Ja | Krever en lagringstilkobling til det underliggende Iceberg-bordlageret. Du kan bare speile Iceberg-tabeller som er tilgjengelige via samme lagringstilkobling. |
| Views | Ja | Støttes med synkroniseringer hver 12. time |
| Materialiserte visninger | Ja | Støttes med synkroniseringer hver 12. time |
| Eksterne tabeller | Nei | Støttes ikke |
| Transienttabeller | Nei | Støttes ikke |
| Midlertidige tabeller | Nei | Støttes ikke |
| Dynamiske tabeller | Nei | Støttes ikke |
Sikkerhetshensyn
Hvis du vil aktivere Fabric Mirroring, trenger du brukertillatelser for Snowflake-databasen som inneholder følgende tillatelser:
CREATE STREAMSELECT tableSHOW tablesDESCRIBE tables
For mer informasjon, se Snowflake-dokumentasjonen om tilgangskontroll Privileges for Streaming tables og Required Permissions for Streams.
Viktig!
Enhver detaljert sikkerhet etablert i kilde-Snowflake-lageret må omkonfigureres i den speilede databasen i Microsoft Fabric. For mer informasjon, se SQL granulære tillatelser i Microsoft Fabric.
Støttede autentiseringsmetoder
Tabellen nedenfor viser hvilke autentiseringsmetoder som støttes for speiling for Snowflake:
| Godkjenningsmetode | Støttes | Merknader |
|---|---|---|
| Brukernavn og passord | Ja | Snowflake-native autentisering |
| Microsoft Entra ID (SSO) | Ja | Single sign-on via Entra ID |
| Nøkkelparautentisering | Ja | RSA-nøkkelpar for tjenestekontoscenarier |
| Arbeidsområdeidentitet | Nei | Ikke støttet for Snowflake for øyeblikket |
Speiling av snøfnugg bak brannmur
Kontroller nettverkskravene for å få tilgang til Snowflake-datakilden. Hvis Snowflake-datakilden ikke er offentlig tilgjengelig og er i et privat nettverk, oppretter du en datagateway for virtuelt nettverk eller installerer en lokal datagateway for å speile dataene. Azure Virtual Network eller gateway-maskinens nettverk må koble til Snowflake-instansen via et privat endepunkt eller være tillatt av brannmurregelen. For å komme i gang, se Tutorial: Konfigurer Microsoft Fabric speilede databaser fra Snowflake.
Private Link og arbeidsområdeidentitet:
- Private Link: Direct Private Link-tilkobling mellom et Fabric-arbeidsområde og Snowflake støttes ennå ikke. I mellomtiden bør du bruke en virtuell nettverksdatagateway eller en lokal datagateway for privat tilkobling.
- Arbeidsområdeidentitet: Arbeidsområdeidentitetsautentisering støttes for øyeblikket ikke for Snowflake-speiling.
Kostnadshensyn for speilet snøfnugg
Fabric compute som brukes til å replikere dataene dine til Fabric OneLake, er gratis. Lagringskostnaden for speiling er gratis opp til en grense basert på kapasitet. For mer informasjon, se Kostnad for speiling og Microsoft Fabric Pricing. Beregningen for å spørre data med SQL, Power BI eller Spark belastes med vanlige satser.
Fabric tar ikke betalt for inngangsgebyrer for nettverksdata i OneLake for speiling.
Det er Snowflake-databehandling og skyspørringskostnader når data speiles: databehandling i virtuelt lager og databehandling av skytjenester.
- Kostnader for databehandling av virtuelt lager for Snowflake:
- Databehandlingskostnader belastes på Snowflake-siden hvis det er dataendringer som leses i Snowflake, og som i sin tur speiles i Fabric.
- Metadataspørringer som kjøres i bakgrunnen for å se etter dataendringer, belastes ikke for Snowflake-databehandling. Spørringer som produserer data, for eksempel a
SELECT *, vil imidlertid vekke Snowflake-lageret, og databehandling vil bli belastet.
- Snowflake-tjenester beregner kostnader:
- Selv om det ikke er noen databehandlingskostnader for oppgaver bak kulissene, for eksempel redigering, metadataspørringer, tilgangskontroll, visning av dataendringer og til og med DDL-spørringer, er det skykostnader knyttet til disse spørringene.
- Avhengig av hvilken type Snowflake-utgave du har, vil du bli belastet for de tilsvarende kredittene for eventuelle skytjenestekostnader.
I skjermbildet nedenfor kan du se databehandlingskostnadene for det virtuelle lageret og skytjenester for den tilknyttede Snowflake-databasen som speiles i Fabric. I dette scenariet kommer flertallet av databehandlingskostnadene for skytjenester (i gult) fra dataendringsspørringer basert på punktene nevnt tidligere. Databehandlingskostnadene for det virtuelle lageret (i blått) kommer kun fra dataendringene som leses fra Snowflake og speiles i Fabric.
Anbefalinger for kostnadsoptimalisering
For å minimere Snowflake-beregningskostnader ved speiling, bør du vurdere følgende beste praksis:
- Gjenbruk et eksisterende lager. I stedet for å lage et dedikert lager for speiling, konfigurer speiling til å bruke det samme lageret som applikasjonene dine allerede bruker for å oppdatere kildetabellene. Denne tilnærmingen unngår unødvendig oppvåkning av lageret og automatiske suspenderingssykluser. Når applikasjonen din oppdaterer en tabell, plukker speilreplikatoren opp endringer nesten umiddelbart mens lageret fortsatt er aktivt, så du trenger ikke å vekke et separat lager. Noen organisasjoner foretrekker kanskje et dedikert lager for budsjettisolering. Denne preferansen er en avveining mellom kostnadsbesparelser og budsjettdetalj.
- Speil bare tabellene du trenger. Å speile en hel database kan føre til uventet høyt Snowflake-forbruk og økninger i Fabric-kapasiteten. Start med å velge kun tabellene som kreves for analysescenarioene dine. Du kan legge til tabeller senere etter behov.
- Følg med på uventede gjensåinger. En reseed (full data reload) behandler hele tabellen og pådrar seg beregningskostnader proporsjonal med tabellstørrelsen. Skjemaendringer – inkludert de som utløses av verktøy som DBT – kan føre til kontinuerlige nyseedinger. Overvåk siden for speilstatus for tabeller som viser gjentatte initialkopieringsoppførsel, og se gjennom delen om gjenutsetting nedenfor for triggere og feilsøkingsveiledning.
- Vær oppmerksom på at speiling kjører kontinuerlig. Speiling støtter for øyeblikket ikke planleggings- eller replikeringsvinduer. Replikatoren spør kontinuerlig etter endringer, noe som genererer løpende Snowflake-databehandling. Planlegg Snowflake-budsjettet ditt deretter.
Hvis du vil ha mer informasjon om Snowflake-spesifikke skyspørringskostnader, kan du se Snowflake-dokumenter: Forstå totalkostnadene.