Metody migracji dedykowanych pul SQL usługi Azure Synapse Analytics do usługi Fabric Data Warehouse

Dotyczy: ✅ Magazynu w platformie Microsoft Fabric

Ten artykuł opisuje metody migracji magazynów danych w Azure Synapse Analytics dedykowanych pulach SQL do Microsoft Fabric Data Warehouse.

Tip

Aby uzyskać więcej informacji na temat strategii i planowania migracji, zobacz Planowanie migracji: dedykowane pule SQL usługi Azure Synapse Analytics w usłudze Fabric Data Warehouse.

Zautomatyzowane środowisko migracji z dedykowanych pul SQL usługi Azure Synapse Analytics jest dostępne przy użyciu narzędzia Fabric Asystent migracji for Data Warehouse. Pozostała część tego artykułu zawiera więcej kroków migracji ręcznej.

Ta tabela zawiera podsumowanie informacji dotyczących schematu danych (DDL), kodu bazy danych (DML) i metod migracji danych. Rozwijamy dalej każdy scenariusz w dalszej części tego artykułu, połączony w kolumnie Opcja .

Numer opcji	Opcja	Do czego służy	Umiejętność/preferencje	Scenariusz
1	Fabryka Danych	Konwersja schematu (DDL) Wyciąg danych Pozyskiwanie danych	ADF/Pipeline	Uproszczenie schematu wszystko-w-jednym (DDL) i migracji danych. Zalecane w przypadku tabel wymiarów.
2	Fabryka Danych z partycją	Konwersja schematu (DDL) Wyciąg danych Pozyskiwanie danych	ADF/Pipeline	Użycie opcji partycjonowania w celu zwiększenia równoległości odczytu/zapisu, co zapewnia dziesięciokrotnie większą przepływność w porównaniu z opcją 1, jest zalecane dla tabel faktów.
3	Usługa Data Factory z przyspieszonym kodem	Konwersja schematu (DDL)	ADF/Pipeline	Najpierw przekonwertuj i zmigruj schemat (DDL), a następnie użyj CETAS do wyodrębnienia danych, a COPY lub Data Factory do ich zaimportowania, aby osiągnąć optymalną ogólną wydajność pozyskiwania danych.
4	Przyspieszony kod procedur przechowywanych	Konwersja schematu (DDL) Wyciąg danych Ocena kodu	Język T-SQL	Użytkownik SQL korzystający ze środowiska IDE z bardziej szczegółową kontrolą nad zadaniami, nad którymi chcą pracować. Użyj funkcji COPY/Data Factory do pozyskiwania danych.
5	Rozszerzenie projektu usługi SQL Database dla programu Visual Studio Code	Konwersja schematu (DDL) Wyciąg danych Ocena kodu	Projekt SQL	Projekt usługi SQL Database na potrzeby wdrożenia z integracją opcji 4. Użyj COPY lub Data Factory do pozyskiwania danych.
6	UTWÓRZ ZEWNĘTRZNĄ TABELĘ Z WYBOREM (CETAS)	Wyciąg danych	Język T-SQL	Ekonomiczny i wysokowydajny eksport danych do Azure Data Lake Storage (ADLS) Gen2. Użyj funkcji COPY/Data Factory do pozyskiwania danych.
7	Migracja za pomocą dbt	Konwersja schematu (DDL) Konwersja kodu bazy danych (DML)	dbt	Istniejący użytkownicy dbt mogą użyć adaptera dbt Fabric do konwersji swoich DDL i DML. Następnie należy przeprowadzić migrację danych przy użyciu innych opcji w tej tabeli.

Wybieranie obciążenia na potrzeby migracji początkowej

Decydując się, od czego zacząć z dedykowaną pulą SQL w Synapse, aby Fabric Data Warehouse projekt migracji, wybierz obszar obciążenia, w którym możesz:

• Udowodnij wykonalność migracji do Fabric Data Warehouse, szybko dostarczając korzyści z nowego środowiska. Zacznij od małych i prostych kroków, przygotowując się na wielokrotne małe migracje.
• Zezwól pracownikom technicznym na uzyskanie odpowiedniego doświadczenia z procesami i narzędziami używanymi podczas migracji do innych obszarów.
• Utwórz szablon dla dalszych migracji, który będzie specyficzny dla źródłowego środowiska Synapse oraz narzędzi i procesów wspomagających.

