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

Dotyczy:✅ Magazyn w systemie Microsoft Fabric

W tym artykule szczegółowo przedstawiono metody migracji magazynowania danych w dedykowanych pulach SQL usługi Azure Synapse Analytics do usługi Microsoft Fabric Warehouse.

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 .

Wybieranie obciążenia na potrzeby migracji początkowej

Gdy decydujesz, gdzie rozpocząć pracę nad dedykowaną pulą SQL usługi Synapse w projekcie migracji usługi Fabric Warehouse, wybierz obszar obciążenia, w którym możesz wykonać następujące działania:

• Udowodnij zasadność migracji do Fabric Warehouse, szybko dostarczając korzyści wynikające z nowego środowiska. Rozpocznij od małych i prostych, przygotuj się do wielu małych migracji.
• 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.

Ilość migrowanych danych w początkowej migracji powinna być wystarczająco duża, aby zademonstrować możliwości i zalety środowiska Magazynu Danych Fabric, ale nie na tyle duża, tak aby szybko zademonstrować 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 Warehouse.
• Utwórz schemat (DDL) w Fabric Warehouse.
• Migracja danych do Fabric Warehouse.

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

Ta metoda używa asystenta kopiowania usługi Data Factory do nawiązywania połączenia ze źródłową dedykowaną pulą danych SQL, konwertowania składni DDL dedykowanej puli SQL na Fabric i kopiowania danych do magazynu Fabric. 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.
• Usługa Data Factory kopiuje dane bezpośrednio z dedykowanej puli SQL do magazynu Fabric Warehouse, ale wymaga to etapowania. Proces przyjmowania 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 polega na przenoszeniu danych ze strefy przejściowej do Magazynu Fabric. 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 pętli ForEach zapewnia prosty interfejs użytkownika do konwertowania instrukcji DDL i importowania wybranych tabel z dedykowanej puli SQL do magazynu danych Fabric 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 operacje odczytu równoległego wymagają specjalnej puli SQL do skalowania do wyższych wartości DWU, aby umożliwić wykonywanie zapytań wyodrębniania. Wykorzystując partycjonowanie, wydajność zwiększa się dziesięciokrotnie w porównaniu do braku partycjonowania. Możesz zwiększyć liczbę jednostek DWU, aby uzyskać dodatkową przepływność za pośrednictwem zasobów obliczeniowych, ale dedykowana pula SQL pozwala maksymalnie na 128 aktywnych zapytań.

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

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 usługi Data Factory lub polecenia COPY, aby pozyskać dane do Fabric Warehouse.

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

Pipelines Fabric umożliwiają łatwe migrowanie DDL schematów dla obiektów tabeli z dowolnej źródłowej bazy danych Azure SQL Database lub dedykowaną pulą SQL. Ten pipeline migruje schemat (DDL) dla źródłowych tabel dedykowanej puli SQL do Fabric 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 Zapytanie musi zostać skompilowane przy użyciu wyrażenia dynamicznego, co umożliwia 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, aby umożliwić 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 używa Dynamicznego Języka Wyrażeń w potokach, w celu stworzenia SELECT TOP 0 * FROM <TABLE> do migracji tylko schematu, bez danych, do hurtowni danych Fabric.

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 obszaru roboczego to Data Warehouse, a Data Warehouse jest ustawiony na Fabric Warehouse.
• Schemat i nazwa tabeli docelowej są definiowane przy użyciu zawartości dynamicznej.
  • Schema odnosi się do pola bieżącej 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 Warehouse.
• Utwórz schemat (DDL) w Fabric 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.

W przypadku migracji danych należy użyć polecenia COPY INTO lub Data Factory, aby załadować dane do Fabric Warehouse.

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.

Aby uzyskać więcej informacji na temat kontroli źródła dla magazynów w Microsoft Fabric, w tym integracji z Git oraz potoków wdrażania, zobacz Kontrola źródła dla magazynu.

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 Warehouse.
• Utwórz schemat (DDL) w Fabric 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).

W przypadku migracji danych użyjesz polecenia COPY INTO czy Data Factory, aby zaimportować dane do hurtowni danych.

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 Getting started with the SQL Database Projects extension (Wprowadzenie do rozszerzenia SQL Database Projects) i Build and Publish a project (Kompilowanie i publikowanie projektu).

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 Fabric przed wczytaniem 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 Warehouse.
• Utwórz schemat (DDL) w Fabric 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 usługi Microsoft Fabric Data Warehouse umożliwia migrowanie istniejących projektów dbt przeznaczonych dla różnych platform, takich jak dedykowane pule SQL usługi Synapse, Snowflake, Databricks, Google Big Query lub Amazon Redshift, do magazynu Fabric z prostą zmianą konfiguracji.

Aby rozpocząć pracę z projektem dbt przeznaczonym dla magazynu danych Fabric, zobacz Samouczek: Konfigurowanie dbt dla magazynu danych Fabric. Ten dokument zawiera również listę opcji przenoszenia między różnymi magazynami/platformami.

Pozyskiwanie danych do magazynu danych Fabric

W celu pozyskiwania danych do Fabric 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 przypadku platformy Fabric nie ma konkurencji o zasoby podczas jednoczesnego ładowania wielu tabel z ADLS do magazynu Fabric. 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: Przypisywanie dedykowanych pul SQL systemu Azure Synapse do obliczeń hurtowni danych Fabric
• Omówienie migracji usługi Microsoft Fabric