Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die aktuellen Einschränkungen in den Microsoft Fabric gespiegelten Datenbanken von Snowflake werden auf dieser Seite aufgeführt. Änderungen dieser Seite sind vorbehalten.
Verbindungs- und Authentifizierungseinschränkungen
- In der folgenden Tabelle sind aufgeführt, welche Authentifizierungsmethoden für die Spiegelung für Snowflake unterstützt werden:
| Authentifizierungsmethode | Unterstützt | Hinweise |
|---|---|---|
| Benutzername und Kennwort | Yes | Snowflake native Authentifizierung |
| Microsoft Entra ID (SSO) | Yes | Einmaliges Anmelden über Entra ID |
| Authentifizierung per Schlüsselpaar | Yes | RSA-Schlüsselpaar für Dienstkontoszenarien |
| Arbeitsbereichsidentität | No | Derzeit nicht für Snowflake unterstützt |
Die Arbeitsbereichsidentität wird für die Snowflake-Spiegelung derzeit nicht unterstützt. Es steht für ausgewählte Quellen wie SharePoint zur Verfügung.
Private Link-Konnektivität zwischen einem Fabric-Arbeitsbereich und Snowflake ist noch nicht verfügbar. Verwenden Sie ein Virtuelles Netzwerkdatengateway oder ein lokales Datengateway für private Konnektivität in der Zwischenzeit.
Sie müssen dem Arbeitsbereich Freigabeempfänger hinzufügen. Um ein Dataset oder einen Bericht zu teilen, fügen Sie dem Arbeitsbereich zuerst Zugriff mit der Rolle Administrator, Mitglied, Leser oder Mitwirkender hinzu.
Groß-/Kleinschreibung: Alle Snowflake-Bezeichner – einschließlich Lagername, Datenbankname, Schemaname, Tabellennamen und Ansichtsnamen – sind bei der Konfiguration von Spiegelungsverbindungen und bei Verwendung der Spiegelungs-REST-API groß- und kleinschreibungsempfindlich. Die Groß-/Kleinschreibung, die Sie in Fabric eingeben, muss genau der in Snowflake konfigurierten entsprechen. Eine nicht übereinstimmende Groß-/Kleinschreibung kann zu Verbindungsfehlern führen oder dazu, dass Tabellen nicht für die Replikation angezeigt werden, oft ohne aussagekräftige Fehlermeldung. Wenn Ihr Snowflake-Warehouse beispielsweise ANALYTICS_WH heißt, müssen Sie in der Fabric-Verbindung ANALYTICS_WH eingeben, nicht analytics_wh.
Unterstützte Objekttypen
- In der folgenden Tabelle ist aufgeführt, welche Snowflake-Objekttypen für die Spiegelung unterstützt werden:
| Objekttyp | Unterstützt | Hinweise |
|---|---|---|
| Verwaltete Tabellen | Yes | Vollständig für die Replikation unterstützt |
| Iceberg-Tabellen | Yes | Erfordert eine Speicherverbindung zum zugrunde liegenden Iceberg-Tischspeicher. Nur Iceberg-Tabellen, die über dieselbe Speicherverbindung erreichbar sind, können zusammengespiegelt werden. |
| Views | Yes | Unterstützt mit Synchronisierungen alle 12 Stunden |
| Materialisierte Ansichten | Yes | Unterstützt mit Synchronisierungen alle 12 Stunden |
| Externe Tabellen | No | Nicht unterstützt |
| Vorübergehende Tabellen | No | Nicht unterstützt |
| Temporäre Tabellen | No | Nicht unterstützt |
| Dynamische Tabellen | No | Nicht unterstützt |
Replikations- und Datenbeschränkungen
- Wenn in einer Quelltabelle keine Aktualisierungen vorhanden sind, beginnt die Replikationsengine mit der Rücknahme und nimmt zunehmend Pausen, deren Dauer exponentiell wächst, bis zu einer Stunde. Das gleiche kann auftreten, wenn ein vorübergehender Fehler auftritt und die Datenaktualisierung verhindert wird. Das Replikatmodul setzt die regelmäßige Abfrage automatisch fort, nachdem aktualisierte Daten erkannt wurden.
- Die Hierarchie des Quellschemas wird in die gespiegelte Datenbank repliziert. Bei gespiegelten Datenbanken, die vor der Aktivierung dieses Features erstellt wurden, wird das Quellschema vereinfacht, und der Schemaname wird in den Tabellennamen codiert. Wenn Sie Tabellen mit Schemas neu organisieren möchten, erstellen Sie die gespiegelte Datenbank neu. Weitere Informationen finden Sie unter Quellschemahierarchie replizieren.
- Die Spiegelung unterstützt das Replizieren von Spalten, die Leerzeichen oder Sonderzeichen in Namen enthalten (z. B.
,;{}()\n\t=). Für Tabellen, die sich in Replikation befinden, bevor diese Funktion aktiviert wurde, müssen Sie die Einstellungen der Spiegeldatenbank aktualisieren oder das Spiegeln neu starten, um diese spezifischen Spalten einzuschließen. Erfahren Sie mehr über die Unterstützung der Delta-Spaltenzuordnung. - Die maximale Anzahl von Tabellen, die in Fabric gespiegelt werden können, beträgt 1.000 Tabellen. Alle Tabellen über dem Grenzwert von 1000 können derzeit nicht repliziert werden.
- Wenn Sie beim Konfigurieren der Spiegelung "Alle Daten spiegeln" auswählen, werden die tabellen, die gespiegelt werden sollen, bestimmt, indem die ersten 1.000 Tabellen verwendet werden, wenn alle Tabellen alphabetisch basierend auf dem Schemanamen und dann dem Tabellennamen sortiert werden. Der verbleibende Tabellensatz am unteren Ende der alphabetischen Liste wird nicht übertragen.
- Wenn Sie die Auswahl "Alle Daten spiegeln " aufheben und einzelne Tabellen auswählen, können Sie nicht mehr als 1.000 Tabellen auswählen.
- Berechnete Spalten und berechnete Tabellen: Gespiegelte Datenbanken sind schreibgeschützt. Sie können keine berechneten Spalten oder berechneten Tabellen direkt in einer gespiegelten Datenbank erstellen. Um berechnete Spalten hinzuzufügen, erstellen Sie ein Lakehouse und verwenden Sie Verknüpfungen, um auf die gespiegelten Daten zu verweisen, und erstellen Sie dann Ihre berechneten Spalten im Lakehouse mithilfe von Notizbüchern oder SQL.
Leistungsbeschränkungen
- Wenn Sie die meisten Daten in einer großen Tabelle ändern, ist es effizienter, die Spiegelung zu beenden und neu zu starten. Das Einfügen oder Aktualisieren von Milliarden von Datensätzen kann eine lange Zeit dauern.
- Einige Schemaänderungen werden nicht sofort wiedergegeben. Einige Schemaänderungen benötigen eine Datenänderung (Einfügen, Aktualisieren oder Löschen), bevor Schemaänderungen in Fabric repliziert werden.
- Überlegungen zu regionenübergreifenden Aspekten: Wenn sich Ihre Snowflake-Instanz und Fabric Kapazität in verschiedenen Cloudregionen befinden, treten möglicherweise höhere Replikationslatenz und Datenausgangsgebühren auf. Um optimale Leistung zu erzielen und regionsübergreifende Ausgangskosten zu vermeiden, stellen Sie Ihre Fabric Kapazität in derselben Cloudregion wie Ihre Snowflake-Instanz bereit. Wenn die standortübergreifende Bereitstellung unvermeidbar ist, berücksichtigen Sie die zusätzlichen Ausgangsgebühren von Snowflake und/oder Azure. Ausführliche Informationen finden Sie in der Snowflake-Egress-Dokumentation.
- Beim Spiegeln von Daten aus Snowflake in das OneLake eines Kunden werden die Daten normalerweise über eine Inline-URL zwischengespeichert, um die Leistung zu verbessern. Wenn der Snowflake-Parameter auf Kontoebene PREVENT_UNLOAD_TO_INLINE_URL auf "true" festgelegt ist, gilt das folgende Verhalten:
| Konnektivitätsmethode | Auswirkung, wenn PREVENT_UNLOAD_TO_INLINE_URL = true |
|---|---|
| Direkt (öffentlicher Endpunkt) | Mirroring greift auf direktes Auslesen aus Snowflake zurück. Dieser Fallback führt zu langsameren Replikationszeiten und einem erhöhten Risiko von Verbindungstimeouts, insbesondere für große Datasets. |
| Virtual Network (VNet)-Datengateway | Die Spiegelung ist vollständig blockiert. VNet-Gatewayszenarien unterstützen kein direktes Lesen und erfordern den Inline-URL-Stagingpfad. |
| Lokales Datengateway (OPDG) | Die Spiegelung ist vollständig blockiert. OPDG-Szenarien können keinen direkten Lesezugriff verwenden und erfordern den Inline-URL-Staging-Pfad. |
Geplante Lösung: Die Unterstützung für die Speicherintegration befindet sich in der Entwicklung und stellt einen alternativen Stagingpfad bereit, der funktioniert, wenn PREVENT_UNLOAD_TO_INLINE_URL auf "true" festgelegt ist. Diese Lösung hebt die Blockierung von VNet- und OPDG-Szenarien auf. Auf dieser Seite finden Sie Updates zur Verfügbarkeit.
-
Verhalten bei der Neuinitialisierung: Eine Neuinitialisierung ist ein vollständiges Neuladen der Daten einer gesamten Tabelle. Im Gegensatz zu einer inkrementellen Synchronisierung (bei der nur geänderte Zeilen verarbeitet werden) werden bei einem Reseed alle Daten in der Tabelle erneut gelesen und neu geschrieben. Reseeds können erhebliche Schneeflake-Berechnungskosten verursachen, insbesondere für große Tabellen.
- Was löst ein erneutes Senden aus:
| Auslöser | Beschreibung |
|---|---|
| DDL-Änderungen | Jede DDL-Änderung, die den DDL-Zeitstempel einer Tabelle ändert, löst eine erneute Verarbeitung aus. Dieser Trigger enthält ALTER TABLE-Anweisungen, die Spalten hinzufügen, ablegen oder umbenennen, Datentypen ändern oder Tabelleneigenschaften ändern. |
| Schemaänderungstools (z. B. DBT) | Wenn ein Tool wie DBT Tabellendefinitionen regelmäßig ändert (z. B. über dbt run, wodurch Tabellen gelöscht und neu erstellt werden), löst jede Änderung ein Neuseeding aus. Das häufige Ausführen dieser Tools (z. B. alle paar Minuten) kann zu kontinuierlichen Erneutverläufen führen. |
| Stoppen und Neustarten der Spiegelung | Jedes Mal, wenn Sie die Spiegelung beenden und neu starten, wird die gesamte Tabelle wieder von Grund auf abgerufen. |
| Unterbrechung der erweiterten Kapazität | Wenn eine Fabric-Kapazität über einen längeren Zeitraum pausiert wird, könnte die Spiegelung bei der Wiederaufnahme erneut von vorn beginnen. Siehe Änderungen an der Fabric-Kapazität. |
- Bewährte Vorgehensweisen zur Vermeidung unnötiger Reseeds:
- Planen Sie Schemaänderungen außerhalb der aktiven Spiegelung. Wenn Sie DBT oder andere Schemaverwaltungstools verwenden, planen Sie diese während der Wartungsfenster, oder halten Sie die Spiegelung an, bevor Sie Schemaänderungen ausführen.
- Vermeiden Sie häufige DDL-Änderungen. Konsolidieren Sie Schemaänderungen in weniger, größere Batches, anstatt im Laufe des Tages inkrementelle Änderungen vorzunehmen.
- Achten Sie auf unerwartete Neuinitialisierungen. Achten Sie auf der Seite "Spiegelungsstatus" auf Tabellen, die wiederholt das Verhalten der ersten Kopie anzeigen. Wenn eine große Tabelle alle paar Minuten neu initialisiert wird, prüfen Sie, ob es vorgelagerte DDL-Änderungen gibt.
- Achten Sie auf die Auswirkungen auf die Kosten. Die Neubefüllung einer Tabelle mit 226 Millionen Zeilen (~26,5 GB) erfordert erhebliche Rechenzeit. Multiplizieren Sie diese Kosten mit der Häufigkeit von Schemaänderungen, um die Kostenwirkungen zu schätzen.
Sicherheitseinschränkungen
- Fabric repliziert die Richtlinien für Row-Level Security (RLS) und Column-Level Security (CLS) von Snowflake nicht. Sie müssen die entsprechenden Sicherheitsrichtlinien in Fabric manuell neu konfigurieren.
- Freigabeempfänger müssen dem Arbeitsbereich hinzugefügt werden. Um ein Dataset oder einen Bericht zu teilen, fügen Sie dem Arbeitsbereich zuerst Zugriff mit der Rolle Administrator, Mitglied, Leser oder Mitwirkender hinzu.
Überlegungen zu Kosten und Abrechnung
Um die Snowflake-Compute-Kosten durch Spiegelung zu minimieren, sollten Sie die folgenden Best Practices berücksichtigen:
- Wiederverwenden eines vorhandenen Lagers. Anstatt ein dediziertes Lager für die Spiegelung zu erstellen, konfigurieren Sie die Spiegelung so, dass sie dasselbe Lager verwendet, das Ihre Anwendungen bereits zum Aktualisieren der Quelltabellen verwenden. Dieser Ansatz vermeidet unnötige Warehouse-Wake-up- und Auto-Suspend-Zyklen. Wenn Ihre Anwendung eine Tabelle aktualisiert, nimmt der Spiegelreplikationsdienst Änderungen fast sofort auf, während das Lager noch aktiv ist, ohne dass ein separates Lager aktiviert werden muss. Einige Organisationen bevorzugen möglicherweise ein dediziertes Lager für die Budgetisolation. Diese Wahl ist ein Kompromiss zwischen Kosteneinsparungen und Budgetierungs granularität.
- Spiegeln Sie nur die Tabellen, die Sie benötigen. Das Spiegeln einer gesamten Datenbank kann zu unerwartet hohem Snowflake-Verbrauch und Kapazitätsspitzen in Fabric führen. Wählen Sie zunächst nur die Tabellen aus, die für Ihre Analyseszenarien erforderlich sind. Sie können tabellen später nach Bedarf hinzufügen.
- Achten Sie auf unerwartete Reseeds. Ein erneutes Seeding (vollständiges Neuladen der Daten) verarbeitet die gesamte Tabelle und verursacht Rechenkosten proportional zur Tabellengröße. Schemaänderungen – auch solche, die durch Tools wie DBT ausgelöst werden – können zu kontinuierlichen Neuinitialisierungen führen. Überwachen Sie die Seite "Spiegelungsstatus " für Tabellen, die das Verhalten wiederholter Initialkopien anzeigen, und überprüfen Sie den Abschnitt "Erneutes Bearbeiten" auf Trigger und Anleitungen zur Problembehandlung.
- Beachten Sie, dass die Spiegelung kontinuierlich ausgeführt wird. Die Spiegelung unterstützt derzeit weder Zeitplanung noch Replikationsfenster. Der Replikator fragt kontinuierlich Änderungen ab, was zu einer fortlaufenden Snowflake-Compute-Nutzung führt. Planen Sie Ihre Snowflake-Budgets entsprechend.
Unterstützte Regionen
Datenbankspiegelung und geöffnete Spiegelung sind in allen Microsoft Fabric Regionen verfügbar. Weitere Informationen finden Sie unter Regionale Verfügbarkeit für Fabric.