Tip

Utwórz spis obiektów, które muszą zostać zmigrowane, i udokumentować proces migracji od początku do końca, aby można je było powtórzyć dla innych dedykowanych pul SQL lub obciążeń.

Objętość przeniesionych danych podczas początkowej migracji powinna być wystarczająco duża, aby pokazać możliwości i korzyści środowiska Fabric Data Warehouse, ale nie zbyt duża, by szybko wykazać wartość. Typowy jest rozmiar zakresu 1–10 terabajtów.

Migracja za pomocą usługi Fabric Data Factory

W tej sekcji omówiono opcje korzystania z usługi Data Factory dla użytkowników nisko-kodowych/bezkodowych, którzy znają usługę Azure Data Factory i Potok Synapse. Ta opcja przeciągania i upuszczania interfejsu użytkownika zapewnia prosty krok konwersji DDL i migracji danych.

Usługa Fabric Data Factory może wykonywać następujące zadania:

• Przekonwertuj schemat (DDL) na składnię Fabric Data Warehouse.
• Stwórz schemat (DDL) na Fabric Data Warehouse.
• Przenieś dane do Fabric Data Warehouse.

Opcja 1. Schemat/migracja danych — kreator kopiowania i działanie ForEach Copy

Ta metoda wykorzystuje Data Factory Copy assistant do połączenia się z dedykowaną pulą SQL źródłową, konwersję dedykowanej składni SQL DDL na Fabric oraz kopiowanie danych do Fabric Data Warehouse. Można wybrać co najmniej jedną tabelę docelową (dla zestawu danych TPC-DS istnieje 22 tabele). Generuje pętlę ForEach, aby przejść przez listę tabel wybranych w interfejsie użytkownika i tworzenia 22 równoległych wątków procesu kopiowania.

• 22 Zapytania SELECT (po jednym dla każdej wybranej tabeli) zostały wygenerowane i wykonane w dedykowanej puli SQL.
• Upewnij się, że masz odpowiednią klasę DWU i klasę zasobów, aby umożliwić wykonywanie zapytań wygenerowanych. W tym przypadku potrzebujesz co najmniej DWU1000 z staticrc10, aby umożliwić obsługę maksymalnie 32 zapytań przy 22 przesłanych zapytaniach.
• Bezpośrednie kopiowanie danych z dedykowanej puli SQL przez Data Factory do Fabric Data Warehouse wymaga etapowania (staging). Proces spożycia składa się z dwóch faz.
  • Pierwsza faza składa się z wyodrębniania danych z dedykowanej puli SQL do usługi ADLS i nazywana jest etapem przejściowym.
  • Druga faza pobiera dane od etapowania do Fabric Data Warehouse. Większość procesu pozyskiwania danych odbywa się w fazie przygotowawczej. Podsumowując, etapowanie ma ogromny wpływ na wydajność przetwarzania.

Zalecane użycie

Użycie Kreatora Kopiowania do wygenerowania ForEach zapewnia prosty interfejs użytkownika do konwersji DDL i pobierania wybranych tabel z dedykowanej puli SQL w Fabric Data Warehouse w jednym kroku.

Jednak nie jest to optymalne w przypadku ogólnej przepływności. Wymóg użycia etapowania oraz konieczność równoległego przetwarzania odczytu i zapisu podczas kroku "Source to Stage" to główne czynniki wpływające na opóźnienie w wydajności. Zaleca się użycie tej opcji tylko w przypadku tabel wymiarów.

Opcja 2. Migracja DDL/Data – przepływ danych z opcją partycjonowania

Aby zwiększyć przepływność ładowania większych tabel faktów przy użyciu Fabric pipeline, zaleca się użycie Activity kopiowania dla każdej tabeli faktów z opcją partycji. Zapewnia to najlepszą wydajność dla funkcji „Kopiuj”.

