Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Nuværende begrænsninger i Microsoft Fabric-spejlede databaser fra Snowflake er listet på denne side. Denne side kan ændres.
Forbindelses- og autentificeringsbegrænsninger
- Følgende tabel viser, hvilke autentificeringsmetoder der understøttes til spejling for Snowflake:
| Godkendelsesmetode | Understøttet | Bemærkninger |
|---|---|---|
| Brugernavn og din adgangskode. | Ja | Snowflake native autentificering |
| Microsoft Entra ID (SSO) | Ja | Single sign-on via Entra ID |
| Nøgleparautentificering | Ja | RSA-nøglepar til servicekontoscenarier |
| Arbejdsområdeidentitet | Nej | Ikke i øjeblikket understøttet for Snowflake |
Workspace identity understøttes ikke i øjeblikket for Snowflake-spejling. Den er tilgængelig for udvalgte kilder som SharePoint.
Private Link-forbindelse mellem et Fabric-arbejdsområde og Snowflake er endnu ikke tilgængelig. Brug en virtuel netværksdatagateway eller en lokal datagateway til privat forbindelse i mellemtiden.
Du skal tilføje delingsmodtagere til arbejdsområdet. For at dele et datasæt eller en rapport, tilføj først access til arbejdsområdet med rollen som administrator, medlem, læser eller bidragyder.
Kasusfølsomhed: Alle Snowflake-identikodere – inklusive lagernavn, databasenavn, skemanavn, tabelnavne og visningsnavne – er små og små bogstavsfølsomme ved konfiguration af spejlingsforbindelser og ved brug af spejlings-REST API'en. Det kabinet, du indsætter i Fabric, skal matche præcis det, der er konfigureret i Snowflake. Mismatched casing kan forårsage forbindelsesfejl eller tabeller, der ikke vises til replikering, ofte uden nogen beskrivende fejlmeddelelse. For eksempel, hvis dit Snowflake-lager hedder ANALYTICS_WH, skal du indtaste ANALYTICS_WH i Fabric-forbindelsen, ikke analytics_wh.
Understøttede objekttyper
- Følgende tabel viser, hvilke Snowflake-objekttyper der understøttes til spejling:
| Objekttype | Understøttet | Bemærkninger |
|---|---|---|
| Administrerede tabeller | Ja | Fuldt understøttet til replikering |
| Isbjergtabeller | Ja | Kræver en lagringsforbindelse til den underliggende Iceberg Table Storage. Kun Iceberg-tabeller, der kan nås via samme lagringsforbindelse, kan spejles sammen. |
| Views | Ja | Understøttet med synkroniseringer hver 12. time |
| Materialiserede visninger | Ja | Understøttet med synkroniseringer hver 12. time |
| Udvendige tabeller | Nej | Ikke understøttet |
| Transienttabeller | Nej | Ikke understøttet |
| Midlertidige tabeller | Nej | Ikke understøttet |
| Dynamiske tabeller | Nej | Ikke understøttet |
Replikations- og databegrænsninger
- Hvis der ikke er nogen opdateringer i en kildetabel, begynder replikatorprogrammet at trække sig tilbage med en eksponentielt stigende varighed for den pågældende tabel, op til en time. Det samme kan ske, hvis der er en midlertidig fejl, der forhindrer dataopdatering. Replikatorprogrammet genoptager automatisk regelmæssig polling, når opdaterede data er registreret.
- Kildeskemahierarkiet replikeres til den spejlede database. For spejlede databaser, der er oprettet før denne funktion aktiveret, er kildeskemaet fladt, og skemanavnet kodes til tabelnavnet. Hvis du vil omorganisere tabeller med skemaer, skal du genoprette den spejlede database. Få mere at vide fra Repliker kildeskemahierarki.
- Spejling understøtter replikering af kolonner, der indeholder mellemrum eller specialtegn i navne (f.eks.
,;{}()\n\t=). I forbindelse med tabeller under replikering, før denne funktion er aktiveret, skal du opdatere indstillingerne for den spejlede database eller genstarte spejlingen for at inkludere disse kolonner. Få mere at vide fra understøttelse af deltakolonnetilknytning. - Det maksimale antal borde, der kan spejles i Fabric, er 1.000 borde. Enhver tabel over 1000-grænsen kan i øjeblikket ikke replikeres.
- Hvis du vælger Spejl alle data, når du konfigurerer Spejling, vil de tabeller, der skal spejles over, blive bestemt ved at tage de første 1.000 tabeller, når alle tabeller sorteres alfabetisk baseret på skemanavnet og derefter tabelnavnet. Det resterende sæt tabeller nederst på den alfabetiske liste vil ikke blive spejlet over.
- Hvis du fravælger Spejl alle data og vælger individuelle tabeller, kan du ikke vælge mere end 1.000 tabeller.
- Beregnede kolonner og beregnede tabeller: Spejlede databaser er skrivebeskyttede. Du kan ikke oprette beregnede kolonner eller beregnede tabeller direkte på en spejlet database. For at tilføje beregnede kolonner skal du oprette en Lakehouse og bruge genveje til at referere til de spejlede data, og derefter oprette dine beregnede kolonner i Lakehouse ved hjælp af notesbøger eller SQL.
Begrænsninger i ydeevnen
- Hvis du ændrer det meste af dataene i en stor tabel, er det mere effektivt at stoppe og genstarte spejlingen. Indsættelse eller opdatering af milliarder af poster kan tage lang tid.
- Nogle skemaændringer afspejles ikke med det samme. Nogle skemaændringer kræver en dataændring (indsætt, opdatering eller sletning), før skemaændringer replikeres til Fabric.
- Tværregionale overvejelser: Hvis din Snowflake-instans og Fabric-kapacitet er placeret i forskellige cloud-områder, kan du opleve højere replikationsforsinkelse og dataudgangsgebyrer. For optimal ydeevne og for at undgå tværregionale egressomkostninger, deploy din Fabric-kapacitet i samme cloud-region som din Snowflake-instans. Hvis tværregional implementering er uundgåelig, skal du tage højde for de ekstra egressgebyrer fra Snowflake og/eller Azure. Se dokumentationen for Snowflake-egress for detaljer.
- Når data fra Snowflake spejles til en kundes OneLake, faser processen normalt data via en indbygget URL for at forbedre ydeevnen. Hvis Snowflake-kontoniveauparameteren PREVENT_UNLOAD_TO_INLINE_URL sættes til true, gælder følgende adfærd:
| Forbindelsesmetode | Påvirkning når PREVENT_UNLOAD_TO_INLINE_URL = sandt |
|---|---|
| Direct (offentligt endepunkt) | Spejling falder tilbage på direkte læsning fra Snowflake. Denne fallback resulterer i langsommere replikationstider og øget risiko for forbindelsesafbrydelser, især for store datasæt. |
| virtuelt netværk (VNet) datagateway | Spejling er fuldstændig blokeret. VNet gateway-scenarier kan ikke bruge direkte læsning og kræver den indbyggede URL-stagingsti. |
| On-premises datagateway (OPDG) | Spejling er fuldstændig blokeret. OPDG-scenarier kan ikke bruge direkte læsning og kræver den indbyggede URL-staging-sti. |
Planlagt løsning: Storage-integrationsstøtte er under udvikling og vil give en alternativ staging-sti, der virker, når PREVENT_UNLOAD_TO_INLINE_URL sættes til true. Denne løsning åbner VNet- og OPDG-scenarier. Tjek denne side for opdateringer om tilgængelighed.
-
Gensåningsadfærd: En resed er en fuld dataindlæsning af en hel tabel. I modsætning til inkrementel synkronisering (som kun behandler ændrede rækker), genlæser og omskriver en re-ed alle data i tabellen. Gensåning kan medføre betydelige Snowflake-beregningsomkostninger, især for store borde.
- Hvad udløser en gensåning:
| Udløser | Beskrivelse |
|---|---|
| DDL-ændringer | Enhver DDL-ændring, der ændrer DDL-tidsstemplet for en tabel, udløser en reseed. Denne trigger inkluderer ALTER TABLE-sætninger, der tilføjer, fjerner eller omdøber kolonner, ændrer datatyper eller ændrer tabellens egenskaber. |
| Værktøjer til skemamodifikation (for eksempel DBT) | Hvis et værktøj som DBT ændrer tabeldefinitioner på en tilbagevendende tidsplan (for eksempel via dbt-kørsel, der fjerner og genskaber tabeller), udløser hver ændring en reseed. At køre disse værktøjer ofte (for eksempel hvert par minutter) kan forårsage kontinuerlige genseeding-loops. |
| Stop og genstart af spejling | Hver gang du stopper og genstarter spejlingen, hentes hele tabellen fra bunden. |
| Udvidet kapacitetspause | Hvis en Fabric-kapacitet er sat på pause i længere tid, kan spejling genopsættes fra starten. Se Ændringer i Fabric-kapacitet. |
- Bedste praksis for at undgå unødvendige gensåninger:
- Planlæg skemaændringer uden for aktiv spejling. Hvis du bruger DBT eller andre skemastyringsværktøjer, så planlæg dem under vedligeholdelsesvinduer eller paus spejling, før du kører skemaændringer.
- Undgå hyppige DDL-ændringer. Konsolider skemaændringer i færre og større partier i stedet for at lave inkrementelle ændringer i løbet af dagen.
- Hold øje med uventede gensåninger. På siden Mirroring Status skal du holde øje med tabeller, der gentagne gange viser initial copy-adfærd. Hvis en stor tabel genseedes hvert par minutter, så tjek for ændringer i DDL opstrøms.
- Vær opmærksom på omkostningspåvirkningen. En genopsætning af en tabel med 226 millioner rækker (~26,5 GB) kræver betydelig beregningstid. Gang denne omkostning med hyppigheden af skemaændringer for at estimere omkostningspåvirkningen.
Sikkerhedsmæssige begrænsninger
- Fabric replikerer ikke Snowflake Row-Level Security (RLS) og Column-Level Security (CLS) politikker. Du skal manuelt omkonfigurere tilsvarende sikkerhedspolitikker i Fabric.
- Delingsmodtagere skal føjes til arbejdsområdet. For at dele et datasæt eller en rapport, tilføj først access til arbejdsområdet med rollen som administrator, medlem, læser eller bidragyder.
Omkostnings- og faktureringsovervejelser
For at minimere Snowflake-beregningsomkostninger ved spejling, overvej følgende bedste praksis:
- Genanvend et eksisterende lager. I stedet for at oprette et dedikeret warehouse til mirroring, kan du konfigurere mirroring til at bruge det samme warehouse, som dine applikationer allerede bruger, til at opdatere kildetabellerne. Denne tilgang undgår unødvendig lageropvågning og automatisk suspenderingscyklusser. Når din applikation opdaterer en tabel, registrerer mirroring-replikatoren ændringer næsten med det samme, mens lageret stadig er aktivt, hvilket eliminerer behovet for at vække et separat lager. Nogle organisationer foretrækker måske et dedikeret lager til budgetisolering. Dette valg er en afvejning mellem omkostningsbesparelser og budgettering.
- Spejl kun de tabeller, du har brug for. Spejling af en hel database kan forårsage uventet højt forbrug af Snowflake og spidser i Fabric-kapaciteten. Start med kun at vælge de tabeller, der kræves til dine analysescenarier. Du kan tilføje tabeller senere efter behov.
- Hold øje med uventede gensåninger. En resed (fuld dataindlæsning) behandler hele tabellen og pådrager sig en beregningsomkostning proportional med tabellens størrelse. Skemaændringer – inklusive dem, der udløses af værktøjer som DBT – kan forårsage kontinuerlige genseeds. Overvåg siden Mirroring Status for tabeller, der viser gentagen initial copy-adfærd, og gennemgå Reseeding-sektionen for triggere og fejlfindingsvejledning.
- Vær opmærksom på, at mirroring kører kontinuerligt. Spejling understøtter i øjeblikket ikke planlægnings- eller replikationsvinduer. Replikatoren spørger løbende efter ændringer, hvilket genererer løbende Snowflake-beregningsforbrug. Planlæg dine Snowflake-budgetter derefter.
Understøttede regioner
Databasespejling og åben spejling er tilgængelige i alle Microsoft Fabric-regioner. Du kan få flere oplysninger under Tilgængelighed af fabric-område.