Projektowanie i wydajność migracji Netezza
Ten artykuł jest jedną z siedmiu części serii, która zawiera wskazówki dotyczące migracji z Netezza do usługi Azure Synapse Analytics. Celem tego artykułu jest najlepsze rozwiązania dotyczące projektowania i wydajności.
Omówienie
Ze względu na zakończenie wsparcia firmy IBM wielu istniejących użytkowników systemów magazynu danych Netezza chce skorzystać z innowacji oferowanych przez nowoczesne środowiska w chmurze. Środowiska chmurowe typu infrastruktura jako usługa (IaaS) i platforma jako usługa (PaaS) umożliwiają delegowanie zadań, takich jak konserwacja infrastruktury i programowanie platformy dla dostawcy usług w chmurze.
Porada
Więcej niż tylko baza danych — środowisko platformy Azure zawiera kompleksowy zestaw możliwości i narzędzi.
Mimo że Netezza i Azure Synapse Analytics to bazy danych SQL, które używają technik masowego przetwarzania równoległego (MPP) w celu osiągnięcia wysokiej wydajności zapytań na wyjątkowo dużych woluminach danych, istnieją pewne podstawowe różnice w podejściu:
Starsze systemy Netezza są często instalowane lokalnie i korzystają z zastrzeżonego sprzętu, podczas gdy Azure Synapse jest oparta na chmurze i korzysta z zasobów obliczeniowych i magazynu platformy Azure.
Uaktualnianie konfiguracji netezza jest głównym zadaniem obejmującym dodatkowy sprzęt fizyczny i potencjalnie długie ponowne skonfigurowanie bazy danych lub zrzut i ponowne ładowanie. Ponieważ zasoby magazynu i zasobów obliczeniowych są oddzielne w środowisku platformy Azure i mają elastyczne możliwości skalowania, te zasoby można skalować w górę lub w dół niezależnie.
Możesz wstrzymać lub zmienić rozmiar Azure Synapse zgodnie z potrzebami, aby zmniejszyć wykorzystanie zasobów i koszty.
Platforma Microsoft Azure to globalnie dostępne, wysoce bezpieczne, skalowalne środowisko chmury, które obejmuje Azure Synapse i ekosystem pomocniczych narzędzi i możliwości. Następny diagram zawiera podsumowanie ekosystemu Azure Synapse.
Azure Synapse zapewnia najlepszą wydajność relacyjnej bazy danych przy użyciu technik, takich jak MPP i wiele poziomów zautomatyzowanego buforowania dla często używanych danych. Wyniki tych technik można zobaczyć w niezależnych testach porównawczych, takich jak ten uruchamiany niedawno przez GigaOm, który porównuje Azure Synapse z innymi popularnymi ofertami magazynu danych w chmurze. Klienci, którzy migrują do środowiska Azure Synapse, widzą wiele korzyści, w tym:
Zwiększona wydajność i cena/wydajność.
Zwiększona elastyczność i krótszy czas na wartość.
Szybsze wdrażanie serwera i tworzenie aplikacji.
Elastyczna skalowalność — płaci się tylko za rzeczywiste użycie.
Ulepszone zabezpieczenia/zgodność.
Zmniejszono koszty magazynowania i odzyskiwania po awarii.
Niższe ogólne TCO, lepsza kontrola kosztów i usprawnione wydatki operacyjne (OPEX).
Aby zmaksymalizować te korzyści, zmigruj nowe lub istniejące dane i aplikacje do platformy Azure Synapse. W wielu organizacjach migracja obejmuje przeniesienie istniejącego magazynu danych ze starszej platformy lokalnej, takiej jak Netezza, do Azure Synapse. Na wysokim poziomie proces migracji obejmuje następujące kroki:
Przygotowanie 🡆
Zdefiniuj zakres — co ma zostać zmigrowane.
Tworzenie spisu danych i procesów na potrzeby migracji.
Zdefiniuj zmiany modelu danych (jeśli istnieją).
Definiowanie mechanizmu wyodrębniania danych źródłowych.
Zidentyfikuj odpowiednie narzędzia i funkcje platformy Azure i innych firm do użycia.
Szkolić pracowników na początku nowej platformy.
Skonfiguruj platformę docelową platformy Azure.
Migracja ㋂
Zacznij od małych i prostych.
Automatyzuj wszędzie tam, gdzie jest to możliwe.
Skorzystaj z wbudowanych narzędzi i funkcji platformy Azure, aby zmniejszyć nakład pracy nad migracją.
Migrowanie metadanych dla tabel i widoków.
Migrowanie danych historycznych do utrzymania.
Migrowanie lub refaktoryzacja procedur składowanych i procesów biznesowych.
Migrowanie lub refaktoryzacja procesów ładowania przyrostowego ETL/ELT.
Zadania po migracji
Monitoruj i dokumentuj wszystkie etapy procesu.
Skorzystaj z zdobytego środowiska, aby utworzyć szablon na potrzeby przyszłych migracji.
W razie potrzeby należy ponownie zaprojektować model danych (przy użyciu nowej wydajności i skalowalności platformy).
Testowanie aplikacji i narzędzi do wykonywania zapytań.
Testowanie porównawcze i optymalizowanie wydajności zapytań.
Ten artykuł zawiera ogólne informacje i wytyczne dotyczące optymalizacji wydajności podczas migracji magazynu danych z istniejącego środowiska Netezza do Azure Synapse. Celem optymalizacji wydajności jest osiągnięcie tej samej lub lepszej wydajności magazynu danych w Azure Synapse po migracji schematu.
Zagadnienia dotyczące projektowania
Zakres migracji
Podczas przygotowywania do migracji ze środowiska Netezza należy wziąć pod uwagę następujące opcje migracji.
Wybieranie obciążenia na potrzeby migracji początkowej
Zazwyczaj starsze środowiska Netezza ewoluowały wraz z upływem czasu, aby obejmować wiele obszarów tematycznych i mieszanych obciążeń. Podczas podejmowania decyzji, gdzie rozpocząć pracę nad projektem migracji, wybierz obszar, w którym będzie można wykonywać następujące zadania:
Udowodnij rentowność migracji do Azure Synapse, szybko zapewniając korzyści z nowego środowiska.
Zezwól pracownikom technicznym na uzyskanie odpowiedniego doświadczenia z procesami i narzędziami, których będą używać podczas migracji innych obszarów.
Utwórz szablon do dalszych migracji specyficznych dla źródłowego środowiska Netezza oraz bieżących narzędzi i procesów, które już istnieją.
Dobry kandydat na początkową migrację ze środowiska Netezza obsługuje poprzednie elementy i:
Implementuje obciążenie analizy biznesowej/analizy, a nie obciążenie przetwarzania transakcji online (OLTP).
Ma model danych, taki jak gwiazda lub schemat płatka śniegu, który można migrować z minimalnymi modyfikacjami.
Porada
Utwórz spis obiektów, które należy zmigrować i udokumentować proces migracji.
Ilość migrowanych danych w początkowej migracji powinna być wystarczająco duża, aby zademonstrować możliwości i zalety środowiska Azure Synapse, ale nie zbyt duże, aby szybko zademonstrować wartość. Rozmiar w zakresie terabajtów 1–10 jest typowy.
W przypadku początkowego projektu migracji zminimalizuj ryzyko, nakład pracy i czas migracji, aby szybko zobaczyć zalety środowiska chmury platformy Azure. Zarówno metody migracji metodą lift-and-shift, jak i migracji fazowej ograniczają zakres migracji początkowej tylko do marty danych i nie dotyczą szerszych aspektów migracji, takich jak migracja ETL i migracja danych historycznych. Można jednak rozwiązać te aspekty w późniejszych fazach projektu, gdy zmigrowana warstwa mart danych zostanie wypełniona danymi i wymaganymi procesami kompilacji.
Podejście migracji metodą "lift and shift" a podejście etapowe
Ogólnie rzecz biorąc, istnieją dwa typy migracji niezależnie od przeznaczenia i zakresu planowanej migracji: lift and shift as-is i podejście etapowe, które obejmuje zmiany.
Migrowanie metodą „lift-and-shift”
W przypadku migracji metodą lift and shift istniejący model danych, taki jak schemat gwiazdy, jest migrowany bez zmian do nowej platformy Azure Synapse. Takie podejście minimalizuje ryzyko i czas migracji, zmniejszając pracę potrzebną do realizacji korzyści związanych z przejściem do środowiska chmury platformy Azure. Migracja metodą lift-and-shift jest dobrym rozwiązaniem dla następujących scenariuszy:
- Masz istniejące środowisko Netezza z pojedynczą składnicą danych do migracji lub
- Masz istniejące środowisko Netezza z danymi, które są już w dobrze zaprojektowanym schemacie gwiazdy lub płatka śniegu lub
- Jesteś w czasie i pod presją kosztów, aby przejść do nowoczesnego środowiska chmury.
Porada
Lift and shift to dobry punkt wyjścia, nawet jeśli kolejne fazy implementują zmiany w modelu danych.
Podejście etapowe, które obejmuje zmiany
Jeśli starszy magazyn danych ewoluował przez długi czas, może być konieczne ponowne zaprojektowanie go w celu utrzymania wymaganych poziomów wydajności. Konieczne może być również ponowne zaprojektowanie obsługi nowych danych, takich jak strumienie Internetu rzeczy (IoT). W ramach procesu ponownej inżynierii przeprowadź migrację do Azure Synapse, aby uzyskać korzyści ze skalowalnego środowiska chmury. Migracja może również obejmować zmianę bazowego modelu danych, taką jak przejście z modelu Inmon do magazynu danych.
Firma Microsoft zaleca przeniesienie istniejącego modelu danych zgodnie z oczekiwaniami na platformę Azure oraz wykorzystanie wydajności i elastyczności środowiska platformy Azure w celu zastosowania zmian inżynierii ponownie. Dzięki temu możesz użyć możliwości platformy Azure, aby wprowadzić zmiany bez wpływu na istniejący system źródłowy.
Używanie Azure Data Factory do implementowania migracji opartej na metadanych
Proces migracji można zautomatyzować i zorganizować przy użyciu możliwości środowiska platformy Azure. Takie podejście minimalizuje trafienie wydajności w istniejącym środowisku Netezza, które może już działać blisko pojemności.
Azure Data Factory to oparta na chmurze usługa integracji danych, która obsługuje tworzenie przepływów pracy opartych na danych w chmurze, które organizują i automatyzują przenoszenie danych i przekształcanie danych. Za pomocą usługi Data Factory można tworzyć i planować oparte na danych przepływy pracy (potoki), które pozyskiwają dane z różnych magazynów danych. Usługa Data Factory może przetwarzać i przekształcać dane przy użyciu usług obliczeniowych, takich jak Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics i Azure Machine Learning.
Gdy planujesz używać obiektów usługi Data Factory do zarządzania procesem migracji, utwórz metadane zawierające listę wszystkich tabel danych do migracji i ich lokalizacji.
Różnice projektowe między Netezza i Azure Synapse
Jak wspomniano wcześniej, istnieją pewne podstawowe różnice w podejściu między bazami danych Netezza i Azure Synapse Analytics, a te różnice zostały omówione w następnej kolejności.
Wiele baz danych a pojedyncza baza danych i schematy
Środowisko Netezza często zawiera wiele oddzielnych baz danych. Na przykład mogą istnieć oddzielne bazy danych: pozyskiwanie danych i tabele przejściowe, podstawowe tabele magazynu i składnice danych (czasami nazywane warstwą semantyczną). Procesy potoków ETL lub ELT mogą implementować sprzężenia między bazami danych i przenosić dane między oddzielnymi bazami danych.
Z kolei środowisko Azure Synapse zawiera pojedynczą bazę danych i używa schematów do oddzielania tabel w logicznie oddzielnych grupach. Zalecamy użycie serii schematów w docelowej bazie danych Azure Synapse w celu naśladowania oddzielnych baz danych migrowanych ze środowiska Netezza. Jeśli środowisko Netezza już używa schematów, może być konieczne użycie nowej konwencji nazewnictwa podczas przenoszenia istniejących tabel i widoków Netezza do nowego środowiska. Można na przykład połączyć istniejące nazwy schematów i tabel Netezza z nową nazwą tabeli Azure Synapse i użyć nazw schematów w nowym środowisku w celu zachowania oryginalnych oddzielnych nazw baz danych. Jeśli nazewnictwo konsolidacji schematów ma kropki, Azure Synapse Platforma Spark może mieć problemy. Mimo że można używać widoków SQL na podstawie bazowych tabel do obsługi struktur logicznych, istnieją potencjalne wady tego podejścia:
Widoki w Azure Synapse są tylko do odczytu, więc wszystkie aktualizacje danych muszą odbywać się w podstawowych tabelach bazowych.
Może już istnieć co najmniej jedna warstwa widoków i dodanie dodatkowej warstwy widoków może mieć wpływ na wydajność i obsługę, ponieważ zagnieżdżone widoki są trudne do rozwiązania.
Porada
Połącz wiele baz danych w jedną bazę danych w Azure Synapse i użyj nazw schematów, aby logicznie oddzielić tabele.
Zagadnienia dotyczące tabel
Podczas migrowania tabel między różnymi środowiskami zwykle tylko nieprzetworzone dane i metadane opisujące je fizycznie. Inne elementy bazy danych z systemu źródłowego, takie jak indeksy, zwykle nie są migrowane, ponieważ mogą być niepotrzebne lub zaimplementowane inaczej w nowym środowisku.
Optymalizacje wydajności w środowisku źródłowym, takie jak indeksy, wskazują, gdzie można dodać optymalizację wydajności w nowym środowisku. Jeśli na przykład zapytania w źródłowym środowisku Netezza często używają map stref, sugeruje to, że w Azure Synapse powinien zostać utworzony indeks nieklasowany. Inne natywne techniki optymalizacji wydajności, takie jak replikacja tabel, mogą być bardziej odpowiednie niż proste tworzenie indeksów podobnych do podobnych.
Porada
Istniejące indeksy wskazują kandydatów do indeksowania w zmigrowanym magazynie.
Nieobsługiwane typy obiektów bazy danych Netezza
Funkcje specyficzne dla platformy Netezza mogą być często zastępowane przez funkcje Azure Synapse. Jednak niektóre obiekty bazy danych Netezza nie są bezpośrednio obsługiwane w Azure Synapse. Na poniższej liście nieobsługiwanych obiektów bazy danych Netezza opisano, jak można osiągnąć równoważną funkcjonalność w Azure Synapse.
Mapy stref: w Netezza mapy strefy są automatycznie tworzone i obsługiwane dla następujących typów kolumn i są używane w czasie zapytania w celu ograniczenia ilości danych do skanowania:
INTEGER
kolumn o długości 8 bajtów lub mniej.- Kolumny czasowe, takie jak
DATE
,TIME
iTIMESTAMP
. CHAR
kolumny, jeśli są częścią zmaterializowanego widoku i wymienione w klauzuliORDER BY
.
Możesz dowiedzieć się, które kolumny mają mapy stref, korzystając z
nz_zonemap
narzędzia , które jest częścią zestawu narzędzi NZ Toolkit. Azure Synapse nie obejmuje map strefowych, ale można osiągnąć podobne wyniki przy użyciu innych typów indeksów zdefiniowanych przez użytkownika i/lub partycjonowania.Tabele podstawowe grupowane (CBT): w Netezza często używane są tabele faktów, które mogą zawierać miliardy rekordów. Skanowanie tak ogromnej tabeli wymaga znacznego czasu przetwarzania, ponieważ może być konieczne pełne skanowanie tabeli w celu uzyskania odpowiednich rekordów. Organizowanie rekordów na restrykcyjnych rekordach CBTs umożliwia Netezza grupowanie rekordów w tych samych lub pobliskich zakresach. Ten proces tworzy również mapy stref, które zwiększają wydajność, zmniejszając ilość danych, które należy skanować.
W Azure Synapse można osiągnąć podobny efekt, partycjonując i/lub używając innych indeksów.
Zmaterializowane widoki: Platforma Netezza obsługuje zmaterializowane widoki i zaleca używanie jednego lub większej liczby zmaterializowanych widoków dla dużych tabel z wieloma kolumnami, jeśli tylko kilka kolumn jest regularnie używanych w zapytaniach. Zmaterializowane widoki są automatycznie odświeżane przez system po zaktualizowaniu danych w tabeli podstawowej.
Azure Synapse obsługuje zmaterializowane widoki z taką samą funkcjonalnością jak Netezza.
Mapowanie typu danych Netezza
Większość typów danych Netezza ma bezpośredni odpowiednik w Azure Synapse. W poniższej tabeli przedstawiono zalecane podejście do mapowania typów danych Netezza na Azure Synapse.
Typ danych Netezza | typ danych Azure Synapse |
---|---|
BIGINT | BIGINT |
BINARY VARYING(n) | Varbinary(n) |
BOOLEAN | BITOWYCH |
BYTEINT | TINYINT |
RÓŻNE ZNAKI (n) | Varchar(n) |
ZNAK(n) | CHAR(n) |
DATE | DATE(date) |
LICZBA DZIESIĘTNA(p,s) | LICZBA DZIESIĘTNA(p,s) |
PODWÓJNA PRECYZJA | FLOAT |
FLOAT(n) | FLOAT(n) |
LICZBA CAŁKOWITA | INT |
INTERWAŁ | Typy danych INTERVAL nie są obecnie obsługiwane bezpośrednio w Azure Synapse, ale można je obliczyć przy użyciu funkcji czasowych, takich jak DATEDIFF. |
PIENIĄDZE | PIENIĄDZE |
ZNAK NARODOWY RÓŻNI SIĘ (n) | Nvarchar(n) |
ZNAK NARODOWY (n) | NCHAR(n) |
NUMERIC(p,s) | NUMERIC(p,s) |
LICZBA RZECZYWISTA | LICZBA RZECZYWISTA |
SMALLINT | SMALLINT |
ST_GEOMETRY(n) | Typy danych przestrzennych, takie jak ST_GEOMETRY, nie są obecnie obsługiwane w Azure Synapse, ale dane mogą być przechowywane jako VARCHAR lub VARBINARY. |
CZAS | CZAS |
CZAS ZE STREFĄ CZASOWĄ | DATETIMEOFFSET |
TIMESTAMP | DATETIME |
Porada
Oceń liczbę i typ nieobsługiwanych typów danych w fazie przygotowywania migracji.
Zewnętrzni dostawcy oferują narzędzia i usługi do automatyzacji migracji, w tym mapowanie typów danych. Jeśli narzędzie ETL innej firmy jest już używane w środowisku Netezza, użyj tego narzędzia do zaimplementowania wszelkich wymaganych przekształceń danych.
Różnice składni języka DML sql
Różnice składni języka SQL DML istnieją między bazą danych Netezza SQL i Azure Synapse języka T-SQL. Te różnice zostały szczegółowo omówione w temacie Minimalizuj problemy z bazą danych SQL na potrzeby migracji netezza.
STRPOS
: w NetezzaSTRPOS
funkcja zwraca pozycję podciągów w ciągu. Równoważną funkcją w Azure Synapse jestCHARINDEX
kolejność odwróconych argumentów. Na przykładSELECT STRPOS('abcdef','def')...
w netezza jest odpowiednikiemSELECT CHARINDEX('def','abcdef')...
w Azure Synapse.AGE
: Netezza obsługujeAGE
operator , aby nadać interwał między dwiema wartościami czasowymi, takimi jak znaczniki czasu lub daty, na przykład:SELECT AGE('23-03-1956','01-01-2019') FROM...
. W Azure Synapse użyj poleceniaDATEDIFF
, aby uzyskać interwał, na przykład:SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM...
. Zanotuj sekwencję reprezentacji daty.NOW()
: Netezza używaNOW()
elementu do reprezentowaniaCURRENT_TIMESTAMP
w Azure Synapse.
Funkcje, procedury składowane i sekwencje
Podczas migrowania magazynu danych ze środowiska dojrzałego, takiego jak Netezza, prawdopodobnie trzeba migrować elementy inne niż proste tabele i widoki. Sprawdź, czy narzędzia w środowisku platformy Azure mogą zastąpić funkcjonalność funkcji, procedur składowanych i sekwencji, ponieważ zwykle bardziej wydajne jest używanie wbudowanych narzędzi platformy Azure niż ponowne kodowanie tych elementów dla Azure Synapse.
W ramach fazy przygotowania utwórz spis obiektów, które muszą zostać zmigrowane, zdefiniuj metodę ich obsługi i przydziel odpowiednie zasoby w planie migracji.
Partnerzy integracji danych oferują narzędzia i usługi, które mogą zautomatyzować migrację funkcji, procedur składowanych i sekwencji.
W poniższych sekcjach szczegółowo omówiono migrację funkcji, procedur składowanych i sekwencji.
Funkcje
Podobnie jak w przypadku większości produktów baz danych, netezza obsługuje funkcje systemowe i zdefiniowane przez użytkownika w ramach implementacji SQL. Podczas migracji starszej platformy bazy danych do Azure Synapse typowe funkcje systemowe można zwykle migrować bez zmian. Niektóre funkcje systemowe mogą mieć nieco inną składnię, ale wszelkie wymagane zmiany można zautomatyzować.
W przypadku funkcji systemowych Netezza lub dowolnych funkcji zdefiniowanych przez użytkownika, które nie mają odpowiedników w Azure Synapse, zakoduj je ponownie przy użyciu języka środowiska docelowego. Funkcje zdefiniowane przez użytkownika netezza są kodowane w językach nzlua lub C++. Azure Synapse używa języka Transact-SQL do implementowania funkcji zdefiniowanych przez użytkownika.
Procedury składowane
Większość nowoczesnych produktów baz danych obsługuje procedury przechowywania w bazie danych. Netezza udostępnia w tym celu język NZPLSQL oparty na bazie bazy danych Postgres PL/pgSQL. Procedura składowana zwykle zawiera zarówno instrukcje SQL, jak i logikę proceduralną oraz zwraca dane lub stan.
Azure Synapse obsługuje procedury składowane przy użyciu języka T-SQL, dlatego należy ponownie zakodować wszystkie zmigrowane procedury składowane w tym języku.
Sekwencje
W netezza sekwencja jest nazwanym obiektem bazy danych utworzonym przy użyciu polecenia CREATE SEQUENCE
. Sekwencja udostępnia unikatowe wartości liczbowe za pośrednictwem NEXT VALUE FOR
metody . Wygenerowanych unikatowych liczb można użyć jako wartości klucza zastępczego dla kluczy podstawowych.
Azure Synapse nie implementuje CREATE SEQUENCE
instrukcji , ale można zaimplementować sekwencje przy użyciu kolumn IDENTITY lub kodu SQL, który generuje następny numer sekwencji w serii.
Wyodrębnianie metadanych i danych ze środowiska Netezza
Generowanie języka DDL (Data Definition Language)
Standard ANSI SQL definiuje podstawową składnię poleceń języka DDL (Data Definition Language). Niektóre polecenia DDL, takie jak i CREATE VIEW
, są wspólne zarówno dla Netezza, jak CREATE TABLE
i Azure Synapse, ale zostały rozszerzone w celu zapewnienia funkcji specyficznych dla implementacji.
Istniejące skrypty i CREATE VIEW
Netezza CREATE TABLE
można edytować, aby uzyskać równoważne definicje w Azure Synapse. W tym celu może być konieczne użycie zmodyfikowanych typów danych i usunięcie lub zmodyfikowanie klauzul specyficznych dla platformy Netezza, takich jak ORGANIZE ON
.
W środowisku Netezza tabele wykazu systemu określają bieżącą tabelę i definicję widoku. W przeciwieństwie do dokumentacji obsługiwanej przez użytkownika informacje o wykazie systemu są zawsze kompletne i zsynchronizowane z bieżącymi definicjami tabel. Za pomocą narzędzi, takich jak nz_ddl_table
, można uzyskać dostęp do informacji katalogu systemu w celu wygenerowania CREATE TABLE
instrukcji DDL, które tworzą równoważne tabele w Azure Synapse.
Można również użyć narzędzi migracji innych firm i ETL, które przetwarzają informacje o katalogu systemu, aby uzyskać podobne wyniki.
Wyodrębnianie danych z netezza
Nieprzetworzone dane tabeli można wyodrębnić z tabel Netezza do plików rozdzielanych płaskich, takich jak pliki CSV, przy użyciu standardowych narzędzi Netezza, takich jak nzsql i nzunload, lub za pomocą tabel zewnętrznych. Następnie można skompresować proste pliki rozdzielane przy użyciu narzędzia gzip i przekazać skompresowane pliki do Azure Blob Storage przy użyciu narzędzia AzCopy lub narzędzi do transportu danych platformy Azure, takich jak Azure Data Box.
Wyodrębnianie danych tabeli tak wydajnie, jak to możliwe. Użyj podejścia do tabel zewnętrznych, ponieważ jest to najszybsza metoda wyodrębniania. Wykonaj wiele wyodrębnień równolegle, aby zmaksymalizować przepływność wyodrębniania danych. Poniższa instrukcja SQL wykonuje wyodrębnianie tabeli zewnętrznej:
CREATE EXTERNAL TABLE '/tmp/export_tab1.csv' USING (DELIM ',') AS SELECT * from <TABLENAME>;
Jeśli dostępna jest wystarczająca przepustowość sieci, możesz wyodrębnić dane z lokalnego systemu Netezza bezpośrednio do tabel Azure Synapse lub usługi Azure Blob Data Storage. W tym celu należy użyć procesów usługi Data Factory lub migracji danych innych firm lub produktów ETL.
Porada
Użyj tabel zewnętrznych Netezza do najbardziej wydajnego wyodrębniania danych.
Wyodrębnione pliki danych powinny zawierać tekst rozdzielany w formacie CSV, zoptymalizowanym kolumnie wierszy (ORC) lub Parquet.
Aby uzyskać więcej informacji na temat migrowania danych i etL ze środowiska Netezza, zobacz Migracja danych, ETL i ładowanie migracji Netezza.
Zalecenia dotyczące wydajności migracji Netezza
Celem optymalizacji wydajności jest taka sama lub lepsza wydajność magazynu danych po migracji do Azure Synapse.
Podobieństwa w pojęciach dotyczących podejścia dostrajania wydajności
Wiele pojęć dotyczących dostrajania wydajności baz danych Netezza ma wartość true dla baz danych Azure Synapse. Przykład:
Użyj dystrybucji danych, aby połączyć dane do przyłączenia do tego samego węzła przetwarzania.
Użyj najmniejszego typu danych dla danej kolumny, aby zaoszczędzić miejsce do magazynowania i przyspieszyć przetwarzanie zapytań.
Upewnij się, że kolumny do sprzężenia mają ten sam typ danych, aby zoptymalizować przetwarzanie sprzężenia i zmniejszyć potrzebę przekształcania danych.
Aby pomóc optymalizatorowi utworzyć najlepszy plan wykonania, upewnij się, że statystyki są aktualne.
Monitorowanie wydajności przy użyciu wbudowanych funkcji bazy danych w celu zapewnienia wydajnego używania zasobów.
Porada
Określ priorytety opcji dostrajania w Azure Synapse na początku migracji.
Różnice w podejściu do dostrajania wydajności
W tej sekcji przedstawiono różnice implementacji dostrajania wydajności niskiego poziomu między netezza i Azure Synapse.
Opcje dystrybucji danych
Aby uzyskać wydajność, Azure Synapse została zaprojektowana z architekturą z wieloma węzłami i korzysta z przetwarzania równoległego. Aby zoptymalizować wydajność tabel, można zdefiniować opcję dystrybucji danych w CREATE TABLE
instrukcjach przy użyciu DISTRIBUTION
instrukcji w Azure Synapse i DISTRIBUTE ON
Netezza.
W przeciwieństwie do netezza, Azure Synapse obsługuje sprzężenia lokalne między małą tabelą a dużą tabelą przez małą replikację tabel. Rozważmy na przykład małą tabelę wymiarów i dużą tabelę faktów w modelu schematu gwiazdy. Azure Synapse może replikować mniejszą tabelę wymiarów we wszystkich węzłach, aby upewnić się, że wartość dowolnego klucza sprzężenia dla dużej tabeli ma pasujący, dostępny lokalnie wiersz wymiaru. Obciążenie replikacji tabeli wymiarów jest stosunkowo niskie dla małej tabeli wymiarów. W przypadku dużych tabel wymiarów bardziej odpowiednie jest podejście dystrybucji skrótów. Aby uzyskać więcej informacji na temat opcji dystrybucji danych, zobacz Wskazówki dotyczące projektowania przy użyciu tabel replikowanych i Wskazówki dotyczące projektowania tabel rozproszonych.
Indeksowanie danych
Azure Synapse obsługuje kilka opcji indeksowania z możliwością definiowania użytkownika, które mają inną operację i użycie w porównaniu z mapami stref zarządzanych przez system w Netezza. Aby uzyskać więcej informacji na temat różnych opcji indeksowania w Azure Synapse, zobacz Indeksy w dedykowanych tabelach puli SQL.
Istniejące mapy strefy zarządzanej przez system w źródłowym środowisku Netezza zapewniają przydatne wskazanie użycia danych i kolumn kandydatów do indeksowania w środowisku Azure Synapse.
Partycjonowanie danych
W magazynie danych przedsiębiorstwa tabele faktów mogą zawierać miliardy wierszy. Partycjonowanie optymalizuje konserwację i wydajność zapytań w tych tabelach, dzieląc je na oddzielne części, aby zmniejszyć ilość przetwarzanych danych. W Azure Synapse CREATE TABLE
instrukcja definiuje specyfikację partycjonowania dla tabeli.
Do partycjonowania można używać tylko jednego pola na tabelę. To pole jest często polem daty, ponieważ wiele zapytań jest filtrowanych według daty lub zakresu dat. Istnieje możliwość zmiany partycjonowania tabeli po początkowym załadowaniu przy użyciu instrukcji (CTAS), aby ponownie utworzyć tabelę przy użyciu CREATE TABLE AS
nowej dystrybucji. Szczegółowe omówienie partycjonowania w Azure Synapse można znaleźć w temacie Partitioning tables in dedicated SQL pool (Partycjonowanie tabel w dedykowanej puli SQL).
Statystyki tabeli danych
Należy upewnić się, że statystyki dotyczące tabel danych są aktualne, tworząc w kroku statystyk zadania ETL/ELT.
Program PolyBase lub COPY INTO na potrzeby ładowania danych
Technologia PolyBase obsługuje wydajne ładowanie dużych ilości danych do magazynu danych przy użyciu strumieni ładowania równoległego. Aby uzyskać więcej informacji, zobacz Strategia ładowania danych polyBase.
Funkcja COPY INTO obsługuje również pozyskiwanie danych o wysokiej przepływności i:
Pobieranie danych ze wszystkich plików w folderze i podfolderach.
Pobieranie danych z wielu lokalizacji na tym samym koncie magazynu. Możesz określić wiele lokalizacji przy użyciu ścieżek rozdzielanych przecinkami.
Azure Data Lake Storage (ADLS) i Azure Blob Storage.
Formaty plików CSV, PARQUET i ORC.
Zarządzanie obciążeniem
Uruchamianie mieszanych obciążeń może stanowić wyzwania związane z zasobami w systemach zajętych. Pomyślny schemat zarządzania obciążeniami skutecznie zarządza zasobami, zapewnia wysoce wydajne wykorzystanie zasobów i maksymalizuje zwrot z inwestycji (ROI). Klasyfikacja obciążeń, ważność obciążenia i izolacja obciążeń zapewniają większą kontrolę nad sposobem korzystania z zasobów systemowych przez obciążenie.
W przewodniku zarządzania obciążeniami opisano techniki analizowania obciążenia, zarządzania i monitorowania ważności obciążenia oraz kroków konwertowania klasy zasobów na grupę obciążeń. Użyj zapytań Azure Portal i T-SQL dla dynamicznych widoków zarządzania, aby monitorować obciążenie, aby upewnić się, że odpowiednie zasoby są efektywnie wykorzystywane.
Następne kroki
Aby dowiedzieć się więcej na temat procesu ETL i ładowania migracji netezza, zobacz następny artykuł w tej serii: Migracja danych, ETL i ładowanie migracji Netezza.