Beperkingen in Microsoft Fabric gespiegelde databases uit Snowflake

Huidige beperkingen in de Microsoft Fabric gespiegelde databases uit Snowflake worden vermeld op deze pagina. Deze pagina kan worden gewijzigd.

Beperkingen voor verbinding en verificatie

• In de volgende tabel ziet u welke verificatiemethoden worden ondersteund voor spiegeling voor Snowflake:

• Werkruimte-identiteit wordt momenteel niet ondersteund voor Snowflake-spiegeling. Deze is beschikbaar voor bepaalde bronnen, zoals SharePoint.

• Private Link connectiviteit tussen een Fabric werkruimte en Snowflake is nog niet beschikbaar. Gebruik tijdelijk een gegevensgateway voor een virtueel netwerk of een on-premises gegevensgateway voor privéverbindingen.

• U moet ontvangers voor delen aan de werkruimte toevoegen. Als u een gegevensset of rapport wilt delen, voegt u eerst access toe aan de werkruimte met een rol van beheerder, lid, lezer of inzender.

• Hoofdlettergevoeligheid: Alle Snowflake-id's, waaronder magazijnnaam, databasenaam, schemanaam, tabelnamen en weergavenamen, zijn hoofdlettergevoelig bij het configureren van mirroringverbindingen en bij het gebruik van de REST API voor spiegeling. De behuizing die u invoert in Fabric moet exact overeenkomen met wat is geconfigureerd in Snowflake. Inconsistent gebruik van hoofdletters en kleine letters kan verbindingsfouten veroorzaken of ertoe leiden dat tabellen niet verschijnen voor replicatie, vaak zonder duidelijke foutmelding. Als uw Snowflake-magazijn bijvoorbeeld de naam ANALYTICS_WH heeft, moet u ANALYTICS_WH invoeren in de Fabric-verbinding, niet analytics_wh.

Ondersteunde objecttypen

• In de volgende tabel ziet u welke Snowflake-objecttypen worden ondersteund voor spiegeling:

Beperkingen voor replicatie en gegevens

• Als er geen updates in een brontabel zijn, begint de replicator-engine zich terug te trekken met een voor die tabel exponentieel toenemende duur, tot een uur. Hetzelfde kan gebeuren als er een tijdelijke fout optreedt, waardoor het vernieuwen van gegevens wordt voorkomen. De replicator-engine hervat automatisch regelmatige polling nadat bijgewerkte gegevens zijn gedetecteerd.
• De bronschemahiërarchie wordt gerepliceerd naar de gespiegelde database. Voor gespiegelde databases die zijn gemaakt voordat deze functie is ingeschakeld, wordt het bronschema afgevlakt en wordt de schemanaam gecodeerd in de tabelnaam. Als u tabellen opnieuw wilt ordenen met schema's, maakt u de gespiegelde database opnieuw. Meer informatie van Bronschemahiërarchie repliceren.
• Spiegeling ondersteunt het repliceren van kolommen met spaties of speciale tekens in namen (zoals ,;{}()\n\t=). Voor tabellen onder replicatie voordat deze functie is ingeschakeld, moet u de gespiegelde database-instellingen bijwerken of spiegeling opnieuw starten om deze kolommen op te nemen. Meer informatie over ondersteuning van Delta-kolomtoewijzing.
• Het maximum aantal tabellen dat in Fabric kan worden gespiegeld, is 1000 tabellen. Tabellen boven de limiet van 1000 kunnen momenteel niet worden gerepliceerd.
  • Als u Alle gegevens spiegelen selecteert bij het configureren van spiegeling, worden de tabellen die moeten worden gespiegeld, bepaald door de eerste 1000 tabellen te nemen wanneer alle tabellen alfabetisch worden gesorteerd op basis van de schemanaam en vervolgens de tabelnaam. De resterende set tabellen onder aan de alfabetische lijst wordt niet gespiegeld.
  • Als u alle gegevens spiegelen uitschakelt en afzonderlijke tabellen selecteert, kunt u niet meer dan 1000 tabellen selecteren.
• Berekende kolommen en berekende tabellen: gespiegelde databases kunnen alleen worden gelezen. U kunt geen berekende kolommen of berekende tabellen rechtstreeks in een gespiegelde database maken. Als u berekende kolommen wilt toevoegen, maakt u een Lakehouse en gebruikt u snelkoppelingen om te verwijzen naar de gespiegelde gegevens en maakt u vervolgens uw berekende kolommen in Lakehouse met behulp van notebooks of SQL.

Prestatiebeperkingen

• Als u de meeste gegevens in een grote tabel wijzigt, is het efficiënter om spiegeling te stoppen en opnieuw te starten. Het invoegen of bijwerken van miljarden records kan lang duren.
• Sommige schemawijzigingen worden niet onmiddellijk doorgevoerd. Sommige schemawijzigingen hebben een gegevenswijziging nodig (invoegen, bijwerken of verwijderen) voordat schemawijzigingen worden gerepliceerd naar Fabric.
• Overwegingen voor meerdere regio's: Als uw Snowflake-exemplaar en Fabric capaciteit zich in verschillende cloudregio's bevinden, kunnen er hogere replicatielatentie en kosten voor uitgaand gegevens optreden. Implementeer uw Fabric-capaciteit in dezelfde cloudregio als uw Snowflake-exemplaar voor optimale prestaties en om uitgaande kosten tussen regio's te voorkomen. Als implementatie tussen regio's onvermijdelijk is, moet u rekening houden met de extra uitgaande kosten van Snowflake en/of Azure. Zie de documentatie voor uitgaand verkeer van Snowflake voor meer informatie.
• Bij het spiegelen van gegevens van Snowflake naar oneLake van een klant, worden gegevens doorgaans gefaseerd via een inline-URL om de prestaties te verbeteren. Als de parameter op snowflake-accountniveau PREVENT_UNLOAD_TO_INLINE_URL is ingesteld op true, is het volgende gedrag van toepassing:

