Ofte stillede spørgsmål om Mirroring Snowflake i Microsoft Fabric

For Snowflake bruger vi en landingszone til at gemme både snapshottet og ændre data til OneLake for at forbedre ydeevnen, da vi konverterer disse filer i landingszonerne til delta vertiparquet.

Administrerede tabeller, isbjergstabeller og visninger understøttes til replikation. Eksterne, transiente, midlertidige og dynamiske tabeller understøttes ikke. For isbjergstabeller kræves en lagringsforbindelse til den underliggende isbjergsbordslagring under konfigurationen. For detaljer om kendte problemer med visninger (såsom datatype-mapping), se Begrænsninger.

Vælg tandhjulet indstillinger, og vælg derefter Administrer forbindelse og gateways. Du kan også slette eksisterende forbindelser fra denne side.

Følgende autentificeringsmetoder understøttes:

• Brugernavn og adgangskode — Snowflake native autentificering
• Microsoft Entra ID (SSO) — Single sign-on via Entra ID
• Nøgleparautentificering — RSA-nøglepar til servicekontoscenarier

1. Genanvend et eksisterende lager. Konfigurer spejling til at bruge det samme Snowflake-lager, som dine applikationer allerede bruger til at opdatere kildetabellerne. Dette undgår overhead ved at vække et separat, dedikeret spejlingslager. Når din applikation opdaterer en tabel, registrerer mirroring-replikatoren ændringer næsten med det samme, mens lageret stadig er aktivt. 2. Spejl kun de tabeller, du har brug for. Undgå at spejle en hel database, når du kun har brug for et delmængde af tabeller. Storskala mirroring kan forårsage betydeligt forbrug af Snowflakes og stigninger i Fabric-kapaciteten. 3. Hold øje med uventede gensåninger. En omlægning læser hele tabellen igen og pådrager sig beregningsomkostninger proportionalt med dens størrelse. Tjek siden Mirroring Status for tabeller, der gentagne gange viser initial copy-adfærd. 4. Brug Snowflake-budgetter og kreditgrænser. Indstil Snowflake-ressourcemonitorer og budgetter til at begrænse spejlingsrelaterede beregningsomkostninger.

Fabric opkræver ikke gebyrer for indtrængen i OneLake for Mirroring.

Hvis du hoster uden for Azure, skal du se Snowflake og din clouddokumentation for at få oplysninger om udgående omkostninger. Hvis den hostes i Azure, men i et andet område end din Fabric-kapacitet, opkræves dataudgående data. Hvis det hostes i Azure i det samme område, er der ingen dataudgående data.

No. Spejling kører kontinuerligt og understøtter i øjeblikket ikke konfiguration af replikeringsplaner eller tidsbaserede vinduer. Replikatoren spørger løbende efter ændringer, hvilket genererer kontinuerlig Snowflake-beregningsbrug. Hvis du skal begrænse beregningen i visse perioder, kan du manuelt stoppe og genstarte spejlingen — men bemærk, at genstart udløser en fuld genstart af alle spejlede tabeller.

Det afhænger af størrelsen på de data, der hentes ind.

Næsten ventetid i realtid.

Ja, tabeller er alle v-sorterede deltatabeller.

Se Monitor Fabric Mirror-replikering.

Ja, vi understøtter spejling via en on-premises datagateway og via en virtuelt netværk (VNet) Data Gateway.

Dataene fra kildetabellerne initialiseres igen. Hver gang du stopper og starter, hentes hele tabellen igen.

Vi stopper spejling af den specifikke tabel og sletter den fra OneLake.

Nej, vi fjerner bare streamingtabellerne.

Ja, det kan du, men det behøver du ikke. Når dataene er i Fabric, kan de deles derfra.

Ja, bestemte tabeller kan vælges under spejlingskonfigurationen.

En reed (fuld datagenindlæsning) udløses af en af følgende:

• DDL-ændringer, der ændrer DDL-tidsstemplet for en tabel, for eksempel operationer ALTER TABLE der tilføjer eller fjerner kolonner.
• Skemamodifikationsværktøjer som dbt, der dropper og genskaber tabeller på en tidsplan.
• Stop og genstart af spejling via Fabric-portalen eller API'et.
• En udvidet kapacitetspause. Hvis Fabric-kapaciteten er sat på pause i længere tid, kan spejling genopsættes, når den genoptages.

Hvis du ser tabeller gentagne gange gå igennem initial copy (reseed) i stedet for inkrementel synkronisering:

1. Tjek for ændringer i upstream skemaet. Kontroller om et værktøj som dbt ændrer tabeldefinitioner på en tilbagevendende tidsplan. Selv mindre DDL-ændringer kan udløse en gensåning.
2. Gennemgå siden for Mirroring Status. Se efter tabeller, der viser gentagne tidsstempler for første kopi med jævne mellemrum.
3. Pause-skemaændringer under aktiv spejling. Hvis dbt-kørsler er årsagen, planlæg dem under vedligeholdelsesvinduer, eller paus spejling før du kører skemaændringer.
4. Overvåg brugen af Snowflake-lageret. Tjek Snowflake-kontoens brugsvisninger for at se, om spejlingsrelaterede forespørgsler dominerer compute.
5. Husk, at hver Resed behandler alle tabeldata og pådrager sig Snowflake-beregningsomkostninger proportionalt med tabellstørrelsen. proportional med bordstørrelsen.

No.

Nej, data er ikke faseinddelt uden for kundemiljøet, de er gemt i kundens OneLake.

Der kræves en Power BI Premium-, Fabric Capacity- eller Prøveversionskapacitet. Du kan få flere oplysninger om licenser under Microsoft Fabric-licenser.

Strukturberegning, der bruges til at replikere dine data til Fabric OneLake, er gratis. Omkostningerne til spejling-lageret er gratis op til en grænse baseret på kapacitet. Du kan få flere oplysninger under Omkostninger ved spejling og Microsoft Fabric-priser. Beregningen til forespørgsler om data ved hjælp af SQL, Power BI eller Spark faktureres til almindelige takster.

Relateret indhold

• Hvad er Spejling i Fabric?
• Oversigt over Snowflake-connector