Begränsningar i Microsoft Fabric speglade databaser från Snowflake

Aktuella begränsningar i Microsoft Fabric speglade databaser från Snowflake visas på den här sidan. Den här sidan kan komma att ändras.

Anslutnings- och autentiseringsbegränsningar

• I följande tabell visas vilka autentiseringsmetoder som stöds för spegling för Snowflake:

• Arbetsytans identitet stöds inte för närvarande för spegling i Snowflake. Den är tillgänglig för utvalda källor, till exempel SharePoint.

• Private Link-anslutning mellan en Fabric-arbetsyta och Snowflake är ännu inte tillgänglig. Använd en virtuell nätverksdatagateway eller lokal datagateway för privat anslutning under tiden.

• Du måste lägga till delningsmottagare på arbetsytan. Om du vill dela en datauppsättning eller rapport lägger du först till access till arbetsytan med rollen administratör, medlem, läsare eller deltagare.

• Skiftlägeskänslighet: Alla Snowflake-identifierare – inklusive lagernamn, databasnamn, schemanamn, tabellnamn och visningsnamn – är skiftlägeskänsliga när du konfigurerar speglingsanslutningar och när du använder rest-API:et för spegling. Det hölje som du anger i Fabric måste matcha exakt det som har konfigurerats i Snowflake. Felmatchat hölje kan orsaka anslutningsfel eller att tabeller inte visas för replikering, ofta utan beskrivande felmeddelande. Om ditt Snowflake-lager till exempel heter ANALYTICS_WH måste du ange ANALYTICS_WH i Fabric-anslutningen, inte analytics_wh.

Objekttyper som stöds

• I följande tabell visas vilka Snowflake-objekttyper som stöds för spegling:

Replikerings- och databegränsningar

• Om det inte finns några uppdateringar i en källtabell, börjar replikatormotorn att minska sin aktivitet med exponentiellt ökande intervall för den tabellen, upp till en timme. Samma sak kan inträffa om det finns ett tillfälligt fel som förhindrar datauppdatering. Replikatormotorn återupptar automatiskt den regelbundna avsökningen när uppdaterade data har identifierats.
• Källschemahierarkin replikeras till den speglade databasen. För speglade databaser som skapats innan den här funktionen aktiveras plattas källschemat ut och schemanamnet kodas till tabellnamnet. Om du vill ordna om tabeller med scheman återskapar du den speglade databasen. Läs mer om Replikera källschemas hierarki.
• Spegling stöder replikering av kolumner som innehåller mellanslag eller specialtecken i namnen (till exempel ,;{}()\n\t=). För tabeller under replikering innan den här funktionen aktiveras måste du uppdatera de speglade databasinställningarna eller starta om speglingen för att inkludera dessa kolumner. Läs mer om stöd för deltakolumnmappning.
• Det maximala antalet tabeller som kan speglas i Fabric är 1 000 tabeller. Det går för närvarande inte att replikera tabeller över gränsen på 1 000.
  • Om du väljer Spegla alla data när du konfigurerar spegling bestäms de tabeller som ska speglas genom att ta de första 1 000 tabellerna när alla tabeller sorteras alfabetiskt baserat på schemanamnet och sedan tabellnamnet. Den återstående uppsättningen tabeller längst ned i den alfabetiska listan speglas inte över.
  • Om du avmarkerar Spegla alla data och väljer enskilda tabeller hindras du från att välja fler än 1 000 tabeller.
• Beräknade kolumner och beräknade tabeller: Speglade databaser är skrivskyddade. Du kan inte skapa beräknade kolumner eller beräknade tabeller direkt i en speglad databas. Om du vill lägga till beräknade kolumner skapar du ett Lakehouse och använder genvägar för att referera till speglade data och skapar sedan dina beräknade kolumner i Lakehouse med hjälp av notebook-filer eller SQL.

Prestandabegränsningar

• Om du ändrar de flesta data i en stor tabell är det mer effektivt att stoppa och starta om spegling. Det kan ta lång tid att infoga eller uppdatera miljarder poster.
• Vissa schemaändringar återspeglas inte omedelbart. Vissa schemaändringar behöver en dataändring (infoga, uppdatera eller ta bort) innan schemaändringar replikeras till Fabric.
• Överväganden mellan regioner: Om din Snowflake-instans och Fabric-kapacitet finns i olika molnregioner kan du få högre replikeringsfördröjning och avgifter för utgående data. För optimala prestanda och för att undvika utgående kostnader mellan regioner distribuerar du din Fabric kapacitet i samma molnregion som din Snowflake-instans. Om distribution mellan regioner är oundviklig kan du ta hänsyn till de ytterligare utgående avgifterna från Snowflake och/eller Azure. Se dokumentationen om utgående trafik i Snowflake för mer information.
• Vid spegling av data från Snowflake till en kunds OneLake, bearbetar processen normalt data via en infogad URL för att förbättra prestandan. Om parametern Snowflake-kontonivå PREVENT_UNLOAD_TO_INLINE_URL är inställd på true gäller följande beteende:

