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.
Nåværende begrensninger i Microsoft Fabric-speildatabasene fra Snowflake er listet opp på denne siden. Denne siden kan endres.
Tilkoblings- og autentiseringsbegrensninger
- 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 |
Workspace-identitet støttes for øyeblikket ikke for Snowflake-speiling. Den er tilgjengelig for utvalgte kilder som SharePoint.
Private Link-tilkobling mellom et Fabric-arbeidsområde og Snowflake er ennå ikke tilgjengelig. Bruk en virtuell nettverksdatagateway eller lokal datagateway for privat tilkobling i mellomtiden.
Du må legge til delingsmottakere i arbeidsområdet. For å dele et datasett eller en rapport, legg først til access i arbeidsområdet med rollen som administrator, medlem, leser eller bidragsyter.
Kasusfølsomhet: Alle Snowflake-identifikatorer – inkludert lagernavn, databasenavn, skjemanavn, tabellnavn og visningsnavn – er små og små bokstaver ved konfigurasjon av speilingsforbindelser og ved bruk av speilings-API-et. Dekselet du legger inn i Fabric må matche nøyaktig det som er konfigurert i Snowflake. Mismatchet kabinett kan føre til tilkoblingsfeil eller tabeller som ikke vises for replikering, ofte uten noen beskrivende feilmelding. For eksempel, hvis Snowflake-lageret ditt heter ANALYTICS_WH, må du legge inn ANALYTICS_WH i Fabric-tilkoblingen, ikke analytics_wh.
Støttede 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. Kun Iceberg-tabeller som kan nås via samme lagringstilkobling kan speiles sammen. |
| 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 |
Replikasjons- og databegrensninger
- Hvis det ikke er noen oppdateringer i en kildetabell, begynner replikatormotoren å gå tilbake med en eksponentielt økende varighet for tabellen, opptil en time. Det samme kan skje hvis det oppstår en midlertidig feil som hindrer dataoppdatering. Replikatormotoren vil automatisk gjenoppta vanlig avspørring etter at oppdaterte data er oppdaget.
- Kildeskjemahierarkiet replikeres til den speilvendte databasen. For speilede databaser som er opprettet før denne funksjonen er aktivert, blir kildeskjemaet flatet ut, og skjemanavnet kodes til tabellnavnet. Hvis du vil omorganisere tabeller med skjemaer, oppretter du den speilede databasen på nytt. Lær mer fra .
- Speiling støtter replisering av kolonner som inneholder mellomrom eller spesialtegn i navn (for eksempel
,;{}()\n\t=). For tabeller under replikering før denne funksjonen er aktivert, må du oppdatere speilede databaseinnstillinger eller starte speiling på nytt for å inkludere disse kolonnene. Finn ut mer fra støtte for deltakolonnetilordning. - Maksimalt antall tabeller som kan speiles inn i Fabric er 1 000 tabeller. Tabeller over 1000-grensen kan for øyeblikket ikke replikeres.
- Hvis du velger Speil all data når du konfigurerer Speiling, vil tabellene som skal speiles over bestemmes ved å ta de første 1 000 tabellene når alle tabellene sorteres alfabetisk basert på skjemanavnet og deretter tabellnavnet. Det gjenværende settet med tabeller nederst i den alfabetiske listen vil ikke bli speilet over.
- Hvis du fjerner markeringen Speil all data og velger individuelle tabeller, blir du forhindret fra å velge mer enn 1 000 tabeller.
- Kalkulerte kolonner og beregnede tabeller: Speilede databaser er skrivebeskyttet. Du kan ikke lage beregnede kolonner eller beregnede tabeller direkte på en speilet database. For å legge til beregnede kolonner, lag et Lakehouse og bruk snarveier for å referere til de speilede dataene, og lag deretter dine beregnede kolonner i Lakehouse ved hjelp av notatbøker eller SQL.
Begrensninger i ytelse
- Hvis du endrer mesteparten av dataene i en stor tabell, er det mer effektivt å stoppe og starte speiling på nytt. Det kan ta lang tid å sette inn eller oppdatere milliarder av poster.
- Noen skjemaendringer gjenspeiles ikke umiddelbart. Noen skjemaendringer krever en dataendring (sett inn, oppdater eller slett) før skjemaendringer kan replikeres til Fabric.
- Tverrregionhensyn: Hvis din Snowflake-instans og Fabric-kapasitet er i forskjellige skyområder, kan du oppleve høyere replikasjonsforsinkelse og datautgangskostnader. For optimal ytelse og for å unngå kostnader på tvers av regioner, distribuer Fabric-kapasiteten din i samme skyregion som din Snowflake-instans. Hvis distribusjon på tvers av regioner er uunngåelig, ta med de ekstra utgangsgebyrene fra Snowflake og/eller Azure. Se Snowflake-egress-dokumentasjonen for detaljer.
- Når data fra Snowflake speiles til en kundes OneLake, faser prosessen vanligvis data via en innebygd URL for å forbedre ytelsen. Hvis Snowflake-kontonivåparameteren PREVENT_UNLOAD_TO_INLINE_URL settes til true, gjelder følgende oppførsel:
| Tilkoblingsmetode | Innvirkning når PREVENT_UNLOAD_TO_INLINE_URL = sant |
|---|---|
| Direct (offentlig endepunkt) | Speiling faller tilbake til direkte lesing fra Snowflake. Denne fallbacken fører til tregere replikasjonstider og økt risiko for tilkoblingstidsavbrudd, spesielt for store datasett. |
| virtuelt nettverk (VNet) datagateway | Speiling er helt blokkert. VNet-gateway-scenarier kan ikke bruke direkte lesing og krever den innebygde URL-staging-stien. |
| Lokal datagateway (OPDG) | Speiling er helt blokkert. OPDG-scenarier kan ikke bruke direkte lesing og krever den innebygde URL-staging-stien. |
Planlagt løsning: Støtte for lagringsintegrasjon er under utvikling og vil gi en alternativ staging-vei som fungerer når PREVENT_UNLOAD_TO_INLINE_URL settes til true. Denne løsningen fjerner blokkeringen av VNet- og OPDG-scenarier. Sjekk denne siden for oppdateringer om tilgjengelighet.
-
Omsåingsatferd: En resed er en full datainnlasting av en hel tabell. I motsetning til inkrementell synkronisering (som kun behandler endrede rader), leser og skriver en Reseed alle data i tabellen på nytt. Reseeding kan medføre betydelige Snowflake-beregningskostnader, spesielt for store bord.
- Hva som utløser en ny såing:
| Utløser | Beskrivelse |
|---|---|
| DDL-endringer | Enhver DDL-endring som endrer DDL-tidsstempelet til en tabell utløser en ny seeding. Denne utløseren inkluderer ALTER TABLE-setninger som legger til, fjerner eller omdøper kolonner, endrer datatyper eller endrer tabellegenskaper. |
| Verktøy for skjemamodifikasjon (for eksempel DBT) | Hvis et verktøy som DBT endrer tabelldefinisjoner på en gjentakende tidsplan (for eksempel via dbt-kjøring som dropper og gjenoppretter tabeller), utløser hver endring en reseed. Å kjøre disse verktøyene ofte (for eksempel hvert par minutter) kan føre til kontinuerlige omseedingsløkker. |
| Stoppe og starte speiling på nytt | Hver gang du stopper og starter speilingen på nytt, hentes hele tabellen fra bunnen av. |
| Utvidet kapasitetspause | Hvis en Fabric-kapasitet er pauset over lengre tid, kan speiling starte fra starten når den gjenopptas. Se Endringer i Fabric-kapasitet. |
- Beste praksis for å unngå unødvendige nysåinger:
- Planlegg skjemaendringer utenfor aktiv speiling. Hvis du bruker DBT eller andre verktøy for skjemahåndtering, planlegg dem under vedlikeholdsvinduer eller pause speiling før du kjører skjemaendringer.
- Unngå hyppige DDL-modifikasjoner. Konsolider skjemaendringer til færre, større batcher i stedet for å gjøre inkrementelle endringer gjennom dagen.
- Følg med på uventede gjensåinger. På siden Speilstatus, se etter tabeller som gjentatte ganger viser oppførsel ved første kopiering. Hvis en stor tabell sås på nytt hvert par minutter, sjekk etter endringer i DDL oppstrøms.
- Vær oppmerksom på kostnadspåvirkningen. En omlegging av en tabell med 226 millioner rader (~26,5 GB) krever betydelig beregningstid. Multipliser denne kostnaden med hyppigheten av skjemaendringer for å estimere kostnadspåvirkningen.
Sikkerhetsbegrensninger
- Fabric replikerer ikke Snowflake Row-Level Security (RLS) og Column-Level Security (CLS)-policyer. Du må manuelt rekonfigurere tilsvarende sikkerhetspolicyer i Fabric.
- Delingsmottakere må legges til i arbeidsområdet. For å dele et datasett eller en rapport, legg først til access i arbeidsområdet med rollen som administrator, medlem, leser eller bidragsyter.
Kostnads- og faktureringshensyn
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, noe som eliminerer behovet for å vekke et separat lager. Noen organisasjoner foretrekker kanskje et dedikert lager for budsjettisolering. Dette valget 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 omplanting 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.
Støttede regioner
Databasespeiling og åpen speiling er tilgjengelig i alle Microsoft Fabric-regioner. Hvis du vil ha mer informasjon, kan du se Tilgjengelighet for stoffområde.