Faza 1. Strategia migracji i planowanie

Ten artykuł to Faza 1 z 4 w serii najlepszych praktyk migracyjnych z Azure Synapse Spark do Microsoft Fabric.

Zacznij tutaj, zanim zmigrujesz wszystkie notesy, definicje zadań platformy Spark, pule lub metadane lake. Ten artykuł pomaga ocenić zakres zasobów Synapse Spark, wybrać podejście do migracji zgodne z twoją tolerancją ryzyka i harmonogramem dostaw oraz zrozumieć różnice w Fabric, które wpływają na planowanie.

Na koniec tego kroku należy wiedzieć, co należy przenieść, którego wzorca migracji użyć, gdzie są główne zagrożenia zgodności, oraz jakie ograniczenia wycofywania lub uruchamiania równoległego należy uwzględnić.

W tym artykule dowiesz się, jak:

  • Oceń ślad Synapse Spark.
  • Wybierz pomiędzy metodą "lift-and-shift", modernizacją fazową a uruchomieniem równoległym.
  • Uwzględnij ograniczenia związane z cofnięciem i synchronizacją.
  • Zapoznaj się z kluczowymi różnicami funkcji i architektury między usługą Synapse Spark i platformą Fabric Spark.

Oceń wpływ Synapse Spark

Azure Synapse Analytics obejmuje wiele typów obciążeń. Ten przewodnik koncentruje się na migrowaniu pul platformy Spark, notesów, definicji zadań platformy Spark, baz danych lake i metadanych magazynu metadanych Hive do Microsoft Fabric. Zapoznaj się z przewodnikami towarzyszącymi dotyczącymi dedykowanej puli SQL, potoku, Eksploratora Danych i migracji zabezpieczeń.

Obciążenie usługi Synapse Fabric Destination Narzędzie/ścieżka migracji
Pule Spark Fabric Spark (Lakehouse) Asystent migracji Spark (wersja zapoznawcza); ręczna migracja puli/środowiska
Laptopy Notatniki Fabric Spark Asystent migracji; refaktoryzacja kodu dla API specyficznych dla Synapse
Definicje zadań platformy Spark Fabric definicje zadań platformy Spark Pomocnik migracji Spark jest zalecany; ręczne odtworzenie w razie potrzeby
Bazy danych jeziora katalog usługi Fabric Lakehouse Spark Asystent migracji (tabele Delta przez skróty); Eksportowanie/importowanie HMS dla tabel innych niż Delta
Metastore Hive katalog usługi Fabric Lakehouse Notatniki eksportu/importu HMS; Skróty OneLake dla danych
połączone usługi połączenia Fabric i Key Vault Tworzenie połączeń Fabric; migrowanie wpisów tajnych do Key Vault; refaktoryzacja kodu notesu

Uruchom narzędzie do oceny Fabric

Przed zaplanowaniem migracji uruchom narzędzie oceny Fabric, aby wygenerować kompleksowy raport obszaru roboczego źródła usługi Synapse. Narzędzie skanuje obszar roboczy i agreguje podsumowanie wszystkich obiektów — pul platformy Spark, notesów, definicji zadań platformy Spark, baz danych typu lake, połączonych usług i ich konfiguracji — zapewniając jasny obraz zakresu migracji.

  1. Pobierz narzędzie. Narzędzie oceny Fabric jest dostępne w repozytorium GitHub Microsoft fabric-toolbox microsoft/fabric-toolbox.

  2. Uruchom ocenę. Wskaż narzędzie w obszarze roboczym Azure Synapse. Skanuje wszystkie elementy związane z platformą Spark i tworzy raport z liczbami obiektów, konfiguracjami, zależnościami i potencjalnymi problemami ze zgodnością.

  3. Przejrzyj raport. Użyj danych wyjściowych oceny, aby zrozumieć zakres migracji: ile notebooków, pul, SJD i baz danych należy migrować, które połączone usługi są używane, oraz jakie potencjalne przeszkody istnieją (pule GPU, nieobsługiwane funkcje i inne).

Tip

Uruchom narzędzie do oceny na wczesnym etapie procesu planowania. Raport pomaga oszacować nakład pracy, zidentyfikować blokady i określić priorytety, które obciążenia mają być najpierw migrowane. Służy również jako spis punktów odniesienia dla fazy 1 listy kontrolnej migracji.

Wzorce migracji

Wybierz wzorzec migracji na podstawie ograniczeń organizacji, tolerancji ryzyka i osi czasu.

Wzorzec typu "lift-and-shift"

