Faza 4: Migracja zabezpieczeń i zarządzania

Ten artykuł to faza 4 z 4 etapów w serii najlepszych praktyk migracji z Azure Synapse Spark do Microsoft Fabric.

Użyj tego artykułu na ostatnim etapie migracji, aby zweryfikować obciążenia, dostosować mechanizmy kontroli zabezpieczeń i ładu oraz zaplanować migrację produkcyjną. Ten artykuł zawiera wskazówki dotyczące mapowania zabezpieczeń oraz oparte na listach kontrolnych podejście do walidacji, optymalizacji i gotowości jednorazowej.

W tym artykule dowiesz się, jak:

  • Odwzoruj wzorce RBAC dla Synapse i sieci na obszar roboczy Fabric, OneLake i zarządzane kontrolki sieciowe.
  • Połącz ponownie przepływy pracy związane z zarządzaniem, w tym integrację z Microsoft Purview i etykietowanie.
  • Użyj listy kontrolnej migracji fazowej, aby zweryfikować, zoptymalizować i wykonać przełączenie.
  • Planowane wyłączenie z użycia starszych zasobów Synapse Spark po pomyślnym przejściu.

Kontrola dostępu

  • Role RBAC Synapse (Synapse Administrator, Synapse SQL Administrator, Synapse Spark Administrator i inne) odpowiadają rolom obszaru roboczego Fabric (administrator, członek, współautor, osoba przeglądająca). Model Fabric jest prostszy i obejmuje cztery role.

  • Usługi połączone Synapse są zastępowane przez Fabric Connections. Utwórz połączenia za pomocą ustawień >Zarządzaj połączeniami i bramami. Dla kodu notebooka zastąp odwołania do połączonej usługi uwierzytelnianiem opartym na Key Vault lub konfiguracją bezpośredniego punktu końcowego.

  • Kontrola dostępu oparta na rolach (RBAC) w OneLake zapewnia szczegółową kontrolę dostępu do danych na poziomie folderu i tabeli w systemie Lakehouse.

Bezpieczeństwo sieci

  • Zarządzana sieć wirtualna i prywatne punkty końcowe usługi Synapse odpowiadają zarządzanej sieci wirtualnej Fabric oraz zarządzanym prywatnym punktom końcowym. Należy pamiętać, że Fabric Spark wymaga wsparcia zarządzanych prywatnych punktów końcowych dla pul niestandardowych (a nie pul początkowych).

  • Samodzielnie hostowane "Integration Runtimes" (SHIR) w usłudze Synapse są zastępowane przez lokalne bramy danych (OPDG) w Fabric. VNet IRs są zastępowane przez bramy danych VNet.

Rządzenie

Jeśli używasz usługi Azure Purview z usługą Synapse, Fabric zapewnia natywną integrację Microsoft Purview z katalogiem danych, pochodzeniem, etykietami poufności i zasadami dostępu. Ponownie połącz swoje konto Purview, aby skanować przestrzenie robocze Fabric.

Lista kontrolna migracji

Ta lista kontrolna służy do śledzenia postępu migracji platformy Spark. Każda faza jest oparta na poprzedniej fazie. Zakończ wszystkie zagadnienia w fazie przed przejściem do następnej.

Faza 1. Ocena i planowanie

Aby uzyskać wskazówki dotyczące planowania, wzorce migracji i porównanie funkcji, zobacz Faza 1: Strategia migracji i planowanie.

  • 1.1 Kompletny spis zasobów platformy Spark: pule platformy Spark, notesy, definicje zadań platformy Spark, bazy danych lake, bazy danych magazynu metadanych Hive (HMS) i połączone usługi używane w notesach.
  • 1.2 Przejrzyj różnice funkcji usługi Synapse a Fabric. Blokady flag: obciążenia GPU, nieobsługiwane interfejsy API katalogu, zależności usług połączonych.
  • 1.3 Przeprowadź kontrolę przed refaktoryzacją: wyszukaj wszystkie notebooki pod kątem wzorców specyficznych dla Synapse (spark.synapse.linkedService, getSecretWithLS, TokenLibrary, synapsesql). Policz dotknięte notebooki.
  • 1.4 Sprawdź zgodność biblioteki: uruchom pip freeze w pulach Synapse, porównaj z wbudowanymi bibliotekami Fabric Runtime 1.3. Wyświetl listę bibliotek, które muszą być wstępnie zainstalowane.
  • 1.5 Utwórz obszary robocze Fabric, zaprovisionuj pojemność i utwórz docelowe elementy Lakehouse.
  • 1.6 Eksportuj konfiguracje puli platformy Spark, biblioteki niestandardowe i właściwości platformy Spark z Synapse Studio.