Planerad lösning: Stöd för lagringsintegrering är under utveckling och tillhandahåller en alternativ mellanlagringssökväg som fungerar när PREVENT_UNLOAD_TO_INLINE_URL är inställt på sant. Den här lösningen möjliggör VNet- och OPDG-scenarier. På den här sidan finns uppdateringar om tillgänglighet.

• Reseeding-beteende: En reseed är en fullständig ominläsning av data för en hel tabell. Till skillnad från inkrementell synkronisering (som endast bearbetar ändrade rader) läser en reseed in och skriver om all data i tabellen. Reseeds kan medföra betydande beräkningskostnader i Snowflake, särskilt för stora tabeller.
  • Vad utlöser en omsådd:

• Bästa praxis för att undvika onödiga omsådder:
  • Schemalägg schemaändringar utanför aktiv spegling. Om du använder DBT eller andra schemahanteringsverktyg kan du schemalägga dem under underhållsperioder eller pausa speglingen innan du kör schemaändringar.
  • Undvik frekventa DDL-ändringar. Konsolidera schemaändringar till färre, större batchar i stället för att göra inkrementella ändringar under dagen.
  • Övervaka oväntade omsådder. På sidan Speglingsstatus tittar du efter tabeller som upprepade gånger visar beteendet för inledande kopiering. Om en stor tabell omseedas med några minuters mellanrum bör du kontrollera om det finns DDL-ändringar uppströms.
  • Var medveten om kostnadspåverkan. En ominitiering av en tabell med 226 miljoner rader (~26,5 GB) kräver avsevärd beräkningstid. Multiplicera den här kostnaden med frekvensen för schemaändringar för att uppskatta kostnadspåverkan.

Säkerhetsbegränsningar

• Fabric replikerar inte principer för Snowflake Row-Level Security (RLS) och Column-Level Security (CLS). Du måste konfigurera om motsvarande säkerhetsprinciper manuellt i Fabric.
• Delningsmottagare måste läggas till i arbetsytan. Om du vill dela en datauppsättning eller rapport lägger du först till access till arbetsytan med rollen administratör, medlem, läsare eller deltagare.

Kostnads- och faktureringsöverväganden

Tänk på följande metodtips för att minimera Snowflake-beräkningskostnader från spegling:

• Återanvänd ett befintligt lager. I stället för att skapa ett dedikerat lager för spegling konfigurerar du speglingen så att den använder samma lager som dina program redan använder för att uppdatera källtabellerna. Den här metoden undviker onödiga cykler för uppstart av warehouse och automatisk avstängning. När programmet uppdaterar en tabell tar speglingsreplikatorn upp ändringar nästan omedelbart medan lagret fortfarande är aktivt, vilket eliminerar behovet av att aktivera ett separat lager. Vissa organisationer kanske föredrar ett dedikerat lager för budgetisolering. Det här valet är en kompromiss mellan kostnadsbesparingar och budgeteringskornighet.
• Spegla bara de tabeller du behöver. Att spegla en hel databas kan leda till oväntat hög Snowflake-förbrukning och kapacitetstoppar i Fabric. Börja med att bara välja de tabeller som krävs för dina analysscenarier. Du kan lägga till tabeller senare efter behov.
• Övervaka oväntade omsådder. En ominitiering (fullständig ominläsning av data) bearbetar hela tabellen och medför beräkningskostnader i proportion till tabellens storlek. Schemaändringar – inklusive de som utlöses av verktyg som DBT – kan orsaka kontinuerliga återställningar. Övervaka sidan Speglingsstatus för tabeller som visar upprepat beteende vid inledande kopiering och granska avsnittet Omsluta för att få vägledning om utlösare och felsökning.
• Tänk på att speglingen körs kontinuerligt. Spegling stöder för närvarande inte schemaläggning eller replikeringsfönster. Replikatorn söker kontinuerligt efter ändringar, vilket genererar löpande användning av Snowflakes beräkningsresurser. Planera dina Snowflake-budgetar i enlighet med detta.

Regioner som stöds

Databasspegling och öppen spegling är tillgängliga i alla Microsoft Fabric regioner. För mer information, se Tillgänglighet för Fabric-regioner.

Relaterat innehåll

• Vad är spegling i tyg?
• Spegling Snowflake
• Tutorial: Konfigurera Microsoft Fabric speglade databaser från Snowflake