Migrowanie wszystkich obciążeń platformy Spark jednocześnie przy użyciu Asystent migracji z minimalnymi zmianami. Skoncentruj się na jak najszybszym uruchomieniu notesów i zadań w Fabric — refaktoryzuj tylko to, co się psuje (połączone usługi, ścieżki plików, nieobsługiwane interfejsy API). Zaakceptuj bieżącą architekturę as-is.

Użyj funkcji lift-and-shift, gdy:

  • Obszar roboczy usługi Synapse jest likwidowany w ustalonym terminie i musisz działać szybko.
  • Obciążenia Spark są już dobrze zaprojektowane (Delta-first, czysty kod, niewiele zależności między usługami).
  • Rozmiar przestrzeni roboczej jest zarządzalny w przypadku migracji jednorazowej, a twój zespół jest w stanie poradzić sobie z refaktoryzacją w jednym sprincie.
  • Odbiorcy podrzędni (Power BI, interfejsy API) mogą tolerować krótkie okno przełączania.

Modernizacja etapowa

Migruj zadania robocze stopniowo, według priorytetu, przebudowując architekturę na bieżąco. Najpierw zacznij od obciążeń o najwyższym lub najniższym ryzyku. Podczas migrowania każdej partii skonsoliduj pule platformy Spark do mniejszej liczby środowisk, zastosuj najlepsze rozwiązania usługi Lakehouse (delta-first, V-Order dla użytkowników analizy biznesowej), włącz rozwiązanie NEE i przeprojektuj je w usłudze Direct Lake.

Użyj modernizacji fazowej, gdy:

  • Masz duże lub złożone środowisko usługi Synapse z wieloma zespołami i różnymi obciążeniami, których nie można migrować za jednym zamachem.
  • Bieżąca architektura ma dług techniczny, które chcesz rozwiązać (formaty inne niż Delta, zależności punktów montowania, rozległe pule Spark).
  • Masz elastyczność na osi czasu i chcesz zwiększyć wydajność i efektywność kosztową podczas migracji.
  • Różne obciążenia mają różnych właścicieli i potrzebują niezależnych harmonogramów migracji.

Wzorzec działania równoległego

Uruchamianie obu środowisk jednocześnie podczas przejścia. Kierowanie nowych obciążeń platformy Spark do Fabric, podczas gdy starsze obciążenia są kontynuowane w usłudze Synapse. Zweryfikuj zmigrowane obciążenia, porównując wyniki równolegle przed przełączeniem. Stopniowo likwiduj usługę Synapse w miarę jak wzrasta zaufanie.

Użyj przebiegu równoległego, gdy:

  • Twoje obciążenia mają ścisłe umowy SLA lub wymagania prawne, które wymagają rozszerzonej walidacji przed przełączeniem.
  • Musisz udowodnić, że wydajność aplikacji Fabric spełnia lub przekracza poziom Synapse, zanim interesariusze zatwierdzą likwidację.
  • Użytkownicy podrzędni (pulpity nawigacyjne, interfejsy API, modele uczenia maszynowego) nie mogą tolerować żadnych rozbieżności podczas przejścia.
  • Migrujesz pipeline'y produkcyjne, w których nieprawidłowe wyniki mają duży wpływ na działalność biznesową (raportowanie finansowe, zgodność).

Uruchomienie równoległe wprowadza problem z synchronizacją danych, który należy zaprojektować z góry. Wybierz jeden z następujących wzorców:

  • Wspólna warstwa przechowywania: Zarówno Synapse, jak i Fabric powinny mieć możliwość odczytu i zapisu w tym samym magazynie ADLS Gen2 za pomocą skrótów OneLake. Dzięki temu obie platformy korzystają z tych samych plików Delta, ale należy zapobiec konfliktom zapisu, zapewniając, że tylko jedna platforma zapisuje w danej tabeli jednocześnie.
  • Write-once, read-both: Keep Synapse as the primary writer during transition and let Fabric read the same data through shortcuts (Zachowaj usługę Synapse jako podstawowy składnik zapisywania podczas przejścia) i pozwól Fabric odczytywać te same dane za pomocą skrótów. Po zweryfikowaniu zmigrowanych notesów w Fabric, przełącz ścieżkę zapisu na Fabric i ustaw Synapse jako odbiorcę tylko do odczytu aż do dezaktywacji. Jest to najbezpieczniejsza opcja dla większości migracji.
  • Zapis podwójny: Unikaj uruchamiania tego samego ETL w obu środowiskach jednocześnie, chyba że masz już zautomatyzowane narzędzia do porównywania i uzgadniania. Podwójne zapisy zwykle tworzą rozbieżność, duplikację i obciążenie operacyjne.