Faza 2. Konfigurowanie połączeń i poświadczeń

Aby uzyskać wskazówki dotyczące zastępowania i uwierzytelniania połączonej usługi, zobacz Faza 2: migracja obciążeń platformy Spark i Faza 4: Migracja zabezpieczeń i ładu.

  • 2.1 Zinwentaryzuj wszystkie połączone usługi Synapse używane przez notesy, definicje zadań Spark i dostęp do danych Lakehouse.
  • 2.2 Utwórz połączenia Fabric dla zewnętrznych źródeł danych (ADLS Gen2, Cosmos DB, Azure SQL i innych) za pośrednictwem ustawień Workspace Settings>Zarządzaj połączeniami i bramami.
  • 2.3 Skonfiguruj Azure Key Vault z tajnikami dla źródeł danych, które wymagają uwierzytelniania opartego na kluczach (klucze Cosmos DB, klucze konta magazynu, tokeny Kusto). Skonfiguruj zasady dostępu dla tożsamości obszaru roboczego w Fabric.
  • 2.4 Konfigurowanie poświadczeń jednostki usługi dla dostępu OAuth do usługi ADLS Gen2: rejestrowanie aplikacji w Entra ID, udzielanie roli Współtwórca danych obiektu blob w usłudze Storage, zanotuj identyfikator klienta, tajny klucz klienta oraz dzierżawcę.
  • 2.5 Sprawdź łączność: przetestuj pobieranie tajnych wpisów z Key Vault i dostęp do konta magazynu z notatnika Fabric przed kontynuowaniem.

Faza 3. Migrowanie danych i magazynu metadanych Hive

Aby uzyskać wskazówki dotyczące migracji metadanych typu lake i dostępu do danych, zobacz Faza 3: Magazyn metadanych Hive i migracja danych oraz Migrowanie danych i potoków.

  • 3.1 Tworzenie skrótów OneLake do istniejących ścieżek usługi ADLS Gen2 (bez kopiowania, preferowane podejście). Użyj Fabric Connections skonfigurowanego w fazie 2 na potrzeby dostępu opartego na bramie danych.
  • 3.2 W przypadku plików innych niż delta (CSV, JSON, Parquet) utwórz skróty w sekcji Pliki. Jeśli kopiowanie danych jest wymagane, użyj AzCopy lub działania kopiowania w usłudze Data Factory.
  • 3.3 Migrowanie obiektów magazynu metadanych Hive. Wybierz jedno podejście: Opcja A: Uruchom notesy eksportu/importu HMS dla wszystkich metadanych. Opcja B: użyj Asystent migracji dla tabel bazy danych Delta Lake DB i eksportu/importu HMS tylko dla danych nie-Delta.
  • 3.4 Zweryfikuj automatyczną rejestrację Tabeli Delta w Lakehouse Explorer.
  • 3.5 Sprawdź, czy wszystkie zaimportowane tabele i skróty są widoczne w Eksploratorze usługi Lakehouse i są dostępne z notesów.

Faza 4. Migrowanie obciążeń platformy Spark

Aby uzyskać wskazówki dotyczące migracji elementów, refaktoryzacji kodu i konfiguracji środowiska, zobacz Faza 2: migracja obciążenia platformy Spark.

  • 4.1 Uruchom Asystenta migracji Spark dla notesów, definicji zadań Spark, pul Spark i baz danych jeziora. Przejrzyj raport migracji pod kątem błędów i ostrzeżeń.
  • 4.2 Tworzenie środowisk Fabric z docelowym środowiskiem uruchomieniowym platformy Spark, konfiguracją puli i bibliotekami niestandardowymi. Wstępnie zainstaluj brakujące biblioteki zidentyfikowane w fazie 1.
  • 4.3 Refaktoryzuj notebook i kod SJD: zastąp mssparkutilsnotebookutils, zaktualizuj ścieżki plików do ścieżek usługi OneLake abfss://, zastąp odwołania do zlinkowanych usług na Key Vault lub połączenia Fabric, i zastąp nieobsługiwane metody spark.catalog odpowiednikami Spark SQL.
  • 4.4 Refaktoryzacja łączników: Kusto/ADX — zastąp powiązaną usługę za pomocą accessToken przy użyciu getToken(). Cosmos DB — zastąp getSecretWithLSgetSecret(akvName, secret).
  • 4.5 Zastąp dostawców tokenów usługi Synapse (LinkedServiceBasedTokenProvider, TokenLibrary) standardem OAuth ClientCredsTokenProvider za pośrednictwem polecenia spark.conf.set().
  • 4.6 Przetestuj refaktoryzowane notatniki i opisy zadań systemowych (SJDs) kompleksowo w stosunku do danych (faza 3) oraz połączeń (faza 2).

