Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Bieżące ograniczenia dotyczące odwzorowanych baz danych Snowflake w Microsoft Fabric są wymienione na tej stronie. Ta strona może ulec zmianie.
Ograniczenia połączeń i uwierzytelniania
- Poniższa tabela przedstawia metody uwierzytelniania obsługiwane przy tworzeniu kopii lustrzanej w Snowflake:
| Metoda uwierzytelniania | Wsparte | Notatki |
|---|---|---|
| Nazwa użytkownika i hasło | Yes | Natywne uwierzytelnianie Snowflake |
| Microsoft Entra ID (SSO) | Yes | Logowanie jednokrotne za pośrednictwem Entra ID |
| Uwierzytelnianie pary kluczy | Yes | Para kluczy RSA dla scenariuszy z kontem usługi |
| Tożsamość obszaru roboczego | No | Nie jest obecnie obsługiwane dla Snowflake |
Tożsamość obszaru roboczego nie jest obecnie obsługiwana w funkcji replikacji lustrzanej Snowflake. Jest ona dostępna dla wybranych źródeł, takich jak SharePoint.
Łączność Private Link między obszarem roboczym Fabric a Snowflake nie jest jeszcze dostępna. Użyj bramy danych sieci wirtualnej lub lokalnej bramy danych na potrzeby łączności prywatnej w międzyczasie.
Musisz dodać adresatów udostępniania do obszaru roboczego. Aby udostępnić zestaw danych lub raport, najpierw dodaj access do obszaru roboczego z rolą administratora, członka, czytelnika lub współautora.
Rozróżnianie wielkości liter: wszystkie identyfikatory Snowflake — w tym nazwa magazynu, nazwa bazy danych, nazwa schematu, nazwy tabel i nazwy widoków — rozróżniają wielkość liter podczas konfigurowania połączeń replikacji lustrzanej i korzystania z interfejsu API REST replikacji lustrzanej. Wielkość liter wprowadzona w Fabric musi odpowiadać dokładnie tym, co zostało skonfigurowane w rozwiązaniu Snowflake. Niezgodność wielkości liter może powodować niepowodzenia połączenia lub sprawiać, że tabele nie będą pojawiać się na potrzeby replikacji, często bez opisowego komunikatu o błędzie. Jeśli na przykład magazyn Snowflake ma nazwę ANALYTICS_WH, musisz wprowadzić ANALYTICS_WH w połączeniu Fabric, a nie analytics_wh.
Obsługiwane typy obiektów
- W poniższej tabeli wymieniono typy obiektów Snowflake obsługiwane w przypadku dublowania:
| Typ obiektu | Wsparte | Notatki |
|---|---|---|
| Tabele zarządzane | Yes | W pełni obsługiwane na potrzeby replikacji |
| Tabele Iceberg | Yes | Wymaga połączenia z bazowym magazynem danych tabeli Iceberg. Tylko tabele Iceberg dostępne za pośrednictwem tego samego połączenia z magazynem mogą być dublowane łącznie. |
| Views | Yes | Obsługiwane, synchronizacja co 12 godzin |
| Zmaterializowane widoki | Yes | Obsługiwane, synchronizacja co 12 godzin |
| Tabele zewnętrzne | No | Niewspierane |
| Tabele przejściowe | No | Niewspierane |
| Tabele tymczasowe | No | Niewspierane |
| Tabele przestawne | No | Niewspierane |
Ograniczenia replikacji i danych
- Jeśli w tabeli źródłowej nie ma żadnych aktualizacji, silnik replikacji zaczyna się wycofywać z wykładniczo rosnącym czasem trwania dla tej tabeli, aż do godziny. Taka sama sytuacja może wystąpić, jeśli wystąpi błąd przejściowy, uniemożliwiając odświeżanie danych. Aparat replikatora automatycznie wznowi regularne sondowanie po wykryciu zaktualizowanych danych.
- Hierarchia schematu źródłowego jest replikowana do dublowanej bazy danych. W przypadku baz danych w trybie lustrzanym utworzonych przed włączeniem tej funkcji schemat źródłowy jest spłaszczony, a nazwa schematu jest zakodowana w nazwie tabeli. Jeśli chcesz zreorganizować tabele za pomocą schematów, utwórz ponownie dublowaną bazę danych. Dowiedz się więcej z Replicate source schema hierarchy.
- Mirroring obsługuje replikację kolumn zawierających spacje lub znaki specjalne w nazwach (takie jak
,;{}()\n\t=). W przypadku tabel w ramach replikacji przed włączeniem tej funkcji należy zaktualizować ustawienia dublowanej bazy danych lub ponownie uruchomić dublowanie, aby uwzględnić te kolumny. Dowiedz się więcej o wsparciu dla mapowania kolumn Delta, oznaczonego jako . - Maksymalna liczba tabel, które można replikować w Fabric, to 1000. Obecnie nie można replikować żadnych tabel powyżej limitu 1000.
- W przypadku wybrania opcji Mirrorowanie wszystkich danych podczas konfigurowania mirrorowania, tabele zostaną określone poprzez wybranie pierwszych 1000 tabel po tym jak wszystkie tabele są sortowane alfabetycznie na podstawie nazwy schematu, a następnie nazwy tabeli. Pozostały zestaw tabel w dolnej części listy alfabetycznej nie będzie przenoszony.
- Jeśli usuniesz zaznaczenie opcji Dublowanie wszystkich danych i wybierzesz poszczególne tabele, nie możesz wybrać więcej niż 1000 tabel.
- Kolumny obliczeniowe i tabele obliczeniowe: bazy danych lustrzane są dostępne tylko do odczytu. Nie można tworzyć kolumn obliczeniowych ani tabel obliczeniowych bezpośrednio w dublowanej bazie danych. Aby dodać kolumny obliczeniowe, utwórz usługę Lakehouse i użyj skrótów w celu odwołowania się do zdublowanych danych, a następnie utwórz kolumny obliczeniowe w usłudze Lakehouse przy użyciu notesów lub języka SQL.
Ograniczenia wydajności
- Jeśli zmieniasz większość danych w dużej tabeli, bardziej wydajne jest zatrzymanie i ponowne uruchomienie funkcji dublowania. Wstawianie lub aktualizowanie miliardów rekordów może zająć dużo czasu.
- Niektóre zmiany schematu nie są odzwierciedlone natychmiast. Niektóre zmiany schematu wymagają zmiany danych (wstawiania, aktualizowania lub usuwania), zanim zmiany schematu zostaną zreplikowane do Fabric.
- Uwagi dotyczące wielu regionów: jeśli instancja Snowflake i pojemność w usłudze Fabric znajdują się w różnych regionach chmury, mogą wystąpić większe opóźnienia replikacji i opłaty za wychodzący transfer danych. Aby uzyskać optymalną wydajność i uniknąć kosztów transferu wychodzącego między regionami, wdroż pojemność Fabric w tym samym regionie chmury co instancja Snowflake. Jeśli wdrożenie między regionami jest nieuniknione, należy uwzględnić dodatkowe opłaty za ruch wychodzący z usługi Snowflake i/lub Azure. Aby uzyskać szczegółowe informacje, zobacz dokumentację ruchu wychodzącego Snowflake .
- Podczas replikowania danych z usługi Snowflake do usługi OneLake klienta proces zwykle tymczasowo zapisuje dane za pośrednictwem bezpośredniego adresu URL w celu zwiększenia wydajności. Jeśli parametr na poziomie konta Snowflake PREVENT_UNLOAD_TO_INLINE_URL jest ustawiony na true, obowiązuje następujące zachowanie:
| Metoda łączności | Wpływ, gdy PREVENT_UNLOAD_TO_INLINE_URL = true |
|---|---|
| Bezpośredni (publiczny punkt końcowy) | Mirroring przechodzi na bezpośredni odczyt ze Snowflake. To rozwiązanie zapasowe wydłuża czas replikacji i zwiększa ryzyko przekroczenia limitu czasu połączenia, szczególnie w przypadku dużych zestawów danych. |
| brama danych Virtual Network (VNet) | Dublowanie jest całkowicie zablokowane. Scenariusze bramy sieci wirtualnej nie mogą używać bezpośredniego odczytu i wymagają wbudowanej ścieżki przejściowej adresu URL. |
| Lokalna brama danych (OPDG) | Dublowanie jest całkowicie zablokowane. Scenariusze OPDG nie mogą używać bezpośredniego odczytu i wymagają wbudowanej ścieżki przejściowej adresu URL. |
Planowane rozwiązanie: obsługa integracji z pamięcią masową jest obecnie opracowywana i zapewni alternatywną ścieżkę etapowania, która działa, gdy PREVENT_UNLOAD_TO_INLINE_URL ma wartość true. To rozwiązanie odblokuje scenariusze sieci wirtualnej i opDG. Sprawdź tę stronę pod kątem aktualizacji dotyczących dostępności.
-
Zachowanie podczas ponownego inicjowania: Ponowne inicjowanie to pełne przeładowanie danych całej tabeli. W przeciwieństwie do synchronizacji przyrostowej (która przetwarza tylko zmienione wiersze), ponowne inicjowanie powoduje ponowne odczytanie i zapisanie wszystkich danych w tabeli. Operacje reseedowania mogą generować znaczne koszty mocy obliczeniowej w Snowflake, zwłaszcza w przypadku dużych tabel.
- Co wyzwala ponowne inicjowanie:
| Trigger | Opis |
|---|---|
| Zmiany DDL | Każda zmiana DDL, która modyfikuje znacznik czasu DDL tabeli, powoduje ponowne inicjowanie. Ten wyzwalacz zawiera instrukcje ALTER TABLE, które dodają, upuszczają lub zmieniają nazwy kolumn, zmieniają typy danych lub modyfikują właściwości tabeli. |
| Narzędzia modyfikacji schematu (na przykład DBT) | Jeśli narzędzie takie jak DBT cyklicznie modyfikuje definicje tabel (na przykład za pomocą polecenia dbt run, które usuwa i ponownie tworzy tabele), każda taka modyfikacja uruchamia ponowne inicjowanie. Uruchamianie tych narzędzi często (na przykład co kilka minut) może powodować ciągłe ponowne uruchamianie pętli. |
| Zatrzymywanie i ponowne uruchamianie dublowania | Za każdym razem, gdy zatrzymasz i ponownie uruchomisz replikację, cała tabela jest ponownie pobierana od początku. |
| Wstrzymanie pojemności rozszerzonej | Jeśli pojemność Fabric jest wstrzymana przez dłuższy czas, dublowanie może zostać przywrócone od początku po wznowieniu. Zobacz Zmiany dotyczące pojemności usługi Fabric. |
- Najlepsze rozwiązania dotyczące unikania niepotrzebnych ponownych zmian:
- Zaplanuj zmiany schematu poza aktywnym dublowaniem. Jeśli używasz narzędzi DBT lub innych narzędzi do zarządzania schematami, zaplanuj ich użycie na czas okien serwisowych lub wstrzymaj replikację lustrzaną przed wprowadzeniem zmian w schemacie.
- Unikaj częstych modyfikacji DDL. Scalaj zmiany schematu w rzadsze, ale większe partie, zamiast wprowadzać stopniowe zmiany w ciągu dnia.
- Monitoruj nieoczekiwane ponowne zmiany. Na stronie Stan dublowania poszukaj tabel, które wielokrotnie pokazują zachowanie podczas kopiowania początkowego. Jeśli duża tabela jest zmieniana co kilka minut, sprawdź zmiany nadrzędnego języka DDL.
- Należy pamiętać o wpływie kosztów. Zmiana tabeli z 226 milionami wierszy (ok. 26,5 GB) zajmuje dużo czasu obliczeniowego. Pomnóż ten koszt przez częstotliwość zmian schematu, aby oszacować wpływ na koszty.
Ograniczenia zabezpieczeń
- Fabric nie replikuje zasad usługi Snowflake Row-Level Security (RLS) i Column-Level Security (CLS). Należy ręcznie ponownie skonfigurować równoważne zasady zabezpieczeń w Fabric.
- Adresaci udostępniania muszą zostać dodani do obszaru roboczego. Aby udostępnić zestaw danych lub raport, najpierw dodaj access do obszaru roboczego z rolą administratora, członka, czytelnika lub współautora.
Zagadnienia dotyczące kosztów i rozliczeń
Aby zminimalizować koszty obliczeniowe w Snowflake związane z dublowaniem, rozważ następujące najlepsze praktyki:
- Użyj ponownie istniejącego magazynu. Zamiast tworzyć dedykowany magazyn na potrzeby dublowania, skonfiguruj funkcję dublowania tak, aby korzystała z tego samego magazynu, którego aplikacje używają już do aktualizowania tabel źródłowych. Takie podejście pozwala uniknąć niepotrzebnych cykli wybudzania magazynu i jego automatycznego wstrzymywania. Gdy aplikacja aktualizuje tabelę, replikator mirroringu wychwytuje zmiany niemal natychmiast, podczas gdy magazyn danych pozostaje aktywny, dzięki czemu nie ma potrzeby wybudzania osobnego magazynu danych. Niektóre organizacje mogą preferować dedykowany magazyn na potrzeby izolacji budżetu. Ten wybór jest kompromisem między oszczędnościami kosztów a szczegółowością budżetowania.
- Duplikuj tylko tabele, których potrzebujesz. Replikacja lustrzana całej bazy danych może powodować nieoczekiwanie wysokie wykorzystanie zasobów Snowflake oraz nagłe skoki wykorzystania pojemności usługi Fabric. Zacznij od wybrania tylko tabel wymaganych dla scenariuszy analitycznych. Tabele można dodawać później zgodnie z potrzebami.
- Monitoruj nieoczekiwane ponowne zmiany. Ponowne ładowanie (pełne ładowanie danych) przetwarza całą tabelę i generuje koszt obliczeniowy proporcjonalny do rozmiaru tabeli. Zmiany schematu — w tym te wywoływane przez narzędzia, takie jak DBT — mogą powodować ciągłe ponowne inicjalizacje. Monitoruj stronę Stan dublowania pod kątem tabel wykazujących powtarzające się początkowe kopiowanie i przejrzyj sekcję Ponowne inicjowanie, aby zapoznać się z czynnikami wyzwalającymi oraz wskazówkami dotyczącymi rozwiązywania problemów.
- Należy pamiętać, że dublowanie jest uruchamiane w sposób ciągły. Dublowanie nie obsługuje obecnie okien planowania ani replikacji. Replikator stale sprawdza, czy zaszły zmiany, co powoduje ciągłe zużycie zasobów obliczeniowych Snowflake. Zaplanuj odpowiednio budżety dla Snowflake.
Obsługiwane regiony
Dublowanie bazy danych i ogólnodostępne dublowanie są dostępne we wszystkich regionach Microsoft Fabric. Aby uzyskać więcej informacji, zobacz Dostępność regionu Fabric.