Równoległe uruchamianie wpływa także na zarządzanie zmianami. Chociaż usługa Synapse pozostaje aktywnym środowiskiem deweloperskim, wszelkie notesy, definicje zadań platformy Spark, konfiguracja puli platformy Spark lub zmiany schematu bazy danych lake wprowadzone w usłudze Synapse nie są odzwierciedlane automatycznie w Fabric. Aby zapewnić zgodność obu środowisk, należy ponownie przeprowadzić migrację zasobów, których dotyczy problem.

  • Zmiany w kodzie notebooków: uruchom ponownie Spark Asystent migracji lub ręcznie wyeksportuj i ponownie zaimportuj zaktualizowane notesy. Ponownie zastosuj wszystkie refaktoryzacje kodu specyficznego dla Fabric, w tym aktualizacje ścieżek plików, sekrety Key Vault i notebookutils.
  • Zmień definicję zadania Spark: Przeprowadź ponowną migrację za pomocą Asystent migracji lub ręcznie ponownie utwórz zaktualizowane definicje zadań Spark (SJD) w Fabric.
  • Zmiany konfiguracji puli Spark: Zaktualizuj odpowiednie środowisko Fabric, aby dopasować je do zmienionego rozmiaru węzła, ustawień automatycznego skalowania oraz bibliotek.
  • Zmiany schematu bazy danych w jeziorze: Ponownie uruchom notesy eksportu/importu HMS lub ręcznie utwórz albo zmień dotknięte tabele w Fabric lakehouse.

Aby zmniejszyć nakład pracy związany z ponowną migracją, po rozpoczęciu migracji wprowadź zamrożenie zmian po stronie Synapse. Jeśli zmiany są nieuniknione, zachowaj dziennik zmian, aby można je było ponownie odtworzyć w Fabric przed przełączeniem.

Zagadnienia dotyczące wycofywania

Migracja usługi Synapse-to-Fabric to operacja kopiowania — nie modyfikuje ani nie usuwa źródłowego obszaru roboczego usługi Synapse. Oryginalne pule, notatniki i dane platformy Spark zachowują się w stanie nienaruszonym w całym procesie. Dzięki temu wycofywanie jest proste:

  • Jeśli wyniki migracji są niezadowalające, kontynuuj korzystanie z istniejącego obszaru roboczego usługi Synapse. Nie trzeba przywracać żadnych zmian.
  • Usuń zmigrowane artefakty Fabric (notesy, środowiska, definicje zadań platformy Spark) i spróbuj ponownie po rozwiązaniu problemów.
  • Skróty OneLake wskazują istniejący zasób ADLS Gen2 — usuwanie skrótów nie wpływa na dane podstawowe.
  • Nie likwiduj obszaru roboczego usługi Synapse, dopóki wszystkie zmigrowane obciążenia nie zostaną zweryfikowane w Fabric, a odbiorcy podrzędni zostaną przekierowani.

Tip

Rozpocznij od małego projektu i szybko udowodnij jego wykonalność. Wybierz reprezentatywne obciążenie platformy Spark i dokonaj pełnej migracji — od konfiguracji puli poprzez refaktoryzację notatnika do finalnej weryfikacji. Wybierz coś, co angażuje najbardziej typowe wzorce (dostęp do danych, połączone usługi, operacje katalogowe), ale jest wystarczająco niskiego ryzyka, aby możliwe było iterowanie. Udotwórz kroki, napotkane problemy i rozwiązania, aby utworzyć powtarzalny proces na potrzeby kolejnych migracji.

Parzystość cech i kluczowe różnice

Zrozumienie różnic architektonicznych między usługą Synapse i Fabric ma kluczowe znaczenie dla planowania. W poniższych tabelach przedstawiono kluczowe różnice w architekturze obliczeniowej i możliwościach platformy Spark.

Aby uzyskać pełne porównanie, zobacz Compare Fabric i Azure Synapse Spark: najważniejsze różnice.

Obliczenia i architektura