Faza 5. Zabezpieczenia, nadzór i sieć

Aby uzyskać wskazówki dotyczące zabezpieczeń, ładu i mapowania sieci, zobacz Faza 4: migracja zabezpieczeń i ładu.

  • 5.1 Przypisz role RBAC Synapse do ról obszaru roboczego Fabric (Administrator, Członek, Współtwórca, Oglądający).
  • 5.2 Skonfiguruj OneLake RBAC na potrzeby drobiazgowej kontroli dostępu do danych na poziomie folderu i tabeli.
  • 5.3 Konfigurowanie zarządzanych sieci wirtualnych i zarządzanych prywatnych punktów końcowych dla obciążeń platformy Spark, które uzyskują dostęp do prywatnych źródeł danych (wymaga pul niestandardowych).
  • 5.4 Zastąp SHIR lokalną bramą danych (OPDG) i zastąp VNet IR bramą danych sieci wirtualnej (VNet Data Gateway).
  • 5.5 Połącz ponownie Microsoft Purview dla zarządzania, pochodzenia danych i etykiet poufności.
  • 5.6 Przejrzyj i zastosuj etykiety poufności do zmigrowanych elementów usługi Lakehouse zgodnie z potrzebami.

Faza 6. Optymalizowanie i weryfikowanie

Aby uzyskać wskazówki dotyczące weryfikacji po-migracyjnej i gotowości produkcyjnej, zobacz Faza 4: migracja zabezpieczeń i zarządzania.

  • 6.1 Włącz Native Execution Engine (NEE) dla poprawy wydajności Spark przy obsłudze danych Parquet i Delta.
  • 6.2 Uruchom OPTIMIZE VORDER w tabelach używanych przez usługę Power BI Direct Lake lub punkt końcowy analizy SQL.
  • 6.3 Uruchamianie równoległych obciążeń i porównanie wyników zadań platformy Spark i wydajności między usługą Synapse i Fabric.
  • 6.4 Przekieruj odbiorców podrzędnych, w tym raporty Power BI, interfejsy API i aplikacje, do punktów końcowych Fabric.
  • 6.5 Monitorowanie obciążeń Fabric przy użyciu centrum monitorowania i emitera diagnostycznego przez co najmniej jeden do dwóch tygodni.

Faza 7: Przełączenie

Aby uzyskać ostateczną walidację, przekierowanie podrzędne i wskazówki dotyczące migracji jednorazowej, zobacz Faza 4: migracja zabezpieczeń i ładu.

  • 7.1 Potwierdź, że wszystkie zmigrowane notesy, SJD i zadania Spark zostały pomyślnie uruchomione w Fabric.
  • 7.2 Sprawdź integralność danych za pomocą liczników wierszy, walidacji schematu i porównania wyników zapytań.
  • 7.3 Przekazanie informacji o przełączeniu interesariuszom i aktualizacja dokumentacji.
  • 7.4 Likwiduj pule, notesy i powiązane zasoby usługi Synapse Spark.

Note

Po migracji rozważ skonfigurowanie integracji Fabric Git dla migrowanych notesów i definicji zadań platformy Spark. Fabric obsługuje integrację Azure DevOps Git na potrzeby kontroli źródła, rozgałęziania i potoków wdrażania. W przeciwieństwie do usługi Synapse (która używa szablonów usługi ARM do ciągłej integracji/ciągłego wdrażania), Fabric używa modelu opartego na obszarze roboczym, w którym łączysz obszar roboczy z gałęzią Git i synchronizujesz bezpośrednio elementy. Notatniki, środowiska i SJD obsługują integrację z Git. Konfigurowanie potoków wdrażania (Dev → Test → Prod) w celu zarządzania podwyższeniem poziomu w różnych środowiskach.

Treści powiązane

  • Last updated on