Geplande oplossing: ondersteuning voor opslagintegratie is in ontwikkeling en zal een alternatief tussenpad bieden dat werkt wanneer PREVENT_UNLOAD_TO_INLINE_URL is ingesteld op true. Met deze oplossing worden VNet- en OPDG-scenario's gedeblokkeerd. Controleer deze pagina op updates over beschikbaarheid.

• Gedrag van opnieuw initialiseren: Opnieuw initialiseren is het volledig opnieuw laden van de gegevens van een volledige tabel. In tegenstelling tot incrementele synchronisatie (waarbij alleen gewijzigde rijen worden verwerkt), leest en schrijft een reseed alle gegevens in de tabel opnieuw. Reseeds kunnen aanzienlijke Snowflake-computekosten met zich meebrengen, met name voor grote tabellen.
  • Wat een reseed activeert:

• Aanbevolen procedures om onnodige nieuwe bewerkingen te voorkomen:
  • Schemawijzigingen buiten de actieve spiegeling plannen. Als u DBT of andere hulpprogramma's voor schemabeheer gebruikt, plant u deze tijdens onderhoudsvensters of onderbreekt u spiegeling voordat u schemawijzigingen uitvoert.
  • Vermijd frequente DDL-wijzigingen. Voeg schemawijzigingen samen in minder, grotere batches in plaats van incrementele wijzigingen gedurende de dag aan te brengen.
  • Controleer op onverwachte reseeds. Kijk op de pagina Status van spiegeling naar tabellen die herhaaldelijk het gedrag van de eerste kopie laten zien. Als een grote tabel om de paar minuten opnieuw wordt geseed, controleer dan of er upstream DDL-wijzigingen zijn.
  • Houd rekening met de impact op de kosten. Het opnieuw seeden van een tabel met 226 miljoen rijen (~26,5 GB) kost aanzienlijke rekentijd. Vermenigvuldig deze kosten met de frequentie van schemawijzigingen om de impact op kosten te schatten.

Beveiligingsbeperkingen

• Fabric repliceert Snowflake-beleid voor Row-Level Security (RLS) en Column-Level Security (CLS) niet. U moet gelijkwaardige beveiligingsbeleidsregels handmatig opnieuw configureren in Fabric.
• Deelnemers waarmee gedeeld moet worden, moeten aan de werkruimte worden toegevoegd. Als u een gegevensset of rapport wilt delen, voegt u eerst access toe aan de werkruimte met een rol van beheerder, lid, lezer of inzender.

Overwegingen voor kosten en facturering

Houd rekening met de volgende aanbevolen procedures om de rekenkosten van Snowflake te minimaliseren door spiegeling te voorkomen:

• Een bestaand magazijn opnieuw gebruiken. In plaats van een toegewezen magazijn te maken voor spiegeling, configureert u spiegeling om hetzelfde magazijn te gebruiken dat uw toepassingen al gebruiken om de brontabellen bij te werken. Deze aanpak voorkomt onnodige ontwaak- en automatische onderbrekingscycli van magazijnen. Wanneer uw toepassing een tabel bijwerkt, neemt de mirroring-replicator wijzigingen vrijwel onmiddellijk over terwijl het warehouse nog actief is, waardoor het niet nodig is om een afzonderlijk warehouse te activeren. Sommige organisaties geven mogelijk de voorkeur aan een toegewezen magazijn voor budgetisolatie. Deze keuze is een afweging tussen kostenbesparingen en budgetteringsgranulariteit.
• Alleen de tabellen spiegelen die u nodig hebt. Het spiegelen van een hele database kan onverwacht hoog Snowflake-verbruik en onverwacht hoge Fabric-capaciteitspieken veroorzaken. Selecteer eerst alleen de tabellen die vereist zijn voor uw analysescenario's. U kunt later zo nodig tabellen toevoegen.
• Controleer op onverwachte reseeds. Een reseed (volledig opnieuw laden van gegevens) verwerkt de volledige tabel en brengt rekenkosten met zich mee die evenredig zijn aan de tabelgrootte. Schemawijzigingen - inclusief wijzigingen die worden veroorzaakt door tools zoals DBT - kunnen doorlopende reseeds veroorzaken. Controleer de pagina Spiegelingsstatus op tabellen die herhaald initieel kopieergedrag vertonen en bekijk de sectie Opnieuw seeden voor aanleidingen en richtlijnen voor probleemoplossing.
• Houd er rekening mee dat spiegeling continu plaatsvindt. Mirroring biedt momenteel geen ondersteuning voor plannings- of replicatievensters. De replicator peilt continu naar wijzigingen, waardoor doorlopend snowflake-rekengebruik wordt gegenereerd. Plan uw Snowflake-budgetten dienovereenkomstig.

Ondersteunde regio's

Databasespiegeling en open spiegeling zijn beschikbaar in alle Microsoft Fabric regio's. Zie Beschikbaarheid van Fabric-regio voor meer informatie.

Verwante inhoud

• Wat is spiegelen in Stof?
• Spiegelen van Snowflake
• Tutorial: Microsoft Fabric gespiegelde databases configureren vanuit Snowflake