Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Mirroring i Fabric ger en enkel upplevelse för att undvika komplex ETL (Extrahera, Transformera och Ladda) och integrera dina befintliga Snowflake-datavaruhus med resten av dina data i Microsoft Fabric. Du kan kontinuerligt replikera dina befintliga Snowflake-data direkt till Fabrics OneLake. I Fabric kan du låsa upp kraftfull business intelligence, artificiell intelligens, datateknik, datavetenskap och datadelningsscenarier.
En handledning om hur du konfigurerar Snowflake-databasen för spegling i Fabric finns i Tutorial: Konfigurera Microsoft Fabric speglade databaser från Snowflake.
Varför använda spegling i Fabric?
Med spegling i Fabric behöver du inte pussla ihop olika tjänster från flera leverantörer. I stället kan du njuta av en mycket integrerad produkt från slutpunkt till slutpunkt och lätt att använda som är utformad för att förenkla dina analysbehov och som är byggd för öppenhet och samarbete mellan Microsoft, Snowflake och 1000-tals tekniklösningar som kan läsa Delta Lake-tabellformatet med öppen källkod.
Vilka analysupplevelser är inbyggda?
Speglade databaser är ett objekt i Fabric Data Warehousing som skiljer sig från slutpunkten för lager- och SQL-analys.
Spegling skapar dessa objekt på din Fabric-arbetsyta:
- Det speglade databasobjektet. Detta möjliggör nedströmsscenarier som datateknik, datavetenskap med mera. Spegling hanterar:
- Replikering av hanterade tabell- och vydata i OneLake och konvertering till Parquet i ett analysfärdigt format.
- Replikering av metadata för Iceberg-tabeller till OneLake med hjälp av genvägar till och konvertering av den lagringsplats som innehåller dina Iceberg-tabeller. OneLake konverterar automatiskt dessa Iceberg-tabeller till Delta Lake-formaterade tabeller för användning i Fabric-arbetsbelastningar.
- En SQL-analysslutpunkt
Viktigt!
Stöd för isbergstabell: Om du väljer att spegla isbergstabeller måste du tillhandahålla en lagringsanslutning till den underliggande lagringen som innehåller isbergstabelldata. Endast Iceberg-tabeller som är åtkomliga via samma lagringsanslutning kan speglas tillsammans. Om du vill hitta lagringsplatsen för en Iceberg-tabell kör du systemfunktionen SYSTEM$GET_ICEBERG_TABLE_INFORMATION i Snowflake. Mer information finns i Självstudie: Konfigurera speglade databaser i Microsoft Fabric från Snowflake.
Varje speglad databas har en autogenererad SQL-analysslutpunkt som ger en omfattande analysupplevelse ovanpå deltatabellerna som skapats av speglingsprocessen. Användare har åtkomst till välbekanta T-SQL-kommandon som kan definiera och köra frågor mot dataobjekt men inte manipulera data från SQL-analysslutpunkten, eftersom det är en skrivskyddad kopia. Du kan utföra följande åtgärder i SQL-analysslutpunkten:
- Utforska tabellerna som refererar till data i dina Delta Lake-tabeller från Snowflake.
- Skapa inga kodfrågor och vyer och utforska data visuellt utan att skriva en kodrad.
- Utveckla SQL-vyer, infogade TVF:er (Tabellvärdesfunktioner) och lagrade procedurer för att kapsla in din semantik och affärslogik i T-SQL.
- Hantera behörigheter för objekten.
- Fråga efter data i andra lager och lakehouses på samma arbetsyta.
Förutom frågeredigeraren SQL, Det finns ett brett ekosystem med verktyg som kan köra frågor mot SQL-analysslutpunkten, inklusive SQL Server Management Studio (SSMS), MSSQL-tillägget för Visual Studio Code och till och med GitHub Copilot.
Snowflake-objekttyper som stöds
I följande tabell visas vilka Snowflake-objekttyper som stöds för spegling:
| Objekttyp | Understödd | Noteringar |
|---|---|---|
| Hanterade tabeller | Yes | Stöds fullt ut för replikering |
| Iceberg-tabeller | Yes | Kräver en lagringsanslutning till den underliggande Iceberg-tabellens lagring. Du kan bara spegla Iceberg-tabeller som är åtkomliga via samma lagringsanslutning. |
| Views | Yes | Stöds med synkroniseringar var 12:e timme |
| Materialiserade vyer | Yes | Stöds med synkroniseringar var 12:e timme |
| Externa tabeller | Nej | Stöds ej |
| Tillfälliga tabeller | Nej | Stöds ej |
| Temporära tabeller | Nej | Stöds ej |
| Dynamiska tabeller | Nej | Stöds ej |
Säkerhetsfrågor
För att aktivera Fabric-spegling behöver du användarbehörigheter för din Snowflake-databas som innehåller följande behörigheter:
CREATE STREAMSELECT tableSHOW tablesDESCRIBE tables
Mer information finns i Snowflake-dokumentationen om åtkomstkontrollbehörigheter för strömningsbord och nödvändiga behörigheter för strömmar.
Viktigt!
All detaljerad säkerhet som upprättas i snowflake-källlagret måste konfigureras på nytt i den speglade databasen i Microsoft Fabric. Mer information finns i SQL detaljerade behörigheter i Microsoft Fabric.
Autentiseringsmetoder som stöds
I följande tabell visas vilka autentiseringsmetoder som stöds för spegling för Snowflake:
| Autentiseringsmetod | Understödd | Noteringar |
|---|---|---|
| Användarnamn och lösenord | Yes | Inbyggd Snowflake-autentisering |
| Microsoft Entra ID (SSO) | Yes | Enkel inloggning via Entra ID |
| Autentisering med nyckelpar | Yes | RSA-nyckelpar för scenarier med tjänstkonton |
| Arbetsplatsidentitet | Nej | Stöds för närvarande inte för Snowflake |
Spegling av Snowflake bakom brandvägg
Kontrollera nätverkskraven för att få åtkomst till din Snowflake-datakälla. Om din Snowflake-datakälla inte är offentligt tillgänglig och finns i ett privat nätverk skapar du en virtuell nätverksdatagateway eller installerar en lokal datagateway för att spegla data. Azure Virtual Network eller gatewaydatorns nätverk måste ansluta till Snowflake-instansen via en privat slutpunkt eller tillåtas av brandväggsregeln. För att komma igång, se Handledning: Konfigurera Microsoft Fabric speglade databaser från Snowflake.
Private Link och arbetsyteidentitet:
- Private Link: Direktanslutning via Private Link mellan en Fabric-arbetsyta och Snowflake stöds ännu inte. Under tiden använder du en virtuell nätverksdatagateway eller lokal datagateway för privat anslutning.
- Arbetsyteidentitet: Identitetsautentisering för arbetsytor stöds för närvarande inte för Snowflake-spegling.
Speglad Snowflake kostnadsöverväganden
Fabric-beräkning som används för att replikera dina data till Fabric OneLake är kostnadsfri. Kostnaden för speglingslagring är kostnadsfri upp till en gräns baserat på kapacitet. Mer information finns i Cost of mirroring and Microsoft Fabric Pricing. Beräkningen för att köra frågor mot data med SQL, Power BI eller Spark debiteras med jämna mellanrum.
Fabric debiterar inte för nätverksdataavgifter vid inkommande trafik till OneLake för mirroring.
Det finns kostnader för Snowflake-beräkning och molnfrågor när data speglas: beräkning av virtuella lager och beräkning av molntjänster.
- Beräkningsavgifter för virtuella Snowflake-lager:
- Beräkningsavgifter debiteras på Snowflake-sidan om det finns dataändringar som läses i Snowflake och därmed speglas i Fabric.
- Metadatafrågor som körs i bakgrunden för att kontrollera eventuell dataändring debiteras inte för Snowflake-beräkning. Men frågor som verkligen producerar data, som en
SELECT *, kommer att aktivera Snowflake-lagret och beräkning utförs mot en kostnad.
- Beräkningsavgifter för Snowflake-tjänster:
- Även om det inte finns några beräkningsavgifter för uppgifter i bakgrunden, till exempel redigering, metadatafrågor, åtkomstkontroll, dataändringar och till och med DDL-frågor, finns det molnkostnader som är associerade med dessa frågor.
- Beroende på vilken typ av Snowflake-utgåva du har debiteras du för motsvarande krediter för eventuella kostnader för molntjänster.
I följande skärmbild kan du se beräkningskostnader för virtuellt lagerutrymme och molntjänster för den associerade Snowflake-databasen som speglas i Fabric. I det här scenariot kommer majoriteten av molntjänsternas beräkningskostnader (i gult) från dataändringsfrågor baserat på de punkter som nämnts tidigare. Beräkningsavgifterna för det virtuella lagret (i blått) kommer strikt från dataändringarna som läses från Snowflake och speglas i Fabric.
Rekommendationer för kostnadsoptimering
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 med uppvakning av warehouse och automatisk avstängning. När programmet uppdaterar en tabell tar speglingsreplikatorn upp ändringar nästan omedelbart medan lagret fortfarande är aktivt, så du behöver inte aktivera ett separat lager. Vissa organisationer kanske föredrar ett dedikerat lager för budgetisolering. Den här inställningen är en kompromiss mellan kostnadsbesparingar och budgeteringskornighet.
- Spegla bara de tabeller du behöver. Att spegla en hel databas kan orsaka oväntat hög förbrukning i Snowflake och toppar i Fabric-kapaciteten. 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 som är proportionella mot 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 nedan 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.
Mer information om Snowflake-specifika molnfrågekostnader finns i Snowflake-dokument: Förstå den totala kostnaden.