Istnieje możliwość użycia partycjonowania fizycznego tabeli źródłowej, jeśli jest dostępne. Jeśli tabela nie ma partycjonowania fizycznego, musisz określić kolumnę partycji i podać wartości minimalne/maksymalne, aby używać partycjonowania dynamicznego. Na poniższym zrzucie ekranu opcje potoku Source określają dynamiczny zakres partycji na podstawie kolumny ws_sold_date_sk.

Podczas korzystania z partycji można zwiększyć wydajność w fazie przygotowawczej. Należy jednak wziąć pod uwagę stosowne dostosowania.

• W zależności od zakresu partycji może on potencjalnie używać wszystkich miejsc współbieżności, ponieważ może generować ponad 128 zapytań w dedykowanej puli SQL.
• Musisz zwiększyć skalowanie do minimum DWU6000, aby umożliwić wykonywanie wszystkich zapytań.
• Na przykład w przypadku tabeli TPC-DS web_sales do dedykowanej puli SQL przesłano 163 zapytania. W DWU6000 wykonano 128 zapytań, podczas gdy 35 zapytań oczekiwało w kolejce.
• Partycja dynamiczna automatycznie wybiera partycję przedziałową. W tym przypadku 11-dniowy zakres dla każdego zapytania SELECT przesłanego do dedykowanej puli SQL. Na przykład:

  WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
  ...
  WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
  

Zalecane użycie

W przypadku tabel faktów zalecamy użycie usługi Data Factory z opcją partycjonowania w celu zwiększenia przepływności.

Jednak zwiększone równoległe odczyty wymagają dedykowanej puli SQL, aby skalować się na wyższe DWU, umożliwiając wykonanie zapytań ekstraktu. Dzięki wykorzystaniu partycjonowania wskaźnik zwiększa się dziesięciokrotnie w porównaniu z opcją bez partycji. Możesz zwiększyć DU, aby uzyskać dodatkową przepustowość dzięki zasobom obliczeniowym, ale dedykowana pula SQL ma maksymalnie 128 aktywnych zapytań.

Aby uzyskać więcej informacji na temat mapowania jednostek DWU usługi Synapse do Fabric, zobacz Blog: Mapowanie dedykowanych pul SQL usługi Azure Synapse na zasoby obliczeniowe Fabric Data Warehouse.

Opcja 3. Migracja DDL — Kreator kopii dla każdej czynności kopiowania

Dwie poprzednie opcje to doskonałe opcje migracji danych dla mniejszych baz danych. Jeśli jednak potrzebujesz wyższej przepływności, zalecamy użycie alternatywnej opcji:

1. Wyodrębnij dane z dedykowanego zasobu SQL do ADLS, co pozwala zmniejszyć obciążenie wydajności etapu.
2. Użyj Data Factory lub polecenia COPY, aby pobrać dane do swojego magazynu.

Zalecane użycie

Możesz nadal używać usługi Data Factory do konwertowania schematu (DDL). Za pomocą Kreatora kopiowania możesz wybrać określoną tabelę lub Wszystkie tabele. Zgodnie z projektem program migruje schemat i dane w jednym kroku, wyodrębniając schemat bez żadnych wierszy przy użyciu warunku TOP 0 false w instrukcji zapytania.

Poniższy przykładowy kod obejmuje migrację schematu (DDL) z usługą Data Factory.

Przykład kodu: migracja schematu (DDL) za pomocą usługi Data Factory

Możesz użyć Fabric Pipelines do łatwej migracji DDL (schematów) dla obiektów tabel z dowolnego źródła Azure SQL Database lub dedykowanej puli SQL. Ten potok migruje schemat (DDL) dla dedykowanych tabel puli SQL źródłowej na Fabric Data Warehouse.

Projekt potoku: parametry

Ten potok akceptuje parametr SchemaName, który umożliwia określenie schematów, które mają być migrowane. Schemat dbo jest domyślny.

W polu domyślna wartość wprowadź listę schematów tabeli rozdzieloną przecinkami, wskazując, które schematy mają być migrowane: aby udostępnić dwa schematy, 'dbo','tpch'dbo i tpch.

Projektowanie potoku: aktywność wyszukiwania

Utwórz aktywność wyszukiwania i ustaw połączenie, aby wskazywało na twoją źródłową bazę danych.