Zdolność Azure Synapse Microsoft Fabric
Model wdrażania PaaS (konfigurowanie zasobów i zarządzanie nimi) SaaS (oparte na pojemności, bez zarządzania infrastrukturą)
Model obliczeniowy Pule Spark (oparte na węzłach); wymaga co najmniej 3 węzłów Jednostki pojemności (CU) współużytkowane we wszystkich obciążeniach; Pule Spark jako szablony konfiguracji; Obsługiwane wykonywanie na jednym węźle; Rozliczanie z automatycznym skalowaniem dla platformy Spark (płatność za użycie, podobnie jak model usługi Synapse)
Silnik Spark Pule platformy Synapse Spark (Spark 3.4, 3.5); Obsługiwane pule procesorów GPU Fabric Spark (środowisko uruchomieniowe 1.2/1.3/2.0: Spark 3.4–4.0); brak obsługi procesora GPU; działa na sprzęcie najnowszej generacji w celu zwiększenia wydajności
Skalowanie Automatyczne skalowanie węzłów dla platformy Spark (min 3 węzły) Automatyczne skalowanie węzłów dla platformy Spark (minimum pojedynczego węzła); skalowanie oparte na pojemności
Uruchamianie sesji Oparte na puli; zimny start dla nowych klastrów Pule startowe (uruchamianie na poziomie sekundy); Niestandardowe pule na żywo; Tryb wysokiej współbieżności
Model kosztów Dla węzła na godzinę (Spark); wstrzymywanie/wznawianie Dwie opcje: (1) Fabric Platforma Spark używa modelu zużycia współużytkowanego opartego na pojemności (CU) lub (2) Automatyczne skalowanie rozliczeń dla platformy Spark — płatność zgodnie z rzeczywistym użyciem w trybie platformy Spark

Spark: Synapse Spark vs. Fabric Spark

Zdolność Synapse Spark Fabric Spark
Wersje platformy Spark Spark 3.4 (EOL), 3.5 (wersja zapoznawcza). Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (RT 2.0 (wersja zapoznawcza)
Przyspieszanie zapytań Brak natywnego aparatu przyspieszania Natywny silnik egzekucji (Velox/Gluten, do 4 razy szybszy w testach TPC-DS)
Model puli zasobów Stałe pule z maksymalną liczbą węzłów na pulę; co najmniej 3 węzły Pule początkowe (uruchamianie na poziomie sekund, brak wymaganej konfiguracji); Pule niestandardowe dla określonych rozmiarów węzłów i bibliotek niestandardowych; Obsługiwane wykonywanie pojedynczego węzła
Zabezpieczenia (sieć) Zarządzana sieć wirtualna; Prywatne punkty końcowe Zarządzane prywatne punkty końcowe (MPE); Zasady dostępu wychodzącego (OAP); Customer-Managed Keys (CMK)
Obsługa procesora GPU Dostępne pule przyspieszane przez GPU Niewspierane
Wysoka współbieżność Niewspierane Obsługiwane: wiele notatników współużytkuje jedną sesję Spark
Zarządzanie biblioteką Biblioteki na poziomie puli i na poziomie obszaru roboczego; ręczne przekazywanie kół, jednostek JAR, tar.gz Zarządzanie środowiskowymi bibliotekami: publiczne kanały (PyPI/Conda) + niestandardowe przesyłanie plików (wheels, JAR-y). Aby replikować biblioteki na poziomie obszaru roboczego usługi Synapse, utwórz środowisko z wymaganymi bibliotekami i ustaw je jako domyślny obszar roboczy. Wszystkie notesy i urządzenia SJD w obszarze roboczym automatycznie dziedziczą te ustawienia.
V-Order Niedostępne Optymalizacja Parquet w czasie zapisu; 40–60% poprawa wydajności dla usługi Power BI Direct Lake i około 10% dla punktu końcowego analizy SQL; brak korzyści z odczytu dla Spark; 15–33% obciążenie zapisu
Optymalizowanie zapisu Domyślnie wyłączone Włączone domyślnie
Domyślny format tabeli Parquet (delta opcjonalna) Usługa Delta Lake (wartość domyślna i wymagana dla tabel usługi Lakehouse)
Metastore Hive Wbudowany HMS; zewnętrzne HMS za pośrednictwem usługi Azure SQL DB lub MySQL (przestarzałe po platformie Spark 3.4) katalog Fabric Lakehouse; Migracja HMS za pośrednictwem skryptów eksportu/importu
Usługa DMTS w notesach Supported Obsługiwane w notesach; jeszcze nieobsługiwane w definicjach zadań platformy Spark
Tożsamość zarządzana dla KV Supported Obsługiwane w notesach i definicjach zadań platformy Spark
mssparkutils Pełna biblioteka (fs, credentials, notebook, env, lakehouse) notebookutils (podobny interfejs API; niektóre różnice w nazwach metod)

Treści powiązane

  • Last updated on