Na karcie Ustawienia:

• Ustaw typ magazynu danych na Zewnętrzny.

• Połączenie to Twoja dedykowana pula SQL w Azure Synapse. Typ połączenia to Azure Synapse Analytics.

• Użycie zapytania jest ustawione na Zapytanie.

• Pole Zapytania musi być zbudowane za pomocą wyrażenia dynamicznego, co pozwala na użycie parametru SchemaName w zapytaniu zwracającym listę docelowych tabel źródłowych. Wybierz pozycję Zapytanie , a następnie wybierz pozycję Dodaj zawartość dynamiczną.

  To wyrażenie w działaniu LookUp generuje instrukcję SQL w celu wykonywania zapytań względem widoków systemowych w celu pobrania listy schematów i tabel. Odwołuje się do parametru SchemaName , umożliwiając filtrowanie schematów SQL. Wynik tego to tablica schematów SQL i tabel, które będą używane jako dane wejściowe do aktywności ForEach.

  Użyj poniższego kodu, aby zwrócić listę wszystkich tabel użytkowników z nazwą schematu.

  @concat('
  SELECT s.name AS SchemaName,
  t.name  AS TableName
  FROM sys.tables AS t
  INNER JOIN sys.schemas AS s
  ON t.type = ''U''
  AND s.schema_id = t.schema_id
  AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
  ')
  

Projekt potoku danych: Pętla ForEach

W przypadku pętli ForEach skonfiguruj następujące opcje na karcie Ustawienia :

• Wyłącz sekwencyjne, aby umożliwić równoczesne uruchamianie wielu iteracji.
• Ustaw Liczba partii na 50, ograniczając maksymalną liczbę współbieżnych iteracji.
• Pole Elementy musi używać zawartości dynamicznej, aby odwoływać się do danych wyjściowych działania LookUp. Użyj następującego fragmentu kodu: @activity('Get List of Source Objects').output.value

Projekt potoku danych: Aktywność kopiowania wewnątrz pętli ForEach

Wewnątrz działania ForEach dodaj działanie kopiowania. Ta metoda wykorzystuje Dynamic Expression Language w potokach do budowy takiej, SELECT TOP 0 * FROM <TABLE> aby migrować tylko schemat bez danych do magazynu.

Na karcie Źródło:

• Ustaw typ magazynu danych na Zewnętrzny.
• Połączenie to Twoja dedykowana pula SQL w Azure Synapse. Typ połączenia to Azure Synapse Analytics.
• Ustaw opcję Użyj zapytania na Zapytanie.
• W polu Zapytanie wklej zapytanie zawartości dynamicznej i użyj tego wyrażenia, które zwróci zero wierszy, tylko schemat tabeli:@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

Na karcie Miejsce docelowe:

• Ustaw Typ magazynu danych na Obszar roboczy.
• Typ magazynu danych Workspace to Data Warehouse, a Data Warehouse jest ustawiony na magazyn.
• Schemat i nazwa tabeli docelowej są definiowane przy użyciu zawartości dynamicznej.
  • Schemat odnosi się do pola aktualnej iteracji, SchemaName z fragmentem: @item().SchemaName
  • Tabela odnosi się do TableName z fragmentem: @item().TableName

Projekt rurociągu: zlew

Dla Sink wskaż swój Magazyn i odnieś się do Schemy Źródłowej i nazwy Tabeli.

Po uruchomieniu tego potoku zobaczysz, że Hurtownia Danych została wypełniona każdą tabelą z twojego źródła z odpowiednim schematem.

Migracja przy użyciu procedur składowanych w dedykowanej puli SQL usługi Synapse

Ta opcja używa procedur przechowywanych do przeprowadzenia migracji Fabric.

Przykłady kodu można pobrać w witrynie microsoft/fabric-migration on GitHub.com. Ten kod jest udostępniany jako open source, dlatego możesz współtworzyć współpracę i pomóc społeczności.

Co mogą zrobić procedury składowane migracji:

• Przekonwertuj schemat (DDL) na składnię Fabric Data Warehouse.
• Stwórz schemat (DDL) na Fabric Data Warehouse.
• Wyodrębnianie danych z dedykowanej puli SQL usługi Synapse do usługi ADLS.
• Oznaczanie nieobsługiwanej składni Fabric dla kodu T-SQL (procedur składowanych, funkcji, widoków).

Zalecane użycie

Jest to świetna opcja dla tych, którzy:

• Znasz język T-SQL.
• Chcesz użyć zintegrowanego środowiska programistycznego, takiego jak SQL Server Management Studio (SSMS).
• Chcesz mieć bardziej szczegółową kontrolę nad zadaniami, nad którymi chcą pracować.

Można wykonać określoną procedurę składowaną dla konwersji schematu (DDL), wyodrębniania danych lub oceny kodu T-SQL.

Do migracji danych musisz użyć albo COPY INTO Fabric Data Factory, aby pobrać dane do swojego magazynu.

Migrowanie przy użyciu projektów bazy danych SQL

Magazyn danych usługi Microsoft Fabric jest obsługiwany w rozszerzeniu SQL Database Projects dostępnym w programie Visual Studio Code.

To rozszerzenie jest dostępne w programie Visual Studio Code. Ta funkcja umożliwia korzystanie z funkcji kontroli źródła, testowania bazy danych i sprawdzania poprawności schematu.

Więcej informacji na temat kontroli wersji można znaleźć w przeglądzie rozwoju i wdrożenia.

Zalecane użycie

Jest to świetna opcja dla tych, którzy wolą używać projektu bazy danych SQL do celów wdrożeniowych. Ta opcja zasadniczo zintegrowała procedury składowane migracji Fabric z projektem bazy danych SQL, aby zapewnić płynne doświadczenie migracji.

Projekt usługi SQL Database może wykonywać następujące czynności:

• Przekonwertuj schemat (DDL) na składnię Fabric Data Warehouse.
• Stwórz schemat (DDL) na Fabric Data Warehouse.
• Wyodrębnianie danych z dedykowanej puli SQL usługi Synapse do usługi ADLS.
• Oznaczanie niewspieranej składni dla kodów T-SQL (procedury składowane, funkcje, widoki).

Do migracji danych użyjesz jednego z COPY INTO tych narzędzi Data Factory do pobierania danych do magazynu.

Zespół CAT usługi Microsoft Fabric udostępnił zestaw skryptów programu PowerShell do obsługi wyodrębniania, tworzenia i wdrażania schematu (DDL) i kodu bazy danych (DML) za pośrednictwem projektu usługi SQL Database. Aby zapoznać się z przewodnikiem po korzystaniu z projektu SQL Database z naszymi przydatnymi skryptami programu PowerShell, zapoznaj się z microsoft/fabric-migration na GitHub.com.

Aby uzyskać więcej informacji na temat projektów usługi SQL Database, zobacz Rozpoczynanie pracy z rozszerzeniem projektów usługi SQL Database i Tworzenie projektu bazy danych z wiersza polecenia.

Migracja danych za pomocą instrukcji CETAS

Polecenie T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) zapewnia najbardziej opłacalną i optymalną metodę wyodrębniania danych z dedykowanych pul SQL usługi Synapse do usługi Azure Data Lake Storage (ADLS) Gen2.

Co może zrobić CETAS:

• Wyodrębnij dane do usługi ADLS.
  • Ta opcja wymaga od użytkowników utworzenia schematu (DDL) w magazynie przed wejściem danych. Zapoznaj się z opcjami w tym artykule, aby przeprowadzić przeniesienie schematu (DDL).

Zalety tej opcji to:

• Tylko jedno zapytanie na tabelę jest przesyłane do dedykowanej puli SQL w usłudze Synapse. Nie będzie to używać wszystkich slotów współbieżności, więc nie zablokuje równoczesnych operacji ETL/zapytań produkcyjnych klientów.
• Skalowanie do DWU6000 nie jest wymagane, ponieważ dla każdej tabeli używany jest tylko jeden slot współbieżności, dzięki czemu klienci mogą używać niższe wartości DWU.
• Aby uzyskać lepszą wydajność, wyodrębnianie jest uruchamiane równolegle na wszystkich węzłach obliczeniowych, co jest kluczowe dla jej poprawy.

Zalecane użycie

Użyj CETAS, aby wyodrębnić dane do usługi ADLS w formacie plików Parquet. Pliki Parquet zapewniają korzyść w postaci wydajnego przechowywania danych dzięki kompresji kolumnowej, co pozwala na mniejsze zużycie przepustowości podczas przesyłania przez sieć. Ponadto, ponieważ Fabric przechowuje dane w formacie Delta Parquet, pobieranie danych będzie 2,5 raza szybsze w porównaniu z formatem plików tekstowych, ponieważ podczas pobierania nie występuje narzut związany z konwersją na format Delta.

Aby zwiększyć przepływność CETAS:

• Dodaj równoległe operacje CETAS, zwiększając wykorzystanie slotów współbieżności, ale umożliwiając większą przepustowość.
• Skaluj DWU w dedykowanej puli SQL Synapse.

Migracja za pomocą dbt

W tej sekcji omówimy opcję dbt dla tych klientów, którzy już używają bazy danych dbt w bieżącym dedykowanym środowisku puli SQL usługi Synapse.

Co dbt może zrobić:

• Przekonwertuj schemat (DDL) na składnię Fabric Data Warehouse.
• Stwórz schemat (DDL) na Fabric Data Warehouse.
• Przekonwertuj kod bazy danych (DML) na składnię Fabric.

Platforma dbt generuje DDL i DML (skrypty SQL) na bieżąco z każdym wykonaniem. Dla plików modelu wyrażonych w instrukcjach SELECT, instrukcje DDL/DML można przetłumaczyć natychmiast na dowolną platformę docelową, zmieniając profil (parametry połączenia) i typ adaptera.

Zalecane użycie

Struktura dbt to podejście oparte na kodzie. Dane muszą być migrowane przy użyciu opcji wymienionych w tym dokumencie, takich jak CETAS lub COPY/Data Factory.

Adapter dbt dla Microsoft Fabric Data Warehouse pozwala na migrację istniejących projektów dbt, które celowały w różne platformy, takich jak dedykowane pule SQL w Synapse, Snowflake, Databricks, Google Big Query czy Amazon Redshift, migrację do magazynu za pomocą prostej zmiany konfiguracji.

Aby rozpocząć projekt DBT skierowany do Fabric Data Warehouse, zobacz Tutorial: Ustaw dbt dla Fabric Data Warehouse. Ten dokument zawiera również listę opcji przenoszenia między różnymi magazynami/platformami.

Pobieranie danych do Fabric Data Warehouse

Do pobierania danych do Fabric Data Warehouse użyj COPY INTO lub Fabric Data Factory, w zależności od preferencji. Obie metody są zalecanymi i najlepiej wydajnymi opcjami, ponieważ mają równoważną przepływność wydajności, biorąc pod uwagę wymagania wstępne, że pliki są już wyodrębnione do usługi Azure Data Lake Storage (ADLS) Gen2.

Należy pamiętać o kilku czynnikach, aby można było zaprojektować proces pod kątem maksymalnej wydajności:

• W Fabric nie ma konkurencji zasobów przy jednoczesnym ładowaniu wielu tabel z ADLS do Fabric Data Warehouse. W związku z tym podczas ładowania wątków równoległych nie występuje spadek wydajności. Maksymalna przepustowość danych będzie ograniczona jedynie przez moc obliczeniową zasobów Fabric.
• Zarządzanie obciążeniem w ramach architektury zapewnia rozdzielenie zasobów przydzielonych do przetwarzania danych i wykonywania zapytań. Nie ma rywalizacji o zasoby podczas wykonywania zapytań i ładowania danych w tym samym czasie.

Powiązana zawartość

• Asystent Migracji Tkaniny dla Hurtowni Danych
• Tworzenie magazynu w usłudze Microsoft Fabric
• Wytyczne dotyczące wydajności magazynu danych fabryki
• Zabezpieczenia magazynowania danych w usłudze Microsoft Fabric
• Blog: Mapowanie dedykowanych pul SQL usługi Azure Synapse na obliczenia usługi Fabric Data Warehouse
• Omówienie migracji usługi Microsoft Fabric